event-planning-timeline

イベント計画のタイムライン

技術イベントのスケジュール戦略を立てる役割です。開場日時を起点に今日まで逆算し、並行する各トラック、逆算して設定したマイルストーン、トラック間の依存関係に基づくゲート、明示的なバッファ方針、そして遅れが危機になる前に再計画を促すチェックポイントをつなぐ、数か月にわたる作業計画を作成してください。

このスキルは、あらゆる開催回に共通する仕組みを扱います。

• 日程そのものではありません。その決定は samber/dev-event-organizer-skills@event-date-selection が担います。
• 初開催に必要な、情報源に基づく準備期間や立ち上げゲート、形式に応じた2つの名前付きタイムライン案は対象外です。それらは samber/dev-event-organizer-skills@event-first-edition が担います。対象の形式に実際どれほどの準備期間が必要かを確認し、その準備期間にこのスキルの仕組みを適用してください。
• 当日そのものではありません。分単位の進行表は samber/dev-event-organizer-skills@event-run-of-show が、技術面の実行は samber/dev-event-organizer-skills@event-production が担います。

インタビュー

一度に1つ質問してください。可能な場合は選択肢を提示してください。質問3〜5があるのは、以下の選択肢が効果の現れる速さ、持続性、労力で大きく異なるためです。デフォルトの優先順位を、ユーザーに代わって選ぶことはできません。

1. 今回は何回目の開催ですか。初開催ですか、それとも定期開催ですか。（初開催の場合 → 情報源に基づく準備期間、チームのゲート、立ち上げ特有のリスクは samber/dev-event-organizer-skills@event-first-edition が扱います。このスキルは、その基盤となるスケジュール策定の仕組みを提供します。）
2. 開場日時は決定し、確定していますか。（未確定の場合 → まず samber/dev-event-organizer-skills@event-date-selection を参照してください。基準となる日時がなければ、逆算した作業計画は立てられません。）
3. 日程以外に、動かせない外部の締め切りはありますか。会場契約の期間、スポンサーの会計年度における予算サイクル、同時開催される主要イベント、イベント日程とは別のカレンダーで進む助成金の申請期間などです。（外部の厳守すべき締め切りがある場合、より細かな計画と早めのチェックポイントが必要になります。）
4. 今回限りの開催ですか。それとも、価値が積み上がる毎年の資産の一環ですか。（価値を積み上げる方針がある場合、信頼を損なう施策のコストが高まります。日程の変更や、目に見えるプログラムの縮小は、単発イベントより定期開催のイベントに大きな損失をもたらします。）
5. 労力の上限はどれくらいですか。主催者の週あたりの作業時間、人数、有給スタッフとボランティアの内訳、そして約束をどの程度柔軟に変更できる必要があるかを教えてください。
6. すでに確定済み、または進行中のものは何ですか。会場の契約、CFPの受付開始、チケット販売、日程の発表などですか。（新規計画か進行中の計画の見直しかを判断し、すでに使えない施策を見極めます。発表済みの日程は、もはや変更可能な変数ではありません。）
7. 現在、各トラックの担当者は誰ですか。また、担当者がいないトラックはどれですか。
8. 以下の選択肢の優先順位を見直すべき材料はありますか。前回の実際の日程と遅延状況、継続的な会場との関係、契約を継続している代理店や制作パートナー、すでに週次チェックインを運営しているチームなどです。
9. 今回は複数の会場を使いますか。署名済みの契約に違約条項はありますか。
10. まだ確保できていない収益に予算が依存していますか。

コミュニティ主催と企業主催

このプレイブックを変える違いは、イベントの人員と資金を誰が提供するかです。（この枠組みは samber/dev-event-organizer-skills@event-first-edition に沿っています。以下の調整は、公開されているイベント業界の事実ではなく、この違いに基づく推論です。）

• コミュニティ主催：制約となるのはボランティアの作業時間です。計画の粒度は粗めにします（更新する時間がない計画は、粗くても常に最新の計画より劣ります）。再計画の主な手段はスコープの縮小です。また、資金に余裕がないため、コミットメントを遅らせることが特に重要です。
• 企業主催：スタッフの作業時間と予算に余裕があるため、どちらの制約も緩和されます。定期的なレビューは低コストで実施でき、再計画の選択肢には、コミュニティ主催のイベントにはない手段も加わります。特急料金、請負業者、代理店への支出で遅れを取り戻すことです。資金で取り戻せるのは実行上の遅れであり、カレンダー上の制約ではありません。短縮されたCFP期間や会場探しの期間は、短縮されたままです。

推奨内容が異なる場合は、どちらの形態を前提としているかを明示してください。逆算による計画の仕組み自体は、どちらにも適用できます。

トラック：並行作業の単位

プロジェクトを並行するトラックとしてモデル化し、それぞれに独自の逆算マイルストーン・チェーンを設け、明示的なゲートのみを介して接続します。時系列のリストを1つ作るだけでは、どの遅れが何を妨げるのかが見えません。トラック表示ならそれが分かります。分類はイベントの規模に合わせて絞り込みます。ミートアップ規模のイベントにはCFPトラックはありません。

1. 会場とロジスティクス：検索 → 候補の絞り込み → 確定 → 契約 → 準備計画。
2. プログラム：CFPの設計 → 募集開始 → 募集終了 → 選考 → 登壇者の確定 → プログラムの発表。
3. スポンサーとパートナー：予算に基づく目標設定 → 提案資料 → アプローチ → 合意 → 履行。
4. マーケティングと広報：告知計画 → チャネルの設定 → 継続的な告知 → 最終告知。
5. チケット販売と登録：決済インフラ → 価格設定 → 販売開始 → 早期割引の終了 → 最終参加者数。
6. 予算と財務：予算案 → ティアの定義 → 収益チェックポイント → 支払期限。
7. チームとボランティア：トラック責任者の確定 → 委任 → 当日のボランティア配置。

各トラックのマイルストーン・チェーンと、出典付きの事例を含むトラック横断のゲート一覧については、references/tracks-and-gates.mdを参照してください。

タスクの表現と時間区分

計画自体を、どの粒度で運用する場合でも検証・再利用できるようにするため、独自の規約を2つ定めます。

• すべてのタスクは、指示ではなく完了した状態として記述します。「CFPフォームが公開されている」なら一目で真偽を判断できます。一方、「CFPフォームを設定する」では、完了とみなすかどうかを読む人が自分で判断することになります。
• タスクは暦の日付ではなく、開場までの相対的な時期で区分します。「S-4」（4週間前）の下に記載したタスクは次回開催でもそのまま使えますが、固定の日付で記載したタスクは、再利用する前に書き直す必要があります。トラック責任者が自分の担当分だけに絞り込めるよう、各タスクには上記のトラックもタグ付けします。

計画の粒度

順位（デフォルトであり、絶対的なルールではありません。特に労力の上限や過去の開催回の資産について、インタビューの回答を踏まえて順位を付け直してください）：

• 労力（週あたりの準備と維持）：タスクレベルのクリティカルパス > 依存関係で制約されたマイルストーン計画 > マイルストーンのみの計画
• 価値（遅れが連鎖する前に検知できる度合い）：タスクレベルのクリティカルパス > 依存関係で制約されたマイルストーン計画 > マイルストーンのみの計画
• 効率：依存関係で制約されたマイルストーン計画 > マイルストーンのみの計画 > タスクレベルのクリティカルパス

優越性のチェック：3つのペアに、厳密な優越関係はありません。構成上そうなるだけであり、構成上の結果は決して合格とはみなせません。

• 価値と労力は同じ順位なので、すべてのペアで同じ仕組みが働きます。より細かい計画ほど遅れを多く検知できますが、準備と維持には明らかにより多くの労力がかかります。

• 第3の軸は示されていません。

• このチェックでは順位の誤りは検出されません。順位は以下の根拠に基づいています。

• 依存関係で制約されたマイルストーン計画：標準となる段階であり、このスキルの中核となる成果物です。各トラックのマイルストーンをおおむね月単位で設定し、トラック間のゲートと、コミットできる最終安全日を加えます。マイルストーンの一覧だけでは見落とされるのが、これらのゲートです。

• マイルストーンのみの計画：主催者が1人か2人で、取り消し不能なコミットメントが少なく、すべての依存関係を一人で把握できる小規模なイベントでは、この段階に下げます。

• タスクレベルのクリティカルパス：選択肢の中では最も負担が重いものです。すべてのタスクを分解し、各タスクに担当者を割り当て、毎週ベースラインを引き直します。これはイベント運営の実務ではなく、一般的なプロジェクト管理（クリティカルパス法）を転用したものです。昇格条件（Q5またはQ9に基づく）：有給の制作スタッフ、複数会場の調整、または契約上の違約金条項がある場合、見逃した遅れのコストは計画の維持コストを上回ります。

Q5の上限が、本業の合間に活動するボランティア主催者1人か2人である場合は、常にタスクレベルのクリティカルパスを降格させるのではなく、削除してください。

• この選択肢から削除し、上の各軸の行からも削除してください。
• これはマイルストーン計画のより綿密な版ではありません。週ごとの維持に、実際に確保できる時間を超える計画です。
• 気づかないうちに機能しなくなります。チームが、ベースラインを引き直していない日付を信頼し続ける一方で、1か月も経たないうちに陳腐化します。
• リストの最後に置いておくと、誰かに午後の空き時間ができた週に、また候補に上がります。

どの段階にも当てはまる警告です。大規模なハッカソン主催者ネットワークのガイドによれば、チーム全体が実際に使い続ける最もシンプルな共有トラッカーのほうが、精巧なトラッカーより優れています。計画の粒度を決めるのは、計画担当者の意欲ではなく、チームが更新に応じる意思です。

バッファ方針

これらは組み合わせて使います。ランキングが示すのは、どれを最初に導入するかであり、どれか一つだけを選ぶべきという意味ではありません。ランキングはあくまでデフォルトであり、絶対的なルールではありません。労力の上限（Q5）と、すでに保有している資産（Q8）に照らして並べ替えてください。継続的に利用できる会場やケータリング業者との関係があれば、直前の確定にかかるコストは下がります。また、前回の開催で費用を算出したスコープの段階案があれば、ほぼ手間なく再利用できます。

• 労力（効果が出る前に必要な計画作業）：scope-tier ladder > delayed commitment > milestone padding
• 価値（信頼を損なわずに吸収できるショック）：scope-tier ladder > delayed commitment > milestone padding
• 効率：delayed commitment > scope-tier ladder > milestone padding

優越性チェック：3組を比較し、厳密な優越関係はゼロです。これは構成上そうなるだけであり、合格を意味するものではありません。

• 価値と労力の順位は同じなので、すべての組み合わせが同じ理由で失格です。より多くのショックを吸収する方針ほど、効果が出る前の計画により多くの労力がかかります。

• これ以外に、組み合わせを阻止したり、救済したりする要素は示されていません。

• 効率の順位は、以下の論拠に全面的に依存しています。

• Delayed commitment：デフォルトの段階であり、出典に基づく手法です（大規模なコミュニティカンファレンスの運営ガイドにあるコスト管理の助言）。取り消せない支出や人数の決定には、最も早く決められる日ではなく、決定を保留できる最終日を設定し、その日まで保留します。誤りの影響は一方が他方より大きくなります。食事、座席、ノベルティは直前でも安価に追加できます。一方、前払いの取り消しや過剰発注の修正には、高い費用がかかるか、そもそも不可能です。

• Scope-tier ladder：優先度を下げた選択肢で、同じガイドに基づいています。チケットを販売する前に、イベントの「Good／Better／Best」版を定義し、実際に受け取った収益に基づく日付入りの縮小判断チェックポイントを設けます。イベントを中止せずに収益不足を吸収できるため、価値は最も高くなりますが、事前にイベントの3つのバージョンを設計する必要があります。Q10に基づく昇格条件：予算が、まだ確保されていない収益に依存していること。スポンサー資金で運営するイベントでは、通常これに該当します。

• Milestone padding：マイルストーンと期限の間に設ける単純な時間的余裕です。ビザ、印刷、配送、会場の書類手続きなど、チームが管理できないリードタイムに限って使います。それ以外のあらゆる場面では、余裕はいつの間にか消費されます。全員が余裕を加えた日付に合わせて計画するため、誰も使う判断をしていないのにバッファがなくなります。

Delayed commitmentは、直前に単一の項目を縮小します。スコープの段階案は、チェックポイントでイベント全体の範囲を見直します。この2つは別々のツールとして提示し、「予備を用意する」という一つの箇条書きにまとめないでください。

再計画のトリガー

評価（デフォルトであり、絶対ではありません。スタッフが運営するイベントでは、上位の段階へ再評価します）：

• 労力（継続的な調整コスト）：頻度に応じた差異レビュー > 事前に記述したチェックポイント > イベント駆動型の再計画

• 価値（ずれの早期発見と、ストレス下での意思決定の質）：事前に記述したチェックポイント > 頻度に応じた差異レビュー > イベント駆動型の再計画

• 効率：事前に記述したチェックポイント > イベント駆動型の再計画 > 頻度に応じた差異レビュー

• 事前に記述したチェックポイント：デフォルトの段階です。出典のある仕組み（同じガイドに記載された、日付ごとの実施可否判断と格下げ判断）を一般化したものです。あらかじめ決めたいくつかの日付に、明確な条件を確認し、事前に決めた対応を実行します。対応には、スコープ項目の削減、予算段階の引き下げ、マーケティング施策の強化などがあります。チームが落ち着いているときに対応を決め、そうでないときに実行します。この順序こそが要点です。計画には、告知のタイミング、早期割引の締め切り、開催1か月前など、自然なチェックポイントの日付がすでにあります（その時点での需要しきい値は samber/dev-event-organizer-skills@event-market-fit に属します）。複数のトラックが実際の後工程の制約を共有している場合は、1つのチェックポイントで同時に複数のトラックを管理できます。独自の設定例として、スポンサーの確定と登壇者の発表を、開催4週間前の同じチェックポイントにまとめるケースがあります。その日付が印刷物のデザイン確定日であると同時に、登壇者が週末の予定を空けるために必要な準備期間でもあるためです。複数の項目をまとめたチェックポイントは、きりのよい数字ではなく、その背後にある実際の制約のうち最も厳しいものを基準に設定してください。

• 頻度に応じた差異レビュー：後回しにされがちな選択肢です。週次または隔週でトラックごとの実績と計画を確認し、遅れがバッファーを超えたら再計画します。3つの選択肢の中で、継続的な調整コストが最も高くなります。およそ5人以上のトラック責任者が並行して作業するようになった場合（独自に設定したしきい値であり、出典に基づくものではありません）、または既存のチーム定例を活用でき、追加コストがほぼゼロになる場合（インタビュー Q8）に、採用してください。

• イベント駆動型の再計画：基礎となる前提が崩れたときのみ再計画します。会場の喪失、主要スポンサーの撤退、CFP の応募数が著しく少ない場合などが該当します。これは、どの計画でも必ず維持する最低限の対応です。これだけに頼ると、事前に合意した選択肢がないまま、危機の最中にすべての再計画を行うことになります。最も低コストですが、その価値もまさにその程度です。

定例のチーム会議がなく、Q5 の上限がボランティアの作業時間である場合は、頻度に応じた差異レビューを格下げするのではなく、削除してください。

• この選択肢から削除し、上の評価項目からも削除してください。
• 実施担当者のいない週次のトラック別確認は、頻度を下げたレビューにはなりません。チームが参加を断る定例招待へと変わるだけです。
• それに伴い、すでに存在していたチェックポイントの規律も失われていきます。
• 採用の条件となるのは、定例を始める意向ではなく、既存の定例です。

3つすべてに共通する基本ルール：日付を発表した後は、日付を維持し、スコープを変更します。発表前は日付もまだ変更可能な要素であり、日付の変更は正当な調整手段です。発表は日付を変更不能にするマイルストーンであり、そのため発表には前提条件があります（ゲート一覧を参照）。

ワークフロー

1. インタビューを実施します。日付が未選択の場合（Q2）、または初開催のゲートが必要な場合（Q1）は、ここで終了します。
2. 開場日を計画の基準とし、変更できない外部の締切（Q3）をその横に記載します。
3. このイベントに合わせて絞り込んだトラックを列挙します。それぞれに、開場日と同日またはその直前の最終マイルストーンを設定します。
4. 選んだ粒度に沿って、最終マイルストーンから最初のアクションまで、各トラックを逆算します。
5. トラック間の依存関係をすべて、両側のマイルストーンを明記した明示的なゲートにします（references/tracks-and-gates.md）。
6. 取り消せないコミットメントにはすべて、実行可能な最終日とオーナーを記載します（上記のバッファメニュー）。
7. チェックポイントを記載します。日付、確認する条件、事前に決めたアクション、オーナーを明記します（上記の再計画メニュー）。
8. 各トラックのオーナーを1人ずつ確定します。チームが実際に更新し続けられる、最もシンプルな共有トラッカーで計画を公開します。
9. 作業逆算表（以下の出力形式）をセクションごとに提示します。まず基準日とトラック、次にゲート、最後にバッファとチェックポイントを提示し、それぞれを確定する前にユーザーに確認します。
10. 進行中に再計画する場合（Q6）：トラックごとに実績と計画の差分を確認し、バッファを明示的に使い、あらかじめ記載したチェックポイントのアクションを実行します。準備が整っていないスコープ項目を救うために、告知済みの日付を変更してはいけません。

計画の終点は開場です。その後の作業は samber/dev-event-organizer-skills@event-debrief に引き継ぎます。計画をイベント前／イベント中／イベント後のフェーズとして構成する方法は、一般的な市場投入のローンチテンプレートから借用したものです。使用する場合はその旨を明記してください。このスキルの対象範囲はイベント前のフェーズのみです。

ハーネスに永続メモリがある場合は、基準日、トラックのオーナー、ゲート一覧、コミットメントの実行可能な最終日、各チェックポイントの条件と結果、使用したすべてのバッファを記録してください。進行中の再計画も次回開催の計画も、これらを再導出せずに、記録済みの情報を基に開始できます。

失敗パターン

• 今日を起点に先の計画を立てる。 「次に何を始められるか」と考えていると、会場の手配や CFP の募集に必要な期間に気づいたときには、もう間に合いません。必ず開催日から逆算してください。
• 別の形式の準備期間を流用する。 カンファレンスとハッカソンでは、構造上の理由から必要な準備期間が異なります。出典のあるバリエーションは samber/dev-event-organizer-skills@event-first-edition にあります。決して平均を取ったり、別の形式に合う準備期間だと思い込んだりしないでください。
• 前提条件が整う前に日程を発表する。 出典のある例：ある運営ガイドでは、支払いの取り扱い体制が整うまで日程を発表してはならないという厳格なルールを定めています。これを省いたチームは、日程変更や中止を余儀なくされています。発表はゲート付きのマイルストーンであり、プレスリリースではありません。
• すべてのマイルストーンに余裕を持たせる。 一律の余裕は気づかないうちに消費され、計画の日付が意味をなさなくなります。バッファを設けるのは、メニューにあるとおり、取り消せないコミットメントとスコープの段階です。
• あらかじめ対応を決めていないチェックポイント。 進捗報告会に成り下がります。遅れが記録されても何も実行されず、判断は危機的な状況になるまで先送りされます。
• 誰も更新しない巨大な計画。 チームが維持できる範囲を超えてタスク単位で計画すると、1か月以内に古くなります。古くなった計画は、大まかでも最新の計画より有害です。粒度を一段階下げてください。
• トラック分けのない、時系列順の単一リスト。 遅れが何を妨げるかが見えなくなり、実際には一方だけが3つのトラックを妨げているのに、会場の遅れとスポンサーの遅れが同じ緊急度に見えてしまいます。
• 担当者のいないトラック。 ゲートに支障が出るまで誰も気づかないまま、そのマイルストーンが遅れます。担当者を定めることは計画の一部であり、実装の詳細ではありません。
• 発表済みの日程を変更する。 登壇者、スポンサー、参加者からの信頼を損ないます。複利的に成長する年次イベント（Q4）では、最も大きなコストを伴う選択肢です。代わりにスコープを削減してください。
• 最終スプリントだけを見る。 チームが最後の1か月に効率よく動けていても、その前の静かな期間に計画がずれていることがあります。その期間、実績と照らし合わせて計画を確認していなければ、ずれが積み重なるまで表面化しません。年次イベントの計画が実際に破綻するのは最終スプリントではなく、見過ごされた中盤です。

測定

ゲート（計画そのものに対する合否判定です。基盤となる仕組みは記載のとおり出典がありますが、それぞれを厳格なゲートとして扱う基準は、このスキル独自に設定したものです）：

• ゲート網羅率：トラック間の依存関係がすべて、両方のマイルストーンを明記した明示的なゲートとして記載されています。暗黙の依存関係を持つトラックの組み合わせはありません。
• コミットメント網羅率：取り消せない支出や人員数の決定にはすべて、最遅安全日と担当者が定められています（仕組みは出典あり、網羅性の基準は独自設定）。
• チェックポイントの完全性：すべてのチェックポイントに、日付、条件、事前に決めた対応、担当者があります（仕組みは出典あり、基準は独自設定）。
• 担当者：すべてのトラックに、責任を負う担当者が1人だけ割り当てられています。

チェックポイント間で確認する傾向（独自設定）：トラックごとのバッファ消費量、現在遅れているトラック数、リスクのあるゲート。開場可否の判断基準：発表後に日程が一度も変更されておらず、スコープの削減がすべて危機の最中ではなくチェックポイントで行われていること。

呼び出し例

• 「来年の6月12日にカンファレンスを開催します。会場は契約済みです。この日から逆算して、全体の計画を作成してください。」
• 「開催まであと4か月です。CFP の締め切りが遅れ、スポンサー獲得も目標に届いていません。日程を変更せずに計画を立て直してください。」
• 「昨年の混乱した準備を、今年の開催に向けたチェックポイント付きの適切な逆算計画にしてください。」

期待される出力：

• トラックごとに、開催日から逆算した日付付きマイルストーンを示す逆算表。
• 両方のマイルストーンを明記したゲートの一覧。
• コミットメントの最遅安全日。
• 日付、条件、事前に決めた対応、担当者を記載したチェックポイント表。

実例と否定的な例は、references/buffers-and-replanning.md にあります。

参考資料

• references/tracks-and-gates.md：トラックごとのマイルストーンの連鎖と、トラック横断の依存関係ゲートの一覧です。出典付きの例を明示しています。
• references/buffers-and-replanning.md：出典のある2つのバッファの仕組みを詳しく説明し、チェックポイントの設計、進行中の計画変更手順、否定的な例を含む作業逆算表を掲載しています。
• samber/dev-event-organizer-skills@event-budget：スコープ階層と財務トラックの根拠となる損益計算書です。
• samber/dev-event-organizer-skills@event-risk-management：チェックポイントの条件の根拠となるリスク登録簿です。
• samber/dev-event-organizer-skills@event-continuous-improvement：意図的かつトレンドに基づくイベントコンセプトの変更を、予定タスクとしてこの計画に反映します。単一の開催回から持ち越されたアクションアイテムとは区別されます。
• samber/dev-event-organizer-skills@cross-event-promotion：他のイベントとの共同開催や相互プロモーションの取り決めです。共同開催の決定は開催回のサイクルにおけるコミットメントであり、会場トラックとマーケティングトラックに反映されます。直前のマーケティングタスクではありません。