Kindle出版で相手に刺さる『深掘り』の3つの軸

こんにちは、Hibikiです。

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

「Chi.」プロジェクトで私たちが残していきたいのは、「体験したこと、考えたこと、感じたこと」という実践知である、という話しは何度もお伝えした通りです。

伝えたい想いは、経験を積み重ねたエンジニアであれば山ほどあるでしょう。

しかし、それらの話が単なる自慢話や独り言で終わっては誰にも届きません。

私たちがターゲットにしている人たちに届くように、きちんと理論武装することが大事です。

では、どう理論武装すれば良いのか。

…

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

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

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

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

ここまでのところで、伝えるべきテーマの「骨格」は決まりました。
システム開発で言えば基本設計が完了している状態です。

しかし、「Chi.」プロジェクトの核心はこれからです。

骨格が決まっただけでは、読み手が受け取れる形になっていません。

実際の詳細設計ではデータベースやフレームワークの種類に合わせて物理設計を行うように、私たちの実践知を磨き上げ、伝えるべき相手に届く形に落とし込んでいく。このプロセスが必要です。

私たちが実践知を伝えたい相手のことをAIは知りません。

私たちが相手をしっかりとイメージし、その人たちに向けたメッセージに磨き上げることで、AIに代替されないものを作り上げることができるはずです。

ぼんやりとした輪郭から、実践知のエッセンスを損なうことなく、相手が受け取れる形を掘り出していくプロセスこそ、第3ステップの「3️⃣比較結果を基に深堀りする」です。

しかし、具体的にどうしたらよいでしょうか？

1️⃣どの方向に深堀りするのが良いのか
2️⃣どれくらい深堀りするのが良いのか
3️⃣どう深堀りすれば良いのか

この3つの問いの答えこそ、AIには知り得ない「伝えるべき相手」の姿を深く洞察し、自らの「実践知」をその相手に最適化するものです。

そして、これこそが「Chi.」プロジェクトで定義する「実践知の物理設計」であり、私たちの実践知を伝えるべき相手に届ける戦略となります。

本記事では、「実践知の物理設計」について、これら3つの問いから考察していきましょう。

1️⃣どの方向に深堀りするのが良いのか

私たちが伝えたいものは、IT業界で長年培ってきた経験、考え、感情であることを起点に考えると、深堀りの方向性も自ずと見えてきます。

私たちはシステム開発を通して、普段どのような方向性を考えているでしょうか。

ざっと、次の3種類が挙げられます。

1️⃣ビジネス ⇔ システム
2️⃣個人 ⇔ 集団
3️⃣過去 ⇔ 未来

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

1️⃣ビジネス ⇔ システム

システム開発でまず考える方向性は、ビジネス ⇔ システムではないでしょうか。

どのようなシステムを作るにしても、お客様のビジネスを理解せずに始めることはできません。

お客様の日々のオペレーションを理解し、その中にある課題を浮き彫りにし、その課題を解決するようにシステムを作る、というのが一般的なシステム開発の流れです。

私たちの実践知を伝えるという観点で考えた時も、ビジネス側の知見をより伝えたいのか、システム側の知見を伝えたいのかで、伝える内容が大きく変わってくるでしょう。

ITエンジニアがビジネスを語るのか？と疑問に思うかもしれません。

しかし、システムをどうビジネスに活用できるのか、という観点であれば私たちの実践知は大いに役立つのではないでしょうか。
活用事例は、いつも多くの人が興味を持つ情報です。

また、キャリアが浅いエンジニアはシステム側に視点が偏りがちである点も私たちベテランエンジニアを悩ませるポイントです。

私も20代の頃はそのような傾向が強かったです。
次々と出てくる新しい技術を学ぶのが楽しく、お客様のビジネスにまで気が回りませんでした。

しかし、本当に難しいのは、

です。

私たちの実践知もビジネスとシステムの狭間にあることが多いのではないでしょうか。

私たちの作るシステムが、お客様のビジネスの中でどう使われ、どうお客様の問題を解決しているのかを示すことも私たちベテランエンジニアの大事な仕事です。

2️⃣個人 ⇔ チーム

ここで重要なのは、「個人、チームのどちらが良いか」ではなく、「私たちの読み手は、今どのフェーズにいるか」を見極めることです。

たとえば、まだキャリアをスタートさせたばかりの若手エンジニアに対して、いきなり「チーム全体の生産性」や「組織論」を説いても、ピンとこないでしょう。彼らにとって今必要なのは、目の前のコードを書く技術であり、個人のスキルアップです。

逆に、リーダー層に対して「個人のコーディング速度」の話ばかりしても、「視座が低い」と思われてしまうでしょう。

相手のレベルに合わない情報を提供しても、それはノイズになるだけです。

たとえば、「生産性」というテーマ1つとっても、深堀りの仕方は相手によって変わります。

• 相手が初心者の場合（個人より）： 効率的なデバッグ手法、個人のタスク管理など、「個人の戦闘力」を高める話にフォーカス

• 相手が中堅・リーダーの場合（チームより）： CI/CDによる自動化、心理的安全性など、「チームの成果」を最大化する話にフォーカス

私たちベテランは、つい「全体最適」や「チーム論」といった視座の高い話をしたくなります。

しかし、相手がその段階になければ、私たちが価値を置く「実践知」もただの「説教」として処理されてしまいます。

私たちが実践知を伝えたい相手は今、個人としてレベルアップすべき段階なのか、それともチームとしての成果を求められる段階なのか。

この「フェーズの見極め」と「チューニング」こそが、私たちの実践知を確実に届けるための、重要な物理設計となります。

3️⃣過去 ⇔ 未来

どんどん技術が進化していくIT業界で過去を振り返るなんてあるのか、と疑問に思うかもしれません。

たしかに目新しい技術は多くの人の興味を引き寄せます。

しかし、私たちの現在は、先人たちが築いた過去の上に成り立っていることを考えると、過去の情報はとても大切です。

どのような技術も、過去にあった問題を克服するために生まれてきています。

過去にどのような問題があったのか、それを先人たちはどのように克服したのか、という情報を知らずして、現在の技術を活かしきれません。

新しい技術も取り入れつつ、今の技術が存在する意義を伝えていく、それが私たちベテランエンジニアに求められることではないでしょうか。

2️⃣どれくらい深堀りするのが良いのか

どのレベルまで深堀りするかは、何を「所与の条件」に設定するかにより決まります。そして「所与の条件」は、浅い方と深い方の両方のレベルを設定する必要があります。

まず、「所与の条件」とは何でしょうか？

たとえば、Pythonプログラミングのノウハウを伝えたいとしましょう。

その時に、Pythonの基本的な文法を知っていることを前提とすれば、文法の説明は省略することができます。この場合、「Pythonの基本的な文法を知っている」ことが所与の条件となります。

では、なぜ所与の条件を明確にしておく必要があるのでしょうか？

この所与の条件が、伝えたい相手に合っていない場合、私たちの実践知は単なるノイズになってしまうからです。

先ほどのPythonプログラミングの例でいうと、すでに基本的な文法を知っている人に対して、くどい文法の説明は「マイクロマネジメント」でしかありません。

浅い方の所与の条件を、相手のレベルに合わせて設定することは、信頼を示すことです。一度信頼したら、自信を持って次のレベルを示しましょう。

これは、深い方の条件にも同じことが言えます。

私たちが伝えたい実践知には、少なからず前提条件としているものがあるはずです。

たとえば、AIを使ったシステムの開発ノウハウを伝えたいとしましょう。

その場合、ChatGPT等のLLMはプロンプトを与えたら、何かしら結果を返してくれることを前提としているはずです。それなのに、ディープラーニングの説明まで踏み込んでいては、焦点がブレてしまい、AIを使ったシステム開発に関する私たちの実践知が相手に伝わらないでしょう。

深い方の所与の条件を、相手のレベルに合わせて設定することは、優しさを示すことです。

求められていないのに知っていることを語るのはベテランの「エゴ」です。そのエゴを抑え、相手のために「語らない」という引き算こそが、「優しさ」です。

このように深堀りのレベルを決める際には、相手のレベルに合わせて物理設計を行い、浅い・深いの両方の所与の条件を定めることが必要です。

3️⃣どう深堀りすれば良いのか

深堀りの簡単な方法は、交差する軸を増やすことです。

「交差する軸を増やす」とはどういうことでしょうか？

ITエンジニアであれば日常的にやっていることですが、マトリクスを使った情報整理が良い例です。

たとえば下表のようなマトリクスを使い、権限情報を整理したことがあるでしょう。

これは、X軸に役割、Y軸に機能を並べ、誰が何の権限を持っているか整理したものです。

このように軸を定義し、軸が交差する領域は、内容が限定されます。

上記マトリクスでは、X軸「一般ユーザー」とY軸「商品検索」の交差する領域は、一般ユーザーが商品検索機能に対して持つ権限に限定した内容になっているはずです。

同じ方法を適用し、軸を増やすことで私たちの実践知を深堀りしていくことができます。

そして、この軸の取り方こそ、私たちの経験を活かすところです。ある軸を採用するということは、他の軸を排除することと同義です。

なぜ、その軸を選択したのか、その答えが私たちの実践知の本質を伝えることにつながります。

上記マトリクスのように、私たちITエンジニアは、日常的に情報の構造化を行っています。その点でも、軸を明確にして深堀りしておくことで、ITエンジニアにとって受け入れやすい構成を作ることができるのもメリットです。

では、拙著である「DjangoxPython ユーザー認証の教科書」の例で見てみましょう。

この拙著は、タイトルから分かる通り、次の軸で深堀りしたものです。

✒Python × Web × Django × ユーザー認証

さらに（特徴的なところだけ）中身を見ると、

✒Python × Web × Django × ユーザー認証 × 時系列

にて、ユーザー認証の歴史から未来までを解説しています。
セキュリティは過去の攻防の歴史で成り立っています。
その歴史の理解が、強固なセキュリティを実現することにつながると考え、「時系列」の軸を追加しています。

✒Python × Web × Django × ユーザー認証 × django-allauthライブラリ × 多要素認証

にて、多要素認証の実装方法を説明しています。
多要素認証は、近年の証券口座乗っ取り被害の対策として徹底を急いでいる技術です。
その点で「多要素認証」という軸は必須であると考えました。

✒Python × Web × Django × ユーザー認証 × django-allauthライブラリ × ソーシャルログイン

にて、Googleを使った認証の実装方法を説明しています。
ソーシャルログインは、ユーザーの利便性を向上させるために多くのサイトで取り入れている技術です。
セキュリティは、ユーザーにとってとかく面倒なものです。
その面倒くささを取り除く工夫として「ソーシャルログイン」の軸は必須であると考えました。

✒Python × Web × Django × ユーザー認証 × django-allauthライブラリ × パスキー

にて、パスキー認証の実装方法を説明しています。
2026年現在、パスワードレス技術として普及しつつあるものです。
最新の技術という点で、「パスキー」の軸もカバーしています。

所与の条件の範囲で軸を増やすことで、私たちの実践知を複数の側面から説明することができます。

ある1つの側面だけで物事を表現することは出来ません。
私たちの経験をフル活用し、実践知を最大限表現できる軸を複数選択しましょう。

📚️まとめ

今回は、「深堀り」という観点で次の3点について一緒に見てきました。

1️⃣どの方向に深堀りするのが良いのか
相手のフェーズに合わせ、ビジネスやチームといった「視座」を与える戦略。

2️⃣どれくらい深堀りするのが良いのか
相手を信頼して任せ（浅）、エゴを捨ててノイズを削る（深）という優しさ。

3️⃣どう深堀りすれば良いのか
独自の軸を交差させ、あなただけの経験を削り出す「座標」の確立。

私たちITエンジニアは深堀りがスキな人種ですが、深堀りの技術について議論することは少ないように思います。

「深堀り」という物理設計にて、相手に実践知を適切に伝える方法が見えてきたでしょう。
「深堀り」は、単なる設計技術ではなく、「読み手の姿を洞察する技術」であることも理解いただけたかと思います。

これこそが「Chi.」プロジェクトが掲げる、実践知を届けるための「理論武装」です。

今後も「Chi.」の体系を具体的に解説していきます。

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

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

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

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

#Kindle出版
#Kindle作家
#プログラマ
#ITエンジニア
#世界観
#比較検討
#Hibiki