専門知の翻訳は、内容を薄めることではない

エンジニアが非エンジニアに説明するとき、「もっとわかりやすく」と言われることがあります。専門性を削るように感じるかもしれませんが、わかりやすくすることは内容を薄めることではなく、相手が判断できる形に情報を組み替えることです。

「この処理は非同期化しています」「冗長構成にしています」はどれも正確な説明です。けれども非エンジニアの聞き手が知りたいのは、その言葉の定義だけではありません。

  • ユーザー体験はどう変わるのか
  • 開発期間や費用にどう影響するのか
  • 障害時に何が守られるのか
  • どのリスクは残るのか
  • いま何を決めればよいのか

専門知の翻訳は専門用語を消す作業ではなく、専門家の頭の中にある関係、前提、制約、判断ポイントを、相手が使える順番に並べ替える作業です。

この記事は、技術そのものの正否ではなく技術をどう説明するかを扱います。セキュリティ、医療、金融、法務など専門的判断や規制対応が関わる内容は、各領域の専門家、社内ルール、ガイドラインに従ってください。

専門知の翻訳とは、正確さを捨てることではありません。正確な内容を、相手が判断に使える形へ整えることです。

エンジニアの説明が伝わりにくくなる理由

伝わりにくくなる理由は、話し手の能力不足だけではありません。多くの場合、話し手と聞き手が見ているものが違います。

エンジニアは仕組みを見ています。どの処理が走り、どのデータがどこを通り、どこがボトルネックになるか。一方、非エンジニアの聞き手は目的や影響を見ています。顧客に何と説明するか、予算を通せるか、納期に間に合うか、リスクを引き受けてよいか。この違いを埋めないまま説明すると、エンジニア側は「詳しく説明した」と感じ、聞き手側は「結局、何を決めればよいのか分からない」と感じます。

もう一つの理由は、専門家ほど前提を省略しやすいことです。「レイテンシ」「技術的負債」「リファクタリング」。自然な言葉でも、相手には似た言葉との違いが見えません。

プレーンランゲージの考え方では、相手が初回で理解し、必要な行動に使えることが重視されます。「幼稚にする」のではなく、聞き手の知識、目的、関心に合わせて情報の順番と言葉を設計するという意味です。

非エンジニアに伝える3つの軸

非エンジニアへの説明は、次の3つで整理すると伝わりやすくなります。

  1. 抽象化 — 技術の細部を隠すのではなく、相手の判断に必要な粒度へ整える
  2. 比喩 — 聞き手が知っている世界を足場に、似ている点と違う点をセットで伝える
  3. 目的 — 仕組みの説明で終わらせず、聞き手が何を判断すればよいかへ接続する
エンジニアが非エンジニアに専門知を伝える3つの軸として、抽象化、比喩、目的を示した図
図1｜専門知を非エンジニアに伝える3つの軸 — 抽象化・比喩・目的

抽象化 — 仕組みを、判断に必要な粒度へ整える

抽象化とは細部を雑に省くことではなく、相手がいま判断するために必要な粒度へ情報を整えることです。

システム障害の説明で、最初からログの詳細や例外名をすべて話すと、聞き手は重要度を判断できません。まず必要なのは、何が起きて、どの範囲に影響し、いま止まっているのか、原因は分かっているのか、誰が何を決めるべきかという全体像です。

悪い説明:

「キャッシュのTTLとDB更新タイミングがずれて、一部ユーザーで古い値が返っていました」

よい説明:

「一部の画面で、最新ではない情報が表示される状態が起きていました。原因は、表示を速くするために一時保存していたデータの更新タイミングです。現在は修正済みで、今後は更新時に一時保存データも同時に消す仕組みに変えます」

後者は正確さを捨てず、先に影響、原因の意味、対応を示しています。専門用語は必要になった段階で補えば足ります。抽象化で大切なのは、相手の問いを先に決めることです。

  • 経営者なら「投資判断・リスク・優先順位」
  • 営業なら「顧客へどう説明するか」
  • カスタマーサポートなら「ユーザーから何を聞き、何を返すか」
  • 法務なら「契約・責任範囲・記録」
  • 現場担当なら「自分の作業がどう変わるか」

「どこまで詳しく話すか」ではなく、「相手は何を判断したいのか」から逆算します。

抽象化は、情報量を減らす技術ではありません。相手が判断できる粒度へ、情報の解像度を合わせる技術です。

比喩 — 似ている点と違う点をセットで示す

技術説明では比喩が役立ちます。データベースを図書館に、APIを窓口に、キャッシュを一時置き場にたとえる。ただし比喩は正確な定義ではなく理解の入口なので、使い方を誤ると誤解を生みます。「APIは窓口のようなものです」は便利ですが、この比喩だけでは認証、エラー処理、利用制限の複雑さは伝わりません。

よい比喩は、次の形で使います。

「APIは窓口のようなものです。相手は決まった形式で依頼を出し、システムは決まった形式で返します。この比喩で伝えたいのは、直接中身を触るのではなく、決められた入口を通るという点です。ただし実際のAPIでは、本人確認、エラー時の返答、利用回数の制限も設計します」

この説明なら、比喩の対応点と限界が見えます。使う前には、聞き手がその比喩を知っているか、伝えたい中心の関係が対応しているか、どこから先は違うかを言えるかを確認します。認知科学の類推研究でも、表面的な類似より構造や関係の対応が理解に重要だと整理されています。

比喩は、専門知を別物に置き換える道具ではありません。似ている点と違う点を示し、概念へ戻るための足場です。

目的 — 技術の話を、相手の意思決定へつなぐ

エンジニアの説明で最も抜けやすいのが目的です。仕組みを正しく話しているのに伝わらないとき、聞き手は「それで何を決めればよいのか」を探しています。技術説明は、次の順番にすると整理しやすくなります。

  1. 目的
  2. 現状
  3. 仕組み
  4. 影響
  5. 判断・次の行動

例:

「今日決めたいのは、検索機能の改善を今月入れるか、次のリリースへ回すかです。現状は商品数が増えて検索に時間がかかっています。毎回全データを見に行く処理になっているためです。改善案では検索用の索引を事前に作ります。待ち時間は減りますが、開発に追加で2週間必要です。今月の売上施策と合わせて優先度を決めたいです」

技術の詳細より先に聞き手の判断が置かれているため、非エンジニアも議論に参加できます。逆に目的がない説明は、聞き手を受け身にします。「この処理はインデックスを貼れば速くなります」だけでは、どれくらい速くなるのか、なぜ今必要か、費用や副作用はあるか、他の施策より優先すべきかが分かりません。

目的を先に置くと専門性は弱くなるどころか、技術の話が相手の仕事とつながり、むしろ信頼されやすくなります。

制約とリスクの伝え方

「技術的に難しいです」「仕様上できません」「負債がたまっています」。これらはエンジニアにとって大切な警告ですが、そのままでは聞き手が動けません。何が問題で、どんな選択肢があり、どこまで許容できるのかが見えないからです。制約は禁止の言葉で終わらせず、判断可能な形にします。

悪い例:

「その仕様は無理です」

よい例:

「その仕様をそのまま入れると、ログインしていない人にも一部情報が見えるリスクがあります。目的が『問い合わせを減らすこと』なら、個人情報を出さない形でFAQを先に出す案で実現できます」

悪い例:

「このままだと技術的負債がやばいです」

よい例:

「今の実装は短期的には動きます。ただ、同じ箇所を毎回手で直す構造なので、機能追加のたびに確認範囲が広がっています。次の2回のリリースまでは対応できますが、その後は修正時間が増えます。今リファクタリングする案と、次の大型改修に合わせる案があります」

リスク説明で大切なのは、不安をあおることではなく、相手が選べる形にすることです。次の順で示します。

  • 何が起きる可能性があるのか
  • どの程度の影響か
  • いつまでなら許容できるのか
  • 選択肢は何か
  • 推奨案と、その理由は何か

制約は「できません」から「こうすれば目的に近づけます」へ変わります。

技術的な制約は、拒否の理由としてではなく、よりよい選択肢を設計するための判断材料として伝えます。

オンラインで技術説明をするときの工夫

オンライン会議では技術説明の難易度が上がります。相手の表情や、資料のどこを見ているかが分かりにくく、専門用語が続くと聞き手は途中で質問しにくくなります。だからこそ、最初に地図を渡します。

「今日は、まず目的、次に現在の課題、最後に対応案と判断ポイントの順で話します。技術詳細は必要なところだけ入れます」

次に、画面共有は一画面一論点にします。構成図、ログ、数値を同時に見せると、どこを見ればよいか迷います。まず結論を一文で置き、その根拠として図や数字を見せます。

理解確認も意図的に入れます。「ここまでで、目的と影響範囲は合っていますか」。「分かりましたか」ではうなずかれて終わります。確認したいのは理解度ではなく、相手が自分の仕事の言葉で説明し直せるかです。

沈黙が続くと説明側は不安になり、さらに話し続けがちです。しかし技術説明ほど、聞き手が考える時間が必要です。

技術説明の実務チェックリスト

説明前:

  • 聞き手は誰か、何を判断したい人か
  • 今日の説明で決めたいことを一文で言えるか
  • 技術詳細より先に、目的と影響を置けるか
  • 使う専門用語を3つ以内に絞り、業務の言葉で補足できるか

説明中:

  • 仕組みからではなく、目的から始めているか
  • 詳細を話す前に「ここまで必要ですか」と確認しているか
  • 制約を「無理です」で止めず、代替案に接続しているか
  • 数字や図を出すとき、見るべきポイントを先に示しているか

説明後:

  • 相手が次に何を判断するか確認したか
  • 決まったこと、保留したこと、追加確認することを分けたか
  • 技術的なリスクと業務上の影響をセットで記録したか
  • 次回はどの粒度で説明すればよいか、学びを残したか

技術説明は話すたびにうまくなるのではなく、振り返る観点を持つことで組織の型になります。「専門用語を減らしたか」だけでなく「相手が判断できたか」を見ます。質問が具体的になったか、次の行動が決まったか、誤解が早い段階で見つかったか。

まとめ

エンジニアが非エンジニアに伝える技術は、専門性を隠す力ではありません。専門知を、相手が理解し、質問し、判断できる形に変える力です。

説明が伝わりにくくなるのは、エンジニアが仕組みを、非エンジニアが目的・影響・リスクを見ているからです。この違いを埋めるのが、抽象化・比喩・目的の3つの軸です。制約やリスクも拒否の言葉で終わらせず、選択肢と推奨案に変えます。

専門知は、正しいだけでは届きません。相手の仕事の文脈に入り、判断に使える言葉になって初めて、組織の力になります。

エンジニアの説明力とは、詳しさを削る力ではありません。技術の核心を保ったまま、相手の目的へ橋をかける力です。

参考文献・出典

本記事で触れた考え方・研究は以下のとおりです。