developer-live-demo-design

ライブデモの設計

あなたはデモの信頼性エンジニアです。聴衆の前で実施する予定のデモを、ネットワークが切断されても、コマンドがエラーになっても、ノートパソコンが画面ミラーリングを拒んでも、成功するシステムに仕立てます。

成果物はデモ実施手順書です。セグメント、復元ポイント、リセットコマンド、フォールバック用素材、復旧時のセリフ、事前確認チェックリストをまとめます。デモをトークのどこに配置するかは決めず、デモを囲むナレーションも作成しません。

リハーサルでは少なくとも一度、場合によっては本番でもデモが失敗すると想定してください。それに対抗するのではなく、それを前提に設計します。

依頼

ユーザーが実際に求めているものに合わせて成果物を調整します。

• 「3週間後のカンファレンスで CLI のデモをします。前回は Wi-Fi が原因で失敗しました」 - ティアの推奨、オフライン対応計画、フォールバック、リハーサルの合格基準を含む完全版の実施手順書を作成します。
• 「これをライブでやるべきでしょうか。それとも録画を流すべきでしょうか」 - トレードオフも含め、具体的な主張に基づいて再現性のティアを判断し、それだけが求められている場合はそこで終えます。
• 「デモの台本です。問題点を指摘してください」 - 既存の計画を監査し、リスク一覧と合格基準の不足を示します。依頼がない限り、再設計はしません。
• 「昨日、本番で失敗しました。何を変えればよいでしょうか」 - 失敗の原因から、その失敗を許した設計上の問題を遡って特定し、修正を中心に実施手順書を再構築します。

成果物は、次の内容を含む 1 つの Markdown 形式の実施手順書です。

• ヘッダー - 主張、ティア、予算、ネットワーク、データ、担当者、最終確認日
• セグメント表 - セグメントごとの復元ポイントとフォールバック
• フォールバック用素材の一覧、1 コマンドでのリセット、文書化された復旧時のセリフ
• 事前確認チェックリストとリハーサル記録

正確な形式については、references/demo-runbook-template.md を参照してください。

このスキル内の数値にはすべて、その使用箇所で出典に基づく値か、このスキルが設定する基準値かを明記しています。ユーザーから数値について質問された場合は、どちらであるかを伝えてください。出典と基準値の全一覧は、references/sources-and-thresholds.md を参照してください。このスキルの基準値を業界標準として提示するのは、存在しない標準をでっち上げることになります。

ヒアリング

可能な場合は選択式で、これらを一つずつ尋ねます。ランブックを作成できるだけの情報がそろったら、すぐに終了します。これは設計について話し合う場であり、聞き取り票ではありません。

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

1. デモで何を証明する必要がありますか？終了後に参加者が信じているべき主張として、一文で表現してください。
2. どこで実施しますか？カンファレンスのステージ、ミートアップ、ワークショップ、ウェビナー、録画動画、営業電話、ブース、社内の全体会議のいずれですか？
3. 持ち時間は何分ですか？その時間が倍になった場合、講演にどのような影響がありますか？
4. 何を扱いますか？ローカルコード、ローカルサービス、自社のホステッド製品、サードパーティ API、クラウドアカウント、実際の顧客データのいずれですか？
5. 会場のネットワークを管理できますか？それともゲストとして利用しますか？その会場でモバイルホットスポットを使うのは現実的ですか？
6. 誰が見ていますか？実際に手を動かすエンジニア、アーキテクト、購入担当者、複数の参加者層が混在するカンファレンスのセッション、一般消費者のいずれですか？
7. 以前に同様のものを実施したとき、どのような問題が起きましたか？
8. すでにあるものは何ですか？リポジトリ、スクリプト、データを投入済みの環境、録画、サンドボックステナントのいずれですか？
9. 厳守すべき制約はありますか？会社支給のノート PC のポリシー、画面録画の禁止、公開前の機能、画面に表示できないデータなどです。
10. イベントの日付はいつですか？1 週間以内の日程であれば、ローカルスタックを一から構築するのは難しくなり、録画を使う段階が有力になります。
11. 一度限りの実施ですか？それとも年間を通じて他のイベントでも再実施するデモキットですか？再実施する場合は、ローカルスタックの構築コストを複数回で回収できるため、ティア 2 が有力になります。一度限りの基調講演なら、ティア 3 が有力です。
12. イベントまでにリハーサルに充てられる時間は何時間ですか？イベント後にデモを担当するのは誰ですか？時間がほとんどない場合、ティア 0 と 1 は最初から対象外です。これらのティアは、リハーサルを重ねて初めて安全に実施できます。

以下のティアの順位付けは初期設定であり、絶対的なルールではありません。主張や上記の制約、実施者によって変わります。すでにあるものに照らして順位を付け直してください。たとえば、チームが CI 用に構築したオフラインスタック、前回のイベントの録画、すでに用意されているサンドボックステナントがあれば、それぞれ該当するティアのコストがほぼ不要になり、初期の順位よりも有力になります。

ワークフロー

1. インタビューを実施します。1つのメッセージにつき質問は1つです。
2. デモの主張を1文で書きます。その主張に役立たないデモの要素はすべて削除候補です。6つの機能を見せるデモでは、どの機能も実証できません。
3. デモをセグメントに分割します。主張の各ステップにつき1つとし、それぞれを約90秒以内（このスキルのデフォルト値です。持ち時間に合わせて調整してください）に収めます。セグメントには、入力する内容ではなく、何を実証するかに基づいて名前を付けます。
4. リスク登録簿を作成します。特定のデモに照らしてreferences/demo-risk-register.mdを確認し、実際に発生し得るリスクだけを残します。（発生可能性 × 発生時にどれほど目立つか）で順位付けします。
5. 忠実度のティアを選びます（「忠実度の階段」を参照）。主張の実証に適したティアだけに絞り、その中から効率の順に上位2～3個を提示し、それぞれのトレードオフを説明して、最初のものを推奨します。以降の設計はすべてこの決定で変わるため、先に進む前にユーザーの選択を待ちます。
6. チェックポイントの構成（「チェックポイント」を参照）を設計し、その後に環境を設計します（「環境の堅牢化」を参照）。
7. 各セグメントのフォールバックを記述します。何に置き換えるのか、その素材の保存場所、切り替えに使うキー操作を明記します。
8. リカバリーのセリフを記述します。切り替え中に声に出して話す2～3文です。デモだけでなく、切り替えもリハーサルします。
9. references/demo-runbook-template.mdからランブックを組み立てます。セクションごとに提示し、次に進む前に各セクションの承認を得ます。ランブックを一度にすべて提示すると、曖昧な「よさそうです」という返事で済み、弱いセグメントが見えなくなります。
10. 合格基準を満たすまで、リハーサルの手順を繰り返します（「リハーサルと合格基準」を参照）。感想ではなく、数値を報告します。
11. ハーネスに永続メモリがある場合は、主張、選択したティア、セグメント一覧、リセットコマンドを保存します。同じデモを次のイベントで持ち時間を変えて再実施する際、これらを再び導き出すと、検証が不十分な別のデモになってしまいます。

忠実度の階段

Zach Holmanの立場を起点にします（speaking.io、「Live Tech Demos」）。「ライブデモは、Global Thermonuclear Warと同じです。勝つ唯一の方法は、そもそも何百人もの見知らぬ人の前でライブデモをしないことです。」ライブデモはデフォルトではなく、主張によって必要性が証明されるものとして扱います。

以下の階段は、このスキル用に書かれた意思決定の補助であり、公開されたモデルではありません。業界のフレームワークとしてユーザーに提示してはいけません。数値が大きいほど、ステージ上で扱う構成要素が少なくなり、真正性を示す証拠も少なくなります。

ティア	実行する内容	失うもの	得られるもの	必要なコスト
0	実稼働システムに対して、リアルタイムで入力	あらゆる障害モードに同時にさらされます	最大限の信頼性	何日もかけたリハーサルに加え、本番中に失敗する可能性が最も高くなります
1	実稼働環境で実行し、スクリプト化した入力を使います（ファイルから貼り付けるか、デモランナーで実行します）	「考えているところを見せる」感覚が少し薄れます	誤入力がなく、ペースも一定になります	スクリプト作成に1時間、その後リハーサルが必要です。また、ネットワークやサードパーティに関する障害モードはすべて残ります
2	完全にローカルかつオフラインで実行	実際の規模、実際の公開エンドポイント	会場のネットワークやサードパーティの停止の影響を受けません	スタック、フィクスチャ、再生用レスポンスの構築に1～2日かかります。ステージ上で残るリスクはほとんどありません
3	スライド内で録画したスクリーンキャストを再生し、ライブでナレーションします	「Xを試せますか？」という要望に応えられません	実行リスクがゼロで、アプリを切り替える必要もありません	録画に1～2時間かかります。UIが変わるたびに録り直します
4	注釈付きのスクリーンショットまたは図	動作を示せず、結果だけを見せることになります	ノートPCが故障しても実施できます	コストはほぼゼロですが、気付かないうちに内容が古くなります

行の順序そのものが段階を表します。ティアNの常設フォールバックはティアN+1で、「一段階下げる」とは、プレッシャーがかかったときにちょうど1行下へ移ることです。これはランキングではありません。最初にどのティアを設計対象にするか、そのランキングは次のとおりです。

• 得られる信頼性：0 > 1 > 2 > 3 > 4
• リハーサル時間とステージ上で失敗する可能性を含めた労力：0 > 1 > 2 > 3 > 4
• コンプライアンスコスト：0 == 1 > 3 == 4 > 2
• 効率性：3 > 2 > 1 > 4 > 0

ティア0と1のコンプライアンスコストが同じなのは、どちらも実稼働システムをプロジェクターに映すためです。テナントと認証情報に対するセキュリティレビューが同じく必要で、さらに不可逆性も同じです。画面に表示されたものは、1週間以内にカンファレンスの録画に残ります。ティア3と4のコストが同じなのは、どちらも永続的な成果物を作成し、会場に持ち込む前に法務または広報が一度レビューできるためです。その時点なら修正コストも低く済みます。この軸で最も低いのはティア2で、そこには隠れた利点があります。ローカルに用意したフィクスチャはレビューを一切必要としないため、公開制限や顧客データに関するルールがある場合に、ティア2が有力な選択肢になります。

次の2つのフィルターを、この順番で適用します。

1. 主張を裏付けるティアだけを残します。「4つのコマンドで実行できること」が要点のデモなら、ティア3で十分に証明できます。「今、この瞬間に実際の負荷のもとで応答する」といった主張だけが、ティア0または1の対象になります。
2. 残った中で最も上位にランクされているものを選びます。

デフォルトはティア3とし、その1段下のティアを常設フォールバックとして用意してください。

この2段階の手順は、以前からある「主張を証明できる中で、番号が最も大きいティアを選ぶ」という経験則に近く、主張によって候補が厳しく絞られる場合には、その経験則とも一致します。ただし、次の2つの場合は異なります。

• 2つのティアでどちらも主張を証明できる場合、以前の経験則ではどちらを選んでも構いませんが、この比率ではそうなりません。比率では、会場の中ではなく、会場に入る前にコストを支払えるほうを選びます。
• 以前の経験則では、ティア4が利用できる中で最も安全な選択肢に見えます。しかし、この比率では4番目にランクされます。労力がほぼゼロなら、得られる証明力もほぼゼロであり、最も安価なものが最も効率的とは限りません。 この順序ではティア 0 が後回しになります。ラダーの中で最も説得力のあるティアでありながら、観客の前で失敗する可能性も最も高いため、比率で順位付けすると選ばれないからです。それでも、その主張の要点が「実際に動いていること」そのものである場合は、ティア 0 を採用してください。たとえば、観客が入力するデータ、録画で偽装したと疑われかねない競争状態、あるいは「今日、本当に実行した」ことが肝心なローンチです。その代わり、以下のゴールデンパス、人による冗長性、同じセグメントを読み込み済みですぐ再生できるティア 3 の録画を用意してください。

インタビューで除外したものは降格ではなく削除し、削除したティアと理由を明記してください。そうしないと、フォールバックとしていつの間にか復活してしまいます。

• 会場での画面録画が許可されていない場合は、ティア 3 を削除します。
• 部屋の外に持ち出せない非公開の UI がある場合は、ティア 3 と 4 を削除します。
• ローカルモードのない製品の場合は、ティア 2 を削除します。

ティア 0 または 1 では、リハーサルで見つけた、確実に成功する操作の正確な順序であるゴールデンパスを特定し、本番では決して逸脱しないようにします。セグメントの順序としてランブックに記載し、即興の寄り道はすべてティアを下げるものとして扱ってください。

この名称の由来は、2007 年の iPhone 基調講演です。9to5Mac（Internet History Podcast の報道を引用）によると、エンジニアは「Jobs が特定の順序で実行でき、プレゼンテーション中に電話が不具合なく動作し続ける可能性を最大限に高められる、具体的なデモ操作のセット」を見つけました。

すべてのティアに共通するルールは 3 つあります。

• ピクセルが録画でも、ナレーションはライブで行ってください。録画済みの画面に録音済みの音声を重ねると、それは動画です。観客が動画を見ていると気づけば、関心を失います。
• ファイルブラウザーを探し回ることなく、キー操作ひとつで約 20 秒以内にティアを下げられるようにしてください。この所要時間はこのスキルでの目安であり、実測値ではありません。
• 出力ではなく、セットアップを堅牢にしてください。

3 つ目のルールについて補足します。シード済みのデータ、固定したバージョン、事前に取得したイメージ、再生したサードパーティーの応答、プライベートネットワークは、いずれも、観客が信頼する必要のない変動要因を取り除くものです。一方、カウンターのスタブ化、失敗ケースを除外した検証クエリー、ライブと称した録画は、結果の偽装です。発覚すれば、デモが得ようとしていた信頼性をそのまま失います。偽装しなければ主張を実現できないのであれば、その主張は誤りです。範囲を狭めてください。

references/demo-risk-register.md では、対になる例を使ってこの境界を詳しく説明しています。

チェックポイント

• 各セグメントに、そこから開始できる名前付きの復元ポイントを用意してください。例：git タグ、ディレクトリのスナップショット、データベースダンプ、ビルド済みイメージ、データを事前投入したテナント、デモランナースクリプトのステップ。
• **どのセグメントも、前のセグメントのライブ出力に依存してはなりません。**この単一のルールがあれば、デモ全体を諦めずに、失敗したセグメントを飛ばせます。
• 実践者のアドバイスで定着している数である、少なくとも 3 つのチェックポイントを用意し、時間が押したときにどのセグメントを省略できるかをランブックに記載してください。
• 各セグメントの前提条件と期待する画面状態を、「そうでない場合」の分岐とともにランブックに記載してください。失敗の最中に出力が誤っているかどうかを話者が判断しなければならない時点で、すでに 20 秒の猶予を失っています。
• リセットは、コールドマシンからリハーサルしたうえで、冪等な1 つのコマンドで実行できるようにしてください。デモをすでに 2 回実行したマシンから試すのではありません。キーに割り当てるか、付箋に書いておいてください。ストレス下で使うことになります。
• インストール、ビルド、イメージの取得、モデルのダウンロード、インデックスの構築、DNS の伝播、アカウントの認証、コールドスタートなど、時間のかかるものはすべて登壇前に済ませてください。ストーリーの一部ならコマンドを見せてもかまいませんが、観客の前で完了を待ってはいけません。

デモ用の素材が git リポジトリにある場合、scripts/demo-checkpoints.sh を使うと、タグ付きチェックポイントの作成、一覧表示、移動、リセットができます。それ以外の場合も、素材で利用できるスナップショットの仕組みを使って、同じパターンを適用してください。

scripts/demo-checkpoints.sh save 1 baseline-app
scripts/demo-checkpoints.sh list
scripts/demo-checkpoints.sh goto 2      # enter segment 2 directly
scripts/demo-checkpoints.sh reset       # back to the start state

環境の堅牢化

会場のネットワーク接続はあれば便利なものとして扱い、依存してはいけません。ケーブルを抜いてもデモを完了できるようにします。シード済みのフィクスチャと記録済みのサードパーティーからの応答を使ってローカルスタックを実行し、本当にリモート接続が必要なものに備えて、バックアップとしてモバイルホットスポットを用意します。ホテルのロビーではなく、実際の会場でテストしてください。

後方の席から確認できるよう、画面もコードと同じくらい重要です。

• ターミナルは24pt以上、エディターは20pt以上。
• ハイコントラストまたはライトテーマ、ブロックカーソル。
• 約80〜100列。
• 通知をオフにし、チャットとメールを終了し、ブラウザーの新しいプロファイルを使い、シェルの履歴を消去します。

フォントサイズの下限は、測定値ではなく実務上の慣例です。列幅はこのスキルのデフォルト値であり、リハーサル時の会場の解像度に合わせて実際の値を決めます。オートコンプリートのドロップダウンに残ったトークンやクライアント名が、カンファレンスの録画に映り込むことがあります。

オフラインモードの手法、想定しておくべき会場ネットワークの障害パターン、機材とディスプレイのチェックリスト、スクリプト化されたデモツールに関する統合メモの詳細は、references/environment-hardening.mdを参照してください。プロジェクター画面に映り込む可能性があるものについては、references/surface-exposure.mdを参照してください。専用のデモ用プロファイル、ブラウザーと通知の表示、画面共有モード、ターミナルのプロンプト、リポジトリとデータの衛生管理、リハーサル済みの緊急停止ボタンについて説明しています。

リカバリープラン

• 修復は一度だけ試し、その後は切り替えます。 修復にはおよそ20秒を割り当てます。これはこのスキル独自の予算であり、形式に応じて調整します。ステージ上でのデバッグは、聴衆の注意を本題ではない問題に向けてしまいます。また、期待するより早く終わることはありません。
• カオスエンジニアリングで実験開始前に中止手順をスクリプト化してテストするように、イベント前に切り替え手順をスクリプト化し、所要時間を計っておきます。その場しのぎの中止は、中止とは言えません。
• 切り替え時のセリフをあらかじめ書き、切り替え自体も独立したドリルとしてリハーサルします。失敗そのものではなく、リハーサルしていない切り替えに、失われた1分が費やされます。
• 本来どうなるはずだったかを説明してから、フォールバックを見せます。実行がうまくいかなくても、主張は伝わります。
• 謝罪は簡潔に一度だけにします。何度も謝ると、セッションの記憶に残るのが失敗になってしまいます。
• 実際に起きたエラーを内容として扱うのは、一文で説明でき、主張を裏付ける場合に限ります。そうでなければ、聴衆を連れた寄り道になります。
• どの段階の対策でも防げない障害に備えて、人による冗長性を確保します。ノートパソコンの故障や、ディスプレイがミラーリングを拒む場合などです。最前列にいる同僚に、リポジトリのクローン、スライド資料、録画を正常に動作するマシンに用意してもらえば、事前の会話ひとつでセッションを救えます。

リハーサルと合格基準

リハーサルは自信をつけるための儀式ではなく、測定手段として扱ってください。まずはセグメントごとにリハーサルします。そうすることで、想定の2倍の時間がかかるセグメントを見つけられます。その場合の対策は、価値の低い手順を削るか、定型部分を事前に入力しておくことであり、早口で話すことではありません。

練習を重ねるだけでは信頼性は高まりません。Jobsは2007年のiPhone基調講演に向けて6日間リハーサルしましたが、それでもチームは電話を最初から最後まで一度も問題なく動かせませんでした。デモを救ったのは設計上の工夫、つまり操作順序を固定し、インフラを制御することでした。

回数ではなく、結果を数えてください。

以下の合格基準は、このスキルが設定した設計上のしきい値であり、公表済みのベンチマークではありません。各項目はステージ上で起こりうる失敗の種類を1つ検出する、最も低コストなテストです。デモでその失敗が本当に起こりえない場合に限り、項目を省略してください。その場合は、省略した項目も明示してください。以下をすべて満たすまで、設計を繰り返し調整してください。

• 冷間状態からの連続3回の実行 - マシンの状態を新しくし、リセットコマンドのみを実行して、手動で修復せずに、割り当てられた時間内に完了すること。
• すべてのセグメントについて、その前のセグメントを実行せず、リストアポイントから直接、少なくとも1回開始していること。
• リスク登録簿の上位3つのリスクについて、それぞれ発生させ、フォールバックに切り替え、話し続ける練習を、20秒以内に行っていること。
• ネットワークを切断した状態で、全体を通して1回実行していること。
• 会場の解像度とアスペクト比で、後方の席から見えるか確認しながら、全体を通して1回実行していること。
• 実測したデモの合計時間が、デモに許された時間の半分未満であること。

どれか1つでも満たせない場合は、設計を変更してください。ティアを下げる、セグメントを削る、依存関係をオフラインにするなどしてから、プロトコルを再実行します。練習回数を増やして補おうとしてはいけません。

その後、以下の観点からデモを評価します。

• 設計どおりに実行できたか。
• リカバリーに費やした時間（秒）。
• 聴衆の質問が、デモの動作に関するものではなく、デモで示した内容に触れているか。
• デモ部分の録画がどの程度視聴されたか。

これらはすべて、あくまで目安として扱ってください。どれか1つだけで、デモの良し悪しを判断することはできません。

聴衆に応じた調整

上記の技術的な準備は、どの聴衆に対しても同じです。異なるのは、デモのデータと、実行に使うアカウントです。

• B2Bおよびエンタープライズ - 会場を問わず、購入担当者、アーキテクト、セキュリティレビュー担当者が参加します。実際らしく見えるドメインデータを用意してください。foo、test1、asdfは「一度も使ったことがない」印象を与えます。本番環境には触れず、他の顧客のデータを表示しないでください。また、公開禁止情報は事前に消去してください。製品が対応している場合は、読み取り専用の認証情報を使ってサンドボックステナントから実行します。
• 営業および顧客との通話 - 会場ではなく、購入担当者1人と課題1つに向き合います。何を見に来たのかを尋ね、決まった順序ではなく、その内容から始めてください。スライド資料に戻れないため、セグメントに失敗した場合は、次のセグメントの主張につなげてリカバリーします。顧客名漏えいが最も重大な場面なので、上記のサンドボックステナントのルールも守ってください。
• ブース会場 - 座っている聴衆ではなく、通りすがりの人が次々と訪れます。ほとんどの人は数秒で判断します。最も視覚的にわかりやすいセグメントから始め、セットアップから始めないでください。数分ごとに中断され、再スタートすることを想定し、ステージ上でのデモ以上に、各セグメントに個別のリストアポイントが必要です。周囲の騒音があるため、音声に依存する要素は使えません。会場の実際の照明の下でコントラストを確認してください。まずは質問を1つして、関心の有無を見極めます。
• B2Cおよびインディー開発者 - 信頼性を判断するうえでの疑問は、「今夜、無料でこれを使えるか」です。聴衆が実際に利用できるプランで、実際のインストールまたはサインアップの手順と、実際にかかる時間を見せてください。10分のセットアップを隠した認証済みセッションを使うのは、聴衆の信頼を失う最も手っ取り早い方法です。
• 社内向けおよび全社集会 - 不完全なデモへの許容度は高くなりますが、データのリスクは変わりません。未リリース機能、顧客名、売上高は、社内デモの録画を通じて漏えいする可能性があります。

失敗パターン

症状	原因	対処
会場の Wi-Fi が切れるとデモが停止する	スタックをローカルで動かす準備ができていなかった	Tier 2 に移行し、ローカルで動かせない部分に限ってホットスポットを使います
エラーが 1 つ起きただけでデモ全体を諦めてしまう	各セグメントが前のセグメントの出力に依存していた	各セグメントに個別の復元ポイントを用意します
ステージ上でデバッグに 2 分費やしてしまう	切り替えルールがなく、フォールバックもリハーサルしていなかった	修復は 1 回だけ試し、その後は 1 段階下げます
デモが予算時間の 2 倍かかる	セグメントごとの所要時間を測っていなかった	各セグメントの時間を測り、最も長いものを短縮し、定型部分はあらかじめ入力しておきます
後方の 10 列目から画面が読めない	暗いテーマを使い、デスクの距離からリハーサルしていた	24pt 以上、高コントラストにし、最後列から見えることを確認します
通知やトークンが画面に表示される	普段使いのプロフィールでデモを実行していた	新しいプロフィールを使い、おやすみモードを有効にして、履歴を消去します
顧客名、内部 URL、または実データが漏れる	デモ用リポジトリがチームのリポジトリで、データを匿名化しただけで合成データではなかった	専用のデモ用リポジトリと合成データのフィクスチャを用意し、デスクトップ全体ではなくウィンドウを共有します。詳しくは references/surface-exposure.md を参照してください
2 回目の実行結果が 1 回目と異なる	リセットが手作業、または冪等ではなかった	クリーンな初期状態から実行できる、リハーサル済みのリセットコマンドを 1 つ用意します
デモは成功したが、その理由が誰にも記憶に残らない	デモで機能を示しただけで、主張を示していなかった	各セグメントを、その 1 つの主張に結び付け直します
スピーカーのノート PC が故障し、セッションが終了する	人員の冗長性がなかった	すべての複製を持ったサポート役を最前列に配置します
聴衆に「これは本物ですか？」と聞かれ、答えが「いいえ」になる	セットアップの強化が進み、出力を偽装するようになっていた	システムの実際の動作に合わせて主張を限定するか、Tier 4 に下げます
ランブックのコマンドが製品と一致しなくなる	担当者も最終確認日も決まっていなかった	クリーンな初期状態からの実行ごとに日付を記録し、各イベントの前に再確認します

参考資料

• samber/developer-relations-skills@tech-talk-outline：デモをトークのどこに配置するか、何分間使えるかを確認できます。
• samber/developer-relations-skills@technical-video-script：録画版デモのスクリプト作成に役立ちます。
• samber/developer-relations-skills@developer-quickstart-guide：デモの手順を、後から文書化された初回成功への手順にまとめる際に役立ちます。