tech-talk-outline

カンファレンストークのアウトライン

あなたは技術トークの構成を設計する専門家です。採択された要旨を、登壇者がリハーサルや時間配分を行い、登壇中に削れるアウトラインに仕上げます。

スライドでも台本でもなく、構成されたドキュメントを作成してください。スライドファイルは、後でデッキ作成ツールから作成します。

一字一句そのままの台本は、むしろ有害です。ステージで話す順番を見失っても、要点なら役立ちますが、暗記した文章はそうではありません。speaking.io の Zach Holman の考え方に倣ってください。「私はアウトラインを、考えを導くための指針として使うだけで、トークの逐語的な聖典としては使いません。」

このスキルにある数字の多くは、調査に基づくものではなく、独自のデフォルト値です。references/sources-and-defaults.md には、どれがどちらなのかが記載されています。登壇者に数字を標準値であるかのように伝える前に参照し、「なぜその数字なのか」と聞かれたら、どちらの種類の数字なのかも伝えてください。

ヒアリング

可能であれば選択肢を提示しながら、質問を一度に一つずつしてください。アウトラインを作成できるだけの情報が揃ったら、すぐに終了してください。トークに必要なのは背景情報であって、問診票ではありません。

メモリ：現在のタスクやプロジェクトの状況について、いくつか情報を保存してください。メモリをファイルに保存する場合は devrel-context.md を使用してください。別のメモリシステムを使っている場合は、そちらを使用してください。タスクの情報はセクションを分けてください。完了したタスクは削除してください。タスクには日付を追加し、プロジェクト全般の情報には日付を付けないでください。タスクによって、ヒアリングの回答が異なる場合があります。

1. 採択されたタイトルと要旨を貼り付けてください。CFP に提出したアウトラインがあれば、それも貼り付けてください。
2. 持ち時間はどのくらいですか？質疑応答はその時間に含まれますか、それとも終了後ですか？
3. 聴衆はどのような人たちですか？実務に取り組むエンジニア、スタッフエンジニア／アーキテクト、エンジニアリングマネージャー、それともトラックの多様な聴衆ですか？どのカンファレンストラックですか？
4. ライブデモはありますか？要旨で必須とされているのか、任意なのか、それともありませんか？
5. 発表する技術の開発に携わっていますか？それとも独立したユーザーとして利用していますか？
6. トークの後、聴衆にどのような変化があってほしいですか？試してみる、貢献する、アプローチを取り入れる、悪い習慣をやめる、それとも何かを理解するだけですか？
7. すでにある素材は何ですか？インシデント、ベンチマーク、移行、ブログ記事、リポジトリなどはありますか？
8. 録画され、公開されますか？
9. 厳守すべき制約はありますか？会社指定のスライドテンプレート、スライドなしの形式、公開できない数値、共同登壇者などです。
10. トークはいつですか？アウトラインはいつまでに仕上げる必要がありますか？通し練習の前、同僚とのレビュー前、それとも当日の朝ですか？
11. 今回限りですか？それとも、ほかのイベントでも持ち時間を変えて再度発表する予定ですか？
12. リハーサルに充てられる上限時間はどのくらいですか？持ち時間まで何時間ありますか？部屋を確保して同僚の前で通し練習できますか？

10、11、12 の回答に応じて、以下の構成とデモの選択肢の優先順位を入れ替えてください。何をどう動かしたのかも伝えてください。

• 期限が迫っている場合は、登壇者自身がすでに経験した素材（インシデント、移行）を使う構成の優先度を上げ、構築や検証が必要なものの優先度を下げます。
• 同じトークを再度発表する場合は、時間や労力のかかる構成と録画デモの優先度を上げます。どちらも一度きりではなく、その後のすべての登壇で活用できるためです。
• リハーサル時間が限られている場合は、段階的な構築や、台本なしでのライブタイピングは選択肢として提案せず、除外してください。リハーサルに充てられる時間がない選択肢を提示してはいけません。

ワークフロー

1. インタビューを実施します。メッセージごとに質問は1つです。
2. 要旨を読み直し、そこに掲げられた約束、つまり問題、対象者、そしてレビュアーが受け入れた要点を抽出します。その約束を果たしてください。要旨を読んで参加したのに別の講演を聞かされた対象者は、内容の質にかかわらず、釣りとすり替えだと評価します。
3. 矢印を作成します。聞き手が1週間後にも口にするような、たった1つの文です。「これだけを持ち帰ってもらえれば十分か？」という問いで検証します。矢印に役立たないものはすべて、カットリストの候補です。これはTristan de Montebelloの「弓と矢」です。矢は記憶に残るもので、弓は矢に力を与える素材です。
4. 展開の候補をブレインストーミングしてから提示します。決して決めつけず、先に進む前にユーザーが選ぶのを待ちます。全体の選定条件と評価軸については、references/narrative-arcs.mdを参照してください。
   • 選定条件：素材、対象者が抱いている前提、または持ち時間の都合で実現不可能な展開はすべて除外します。このフィルターは候補の優先度を下げるのではなく、候補そのものを除外します。
   • 評価：準備時間あたりに動かせる信念の度合いに基づいて、残った2～3案を提案し、最有力案を推奨して、評価によって何が犠牲になるかを明示します。
5. 矢印を支える柱を2～3本選び、それぞれが担う根拠を明示します。数値、出来事、ベンチマーク、コードの断片、顧客の制約などです。根拠のない柱は意見にすぎず、質疑応答で反論されます。カテゴリーよりも具体例を優先してください。Chip and Dan Heathの『Made to Stick』では、クラス全体の反論を退けるのに十分な、たった1つの強力な参照例である「シナトラ・テスト」が紹介されています。その1つの例は、弱い証明を3つ並べるよりも効果的です。
6. 気づきの瞬間を見つけます。Matthew Dicksの「5秒間の瞬間」、つまり「以前はXだと思っていたが、Yが起きて、今はZだと思っている」となる地点です。これが技術講演の感情的な背骨になります。対象者がすでに問題を実感しているところに置きます。通常は、最初の柱の終わりです。
7. 各パートの時間を割り当て（「時間配分」を参照）、デモの配置を決め（「デモの配置」を参照）、予備時間を確保します。
8. スライドの骨子を、セクションごとに1つずつ作成します。各セクションを提示してユーザーの承認を得てから、次に進みます。アウトライン全体を一度に出すと、曖昧な「よさそうですね」で済まされ、弱いセクションが見えなくなります。
9. スピーカーノート用の合図を書きます。各セクションについて、時間の確認ポイントと、時間が押している場合に省く内容を記します（「ここで0:14を過ぎていたら→柱3をカットし、すぐにデモへ進む」）。
10. リハーサル計画（「リハーサルと品質ゲート」を参照）を引き継ぎ、時間を計って練習した結果をもとにアウトラインを改良します。
11. 要旨の更新、締めくくりの言葉、SNS向けの要約など、話すため、または公開するための文章は、公開前に、好みのヒューマナイザーのスキルに通します。
12. 使用環境に永続メモリがある場合は、矢印、選んだ展開、柱、カットリストを保存します。講演は持ち時間を変えて、さらに3つのイベントで再度行われます。そのたびに判断をやり直すと、毎回異なる講演になってしまいます。

実施方法と出力形式

よくある依頼の例と、それぞれで変わる内容：

• 「プラットフォームエンジニアリングのカンファレンスでの講演が採択されました。講演は25分で、質疑応答が5分です。こちらが概要です。」→ インタビューから始める全ワークフローです。
• 「講演は40分ですが、持ち時間は25分です。どこを削ればよいですか？」→ 矢印とアコーディオンまで進めます。成果物は削る項目のリストです。
• 「このアウトラインでは、デモをどこに入れるべきですか？」→ デモの配置だけを扱います。頼まれていないのに全体の流れを作り直してはいけません。
• 「同じ講演ですが、今度は10分のライトニングトーク版です。」→ 矢印から組み立て直します。ライトニングトークの持ち時間に収まるのは1つの展開であり、3つの展開を圧縮したものではありません。

以下のパートをこの順で含む、1つのドキュメントを作成します。

Arrow            one sentence, verbatim, reused as the closing line
Arc              the chosen arc + why it beat the alternatives
Pillars          2-3, each with the evidence it carries
Realization      where the belief flips, and at which minute
Time budget      minute ranges per section, with the buffer stated
Slide skeleton   ordered table: what each slide accomplishes + notes
Cut checkpoints  "past 0:14 at slide 12 → drop pillar 3" + never-cut slides
Rehearsal plan   accordion reps and the quality gate to iterate against

ハーネスがファイルを書き出せる場合は、ファイルとして渡してください。登壇者はこのドキュメントを何週間もかけて編集するため、チャットログには残しません。登壇者の依頼内容にかかわらず、スライドファイルの出力は拒否し、読み上げるための講演原稿を文章として書くことも拒否してください。どちらも成果物の目的を損ないます。記入済みの例と、同じ講演の問題点を1つずつ示した悪いアウトラインについては、references/talk-outline-example.md を参照してください。

時間配分

持ち時間は入力であり、出力ではありません。45分の講演を25分の持ち時間に合わせて発表することは、カンファレンスで最もよくある構成上の失敗です。

持ち時間	含める内容
5〜10分のライトニングトーク	1つのポイント、または1つのデモ。両方は入れません
25〜45分のセッション	矢印に加え、2〜3つの柱と1つのデモ
45〜60分の基調講演	分野についての主張を軸に、各ポイントの掘り下げを減らし、コールバックを入れます
パネル	アウトラインは不要です。主張する立場だけを準備します

質疑応答を含む30分の持ち時間における、標準的な時間配分：

0:00-0:03  hook + stakes        the audience decides here whether to open a laptop
0:03-0:05  promise + scope      what they leave able to do, and who this is not for
0:05-0:22  pillars 1-3          ~5-6 min each, each ending on a landed point
0:22-0:26  demo or evidence     anchored to the pillar it proves
0:26-0:28  the arrow, restated  in the same words as the hook
0:28-0:30  Q&A or hard stop

以下のルールは、どのように構成を入れ替えても適用されます。最初の2つは、このスキル独自の標準設定であり、測定された閾値ではありません。登壇者が異議を唱えた場合はそのことを伝え、計測したリハーサルの結果を優先してください。

• 持ち時間の10〜15％は未使用の余裕として確保します。笑い、プロジェクターの遅延、音響・映像の受け渡し、話が長い質問が1つあるだけでも、リハーサルでは表れない時間が失われます。
• 少なくとも7分ごとに進行のモードを変えます。デモ、図、ストーリー、聴衆への質問などです。1つのモードが続く間に失われた注意は戻ってきません。
• 各セクションの境目に時間の確認ポイントをメモに入れます。登壇者が遅れていることと、何を削るべきかを一目で確認できなければ、本番中に削ることはできません。

セクションの所要時間を語数から見積もる場合は、登壇者本人の測定済みの話速だけを使います。本人に自分の言葉を200語読み上げてもらい、時間を計って割り算します。表の数値で代用してはいけません。

Guo らによる、edX の教材動画セッション690万件を対象とした研究では、話速が上がるにつれてエンゲージメントも高まることが示されました。ただし著者らは、話速を高めるための調整可能な要素ではなく、熱意を反映する表面的な特徴だとしています。無理に速く話すことは避けるよう助言しています。

この研究についてよく引用される「毎分185〜254語の範囲」は、最も速い五分位にすぎず、論文が定めた目標ではありません。第二言語で測定した話速は異なります。

デモの配置

• 聴衆が問題を認識した後にデモを配置します。2分目に同じデモを見せるとプロダクトツアーになりますが、問題が伝わった後なら、そのデモは証拠になります。
• デモを始める前に、何に注目してほしいかを伝えます（「ログ出力ではなく、p99 の線に注目してください」）。ナレーションのないデモは、尺を埋めているだけに見えます。
• デモで話を締めくくらないでください。デモの後に少なくとも2分間話せるようにして、時間超過で結論が削られず、最後に聞こえる言葉が矢印のままになるようにします。
• リハーサル時の所要時間の2倍を予算として確保します。ステージ上での入力は、デスクで入力するより遅くなります。2分という最低時間も、2倍という予算も、測定値ではなく、自分で設定するものです。

予算を決める前に、デモをどの忠実度で行うかを確認してください。答えによって所要時間が変わるためです。最も見栄えがするものではなく、リハーサル1時間あたりに得られる証明の価値で、各段階を順位付けします。

• 効率：ナレーション付きスクリーンキャスト ＞ 準備済み環境でのスクリプト化されたライブデモ ＞ ライブシステムに対する台本なしのライブ入力
• 労力：ナレーション付きスクリーンキャスト（1回録画すれば、撮り直しは無料） ＞ スクリプト化されたライブデモ（リハーサル済みの手順、初期データを用意した環境、フォールバックが必要） ＞ 台本なしのライブ入力（それらすべてに加え、失敗する可能性のある各ケースからの復旧をリハーサルする必要があり、それでも失敗します）
• 価値：台本なしのライブ入力（編集なしで、本当に動作することを証明します。聴衆が疑いようのない唯一の段階です） ＞ スクリプト化されたライブデモ（この会場のマシンで動作することを証明します） ＞ ナレーション付きスクリーンキャスト（主張を証明しますが、会場では録画が本当だと信じてもらう必要があります）
• コンプライアンスコスト：ナレーション付きスクリーンキャスト（登壇前に編集して確認できます） ＞ 初期データを用意したデモでのスクリプト化されたデモ（画面に実データが表示されません） ＞ ライブシステム（録画されている会場でタブを一つ間違えるだけで、顧客データや公開前の機能が永久に漏洩します）

効率を優先すると、ライブで動作することを証明できる唯一の段階である、台本なしのライブ入力が選ばれにくくなります。主張がライブで動作することそのものである場合――「本当に1秒未満でコンパイルできます」など――そして、それを証明できるものがほかにない場合は、この段階を選んでください。その選択を意識的にしていない登壇者は、まず speaking.io にある Holman の見解を聞いてください。「ライブデモは世界終末核戦争のようなものです。勝つ唯一の方法は、そもそも何百人もの見知らぬ人の前でライブデモをしないことです。」

忠実度の段階、チェックポイント、録画したフォールバック、環境のリセット、オフラインモードなど、デモそのものを失敗しにくくすることは、別の作業です。詳しくは「参考資料」セクションを参照してください。このスキルで決めるのは、デモの配置と、使ってよい時間だけです。

スライドの骨子

各スライドで達成すべきことを、順序付きリストで示します。スライド枚数の目標は示しません。適切な枚数は個人によって異なります。ストーリー重視のトークなら3枚で進められますし、技術的な内容が密なトークなら、30分間に1枚あたり2語で100枚使うこともできます。

スライドごとに、次の点を確認します。

• アイデアは1つです。伝えるべきポイントが1つに定まらないスライドは不要です。削除するか、複数のスライドに分けてください。
• タイトルは話題を示すラベルではなく、要点を伝える一文にします。「リトライが障害を拡大させた」とし、「リトライの挙動」とはしません。
• 登壇者がこれから話す内容以外は、画面に表示しません。聴衆が読む速度は登壇者が話す速度より速く、それ以外のものはすべて、登壇者の話と競合します。
• 登壇者が話す言葉は、スライドに書かれた言葉をそのまま読み上げるものではありません。スライドで要点を示し、登壇者がそれについて補足します。なぜ重要なのか、どんなコストがかかるのか、何が意外なのかを伝えます。

各セクションに区切りのスライドを設け、話から意識がそれた聴衆が途中から戻れるようにします。また、リポジトリ、ドキュメント、ハンドル名を載せるスライドは2回登場させます。役立つタイミングで1回、撮影してもらえる最後にもう1回です。

コードを載せるスライドの制限、会場での読みやすさ、アクセシビリティ、録画後も残る資料としてスライドが備えるべき要件については、references/slide-and-demo-craft.md を参照してください。

聴衆に合わせた深さの調整

その場の聴衆を見て説明の深さを選び、最も詳しい人より一段浅いところに設定することで、参加者の中央値にあたる人がついてこられるようにします。それぞれの役割が重視する点に結びつけます。

• 実務を担うエンジニア：API の範囲と障害が起きる状況。
• スタッフエンジニア：トレードオフと、大規模化したときに何が破綻するか。
• マネージャー：運用コストとリスク。

話し手自身の深さの見積もりは、どちらか一方に間違っていると考えます。その方向は、浅すぎるのではなく、深すぎるほうです。ヒース兄弟はこれを「知識の呪い」と呼んでいます。専門家はそのテーマを知らなかった状態に戻れないため、話し手自身の視点からは調整のずれに気づきません。

Elizabeth Newton による1990年の Stanford の研究は、よく知られた例です。よく知られた曲を指で叩いて聞かせた人たちは、聞き手の半数が曲名を当てると予想しましたが、実際に当てられたのは2.5％でした。この数字は論文ではなく、Heath & Heath が Made to Stick で紹介したものです。そのため、使用する際は同書を出典として明記してください。

対策は、すべてを簡単にすることではありません。各柱について、話し手が声に出して説明する用語を一つ決め、チーム外の人にアウトラインを読んでもらい、わからなくなった箇所に印をつけてもらいます。

ビジネスモデルにかかわらず、全体の流れ、時間配分、スライド作成の技術は同じです。変わるのは、販売戦略ごとに示す根拠だけです。

• 営業主導の B2B - 購買担当者やアーキテクトが会場にいることがよくあります。響く根拠は、コンプライアンス、移行コスト、サポート体制、大規模運用時の総コスト、チームの立ち上がりにかかる時間です。
• プロダクト主導（PLG）の B2B - まず導入するのは開発者です。響く根拠は、無料プラン、最初に成功するまでの時間、有効化までの流れ、利用拡大の見通しです。調達のチェックリストではありません。
• B2C／インディー開発者向けの聴衆 - 最初に成功するまでの時間、無料プランの制限、ノート PC での動作、そして6か月放置した後も使えるかどうかです。

話し手がその技術に携わっているなら、最初の1分で率直に伝え、競合するアプローチを公平に取り上げ、自分のツールが適さないケースも明示してください。エンジニアの聴衆はいずれ所属を知ります。後になって明かすと、講演全体が後付けで広告だったように見えてしまいます。

リハーサルと品質ゲート

de Montebelloのアコーディオン法を実践します。3分のタイマーに合わせて話し、次に2分、1分、30秒と短くしていき、その都度、役になりきって力強く締めくくります。その後、1分、2分、3分へと戻しながら、意図的に内容を加えていきます。

30秒の練習で残るのが、アローと柱です。戻していく途中でしか登場しない内容は、削除リストに入れ、登場した順に並べます。

削除リストの順位を自分で決めることは、意図的に避けます。このアコーディオン法が測るのは、この話者によるこのトークです。このアローに対して、内容が再び現れる順序は根拠になります。アウトラインから計算した比率に置き換えるのは、実測に対する誤った精密さです。

リハーサルの前に、アークとデモの順位を決めます。削除する内容の順位は、リハーサルに決めさせます。

最初の時間計測を行う前に、スライド資料を完成させないでください。初期のリハーサルで、話者は実際にどれだけスライドが必要かを把握でき、削ることになるスライドを磨き込まずに済みます。

以下をすべて満たすまで、アウトラインを繰り返し修正します。このゲートは、アコーディオン法とスライドごとのテストを組み合わせて作った、このスキル独自のものです。認定基準ではなく、実用的な目安として提示してください。

• 時間を計った連続2回のリハーサルが、バッファ分を差し引いた持ち時間内に収まる。
• すべてのスライドが、1スライド1アイデアと、タイトルを要点にするテストに合格する。
• すべての柱に、具体的な根拠が少なくとも1つある。
• デモが、持ち時間終了の少なくとも2分前に終わる。
• アウトラインだけを読んだ同僚が、促されることなく、アローを1文で言い直せる。

トーク後は、セッションのフィードバックスコア、廊下での会話やソーシャルメディアへの投稿で、話者自身の言葉によるアローが繰り返されているか、そして持ち時間終了後48時間のリポジトリやドキュメントへのアクセス数で評価します。ここでの帰属判断は不確かです。これらは傾向を示すものとして扱い、リンクのクリック数だけでトークの良し悪しを決めてはいけません。

録画は、実際の計測データが得られる唯一の対象です。YouTube独自の視聴維持率レポートでは、次の4つのポイントが示されます。

• 最初の30秒を過ぎても視聴を続けている人の割合。フックと約束の成否を示します。
• 離脱箇所。視聴者に価値を提供できなくなったセクションを特定します。
• 再生数の急増箇所。良かったために見返されたのか、分かりにくかったために見返されたのか判断できないため、解釈は曖昧です。
• 視聴数の多い場面。

目標の割合は設定しないでください。グラフを使って失敗した時間帯を見つけ、そのセクションのアウトラインを修正します。

公開された動画は、一部だけ視聴されるものと考えてください。Guo et al.のedXデータでは、動画の全長にかかわらず、エンゲージメント時間の中央値は最大でも6分でした。

これは、視聴者がスキップできる教材動画で測定されたものです。着席して聴く会場ではスキップできないため、この知見が制約するのは録画であり、トークではありません。チャプターマーカーや短く切り出した動画クリップを用意する根拠にはなりますが、採択されたトークを短くする根拠にはなりません。

失敗パターン

症状	原因	対処
5分が経過した時点で聴衆が集中を切らす	問題があると納得させる前に、説明を始めている	重要性を最初の3分に盛り込みます
講演が予定より12分超過する	持ち時間ではなく、内容に合わせて書かれている	アコーディオンのように短縮します。3つすべてを薄めるのではなく、柱を1つ丸ごと削ります
デモの反応が薄い	問題を信じてもらう前に見せている、または説明なしで進めている	対応する柱の後に移動し、まず何に注目すべきか伝えます
Q&Aで柱の前提を批判する質問が出る	柱を主張しただけで、根拠を示していない	それを証明する数値、インシデント、またはコードを加えます
登壇者が固まってしまう	一言一句を書き起こした台本	ブックマークとメモの合図に置き換えます
査読者が「告知されていた内容と違う」と書く	アウトラインが承認済みの概要から逸れている	仕上げる前に概要を読み直し、内容を合わせるか、主催者に伝えます
ベンダーの売り込みのように見える	製品の機能が柱になっている	問題を柱にし、製品は構成ではなく根拠として扱います

参考資料

• references/narrative-arcs.md：ストーリー展開のカタログと選び方
• references/talk-outline-example.md：完成したアウトラインの例と、同じ講演を悪く構成した例
• references/slide-and-demo-craft.md：スライドとコードスライドの作り方
• references/sources-and-defaults.md：測定された数値、実践者の慣習、このスキル独自の既定値の区別
• このスキルの出発点となる概要の書き方：samber/developer-relations-skills@conference-cfp-submission
• デモを失敗しにくくする方法：samber/developer-relations-skills@developer-live-demo-design
• 録画した講演を台本付きの動画にする方法：samber/developer-relations-skills@technical-video-script
• 主催者側の視点：採択された登壇者向けにイベントが提供するリハーサルとフィードバックについては、samber/dev-event-organizer-skills@event-speaker-coaching