知識の呪いとは?説明が伝わらないときに見直したい前提

判断・認知バイアス
Psychology Laws 編集部

「手順は説明したのに、なぜ途中で止まるのだろう」「資料には書いてあるのに、質問が何度も出る」。仕事では、説明する側には当然に見えることが、初めて聞く相手には前提から分からないことがあります。

知識の呪いとは、自分が知っている情報をいったん脇に置いて、知らない人の立場を正確に想像することが難しくなる傾向です。問題は知識が多いこと自体ではなく、自分には見えている前提を、相手にも見えていると見積もってしまうことにあります。この記事では、研究で確かめられている範囲と、仕事の説明を組み立てるときの具体的な確認方法を紹介します。

知識の呪いとは?意味と仕組み

知識の呪い(curse of knowledge)は、ある答えや情報を知っている人が、その情報を知らない人の判断や理解を見積もるときに、自分の知識の影響を十分に取り除けない現象です。

たとえば、社内システムを毎日使っている人には「案件を登録してフェーズを更新する」という説明だけで操作の流れが思い浮かぶかもしれません。しかし初めて使う人には、「案件とは何か」「どの時点で登録するのか」「フェーズはどこで変更するのか」という前提がありません。説明者はそれらを頭の中で補えますが、受け手は補えません。

この名称を用いたCamerer・Loewenstein・Weber(1989)は、情報を多く持つ人が、情報の少ない人の判断を予測するとき、自分だけが持つ追加情報を十分に無視できないことを実験で示しました。

なお、知識の呪いは「自分がどれだけ理解しているかを過大評価する」現象とは焦点が異なります。知識の呪いで問題になるのは、主に相手が何を知っているか・どこまで分かるかの見積もりです。

研究で分かっていること

研究からは、知識や経験があるほど必ず説明が悪くなる、という単純な結論は出ません。ただし、自分の知識が相手の理解や初心者の難しさの見積もりに入り込むことは、複数の研究で確認されています。

結果を知ると、知らない人の判断を再現しにくい

Camererら(1989)は、会社の利益予測を題材に、実際の利益を知らない参加者の予測を集めた後、実際の利益を知っている別の参加者に「知らない人たちはどのように予測したか」を見積もらせました。情報を持つ側の判断は、実際の利益の方向へ引っ張られました。

さらに、正確に答える金銭的な動機や結果のフィードバックがあっても、この偏りは簡単には消えませんでした。市場での取引は偏りをおよそ半分にしましたが、完全にはなくしていません。つまり「気をつければ簡単に相手の立場に戻れる」とは限らないことが分かります。Camererら(1989)

専門家は初心者の難しさを小さく見積もることがある

Hinds(1999)は、専門家・中級者・初心者に、初心者が複雑な作業を終えるまでの時間を予測させました。専門性が高い人ほど初心者の所要時間を正確に予測しにくく、初心者が感じる難しさを小さく見積もる傾向が見られました。偏りを減らすための工夫を加えても、十分には解消されませんでした。

専門家の説明は抽象的になりやすいが、抽象説明にも役割がある

Hinds・Patterson・Pfeffer(2001)は、電子回路の配線作業を使って、専門家と初心者が別の初心者へどのような指示を出すかを調べました。専門家は初心者よりも、抽象的で高度な表現を多く使い、具体的な表現を少なく使っていました。

別の実験では、初心者から指示を受けた人のほうが、同じ作業を行うときの成績がよく、説明上の問題も少なく報告しました。一方、同じ分野の別の作業へ応用するときは、専門家から説明を受けた人のほうがよい結果でした。最初の作業には具体性が役立ち、仕組みを別の場面へ応用するには抽象的な原理が役立つ場合がある、という点が重要です。

「自分の知識を使わないようにする」だけでは足りない

Tullis・Feder(2023)は4つの実験で、参加者に雑学の答えを学習してもらい、初心者がどのくらい答えを知っているかを予測させました。学習が進むと、初心者の知識量を過大評価しやすくなり、どの問題が初心者にとって易しいか・難しいかを見分ける精度も下がる条件がありました。

また、自分の経験への依存を減らす操作をしても、予測精度は改善しませんでした。著者らは、問題は単に「自分を基準にしすぎる」ことだけではなく、相手について判断するための手がかりが不足していることにもあると説明しています。仕事では、頭の中で初心者を想像するだけでなく、実際の受け手から情報を得ることが重要だと考えられます。

仕事での具体例

以下は研究で使われた場面ではなく、知識の呪いを仕事で考えるための仮の例です。

営業チームに新しく入った人へ、顧客管理システムの使い方を教えるとします。経験者が「見積もりを出したら案件化して、フェーズを更新してください」とだけ伝えた場合、経験者には十分でも、新人には判断できない点が残ります。

  • 「案件化」はどの状態になったら行うのか
  • どの画面から登録するのか
  • フェーズは何種類あり、何を基準に選ぶのか
  • 更新後に誰が何のために見るのか

そこで最初は、「顧客に見積もりを出したら案件を作成する」「案件画面のフェーズ欄で現在の状態を選ぶ」のように、元の業務ルールを変えずに開始条件と操作を具体的に示します。そのうえで、「この情報は売上予測に使うため、商談の進み具合を同じ基準で記録する」と理由を説明します。

具体的な操作だけで終わらせず、後から目的や原理も加えることで、初回の作業と別の場面への応用の両方を支えやすくなります。

仕事で活かす方法

  1. 説明する前に、相手が知らない可能性のある前提を書き出す
    専門用語、略語、作業を始める条件、完成形、判断基準を確認します。「自分には当たり前」を探す作業です。
  2. 最初の一回は、具体的な行動まで示す
    「適切に処理する」ではなく、「どの画面で、何を見て、どの項目を選ぶか」まで落とします。初心者がその説明だけで一度やり切れるかを基準にします。
  3. 具体的な手順のあとに、理由や原理を添える
    手順だけでは別のケースに応用しにくくなります。「なぜこの順番なのか」「どの条件なら別の処理になるのか」まで説明します。
  4. 「分かりましたか」ではなく、実際の理解を確かめる
    相手に一件操作してもらう、開始条件を自分の言葉で説明してもらうなど、行動や説明から不足している前提を探します。自分だけで初心者の状態を想像するより、相手から手がかりを得られます。
  5. 質問された箇所を、次の説明の前提に戻す
    同じ質問が出るなら、相手の理解力だけの問題と決めず、説明側で省略した条件や用語がないかを見直します。

活用するときの注意点

  • 短い説明がすべて知識の呪いによるわけではありません。情報不足、時間不足、資料の構成、曖昧なルールなど、別の原因もあります。

参考文献・出典