event-format-selection

イベント形式の選定

技術イベントの形式を企画する立場として、次の点を決定します。

• イベントを1つのプログラムにするか、複数にするか
• どの形式にするか：ミートアップ、ハッカソン、アンカンファレンス、1日または複数日のカンファレンス
• ワークショップと講演をどう組み合わせるか
• どのセッション形式で1日を構成するか
• 対面、オンライン、ハイブリッドのどの形式で開催するか

スケジュールの作成は担当しません。グリッド形式の設計、セッションの重複回避、部屋の収容人数との調整は、samber/dev-event-organizer-skills@event-schedule-design の担当です。ここでは、規模、対象者、コンテンツ構成の方針に基づいて、単一トラックか複数トラックかを決めます。その構成に沿ってセッションを配置するのは、event-schedule-design の担当です。

以下の推奨はすべて既定の案であり、絶対的なルールではありません。状況や実行担当者によって変わります。ヒアリング後、この主催者について把握した内容に照らして、各メニューの優先順位を付け直してください。専用会場、社内のAVチーム、分散型コミュニティ、ベンダーの既存顧客基盤は、いずれも既定の優先順位を覆す可能性があります。

ヒアリング

一度に質問するのは1つだけにし、可能であれば選択式にします。質問4〜6を設けているのは、以下のメニューで効果が出るまでの期間、成果の持続性、必要な労力が大きく異なるためです。既定の順位だけでユーザーに代わって選ぶことはできません。

1. 今回検討するのは、ゼロからイベント全体の構成を決めることですか、それともトラック数、開催形式、セッション構成、ハッカソンのデモ形式など、1つの要素ですか？すでに決まっている項目に関するメニューはスキップしてください。
2. イベントの主催者と開催目的は何ですか？独立運営でCFPを実施し、ボランティアが運営し、スポンサー収入を費用回収に充てるコミュニティカンファレンスですか？それとも、ベンダーが主催し、基調講演を中心に構成し、マーケティング予算を持ち、スポンサーを見込み顧客の獲得につなげるユーザー／ベンダーカンファレンスですか？
3. 現時点で、対象者についてどのようなデータがありますか？定期ミートアップの参加者数、コミュニティの規模、過去の開催回の登録者数など、印象ではなく数字で教えてください。
4. 開催日または開催時期に厳しい制約がありますか、それとも時期は自由ですか？（厳しい期限がある場合、準備期間の短い形式や、長期にわたるCFPサイクルより招待制のコンテンツが有利になります。）
5. 今回限りの試みですか、それとも毎年価値が積み上がる資産として育てる予定ですか？（継続的に育てる方針なら、時間はかかっても信頼を築ける形式、つまり公開CFP、販売目的ではない基調講演、単一トラックでのキュレーションが有利になります。）
6. 許容できる労力の上限はどのくらいですか？本業と並行して主催者が割ける時間、人員、予算への許容度、会場の予約金に伴うリスクへの許容度を教えてください。
7. 用意できるコンテンツはどのくらいありますか？質の高い講演者や投稿を、現実的に何件集められますか？過去にCFPを実施している場合、応募数と採択枠数の比率はどのくらいでしたか？
8. リモート参加者が費用を払うという根拠はありますか？過去のライブ配信への反応、実際に分散しているコミュニティ、この分野でのオンラインチケット販売実績などを教えてください。（これはハイブリッド形式を推奨するための条件です。「配信してほしい」と言われたことは根拠になりません。）
9. 各メニューの優先順位を見直す材料となる、すでに利用できる資産は何ですか？雇用主やスポンサーを通じて使える会場、社内の制作／AVスキル、録画の運用体制、既存のワークショップ講師陣などを教えてください。
10. パネルを中断して進行を軌道修正できるモデレーターはいますか？また、その役割を引き受ける意思はありますか？
11. 報道対応やスポンサー向け報告のために、ハッカソンのデモで分かりやすいステージ上のフィナーレが必要ですか？
12. 定期ミートアップの場合のみ：現在の参加者はどのような人たちですか？実務に携わる人ですか、それとも、対象トピックをまだ実践していない人が中心ですか？新規参加者から見て、ミートアップは内輪の集まりのように感じられますか？（ディスカッションカフェ形式を採用する条件です。）
13. 定期ミートアップの場合のみ：地元企業が部屋とコーヒーを無料で提供してくれますか？スポンサーが飲み物代を負担するバーのスペースや、複数のコミュニティが集まる夜のイベント向けに会場を提供するコワーキングスペースのホストはいますか？（費用のかからない形式を採用する条件です。）
14. 地元の類似イベントでは、どのような形式、セッション形式、サイドイベントがすでに行われていますか？（ワークフローのステップ3にある「模倣レシピ」の確認条件です。類似イベントが飽和している都市では、この点が決め手になります。）
15. カンファレンスの場合のみ：対象者として、特定の1つの層を掲げていますか、それとも複数の層を掲げていますか？複数の場合、それぞれの層にはどのコンテンツが対応しますか？（トラック数に関する複数対象者ルールの適用条件です。）

コミュニティカンファレンスとベンダーカンファレンス

形式の選択を左右する分岐点は、誰がイベントを主催し、何を目的としているかです（同じ分岐を samber/dev-event-organizer-skills@event-first-edition でも論じています）。

• コミュニティカンファレンス - CFPを一般公募し、明確なセールストーク禁止（CNCFの表現では「no product and/or vendor sales pitches」）を設けます。スポンサーは展示会場やサイドイベントの枠を購入しますが、プログラム枠は購入できません。中立性が信頼性の源です。このスキルのメニューに掲載されている事例（DevOpsDays、Strange Loop、GOTO、MLH）は、すべてこの側に属します。
• ユーザー／ベンダーカンファレンス - ベンダーのアーキテクチャを軸に招待制のコンテンツを編成し、スポンサーによる基調講演を設け、より狭い「垂直型」の範囲に焦点を当てます（swyx）。形式に関する問いは、キュレーション方針から、プログラムとマーケティングのバランスへと移ります。このスキルでは、構造上のメニューが異なる部分を扱います。製品発表の基調講演、エグゼクティブサミット、展示会場など、ベンダー側の形式ファミリーの詳細は samber/dev-event-organizer-skills@business-event-formats が扱います。また、どちら側のカンファレンスでもプログラムと並行して実施される、スポンサー向けの活動レイヤーも同様です。

推奨内容が異なる場合は、どちら側を前提としているかを明記してください。シングルトラックの根拠、CFPの経済性、セールストークの禁止はコミュニティ側の事実です。開催方式に関するコストの根拠は、どちら側にも当てはまります。

ワークフロー

1. インタビューを実施します。ユーザーがすでに決めているメニューは省略します（Q1）。
2. 主催者の側を確定します（Q2）。以降のすべてのメニューで、これによって初期設定が変わります。
3. 段階的な選択肢からイベントの形態を選びます。Q3とQ7の根拠に照らして、次の段階へ進む条件を正直に確認します。内容の深さとリスク許容度が段階を進める条件であり、参加人数だけで決めてはいけません。次に、候補の構成を、地域で既に実施されているイベントと比較します（Q14）。近隣の標準的な構成を再現する形態やセッション構成では、参加者がこのイベントを選ぶ理由がありません。少なくとも1つの形式またはアクティビティに独自性を持たせてください。ただし、差別化の主張そのものは samber/dev-event-organizer-skills@event-positioning が扱います。この確認によって順位を付け直すことはありません。既に順位付けで許容されている段階の中から選ぶためのものです。
4. トラック数を、そのコンテンツ構成への影響と合わせて決定します。これは2つに分けず、連動する1つの決定です。
5. 選んだ形態に合わせてセッション形式の構成を組み立てます。仕組み、失敗パターン、基調講演／ファイヤーサイドチャット／パネルの選択指針については、references/session-format-catalog.md を読み込みます。
6. 開催方式を選びます。ハイブリッドを推奨する前に、references/delivery-mode-evidence.md を読み込みます。
7. ハッカソンの場合のみ、デモ／審査の構成を選びます。採点基準は samber/dev-event-organizer-skills@hackathon-judging に引き継ぎます。
8. トレードオフを示した候補構成を2～3案提示し、推奨案を1つ示します。ユーザーの確認はセクションごとに行い、全体を一度に提示して済ませてはいけません。これは戦略に関する成果物です。最終決定の前に、明示的な承認を得てください。
9. 承認された構成を引き継ぎます。
   • グリッドの作成は samber/dev-event-organizer-skills@event-schedule-design に引き継ぎます。
   • 選んだ形式がイベントのアイデンティティに影響する場合（シングルトラックのキュレーションイベントとマルチトラックの展示会では、イベントの位置付けが異なります）は、samber/dev-event-organizer-skills@event-positioning に引き継ぎます。

利用する環境に永続メモリがある場合は、選んだ形態、トラック数、セッション構成、開催方式、そして何よりも、各選択を見直すきっかけとなる根拠を記録してください。次回の形式見直しでは、初期設定を改めて議論するのではなく、そうしたきっかけを出発点にできます。

イベント形式の段階

順位（デフォルトであり、絶対的なルールではありません。Q4〜Q6、Q9に照らして並べ替えてください）：

• 労力（準備期間＋当日の運営＋財務リスク）：複数日カンファレンス > 1日カンファレンス == ハッカソン > アンカンファレンスデー > 定期ミートアップ
• 価値（開催ごとの信頼性＋深さ＋つながり）：複数日カンファレンス > 1日カンファレンス > ハッカソン > アンカンファレンスデー > 定期ミートアップ
• 効率：定期ミートアップ > アンカンファレンスデー > 1日カンファレンス > ハッカソン > 複数日カンファレンス

==には議論の余地があります。1日カンファレンスとハッカソンは、異なる部分に労力をかけるものの、総労力は同程度です。カンファレンスでは、CFPと企画選定のサイクルに長い準備期間を費やします。一方、ハッカソンは準備期間を短縮します（情報源にあるハッカソンのタイムラインでは4〜9か月）が、その分、当日の継続的な運営、審査の段取り、賞品の提供に労力がかかります。どちらも低コストな選択肢ではありません。

• 定期ミートアップ - 昇格のきっかけが生じるまでは基本となる段階であり、それより上のすべての段階に向けた需要創出の原動力でもあります。会場にまだ余裕があり、登壇者の候補が少ない間は、この形式を続けましょう。
  • 定期ミートアップには、ひとつの形式しかないわけではありません。「夜の講演会」として固定する前に、「定期ミートアップのバリエーション」§をお読みください。
• アンカンファレンスデー（オープンスペース、または終日規模のリーンコーヒー） - プログラム選定なしで次の段階に進む形式です。実際の会場と丸1日を確保しながら、CFPサイクルは必要ありません。コミュニティが自らトピックを生み出せる場合に適しています。実際にどのような進行を担うことになるかは、カタログの参考資料をご覧ください。
• ハッカソン - カンファレンスより上でも下でもなく、異なる価値提案（講演ではなく、ものづくり）を持つ形式です。目標が共に学ぶことではなく、成果物の作成やチーム形成である場合に選びましょう。
• 1日・シングルトラックのカンファレンス - 次の段階への目標です。公表されている移行条件は、ミートアップの参加者が継続して100〜150人以上であること、1日分のプログラムを組めるだけの質の高い地元の登壇者がいること、そして会場のリスクを引き受けるチームがあることです。North Bay Pythonは、6か月未満の計画期間で40,000ドルの予算を使い、信頼できる初開催を実現しました。固定の参加者数が条件ではありません。DartUPは250人以上、GopherConは700人で初開催しました。条件となるのは、コンテンツの深さとリスク許容度です。
• 複数日カンファレンス - もっとも価値が高い一方、効率面では常に最下位となる、後回しにされがちな選択肢です。参加者数だけを理由にせず、コンテンツの深さと、移動して参加する価値があることを根拠に選びましょう。Strange Loop自身の基準は、「2〜3日が最適です……1日のカンファレンスでは、移動時間に見合いません」です。この段階で標準的な低リスク構成となるのは、ワークショップデーで講演日を挟むモデルです（SmashingConf、PyCon、GOTO）。参加任意で別売りの実践的な日を講演日の前後に設けることで、選定済みのトラックの一貫性を損なわずに深みを加え、現実的な収益源にもなります。業界全体の単一の数値に平均するのではなく、イベントごとの比率をreferences/format-precedents.mdで参照してください。

初開催の場合は、samber/dev-event-organizer-skills@event-first-editionを使って規模と立ち上げ方を決めてください。そこでは、単一の焦点に絞ったスコープ段階により、このカタログから意図的に選択肢を絞っています。また、段階を飛び越える際の条件（チーム、予算の段階）は、このメニューより厳しく設定されています。

定期ミートアップのバリエーション

定期ミートアップの段階におけるバリエーションであり、段階を追加するものではありません。上記のはしごにおける労力、価値、効率の位置づけは共通で、参加者と費用が異なります。各バリエーションの仕組み、費用、失敗要因については、references/session-format-catalog.md § 定期ミートアップのバリエーションを参照してください。

• トークイベント - 標準的なバリエーションです。厳選したトークを1〜2件行い、その後にドリンクを楽しみます。
• 事前知識不要のディスカッションカフェ - 講演や専門家による進行を設けず、「質問や不安を持ち寄ってください。少し詳しい人たちが一緒に話します」という趣旨で開催する、月例のオープンな座談会です。ミートアップは内輪の集まりになりがちなので、より踏み込んだセッションに進む前の入り口となります。推奨条件、Q12に基づく：参加者の大半が実務者ではない場合、またはミートアップが内輪の集まりだと見なされている場合。
• 開催企業の朝食会 - 開催企業が会場とコーヒーの費用を負担する、平日の朝のイベントです。主催者の費用はゼロで、開催企業は地元の大手企業の間で交代します。Q13で協力的な開催企業が挙がり、参加者にマネージャーやビジネス職が含まれる場合に推奨します。開催企業が日程を支配したり、ブランドが前面に出すぎたりしないよう注意してください。
• バー主催の仕事帰りイベント - バーで夜に開催し、スポンサーがドリンク代を負担します。準備コストは最も低い一方、コンテンツは最も弱くなります。
• ローテーション形式 - シリーズでディナー、ランチ、仕事帰りのイベント、トーク、オープンセッションを順番に開催し、同じ曜日と時間帯が2回連続で使われないようにします。samber/dev-event-organizer-skills@event-date-selection § 定期シリーズと併用します。
• コミュニティ横断の合同イベント - 地元の複数のミートアップグループが、同じ会場で同じ夜に、それぞれブースまたはセッションを開催します。調整の負担は軽めです（コーディネーター1人、コワーキングスペースのホストなど）が、参加する各グループには実質的な負担がかかります。時折実施するものとし、定期開催にはしません。
• 街頭でのアウトリーチ - 街頭インタビュー動画や、季節のマーケットでのブース出展などです。一般の人々に親しんでもらうための活動であり、ミートアップの開催形式ではありません。アウトリーチとして数え、参加者数には含めないでください。

各回で扱うトピック領域（技術、マーケティング、人事、人間に関するテーマ）を交互にすることは、新規参加者の割合を高めるための見直しの手段であり、samber/dev-event-organizer-skills@event-community-building が担当します。シリーズでこの方法を採用する際は、ここでトピックの境界を定めてください。

トラック数と、それによって可能になるコンテンツ構成ルール

順位（デフォルトであり、絶対的なものではありません）：

• 労力（キュレーション＋調整）：複数トラック > 単一トラック＋午後のオープンスペース > 単一トラック
• 価値、コンテンツ容量＋参加者の主体性：複数トラック > 単一トラック＋午後のオープンスペース > 単一トラック
• 価値、共有体験＋キュレーションの裁量：単一トラック > 単一トラック＋午後のオープンスペース > 複数トラック
• 効率：単一トラック > 単一トラック＋午後のオープンスペース > 複数トラック

優越性チェック：3つのペアに厳密な優越関係はゼロ――構成上そうなるだけで、構成上の結果は合格とはみなされません。 3つすべてを妨げる要因は1つです。2つの価値軸は正反対なので、コンテンツ容量を増やせる段を選ぶと共有体験が損なわれ、どの段も両方の軸で他と同等以上にはなりません。

どのペアでも労力の比較には至らず、3つ目の軸も示されていません。このチェックからは何もわかりません。順位は、以下の議論に基づいています。

2つの価値軸は実際に相反しており、その不一致こそが判断の対象です。複数トラックは、共有されるストーリーの流れと主催者の編集権限を手放すことで、コンテンツ量を増やします。

• 単一トラック - 独立した複数のイベントが同じ結論に至っているため、デフォルトとします。Strange Loop、GOTO、Monktoberfest、Deconstruct、SmashingConfはいずれも意図的に単一トラックを選び、共通する理由（共通の文脈、編集上の責任としてのキュレーション、設計目標としての廊下での交流、販売枠を設けないこと、登壇者が会場に残ること）を挙げています。引用と出典はreferences/format-precedents.mdを参照してください。複数トラックは規模を拡大するための判断とし、品質向上とはみなさないでください。
• 単一トラック＋午後のオープンスペース - DevOpsDaysの構成です。午前はキュレーションされた30分の講演、Ignite枠、午後はすべてオープンスペースです。見落とされがちな利点は、これによって可能になるコンテンツ構成ルールです。ツールやベンダーに特化した講演はオープンスペースに誘導され、キュレーションされたトラックを概念的な内容に保てます。トラック数とコンテンツ方針は連動する判断です。キュレーションされた2つ目のトラックを設けるなら、独自のバランス方針も必要です。
• 複数トラック - 最も選ばれにくい選択肢です。昇格条件（公開済み）：CFPへの応募が枠数の約8〜10倍に達していること（swyxの基準では、トラックごとに1日あたり8〜12人の登壇者、JSConf級のイベントで応募者200〜1,200人）。そうすれば、真に優れた内容の不採用を減らせます。共有体験をある程度保つため、全体講演の場（オープニング基調講演、全員での昼食、クロージング）を追加する場合に限り、昇格させてください。
  • もう1つの別個の昇格条件は、公開されたものではなく独自に設定したものです。同じ根本的な課題を、深さを変えて捉える、実際に異なる2つの参加者層がいる場合です。つまり、意思決定者は「なぜ」を、実務担当者は「どのように」を知りたい場合、別々のイベントではなく、同じ看板のもとで2つのトラックを運営します。この条件が当てはまる場合は、各セッションに習熟度レベルを付けてください。そうすれば、初心者中心のトラックも専門家中心のトラックも、均一な難易度帯に縛られず、それぞれの参加者層が実際に求める深さでセッションを構成できます。

複数ターゲットのルール（1日または数日間のカンファレンスのみ。Q15に基づく）：samber/dev-event-organizer-skills@event-positioningでは、ターゲットとなる参加者層を1つにすることを推奨しています。複数を掲げる場合は、毎回、すべてのターゲット向けにそれぞれのセッションを用意する必要があります。用意できなければ、そのターゲットは離れ、掲げた約束も破られます。単一トラックでは、各ターゲットに専用枠を割り当てます。複数トラックでは、ターゲットごとにトラックを1つ設けます。どちらの場合も、スケジュール案をsamber/dev-event-organizer-skills@event-schedule-designに渡す前に、ターゲットごとのセッション構成を確認してください。このルールは順位を変えるものではなく、選んだ段に適用されるカバレッジ上の制約です。

トラック数にかかわらず、コミュニティを軸とするためのガードレールとして、スポンサーがプログラム枠を購入することは一切認めません。スポンサー向け枠は、展示会、サイドイベント、DevOpsDays形式の講演間に設ける1分間の枠に限り、ステージ上の枠は認めません。採用コーナー、実際に製品を試すフィードバックセッション、参加任意のデモスペース、マッチングなど、スポンサー向けの活動はプログラムに並行して実施し、CFPには含めません。その形式はsamber/dev-event-organizer-skills@business-event-formatsに定められています。

セッション形式の組み合わせ

カタログから1日の構成を組み立てます。各形式の仕組みと失敗しやすい点については、references/session-format-catalog.mdを参照してください。追加のプログラム時間あたりの優先順位（デフォルトであり、絶対的なルールではありません）：

• 労力（質の高いプログラム時間1時間あたりに必要な主催者の作業時間）：パネル > ワークショップデー > 厳選トーク > ファイヤーサイドチャット > Igniteブロック > オープンスペース

• 価値（1時間あたりの学び＋つながり＋長く残る成果物）：厳選トーク > ワークショップデー > オープンスペース > ファイヤーサイドチャット > Igniteブロック > パネル

• 効率：オープンスペース > Igniteブロック > 厳選トーク > ファイヤーサイドチャット > ワークショップデー > パネル

• デフォルトの軸となる形式：厳選された約25～30分のトークです。コンテンツのバランスが取れ、イベントの記録に残る成果物にもなります。

• Igniteブロックとオープンスペースは効率の面で優れています。コンテンツを選定するコストがほぼゼロで、実際のプログラム上の課題（初登壇者の参加機会、自ら選べる関連性、特定ツール向けコンテンツの受け皿）を解決します。

• 洗練されたプレゼンターではない著名ゲストには、基調講演ではなくファイヤーサイドチャットを採用します。これは、出典に基づいた代替案です。

• この順位で最も割を食うのはワークショップデーです。価値で2番目、労力でも2番目のため、追加のプログラム時間を割り当てる判断では選ばれません。昇格の条件は、プログラムから切り離し、プログラム時間を巡る競争から外すことです。チケットを別売りする前後日として設けます（開催形式の段階を参照）。そうすれば収益源にもなります。

• パネルはすべての軸で最下位です。初開催のイベントでは、順位を下げるのではなく、なくします（出典に基づく段階的な構成では完全に除外されています。実施が最も難しく、最も批判されている形式です。カタログの参照先ではFred Wilson、Brad Feld、Scott Berkun、Duncan Greenが具体名で挙げられています）。開催実績のあるイベントで、Q10を基準に採用する条件：事前に準備し、必要なら話を遮ることもいとわない優秀なモデレーターを立て、挑発的な質問を事前に共有し、長い自己紹介は避けます。そのようなモデレーターがいなければ、選択肢から外したままにします。

• 廊下での交流の時間を、余った時間ではなく、意図的に選ぶ形式として確保します。長い休憩、おいしい食事、静かな部屋を用意します（Monktoberfestは、その時間を軸に開始時刻を最適化しました）。

開催形式

ランキング（デフォルトであり、絶対ではありません。Q8 の根拠により、選ばれにくい選択肢が昇格することがあります）：

• 労力：インタラクティブなハイブリッド > 完全オンライン == 記録・公開付きの対面開催
• 価値（エンゲージメントの深さ＋リーチ）：インタラクティブなハイブリッド > 記録・公開付きの対面開催 > 完全オンライン
• 効率：記録・公開付きの対面開催 > 完全オンライン > インタラクティブなハイブリッド

== には異論があります。単一形式はいずれも完全な制作を必要とし、コストの中心となる項目は互いに代替し合うためです。CHI の公開数値では、ハイブリッドプラットフォームの料金は「物理的なコンベンションセンターのレンタルと同程度」とされ、MLH は「適切に運営されたデジタルハッカソンは Discord だけではない」と警告しています。

CHI のもうひとつの数値、つまりオンライン開催の運営支援費が対面イベントの 2 倍という数字は、単独のオンライン開催ではなく、ハイブリッド開催におけるオンライン部分の費用を示しているため、同率を覆すものではありません。ハイブリッドは同規模の第三の開催方式ではなく、両方を同時に実施するものです。

• 記録・公開付きの対面開催 - デフォルトであり、2022 年以降の淘汰を経て残った形式です。会場を満席にし、講演は録画して後日公開します（または、監視なしの単一フィードで配信します）。遠隔参加者は、第二のライブ制作なしに、非同期でコンテンツを視聴できます。
• 完全オンライン - コミュニティ自体に、すべてを遠隔で実施するコスト面またはアクセス面の理由がある場合に適した形式です（MLH のデジタル形式は設計上グローバルです）。意図的に選ぶ単一形式であり、格下げではありません。
• インタラクティブなハイブリッド - カンファレンスでは選ばれにくい形式です。公開記録によると、ハイブリッドでは AV と運営のコストが約 2 倍になり、オンライン参加費ではオンライン開催の費用を賄えず、CHI 2022 は 484,886 ドルの損失を出し、無料ライブ配信の視聴者数は登録者数の 10% を大きく下回ります（数値と但し書きは references/delivery-mode-evidence.md を参照）。昇格条件：オンライン登録者数が有料参加者数の約 25～30% を安定して上回り、かつその限界費用を賄えること、さらに AV と運営のコストが約 2 倍になることを想定した専用制作予算があること。ハッカソンでは、ハイブリッドは選ばれにくいのではなく、選択肢から除外されます。MLH はハイブリッドを明確に拒否し（「主催者にもハッカーにも、どちらにとっても劣る」）、具体的な失敗要因も挙げています。対面かデジタルのどちらかを選び、徹底してください。

ハッカソンのデモ・審査形式

構造のみを選択します。評価基準、配点、審査員の運営方法は samber/dev-event-organizer-skills@hackathon-judging に属します。ランキング（デフォルトであり、絶対ではありません。隣接分野の実践を参考にしています。カタログの参照先を参照）：

• 労力（チームごとの審査員工数＋設営）：二段階制の展示会から決勝へ > ステージでのプレゼン > 展示テーブル > 動画のみ
• 価値（審査員との対話の深さ＋受賞者の物語の伝わりやすさ）：二段階制の展示会から決勝へ > ステージでのプレゼン > 展示テーブル > 動画のみ
• 規模拡大時の効率：動画のみ > 展示テーブル > 二段階制の展示会から決勝へ > ステージでのプレゼン

優越性チェック：4 つの選択肢、6 つの組み合わせ、厳密な優越関係はゼロです。構造上は問題ありませんが、それだけでは合格ではありません。 価値と労力のリストが同じなので、どの組み合わせにも同じ要因が影響します。審査員との対話を深める構造は、審査員の工数と設営のコストが必ず高くなります。

ほかに、組み合わせを阻止したり救済したりする記載はありません。このチェックで誤った順序は見つかりませんが、以下は検証ではなく議論です。

• 展示テーブル - デフォルトです。審査員と実際にデモをやり取りでき、並行して実施できるため規模を拡大できます。
• 二段階制 - 選ばれにくい形式です。価値の両軸で最上位である一方、労力も最大のため、効率を理由に選ばれることはありません。Q11 に基づく昇格条件：報道またはスポンサー向けの報告に、分かりやすいステージ上の決勝が必要であること。
• 動画のみ - デジタル形式のデフォルトであり、審査員の工数で対応できる範囲を超えて規模を拡大できる唯一の構造です。

審査員の構成に形式を合わせてください。技術系の審査員にはデモを実際に触ってもらい、ビジネス系の審査員にはストーリーを伝える枠が必要です。

失敗パターン

• 安全な折衷案としてハイブリッドを選ぶ。 ハイブリッドは中間案ではなく、コストとリスクが最も高い選択肢です。2つのイベントを同時に開催し、AVとロジスティクスが倍増するうえ、リモート参加者は二級の参加者のように感じると報告しています。出典付きのコスト一覧を比較し、両者の中間を取らないでください。
• マルチトラックを品質向上策と捉える。 独立したシングルトラックのマニフェストが5つ、そうではないと示しています。マルチトラックは規模と参加者の選択肢に関する判断であり、出典のある移行条件があります。CFPの応募超過率が約8〜10倍を下回る段階でマルチトラックにすると、空室と分断されたイベントを招きます。
• 参加人数だけを基準に段階を上げる。 出典のある基準は、コンテンツの深さ、会場リスクへの許容度、登壇者の確保状況です。GopherConの初開催時が700人だったからといって、700人が基準になるわけではありません。DartUPは250人で次の段階に移行しました。
• 業界平均のワークショップ比率を作り出す。 イベントごとの比率を出典とともに示し、その差をそのまま残してください。1つの数字にまとめると、各イベント自身が共有していない基準を作り出すことになります。
• スポンサーを喜ばせるため、または枠を埋めるためにパネルを組む。 出典のある総意は厳しいものです。準備を整えたモデレーターを条件に昇格させるのでなければ、パネルをファイヤーサイドチャットか、キュレーションした講演をもう1つに置き換えてください。
• トラック数とコンテンツ方針を別々に決める。 「ステージでは概念的な講演、オープンスペースではツールに関する講演」というルールを徹底できるのは、キュレーションされたシングルトラックだからです。両者を同時に決めなければ、そのルールは2つ目のトラックで機能しなくなります。
• 固有の制約を無視して、特定イベントの構成をコピーする。 Monktoberfestの小規模さとStrange Loopのキュレーションは、会場を起点に逆算し、何百人もの応募を断る選択の結果です。表面的な形ではなく、その考え方を取り入れてください。
• 地域の定番構成をコピーする。 近隣イベントとまったく同じ構成では、開催日と価格だけで競うことになり、イベント過密の都市では勝ち目がありません。対策：Q14に照らしてワークフローのステップ3を確認し、形式かアクティビティを1つ変えてください。
• 独自のセッションがない2つ目の対象者層を設ける。 複数の対象者に向けたカンファレンスが主な対象者向けにプログラムを組むと、1回の開催だけでもう一方の対象者を失います。対策：トラック数に関する複数対象者向けルールに従うか、samber/dev-event-organizer-skills@event-positioning でその対象者を削除してください。
• 定期ミートアップの形式と時間枠を固定する。 常連は維持できますが、新規参加者の入口はいつの間にか閉ざされます。対策：意図的にバリエーションを選び（§ 定期ミートアップのバリエーション）、新規参加者の割合が下がったら形式と時間枠を入れ替えてください。
• ホスト企業が主導権を握る朝食会を開く。 無料の会場には、ホストの予定とロゴが付いてきます。対策：ホストを交代させ、プログラムの主導権を保ち、初回開催の前に、ホストが得るもの（認知度、紹介）を書き出してください。
• 形式にかかる費用を補うためにプログラム枠を販売する。 出典のあるコミュニティイベントはすべて、スポンサーへのステージ枠の販売を拒んでいます。資金調達の構成はプログラムではなく、samber/dev-event-organizer-skills@event-budget で扱ってください。

測定

フォーマットの選択は、開催ごとに検証できます。以下の各指標には、公表済みまたは独自設定のラベルが付いています。独自設定の基準は、イベントごとに調整してください。

• 開催形式の確認（公表済みの数値）：配信またはバーチャル枠を設けた場合は、リモート参加者のエンゲージメントを、申し込み数の10％未満というライブ配信のベンチマーク（参考値のみ。数値はテック分野ではなく学術会議に基づくものです。参考資料を参照）および約25～30％の告知基準と比較します。これらを下回る場合、次回開催ではハイブリッド開催の費用対効果が見合わないことになります。
• CFPの競争率（公表済みの数値）：応募者数と採択枠数の比率を、複数トラックを追加する唯一の公表済み基準である約8～10倍の目安と比較します。これは検討を始める最低ラインとして捉えてください。CFPに問題がある証拠ではありません。swyx自身の数値によると、人気のあるシングルトラックイベントでは、応募が採択枠の8～30倍になるのが一般的です。
• ミートアップ形式の指標（独自設定、定期開催のミートアップのみ）：各形式の新規参加者比率とリピーター比率（定義は samber/dev-event-organizer-skills@event-community-building を参照）、およびディスカッションカフェでは、より深いセッションに進む参加者数を確認します。
• ワークショップの販売率（独自設定）：別売りのワークショップ開催日が、事前に定めた基準（例：定員の60％）まで売れなければ、次回は開催日を減らす根拠になります。開催日を段階的に設定するモデルなら、変更を元に戻せます。
• セッション構成の指標（独自設定）：オープンスペースのマーケットプレイスが掲示スペースを埋めるか、ライトニングトーク枠への応募数、パネル中の途中退席、ニュースの振り返りブロック直後の退席などです。2～3項目を選び、それぞれがどのような変更につながるかを決め、イベント前に両方を書き留めてください。
• 完売までの速さ、参加者の定着率、スポンサーの継続率は、フォーマットではなくイベント全体の指標です。これらは samber/dev-event-organizer-skills@event-market-fit で扱います。

呼び出し例

• 「私たちのRustミートアップには毎月120人が参加します。カンファレンスを開催すべきでしょうか。開催するなら、どのような形式がよいでしょうか？」
• 「来年、2つ目のトラックを追加するか検討しています。CFPには24枠に対して90件の応募がありました。」
• 「CEOは、リモート参加の顧客もライブで参加できるよう、ユーザーカンファレンスをハイブリッド開催にしたいと言っています。判断のポイントを教えてください。」
• 「当日の構成を考えてください。1日開催、参加者200人、コミュニティ主導で、初登壇者をもっと増やしたいです。」
• 「私たちのAIミートアップには、すでにAIを使って開発している人しか集まりません。興味はあるけれど不安を感じている人に参加してもらうには、どうすればよいでしょうか？」
• 「地元の大手企業が、毎月午前8時に無料で会場を提供すると言っています。引き受けるべきでしょうか？」

期待される出力：次の内容を含むフォーマット概要。（1）選択した形式と、その段階へ進む根拠となる実績。（2）有効になるコンテンツ構成ルールとトラック数。（3）1日の構成としてのセッション形式の組み合わせ。（4）告知・廃止の判断理由を含む開催形式。（5）各選択について、次回開催で見直すきっかけとなる、出典に基づいた基準。検証できるようセクションごとに提示し、候補の構成を2～3案と、冒頭に推奨案を1つ示してください。

参考資料

• references/format-precedents.md - カンファレンス形式の変遷（DartUP、GopherCon、RailsConf/Rails World、North Bay Python）、引用付きの5つのシングルトラック宣言、DevOpsDaysの1日構成、イベントごとのワークショップ比率、コミュニティとベンダーのセッション選定に関する根拠。
• references/session-format-catalog.md - セッション形式ごとの進行方法、コスト、失敗しやすい点：厳選トーク、ニュースまとめブロック、Ignite、小グループでの進行方法を取り入れたオープンスペース、Lean Coffee、名前の挙がっている批判者による基調講演／ファイヤーサイドチャット／パネルの指針、ワークショップデーのモデル、ハッカソンの審査形式の表、定期ミートアップの各種形式。
• references/delivery-mode-evidence.md - CHIが公表したハイブリッド開催の財務情報、SIGMETRICSのリトリート、10%未満のライブ配信視聴者数、MLHによるハイブリッド開催の失敗パターン一覧、および既定の方針を見直すためのベンチマーク。

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

• samber/dev-event-organizer-skills@event-cfp-design と samber/dev-event-organizer-skills@event-talk-selection - ここで選択するトラック構成に沿ったCFPプロセスとトーク選定。
• samber/dev-event-organizer-skills@event-venue-sourcing - ハイブリッド／バーチャル開催の設備を含め、選択した構成に必要となる会場要件。
• samber/dev-event-organizer-skills@event-cultural-identity - ここで選んだ形式を、言葉遣い、伝統、儀式へと落とし込みます。シングルトラックの厳選プログラムによる1日開催と、複数トラックのエキスポでは文化が異なり、その結果にも責任を持ちます。
• samber/dev-event-organizer-skills@workshop-program-design - このスキルが別枠とすることを決めたワークショップデーを運営します。定員、ファシリテーターの配置、参加者の前提知識と環境設定、ノートPCを使う部屋に必要なネットワーク体制を扱います。ワークショップデーを開催するか、チケットをどう販売するかについて再検討することはありません。
• samber/dev-event-organizer-skills@hackathon-brief-design - ここで選択するデモと審査の構成に沿って、課題の説明資料を作成します。用語の重複に注意してください。ここでの track は並行して行われるセッションの流れを指しますが、あちらの challenge track はチームが参加するテーマ別カテゴリーです。