専門外の人に技術を説明するには：伝わる6枚のプレゼン構成

技術的なプロジェクトを専門外の人に説明するときは、まず相手に関わる変化を示し、根拠やトレードオフが分かるだけの仕組みを説明します。難しい単語を短い言葉に置き換えても、話の筋が追いやすくならなければ十分ではありません。

相手は顧客、現場の手順、予算について、あなたより詳しいかもしれません。足りないのは、構成図を読むための専門的な背景です。判断に必要な不確実性を消さずに、その背景を丁寧に補いましょう。説明の材料がそろったら、Presentiで文章からスライドの構成を作ることもできます。

相手に答えてほしい問いから始める

参加者の役割と、求める行動を書き出します。サポート責任者は顧客へ動作の変更を説明する必要があり、プロダクトマネージャーは試行の範囲を選び、財務担当者は必要な費用や人員を理解したいかもしれません。コードレビューとは必要な詳しさが違います。

この例では、開発チームが新しいレポート生成方式を試す許可を求めます。相手は製品企画、運用、サポートの担当者です。ユーザーに何が見え、どんな問題が起こり得るか、本格展開の前に何を確かめる必要があるかを理解してもらいます。

MIT EECS Communication Labのスライド作成ガイド（英語）は、相手の知識に合わせた説明、なじみのない図の導入、各スライドの明確なメッセージを勧めています。構成図全体を見せる前に、判断に必要なのは仕組みのどの部分かを選んでください。

書き換え例：キューを使うレポート生成を説明する

以下は伝え方を考えるために作成した例です。システム案と練習用データはスライドの書き換えを説明するものであり、実在する顧客の成果や製品の実測結果ではありません。

最初のタイトルは「永続キューと冪等なワーカーによる非同期オーケストレーション」です。図にはAPIゲートウェイ、キュー、ワーカープロセス、データベース、再試行の矢印、監視の仕組みが並びます。エンジニアには見慣れた構成でも、ほかの担当者には、レポートを依頼する人に何が変わるかが分かりません。

タイトルを「レポートの作成中も、ユーザーはページを離れられる」に変え、その下に提案する流れを示します。

1. ユーザーがレポートを依頼する。
2. アプリが依頼の受け付けを知らせ、処理待ちの仕事として記録する。
3. バックグラウンドの処理がレポートを作成する。
4. アプリが完成した結果、または明確な失敗状態を表示する。

図のそばに、「依頼の受け付け」と「レポートの完成」は別と書き添えます。すぐに受け付けを知らせれば待ち方は変わるかもしれませんが、計算そのものが速く終わる証拠にはなりません。

Microsoftのキューによる負荷平準化の解説（英語）は、受け付けと処理を分ける仕組みを説明しています。また、処理できる量を上回る仕事が届き続けると、待ち行列が増えるとも述べています。発表では「処理待ちが増えたとき、ユーザーには何が見えるか」という問いに置き換えられます。

判断に必要な技術用語は残して説明する

説明すべき用語もあれば、技術付録に残せるものもあります。必要な用語は文脈の中で一度定義し、その後は同じ言い方を使います。

この表は、提案システムがすでに正しく対応できている証拠ではありません。開発チームが説明し、試験すべき事項を示しています。実際の障害処理、実装の選択、試験結果は補足資料に置きます。

「キューは対応を待つ整理券の列のようなもの」と例えると入り口になります。ただし、例えが通用しない範囲も説明しましょう。実際のシステムでは複数のワーカーや再試行が順番に影響するため、単純な先着順の絵が、設計で保証していない動作を連想させることがあります。

根拠を分かりやすくしても、強く言い換えない

練習用に、100件のレポート依頼のうち90件が60秒以内に完了し、10件はそれ以上かかったとします。提案の目標は「95%が60秒以内」です。これは説明用の条件であり、この記事のためにシステムを測定した結果ではありません。

「新しい構成でレポートが高速になる」では言い過ぎです。「練習用の標本は、提案する完了時間の目標に届かない」なら根拠に沿っています。図のそばに分母としきい値を示し、どの追加情報があれば判断が変わるかを説明します。

実際の提案では、計測の開始と終了、負荷、依頼件数、失敗を含めたかを示します。観測結果、予測、目標値は分けてください。現行と提案を比べるなら条件をそろえるか、違いを説明します。根拠を行動へつなげる方法は、データストーリーテリングのガイド（英語）でも扱っています。

技術的な問いを残した6枚の説明

レポート生成の例を、次の流れにできます。仕事で使う前に、説明用の条件を確認済みのプロジェクト情報へ置き換えてください。

1枚目：現在のユーザー体験を説明する

タイトル：「レポート作成中、ユーザーはページで待つ必要がある」。

口頭の説明：「現在はレポートが完成するまでこの画面で待ちます。依頼を受け付けた後、結果を改めて確認できる流れを検討しています」。現状の手順を見せ、測っていない失敗率を加えないようにします。

2枚目：変わる仕組みを示す

タイトル：「提案する流れでは、レポートの依頼と受け取りを分ける」。

口頭の説明：「アプリが依頼を記録し、バックグラウンドの処理がレポートを作り、ユーザーは状態を確認します。受け付けと完成は別の出来事です」。構成図全体ではなく、四段階の図を使います。

3枚目：分かっていることを説明する

練習用データのタイトル：「60秒以内の完了は90%で、目標案の95%に届かない」。

口頭の説明：「この説明用の標本は100件で、10件はしきい値を超えています。改善を主張する前に、代表性のある計測と現行システムの基準値が必要です」。実際の発表では、実データとその限界に置き換えます。

4枚目：新しく必要になる対応を示す

タイトル：「新しい流れには、分かりやすい状態表示と回復手順が必要」。

口頭の説明：「ユーザーには待機中、完了、失敗を知らせます。サポートは、単に遅い処理と、人の対応が必要な処理を見分ける必要があります。再試行で意図しない重複が生じない設計も必要です」。付録の具体的な設計・試験の問いへ案内します。

5枚目：範囲を限った次の一歩を提案する

タイトル：「限定した試行で、待ち方と回復手順を確認する」。

口頭の説明：「参加者、開始条件、測定項目、中止条件、責任者を開始前に合意します。受け付けだけでなく完了と失敗も測ります」。責任者同士で合意するまでは、値を勝手に埋めません。

6枚目：根拠を用意できている判断を求める

タイトル：「試行を進めるかと、結果確認の責任者を決める」。

口頭の説明：「範囲を限定した試行を提案します。本格展開の前に、合意した根拠を確認します」。未解決の設計が試行を妨げるなら、まずそれを解消するための、より小さな行動を求めます。

次の質問に答えられる付録を残す

本編を簡単にしても、詳細を消すのではなく参照できるようにします。構成と依存関係、計測の定義、試験条件、失敗と再試行の動作、比較した代替案、展開や切り戻しの責任者に、固定の見出しを付けます。本編から該当ページへ案内してください。

大切な区別を問う質問も準備します。「レポートは即座にできるのか」と聞かれたら、依頼の受け付け方は変わるが、完成は処理と負荷に依存すると分けて答えます。「待ちが増えたらどうなるか」には状態表示と回復計画を示すか、まだ設計が必要な点を説明します。

対象の職種の同僚に一度説明し、ユーザーに何が変わり、何を決めてほしいと理解したかを聞きます。「速いシステム」という印象しか残らないなら、受け付けと完成の区別をもっと明確にする必要があります。

スライドを作る前に説明の材料をそろえる

技術説明の整理シートと6枚の構成例を、コピーできるテキスト資料にまとめています。説明用データと、保持すべき区別も含みます。

相手、ユーザーへの影響、短い仕組み、必要な定義、確認済みの根拠、不確実性、求める判断を集めます。その文章からPresentiで構成やスライドの下書きを作れます。説明を短くするときも技術責任者に関わってもらいましょう。滑らかな文章でも、重要な条件を落としていることがあります。

［プロジェクト］を［相手と役割］に説明してください。
理解・判断してほしいこと：［課題］。
提供した仕組みと根拠だけを使ってください。
影響、仕組み、根拠、トレードオフ、次の一歩、判断の6枚に構成してください。
判断に必要な未知の用語は説明してください。
単位、分母、不確実性、限界を保ってください。
不足する根拠を作らず、確認事項として示してください。
詳しい実装情報は、参照先が分かる付録に置いてください。

説明が届いたかは、会話が具体的になったかで確かめられます。未解決の条件は何か、受け入れられるトレードオフはどれか、次にどの根拠が必要か。こうした問いが、開発チームとほかの担当者の次の行動につながります。