event-run-of-show

当日の進行表

当日そのものを担当します。進行表は決定済みで渡され、再検討することはありません。samber/dev-event-organizer-skills@event-schedule-design は、担当範囲の違いを次のように示しています。「公開済みの進行表を作るところまでが担当です。当日にスタッフが分単位でどう進行するか、欠席者や AV の障害に現場でどう対応するかは、samber/dev-event-organizer-skills@event-run-of-show の担当です」。

進行表以外に、もう一つ成果物を引き継ぎます。スケジュール文書に記載された中断時の優先順位です。

1. まず全体会または基調講演を守ります。
2. 次に、参加者が足を運ぶ理由となった目玉の企画を守ります。
3. 対応策によって影響を受ける他のセッションをできるだけ減らします。
4. そのブロックの残り時間について、修正後の進行表を確定します。

この優先順位を引き継いでください。プレッシャーの中で新たに導き出してはいけません。

samber/dev-event-organizer-skills@event-speaker-experience も、担当範囲の違いを次のように示しています。「当日の分単位の進行は samber/dev-event-organizer-skills@event-run-of-show の担当です」。また、このスキルが担当するのは「当日の分単位の進行文書」であり、「登壇者の時間に関する要件を伝えてください」と記しています。グリーンルーム、テックチェック、登壇者を会場内の部屋まで案内する現地ホストは、引き続きそちらの担当です。登壇者の到着予定や時間に関する制約を入力として受け取り、登壇者の遅れが発生したときに判断を下すのが、あなたの役割です。

さらに、次の2つの境界があります。

• samber/dev-event-organizer-skills@event-risk-management は、常設のリスク一覧表と印刷された緊急対応計画を作成します。対象となるシナリオや連絡先がその範囲です。安全に関するシナリオを再作成することはありません。何かが起きたときにその計画を_実行する_当番の担当者と連絡手段を受け持ちます。
• samber/dev-event-organizer-skills@event-production は、予備マイクや2つ目の録音経路など、技術的な冗長性を設計します。冗長性が機能しなくなった後の90秒間に、ルームリードが何をするかを受け持ちます。

以下の各順位はあくまで初期設定であり、絶対的なルールではありません。状況や実行する人によって変わります。聞き取りの後、すでに把握している情報に照らして、3つの選択肢をすべて順位付けし直してください。次の要素は、いずれも初期設定の順位を覆す可能性があります。

• イベントがすでに所有している無線機。
• 電波の届かない会場の地下。
• 同じイベントをすでに4回運営したことのあるボランティアチーム。
• 前回、毎時間開始が遅れた部屋。
• 厳守すべきブリーフィングの締め切り。

面談

一度に質問は1つにし、可能であれば選択式にします。質問5～7があるのは、メニューの優先順位が効果の出るまでの時間、持続性、労力によって大きく異なるためです。こうした優先順位をユーザーに代わって決めることはできません。

1. 公開済みのタイムテーブルはどのようなもので、スケジュール資料には混乱発生時の優先順位が記載されていますか？記載されていなければ、何かを書く前に入手してください（ワークフローのステップ1を参照）。
2. 同時に稼働する部屋やステージはいくつありますか？また、それ以外にスタッフを配置する場所として、受付、運営本部、案内デスク、スポンサー展示ホールなどはありますか？
3. 当日は誰が、どのシフトに入りますか？ボランティア、主催者、有給スタッフ、会場スタッフなどです。これは samber/dev-event-organizer-skills@event-volunteers から得る情報であり、自分で作るものではありません。
4. スタッフがいる場所すべてで携帯電話の電波は届きますか？また、会場独自の連絡手段に参加する必要があり、ほかの連絡手段で代用できないことはありますか？
5. 変更できる最後のタイミングはいつですか？進行表を印刷する、シフトに人を追加する、部屋のリーダーに説明するといった変更です。メニューの優先順位を決める基準はイベント当日ではなく、その期限です。
6. 単発の開催ですか、それとも定期開催ですか？定期開催なら、効果が当日終了後に現れる項目の優先度を上げます。再利用可能な進行表テンプレート、文書化した引き継ぎ形式、記録した転換時間などです。
7. 労力の上限はどの程度ですか？この文書を作成・維持するのは誰で、何時間かけられますか？また、担当業務をせずに対応できる当番の人員は何人ですか？
8. 印刷済みの緊急時対応計画はありますか？そこには誰の名前が記載されていますか？なければ、それは samber/dev-event-organizer-skills@event-risk-management の担当範囲であり、作業を進める前に必要です。
9. メニューの優先順位を変えるべき既存の事情はありますか？前回開催時の超過時間、所有している無線機、電波の届かない地下室、経験豊富なチーム、いつも開始が遅れる部屋などです。
10. オープニングは録画またはライブ配信されますか？また、スポンサー契約で一字一句そのまま読み上げる文言が定められていますか？

コミュニティ運営かベンダー運営か：検証の結果、この区分が当てはまるのは一部だけです

コミュニティ運営かベンダー運営かという区分は、当日の一部には当てはまりますが、それ以外には当てはまりません。

司会進行には当てはまります。 DevOpsDays は「1人以上の司会者」と記しており、これは代替策ではなく、正式な選択肢として複数人を認めています。これは実際に選択が分かれる点です。

• コミュニティ寄り： 決まった手順書がない中で、イベントの理念をすでに体現している主催者に司会を分担します。主催者が交代で司会を務め、各セッションには別途、登壇者を紹介する人を配置する計画を立てます。
• ベンダー寄り： 司会を専門的な役割として捉え、事前説明とリハーサルを受けた1人の司会者を立てます。実践者向けのガイダンスでは、イベントの文化に合わせた台本作成や、事前に一緒にリハーサルを行うことが取り上げられています。また、「最初の90秒がイベント全体の雰囲気を決める」という規律も紹介されています（司会業務を販売するプロの司会サービスによるガイダンスなので、その利害関係を念頭に置いて読んでください）。司会者1人、台本1本、リハーサル1回を計画し、それに応じて進行表の詳細度も1段階上げます。

それ以外のすべてには当てはまりません。 移行にかかる時間は誰が実行しても同じで、無線機の通信距離も同じです。会場の費用を誰が負担しても、引き継ぎで失われる情報は変わりません。

それ以外の作業を実際に左右するのは、同時に稼働するスタッフ配置場所の数と、当番の人が別の業務も兼ねているかどうかです。主催者3人が一日中互いを把握できる単一会場のミートアップでは、チャンネル構成はまったく必要ありません。4部屋を使う日は、ほかの何よりも先にチャンネル構成が必要です。

推奨事項で前提が異なる場合は、どちらの運営形態、またはどの規模を想定しているかを明記してください。

ワークフロー

1. 公開済みの進行表と、混乱時の優先順位を確認します。スケジュールドキュメントに優先順位が記載されていない場合は、独自に決めず、確認してください。優先順位の決定はプログラム上の判断事項です。会場に人がいっぱいの14:00に即興で決めると、スポンサー枠を確保するために基調講演をカットすることになりかねません。
2. 当日の運営に必要な情報を集めます。シフト計画、各登壇者の到着予定と時間的な制約、会場側の利用可能時間とスタッフ、担当者名が記載された緊急時対応計画です。
3. 当日の役割を、機能ではなく担当者名で割り当てます（下記参照）。「ボランティア」では担当者が明確になりません。
4. メニューで選んだ詳細度に合わせてキューシートを作成し、進行表から範囲を広げていきます。1時間ごとではなく、各セグメントと各切り替えごとに行を設けます。
5. 通信チャンネルの構成を決め、エスカレーション経路を2つキューシート自体に記載します。通常経路（担当者の権限を超える事案が発生した場合）と、緊急時対応計画につなげるインシデント経路です。緊急時対応計画は書き換えません。
6. 当番ローテーションと引き継ぎの形式を整えます。各時間帯の当番担当者をキューシートに記載し、受付デスクのボランティアが誰にも尋ねずに確認できる場所に掲示します。
7. 書類を基準に全員へブリーフィングを行います。ブリーフィングでは、2つの行が同じ担当者を同時に別々の部屋に配置している、といった問題を見つけます。
8. 当日を運営します。切り替えのたびにキューを実行します。列の位置、テクニカル担当者、読み上げる文言（下記参照）を確認します。
9. 問題が起きたら、その場で判断をやり直すのではなく、実際の混乱時の対応手順（下記参照）を実行します。
10. シフト交代のたびに、退任する担当者が退出する前に引き継ぎを完了します。ライブチャンネルの確認も含めます。
11. 終了処理を行います。最後のセグメント、会場への引き渡し、書類の誤りの当日中の記録を済ませます。

印刷してブリーフィングを行う前に、進行表をセクションごとに提示して検証します。役割、キューシート、通信とエスカレーション、ローテーションの順に確認してください。印刷後に変更するたびに、旧版を持っている人が1人必要になります。

ハーネスに永続メモリがある場合は、次の内容を記録します。

• 誤っていた行。
• 長引いた切り替え。
• 通信チャンネルが機能しなかった場所。
• 実際に連絡が取れた人。
• 会場独自の通信手段とカバー範囲に関する情報。

2回利用する会場なら、同じことを再び調べる手間を省く価値があります。

当日の役割

3つの役割は、公開されている主催者向けガイドに由来します。4つ目は独自に定義する役割で、登場箇所にその旨を記載しています。

• MC（出典あり） - イベントを開始し、進行を取り仕切ります。1人以上を配置できます。複数人に役割を分担させるのは、妥協ではなく明示された慣行です。
• 登壇者紹介担当（出典あり） - MCとは_別の_役割で、各セッションに割り当てます。MCはイベント全体の流れを取り仕切り、次の登壇者を紹介する各セッションの担当は別の人が務めます。この2つを兼任させることは、以下に挙げる明確な失敗パターンです。
• 当番の主催者（出典あり） - 各時間帯の直前の判断を担う指名された担当者で、通常のエスカレーション経路の連絡先です。これは公平なローテーションのためではなく、危機対応の意思決定における単一障害点を軽減する手段として、明示的に出典で示されています。
• ルームリード（独自に定義する役割） - 各部屋に1人配置し、その部屋の進行時間を管理します。開始を保留し、質疑応答を切り上げ、テクニカル担当者を呼び、当番の主催者にエスカレーションします。公開されている慣行では部屋ごとの担当者を想定していますが、その担当者が何を判断できるかは定められていません。したがって、自分の書類では権限を明確に定義します。単独でできることと、エスカレーションが必要なことを記載してください。

識別可能なチームは、独自に定義する役割ではなく、入力として扱います。samber/dev-event-organizer-skills@event-code-of-conduct の行動規範対応チームと、大規模なカンファレンスの場合は samber/dev-event-organizer-skills@event-accessibility-inclusion のインクルージョンチームです。それぞれを当番表の行と、冒頭で読み上げる文言に記載します。各チームの役割と、見分け方を伝えてください。

キューシートの詳細度

優先順位（デフォルトであり、絶対的なルールではありません。Q5、Q6、Q7、Q9で順位は変わります）：

• 労力（執筆、リハーサル、各セグメントの時間計算、ブリーフィングでの調整にかかる時間）：一言一句書き起こしたMC台本 > 各枠の実施予算 > 進行台本 > 担当者名入りのタイムテーブル

• 価値、間延びや引き継ぎ漏れなく進行する一日：進行台本 > 各枠の実施予算 > 担当者名入りのタイムテーブル > 一言一句書き起こしたMC台本

• 価値、オープニングとクロージングを参加者がどれだけ記憶にとどめるか：一言一句書き起こしたMC台本 > 進行台本 > 担当者名入りのタイムテーブル == 各枠の実施予算 - 同順位の根拠：担当者の列も、設営と入れ替えの時間も、聴衆が耳にする言葉を一つも変えません。どちらも円滑に進む一日には役立ちますが、誰かの記憶に残る瞬間は生み出しません。

• 効率：担当者名入りのタイムテーブル > 進行台本 > 各枠の実施予算 > 一言一句書き起こしたMC台本

• 担当者名入りのタイムテーブル - デフォルトです。すべてのセグメントと引き継ぎに開始時刻、担当者名、会場を割り当てます。タイムテーブルはすでにあり、列を一つ追加するだけなので、作業はほぼゼロです。ブロック間の引き継ぎがバッファで吸収できないほど速い場合（ライトニングトーク、デモ、連続するスポンサー枠など）、または複数の会場が同時に使われる場合は、すぐに一段階上げてください。

• 進行台本 - 各引き継ぎで実際に何が行われるかを定めます。次の登壇者が立つ場所、技術面の担当者、実際に口にするセリフを明確にします。これは短時間で次々に切り替わる形式をもとにし、あらゆるタイトな引き継ぎに応用できるよう一般化した、出典のある進行方法です。具体的な手順と記入例はreferences/cue-sheet-anatomy.mdを参照してください。

• 各枠の実施予算 - 公開されている枠の長さに準備時間が含まれていると想定せず、ライブ実施に伴うリスクがある枠では、設営と入れ替えにかかる時間を予算に含めます。出典のある具体例では、ライブデモにチームごとに10分を割り当てています。デモに3分、質疑応答に1～2分、残りの5～6分を設営と次のチームへの入れ替えに使うため、枠の半分以上が発表以外に費やされます。これはその形式でのイベント固有の数字として提示し、固定値として扱わないでください。

• 一言一句書き起こしたMC台本 - 優先度を下げる選択肢です。すべてのセリフを書き起こし、リハーサルします。記憶に残るかという軸では最上位ですが、労力も最大なので、効率の観点から選ばれることはありません。Q10に基づく昇格条件：雇用または事前説明を受けたホストが一人で進行し、主催者が分担してホストを務めない場合、録画またはライブ配信するオープニングの場合、契約どおり正確に読む必要のあるスポンサー向けの文言がある場合、または誰も経験したことのない初開催で、即興より読み上げが適している場合。

• 優先度を下げずに削除してください： スタッフ用文書として、参加者向けに公開するスケジュールを使うこと。担当者、引き継ぎ、技術面の情報がなく、これを選択肢に残しておくと、電話を持っている人が公開アジェンダを見ながら一日を進行することになります。

通信チャネルのアーキテクチャ

ここで採用されているパターンは、製品ではなく構造です。運営チーム専用の連絡チャネルを1つ設け、参加者向けのあらゆるチャネルと分けます。運営チームに連絡するために参加者が使うチャネルも例外ではありません。こちらは別の公開スペースであり、運営チームはそこで連絡を受けるだけです。元の例ではハッカソンについて説明しているため、チャットプラットフォームでこの分離を実現していますが、無線、電話グループ、あるいは互いの様子が見える3人のチームにも応用できます。実際のイベントにある連絡手段に合わせてください。

優先順位（デフォルトであり、絶対ではありません。Q2、Q4、Q9で順位を見直します）：

• 労力（機材、セットアップ、使ったことのない人に教えるための規律、管理するメッセージ量）：コールサインを使う無線ネット > 役割別チャネル > テキストとリアルタイムの組み合わせ > 運営チーム専用チャネル1つ

• 価値：リアルタイムの問題が起きたとき、メッセージが適切な人に届くか：コールサインを使う無線ネット > 役割別チャネル == テキストとリアルタイムの組み合わせ > 運営チーム専用チャネル1つ - 同順位とする理由：どちらも、分化していない同じ情報の流れを1つの基準で分ける点では同じで、一方は機能、もう一方は緊急度で分けます。どちらが役立つかは、その日の混乱が役割間の連携不足によるものか、ノイズによるものかによって変わります。どちらも電波の届かない場所にいる人には届きません。

• 価値：引き継ぎやイベント後の振り返りで、読み返せる記録が残るか：テキストとリアルタイムの組み合わせ > 役割別チャネル > 運営チーム専用チャネル1つ > コールサインを使う無線ネット。無線には何も残りません。そのためここでは最下位ですが、上の項目では最上位です。

• コンプライアンス上のコスト（必要となるレビューと、取り消しにくいこと）：コールサインを使う無線ネット > 運営チーム専用チャネル1つ == テキストとリアルタイムの組み合わせ == 役割別チャネル - 同順位とする理由：残る3つはいずれも、参加者向けチャネルを開設した時点でイベントがすでに利用規約に同意しているプラットフォーム上にあるため、新たなレビューは発生しません。レビューが必要になるのは無線だけです。管轄区域でその周波数帯が免許不要か、また会場が運用しているネットに割り込んで話すのではなく参加しなければならないかを確認してください。無線が届いてから決めたチャネル計画は、変更が難しいものです。

• 効率：運営チーム専用チャネル1つ > テキストとリアルタイムの組み合わせ > 役割別チャネル > コールサインを使う無線ネット

• 運営チーム専用チャネル1つ - デフォルトの選択肢です。運営チームのための連絡スペースを1つ設け、構造上、参加者向けのあらゆるチャネルと分けます。勤務中の誰かが画面から離れる場合、またはシフト交代時に次の担当者が状況を把握する必要がある場合は、すぐに1段階上の選択肢に移行してください。

• テキストとリアルタイムの組み合わせ - ログが残るテキストチャネルと、リアルタイムの連携に使うチャネルの組み合わせです。元のセットアップで推奨されているのは、まさにこの組み合わせで、追加するチャネルは1つだけです。

• 役割別チャネル - 運営チーム用チャネルに加えて、機能別（会場、受付、制作）のチャネルを設けます。情報を正確に届けられる一方で、各メッセージの送信先を全員が判断する必要があり、誰かが4つのウィンドウを見守る必要があります。

• コールサインを使う無線ネット - 人手が足りない場合の選択肢です。到達性と労力の必要度が最も高く、運用ルールも自分たちで決めなければなりません。コールサイン、役割別のチャネル割り当て、プッシュ・トゥ・トークのエチケット、チャネルが混信したときの対応を定めます。次の場合は、この選択肢に引き上げます。会場で携帯電話の電波が届かない場合、複数階または複数の建物にまたがる会場の場合、スタッフの手がふさがっている場合、テキストチャネルのスクロールが読む速さを上回るほどメッセージ量が多い場合、または参加しなければならないネットを会場がすでに運用している場合。

• 降格ではなく削除する： 運営チームの連絡に使う参加者向けチャネルです。誰が何を理由に慌てているのかを、その当事者に向けて公開し、勤務中の担当者が必要としていた1つのメッセージを、ほかの人の投稿の下に埋もれさせます。後回しにして残しておくと、運営チーム用チャネルがまだ作られていない09:00に、また使われることになります。

当番のローテーションと引き継ぎ

ローテーションは、公表されている主催者の慣行に従います。シフトの交代方法に関する以下の内容はすべて、オンコールエンジニアリングの慣行を参考にしています。構造のみを取り入れ、ツールや数値は取り入れません。全体の対応関係はreferences/shift-handoff-protocol.mdを参照してください。

順位（デフォルトであり、絶対的な決まりではありません。Q3、Q6、Q7では順位を変更します）：

• 労力（担当する人数、変更ごとに必要な2人分の時間、ロスターの複雑さ）：ペアで当番 > 時間を区切った重複とその場での確認 > 文書化された引き継ぎチェックリスト > 各ブロックの当番を明示。重複はチェックリストを含むため、チェックリストより上位です。重複時間は記録と会話の両方に使われ、境界の時点で両者が同じ場所にいる必要があります。チェックリストは作成後に残しておくだけなので、この点が異なります。
• 価値：引き継いだ内容を次の担当者が把握していること：ペアで当番 > 時間を区切った重複とその場での確認 > 文書化された引き継ぎチェックリスト > 各ブロックの当番を明示
• 価値：危機対応の判断を一人だけが担うことにならないこと：ペアで当番 > 各ブロックの当番を明示 > 時間を区切った重複とその場での確認 == 文書化された引き継ぎチェックリスト。同順位とする根拠は、どちらも判断を下せる人数を変えず、次の担当者への説明の質だけを変えるためです。明示されたローテーションが両方より上位なのは、まさにこの問題に対して、参照元の慣行が示す仕組みだからです。
• 効率：各ブロックの当番を明示 > 文書化された引き継ぎチェックリスト > 時間を区切った重複とその場での確認 > ペアで当番

優越性の確認：4段階、6組、厳密な優越関係はゼロです。 これは構成上そうなっているだけであり、構成上の結果は合格を意味しません。次の2つの仕組みが、6組すべての優越関係を阻んでいます。

• 4組は労力が理由です。 引き継ぎの質が高い上位の段階ほど、厳密に大きなコストがかかります。重複とチェックリストの組み合わせも例外ではありません。重複は引き継ぎの質で上回り、一人に依存するリスクでは同等ですが、それでもコストは高くなります。
• 残りの2組（重複とローテーションの比較、チェックリストとローテーションの比較）は、価値の評価軸が逆向きであるため、優越関係にはなりません。誰が判断を下せるかに対応する、低コストの段階はローテーションだけだからです。

どちらの理由も、根拠とは言えません。以下の順位には根拠があります。

• 各ブロックの当番を明示 - デフォルトであり、参照元の慣行です。すべてのブロックについて当番を公表し、ポストにいるボランティアが尋ねなくても読めるよう、運営用シートに記載します。対応中の問題がある最中に交代が発生する場合や、交代時に前の担当者が会場を離れる場合は、一段階上げます。
• 文書化された引き継ぎチェックリスト - 固定の項目を定め、各項目への記入を必須にします。すべての項目に記入するか、明示的に「なし」と記載するまでは完了としません。重要なのは、この「なし」の明記です。「報告事項がない」と「誰も確認していない」を区別できるためです。慌ただしい引き継ぎでは、まさにこの違いが見落とされます。
• 時間を区切った重複とその場での確認 - 即時に交代するのではなく、短い重複時間を設け、最後に、次の担当者が実際に連絡チャネルに接続できることをその場で確認します。口頭で「できる」と保証するだけでは不十分です。前の担当者がすでに退場している場合は、書面による簡易な引き継ぎと短い録画による説明に切り替えます。
• ペアで当番 - 実施が難しい選択肢です。各ブロックを2人で担当し、2人が同時に交代しないよう時間をずらします。継続性に関する2つの評価軸で最上位ですが、労力も最大です。コミュニティ規模では、追加の人員はそのまま運営チームの規模拡大を意味します。優先する条件は、夜通しのイベント、失敗のパターンがまだ誰にもわからない初開催、当番が司会または登壇者を兼ねる場合、あるいは2つのトラブルが同時に起きるほど大規模なイベントです。
• 格下げではなく削除： 当番を明示しない方法。「最も近くにいる人が判断する」という考え方です。これは、参照元の慣行が防ごうとしている単一障害点を、柔軟性という装いで覆い隠しています。実際には一人がすべてを判断することになり、会場を離れることもできません。

進行の切り替え

進行の切り替えを支える要素は3つあり、いずれもタイミングではありません（連続する短いデモ形式から取り入れ、どんなタイトな引き継ぎにも応用できます）。

• 待機位置 - 次の担当者が実際に立つ場所です。客席ではなく、ステージの横に立ちます。
• 技術担当 - 事前に資料を集めておき、1台のマシンを1人の担当者が操作します。こうすれば、引き継ぎはファイルの切り替えで済み、ノートPCを交換する必要はありません。
• 口頭での案内 - 形式上の制約をその場で口頭で再確認します。全員に事前に伝えてあっても、当日に伝えます。

情報源は、事前説明で伝えたことを前提にせず、実際に使う場面であらためて伝える価値があると明確に述べています。

特に重要なセグメントは2つあり、キューシートでは最も詳しく記載する必要があります。

• オープニング - その日の流れを決めます。
• クロージング - 人々の記憶に残るのは、始まりと終わりです。

情報源に基づくオープニングの内容チェックリストとクロージングの進行方法は、references/cue-sheet-anatomy.md を参照してください。

クロージング後の時間を守る

最後のセッション直後の交流時間は、残り時間ではなく、独立したセグメントです。変化の速い分野では、交流会のドリンクタイムが同業者同士で教え合う場になります。ある主催者は、これを夜のイベントで最も重要な時間だと述べています。キューシートにはこの時間を守る仕組みがないため、それ以前のすべての遅れがここにしわ寄せされます。

• クロージングの交流会には専用の行を設けます。開始時刻を厳守し、担当者を決め、開始を告げる口頭での案内を記載します。
• 最後のセッションには、会場責任者が担当する終了合図を設定します。セッション枠の公表終了時刻ではなく、交流会の開始時刻に合わせます。
• samber/dev-event-organizer-skills@event-official-social-program がスケジュールに時間の保護要件を設けている場合、確保した時間は中断時の優先順位において保護対象として扱います。まずQ&Aまたは移行用の予備時間を削ります。
• 最後のセッションで早めに退出する人がいないか確認します。退出者がいる場合、プログラムが長引いたか、クロージングがイベントの一部として感じられていなかったことを意味します。

進行中に混乱が起きた場合

その場で一から判断してはいけません。次の手順に従います。

1. 会場で状況を伝えます。 会場責任者が何が起きたかを伝え、計時を開始します。欠席、配信の障害、30分枠のセッションが始まってから40分が経過している場合などです。
2. 適切な担当者に回します。 現場担当だけで解決できることは、現場で解決します。その権限を超えることは、通常の経路として、組織のチャンネルで当番の主催者に伝えます。安全、医療、セキュリティに関する事案は、印刷済みの緊急対応計画に記載された連絡先へ直接つなぎます。この計画は samber/dev-event-organizer-skills@event-risk-management が作成したものであり、書き換えるのではなく、その指示を実行します。
3. 会場の雰囲気ではなく、公表済みの混乱時の優先順位に基づいて判断します。 まず全体会または基調講演を守り、次に目玉となる約束を守り、そのうえで、対応による他のセッションへの影響を最小限に抑えます。
4. 残りの時間帯について変更後のスケジュールを確定します。 当日中に何度も組み替えることは避けます。
5. 会場とチャンネルの両方で、声に出して伝えます。 変更を誰も告知しなければ、印刷済みのシートを見て次に行動する人によって、変更が取り消されてしまいます。
6. 誤っていた行を、進行中のうちにテキストチャンネルに記録します。 次のシフトと次回の開催に引き継がれるのは、その記録です。

手順3で誰がどの権限を持つかは、あなたが決めます。事前に決定し、文書に記載して、標準的な慣行として示すのではなく、誰が決定したかを明記してください。空白のページではなく、たたき台が必要な場合は、references/comms-and-escalation.md に、さまざまな業界でのエスカレーション手順の構成に関する慣例が記載されています。

終了処理

終了処理では、次のことを行います。

• 契約で定められた条件に従って、会場を返却します。
• 人が自然にいなくなるのを待たず、スタッフに明確に解散を伝えます。
• 文書の不備を当日中に記録します。誤っていた行、長引いた移行、担当者に伝わらなかったエスカレーションを特定します。

時間が経ってから振り返ると、決定事項は思い出せても、タイミングは失われます。

失敗パターン

• あらゆる危機対応の判断が、1人に集中している。 担当ローテーションが決められていないため、同じ主催者がすべての連絡を引き受け、建物から離れられません。根拠のある対策は、時間帯ごとに公開する当番ローテーションです。
• MCがすべての登壇者も紹介している。 根拠のある2つの役割が1つにまとめられた結果、当日の進行を取り仕切る人が、40分ごとに特定の演台にいなければならなくなります。役割を分けましょう。紹介役は自由に交代できます。
• 参加者向けチャンネルで主催者間の連絡をしている。 関係者の目の前で問題が議論され、重要なメッセージがほかの人の投稿に埋もれてしまいます。別チャンネルは当日ではなく、事前に作成しましょう。
• 合図のない移行。 進行表にはセッションが11:20に終了すると書かれているだけで、誰が話すのか、次の担当者がどこに立つのか、誰のマシンにスライドがあるのかが記載されていません。その結果、無音の時間が生まれ、スケジュールが見込んでいたバッファを消費します。
• 会場の再配置が、目に見えないところで行われると思い込んでいる。 同じスペースを別の用途で使う間の設営変更に、担当者も時間枠も割り当てられていないため、次の枠を圧迫するか、作業そのものが省かれます。ほかの移行と同じように専用の行を設け、現在のセグメントが終わってからではなく、進行中に開始しましょう。
• 終了後の交流時間が、あらゆる遅れを吸収している。 各セッションが5分ずつ延び、参加者同士が実際に知識を共有するドリンクタイムがなくなります。対策：最後のセッションに終了厳守の合図を設け、終了後の行の開始時刻に連動させます（§ 終了後の時間を確保する）。
• 実地確認のない引き継ぎ。 引き継ぎを受ける人はチャンネルを使えると思っていますが、最初のエスカレーション時に使えないことがわかります。引き継ぎ元が立ち去る前に、実際に確認しましょう。
• 混乱発生時の対応順序をその場で決める。 スケジュールにはすでに対応順序が公開されています。この連絡を、その場で故障箇所に最も近い人が、プレッシャーの中で判断しなくて済むように定めたものです。
• 独自のルールを業界標準として提示している。 無線の運用ルール、会場リードの権限、シフト交代の方法は、最後のものがオンコールのエンジニアリング現場から取り入れたものですが、いずれも独自に定めたルールです。実際の権限系統の形は、公開されている舞台管理や制作の慣習を参考にしていますが、具体的な担当者の割り当ては、依然として主催者が決めるものです。独自の詳細を確立済みの標準として提示すると、出典のある部分に必要な信頼性を損ないます。

測定

開始前に確認できる完全性の基準は2つです。議論の余地がある数値目標は設けません。

• 担当者が配置されたすべてのポストで、誰にも尋ねずに、自分の時間帯の当番主催者を答えられること。
• キューシートのすべてのセグメントに担当者が明記され、すべてのシフト境界に、各項目の記入または明示的な「なし」が記載された引き継ぎ記録があること。

以下の指標はすべて、達成すべき基準ではなく、主催者が独自に定めるものです。提示する際は、その点を明示してください。

• 移行時の無音時間（独自設定）：あるセグメントの終了から次のセグメントの開始までの秒数。キューシートに台本として記載されていた移行と、記載されていなかった移行を分けて記録します。この比較が、次回に深さの段階を引き上げる根拠となります。
• 当番担当者に届いたエスカレーション（独自設定）：件数を記録し、決して少なく見せないでください。通常、ゼロは何も起きなかったという意味ではなく、スタッフが誰にも連絡できなかったことを意味します。
• 公開済みの混乱時対応順序に従った現場での変更と、その場で即興で行った変更（独自設定）：減らすべきなのは後者です。
• 終了時刻の遵守（独自設定）：確保した分数に対し、実際に実施できた終了後の交流時間の分数と、開始前に帰った人のおおよその人数を記録します。
• キューシートとのずれ（独自設定）：実際には違っていた行。担当者が不在だった、機材が記載場所になかった、セグメントが存在しなかった、などです。定期開催イベントのテンプレートには、この結果が引き継がれます。

2つか3つ選び、それぞれにどの改訂を行うかを書き留め、開催後ではなく開催前に記録してください。

呼び出し例

• 「2日間、3会場で開催するカンファレンスのスケジュールが確定しました。進行表を作成してください。」
• 「当日は誰が無線を持つべきですか。必要なチャンネルも教えてください。」
• 「基調講演者が渋滞にはまり、開始まであと20分です。どうすればよいですか。」
• 「午前と午後の当番オーガナイザー間で、どのように引き継げばよいですか。」
• 「8チームのデモを行うクロージングセレモニーのキューシートを作成してください。」

期待される出力：以下を含む進行表です。

1. 各時間帯の担当者を含む、役割ごとの担当者の明記。
2. 選択した詳細度でのキューシート。各セグメントと各切り替えを1行ずつ記載します。
3. コミュニケーションチャンネルの構成と、その運用媒体。
4. 2つのエスカレーション経路を、シート自体に記載します。
5. 引き継ぎ形式と、変更が反映される箇所。
6. スケジュールの優先順位を引用した、当日のトラブル対応手順。
7. 終了時の手順。
8. 2つの完全性チェックと、選定した指標。

印刷およびブリーフィングの前に、確認のためセクションごとに提示します。

参考資料

• references/cue-sheet-anatomy.md - 成果物としてのキューシートについて、各行に記載する内容、出典に基づく切り替えの仕組みの全容、オープニングセレモニーのコンテンツチェックリストとクロージングセレモニーの仕組み、イベントと形式の出典を含むライブデモの時間配分、キューシートの行の適切な例と不適切な例を解説します。

• references/comms-and-escalation.md - チャンネルを分離するパターンと、それを無線、チャット、電話グループに適用する方法、2つのエスカレーション経路を並べて示し、それぞれの違いを解説します。役割とチャンネルの割り当て例、ライブ時の権限階層に関する業界横断の慣例、独自に定める無線運用ルールも掲載しています。

• references/shift-handoff-protocol.md - ここで採用したオンコールの引き継ぎ構造（重複時間帯、必須記入チェックリスト、別個のインシデント発生中テンプレート、ライブ検証、非同期フォールバック）を、対応関係を明示して解説します。また、適用できない内容と再利用してはならない数値も示します。

• samber/dev-event-organizer-skills@event-schedule-design - この文書で実行するグリッドを作成し、トラブル対応の優先順位を引き継ぎます。ここで再検討することはありません。

• samber/dev-event-organizer-skills@event-speaker-experience - グリーンルーム、テックチェック、現地ホストを担当し、各登壇者の到着時刻と時間上の制約を入力情報として引き継ぎます。

• samber/dev-event-organizer-skills@event-risk-management - 常設のリスク台帳と、シナリオおよび連絡先を記載した印刷用の緊急対応計画を作成します。このスキルのインシデント対応経路はその計画を起動しますが、書き換えることはありません。

• samber/dev-event-organizer-skills@event-production - AV、ステージ、録画の冗長化を設計します。このスキルは、その冗長化が機能しなくなった後にルームリードが行う対応を担当します。

• samber/dev-event-organizer-skills@event-volunteers - ここで入力情報となるシフト計画の作成に向けて、人員の募集、人数の調整、ブリーフィングを行います。このスキルは、当日になってから各担当者が行うことを手順化します。

• samber/dev-event-organizer-skills@event-social-media - 当日のライブ配信を計画します。投稿担当者と撮影ルールはこの文書に記載します。当日に誰も開かない別ページには記載しません。