【Kindle出版】ITエンジニアの「仕様書脳」を「書籍脳」へリファクタリングする方法

こんにちは、Hibikiです。

本記事は、「ITエンジニア×Kindle出版の体系化」シリーズです。
その名も「Chi. （チ。）」プロジェクト。
なぜ「Chi.」なんて名前を付けているのかは、第1回の記事をご覧ください。

「Chi.」プロジェクトは、私たちITエンジニアが「体験したこと、考えたこと、感じたこと」という実践知を1冊の書籍にまとめ、本当に価値あるものを次世代につなぐ活動です。

初回の記事で、「ITエンジニア×Kindle出版」の体系は大きく分けて、以下の4つがあると説明しました。

1️⃣技術トレンドからテーマを決める
2️⃣テーマ内で比較検討する
3️⃣比較結果を基に深堀りする
4️⃣比較・深堀りを発信する

「1️⃣技術トレンドからテーマを決める」を扱った次の記事では、避けるべきテーマを明確にし、

「2️⃣テーマ内で比較検討する」を扱った次の記事では、暗黙知を納得感のある論理構成に落とし込むコツを確認し、

「3️⃣比較結果を基に深堀りする」を扱った次の記事では、深堀りの方向性や方法について見てきました。

そして、ついに私たちの実践知に形を与える作業になります。

システム開発でいうところの「実装フェーズ」です。

私たちITエンジニアは、普段からたくさんのドキュメントを作成します。
要件定義書から設計書、テスト結果報告書、進捗資料や品質評価資料…

これだけドキュメント作成を経験していれば、私たちの実践知を書籍にまとめることも簡単でしょうか。

答えはYesでもあり、Noでもあります。

書籍の執筆はシステム開発に似たところも、異なるところもあります。まだ書籍の執筆をしたことが無い人にとっては、何が異なり、その相違点について自分はクリアできるのか不安でしょう。実際、私も最初の執筆は苦労しました。

伝えたいことはあるのに、いざ書いてみると表面的なことしか書けない、アイディアは良いと思っているのに書いてみると陳腐な内容に感じる…

そこで、本記事では、システム開発でのドキュメンテーションとの相違点に注目しつつ、どう克服していけば良いかを解説していきます。

主な相違点は次の3つです。

1️⃣仕様の定義 ≠ 背景の解説
2️⃣機械的な判定 ≠ 人間的な評価
3️⃣客観的な事実 ≠ 主観的な物語

1つずつ見ていきましょう。

1️⃣仕様の定義 ≠ 背景の解説

私たちITエンジニアが仕事で作成するドキュメントは、短く簡潔な文で仕様を定義するものが多いです。

抜け・漏れが無いように注意しながら、端的に正解を書き切ることが求められます。

仕様の抜け・漏れは、そのままシステムの不具合につながりますので、抜け・漏れが無いことを保証するのはプロフェッショナルとして当然の責務です。

私もこれまでプロジェクトマネージャや管理職として数多くのドキュメントを作成してきましたし、ドキュメント作成は得意だと自負していました。

しかし、それでも書籍の執筆は違いました。

システム開発で作成するドキュメントは、書き手と読み手の間でコンテキストが共有されており、その背景が省略されているのです。

一方で、書籍はコンテキストの共有から行わないと、読み手が迷子になってしまいます。

読み手にストレスなく読んでもらうように、丁寧に背景を描く優しさが必要なのです。

たとえば、次の1文を書いたとします。

私たちにとっては当たり前の情報ですが、知らない人にとってはこの1文では分からないことだらけなのです。

• なぜ暗号化するのか？

• どのように暗号化されているのか？

• 誰が暗号化するのか？

• どのタイミングで暗号化するのか？

• どこに保存されているのか？

もちろん、読み手のレベル感に前提を置くことで省略するものもありますが、私たちベテランの当たり前が、読み手の当たり前ではないことに注意しなくてはいけません。

大事なのは、想定読者のレベルに合わせた疑問をピックアップすることです。

レベル感については、前回の記事で説明した「所与の条件」次第になります。まだ読んでいない方は、ぜひ前回の記事もご一読ください。

書籍の執筆というと、大量の文章が先に目に付きますが、文字数は本質的な問題ではありません。

読み手の疑問に先回りして答え、伝えるべき内容が丁寧にカバーされていることがなにより大事です。

2️⃣機械的な判定 ≠ 人間的な評価

プログラムは実行してみることで、書いたソースコードが正しいのかどうか、設定内容が合っているのかを確認することができます。

しかし、文章の正しさは検証が非常に難しいです。誰も、何もフィードバックしてくれないためです。

知人に頼めば、レビューをしてくれるかもしれません。
しかし、それは一通り完成した後になってしまうでしょう。

私たちが自分でできるセルフレビュー法はないのでしょうか？
私は次の2つの方法を使っています。

①AIを使ったレビュー
②過去の自分に戻ってレビュー

詳しく見ていきましょう。

①AIを使ったレビュー

ご存知の通りAIは急激に進化しています。これをレビューに使わない手はありません。

しかし、AIでのレビューを使いこなすにはコツが必要です。

単に「レビューしてください」と依頼しても、"本質的でない"ところばかり指摘が返ってきます。

これはAIが、私たちの原稿の背景を理解していないためです。
そのため、色々とコンテキスト情報を渡してあげる必要があります。
コンテキスト情報とは、次のようなものです。

• 全体を通して伝えたいメッセージは何か？

• 文章の目的は何か？

• 誰に向けた文章なのか？

• 読了後に、読者にどのようなアクションを取ってほしいか？

• どのような文章のスタイルで書きたいか？

このようなコンテキスト情報を与えることによって、愚直にコンテキスト情報に合ったレビューをしてくれます。

しかし、それでもまだ油断は禁物です。

一見まともな指摘に見えるものでも、他の章と矛盾する指摘が返ってきたりします。

疑問に思う指摘は、必ずAIにぶつけましょう。

のようにAIと会話し、二人(?)で文章を磨き上げるような使い方をするのがベストです。

これは、システム開発におけるペアプログラミングに近いものです。

くれぐれも、AIの指摘をそのまま受け入れるのは避けましょう。

コンテキスト情報を与えなければ、彼らは決して私たちの考えを慮るようなことはしません。

②過去の自分に戻ってレビュー

AIレビューはとても有用ですが、生身の人間に響く内容になるかどうかは疑わしいです。

生身の人間のレビューを受ける上で、一番身近な存在は自分自身です。

私たちが書く実践知は、私たちの経験を通して得たものです。
つまり、その実践知を身につける前の自分がレビューできればベストではないでしょうか。

過去に戻ることはできませんが、頭の中で数年、数十年前の自分に戻り、レビューするという思考実験的なことはできるはずです。

過去の自分が、著作を読んで、今の自分と同じレベルに達することができれば成功です。

そうして出来た書籍は、きっと私たちが実践知を伝えたい相手の成長にも貢献することでしょう。

3️⃣客観的な事実 ≠ 主観的な物語

システム開発でのドキュメントは、仕様に抜け漏れがないように細心の注意を払って、ロジカルに書きます。

一方で、書籍は読み手の共感を得るような書き方をします。

私たちITエンジニアが書籍を執筆するにあたって、最大の難関がこの相違点かもしれません。

私たちは通常、仕様書に自分たちの感想を挟み込みません。
仕様書は、ある意味、無個性であることが求められるものであり、その世界にどっぷり浸かっている私たちにとって、考えたこと、感じたことを書けと言われても、何を書いてよいか戸惑うでしょう。

しかし、振り返ってみてください。
ここに辿り着くまでに、

• 何をメインテーマにするか検討を重ね、

• 比較調査により、伝えるべき特徴を磨き上げ、

• どのレベルまで深堀りするかを考え抜いた

はずです。

その中の様々な判断において、考えたこと、感じたことが数多くあったのではないでしょうか。

伝えるべき相手のことを想い、私たちの実践知をどこまで、どのように伝えるか。そこで考えたこと、感じたことこそ、書籍の中で伝えるものです。

なんて説明には誰も共感しません。

など、私たちが本当に苦労したこと、戦った軌跡のストーリーが共感を呼び、人を強く惹きつけるのです。

そして、それはこの記事に辿り着いた時点ですでに持っているはずです。

私たちは自分の考えや感情を表現するのに慣れていないので、はじめは恥ずかしく感じるかもしれません。

でも隠す必要はないのです。私たちのそうした泥臭い想いこそが、後に続く誰かが動き出すきっかけとなるのです。

📚️まとめ

今回は、「発信」という観点で、システム開発におけるドキュメント作成と書籍の執筆の違いにフォーカスし、次の3点について説明しました。

1️⃣仕様の定義 ≠ 背景の解説
簡潔な正解よりも、読者を迷子にさせないために背景を丁寧に描く「優しさ」を持つこと。

2️⃣機械的な判定 ≠ 人間的な評価
正解を判定してくれるコンパイラはいないからこそ、AIや過去の自分との「対話」で孤独な推敲を乗り越えること。

3️⃣客観的な事実 ≠ 主観的な物語
無機質なロジックではなく、プロとしての葛藤や敗北感といった「泥臭い物語」にこそ共感が宿ること。

IT関連の技術書では通常、プログラミングテクニックのような客観的な事実を書くでしょう。

もちろん、そのような内容をすべて否定している訳ではないのです。

しかし、客観的事実だけなら、AIで良いのです。わざわざ私たちが書く本を読む必要なんてないのです。

だからこそ、客観的事実の裏にある私たちの考え、苦労、恐れ、感情を合わせて伝えるのです。

これは単に「本を売る」テクニックという訳ではありません。

読み手に私たちの思考を辿ってもらうことで、私たちが伝える実践知を最大限活用してもらうためのものです。

慣れるまで少し練習が必要かもしれませんが、必ず出来ます。

さあ、私たちの実践知を形にする時です。私も一緒に、挑戦を続けます。

「Chi.」プロジェクトを応援していただける方、一緒に挑戦していきたい方はぜひフォロー、スキ、コメントをお願いします。

皆さんのリアクションが、この挑戦を続ける大きな力になります。

「ITエンジニア×Kindle出版」のシリーズをマガジンにまとめていきます。

マガジンもフォローいただけると、漏れなく更新を確認できます！

#Kindle出版
#Kindle作家
#プログラマ
#ITエンジニア
#世界観
#実践知
#発信
#Chi
#Hibiki