ライブイベントのための本番前チェックリスト

画面は静かに壊れます。親切なボランティアが閉じたブラウザタブ、眠ったディスプレイ、控え室で切れた Wi-Fi。

これはルームのオーナーか管理者のチェックです — ライブ接続一覧はこの2つのロールにだけ送られるので、オペレーターのコントローラーからは実行できません。

点検項目：

• ルームのライブ接続ビューを開き、一覧を読みます — 接続されているべきディスプレイは、ビューアーがつながっていればそこに現れます。
• 一覧を計画と突き合わせて数えます：ステージモニター、ロビー画面、控え室、モデレーターのタブレット。欠けている画面は謎ではなく、発見です。
• 一覧を読みやすくするために接続名を計画に合わせて変えても構いませんが、名前は一時的なものとして扱うこと。「ロビー画面」はそのブラウザがつながっている間だけ有効で、リロードすると端末は既定の名前に戻ります。
• 各表示端末のスリープが無効で、電源がショーの間もつことを確認します。
• 配信や録画の中の画面については、ブラウザソースが現在のシーンに存在することを確認します。

ランダウンは計画から本番日までの間にずれます — トークが延び、休憩が動く。

点検項目：

• すべてのタイマーの名前・話し手・尺を、最終スケジュールと突き合わせて読みます。
• リンクを検証します：自動で進むべきセグメントはリンクされているか。時計に固定されたものにはスケジュール開始が設定されているか。
• スピーカーのセグメントにラップアップしきい値があるか — そしてそれがブリーフィングでスピーカーに伝えた内容と一致しているかを確認します。
• 終わりの開いたセグメント — Q&A、交流タイム — が恣意的な締め切りではなくカウントアップに設定されていることを確認します。
• バッファを確認します：主要セグメントの間に数分の名前付き転換時間があること。それがあるから、遅れた開始をクロージング枠に払わせずにスケジュールが吸収できるのです。

5分間のリハーサルがシステムを端から端まで証明します。最初のタイマーを開始してステージのディスプレイが拾うのを見る。ラップアップしきい値を越えさせて見た目が変わるのを確かめる。コントローラーからテストメッセージを送り、カウントダウンの隣に届くのを見る。

この3つの挙動が1つの画面で動けば、全画面で動きます — どのディスプレイも同じルームを表示しているからです。残るのは人間の側です。コントローラーを持つ人がどのタイマーでショーが始まるかを知っていて、バックアップの人がコントローラーリンクのありかを知っていること。

最後のチェックは割り当てです。ここではリンクこそが役割だからです。

リスト：

• コントローラー — ショーを回す人の手元に、上演時間もつ電源のある端末で。
• ビューアー — 観客やスピーカーに向いたすべての画面に、フルスクリーンで。
• アジェンダ — クルーとバックステージに。進行表が、聞かれる前に質問に答えるように。
• モデレーター — ショー中にメッセージを送るホストに。
• ルームのリンクを書き留めたメモを見つけやすい場所に1枚 — 端末が死に、代替のブラウザがリンクを必要とする瞬間のために。