なぜ「ドキュメントを読んで」は機能しないのか
チームのメンバーが手順を間違えたり、すでに共有したはずの質問をしてきたとき、リーダーはよくこう嘆きます。「ドキュメントに書いてあるのに、なぜ読んでくれないのか？」
多くの場合、読み手側が怠惰だと思われがちです。しかし、問題のドキュメントを開いてみると、そこにはフォーマットされていない文字の壁があり、何が重要なのか分からないまま、結論に辿り着くまでに長い背景が語られていることがほとんどです。
チームが社内文書を読まないのは、関心がないからではありません。単に、読むのが「疲れる」ビジュアルになっているからです。
あなたの文書を「ランディングページ」として扱う
もし自社のWebサイトのエンゲージメント率が20%しかなかったら、マーケティングチームはすぐに「ファーストビュー」を修正するはずです。見出しを研ぎ澄まし、ノイズを削り、スクロールしなくても「次に押すべきボタン」が分かるようにするでしょう。
社内のドキュメントにも、全く同じアプローチが必要です。ドキュメントを開いて最初に目に入る画面（ファーストビュー）で、「この記事は誰向けか」「結論は何か」「次に何を見るべきか」が即座に伝わる必要があります。
非同期コミュニケーションを軸とする少人数チームにおいて、文章の正確さだけでは不十分です。文章の「構造」こそが、それが読まれるかどうかを決定します。
読みにくい文書がもたらすコスト
AIの普及により、社内のテキスト量は爆発的に増えています。3ページの議事録や5ページの企画書を生成するのは一瞬です。
しかし、テキストが増えればノイズも増えます。もし、目的を理解するだけで5分かかるドキュメントばかりになれば、チームは無意識のうちに社内のナレッジベースを避けるようになります。そして結局、Slackなどのチャットツールで直接質問を投げる「割り込み」の習慣へと戻ってしまうのです。
ファーストビューを修正する3つの手順
1. 冒頭に結論（TL;DR）を置く
ドキュメントを歴史や背景から書き始めてはいけません。必ず「結論」から始めてください。一番上に太字で TL;DR（要約） を置き、もし最初の3文しか読まれなかったとしても、一番伝えたい情報が相手に届くように設計します。
2. 内部リンクで次のアクションを明確にする
その文書を読んだ後に別のツールでの作業が必要な場合や、過去の決定事項を参照してほしい場合は、そのリンクをファーストビューに配置してください。Figma、Jira、GitHubなどへの重要なリンクを、3ページ目の最後に埋もれさせてはいけません。次のステップは常に一番目立つ場所に置くべきです。
3. 無慈悲なまでにフォーマットする
段落を細かく分け、箇条書きを使い、重要な用語は太字にします。読み手がページの左側をサッと視線でなぞる（スキャンする）だけで、文章全体の骨格が理解できるようにします。
注意を引くための努力を怠らない
チームがドキュメントを読まないのなら、それは大抵の場合、ドキュメントの「読ませる努力」が足りないからです。
2秒間のスキャン・テスト
ドキュメントをチームに共有する前に、以下の「2秒テスト」を行ってください：
- スクロールせずに、最も重要な結論が見えるか？
- 次のアクションや関連リンクがひと目で分かるか？
- 4文以上連なっている、長すぎる段落はないか？
「すべてが重要」という罠
ドキュメントを改善しようとする際によくある失敗は、「すべてを目立たせてしまう」ことです。すべての文を太字にすれば、結局何も目立たなくなります。ファーストビューに10個のリンクを詰め込めば、どれを押せばいいのか分からなくなります。ファーストビューの目的は、読み手の認知負荷を下げることであり、文章全体を上部に無理やり詰め込むことではありません。
読まれる文章は、編集されている
「文章に残す」ことは、非同期コミュニケーションの半分でしかありません。残りの半分は、「人が実際に読みたくなるようにフォーマットする」ことです。 もし落ち着いて自律的に動くチームを作りたいなら、「ちゃんと読んでくれ」と要求するのをやめ、洗練されたファーストビューによって「読ませる」工夫を始めましょう。
