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

• 日程: Day 20 / セッション 2
• 時間: 09:50-11:00（70分）
• 形式: 実習（ハンズオン）
• ゴール:

  • 行動: セッション1で作ったチェックリストの全項目を確認し、発見した問題を修正する
  • 条件: 本番と同じ機材・環境で
  • 基準: チェックリストの全項目がOK、もしくはOK不能な項目にPlan Bが用意されている状態にする
• 学習形式: ハンズオン実習

セッション1で5観点のチェックリストを作りました。ここからは「実際にやってみる」時間です。

ここで1つだけ強調します。本番と同じ機材・環境で確認する。これが破られると、リハーサルの意味の8割が消えます。

たとえば「自分のPCでは動いたから大丈夫」は通用しません。本番会場では、プロジェクタの解像度が違う、Wi-Fiが遅い、フォントが入っていない、画面サイズが小さい——あらゆる「自分の机にはない条件」が襲ってきます。

このセッションでは、チェックリストを潰しながら「動かなかったらどうする？」のPlan Bも同時に育てていきます。

「本番と同じ環境」と言われても、本番会場が今ここにないなら、できることは限られます。それでも次の4つは必ず合わせます。

「自分のPCでは動くが、別PCで動かない」典型例。

[NG例] localhost で動くデモ
  → 別PCのブラウザからアクセスできない
  → 当日は発表者のPC1台のみで完結する構成にする

[NG例] 開発中のブランチで動くデモ
  → 当日のリポジトリ状態と違う
  → 「発表用ブランチ」を確定させ、当日もそこから動かす

[NG例] 「絶対動く」前提のAPI呼び出し
  → 当日ネットワークが詰まったら即崩壊
  → 失敗時のメッセージを準備、もしくはローカルにモックデータ

「今動いた」は「本番で動く」の証拠ではありません。「他人が・他のPCで・他のネットで・本番直前に動く」ことが本物です。

ソフトウェア開発の世界に「Demo Effect（デモ効果）」という言葉があります。
「リハーサルでは完璧に動いたデモが、本番では必ず壊れる」という現象です。原因は超常現象ではなく「観客が増えて緊張」「環境が違う」「実行者が違う」のどれか。
スティーブ・ジョブズはiPhone初代発表のリハーサルで何百回もデモを通したと言われます。それでも本番では裏で2台目のiPhoneがスタンバイしていました。プロほどPlan Bを用意します。

デモが止まったとき、無音になって司会が固まる——これが最悪のシナリオです。これを避けるため、Plan Bを3段階で準備します。

切り替えは「2秒詰まったらPlan B」など、事前に判断基準を決めておきます。本番でアドリブで判断すると、判断自体に時間を取られて沈黙が長引きます。

スライドの誤字脱字・ページ番号・遷移リンク・デモ呼び出しの位置——これらは1人でチェックすると必ず見落とします。

おすすめの方法は「音読リレー」です。

1. スライドを画面に映す
2. メンバーが順番に1スライドずつ声に出して読む
3. 違和感を覚えた人はその場で止める

声に出すと、目だけでは気づかなかった「読みづらさ」「意味の通らなさ」がわかります。これは設計書レビューでも使えるテクニックです。

• 「（製品のデモシナリオを貼って）このデモで起こりうるエラーを5つ挙げて」
• 「（スライドのアウトラインを貼って）論理の飛躍がある箇所を指摘して」
• 「プロジェクタにつないだ時に起きる典型的なトラブル5つと対処を教えて」

時間配分の目安:

確認の進め方:

1. 担当者がチェック項目を音読する
2. 該当機能・資料を実機で動かす／見る
3. OKなら「OK」、NGならその場で修正or Plan Bに振り分ける
4. 修正したら必ず再確認する（直したつもり病の予防）

このセッションでは、チェックリストを片手に本番と同じ環境で確認しました。

次のセッションでは、本番と同じ流れで通しリハーサル。他チームが聴衆役・審査役になり、質疑応答まで含めて本番さながらにやります。

• 「本番と同じ」の4要素を言えますか？
• Plan A・B・Cはそれぞれ何を指しますか？
• 「直したつもり病」を防ぐにはどうしますか？
• 音読リレーの目的は何ですか？

• 参考リンク

  • 「Demo Effect」: 開発者の経験則。実例検索でケースを学ぶ
• 発展課題

  • 自チームのデモ動画（30秒）を録画してみる
  • スクショだけで「製品の価値が伝わる5枚」を選んでみる