Curse of knowledge ─ 専門家が書く文書がなぜ新人に通じないか、そして対処法

• 想定読者： 「専門家が書いたのに新人に通じない」状況に直面するテクニカルライター・ドキュメント担当・EM
• 前提知識： 「組織のコンテキスト供給能力を整える実装ガイド」12パターン I の概要
• 所要時間： 通読 約13分／要点把握 約4分

概要

補填する個人が書いたドキュメントは、新人が読んでも何もわからない。前提が省略されすぎ、用語が定義されない、図がない——これは個人の文章力ではなく 構造的バイアス だ。

Camerer, Loewenstein, Weber の1989年の Journal of Political Economy 論文¹ が報告した 「呪いの知識（curse of knowledge）」：いったん知ってしまうと、知らない他者を想像できない認知バイアス。専門家が書く文書はほぼ必ずこのバイアスを抱える。

本記事は、姉妹記事「組織のコンテキスト供給能力を整える実装ガイド」12パターン I を独立記事として深掘りする。バイアスを前提とした文書設計（ペアドキュメンテーション必須化、新人レビュアー、想定読者欄、用語集）を扱う。

症状：通じない専門家ドキュメント

典型的な症状：

• 専門家が書いた手順書を新人が読んでも、実行できない
• 用語の定義がない（「アグリゲーション」「リコンサイル」「ロールフォワード」が定義なしで使われる）
• 「先にやっておくべき設定」が省略されている（書き手は当然と思っている）
• 図がなく、文章だけで複雑な構造を説明している
• エラー時の対処が省略されている（書き手は遭遇したことがない）
• 「○○ということは△△」と論理が飛躍している
• 関連する別文書への参照がない（書き手は記憶している）

これらは書き手の能力不足ではなく 認知バイアス だ。能力が高いほど症状が顕著になる。

メカニズム：呪いの知識（curse of knowledge）

原典：Camerer et al. 1989

Camerer, Loewenstein, Weber の1989年の研究¹ は経済学設定での実験で、情報を持つ参加者が情報を持たない他参加者の判断を 過度に楽観的に 予測することを示した。「私が知っているなら、相手も同程度の理解を持つだろう」という認知の歪み。

Heath & Heath の “Made to Stick”

Chip と Dan Heath の “Made to Stick”² は curse of knowledge を一般読者向けに解説した古典だ。同書が紹介する Elizabeth Newton の有名な実験（1990年 Stanford 博士論文）：「タッパー（叩く側）」と「リスナー（聞く側）」で、タッパーが歌のリズムを叩いて当てさせる。タッパーは50%は当たると予測するが、実際は2.5%しか当たらない。

タッパーは頭の中で曲全体（旋律・歌詞）を聞いているため、リスナーも同じものを聞いていると錯覚する。だがリスナーには「叩く音」しかない。これが curse of knowledge の本質だ。

専門家ほど症状が重い

専門度が高いほど：

• 自分が知っていることが「常識」だと感じる
• 知らない人の状態を想像できなくなる
• 「これは書く必要がない」と省略する
• 用語を定義なしで使う
• 階段を一段飛ばしで論理を進める

結果、書いた文書が 新人に通じない。書き手の能力が高いほど症状が顕著だ。

「優しく書けば伝わる」は誤解

「平易な言葉で書けば伝わる」は誤解だ。問題は 言葉の難しさ ではなく 前提の省略。文章自体は簡単な言葉で書かれていても、暗黙の前提（背景知識・先行手順・関連知識）が省略されていれば、新人には通じない。

対処の方向

1. ペアドキュメンテーションの必須化

書き手と質問役を分ける ペアドキュメンテーション：

• 書き手：専門知識の保有者
• 質問役：その領域を知らない、または学習中の人
• 質問役が「これってどういう意味？」「なぜこれが必要？」「次に何が起きる？」を継続的に質問する
• 書き手が答え、質問役がそれを文書化する
• 完成後、書き手がレビュー

これは Stripe の文書化文化³ や、技術ライティングの “interview-based documentation” 系譜と同じ手法だ。書く責任を分散 することで curse を軽減する。

2. 新人を「ドキュメントレビュアー」に任命

入社直後の新人を ドキュメントレビュアー に任命：

• 「分からない箇所」「前提が抜けている箇所」を指摘する役割
• 新人だからこそ curse の影響がない
• レビュー結果を文書改善に反映
• 新人にとっても、組織知の理解が深まる利点

これは新人オンボーディングそのものの一部にできる。「分からない箇所を指摘してくれてありがとう」という規範を作る。

3. 想定読者と前提知識の明示

ドキュメントテンプレートに 必須項目 として組み込む：

## 想定読者
- 例：エンジニアリング歴2年以上、SQL 基礎知識あり、本システムは初めて

## 前提知識
- xx の基本概念
- yy の操作経験
- zz のドキュメントを先に読んでおく

## 用語
- A: ...
- B: ...

これは Diátaxis フレームワーク⁴ の Tutorial / How-to ドキュメントで特に重要だ。「想定読者」を明示すると、書き手も「この人に通じるか」を意識する。

4. ドメイン用語を glossary に紐付け

各文書から glossary（用語集） に自動リンクする運用：

• 専門用語の初出時に glossary へのリンク
• glossary は組織で1つに集約
• 用語の追加・更新は誰でもできる
• 用語を使うときは glossary でチェックする習慣

これにより、書き手が「この用語は当然分かる」と省略しても、読み手が後追いで定義を確認できる。

5. 書く側の認知トレーニング

書き手側にも訓練を提供：

• 「これは新人に通じない」を体感するワークショップ
• Heath & Heath のタッパー実験を実演
• 過去に書いた自分のドキュメントを新人に読ませて、不明点を指摘してもらう
• 自分の curse パターンを認識する1on1

「自分は分かりやすく書いている」という確信を解体することが第一歩だ。

アンチパターン

パターン	何が起きるか	対処
「専門家が書いたから安心」	curse で新人に通じない	ペアドキュメンテーション必須化
「読み手が悪い（勉強不足）」	永遠に通じない文書が量産	書き手側の認知バイアスを認識
「ライティング研修すれば書ける」	個人スキル論で構造を見ない	構造的設計（ペア・新人レビュー）
「優しい言葉で書けば伝わる」	言葉でなく前提省略が問題	想定読者と前提知識の明示
テクニカルライターを雇って解決	curse は専門家との対話で再生産される	テクニカルライターも質問役として機能させる

まとめ

• 呪いの知識（curse of knowledge）：いったん知ると知らない他者を想像できない認知バイアス
• Camerer et al. 1989 が経済学設定で実証、Heath & Heath が一般化
• 専門度が高いほど症状が顕著、能力不足ではなく構造的バイアス
• 「優しく書けば伝わる」は誤解。問題は言葉でなく前提省略
• 対処：ペアドキュメンテーション必須化／新人をレビュアーに／想定読者・前提知識の明示／glossary への自動リンク／書き手側の認知トレーニング

関連記事

• 組織のコンテキスト供給能力を整える実装ガイド ─ 直視から、修復へ - 本記事の親記事
• 暗黙知保有者の status anxiety - ペアドキュメンテーションの設計（status anxiety への対処と接続）
• ドキュメンテーション・シアター - 死んだ文書と curse の関係
• ADR / Pitch / キックオフメモの実装ガイド - Diátaxis フレームワークと文書設計

参考資料

1. The Curse of Knowledge in Economic Settings: An Experimental Analysis - Colin Camerer, George Loewenstein, Martin Weber, Journal of Political Economy, vol. 97, no. 5 (1989). DOI: 10.1086/261651。【信頼性: 高】 ↩︎ ↩︎²

2. Made to Stick: Why Some Ideas Survive and Others Die - Chip Heath, Dan Heath, Random House (2007). ISBN: 9781400064281。タッパー実験で curse を一般化。【信頼性: 中〜高】 ↩︎

3. From kickoffs to retros and Slack channels — Stripe’s documentation best practices with Brie Wolfson - First Round Review (2023). 【信頼性: 高】 ↩︎

4. Diátaxis: A systematic framework for technical documentation authoring - Daniele Procida (継続更新). Tutorial / How-to / Reference / Explanation の4分類。【信頼性: 中〜高】 ↩︎