開発者の文章が読まれない最も一般的な理由は、内容が間違っているからではない。
ほとんどの場合、話す言語が異なるためだ。
開発者は技術の言語で話し、読者は生活の言語で理解する。
このギャップを超えられないと、どんなに良い内容でも人々に残らない。
人々はコードを覚えない
状況を覚える
このような文章を見たことがあるだろう。
“この関数はO(n)で動作します。”
“この構造は拡張性が良いです。”
“この方法がより効率的です。”
間違ったことではない。
しかし数日後、
この文章の内容を覚える人はほとんどいない。
逆にこのような文は残る。
“夜明け3時にサーバーがダウンした時、
このコードが私を救ってくれるだろうか？”
この文には
複雑な技術説明はない。
しかし状況がある。
人々は
技術ではなく状況を通じて理解し、
状況を通じて覚える。
良い開発者文章の共通点
よく読まれる開発者文章をじっくり見ると
共通した特徴がある。
- コードよりも先に状況が出てくる
- 機能説明よりも文脈が先に登場する
- 正解よりも選択の理由が強調される
つまり、こう流れる。
状況 → 考慮 → 判断 → 選択 → 結果
この構造は
技術ブログというより
物語に近い。
そして物語は
人の頭が最もよく受け入れる形式だ。
技術を生活の言語に変えること
技術を生活の言語に翻訳することは
難しい言葉を簡単に解くことではない。
これは視点の移動だ。
例を挙げてみよう。
- “このAPIはRESTfulではない”
“このAPIは初めて使う人が
継続してドキュメントを見直させる。”“この構造は結合度が高い”
“この構造は一箇所だけ修正しようとしても
他の場所も一緒に壊れる。”“パフォーマンス最適化をした”
“トラフィックが殺到しても
眠りに行けるようになった”
技術用語をなくしたわけではない。
技術が生み出す‘現実の変化’を明らかにしたのだ。
なぜこの方法がブランディングに強力なのか
技術中心の文章は
常に競合が多い。
すでに誰かは
よりよく整理し、
より詳しく書き、
より速く説明する。
しかしあなたが経験した状況は複製されない。
- どんな文脈でこの問題に直面したか
- なぜこの選択が必要だったか
- その選択が人生をどう変えたか
これはあなただけが書ける。
だから生活の言語に翻訳された技術文章は
比較されず、
置き換えられない。
読者が“あ、これは私の話だ”と感じる瞬間
ブランディングは
人々がこう言い始めた時に完成する。
“この人の文章は
いつも私の状況と重なる。”
この言葉が出ると
技術の深さとは関係なく
人々は続けて戻ってくる。
なぜなら
その文章が情報を与えるためではなく
自分自身を映し出すためだから。
このように書いてみよう
文章を書く前に
この質問から投げかけてみよう。
- この技術が必要な瞬間はいつだったか
- この選択が私をどんな状態から救ってくれたか
- これを導入する前と後の違いは何だったか
そして文をこのように始めてみよう。
- “これを最初に導入した時、一番不安だったのは…”
- “この機能を作ることを決心した日は…”
- “この構造を選んだ理由は単純だった…”
このように書くと
自然に技術は後退し、
物語が前に出てくる。
次の記事では
次の記事では
こう積み重ねられた物語を
どこに、どのように積むとブランドになるかを取り上げる。
プラットフォームをたくさん使うことがなぜ答えでないか、
なぜ‘本拠地’を一つ定めなければならないか、
そしてブランディングがなぜ
散らばるゲームではなく
蓄積のゲームなのかについて話そう。
次の記事で続けよう。