専門家間の「分かりきっているはず」を疑う：暗黙知と前提をストーリーで共有し誤解を防ぐ技術
専門性の高い分野で長年の経験を積まれた方ほど、特定の知識や概念について「これは当然共有されているだろう」「この言葉の意味は皆理解しているはずだ」と考えがちです。しかし、同じ専門分野にいるはずの同僚や他部署の専門家との間で、プロジェクトの進行中や技術的な議論の中で、認識のずれや前提の違いから生じる誤解に直面した経験はないでしょうか。
この「分かりきっているはず」という認識の落とし穴は、特に複雑な技術開発や研究において、手戻りや非効率を生む大きな要因となり得ます。異なるバックグラウンドや過去の経験を持つ専門家同士では、たとえ同じ用語を使っていても、そこに紐づく具体的なイメージや重要視するポイント、あるいは属人的なノウハウとしての「暗黙知」に違いがあることは少なくありません。
本記事では、このような専門家間の暗黙知や前提知識のギャップから生じる誤解を防ぎ、より正確で深い共通理解を醸成するための手法として、「ストーリー形式で伝える」ことの有効性とその実践方法について掘り下げていきます。単なる技術情報の羅列ではなく、背景や文脈を共有する物語の力を使うことで、いかにして見えない前提を「見える化」し、チーム全体の足並みを揃えることができるのかを探ります。
なぜ専門家間の「分かりきっているはず」は誤解を生むのか
高い専門性を持つ個人やチームが集まる環境では、各々が持つ知識の質と量が豊富である一方、それが「暗黙知」として個人や特定のグループ内に留まりやすいという側面があります。暗黙知とは、言葉や文字では表現しにくい、経験に基づいた直感的・身体的な知識やノウハウのことです。
専門家同士のコミュニケーションにおいて誤解が生じる背景には、主に以下の要因が考えられます。
- 異なる経験や経緯: 同じ専門分野であっても、所属する部門、過去に携わったプロジェクト、参照してきた情報源などが異なれば、培われた暗黙知や重視する観点にも違いが生まれます。特定の概念に対する理解の深さや、具体的なケースに対する「勘所」が異なるのです。
- 専門用語の多義性: 専門用語の中には、分野や文脈によって微妙に意味が異なったり、定義が曖昧であったりするものがあります。互いに異なる定義を前提としていることに気づかず会話を進めると、議論が噛み合わなくなります。
- 省略と効率化: 専門家同士の会話では、効率を重視して多くの前提が省略されがちです。「言わなくても分かるだろう」という判断が働く一方、その省略された部分にこそ、前提のずれが隠されていることがあります。
- 新しい情報の定着度: 最新の研究成果や、過去にチーム内で共有されたものの全員に十分に浸透していない情報なども、前提知識のギャップを生む原因となります。
これらの要因が複合的に絡み合い、「分かりきっているはず」という意識が、見えない前提のずれを生み出し、後々になって大きな手戻りや意思決定の遅延、あるいは誤った判断に繋がるリスクを高めるのです。
暗黙知と前提の共有にストーリー形式が有効な理由
では、なぜ専門的な暗黙知や前提を共有する上で、ストーリー形式が有効なのでしょうか。そのメカニズムは、情報の伝達方法と人間の認知特性に深く関わっています。
- 背景と文脈の共有: ストーリーは単なる事実の羅列ではなく、出来事の背景、原因と結果、登場人物の意図や感情といった「文脈」を含みます。専門的な前提や暗黙知は、多くの場合、特定の背景や経験から培われたものです。ストーリー形式で伝えることで、その知識がどのように生まれ、なぜ重要なのかという背景ごと共有でき、受け手は表層的な情報だけでなく、その「成り立ち」や「意味合い」を深く理解できます。
- 抽象概念の具体化: 専門的な前提や暗黙知は、抽象的な概念として存在することが多いです。ストーリーは具体的な登場人物（システム、部品、データ、関係者など）や出来事（問題発生、意思決定、試行錯誤など）を通じて語られるため、抽象的な概念を具体的なイメージとして捉えやすくなります。
- 共感と記憶の促進: 人間はストーリーに感情移入しやすく、出来事とその背景を結びつけて記憶する能力に優れています。過去の失敗談や成功への道のりといったストーリーは、単なる指示や情報伝達よりも記憶に残りやすく、共有された前提が「自分ごと」として認識されやすくなります。
- なぜ、その前提が重要なのかを示す: ストーリーは、「もし、この前提がなかったらどうなるか」といったリスクシナリオや、「過去にこういう問題が起きたから、この前提を置いている」といった経験則を効果的に伝えることができます。これにより、受け手はその前提が単なる情報ではなく、具体的な重要性を持つものであると納得しやすくなります。
暗黙知・前提をストーリーとして構成するフレームワーク
専門的な暗黙知や前提をストーリーとして効果的に伝えるためには、いくつかのステップと視点があります。以下に、具体的なフレームワークとテクニックを紹介します。
ステップ1：共有すべき暗黙知・前提を特定する
まず、どのような暗黙知や前提がチーム内で共有されていない可能性があるのか、あるいは共有されることで誤解を防げるのかを明確にします。
- 過去のヒヤリハットを洗い出す: 過去に前提のずれが原因で問題が発生した事例（軽微なものも含め）を振り返ります。「あの時、〇〇さんはこう考えていたが、私はこう考えていた」という具体的なシーンを特定します。
- 重要な設計思想や判断基準を言語化する: プロジェクトや技術の根幹に関わる設計思想、過去の重要な意思決定の判断基準、暗黙のうちに行っているリスク評価の方法などを改めて言葉にしてみます。
- 部門間・担当者間で異なる可能性のある視点をリストアップする: 同じ技術要素でも、設計担当者、実装担当者、評価担当者、顧客対応担当者など、それぞれの立場で重視するポイントや知識の深さが異なります。どのような違いが考えられるかを列挙します。
- 「初心者ならつまずきそう」な点を考える: もしこの分野に初めて触れる人がいたら、どの点で前提知識が不足しているか、どのような点が自明ではないかを想像します。
ステップ2：想定する聴き手（受け手）を理解する
専門家同士とはいえ、そのバックグラウンドは様々です。誰に何を伝えるのかを明確にし、その受け手がどのような知識を持ち、どのような経験をしているか、どのような前提を持っているかを推測します。
- 聴き手の専門分野・担当: 同じ研究開発職でも、物理系、化学系、情報系など専門が異なれば、共通言語や知っているはずの前提も異なります。
- プロジェクトへの関わり方: 設計段階に関わるのか、実装に関わるのか、評価に関わるのか、あるいはマネジメント層なのかによって、必要となる前提知識の深度や種類が異なります。
- 過去の経験: 過去に同じような技術やプロジェクトに関わった経験があるかどうかで、前提として共有されているレベルが大きく変わります。
ステップ3：ストーリーの核となるメッセージと構造を設計する
特定した暗黙知や前提を伝えるために、どのような物語が最も効果的かを設計します。
- 核となるメッセージ: 伝えたい暗黙知や前提そのものがメッセージです。「このパラメータは、過去の実験で〇〇の条件では不安定になることが分かっている」「この設計選択は、将来的な〇〇の可能性を考慮している」「このエラーコードは、表面的な原因とは異なる真の原因を示すことがある」といった、具体的かつ重要な情報をメッセージとします。
- 物語の構造:
- 問題提起: 伝えたい前提が共有されていなかった場合に起こりうる問題や、過去に実際に発生した困った出来事を提示します。（例: 「もし、この前提を知らないと、後で〇〇という予期せぬ問題に直面します」「以前、これを知らなかったために、〇〇という失敗をしてしまいました」）
- 背景・原因: なぜその前提が生まれたのか、その知識がどのようにして得られたのか、過去に何があったのかを説明します。経験や試行錯誤の過程を語ります。（例: 「これは、過去に〇〇という現象を解析する中で見つかった知見です」「〇〇という実験を繰り返すうちに、この振る舞いがあることが分かりました」）
- 解決・示唆: その前提を知っていることで、どのように問題を防げるのか、どのような意思決定に役立つのかを示します。その知識が持つ価値を伝えます。（例: 「この前提を知っておけば、設計初期段階で〇〇を考慮でき、手戻りを防げます」「この知識は、エラー発生時の迅速な原因特定に役立ちます」）
ステップ4：比喩、アナロジー、具体的なエピソードを活用する
抽象的な概念や専門的な前提を分かりやすく伝えるためには、適切な比喩やアナロジー、そして具体的なエピソードが非常に有効です。
- 比喩・アナロジー: 全く異なる分野の、しかし構造が似ている事象に例えることで、直感的な理解を促します。例えば、複雑なシステム間のデータ連携を「言語の異なる人々が通訳を介して会話する様子」に例えたり、技術的な制約を「特定の地形ではこの乗り物しか使えない」という物理的な制約に例えたりするなどです。聴き手の共通認識となりやすい日常的な事物やよく知られた概念を用いるのが効果的です。
- 具体的なエピソード: 過去のプロジェクトにおける具体的な失敗談や成功談、あるいは個人的な経験に基づいたエピソードは、情報に血を通わせ、記憶に残りやすくします。「あの時、〇〇さんが経験した△△という問題は、まさにこの前提が共有されていなかったからです」「この設計変更は、以前のプロジェクトで発生した〇〇というトラブルが教訓になっています」といった具体的な話は、抽象的な説明よりもはるかに強い説得力を持ちます。
具体的なテクニックと応用例
- 「もし〜だったら」シナリオ: 「もし、このパラメータが〇〇の範囲外になったらどうなるでしょう？ 実は過去の経験から、その場合システムは不安定になり、回復に時間を要することが分かっています。」のように、前提が満たされない場合のリスクをストーリーとして語ることで、その前提の重要性を際立たせます。
- 技術の「誕生秘話」: ある技術的判断や設計思想がなぜ採用されたのかを、開発当時の背景、試行錯誤、克服すべき課題といった物語として語ります。「当時、我々はこの性能目標を達成するために様々な方法を試しました。〇〇というアプローチも検討しましたが、△△という理由で見送り、最終的にこの手法を選んだのです。その背景には、将来的に☆☆に拡張する可能性を考慮していたという理由もあります。」といった経緯は、その技術の本質的な理解を深めます。
- 失敗事例を教訓として語る: 過去の失敗は、前提のずれがもたらすリスクを最も具体的に示す事例です。「以前のバージョンで、特定の条件下でデッドロックが発生しました。原因を調べたところ、二つのモジュールの担当者が、それぞれ異なるリソース解放のタイミングを前提として設計していたことが分かりました。この経験から、リソース管理においては〇〇という共通のルールを設けることにしました。」のように、失敗から学んだ教訓をストーリーとして共有することで、同様の誤りを防ぎます。
- 図やイラストとの組み合わせ: 複雑なシステムの構成や処理フローを説明する際に、単なる図だけでなく、データや信号がどのように流れていくかを追う「旅」のようなストーリー形式で解説します。図中の要素が「登場人物」となり、その間のやり取りが「出来事」となります。
これらのテクニックを活用することで、単に「〇〇という前提があります」と伝えるだけでなく、「なぜ、その前提が重要なのか」「どのような背景からその知識が生まれたのか」という深い理解を促し、チームや関係者間の共通認識を強固にすることができます。
まとめ：見えない前提を物語の力で共有する
専門家間のコミュニケーションにおける「分かりきっているはず」という思い込みは、時に見えない前提知識や暗黙知のギャップを生み出し、プロジェクトの遅延や手戻り、そして誤解の原因となります。特に複雑な技術領域では、この前提の共有不足が思わぬ問題を引き起こすことがあります。
このような課題に対し、ストーリー形式で情報を伝えることは、単なる事実の羅列では伝えきれない背景や文脈、そしてその知識の重要性を効果的に共有するための強力な手法です。過去の経験に基づいた暗黙知や、特定の設計思想の根拠といった抽象的な情報を、具体的なエピソードや比喩、そして明確な物語構造に乗せて語ることで、受け手はより深く理解し、記憶に留め、そして「自分ごと」として捉えることができます。
本記事で紹介したフレームワークやテクニック（共有すべき前提の特定、聴き手の理解、物語構造の設計、比喩やエピソードの活用）は、皆さんが日々の業務で直面する専門知識伝達の場面において、すぐにでも応用可能なものです。ぜひ、次回の技術会議やプロジェクトミーティング、あるいは報告書の作成において、「この前提は本当に共有されているだろうか？」「この暗黙知をどうすれば分かりやすく伝えられるだろう？」と考えてみてください。そして、それを物語の形式に落とし込んでみることに挑戦していただければ幸いです。
ストーリーの力を借りることで、専門家間のコミュニケーションはさらに円滑になり、共通理解に基づいた、より強固なチームワークを築くことができるはずです。