実践的な演出シナリオガイド:必須項目、役割、スタッフへの指示、リハーサル、バージョン管理、代替案。
イベントの演出シナリオは、プログラムを実行可能なアクションの連続に変換します。ステージ上で何が起こるか、どのファイルを再生するか、どこで照明が変わるか、誰がマイクを渡すか、誰が準備完了を確認するかを示します。チームはこれに基づいてイベントを進行し、逸脱が生じた場合には合意した決定を下します。
「Aventura」では、目標、フォーマット、主要ブロックが承認された後にこのようなドキュメントを作成します。まずコンテンツをゲストのアクションと結びつけます。次にトランジション、スタッフへの指示、担当者、資料のバージョン、代替案を追加します。この作業部分のない美しいテキストは、現場のツールではなく単なる文章のままです。
お問い合わせください - 課題について話し合いましょう
イベントの形式を確認し、次のステップをご提案します。
演出台本はプログラムと何が違うのですか?
簡単に言うと:プログラムは参加者に何がいつ行われるかを説明します。文芸台本には台詞と意味のつながりが含まれます。演出台本は舞台進行とスタッフ・技術チームの指示を結びつけます。これらの文書は同じ構成に基づくこともありますが、互いに置き換わるものではありません。
プログラムはゲストにとって便利です。セクション名、時間、会場、スピーカーが記載されていれば十分です。しかし会場運営にはこれだけでは不十分です。技術チームには、どの合図で映像が始まり、どのマイクがオンになり、いつ照明が変わり、最後の映像の後に何が続くのかを知る必要があります。
司会者の台本もこの課題を解決しません。「それではディレクターがステージに上がります」というフレーズは、コーディネーターにスピーカーの準備ができているかを知らせません。ビデオエンジニアには映像の名前を伝えず、音響オペレーターにはマイクを開くタイミングを指定しません。そのため、私たちはプロジェクト全体を1つの文芸台本ファイルにまとめようとはしません。
表にはセクションの主要項目がまとめられています:文書、主な問い、主なユーザー。イベント準備の際のクイックリファレンスとしてご利用ください。
| 文書 | 主な問い | 主なユーザー |
|---|---|---|
| プログラム | 参加者が何を見るか | ゲスト、クライアント、スピーカー |
| 司会者の台本 | 何が語られるか | 司会者、編集者、クライアント |
| 演出台本 | 誰がどの合図で動くか | ディレクター、コーディネーター、技術チーム |
| 技術リスト | 必要な設定とリソース | 専門技術チーム |
フォーラムやカンファレンスでは、演出台本はビジネスイベント運営の全体システムの一部となります。プログラム、会場、ステージ、受付、参加者の行動をつなぎます。
マスター行の構成
要約: マスターシナリオの各行は、1つの管理ポイントを記述します。識別子、予定時刻、ステージ上のアクション、音響・映像・照明のコマンド、担当者、準備基準、バックアップが含まれます。フィールドは調整可能ですが、チーム内で行の共通理解を維持する必要があります。
私たちは「キュー」という概念を使用しています。これは特定のアクションが開始されるポイントです。ロシア語では実務上「コマンド」または「シグナル」に相当します。QLabのドキュメントでは、キューリストは音響、映像、照明などのアクションのコマンドシーケンスとして機能します。特定のプログラムは必須ではありません。各コマンドの番号と意味が明確であれば、表形式でも機能します。
最小限のマスター行には以下が含まれます:
- キュー番号。 時間がずれても変わらない安定した識別子。
- 予定時刻と長さ。 これにより、前進または遅延を確認できます。
- ステージ上のアクション。 誰が入場し、話し、手渡し、見せ、退場するか。
- 台詞または意味的なシグナル。 次のアクションの開始ポイントがあれば十分です。
- 音響。 マイク、トラック、音量、チャンネルの開閉。
- 映像。 ファイル名、バージョン、ソース、表示後のアクション。
- 照明。 状態、強調、暗転、またはトランジション。
- コマンドと受信者。 誰がシグナルを出し、どの部署がそれを確認するか。
- 準備ステータス。 ファイル、スピーカー、小道具、バックアップが確認済みかどうか。
- プランB。 条件が満たされない場合にチームが行うこと。
私たちは音響、照明、映像を「技術」という列にまとめません。共通のセルは記載を速くしますが、現場での作業を複雑にします。各部署は自分のアクションと隣接するコマンドとの関連をすばやく確認できる必要があります。
会場でのドキュメント管理は誰が行うのか?
要約: マスターバージョンには単一の所有者が必要です。通常、演出家または任命されたショーコーラーが承認済みの台本に沿って指示を出します。プロデューサーはプロジェクトのリソースと決定を管理し、コーディネーターは人員と小道具を準備し、技術責任者はそれぞれの担当範囲で実行に責任を負います。
役職名はプロジェクトごとに変わります。決定的なのは決定権です。設営前にチームは、誰が順序を変更できるか、誰がブロックの短縮を承認するか、誰が舞台上のアクションを停止する権限を持つかを確定します。指揮権が優先順位なく複数の人に分散していると、コントロールデスクは矛盾した指示を受けることになります。
この表には、このセクションの主要なポイントがまとめられています:役割、イベント前、プログラム中。イベント準備の際のクイックリファレンスとしてご利用ください。
| 役割 | イベント前 | プログラム中 |
|---|---|---|
| プログラムの発注者 | 内容と決定の範囲を承認する | 確立されたチャネルを通じて内容の変更を受け入れる |
| プロデューサー | リソース、スケジュール、請負業者を集める | 組織上の障害を取り除く |
| 演出家 | プログラムを舞台アクションに変換する | マスター台本と指示を管理する |
| ステージコーディネーター | 人員、小道具、登場を準備する | 演出家に準備完了を確認する |
| 技術責任者 | 図面と各部署の任務を確認する | 音響、照明、映像の実行を調整する |
| 司会者 | 台本とつなぎを準備する | 承認された文言を話し、演出家と連絡を保つ |
大規模なカンファレンスでは、この体制がさらに拡大します。各会場の演出家、スピーカーコーディネーター、プレゼンテーション編集者、そして専任の配信チームが登場します。このようなプロジェクトでは、全体プログラムと各会場が単一のバージョン管理台帳で結ばれるカンファレンス運営の枠組みを利用します。
お申し込みください - 課題についてご相談ください
イベントの形式を確認し、次のステップをご提案します。
バージョン、ファイル、最終修正
要約: マスター台本は一か所に保存され、目に見えるバージョンを持っています。各メディア資料には安定した名前と確認ステータスが付与されます。作業バージョンが凍結された後、緊急の修正は一人の所有者が受け付け、影響を受けたキューに印を付け、すべての部署からの確認を受けます。
最終段階での主な問題は、修正の経路に関連することが多いです。クライアントはプレゼンテーション内の氏名を変更し、司会者はメッセンジャーで台詞を修正し、ビデオエンジニアは第三者を通じて新しいファイルを受け取ります。結果として、それぞれが自分のコピーに対しては正しく行動していますが、バージョンが一致しません。
私たちはシンプルなルールを設けています:修正の通知は、実装された修正とはみなされません。変更はマスターバージョンに反映され、タイムスタンプを取得し、具体的な担当者に届く必要があります。受信者は新しいバージョンを確認し、行動を理解したと返答します。
ファイルには統一された命名規則が有効です:セクション、キュー番号、内容、バージョン。単語 final は、隣に final2 や final_new があると役に立ちません。正確な規則は会社によって異なりますが、日付、バージョン番号、所有者はファイルを開かなくても確認できるべきです。
プログラム開始後、自由な編集を制限します。緊急の修正は短いサイクルで行われます:
- コンテンツ所有者が変更内容を明確にします。
- ディレクターが影響を受けるアクションとリスクを評価します。
- マスターバージョンを一か所で更新します。
- 各部署は新しいバージョン番号と自分たちの変更点を受け取ります。
- 各部署が準備完了を確認します。
- ディレクターが、そのバージョンが有効になる時点を指定します。
ステップごとにシナリオを組み立てる方法
要約:作業はイベントの結果から始まり、セリフからではありません。その後、チームは参加者の旅をエピソードに分解し、責任者を割り当て、舞台や技術的なアクションを追加し、つなぎ目を確認し、その後に初めて司会者のテキストを書き上げます。この順序により、美しい表現が制作上の欠陥を隠すことを防ぎます。
まず、お客様に次のフレーズを完成させていただきます:「このブロックの後、参加者は...」。答えは観察可能な行動を記述する必要があります。参加者はルールを理解し、質問をし、ルートを選び、製品を見て、書類に署名し、または次のゾーンへ移動しました。「感動した」という表現はコンセプトに残しても構いませんが、そこからチームを構築することはできません。
その後、プロセスは次のようになります:
- 目標と境界を固定します。イベントが何を変えるべきか、何がその結果に関係しないか。
- 参加者のルートを構築します。入場、待機、主要ブロック、移行、フィナーレ、退場。
- ルートをエピソードに分割します。1つのエピソードには明確な入口と出口があります。
- 各結果の責任者を任命します。彼は内容と準備状況を確認します。
- 舞台アクションを追加します。登場、小道具、配置換え、司会者の仕事。
- サービスチームのコマンドを追加します。音響、映像、照明、配信、通信。
- アクセシビリティと安全性を組み込みます。これらの要件は時間と行動の順序に影響します。
- バックアップを準備します。ファイル、マイク、スピーカー、移行の交換。
- リハーサルでつなぎ目を確認します。実際の通し稽古に基づいてシナリオを修正します。
すべての行が同じ詳細度を必要とするわけではありません。ウェルカムコーヒーは大きなブロックとして記述できます。舞台のオープニング、賞の授与、リモートスピーカーの起動、ビデオの上映には個別のcueが必要です。詳細度は、責任、技術、リスクが変わる場所で高まります。
トランジション、キュー、各部門へのコマンド
簡単に言うと: コマンドは短く、明確な宛先があり、検証可能でなければなりません。まず各部門が準備完了を確認し、次にディレクターがアクションの合図を出し、実行後に明確なステータスが返されます。「その後」のような相対的な表現は、キュー番号、アンカーとなるセリフ、または目に見えるイベントに置き換えられます。
作業手順は、準備、警告、開始の3段階で構成されます。例えば:コーディネーターがスピーカーが入口にいることを確認し、ビデオ担当がオープニング映像の準備完了を伝え、音響担当がマイクの確認をし、ディレクターが各部門に次のキューを警告し、最終セリフに合わせて登場とスクリーン表示を開始します。
コマンドは演劇的に聞こえる必要はありません。必要なのは明確さです。「ビデオ32、準備」は番号と部門を伝えます。「ビデオ32、開始」はアクションを指示します。「準備完了、始めます」では、誰が何をすべきかが明確になりません。
複雑なシーンでは、中止の基準を設けることが有効です。スピーカーがまだ出口にいない場合、ディレクターはトランジションを保留し、司会者は合意されたつなぎの言葉を使用します。ファイルが確認されていない場合、ビデオ担当は予備のオープニング映像を開始します。リモート参加者との接続が失われた場合、モデレーターは次の質問やセクションに進みます。
音響には特別な注意が必要です。Shureはサウンドチェックを行い、事前に専門家とマイクの種類と位置を確認することを推奨しています。台本では、特定のチャンネル、伝送方法、担当コーディネーターを明記します。完全なスキームのためには、技術サポートおよび音響の個別サービスが必要になる場合があります。
役立つ実用的なフレーズ:
- 「ステージ確認:スピーカーは出口にいます、マイクは装着済みです」;
- 「ビデオ18準備完了、最初のフレームがプレビューに表示されています」;
- 「ライト12、全体照明の準備をしてください」;
- 「司会者の「始めます」の合図で:ビデオ18とライト12、開始」;
- 「キュー21を保留、司会者は予備の質問に進みます」.
制作現場の観察やイベント事例のまとめは、AventuraのTelegramチャンネルでも公開しています。
演出リハーサルでは何を確認すべきか?
要約: リハーサルは、重要なシーンや、人・コンテンツ・技術の間のつなぎ目を確認します。チームはオープニング、複雑な出入り、メディア素材、表彰、中継、フィナーレ、そしてバックアップをリハーサルします。各エピソードの後、マスタースクリプトに決定事項、担当者、新バージョンを記録します。
司会者の台本をテーブルで読むことは編集者にとって有益ですが、現場での作業に代わるものではありません。演出家は実際の距離、視界、転換の速さ、連絡の聞こえ方を確認する必要があります。スピーカーは入場、マイク、停止位置を試す必要があります。技術スタッフは実際の順序でコマンドを実行する必要があります。
まず短いブリーフィングから始めます。参加者全員が台本のバージョン、連絡チャンネル、リハーサルを停止する権利を把握します。次に、観客に気付かれるミスや安全に影響するシーンを確認します。常にフルリアルタイムのリハーサルが必要なわけではありません。形式的に全プログラムを通すより、複雑なトランジションを2回繰り返す方が有益な場合もあります。
リハーサルのチェックリスト:
- オープニング:最初の合図、音楽、照明、スクリーン、司会者の登場。
- スピーカー:動線、マイク、スライド、タイマー、退場。
- メディア素材:ファイル名、最初と最後のフレーム、音声、次のキュー。
- 転換:誰が家具や小道具を出し入れするか。
- インタラクティブ:参加者への指示、デバイスのテスト、反応が低い場合の対応。
- 表彰:人、物、写真、退場の順序。
- ハイブリッド:通信、遅延、予備チャンネル、モデレーターの役割。
- フィナーレ:全体集合、謝辞、音楽、スクリーン、退場経路。
- バックアップ:エピソードのスキップ、ファイル、マイク、スピーカーの代替。
- 停止:誰が決定し、誰が観客に話すか。
リハーサル後、変更は台本に反映されます。共有チャットに手書きメモの写真を投稿しても、新しいマスターバージョンの代わりにはなりません。接続リハーサルの手順の詳細は、イベントのテクニカルリハーサルの記事で解説しています。
バックアップ対応とプログラムの停止
要約:通常の不具合、演出上の一時停止、安全上のショーストップにはそれぞれ異なる対処が必要です。起こり得る逸脱に対しては、予備対応と中立的なアナウンスを用意します。プログラムを停止する権限、通知手順、専門チームへの引き継ぎは、イベント前にセキュリティ計画で定めます。
スピーカーの遅刻には、モデレーターの質問を用意します。プレゼンテーションの破損には、バックアップのPDFを。ヘッドセットの故障には、ハンドマイクを。動画が利用できない場合は、静止画のスプラッシュと司会者の短いつなぎを用意します。このようなバックアップはシームレスさを保証するものではありませんが、問題解決までの時間を短縮します。
HSEは事前にショーストップについて合意することを推奨しています:主要担当者、コミュニケーションチャネル、参加者への連絡方法、アナウンスの文言を決めておきます。通信システムはイベント前に確認すべきです。これらのルールは安全に関わるものであり、創造的な即興に埋もれてはなりません。
マスターシナリオでは、緊急時計画全体を書き直すのではなく、別途定めた手順への参照を記載します。各行には「停止条件」「確認者」「参加者へのメッセージ」「管理移管ポイント」などのフィールドを設けることがあります。具体的な閾値や役割は、会場、クライアント、専門スタッフが決定します。
ハイブリッドとアクセシビリティをどう考慮するか?
要約:ハイブリッドとアクセシビリティはプログラムの進行そのものを変えます。シナリオでは、リモート参加者に役割を与え、必要に応じて字幕や通訳を用意し、マイクの受け渡し時間を確保し、ステージまでのアクセシブルな経路を記述する必要があります。「アクセシビリティを考慮する」という一般的な注記だけでは不十分です。
W3Cは、事前に特別な要件を尋ね、入口、会場、ステージ、トイレのアクセシビリティを確認し、マイクとスピーカーの視認性を確保することを推奨しています。資料は、参加者、通訳者、字幕担当者に事前に渡すべきです。
シナリオでは、これらの要件が具体的な記述になります。コーディネーターは通行可能なルートを確認します。司会者は回答前に質問を繰り返します。ビデオエンジニアは字幕ファイルを受け取ります。カメラはスピーカーや通訳者の顔が見えるように保ちます。モデレーターはリモート参加者に明確な参加方法を提供し、会場に声が聞こえていることを確認します。
ハイブリッドブロックでは、以下を個別に記述します。
- 接続チャネルとバックアップ。
- 本番前の通信確認。
- リモート参加者の準備完了シグナル。
- 会場向けの表示と配信向けの表示。
- 会場とオンライン間での質問の受け渡し。
- 遅延や接続喪失時の対応。
- ブロック終了後の資料へのアクセス。
撮影もシナリオに明記される必要があります。民法第152.1条は、個人の肖像の公表およびその後の使用を規制しています。この規定には例外がありますが、企業の出版物すべてに自動的に適用されるわけではありません。規則と書式はクライアントの弁護士が確認し、ディレクターチームは承認された手順を実行します。
スタートのための最小パッケージ
要約:最初の見積もりには、イベントの目的、対象者、形式、会場または会場への要件、ドラフトプログラム、スピーカー、メディア資料、技術設計、承認ルール、制約が必要です。データの一部がまだない場合は、ギャップを隠すのではなく、責任者と決定日を任命することが重要です。
最初のブリーフィングでは、シナリオと予算に影響する質問をします:
- 各主要ブロックの成果として、参加者のどの行動を結果とみなしますか?
- 内容、ステージング、技術スキームを承認するのは誰ですか?
- どのスピーカー、アーティスト、リモート参加者がすでに確定していますか?
- どのプレゼンテーション、動画、音楽、グラフィックが必要ですか?
- ライブ配信、録画、字幕、翻訳は必要ですか?
- 表彰、署名、デモンストレーション、小道具、配置換えはありますか?
- 会場と安全に関する既知の要件は何ですか?
- 参加者はアクセシビリティ要件をどのように報告しますか?
- 最終修正を承認するのは誰で、作業版はいつ確定しますか?
- 重要なエピソードに必須のバックアップ案は何ですか?
チームとドキュメントの構成は規模によって異なります。小規模な社内イブニングはコンパクトな表で管理できます。多ホールフォーラム、オープニングセレモニー、ライブ配信では、各部門の子シートや各系統の専任ディレクターが必要になります。どの場合でも、マスターバージョンは統一された番号付けと責任者を保持する必要があります。
専任ディレクターは、プログラムに複数の部門、正確な出番、メディアコンテンツ、ステージ転換、ライブ配信、またはミスによる評判リスクが高い場合に必要です。イベントが演出上の転換のない単一のミーティングで構成される場合は、機能の一部をプロデューサーやコーディネーターが担うことができます。判断はゲスト数ではなく複雑さに基づいて行われます。
よくある質問
簡単に言うと: プログラムは参加者に何がいつ行われるかを説明します。台本(リテラリースクリプト)にはセリフと意味的なつながりが含まれます。演出台本は舞台上のアクションを人々と技術スタッフへの指示に結びつけます。これらの文書は同じ構造に基づくことがありますが、互いに置き換わるものではありません。
簡単に言うと: マスター台本の各行は1つの管理ポイントを記述します。そこには識別子、予定時刻、舞台上のアクション、音響・映像・照明への指示、担当者、準備基準、予備が含まれます。フィールドは調整可能ですが、チームは行について共通の理解を保つ必要があります。
簡単に言うと: マスターバージョンには1人の所有者が必要です。通常、演出家または任命されたショーコーラーが承認された台本に基づいて指示を出します。プロデューサーはリソースとプロジェクトの決定を管理し、コーディネーターは人員と小道具を準備し、技術責任者はそれぞれの範囲での実行に責任を負います。
簡単に言うと: マスター台本は一か所に保管され、バージョンが明確に示されます。各メディア素材には安定した名前と検証ステータスが付与されます。作業バージョンが凍結された後、緊急の修正は1人の所有者が受け付け、影響を受けるキューをマークし、すべての部門から確認を取ります。
簡単に言うと: 作業はセリフからではなく、イベントの成果から始まります。その後、チームは参加者の動線をエピソードに分解し、所有者を割り当て、舞台上および技術的なアクションを追加し、接続点を確認してから、ようやく司会者の台本を書き上げます。この順序により、美しい表現が制作上の問題を隠すことを防ぎます。
簡単に言うと: 指示は短く、対象が明確で、確認可能でなければなりません。まず部門が準備完了を確認し、その後演出家がアクションの合図を出し、実行後に明確なステータスを受け取ります。「その後」のような相対的な表現は、キューナンバー、アンカーとなるセリフ、または目に見えるイベントに置き換えられます。
出典
- HSE: Getting started with event safety
- HSE: Planning for incidents and emergencies
- W3C WAI: Making Events Accessible
- QLab 5 Documentation: The Workspace
- Shure: A Basic Guide to Presentation Microphones
- ロシア連邦民法第152.1条:市民の肖像の保護
目次
この記事は役に立ちましたか?
