製品の動作確認と資料の最終確認

• 日程: Day 20 / セッション 2
• 時間: [9:50-11:00]
• 形式: 実習
• ゴール: チェックリストの全項目を確認し、発見した問題を修正できる
• 学習形式: ハンズオン実習

前のセッションで最終確認チェックリストができました。このセッションでは、それを1つずつ実行していきます。

ここで問いかけです。
「自分のPCでは完璧に動いたのに、人前で見せたら動かなかった」——なぜこんなことが起きると思いますか？

理由はシンプルで、環境が違うからです。プロジェクタにつなぐと解像度が変わってレイアウトが崩れる。会場のネットワークが遅くて画面が表示されない。借りたPCにはフォントが入っていない。コンサートのリハーサルを練習スタジオでやるバンドはいません。本番と同じステージで音を出すから意味があるのです。

このセッションの合言葉は2つです。

• 本番と同じ機材・環境で確認する
• デモが失敗しても発表が止まらない準備をする

動作確認は「機能が動くか」ではなく「本番のデモが成功するか」を確かめる作業です。次の手順で進めます。

1. 本番と同じ機材（プロジェクタ・PC・ネットワーク）に接続する
2. デモで見せる操作を、発表で話す順番の通りに最初から最後まで操作する
3. デモ用データ（ユーザ名・登録内容）が発表にふさわしい状態かを確認する
4. 異常があればその場で記録し、修正する

「機能テストは済んでいるから大丈夫」は通用しません。Day 16のテストは「製品が正しく動くか」の確認でしたが、今日は「発表という舞台で製品が輝くか」の確認です。たとえばテストデータが「あああ」「test1」のままでは、機能は正しくても発表としては台無しです。逆に、些細な既知バグでもデモの動線に乗らないなら今日は直さなくて構いません。

デモ動線確認の記録例です。

• 確認はチェックリストの順に行い、結果（OK/NG）と対応を必ず記録する
• 操作は実装した本人以外が行うと、思い込みによる見落としを防げる
• 修正したら、その周辺の動作をもう一度確認する（デグレード防止。Day 15の学び）
• 直すのは「デモの動線上の問題」だけ。新機能の追加は絶対にしない

「デモの神様」という言葉を知っていますか？ IT業界には「デモは本番に限って失敗する」という伝説的なジンクスがあり、英語では「Demo Effect」と呼ばれます。最も有名な犠牲者はマイクロソフトのビル・ゲイツ。1998年、Windows 98の発表デモで、世界中のメディアの前でブルースクリーン（致命的エラー画面）が出てしまいました。会場は大爆笑。しかし担当者が「だからまだ出荷していないんです」と切り返して拍手を浴びました。世界一の企業でも本番のデモは失敗するのです。だからこそ、次のトピック「代替手段」が効いてきます。

どれだけ確認しても、本番のトラブルをゼロにはできません。プロの発表者は「失敗しない準備」と同時に「失敗しても続行できる準備」をします。

• スクリーンショット: デモの各ステップの画面を撮影し、スライドの末尾（補足ページ）に貼っておく
• 録画動画: デモの操作を通しで録画しておく。ネットワーク障害に最も強い
• 切り替えの台詞: 「うまく表示されないので、画面を撮影したものでご紹介します」と落ち着いて言えるよう、誰がどう切り替えるかを決めておく

ここで考えてみてください。
スクリーンショットと動画、それぞれどんなトラブルに強いでしょうか？

スクリーンショットは「説明のテンポを保ちつつ要点を見せる」のに向き、動画は「操作の流れや動きを見せる」のに向きます。両方あれば最強ですが、時間がなければ最低限スクリーンショットを用意しましょう。

• 代替手段は「作った」だけでは不十分。切り替える手順と担当者まで決めて初めて保険になる
• スクリーンショットはデモと同じきれいなデータで撮る
• 「代替手段があるから雑に確認していい」は本末転倒。あくまで最後の保険

代替手段の備えで歴史に残るのがアポロ計画です。NASAは月着陸ミッションのあらゆる故障を想定し、膨大な「異常時手順書」を準備していました。アポロ13号で酸素タンクが爆発したとき、乗組員が生還できたのは、想定外の事態ですら「想定の組み合わせ」で乗り切る準備があったからです。管制室の合言葉は「Failure is not an option（失敗は選択肢にない）」。みなさんの発表もスケールは違えど同じです。デモが落ちても発表は落とさない。それが準備の力です。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「プレゼン資料の最終チェックで見落としやすいポイントを10個挙げて」
• 「デモ用のスクリーンショットを撮るとき、伝わりやすくするコツは？」
• 「プロジェクタ投影で起きやすいトラブルと対策を教えて」

セッション1で作成したチェックリストに従い、最終確認と修正を行ってください。

1. 製品の動作確認（20分）: 本番と同じ機材・環境で、デモの動線を通しで操作する。結果（OK/NG）を記録し、NGはその場で修正する
2. 代替手段の準備（10分): デモ各ステップのスクリーンショット（可能なら録画動画）を作成し、切り替え手順と担当者を決める
3. 資料の最終確認（15分）: プレゼンスライドの誤字・表示崩れ・ページ番号、パネル・チラシ等の印刷物、想定問答集を確認する。スライドは必ずプロジェクタに投影して、部屋の一番後ろから見え方を確かめる

• 確認結果を記入済みのチェックリスト（全項目にOK/NGと対応の記録）
• 修正済みの製品とプレゼン資料
• デモ失敗時の代替手段（スクリーンショット一式または動画）と切り替え手順

• 確認順序に迷ったら「直すのに時間がかかりそうなもの（製品・印刷物）」から先に確認しましょう
• エラーが出たらAIに「デモ中に〜というエラーが出た。発表まで時間がない。応急処置はある？」と状況ごと伝えると、根本修正と応急処置の両方を提案してもらえます
• 誤字チェックはAIが得意です。スライドの文字を貼り付けて「誤字脱字と表記ゆれを指摘して」と頼みましょう
• 全項目を終えるのが目標です。1つの修正に10分以上かかりそうなら、チームに報告して対応方針（直す／代替手段でカバーする）を合意してから進めましょう

今回学んだことを一言でまとめると、**「本番と同じ環境で確認し、失敗しても続行できる保険を持つのがプロの準備」**です。

• 動作確認は「機能が動くか」ではなく「デモが成功するか」の視点で行う
• 代替手段（スクリーンショット・動画）は切り替え手順までセットで準備する
• 修正は「デモの動線上の問題」に絞る。新機能追加はしない

次のセッションは、いよいよ本番と同じ流れの通しリハーサルです。確認済みの製品と資料を持って、発表そのものを磨きます。

以下の問いに答えられるか確認してみましょう：

• なぜ「本番と同じ機材・環境」で確認する必要があるのですか？
• デモ失敗時の代替手段を2つと、それぞれの強みを言えますか？
• チェックリストでNGが出たとき、記録する内容は何ですか？
• このタイミングで「やってはいけないこと」は何ですか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: 「Demo Effect」で検索すると、世界中のデモ失敗とその教訓が読めます
• 発展課題: 自チームのデモで起こりうるトラブルをAIと一緒に5つ想定し、それぞれの対応を1行ずつ書いてみましょう（リスクの事前洗い出しは実務のプロジェクトでも必須スキルです）

このセクションは、受講者が理解を深めることをサポートする参考情報です。