event-schedule-design

イベントスケジュールの設計

すでに選定されたセッションを物理的なグリッドに配置します。どのトークを何時に、どの部屋で行い、その間に何を入れるかを決めます。入力として使う情報は、次のソースによってすでに決まっています。

• トラック数、イベントの形式、セッション形式の構成、開催形態 - samber/dev-event-organizer-skills@event-format-selection。このスキルは、自身の役割を次のように定めています。「スケジュールの作成は行いません。グリッドのレイアウト、セッションの衝突回避、部屋の収容人数との照合は、samber/dev-event-organizer-skills@event-schedule-design の担当です。シングルトラックにするかマルチトラックにするかは、規模、参加者、コンテンツ構成の方針に基づくため、ここで決定します。その構成にセッションを配置するのは、そちらの担当です。」
• 採択されたトークと、その形式・トラックのタグ - samber/dev-event-organizer-skills@event-talk-selection。
• 登壇者の移動と参加可能な時間帯 - samber/dev-event-organizer-skills@event-speaker-experience が収集し、このスキルがそれらを枠に割り当てます。

公開するグリッドを作成したら、ここでの作業は終わりです。当日にスタッフが分単位で進行する方法や、欠席者や AV の障害に現場で対応する方法については、samber/dev-event-organizer-skills@event-run-of-show を参照してください。

以下の各メニューの順位は、規則ではなく初期設定です。状況や実際に担当する人に応じて変わります。ヒアリングの後、このイベントについて分かったことを踏まえて、3 つのメニューすべての順位を付け直してください。

• 各部屋が細い廊下 1 本につながっている会場。
• 衝突を無料で算出するスケジューリングツールをすでに使用している。
• どの 2 つのトラックで迷ったかを、リピーターが具体的に伝えている。
• 厳守すべき公開日がある。

これらの条件はいずれも、初期設定の順位を覆す可能性があります。

ヒアリング

一度に 1 つ質問してください。可能であれば、選択肢形式にします。質問 4～6 があるのは、以下のメニューで、効果が出るまでの時間、持続性、労力の順位が大きく異なるためです。どの順位を選ぶかは、ユーザーに判断してもらう必要があります。

1. 同時に使用する部屋はいくつあり、何日間にわたって何件のセッションを配置しますか？（この違いによって、以下の内容は大きく変わります。次のセクションを参照してください。）
2. 各部屋について、名前、着席時の収容人数、部屋間の徒歩での所要時間を教えてください。収容人数を考慮せずに作ったグリッドは、当日になって初めて気付く座席計画にすぎません。
3. 会場との契約で決まっていることは何ですか？ 開場・閉場時刻、ケータリングの時間帯、会場の利用開始・終了時刻、1 日の一部の時間しか確保していない部屋はありますか？
4. スケジュールをいつ公開する必要があり、その日付は何のためですか？ チケット販売、旅行の手配、それともスポンサーとの約束ですか？
5. 今回限りの開催ですか、それとも毎年積み重ねていく資産ですか？（継続的な改善を目指す場合は、記録した部屋の入れ替え時間、バージョン管理された公開グリッド、翌年に衝突の問題点が分かるアンケート項目など、効果が出るまで時間のかかる項目の優先順位が上がります。）
6. 労力の上限はどのくらいですか？ 実際にグリッドを作成・管理するのは誰で、何時間かけられますか？ 2 つのセッションが同じ枠を希望した場合、誰が判断しますか？
7. すべての登壇者について参加可能な時間帯を把握していますか？ 複数人で行うセッションの場合、共同登壇者全員の時間帯も把握していますか？ まだの場合は、配置を始める前に確認してください（ワークフローを参照）。
8. どのセッションが固定枠で、自由に動かせませんか？ 基調講演、オープニング、クロージング、スポンサー枠、登壇者が特定の日にしか行えないセッションなどです。
9. メニューの順位を付け直すのに役立つ、すでにある情報は何ですか？ 前回のグリッドと寄せられた不満、記録された時間超過、衝突検出機能のあるスケジューリングツール、廊下の混雑が予想される場所、問題となった衝突を挙げた参加者アンケートなどはありますか？
10. 各部屋で連続する 2 つのセッションの間に、物理的に何を変更する必要がありますか？ AV のリセット、家具の配置換え、ステージの設営などです。
11. 参加者の構成はどのくらい多様ですか？ 開発者のみですか、それとも非技術系の参加者も含まれますか？ また、分野の変化が速いため、数か月前に決めたトークの内容が当日には古くなってしまう可能性はありますか？

単一トラックと複数トラック

このコレクションでよくある、コミュニティ主催かベンダー主催かという区分でも、実際の運営方法は変わりません。どちらの種類のイベントに参加費を払っても、開発者が廊下を歩く速度は同じです。イベントの主催者によって変わるのは採用されるコンテンツであり、会場から人が退出する方法ではありません。

作業内容を本当に左右するのは、複数のセッションが同時に開催されるかどうかです。

• 単一トラック - ツールが想定する意味での競合は発生しません。重複するセッションがないため、競合検出で確認するのは、登壇者が会場内にいるかどうかだけです。会場の収容人数に合わせた割り当ても必要ありません。全員が1つの会場に入るか、イベントの定員を超えるかのどちらかです。設計上の負荷はすべて、進行のペース配分、休憩の配置、余裕時間にかかります。また、1つのセッションの超過はそのトラックだけでなく、1日全体に影響します。
• 複数トラック - 4種類すべての競合が該当し、会場の収容人数に合わせた割り当ては実際の配分問題になります。廊下の通行量も後回しにできない設計上の制約となり、単一トラックの日なら自然に生まれる全体会の時間を、意図的に再構成する必要があります。
• 規模の上限 - 数十の会場がある規模です。FOSDEM 2026では、37の会場と71のトラックで1,079件のイベントが公開されており、グリッドに加えて「トラック別の会場使用状況」の概要も別途公開されています。この規模になると、グリッドは1つの文書では済まなくなり、会場とトラックの対応付け自体が独立した成果物になります。これは目標ではなく、規模の上限のベンチマークとして捉えてください。

推奨内容が異なる場合は、どちらの極を前提としているかを明記してください。

ワークフロー

1. インタビューを実施します。グリッドに手を加える前に、部屋の一覧と収容人数、徒歩での移動距離（Q2）、会場で固定されている時間帯（Q3）を確認します。どちらも調整するのではなく、削除する選択肢です。
2. すべての登壇者の都合がつく時間帯と、複数登壇者のセッションでは共同登壇者の都合がつく時間帯を、配置を始める前に集めます。情報源のある実践では、カレンダーウィジェットを使い、提案時に都合を確認します。フォームで尋ねていない場合は、今すぐ尋ねて回答を待ちます。公開後に都合の不一致が判明すると、公開の訂正が必要になります。この項目をフォームのどこまで詳しく尋ねるかという判断は、samber/dev-event-organizer-skills@event-cfp-designの担当です。
3. セッションの長さを標準化します（下記参照）。そうすれば、各枠を入れ替えられます。何かを移動すると順序を組み直せなくなるため、独自の長さが混在するグリッドに何かを割り当てる前に標準化してください。
4. まず固定枠を配置します（Q8）：オープニング、基調講演、クロージング、開催日が1日に限られるセッションです。それ以外はその周囲に配置します。
5. 昼食と休憩は最後ではなく、次に配置します。複数トラックの日には、各トラックで積み重なった時間のずれをリセットする、全体で再集合するタイミングにもなります。PyCon USでは、専用の大きな部屋を1室使い、9:00～9:45に基調講演を行い、午前中の休憩を10:30頃、昼食を12:30～1:15、午後中盤の休憩を4:00頃に設けています。
6. セッションは、トラックの整然さではなく、想定される参加者数に基づいて部屋に割り当てます（下記参照）。
7. 残りのセッションをグリッドに配置します。複数の採択済み講演が人気の時間枠を取り合う場合は、制約が最も厳しいものから配置します。都合のつく日が1日だけの登壇者を、週を通して都合がつく登壇者より先に配置します（最早納期法によるジョブショップ・スケジューリングから借りた、構成を考えるための類推であり、機械的に適用する規則ではありません）。
8. トラックの開始時刻のそろえ方を選び（下記参照）、一貫して適用します。
9. メニューで選んだ深さで、衝突の検出を実行します。その後の変更のたびに再実行し、最後に一度だけ実行することのないようにします。
10. メニューからバッファを設定し、Q2の徒歩での移動距離と照らし合わせます。
11. 1日全体のペースを読み通し、その読み取りが何を示すものかを明記します（エネルギー曲線に基づくペース配分を参照）。
12. 中断が発生した場合の優先順位をグリッド文書に記載し、samber/dev-event-organizer-skills@event-run-of-showに引き継ぎます。
13. メニューで選んだ姿勢で公開し、グリッドは最終成果物ではなく、更新され続ける文書として扱います。

公開前に、固定枠、休憩、部屋の割り当て、全体のグリッドの順に、セクションごとに提示して検証を受けてください。スケジュールを公開した後は、変更のたびに、以前の予定を前提に計画していた参加者に影響が及びます。

ハーネスに永続メモリがある場合は、以下を記録してください。

• セッションの長さの標準。
• バッファの数値と、それを選んだ理由。
• 実際と異なっていた部屋の収容人数の想定。
• 参加者から報告された衝突。
• この会場の徒歩での移動距離に関する事実。

2回使う会場なら、移動距離を再計測する価値があります。

セッションの長さの標準化

枠の長さを少数に絞り、すべてのセッションがそのいずれかに収まるようにします。異なる規模での、情報源のある事例が2つあります。FOSDEMでは約50分の講演を行い、ライトニングトークは15分以内です。PyCon USでは45分の講演を行います。どちらも長さを標準化しており、独自の長さを選べるメニューは用意していません。

標準化するのは講演ではなく、_枠_です。25分の講演を30分の枠に入れれば、公開する時間の中に入れ替え時間も含まれます。そのため、下記のデフォルトのバッファ段階では、追加の計算が必要ありません。登壇者向けの案内では、講演の長さと枠の長さを分けて記載してください。そうしないと、登壇者は枠の長さを講演時間として使ってしまいます。

部屋と収容人数の割り当て

以下の順に、セッションに部屋を割り当てます。

1. 想定される参加者数。
2. 部屋の隣接性。

どのトラックが大きな部屋にふさわしいかという印象で割り当ててはいけません。これによって防げる問題は、一方向に、そして人目につく形で起こります。部屋の座席数を上回る参加者を集めたセッションでは、来場者が入口で入場を断られます。一方、広すぎる部屋で開催するセッションは、単に閑散として見えるだけです。

手元に実際にある情報を使って、想定規模を見積もります。

• 前回開催時のセッションごとの参加者数。
• コミュニティにおける、そのトピックの集客力。
• フォロワーの多いスピーカー。
• CFP におけるそのトラックの応募割合。

ここでの見積もりはすべて主催者独自のものなので、そのように示してください。参加者が定員を超える可能性が十分にあるセッションには、より大きな部屋を割り当てるか、集客力のある別のセッションと同じ時間帯に配置して、参加者が集中せず分散するようにします。

部屋数が多い場合は、部屋とトラックの対応関係を独立した資料として用意し、時間割から読み取らせないようにします。FOSDEM が独立した部屋使用状況の一覧を用意しているのはそのためです。

以下の 2 つの配置上の工夫も、マルチトラックの時間割の連続性と公平性を保つうえで、ほとんどコストがかかりません。どちらも公開されている取り組みではなく、主催者独自のものです。

• 内容が許す場合は、隣接する枠をトピックごとにまとめます。そうすれば参加者は、セッションごとに部屋を移動せず、連続する 2 つのセッションの間も同じ部屋に留まれます。
• 各トラックで、1 日を通して大きな部屋と小さな部屋を交互に使う場合は、折り返し地点でどのトラックがどちらの部屋を使うかを入れ替えます。そうすれば、特定のトラックの参加者が 1 日中、より条件の劣る部屋に座り続けることがありません。

クラッシュ検出の深さ

実際のスケジューリングツールでは、これを汎用的なフラグ1つではなく、次の4種類の競合として扱います。

• セッションが、その会場の利用可能時間外にある。
• セッションが、登壇者の申告した不在時間と重なる。
• 同じ会場で2つのセッションが重なる。
• 同時開催のセッションに、同じ登壇者が重複して割り当てられている。

複数の登壇者がいるセッションで有効な時間帯は、全登壇者の対応可能時間の_共通部分_です。共同登壇者のうち1人でも対応できない時間に、セッションを設定することはできません。これらはツールがなくても、そもそもツール自体がなくても確認できます。グリッドで表現すべきなのはこの4種類で、スプレッドシートでもすべて管理できます。

優先順位（デフォルトであり、絶対ではありません。Q1、Q6、Q9で順位を付け直します）。

• 労力（新たに収集する必要があるデータ、グリッドを確認する回数、判断の必要性）：参加者の関心の重複チェック > 対応可能時間の確認 > 登壇者の重複予約 == 同じ会場での重複。同率なのはごまかしではなく、議論に基づいています。どちらもグリッドにすでにあるデータを使った単純な計算で、新たな情報収集も判断も必要なく、片方でも両方でも確認は1回で済みます。
• 実際に公開予定どおり開催できるセッションの価値：対応可能時間の確認 > 登壇者の重複予約 == 同じ会場での重複 > 参加者の関心の重複チェック。対応可能時間の確認を最上位にするのは、見落とされやすいためです。登壇者が飛行機に乗っていても、グリッド上には何の問題も見えません。
• 参加者が満足するプログラムの価値：参加者の関心の重複チェック > 対応可能時間の確認 > 登壇者の重複予約 == 同じ会場での重複。この観点があるからこそ、優先されない段階が存在します。機械的な3つの確認で実現するのは、開催できるスケジュールであって、参加者が楽しめるスケジュールではありません。
• 効率性：同じ会場での重複 == 登壇者の重複予約 > 対応可能時間の確認 > 参加者の関心の重複チェック

優越性の確認：4段階、6組、厳密な優越関係はゼロ。これは構造上そうなるように設計した場合にのみ問題がありませんが、構造上の結果は合格の根拠にはなりません。 次の3つの理由で、6組すべてにおいて優越関係が成立しません。

• 参加者の関心の重複チェックと他の3項目との比較は、価値の軸が相反するため成立しません。プログラムの質では最上位ですが、開催できるかという点では最下位です。
• 対応可能時間の確認と2つの計算項目との比較は、労力だけが障害になります。対応可能時間の確認は_両方の_価値の軸で最上位でありながら、より多くの労力がかかります。
• 最後の組み合わせである同じ会場での重複と登壇者の重複予約は、すべての軸で同率のため、どちらかが厳密に優位とはいえません。

この3つの理由はいずれも根拠ではありません。効率性の順位は、以下の議論に基づいています。

• 3つの機械的な確認 — デフォルトでは、同じ会場での重複、登壇者の重複予約、複数登壇者の共通部分を含む2種類の対応可能時間を、1回の確認で調べます。これらを合わせるとツールが自動化できる範囲のすべてをカバーでき、実行コストも低いため、3つすべてを確認しないのは決して適切な節約ではありません。
• 参加者の関心の重複チェック — 優先されない選択肢です。共通の参加者がどちらも参加したいと思う2つのセッションが、同じ時間に組まれている状態です。これを計算する方法はありません。コミュニティをよく知る人がグリッドを確認し、該当する組み合わせを特定する必要があります。プログラムの質を最も高める一方で、最も手間がかかるため、効率性の観点では選ばれません。
  • 優先度を上げる条件：参加者層が明らかに重なる2つのトラック、同時間帯の競合を減らす目的で追加されたトラック、または前回の開催でどの競合が問題だったかをすでに伝えてくれているリピーターの参加者がいること。
• 優先度を下げるのではなく、削除する： 単一トラックのイベントでは、重複の確認と参加者の関心の重複チェックを完全に削除してください。同時に進行するものがないため、有効な確認項目は登壇者の対応可能時間だけです。単一トラックの計画の最下部に複数トラック向けのチェックリストを残しておくと、いつの間にか2つ目のトラックがスコープに再び入り込むことになります。

セッション間のバッファ

順位（デフォルトであり、絶対的な規則ではありません。Q2、Q5、Q9 では順位が変わります）：

• 作業量（グリッドの計算、部屋ごとの記録、消費される日程時間）：部屋の入れ替えを考慮 > 比例方式 > 固定のスロット間ギャップ == スロット内バッファ - 同率とする根拠：どちらも、グリッド全体で使える数値を1つ公開し、設定時に必要な判断も1回です。バッファをスロットの内側に置くか、スロット間に置くかで参加者の受け取り方は変わりますが、計算する内容は変わりません。

• 価値、予定どおりに始まるセッション：部屋の入れ替えを考慮 > 比例方式 > 固定のスロット間ギャップ == スロット内バッファ - どちらでも吸収される分数は同じなので、同じ理由で同率です。

• 価値、参加者が実際に予定に組み込める廊下での交流時間：固定のスロット間ギャップ > 部屋の入れ替えを考慮 > 比例方式 > スロット内バッファ。公開されたギャップは、廊下での会話に使える、目に見える時間です。一方、スロット内に隠れたバッファは無駄な時間に見え、予定を超過した登壇者に使われてしまいます。

• 効率：スロット内バッファ > 固定のスロット間ギャップ > 比例方式 > 部屋の入れ替えを考慮

• スロット内バッファ - デフォルトです。予定しているトークより長いスロットを公開し、両方の時間を登壇者に伝えます。いずれにせよ公開する数値の中にバッファを収めるため、コストはほぼゼロです。

• 固定のスロット間ギャップ - スロット間に設ける、どこでも同じ長さの公開ギャップです。FOSDEM では、09:30-09:50 のオープニング基調講演と、その後に続く 10:00-10:50 のスロットの間に、会場全体で共通の 10 分間のギャップがあります。これは、最大規模での密度とバッファのトレードオフを示す実例として引用してください。推奨値としてではありません。この会場規模では 10 分は短く、1,079 件のイベント数を実現するための設定です。

• 比例ギャップ - 一律の数値ではなく、直前のセッションの長さに対する割合でバッファを設定し、バッファの消費状況を時間どおり／遅刻の二択ではなく、段階的な指標（余裕あり、逼迫、超過）として捉えます。このパターンは製造業の生産スケジューリングに由来します。取り入れるのはパターンのみとし、製造業固有の割合は採用しないでください。50% の設定値と 33/67% の区分の境界は別の領域に由来するため、ここには適用できません。

• 部屋の入れ替えを考慮したギャップ - 優先度の低い選択肢です。部屋ごとに、連続する2つのセッションの間に物理的に必要な変更に応じてギャップを設定します。たとえば、AV のリセット、ワークショップ用のテーブルを劇場形式の列に戻すこと、パネル用の椅子を配置することなどです。このパターンは製造業の生産スケジューリングにおける段取り替えの順序付けに由来し、ペアごとの記録作業が必要なため、予定どおりに開始する価値と作業量の両面で最上位です。

  • Q10 に基づく導入条件：1つの部屋で複数の形式を扱う場合、セッション間にAVの本格的なリセットが必要な会場の場合、または実際の入れ替え時間を一度記録して各開催回で再利用するという継続的な要件がある場合。
  • 手軽に併用できる方法もあります。部屋ごとに同じ形式のセッションを続けて配置し、変更が必要なものを減らします。

• 格下げではなく削除：部屋が異なる階にある場合、または部屋間の移動に数分以上かかる場合は、ギャップなしのグリッドを削除してください。瞬間移動を前提とするスケジュールは、参加者が遅れて到着することで一日中修正されます。そのまま選択肢に残しておくと、日程が長く見えるときに復活するおそれがあります。

トラック開始時刻の調整

ここでは、意図的に順位づけをしていません。同時開始とずらした開始は、決定にも適用にも同じコストがかかります。呼び出しは1回、グリッドの確認は1回で済むため、両者の効率に順位をつけるのは、精度を装っているにすぎません。選択を左右するのは比率ではなく会場です。

• 開始時刻をずらす：同時に部屋を移動すると、廊下が混雑する場合に適しています。PyCon US 2026では、5つのメインルームで開始時刻をずらしており、観測された開始時刻は11:00、11:45、12:30、1:45、2:45、3:30、4:30です。あるトラックが終了すると別のトラックがセッションの途中になるため、人の流れが分散し、一か所に集中しません。開始時刻をずらすと、「すべて正時に開始」というわかりやすいルールを維持できなくなり、セッションの重複を確認する作業も読み取りにくくなります。
• 開始時刻をそろえる：部屋数が少なく、全員が一斉に移動しても滞りなく流れる場合や、全参加者に全体会のタイミングで一緒に集まってほしい場合に適しています。

どちらを選ぶ場合も、全体会の同期ポイントは維持してください。基調講演や昼食のために全トラックが1つの部屋に集まると、各トラックが次のブロックの開始までに積み上げたずれがリセットされます。PyCon USとFOSDEMはどちらも、開始時と終了時に全体会を設け、このようにグリッドの両端を揃えています。

エネルギー曲線に合わせた進行

実績のある主催者は、一日を通してセッション形式と密度を変化させ、一定にはしません。また、墓場の時間帯（構造的に参加者が少なくなりやすい枠）は、製造業のたとえを言い換えたものにすぎないのではなく、明確に認識されている課題です（出典一覧は references/published-schedule-benchmarks.md § Energy-curve pacing and graveyard slots: named sources を参照してください）。

• DevOpsDaysの主催者向けガイドでは、午前中に構成の整った講演を行い、その後に短いIgniteトークを挟み、午後には参加者が自主的に企画するOpen Spaceを行います。これは、構成の強い形式から弱い形式へと移行する、公開された形式の段階づけです。
• 昼食後に注意力が低下する現象は概日リズムによるもので、参加者が何を食べたかとは無関係に記録されています。これは、昼食の直後に内容の濃いセッションを避ける生理学的な根拠です。
• 調査対象となったカンファレンスでは、最終日の最終枠が最も参加者数と参加意欲の低い時間帯であることが、実証的に確認されています。週末の開催日にも、一日全体の規模で同じリスクがあります。

これらの出典が紹介する具体的な手法を2つ挙げます。自分たちのグリッドを読むことに加えて、次の点を確認してください。

• 内容ではなく形式を入れ替える。 DevOpsDaysは、昼食後の内容を避けるだけではありません。形式そのものを入れ替え、講義形式の講演から、参加者が自主的に企画するOpen Spaceへと移行します。枠に合わせて形式を変えることで、参加者の実際のエネルギー状態に逆らわず、適合させます。
• 枠ごとのトラックの欠席率を診断指標として記録する（下記の「測定」を参照）。予想された参加者数を下回った枠を、枠ごと、開催回ごとに記録することで、「ここではどの枠が墓場になるのか」という経験則を、自分たちのイベントで測定できるものに変えられます。

各開催日の最初と最後に、異なる形式の基調講演を設ける

カンファレンスの各開催日は基調講演で始め、基調講演の形式は、その間の講演とは異なるものにします。楽しいパフォーマンス、心を動かすストーリー、芸術的な演目、ライブデモ、ショーなどが考えられます。主催者自身の経験がこれを裏付けていますが、ここでは公開された出典を引用していません。

• 開始時の基調講演。 その日の雰囲気を定め、トラックが分かれる前に参加者を一堂に集めます。珍しい形式にすることで、このイベントが講演の連続とは異なることを伝えます。
• 終了時の基調講演。 一日の終わりを全員で共有し、最後の枠まで残る理由を作ります。上記の墓場の時間帯に関する調査結果から、最終枠は最も弱い時間帯だとわかっています。終了時の基調講演を意図的にその枠に置き、全員が同じ部屋で参加できるようにして、特定のトラックだけに設けないでください。
• 講演とは異なる形式にする。 同じ調子の技術講演をもう1つ加えても、目的を果たせません。出演者には、会場、枠の長さ、その時間帯の参加者のエネルギー状態を事前に伝えてください。
• 固定ポイントを先に配置する。 トラックの枠を埋める前に、他の固定ポイントと合わせて、両端の基調講演を配置してください（Q8）。

自分たちのイベントで確認してください。終了時の枠の参加者数を、終了時の基調講演がなかった開催回の同じ枠と比較します。

1 トラックの夜の深度勾配

混合型の参加者がいる会場での順序ルールです（Q11）。

• 最も幅広い内容の講演から始め、最も高度な講演を最後に配置します。 技術に詳しくない参加者も最初の講演を十分に楽しめ、専門家は最後の講演まで待てます。背景情報を得る前に、誰かが深掘り講演を聞くことになるのを避けられます。
• ファネル型の講演と組み合わせます。 各講演はほぼ全員が理解できる内容から始まり、最後は深い内容に至ります。samber/dev-event-organizer-skills@event-talk-selection の採択概要と、samber/dev-event-organizer-skills@event-speaker-experience のコーチングでこの方針を伝えます。グリッドで決めるのは順序だけです。
• 2 トラックにしない理由：同じ主催者は、技術トラックと非技術トラックに分ける試みを報告しています。ある程度はうまくいきましたが、参加者はどちらの会場に行くか選ぶ際に迷いました。トラック数そのものは samber/dev-event-organizer-skills@event-format-selection で決める事項です。試行の結果はそちらに記載し、グリッドで再検討しないでください。

この勾配は、上記の不人気な時間帯に関する知見と矛盾します。最も高度な講演が、最も条件の悪い時間帯である最後に配置されるためです。専門家が深い内容まで残る夜のミートアップでは、このトレードオフを受け入れ、時間帯ごとの欠席率を確認してください。

references/production-scheduling-concepts.md にある平準化生産計画のたとえは、強度の高い内容を前半に配置することが有効な理由を説明する仕組みに最も近いものです。上記の情報源はその方向性を裏付けていますが、理由には触れていません。また、追加で指摘されている昼食後の落ち込みは、終業前の追い込みというたとえではまったく捉えられない、もう一つのリスク時間帯です。進行の考え方を示す際は、主張が情報源に基づくものか、判断によるものかを明記し、いずれについても数値を作り出さないでください。

登壇者の制約と混乱への対応

会場と登壇者にはそれぞれ異なる利用可能時間帯があり、これは別々の制約です。会場の予約可能時間帯は、登壇者の予定とは異なります。時間枠を割り当てる際は、次の点に従ってください。

• 両方を調整します。
• 複数登壇者のセッションでは、利用可能時間帯の共通部分を採用します。
• 移動時間も利用可能時間帯として扱います。開催当日の朝に到着する登壇者は、1 日の最初の講演を担当できません。

混乱が起きても対応できるようにグリッドを設計し、プレッシャーのかかる状況で優先順位を考え出さなくて済むよう、文書に優先順位を記載してください（製造業の生産計画における混乱時の再配列から借用しています。そこでの連絡方法や固定期間の数値は、この分野には当てはまりません）。

1. まず全体講演または基調講演の時間枠を守ります。
2. 次に、参加者が目当てに来た目玉の企画を守ります。
3. 修正によって影響を受ける他のセッションの数を最小限にします。
4. その時間帯の残りの間は修正後のグリッドを固定し、その日の進行中に何度も並べ替えないようにします。

当日にこの優先順位を適用するのは samber/dev-event-organizer-skills@event-run-of-show の担当であり、このスキルの範囲ではありません。

公開方針

順位（デフォルトであり、絶対的なルールではありません。Q4、Q5、Q9によって順位は変わります）：

• 労力（初回リリース後のメンテナンス、告知の調整）：バージョン管理されたリリース > 早期リリースして反復 > 段階的な公開 > 直前まで確定しない
• 価値、旅行を予約し個人の予定を立てられる参加者にとって：バージョン管理されたリリース > 早期リリースして反復 > 段階的な公開 > 直前まで確定しない
• 価値、告知の機会：段階的な公開 > バージョン管理されたリリース == 早期リリースして反復 > 直前まで確定しない ― 同順位の根拠：どちらも全体の予定表を一度に公開するため、告知の機会はそれぞれ正確に1回です。変更履歴は、再訪者に見える内容を変えますが、告知できる回数は変わりません。
• 効率：早期リリースして反復 > 段階的な公開 > バージョン管理されたリリース > 直前まで確定しない

優越性チェック：4段階、6組、厳密な優越関係はゼロ ― 構成上は問題ありませんが、それだけで合格とは言えません。 次の2つの要因が、6組すべてで優越関係を阻んでいます。

• 労力だけで4組が阻まれています。計画面で価値の高い段階ほど、メンテナンスにかかるコストも厳密に高くなります。これには、価値の面で負け、何のコストもかけずに勝つわけではない「直前まで確定しない」との3組すべての比較と、計画面ではバージョン管理が早期リリースを上回るものの、告知の機会では同順位で、なおコストが高い比較が含まれます。
• 価値の相反する軸により、残る2組が阻まれています。早期リリースと段階的な公開、段階的な公開とバージョン管理の比較です。

このチェックでは、このケースでは何も見つかりません。

• 早期リリースして反復 ― デフォルトであり、出典に基づく指針です。「完璧なスケジュールを待たずにリリースしましょう。早期リリースして反復してください。」公開済みのスケジュールを、その場で改訂される生きた文書として扱います。また、予定表がどれほど頻繁に変わるかを正直に反映する唯一の方針でもあります。
• 段階的な公開 ― まず登壇者と講演を告知し、後から全体の予定表を公開します。手間が少なく、2回目のマーケティング機会を得られます。ただし、参加者は2回目の告知まで旅行の計画を立てられません。
• バージョン管理されたリリース ― 選ばれにくい選択肢です。早期に公開し、さらに変更点がわかる表示も付けることで、予定を立てた人が変更箇所を確認できるようにします。計画面で最も価値が高い一方、継続的な作業として維持する必要があるため、労力も最も大きくなります。採用条件：参加者が個人の予定を組む複数日・複数トラックの予定表、チケット販売後に決まる変更、または参加者が前年と同じ信頼性を期待して戻ってくる、規模が年々拡大するイベントです。
• 降格ではなく削除： 参加者が会場まで旅行する場合、直前まで予定表を公開しない方針は選択肢から外します。開催の2週間前に公開した予定表では、2か月前に予約したフライトの参考になりません。この選択肢を順位の最下位に残しておくと、忙しいプログラム委員長が選んでしまいます。都市内で完結する小規模なミートアップなど、参加のために旅行のチケットを買う人がいないイベントでのみ使えます。

直前まで保留する時事テーマ枠（選択肢には含まれませんが、どの段階にも組み合わせられます）：変化の速い分野（Q11）では、主催者によると、昨年の注目テーマはすぐに古くなります。「後日テーマを発表」とする枠数を主催者が決めて予定表を公開し、イベント直前にsamber/dev-event-organizer-skills@event-speaker-sourcingを使って枠を埋めます。枠、部屋、時間は固定し、講演だけを後から決めます。

失敗パターン

• 複数登壇者によるトークの二重予約。 各共同登壇者の時間枠は確認したものの、重なりは確認していませんでした。重なりを明示的に計算してください。共同登壇者のうち一人でも都合がつかない時間にセッションを配置することはできません。
• 定員の見積もり違い。 セッションの規模を小さく見積もり、小さな部屋に配置した結果、定員を超える来場者が入口で入場を断られました。割り当てる前に規模を見積もり、定員を超える可能性が十分にあるものは大きな部屋に配置してください。部屋が大きすぎても、静かに見えるだけです。
• 開始時刻をそろえたことで廊下が混雑。 会場が受け止めきれない人数が、すべての部屋から一斉に流れ出します。これに対する根拠のある対策は、PyCon USで採用された開始時刻のずらし方です。きっかり時刻に始めるルールを手放す代わりに、廊下の混雑を抑えられます。
• 部屋の入れ替え時間を設けない。 2つのセッションの間に何も物理的な作業が発生しないことを前提としたグリッドを、形式が変わる部屋で使うことです。入れ替えには実際に時間がかかり、必要な時間はセッションの組み合わせによって異なります。
• 借用したヒューリスティックをイベントに関する事実として扱う、または出典のある知見をあらゆる場面に当てはめる。 平準化の類推は製造業に関するものであり、イベントに関するものではないため、そのように明記したままにします。終盤の低調な時間帯や昼食後の落ち込みに関する出典は、実際にイベントや生理学に特化した知見ですが、測定された大きさは経済学のカンファレンスや実験室のデータに基づいており、開発者カンファレンスのものではありません。独自のデータがない限り、数値ではなく傾向を引用してください。
• グリッド作成中にトラック数を再検討する。 グリッドが収まらないからといって、トラックを追加すべきということではありません。その判断はすでに samber/dev-event-organizer-skills@event-format-selection が担い、決定済みです。構築の途中でトラックを追加すると、それに連動していたコンテンツの構成が気づかれないまま変わってしまいます。
• 幅広い層が集まる夜の冒頭に、掘り下げたトークを置く。 最も高度なトークを最初に置くと、その夜の残りの時間、技術者以外の参加者が会場から離れてしまいます。幅広い内容から高度な内容へと並べてください。
• 衝突検出を一度だけ実施する。 変更を加えるたびに、前回のチェック結果は無効になります。公開後の変更も含め、変更のたびに再実行してください。

測定

ここに記載したしきい値は、達成すべきベンチマークではなく、あなた自身が設定するものです。提示する際は、その点を明記してください。

• 部屋ごとの定刻開始率（独自設定）：バッファ内に開始したセッションの割合です。一日中ずれ続ける部屋は、登壇者ではなくバッファの設定に問題があります。
• バッファ消費量の段階評価（独自に設定するしきい値。段階評価の考え方は、製造業のバッファ管理から借用）：各バッファが実際にどの程度使われたかを、定刻／遅刻ではなく、余裕あり／逼迫／超過として評価します。
• 部屋の適合状況（独自設定）：定員を超えたセッションと、ほとんど人が入らなかったセッションの両方を数えます。前者は公の場での失敗、後者は収容能力の無駄です。その比率から、次回の見積もり方法がわかります。
• 公開後の変更回数と最終変更日（独自設定）：グリッド公開後にどれだけ変更があったか、そしてその変更がどれだけ遅い時期に行われたかを記録します。次回、バージョン管理されたリリース段階にコストをかける価値があるかどうかを判断する材料になります。
• 報告された競合（独自設定）：イベント後のアンケートで、参加者がどの2つのセッションのどちらに参加するか迷ったかを尋ねます。効率性を重視した順序付けでは後回しにされる、参加者層の重なりという段階に到達できる唯一の測定方法です。
• 枠ごとの不参加率（イベントスケジューリングのガイダンスで紹介されている手法。記録は各自で行います）：参加が見込まれていた人のうち、実際には来なかった人の割合を、セッション単位ではなく枠の位置ごとに記録します。複数のセッションや開催回にわたって不調な枠は、一般的な枠について公開された情報にかかわらず、あなたの会場における終盤の低調な枠です（上記「エネルギー曲線に沿ったペース配分」を参照）。

この中から2つか3つを選び、それぞれがどのような見直しにつながるかを書き留め、イベントの前に記録してください。

呼び出し例

• 「採択された講演が42件、部屋が4つ、開催日が2日あります。タイムテーブルを作成してください。」
• 「部屋は3フロアに分かれていて、昨年はあらゆる場面で参加者の遅刻がありました。どれくらいのバッファが必要でしょうか？」
• 「2つのトラックの対象者が重なっています。互いに同じ時間帯に組まれないようにするには、どうすればよいでしょうか？」
• 「基調講演者の1人が土曜日の午前11時にしか到着できません。どこに配置すればよいでしょうか？」
• 「スケジュールは今公開すべきでしょうか、それとも確定するまで待つべきでしょうか？」

期待される出力：以下を網羅するスケジュール計画です。

1. セッション時間の標準と、各枠に含まれる内容。
2. 配置した固定枠と、その理由。
3. 休憩と全体同期のタイミング。
4. 各部屋の割り当てと、その根拠となる収容人数の見積もり。
5. 完全なタイムテーブル。
6. 実施した衝突検出の詳細と、その結果。
7. バッファの数値と、照合した移動距離。
8. トラック開始時間を揃えるかどうかと、その理由。
9. 「判断」と明記した進行ペースの評価。
10. samber/dev-event-organizer-skills@event-run-of-show に引き継ぐ、混乱発生時の優先順位。
11. 日付を含む公開方針。

一般公開する前に、セクションごとに提示して検証します。

参考資料

• references/grid-mechanics-and-clash-types.md - 部屋×時間のグリッドモデル、4種類の衝突とそれぞれが検出できるもの・できないものの詳しい説明、部屋の空き状況と登壇者の空き状況の違いおよび複数登壇者の空き時間の重なり、休憩と内部的なブロッカーの違い、枠の割り当てに関する肯定例・否定例。
• references/published-schedule-benchmarks.md - FOSDEM と PyCon US の公開済みスケジュール、混雑への対照的な2つの対応策の比較、エネルギー曲線に基づく進行ペースや閑散枠に関する、主催者および査読済みの情報源、各スケジュールに示されていない内容。
• references/production-scheduling-concepts.md - このスキルが取り入れている製造スケジューリングの概念（段階的なバッファゾーン、安定性ロックを伴う混乱時の再編成、切り替え順序、平準化した進行ペース）。それぞれにおいて対応関係を明示し、適用できない要素と再利用してはならない数値も説明しています。

同じコレクションの関連項目：

• samber/dev-event-organizer-skills@event-format-selection - このグリッドで実施するトラック数、イベント形式、セッション形式の組み合わせを決定します。
• samber/dev-event-organizer-skills@event-talk-selection - 採択された講演と、形式・トラックのタグを提供します。
• samber/dev-event-organizer-skills@event-venue-sourcing - このグリッドを作成する際に使う、座席数、移動距離、契約期間を提供します。
• samber/dev-event-organizer-skills@event-speaker-experience - 枠の割り当てを制約する、登壇者の移動と空き時間に関する条件を収集します。
• samber/dev-event-organizer-skills@event-run-of-show - 当日にこのグリッドを実施します。
• samber/dev-event-organizer-skills@event-cfp-design - 応募フォームの空き時間フィールドと、それを追加する設計上の決定を担当します。