event-cfp-design

イベントの CFP 設計

技術イベントの登壇者募集（CFP）を設計します。これは、登壇を検討している人が読む告知、記入するフォーム、そして双方が守るタイムラインを形にするものです。

次のことは行いません。

• 応募を評価・選考しません。評価基準表、審査委員会、通知は samber/dev-event-organizer-skills@event-talk-selection が担当します。
• CFP 以外の経路で登壇者を募集しません。この並行する取り組みは samber/dev-event-organizer-skills@event-speaker-sourcing が担当します。

募集で提示するセッション形式は入力情報です。上流の samber/dev-event-organizer-skills@event-format-selection で選択してください。

以下の推奨事項はすべてデフォルトであり、絶対的なルールではありません。状況や実行する人に応じて変わります。インタビュー後、このスキル内の各メニューを、主催者について把握した情報に基づいて再度順位付けしてください。既存のメンタープール、国際的に分散したコミュニティ、すでに利用料を支払っているツール、あるいは確定したプログラム発表日などがあれば、デフォルトの順位は変わることがあります。

インタビュー

一度に質問は1つにし、可能な場合は選択式にします。質問4〜6があるのは、以下のメニューで効果が出るまでの期間、見返りの持続性、労力に大きな差があり、デフォルトの順位をユーザーに代わって決められないためです。

1. イベントの日程と、選択済みの構成（全体の形、トラック数、セッション形式の組み合わせ）を教えてください。まだ構成が決まっていない場合は、まず samber/dev-event-organizer-skills@event-format-selection を利用してください。誰も選んでいない形式を CFP で提示することはできません。
2. イベントの主催者は誰ですか。公開 CFP でプログラムを埋めるコミュニティカンファレンスですか、それとも大半のコンテンツを招待で決め、CFP で一部を募集するベンダー／ユーザーカンファレンスですか。
3. 今回が初めての CFP ですか、それとも2回目以降ですか。過去に CFP を実施している場合、募集枠数に対して応募数はいくつでしたか。また、登壇者や審査員からどのような不満が寄せられましたか。
4. プログラムの発表期限まで、あと何週間ありますか。（期限が決まっている場合、タイムラインのメニューが制約されます。最低期間に満たない場合、公開 CFP は短縮するのではなく、取りやめます。）
5. 今回は単発の開催ですか、それとも毎年価値を積み上げる資産ですか。（価値を積み上げる方針であれば、ブラインド審査、メンタリング、年をまたいで維持される公開基準など、時間をかけて信頼を築く選択肢の順位が上がります。）
6. 労力の上限はどの程度ですか。審査委員会の人数、主催者の作業時間、募集期間中の CFP 広報を誰が継続して行うかを教えてください。
7. 登壇者への約束として、予算上確実に提示できるものは何ですか。無料チケットのみですか。交通費の払い戻しや助成金もありますか。それ以上のものはありますか。未確定の予算を募集要項に記載してはいけません。
8. 登壇者の多様性は明示された目標ですか。また、募集の告知を掲載するだけでなく、積極的に働きかける余力はありますか。
9. メニューの順位付けを見直すべき既存の資産はありますか。公開できる過去の採択提案、ボランティアのメンタープール、ビザ取得に要する期間を把握している国際的な登壇者コミュニティ、すでに利用中の CFP ツールなどです。

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

応募者はどちらの場合も開発者です。CFP の設計を左右するのは、誰がイベントを主催するかです（samber/dev-event-organizer-skills@event-format-selection が論じているのと同じ区分です）。

• コミュニティカンファレンス - CFP がプログラムの主な募集窓口です。情報源となるガイドでは、露骨な営業目的の発表の禁止と「スポンサーが登壇枠を購入することは、決して、絶対にできない」という規範が明示されています（DevOpsDays の主催者向けガイド）。このスキルで参照する情報はすべて、この立場に基づいています。
• ベンダー／ユーザーカンファレンス - 主に招待でコンテンツが決まり、ベンダーのアーキテクチャを中心に構成されます（swyx による説明）。CFP を実施する場合、キュレーションされたプログラムの中のコミュニティ向け枠を募集します。以下のメニューはその枠にも適用されますが、タイムラインは登壇者の移動日程だけでなく、ベンダーの製品発表カレンダーにも連動します。

推奨事項の前提となる立場が異なる場合は、どちらの立場に基づくかを明記してください。

ワークフロー

1. インタビューを実施し、所有権の軸を確定します（Q2）。
2. 選んだ構成から、提示する形式を決めます（Q1）。募集では、その構成に必要なセッション形式だけを、過不足なく提示します。各形式に専用の応募種別と固有の入力項目を設けます。「トーク」という枠を一つ設けるだけでなく、より幅広いメニューを用意するのが、実例に基づく実践です（PyCon US では、トーク、チュートリアル、スペイン語の charlas、ポスターを募集しています。charla は、英語以外の言語を具体的に取り入れる仕組みです）。
3. 下記のメニューを参考に、イベント開催日とプログラム発表日から逆算してスケジュールを設定します（Q4）。
4. フォームの詳細度に関するメニューと references/submission-form-catalog.md を参考に、応募フォームを作成します。1 人あたりの応募上限も設定します（実例は 1 件のみで、PyCon US は 1 人あたり 3 件の提案を上限としています）。
5. 審査基準を募集要項自体に記載します。審査基準については下記のセクションを参照し、匿名化の方針をメニューから選びます。募集要項には、方針と、審査において応募者の身元を確認するタイミングを明記します。
6. 登壇者への特典を募集要項に明記します。実例で確認できる最低限の内容と、下記の誠実さに関するルールに従います。予算で確認できていない特典は、決して公表しないでください（Q7）。
7. 初登壇者へのサポートレベルを、メニューから選びます。
8. 選んだ設計に必要なツール機能（フォーム項目、スケジュール設定、審査モード、メッセージ送信）を、カタログの参考資料から洗い出します。まず必要な機能を決め、その後にツールを選びます。
9. 募集期間全体を通じた告知を計画します（告知のセクションを参照してください。意図的に最小限にし、そのことを正直に伝えます）。
10. 募集を締め切り、引き継ぎます。募集要項には、応募者への結果通知時期を記載します。応募は samber/dev-event-organizer-skills@event-talk-selection に送ります。招待登壇者向けのルートは samber/dev-event-organizer-skills@event-speaker-sourcing で並行して進め、採択されたプログラムは samber/dev-event-organizer-skills@event-schedule-design に引き継ぎます。

完成した募集要項を公開する前に、スケジュール、フォーム、審査基準、特典の各セクションを順に提示し、内容を確認してもらいます。公開済みの CFP は見知らぬ人たちとの約束です。公開後に目立たない形で修正すれば、信頼を損ないます。

ハーネスに永続的なメモリがある場合は、選んだスケジュールの基準日、方針、上限数、公表済みの審査基準、そして何よりも、次回の開催で各選択を見直すための測定閾値を記録してください。

CFP のスケジュール

順位（デフォルトであり、絶対的なルールではありません。Q4、Q8、Q9 に基づき順位を見直してください）：

• 労力（準備期間と、募集期間を通じて継続する告知）：long window > standard window > floor-compressed
• 価値（リーチ、代表性が十分でない層への告知期間、早期の需要把握、海外参加者の渡航準備期間）：long window > standard window > floor-compressed
• 効率：standard window > floor-compressed > long window

優位性の確認：比較は 3 組で、厳密な優位関係は 0 件です。これは設計上そうなるだけであり、設計上そうなることは合格を意味しません。 価値と労力は同じ順位です。そのため、1 つの仕組みが 3 組すべての比較を阻みます。価値が上位の選択肢ほど必ずコストが高く、コストが低いのに価値が同等以上の選択肢はありません。比較を阻んだり、逆転させたりする可能性のある第 3 の評価軸は示されていません。この確認では何も検出されず、順位は以下の根拠に全面的に依存します。

実例から確認できる最低限の基準（DevOpsDays の運営ガイド）：「CFP はできるだけ早く開始し、イベントの少なくとも 6〜8 週間前に締め切ってください。」募集期間は「少なくとも 1 か月」とし、「提案内容を検討し、不足分を補うために少なくとも 2 週間」を確保します。その理由は運営者の都合ではなく、登壇者の予定にあります。「通常、渡航や休暇の手配には少なくとも 4〜6 週間が必要です。」

• 標準期間 - デフォルトの選択肢です。約2か月間募集し、イベントの8週間以上前に締め切り、その間に審査します。対象者が明確な、継続開催のイベントに適しています。
• 最短期間 - 参照元で認められている最短期間です。約4週間募集し、イベントの6〜8週間前に締め切り、2週間審査します。募集開始からイベントまで、全体で約10〜12週間です。日程を厳守する必要がある場合の正当な選択肢ですが、これより短い期間は正当とはいえません。
• 長期期間 - リソースが不足する選択肢です。DevOpsDaysの公式マスタータイムラインでは、CFPの開始をイベントの7.5か月前、投稿の投票を4.5か月前、プログラムの公開を3.5か月前と定めています。つまり、審査開始から公開まで約3か月の余裕があります。リーチが最も広く、メンタリングのマッチングやビザ取得に必要な期間を確保できる唯一の段階ですが、効率性の評価では常に不利になります。実際のコストは日程ではなく、何か月にもわたってプロモーションを続けることだからです（失敗パターンを参照）。この選択肢が向いている条件は、初開催でCFPの応募数を事前販売に向けた需要の指標として把握したい場合（その結果を samber/dev-event-organizer-skills@event-market-fit に渡します）、海外の登壇者を招く場合、または締め切り前に準備期間が必要なメンタリングプログラムを実施する場合です。

動きの速い分野での、直前まで確保しておく枠（選択肢の枠外の注記で、どの段階にも適用できます）：動きの速い分野では、昨年の注目トピックが数か月で時代遅れになると主催者から報告されています。募集期間が長いほど、投稿から登壇までの隔たりが大きくなります。公募の対象外として、主催者が自分で決めた数の枠を確保し、samber/dev-event-organizer-skills@event-speaker-sourcing を通じてイベント直前に招待で埋め、その旨を募集要項に明記してください。応募者には、競争する枠の数を知らせる必要があります。募集要項に「最先端」のテーマを掲げる場合は、審査時に同様の鮮度確認が必要です。

公募より先に目玉登壇者を確保する（選択肢の枠外の注記で、どの段階にも適用できます）：公募でプログラムが埋まる前に、知名度の高い人材を個別に勧誘し、公募は残りの枠に活用します。

• 対象者。 登壇することで集客につながる、知名度の高い人や企業です。samber/dev-event-organizer-skills@event-speaker-sourcing を通じて候補を探し、適性を確認してください。スポンサー関係が、適性を示す根拠の代わりになることはありません。
• 個別に勧誘する理由。 参加者が目にするのはプログラムであり、候補者リストではありません。どの講演が公募経由だったかを知ることはないため、個別に勧誘した目玉登壇者も、採択された応募者も、登壇時には同じように見えます。公募を利用すれば、限られた候補者リストでは見つけられない人たちにも残りの枠を開放できます。
• 補充の順序。 まず目玉登壇者を探します。候補者がプログラムに必要な枠数を満たさない場合は、公募で不足分を補います。登壇が確定していない人のために枠を空けたままにしないでください。
• 早めに打診する。 特に需要の高い企業や登壇者は早くから予定が埋まり、多くのイベントから声がかかります。募集開始前、長期期間の開始時期か、それより早く連絡してください。遅い打診では、予定がすでに埋まっています。
• 公募の透明性を保つ。 上記の「直前まで確保しておく枠」の注記のとおり、公募の対象外として確保する枠数（主催者が自分で決めた数）を募集要項に記載してください。公開プログラムで、各講演がどの経路で決まったかを示す必要はありません。
• 長期的な関係を築く。 辞退した人や都合がつかない人も、関係が途切れたわけではありません。登壇者リストを保管し、開催回の合間も連絡を取り続け、次回は新たな枠の概要を添えて再度依頼してください。
• 移動が障壁なら、別の主催者につなぐ。 登壇者があなたの都市まで来られない場合は、別の都市の主催者を紹介してください。登壇者との連絡を保てるうえ、相手のイベントには講演が加わり、次回の依頼にもつながる信頼を得られます。連絡先を共有する前に、必ず登壇者の同意を得てください。

最短期間を下回る場合、つまりイベントまで約10週間を切っている場合、またはイベントの6週間以内に締め切る場合は、公開CFPを取りやめ、格下げして続行するのではなく、削除してください。参照元が示す4〜6週間の期間内では、登壇者が移動の手配をできないため、samber/dev-event-organizer-skills@event-speaker-sourcing を通じた招待制でプログラムを組みます。

応募フォームの詳細度

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

• 労力（登壇者の負担＋フォーム作成＋応募ごとの審査時間）：extended > standard > minimal
• 価値（審査での見極め力＋プログラムのバランスや運営に関するデータ）：extended > standard > minimal
• 効率：standard > minimal > extended

優越性チェック：3組を比較し、厳密な優越関係はゼロです。構造上そうなるようにしただけであり、構造上の結果は合格になりません。 価値と労力の順位は同じなので、3組すべてで結果は同じです。価値が高い選択肢ほど、コストも高くなります。比較を妨げたり、救済したりする情報はほかにありません。効率の順位は、チェックに合格した結果ではなく、以下の議論に基づいています。

• Standard - デフォルトです。タイトル、100語程度を上限とする概要、独立した「なぜ自分なのか」を説明するコンテキスト欄、形式の選択、想定する参加者のレベル、略歴、任意の過去の登壇リンクを含みます。概要とコンテキストを分けることが重要です。審査員は1つのテキスト欄を読み解くことなく、トピックの質と登壇者との適合性を別々に評価できます（swyx の CFP に関するアドバイスに基づいています。タイトルは「概要の2倍」重視され、概要は短くし、独立したコンテキスト欄を設けて活用します）。各項目の詳細、出典付きの例、悪い例については、references/submission-form-catalog.md をご覧ください。
• Minimal - タイトル、概要、略歴を含みます。ほとんど手間がかからないため、効率では2番目です。ただし、手間が少ないことは一部で見せかけにすぎません。省いた項目の分は、審査時の推測や追加のメールで埋め合わせることになります。ミートアップ規模の募集や、招待制と CFP を組み合わせた小規模な募集には適しています。
• Extended - 選択肢の中で最も手間がかかります。形式ごとの条件付き項目、録画・同意のチェックボックス、フォームに組み込んだ旅費助成の申請（PyCon US に基づく）、構造化されたアウトラインが加わります。採用条件は、助成プログラムがあること（独立した申請プロセスよりも、フォーム内のチェックボックスのほうが適しています）、形式によって要件が実際に異なること、または委員会の規模が大きく、追加の構造を活用できることです。

匿名化の方針

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

• 労力（レビュー手順の規律＋登壇者への指示＋二段階の仕組み）：mandatory blind > opt-in anonymous > named review
• 価値、応募者側の公平性と信頼：mandatory blind > opt-in anonymous > named review
• 価値、レビュー中のプログラム編成に役立つデータ（名前の認知度、地域内外のバランス、登壇者の適性の見極め）：named review > opt-in anonymous > mandatory blind
• 効率性：named review > opt-in anonymous > mandatory blind

優越性チェック：3組を比較し、厳密な優越関係はゼロです。構造上そうなるようにした場合に限り、問題はありませんが、構造上そうなることは決して合格を意味しません。 3組すべてを妨げる仕組みは1つありますが、一般的なものではありません。2つの価値軸は正確に逆方向を向いているため、公平性で上位に立つ選択肢はプログラム編成に役立つデータでは劣り、両方で同等以上となる選択肢はありません。どの組み合わせでも労力の項目には到達しません。このチェックからは何も見つかりません。効率性の項目は、以下の論拠に基づいています。

2つの価値軸は実際に相反しています。この不一致こそが判断の要点であり、どちらの側にも根拠があります。swyxによれば、「ある程度の公平性を確保するうえで、ブラインド形式のCFPレビューは重要です……私の経験では、ほとんどのCFPはブラインド形式ではありません。」PyCon USは、大規模に実際に実施している反例です。「初回レビュー中は、提案者の情報はレビュアーに表示されません」。

• 記名レビュー - swyxの所見によれば事実上の分野標準であり、2～3人の委員会がプログラムのバランスを細かく調整する、小規模な初回CFPでのデフォルトです。匿名化で担保されない公平性を、公表された基準で補う場合にのみ誠実な方法です。
• 任意の匿名化 - ツールのデフォルトです。カタログで参照しているプラットフォーム例3つのうち2つは、任意のモードとして匿名化を提供しています。これは公平性の方針ではなく、プラットフォームの機能として扱ってください。記名と匿名の応募が混在する応募者群は、同じ条件でレビューされていません。
• 必須のブラインドレビュー - 選ばれにくい選択肢です。公平性の価値が最も高く、労力も最も大きいため、効率性の観点から選ばれることはありません。PyConでの実施例から分かる実際のコストは、レビューが二段階になること（プログラムが確定する前に、身元情報を確認する必要があります。バランス、移動、名前の認知度の見極めなどがその対象です）、そして登壇者に対し、タイトルや自由記述から個人を特定できる情報を自ら除くよう指示する必要があることです。プラットフォームが非表示にするのは著者欄であり、著者が書いた内容ではないためです。採用条件は、公平性を明示的な目標とすること（Q8）と、委員会が二段階のプロセスに対応できることです。採用する場合は、身元情報をいつ確認するのかを正確に含め、募集要項で仕組みを公開してください。そうしなければ、ブラインドレビューの茶番を作ることになります（失敗モードを参照）。

公開する審査基準

審査基準は公募文そのものに記載してください。参照したテンプレートは、DevOpsDays の6つのコンテンツ方針です。登壇者には明確に伝えられており、references/published-call-evidence.md に原文のまま掲載されています。

• スポンサーが購入した登壇枠は、決して設けません。
• 既に公開されている内容より、新しい内容を優先します。
• 地元の登壇者と、地域外の登壇者のバランスを取ります。
• 初登壇者を積極的に優先します。
• 大胆なテーマを歓迎します。
• ツールや製品に特化した講演は却下せず、オープンスペースに案内します。

公募では、ベンダーの売り込みを適した形式へ案内します。これは、事前にプログラムにオープンスペースの枠が設けられている場合にのみ機能します。

オープンスペースの枠がない場合は、別の文言を使ってください。スタートアップやベンダーも、聴衆が持ち帰るものが製品ではなく、教訓やひらめきであり、ステージ上で商業的なデモを行わないのであれば、登壇できます。これを採用する場合は、第7の基準として公開してください。これは 教訓の伝達テスト です。創業者が応募前に自分で判断できるよう、次のように表現します。「聴衆が明日あなたの製品名を忘れても、その教訓は覚えているでしょうか？」samber/dev-event-organizer-skills@event-talk-selection では審査時にこのテストを適用し、採択メールでも商業的な内容に関するルールとして一文で繰り返しています。

公開前に誠実さを確認してください。swyx によれば、主催者は「おおむねその順番で、チケットを売り、優れたコンテンツ構成を実現し、翌年のチケットを売る」ようにプログラムを最適化します。知名度やテーマの構成が実際に選考に影響するのであれば（影響します）、基準でその事実をごまかしてはいけません。実際に適用する基準を公開し、唯一譲れない条件は「絶対に認めない」というコミュニティ枠の明確な方針に委ねてください。

公募文に記載する登壇者への特典

• 公開する最低条件：「最低限、すべての登壇者にイベントの無料チケットを提供する必要があります」（DevOpsDays 主催者ガイド）。この点を明記してください。特典について何も書かれていない公募文は、特典がないものとして受け取られます。
• 交通費：利用可能な場合、「資金の有効な使い道」です。ただし、主催者に共有すべき注意点が記録されています。直接支払うと、「税金、ビザ、利益相反や雇用契約に関する複雑な問題が生じる可能性があります」。助成金を設ける場合は、PyCon US の方針の形を参考にしてください。助成金は質への報酬ではなく、参加を可能にするためのものと位置づけ、採択された提案1件につき1回までとし、参加費を自分で負担できる登壇者には、限られた助成枠への応募を辞退するよう明確に求めます。
• 謝礼：業界標準はありませんが、現在、2つのコミュニティイベントがそれぞれの公募で定額を公開しています。!!Con は2018〜2024年の各開催回で変更せず、すべての登壇者に一律「$256 (USD)」の謝礼を支給すると明記しています。ffconf（英国）は、全額の交通費、ホテル代、食事代とともに「£500 honorarium」と記載しています。この2つの金額から一定の相場は導けません。市場相場や「業界標準」ではなく、判断の目安として扱ってください。謝礼の方針を定める場合は、まずこの2つの金額を示し、実際の金額は予算と法律・税務上の確認を踏まえて決めてください。
• 3つすべてに適用されるルール：公募文には登壇者が受け取るものを正確に記載し、予算で確認されていない内容は約束しません。

初めて登壇する方への支援

ランキング（デフォルトであり、絶対的なものではありません）：

• 労力（準備＋登壇者1人あたりの時間）：提案メンタリング > 実例 > 応援メッセージ
• 価値（審査を通過する、新しい声による応募）：提案メンタリング > 実例 > 応援メッセージ
• 効率：実例 > 応援メッセージ > 提案メンタリング

優越性チェック：3組、厳密な優越関係はゼロ――構成上は問題ありませんが、それだけでは決して合格ではありません。 価値と労力の順序は同じなので、すべての組で同じ仕組みが働きます。価値が高い段階ほど、コストも厳密に高くなります。どの組にも、この関係を変える別の軸はありません。このチェックでは何も検証できません。以下の比率を見て判断してください。

• 実例 - デフォルトの選択肢です。過去に採択された提案を調整用の参考として公開します。PyCon US は初登壇者に過去の提案を案内しています。第1回のイベントにはアーカイブがないため、1段階下に戻り、公開した基準と適切に分割されたフォームで調整します。
• 応援メッセージ - 労力はほぼゼロで、常に含めるべきですが、これだけでは不十分です。「新しい登壇者を優先する」と明記すること自体が、出典のある公開基準の1つです。
• 提案メンタリング - 十分な支援を受けていない選択肢です。CFP と並行して、応募前に構造化されたペアリングプログラムを別途実施します。PyCon US の Proposal Mentorship は、この仕組みを記録した実例です。実施条件：ボランティアメンターのプールがあること（Q9）、そして締め切り前にメンターとのペアリングを行えるだけの長さが募集期間にあること。この段階は、募集期間を長くするタイムラインと連動します。

プロモーション

カンファレンスの主催者も CFP プラットフォームも、応募が実際にどのチャネルから届いたかをチャネル別に公表していません。順位付きのチャネル一覧を作り上げるのではなく、その事実を率直に伝えてください。出典があり、重要な要素となるものは3つです（references/published-call-evidence.md に原文を掲載）。

• 募集開始時だけでなく、募集期間全体を通してプロモーションを続けます。募集期間を長くする段階で必要なコストは、ここにあります。
• 具体的な投稿順序（Write the Docs）：告知文を書き、ブログに投稿し、その投稿へのリンクをツイートしてから、1～2時間待って一斉メールを送信します。この遅延により、より広い配信先に情報が届く前に、コミュニティが誤りを見つけられます。
• 公平性に関する警告（DevOpsDays）：「テック業界で過小代表されている人々は、CFP に応募する可能性がはるかに低いです」。多様性が目標なら（Q8）、そうしたコミュニティに積極的に働きかけましょう。公開募集だけでは実現できません。積極的に働きかける方法として、出典のある仕組みが2つあります。名前を挙げたコミュニティグループの一覧を維持し、テンプレートの連絡メールを用意する方法（jlengstorf/awesome-speaker-diversity）と、同じ取り組みをカンファレンス規模で行う具体的な先例として、PyCon 2010 が CFP の配布先をカテゴリ別にまとめたリストです。

失敗パターン

• 基準が明示されていない。 評価基準はあるのに募集要項に記載されていないため、不採択の理由が恣意的に見え、翌年の応募者募集にも悪影響が及びます。根拠のある実践では、募集要項そのものに6つの基準を記載します。
• 方針のない特典の約束。 予算の確定前に旅費や謝礼について告知すると、根拠のある税金・ビザ・利益相反の落とし穴にはまります。募集要項では確定した最低額を示し、それ以上は約束しません。
• 形だけのブラインド審査。 ブラインド審査を必須と告知しても、自由記述欄から漏れる身元情報を管理できていなかったり、公開されたフェーズの区切りもないまま、プログラム編成のために密かに身元情報を再び参照したりします。仕組みを公開するか、記名審査を選びましょう。
• 長い募集期間を放置する。 T-7.5か月にCFPを開始しても、告知を1回行っただけで継続的な広報をしなければ、募集期間の中盤は沈黙したままです。長い募集期間は、早く開始するだけでなく、広報を続ける責任も伴います。
• 最低基準を下回るCFP。 イベントの6週間以内に締め切る場合や、募集期間が1か月未満の場合、根拠のある4〜6週間の渡航準備期間を無視するよう登壇者に求めることになります。公募を取り下げ、招待制に切り替えましょう。
• すべてを1つの入力欄に詰め込む。 トピック、概要、「なぜ自分なのか」をすべて1つの要旨に書かせると、どの要素も評価できません。フォームを分ければ、トピックの質と登壇者との適合性を別々に審査できます。
• 不適切な形式を提示する募集。 選定した構成にない形式を募集要項に記載したり、構成にはある形式を記載しなかったりすると、スケジュールに組み込めない応募が集まります。形式の選択肢は上流工程から引き継ぐものであり、CFPの段階で決めるものではありません。
• 検証方法のないベンダー向けの規定。 応募者が判断できる基準を示さずに「営業目的の発表は禁止」と告知すると、創業者は有用な学びも自己検閲する一方、営業目的の発表は通過してしまいます。代わりに、学びを参加者にどう還元するかを問う質問を公開しましょう。
• 変化の速い分野で、数か月前にすべての枠を埋める。 募集締め切り時点でプログラム全体を埋めてしまうと、当日の最も注目されるトピックが抜け落ちます。公募対象外の枠を確保し、そのことを明示しましょう。
• 応募超過を失敗と見なす。 応募の大半を不採択にするのは、健全なCFPでは通常の状態です（測定方法を参照）。応募数への対処は、募集を狭めることではなく、審査能力を高めることです。

測定

文書で確認できるベンチマークは明記しています。それ以外は、CFP開始前に設定するしきい値です。

• 応募数と採用枠数の比率：PyCon US 2025では、938件の提案のうち15％を採用しました。およそ6.5対1です。Swyxのベンチマークでは、実績のあるカンファレンスの応募者プールは200人から800〜1,200人であり、人気の単一トラックイベントでは、応募超過が8〜30倍になるのが一般的です。事前の需要を測る指標として、初回のCFPでも2〜3対1であれば強いシグナルです。この開催可否の判断は、samber/dev-event-organizer-skills@event-market-fit の範囲に含まれます。
• 初めて応募する人の割合：DjangoCon Europe 2024では、138人の応募者から174件の提案があり、そのうち51人が初登壇者でした。応募数だけでなく、応募者の多様性も活気を測る指標です。
• 方針に合わない応募の割合：公開済みの基準で除外される応募（選定対象の中に含まれるベンダーの営業発表など）の割合です。この割合が高ければ、募集要項で基準が伝わっていません。
• 応募のタイミング：募集期間のどの時点で応募が届くかを見ます。中盤に応募が途切れるなら、募集期間の長さではなく、広報計画に問題があったと考えられます。

2〜3項目を選び、それぞれが次回開催でどのような見直しにつながるかを書き留めて、イベント前に記録しておきましょう。

応募要項の作成例

• 「初めてのDevOpsカンファレンスまであと9か月です。応募要項を最初から最後まで整えてください。」
• 「2日間のコミュニティカンファレンスの応募ページを作成してください。スケジュール、フォーム、基準、特典を盛り込んでください。」
• 「応募要項は匿名にすべきでしょうか？昨年、同じ人ばかりが選ばれていると批判されました。」
• 「イベントまであと10週間なのに、講演がまだ一つもありません。今からでも応募を募集できますか？」

期待される出力：以下を含む応募要項の設計書。

1. イベント日から逆算したスケジュール。応募受付開始・締切・通知の各日程を含めます。
2. 提供する各形式のフォーム項目と、応募数の上限。
3. 公開する選考基準の文面。
4. 匿名化の方針と、募集要項に記載する具体的な仕組み。
5. 登壇者への特典に関する説明。
6. 公平性に関する根拠付きの注意事項を含む、告知・アウトリーチに関するメモ。
7. 選考、登壇者の発掘、スケジュール作成への引き継ぎ計画。

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

参考資料

• references/submission-form-catalog.md - 項目ごとのカタログと例、4種類の形式から選べるPyConのメニュー、応募数の上限、ツールの機能チェックリスト（具体的なプラットフォームの例を含む）、および適切なフォーム例と不適切なフォーム例。
• references/published-call-evidence.md - DevOpsDaysのスケジュールと6つの選考基準の原文、登壇者への特典と旅費助成に関する文面、匿名化をめぐる賛否両方の根拠、初登壇者向けの仕組み、十分に代表されていない層からの応募に関する注意事項と根拠付きのアウトリーチ手法2つ、根拠付きの告知順序のパターン、応募過多のベンチマーク。

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

• samber/dev-event-organizer-skills@event-format-selection - この募集要項で提供するセッション形式の構成を選定します。
• samber/dev-event-organizer-skills@event-talk-selection - この募集で集まった内容を審査・選定します。評価グリッド、委員会、バイアス管理、通知を扱います。
• samber/dev-event-organizer-skills@event-speaker-sourcing - 招待登壇者向けの並行チャネルと、スケジュールの都合で一般公募を中止する場合の代替策を扱います。
• samber/dev-event-organizer-skills@event-speaker-experience - セッション形式ごとに定めた録画方針を含め、この募集要項で約束した特典を提供します。このスキルで明示的な未決事項とされている謝礼の問題を改めて取り上げることはありません。
• samber/dev-event-organizer-skills@event-schedule-design - 採択されたプログラムを後続のトラック構成に配置します。
• samber/dev-event-organizer-skills@event-market-fit - このスキルで判断を委ねている、応募過多に関する需要の分析を担当します。