event-talk-selection

イベント講演の選考

募集要項（CFP）ですでに集まった提案を審査するプロセスを運営します。誰が審査し、どのような基準を使い、何ラウンドで審査するのか、そして応募者全員にどのような結果を伝えるのかを決めます。

このスキルでは、次のことは行いません。

• 募集要項を設計すること。スケジュール、フォーム、公開する審査基準、匿名化の 方針 は samber/dev-event-organizer-skills@event-cfp-design の範囲です。その方針は引き継ぎ、改めて決め直すことはありません。
• 募集とは別に登壇者を探すこと。その並行チャネルは samber/dev-event-organizer-skills@event-speaker-sourcing です。招待した提案をどのように選考プロセスに加えるか、明確なルールを設ける必要があります（ワークフローを参照）。
• 採択した講演をプログラム表に配置すること。それは samber/dev-event-organizer-skills@event-schedule-design の範囲です。
• ハッカソンで制作されたプロジェクトを審査すること。これは同日中に完結する、構造の異なるスケジュールで進行します。samber/dev-event-organizer-skills@hackathon-judging を参照してください。

以下に示す各選択肢の順位はすべて標準的な目安であり、絶対的なルールではありません。状況や実行する人によって変わります。インタビューの後、主催者についてすでに分かっていることを踏まえて、3つの選択肢をすべて順位づけし直してください。次のいずれも、標準的な順位を覆す可能性があります。

• すでに存在する委員会。
• すでに料金を支払っているツール。
• 審査員が応募者の文体から本人を見分けられるほど小さなコミュニティ。
• 変更できないプログラム発表日。

インタビュー

質問は一度に1つずつ行い、可能であれば選択式にします。以下の選択肢は、効果が出るまでの時間、見返りが持続する期間、必要な労力が大きく異なるため、質問3〜5を設けています。これらの順位をユーザーに代わって決めることはできません。

1. 応募は何件あり、枠はいくつありますか？（その比率がプロセス全体を左右します。提案が40件の募集と2,500件の募集は、規模が違うだけで同じ問題なのではなく、別の問題です。）
2. 公開した募集要項では、匿名化、審査基準、結果通知日について何を約束しましたか？何かを設計する前に募集要項を確認してください。プロセスでは、都合のよい内容ではなく、公開した内容を実行する必要があります。
3. プログラムの発表日はいつで、何週間残っていますか？（変更できない期日がある場合、各選択肢にかける時間を短縮するのではなく、実施できない選択肢を除外します。）
4. 今回限りの開催ですか、それとも年々積み重なる資産を築く機会ですか？（継続的に積み重ねることが目的なら、時間のかかる選択肢の順位が上がります。提案ごとのフィードバック、実際に機能する委員会、年ごとに一貫して使える文書化された評価基準などです。）
5. 労力の上限はどれくらいですか。実際に提案を読む人は何人で、各人は何時間使えますか。また、意見がまとまらない場合は誰が裁定しますか？
6. イベントの主催者は、コミュニティカンファレンスですか、それともベンダー／ユーザーカンファレンスですか？（以下の区分を参照。）
7. 同じプログラムに招待講演やスポンサーに関連する講演はありますか。また、募集要項にはそれらと一般応募の扱いについて記載がありますか？
8. どのようなバランス目標を掲げていますか。初登壇者、過小評価されている立場の登壇者、地域の登壇者と遠方からの登壇者、トピックや勤務先の多様性などです。どれを公開し、どれを内部向けにしていますか？
9. 選択肢の順位を見直すうえで考慮すべきものとして、すでに何がありますか。継続参加する委員会、前回の評価基準と寄せられた不満、審査モードを備えたCFPツール、過去の決定の記録などです。
10. 応募フォームでは、経済的支援や旅費助成の申請も受け付けていますか？
11. 複数トラックのプログラムですか、それともシングルトラックですか？
12. 実際に会場にいるのはどのような人たちですか。専門家、分野に移ってきた開発者、非技術系の参加者、またはその混合ですか？イベントの宣伝文句ではなく、前回の参加状況をもとに答えてください。参加者が混在する場合、プログラムとの適合性を確認する工程と、採択された各講演に付随する説明が変わります。
13. 主催者、その勤務先、またはスポンサーのスタッフも応募しますか？最初の提案を読む前に、その場合のルールを決めてください（「主催者およびスポンサー関係者の応募」を参照）。

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

イベントの主催者によって選考方法は変わります。このコレクションの形式やCFPスキルが主張するのと同じように、置き換えが必要です。

• コミュニティ主催カンファレンス - 公募枠がプログラムの中核です。譲れない原則は、「スポンサーが講演枠を購入することは一切できない」ということです。このスキルの情報源はすべて、この立場に基づいています。
• ベンダー／ユーザーカンファレンス - コンテンツの大半は招待制で、ベンダーのアーキテクチャを中心に構成されています。レビューの対象となるのは、全体として厳選されたプログラムのうち、コミュニティ向けの一部です。以下の仕組みはその部分にも適用されますが、バランスの調整では、参加者だけでなくベンダーのストーリーも考慮します。

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

ワークフロー

1. ヒアリングを行います。まず公開済みの募集要項を読みます（Q2）。以降のすべての作業で、募集要項を遵守する必要があります。
2. 以下のメニューから委員会モデルを選び、応募数（Q1）と作業時間の上限（Q5）に合わせて規模を決めます。
3. そのモデルに対応するルーブリックを選びます（「採点ルーブリック」を参照。ルーブリックは委員会モデルに従うもので、自由に選べるものではありません）。誰かが採点を始める前に、ルーブリックを書き出しておきます。レビューの途中で作られたルーブリックでは、先に読まれた応募だけを再採点することになります。
4. 匿名化の実施レベルをメニューから選び、募集要項で公開した方針の範囲内で決めます。担当者を実名で指定します。募集要項でブラインドレビューを約束している場合は、身元情報をどの段階で、誰に対して再び明らかにするのかを、今のうちに書面で決めます。
5. 採点を開始する前に、利益相反についてレビュアーに説明します。利益相反が発覚してからではありません（下記参照）。忌避によってレビュー担当者が減りすぎた場合の代替策も決めておきます。
6. 第1ラウンドを実施します。すべての応募をルーブリックに基づいて採点し、すべての採点にコメントを添えます。コメントの記載は必須であり、これがあって初めて、第2・第3ラウンドや、実際に役立つ不採用理由の通知が可能になります。
7. スコアに基づいて候補を絞り込みます。お気に入りの応募に合わせて基準を動かさないよう、順位を見る前に、しきい値または割合として選考基準を定めておきます。
8. プログラムとの適合性を確認するのは、応募全体ではなく候補に絞った後です。トピックの広がり、所属先の多様性、地元と遠方のバランス、初登壇者、そしてQ7で招待講演を決めた方法などを確認します。以下の現場から報告された確認事項も加えます。ベンダー向け講演での学びの応用可能性、トピックの新鮮さ、参加者の幅広い層に対応する深さの段階づけ、開催回のブランドとしての約束です。この段階で、スコア順の一覧がプログラムになります。また、現場で最も記録が残されていない段階でもあります（「失敗パターン」を参照）。次回の委員会から質問されることになるため、何をどのような理由で優先したのかを記録してください。
9. 講演枠を埋めてから、通知を送る前に待機リストを作ります。予備候補の順序を明確にします。
10. 次の順番で通知します。
    • まず採択者に、回答期限を添えて通知します。
    • 採択が確定してから、不採択者に通知します。
    • 待機リストに登録された応募者には、待機中であること、いつまでに結果がわかるか、そして空き枠が出ない可能性もあることを明確に伝えます。
11. 形式とトラックのタグを付けた採択者リストを、samber/dev-event-organizer-skills@event-schedule-design に引き継ぎます。次回に備えて、採択率とバランスの結果を記録します。

レビューを開始する前に、委員会、ルーブリック、匿名化、選考基準、連絡計画の各セクションを順に提示し、確認を受けます。採点が始まった後にルールを変更すると、すでに読まれた応募の評価は無効になります。

ハーネスに永続メモリがある場合は、ルーブリック、選考基準、採択率、バランスの結果、そして次回の変更を促すことになる具体的な苦情を記録します。

審査委員会モデル

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

• 労力（審査員数、調整、審査回数、日程）：多段階カスケード > 小規模な合意形成委員会 > 個人による選考
• 価値、防御可能性、バイアスの希釈：多段階カスケード > 小規模な合意形成委員会 > 個人による選考
• 価値、プログラムの一貫性：個人による選考 == 小規模な合意形成委員会 > 多段階カスケード - 同順位とするのは論点を避けるためではなく、根拠に基づいています。どちらもすべての判断を一つの場に集め、プログラム全体を常に見渡せる状態に保ちます。この軸が測るのはその点だけです。カスケード方式は、審査員数をどれだけ増やしてもこれにかないません。後段の審査者が目にするのは、前段が引き継いだものだけだからです。
• 効率性：小規模な合意形成委員会 > 個人による選考 > 多段階カスケード

優越関係の確認：3組を比較し、厳密な優越関係はゼロです。 構成上、順位は整っていますが、構成上整っているだけでは合格とはなりません。以下の2つの要因が、この3つの方式の比較を妨げています。

• カスケード方式と他の2方式の比較では、相反する価値軸が障壁となります。防御可能性では優位ですが、一貫性では劣ります。
• 残る委員会と個人選考の比較では、労力だけが障壁となります。委員会は防御可能性で優位、一貫性では同等ですが、なおコストがかかります。

この確認では、順位の誤りは見つかりません。効率性の順位は以下の議論に基づいています。

• 小規模な合意形成委員会 - 小規模なイベントでデフォルトとされ、最も多く記録されている方式です。投票権を持たない専任の匿名化担当者に加え、およそ4～6人の採点者、同期形式のディスカッション1回、レターグレードによる評価基準、およそ5件の講演を載せた予備リストを用意します。全応募を一つの審査会で確認できる、単一トラックまたは2トラックのイベントに適しています。

• 個人による選考 - 主催者1人、または2人で登壇者を手作業で選びます。調整コストはほぼゼロで、単一トラックの主催者は、これを近道ではなく編集上の責任として説明しています。招待制または小規模なプログラムでは妥当な選択です。公募で基準を公開し、ブラインド審査を約束している場合は、順位を下げるのではなく、選択肢から外してください。1人の審査者が自分自身をブラインド審査することはできず、審査から除外することもできません。そのため、この方式を最下位に置いたままにすると、公募で退けたプロセスをひそかに再び持ち込むことになります。

• 多段階カスケードは、採用されにくい選択肢です。防御可能性と労力の両方で最上位にあるため、効率性の観点から選ばれることはありません。確立されている形式は次のとおりです。

  1. トラック委員会が採点します。
  2. 得点上位30％がトラックチェアに進みます。
  3. トラックチェアがそのうち約30％を、コメントを必須として次の段階に進めます。
  4. 共同チェアが最終決定を下します。

  採用条件：

  • マルチトラックのプログラム（Q11）。
  • 一つの審査会では全件を確認できない応募数。
  • 競合する雇用主からの公の精査にも、判断の妥当性を保つ必要があるイベント。

  規模に関する注記：上記の数値は、記録されている2つの例に基づいています。小規模な単一トラックのカンファレンスでは審査員がおよそ5人、大規模なマルチトラックイベントでは3段階の構成です。3つ目の分散型プールモデル（下記「採点基準」を参照）は、この資料群で唯一の、提案1件あたりの審査員数を示す実例です。すなわち、応募が追加審査の対象として積極的に提示されなくなるまでに、3件以上のレビューを行います。この3つの例の間に、妥当な曲線はありません。自分たちの審査能力に照らして補間し、そうしていることを明記してください。

採点基準

この採点基準は、個別に順位付けするのではなく、委員会モデルに従います。上流ですでに選択が決まっている候補を順位付けするのは、見せかけの精度にすぎないためです。確立された採点基準は3種類あり、それぞれ異なる場面を想定して設計されています。

• レターグレードの支持者尺度。委員会が集まって議論する場合に適しています。

  • A：積極的に支持します。
  • B：好意的ですが、支持はしません。
  • C：中立です。
  • D：反対を主張します。
  • X：棄権です。査読者は、発表者を特定できたと思っています。

  評価は、提案ごとの最良・最悪の組み合わせ（「AC」）として集計し、平均は取りません。また、真剣に検討するための実務上の最低ラインは、Aが少なくとも1つあることです。この尺度は支持の度合いを測ります。まさに議論の時間に費やすものです。

• 複数基準の星評価尺度。査読者同士が顔を合わせることがない場合に適しています。内容、新規性、関連性、発表者との適合性について、半星刻みの5段階で評価し、すべての評価に書面でのフィードバックを必須とします。この尺度は比較可能性を測ります。集計して候補を絞る際に必要なものです。

• 数値の0〜3尺度。固定された委員会ではなく、査読プラットフォームを通じて割り当てられた分散型の査読者プールに適しています。各スコアには書面での意味（強く反対、どちらかといえば反対、どちらかといえば賛成、強く賛成）があり、すべての査読にコメントが必須です。また、投稿に3件以上の査読が付くと、積極的に再表示されなくなります。この尺度は、レター尺度の支持度シグナルも、星評価尺度の4基準の内訳も用いずに、プラットフォーム規模で単純な採否の傾向を測ります。

レター尺度を平均したり、星評価尺度の結果を議論で覆したり、数値尺度の4つの意味を単なる「高い／低い」にまとめたりすると、それぞれの尺度が想定して設計された特性が失われます。基準の全文、集計方法、実例はreferences/committee-models-and-rubrics.mdに記載されています。

匿名化の実施方法

どの方針を採用するかは、すでに通話で決定しています。このメニューは、その方針をどの程度まで実施するかを示すものです。

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

• 労力（応募ごとの取り扱い、役割分担、審査担当者への指示）：専任の匿名化担当者 > プラットフォームレベルでの非表示 > 記名審査
• 価値、情報漏えいへの耐性：専任の匿名化担当者 > プラットフォームレベルでの非表示 > 記名審査
• 価値、採点時に利用できる情報：記名審査 > プラットフォームレベルでの非表示 > 専任の匿名化担当者 — ここに同点はありません。プラットフォームでの非表示は著者欄を隠すだけで、応募者がタイトル、概要、アウトラインに書いた内容はそのまま残ります。一方、匿名化担当者はそれらも書き換えます。匿名化を行うと審査担当者が実際に見る情報は減ります。その損失は、この順位に伴うコストであり、丸め誤差ではありません。
• 効率：プラットフォームレベルでの非表示 > 記名審査 > 専任の匿名化担当者

優越性の確認：3組、厳密な優越関係はゼロです。 構造上、優越性の関係がないだけで、合格ではありません。3組すべてを妨げる仕組みが1つあります。価値に関する2つの軸は正反対なので、情報漏えいへの耐性が高い段階ほど審査担当者が見られる情報は少なくなり、どの段階も両方で同等以上にはなれません。

どの組でも労力の軸には到達せず、3つ目の軸も示されていません。確認では何も見つかりません。以下の順位は、検証済みではなく、論拠を示したものです。

• プラットフォームレベルでの非表示 — 募集要項でブラインド審査を約束した場合のデフォルトです。ツールは初回審査中、著者情報を非表示にします（一般的なCFPプラットフォームには、オプションで選べる匿名モードがあります）。文書化されている制限については、審査中に初めて判明することがないよう、募集締め切り前に応募者に明示する必要があります。プラットフォームが隠すのは著者欄であり、著者がタイトル、概要、アウトラインに書いた内容ではありません。
• 記名審査 — 募集要項で匿名化を約束していない場合のデフォルトであり、実務上の分野標準です。公表された基準が、匿名化では担保されない公平性を補う場合にのみ、誠実な選択となります。
• 専任の匿名化担当者 — 選ばれにくい選択肢です。1人か2人だけが応募内容の原文を見て、そのいずれにも採点を行いません。特定につながる情報を角括弧付きのプレースホルダーに書き換え、講演自体の主題としてのアイデンティティは意図的に残し、応募順から応募者が特定されないようランダムなIDを割り当てます。情報漏えいへの耐性は最も高く、労力も最も大きいため、効率の軸で選ばれることはありません。優先する条件：
  • ツールが何を隠しても常連参加者を見分けられるほど、委員会の規模が小さいこと。
  • Q10に紐づくこと：同じフォームで経済的支援の申請を受け付ける場合。匿名化は、資金を申請しても提案の評価に不利にならないという約束を実施するための仕組みです。
  • 前回開催について、公平性に関する未解決の苦情がコミュニティにあること。

格下げではなく、削除してください： 募集要項で記名審査を公表した場合、今開催では匿名化を選択肢から外します。審査の途中で後付けしても、審査担当者はすでに名前を読んでいるため、何も匿名化できません。それどころか、募集要項で実際に約束した内容を破ることになります。

この制限を、計画書と委員会の両方に明確に伝えてください。 匿名審査によって属性別の採択結果が変わるかどうかを測定した証拠はありません。

存在するのは、主催者が表明した意図と仕組みの設計だけで、それ以上のものはありません。ブラインド審査をプロセス上の約束として行うことには正当性があります。しかし、それが公平性を実証した結果であるかのように示す主張は、証拠によって裏付けられていません。

利益相反

確立されているルールは自己申告制であり、異なる二つの不正を対象としています。どちらもレビュアー向けの説明に含めてください。

• 親しく一緒に働いている同僚、または関係のある組織や競合する組織からの応募については、採点してから開示するのではなく、質問をスキップして採点を辞退するようレビュアーに伝えます。雇用主の立場ではなく、「イベントの立場」でレビューしてください。
• 匿名化された登壇者が誰か特定できたと思われる場合は、辞退してください。

この二つは、それぞれ異なる不正を防ぐものです。

率直に言えば、どちらも当事者の良心に委ねられた辞退です。利益相反の申告を登録する仕組み、エスカレーション経路、監査の仕組みは、公開されたものがどこにもありません。そのため、独自に追加するエスカレーション手順は自ら設計したものとして扱い、その旨を明記してください。紛争が起きてからではなく、あらかじめ次の二点を決めておきます。

• レビュアーが辞退しない場合、誰が裁定するのか。
• 辞退によってレビュアーが減り、スコアを比較できなくなった提案をどう扱うのか。

主催者およびスポンサー関係者による応募

上記のレビュアー向け説明は、他の人の提案を採点するレビュアーを対象としています。応募者でもある主催者については扱っていません。主催者は登壇者としても都合がつきやすいことが多いため、小規模なミートアップのチームでは毎回問題になります。調整して使える基本方針は次のとおりです。

• 開示する。 主催者自身の提案は、採点開始前に委員会の他のメンバーへその旨を示します。ブラインドレビューでも、主催者は自分の文章を知っています。自分の提案に対しては匿名になれないため、ラベルを付けてもプロセス上の利点は損なわれません。
• 自分の講演と雇用主の講演は辞退する。 主催者は、自分の提案や雇用主からの提案を採点しません。上記と同じ「質問をスキップする」ルールを適用します。
• 頻度に上限を設ける。 主催者が1回の開催または1年間に担当できる講演数について、主催者自身で上限を設定し、記録に残します。上限がなければ、主催者チームがいつの間にかプログラムを占めることになります。
• 辞退を認める。 自分が主催するイベントでは一切登壇しないことを望む主催者もいます。それを、考え直すよう説得すべき遠慮ではなく、正当な恒常方針として扱います。
• スポンサー関係者の登壇数に上限を設ける。 現在のスポンサーに雇用されている登壇者も、同じ審査を受けます。また、プログラムには、そのような登壇枠の数について主催者自身が設定した上限を設けます。コミュニティを重視する姿勢を保ち、枠を購入できないことを明確にします。編集の独立性に関する文言は、samber/dev-event-organizer-skills@event-sponsor-agreement を通じてスポンサー契約そのものに盛り込み、上限がスポンサーも署名した条件になるようにします。そうすれば、主催者が便宜を拒んでいるわけではありません。

各提案に、開示と辞退の記録を添えてください。後からプログラムが自己利益のために作られたように見えたとき、それを守るのは記憶ではなく、その記録です。

実践者が報告するプログラム適合性の確認項目

これらは実測結果ではなく、現場での経験に基づくヒューリスティックです。そのように提示してください。詳細と具体例については、references/program-fit-field-reports.md を参照してください。

• ベンダーやスタートアップの講演に対する学びの転移テスト。 質問は一つです。聴衆が翌日、製品名を忘れても、その学びを覚えているでしょうか。持ち帰るものが、どのスタックにも応用できる学びや刺激であれば、スタートアップやベンダーも講演できます。持ち帰るものが製品そのものである講演は不合格で、商業的なデモは論外です。採択通知メールに商業的コンテンツに関するルールを追加してください（参考資料を参照）。
• トピックの新鮮さ。 変化の速い分野では、昨年の注目トピックも数か月で古くなります。「最先端」や「最新」をうたう内容はすべて、応募締切日ではなく、実際のイベント開催日を基準に確認してください。レビュー後に、あらかじめ決めた数の枠を空けておき、ニュースの動向に近い時期に招待制で埋めてください。どの枠を空けておいたか、その理由とともにプログラム適合性の記録に記載してください。
• さまざまな参加者がいる会場に合わせた深度の勾配（Q12 に対応）。1 つのトラックでも、技術者と非技術者が混在する会場に対応でき、トラックを分ける必要はありません。採択した各講演には、ほぼ全員が理解できる内容から始め、会場の大半が理解できない内容で終えるよう伝えてください。実践者によるヒューリスティックでは、講演の終わりまでに会場の大半がついてこられなくならなければ、深掘りが足りません。両端の内容を扱えるかどうかで応募を評価し、夜の進行順を samber/dev-event-organizer-skills@event-schedule-design に引き継いでください。
• 期待する聴衆像ではなく、実際の参加者に合わせたレベル。 実践者によると、家庭の事情や都合が合わないことから、一般向けの夜間ミートアップには専門家を集めにくく、常連参加者はこの分野に入ろうとしている開発者が中心になる傾向があります。各講演の難しい内容は、その会場に合わせてください。参加しない専門家向けに組まれたプログラムでは、実際に参加する人を取りこぼします。
• ブランドとして掲げる約束。 イベントが毎回、記憶に残る瞬間（「目を覚まさせるような話」や、1 か月後も話題に上る講演）を約束しているなら、選考だけではその実現を維持できません。レビュー時に共通の良質な講演のフレームワークを適用し、採択後には samber/dev-event-organizer-skills@event-speaker-experience を通じたコーチングとリハーサルを行って支えてください。今回の開催でコーチングの体制を整えられないなら、公に約束を果たせなくなるよりも、約束を控えめにしてください。

ウェイトリストと不採択の通知

誰かに通知する前に、ウェイトリストを作成します。公表されている一例では、単一トラックのプログラムに対して予備の講演を5件ほど用意します。不採択のリスクに合わせて規模を調整し、推定であることを明示してください。ウェイトリストに載った講演が実際に繰り上げ採用される頻度を示す公表データはないため、ウェイトリストに載った登壇者には確率を伝えず、いつ結果がわかるかを伝えてください。

不採択の通知にかける労力の順位（標準的な考え方であり、絶対ではありません。Q4とQ5では順位を再検討します）：

• 労力（不採択1件あたりの主催者の時間を、不採択が大半を占める応募数で乗じたもの）：提案ごとのフィードバック > 不採択通知と選考基準の再掲 > フォームによる不採択通知
• 価値（次回も応募する提出者と、翌年の応募者層を充実させる評判）：提案ごとのフィードバック > 不採択通知と選考基準の再掲 > フォームによる不採択通知
• 効率：不採択通知と選考基準の再掲 > フォームによる不採択通知 > 提案ごとのフィードバック

優越性チェック：3組、厳密な優越関係はゼロです。 構造上きれいに見えるだけで、それだけで合格とはなりません。

価値と労力の順位は同じなので、1つの仕組みがすべての組み合わせを阻みます。より多くの提出者を呼び戻す段階ほど、不採択1件あたりの主催者の時間が確実に増えます。ほかに、組み合わせを阻んだり救済したりする要素は示されていません。効率の順位は、以下の議論に全面的に依存しています。

• 不採択通知と選考基準の再掲 — 標準的な方法です。温かみのあるテンプレートに、公募時に公表した選考基準と採択率を添えます。採択率には実質的な役割があります。提出者1人あたりの追加コストなしに、不採択を判定ではなく算術上の結果として捉え直せます。
• フォームによる不採択通知 — 短く、丁寧で、全員に同じ内容の通知です。手間がかからず、誠実な方法ですが、沈黙しないこと以上の価値はありません。
• 提案ごとの書面フィードバック（リソース不足になりがちな選択肢）：レビュー担当者のコメントを、表現を整えて送ります。次の条件がそろえば採用を検討できます。
  • すべての応募にコメントを書けるほど、応募者数が少ない。
  • 初参加の登壇者が多く、登壇者層の拡大を重視している。
  • 評価基準で書面コメントがすでに必須となっており、文章がほぼ追加コストなしで存在し、編集だけが残っている。

一般的なCFPプラットフォームの少なくとも1つでは、不採択通知に個別のフィードバックを添付できます。そのため、制約となるのは仕組みではなく、編集にかかる時間です。

ブラインド審査のプロセスから参考にできる構造上の工夫が1つあります。採択された登壇者は、誰かが運営上の調整を担う必要があるため匿名解除されます。一方、不採択となった提出者には、審査チームがその人物を知ることなく通知します。不採択となった提出者の名前を誰が知ることになるのか、自分たちのチームについて決めてください。テンプレートと通知の順序については、references/decision-communication.mdを参照してください。

失敗しやすい点

• 匿名化の見せかけ。 ブラインド審査を発表した後、フェーズの境界を公表せずに身元情報を再び確認したり、ツールが「処理してくれる」からと自由記述に含まれる情報漏えいを放置したりします。身元情報がどの時点で明らかになるかを公開するか、正直に記名審査を行いましょう。
• 評価基準のない合意形成。 書面による評価基準がないまま委員会が集まって話し合うと、最も強く主張した人の意見に収束し、半年後には不採用の理由を説明できなくなります。採点を開始する前に、評価基準を書面にしておきましょう。
• 利益相反の見落とし。 説明資料も辞退ルールもなく、誰も禁止していないために、審査員が同僚の提案を採点してしまいます。ルールの作成には1段落で済みますが、機能するのは採点前だけで、採点後では手遅れです。
• 待機リストへの約束。 「あなたが次の順番です」や「必ず枠を用意できます」は、誰にも守れない約束です。日付を約束し、確率は決して約束しないでください。
• 記録のないバランス調整。 プログラムへの適合性を確認する段階で、スコアの高い講演を多様性のために差し替えながら、その経緯を何も記録しません。次回の委員会は、知らないまま同じ議論をやり直し、質問した応募者には誰も答えられない返答をすることになります。
• 応募超過をトラック不足と読み違えること。 応募数と枠数の比率が高いのは需要の兆候であり、サイクルの途中でトラックを追加せよという合図ではありません。トラック数は上流の samber/dev-event-organizer-skills@event-format-selection で決定済みです。需要の評価は samber/dev-event-organizer-skills@event-market-fit で行います。
• 主催者による自己選定。 主催者が応募し、互いの講演を採点し、チームのメンバーでプログラムを埋めてしまいます。開示し、審査を辞退し、上限を設けましょう。そして募集を締め切る前にルールを決めてください。
• 教訓として認められた製品紹介。 ベンダーの提案がよく見えても、実際にはデモの披露になってしまうことがあります。審査時に教訓の移転可能性を確認し、採択通知で商業的な内容に関するルールを明示して、登壇者が資料を作成する前に伝えましょう。
• 最新の状況を反映しない内容。 何か月も前に固定したプログラムが「最新」を約束しながら、前シーズンのニュースを届けてしまいます。変化の速い分野では、直前まで枠を空けておきましょう。
• 参加していない聴衆を想定したプログラム作り。 実際にはその分野に進もうとしている開発者が集まる会場なのに、参加しない専門家向けに講演を調整してしまいます。参加状況から会場の様子を把握しましょう（Q12）。
• 招待講演を一般公募と同じ審査対象にすること。 招待講演者は、その人自身が招待した理由です。そのため、一般公募と一緒にブラインド審査すると、双方の審査を損ないます。事前に審査の枠組みを決めておきましょう（Q7）。

測定

出典のある数値にはその旨を明記しています。それ以外はすべて自ら設定する基準なので、提示する際にはそのように記してください。

• 採択率（目標ではなく、調整の参考値）：

  • PyCon US 2025では、938件の提案のうち15%が採択されました。
  • KubeCon EU 2024では、2,541件のうち9%が採択されました。
  • 学術系の会議は採択ロジックが異なり、数値も高めです。CHI 2024では26.4%でした。この基準はそのまま転用できません。

  自分たちの数値を記録しましょう。回ごとに大きく変動する場合、通常は応募者層ではなく募集内容が変わったことを意味します。

• 明示した目標に対するバランスの達成状況（出典と独自基準の混在）：採択者の中で、初登壇者、所属先の分散、地元と遠方からの参加者の割合を数え、約束した内容と比べます。イベントのレベルで定量化された目標が1つ記録されています。「可能であれば、初登壇者を登壇者の少なくとも50%にすること」に加え、エンドユーザー企業からの登壇者を少なくとも25%にすることです。特筆すべきなのは、実際に審査員が目にする評価基準には、これが項目として含まれていない点です。目標を設定するなら、審査前に、それが目標なのか必須基準なのかを決めましょう。

• 審査員の対応範囲（独自基準）：審査員1人あたりの提案数と、利益相反による辞退で審査から外れた審査員の数を記録します。日程内に応募全体を審査できない委員会では、プロセスの不備が発覚するのが遅すぎます。

• 不採択者の再応募率（独自基準）：不採択となった応募者が、次回の開催時に再応募する割合です。不採択の連絡に手間をかける価値があったかどうかを測る、唯一の実質的な検証方法です。

2つか3つを選び、それぞれの数値がどのような見直しにつながるかを書き留め、イベント後ではなく前に記録しておきましょう。

呼び出し例

• 「24枠に180件の応募があり、レビューを担当できる主催者が5人います。どのように進めればよいでしょうか？」
• 「2トラックのカンファレンスのCFP向けに、レビュー委員会と評価基準を設定してください。」
• 「CFPではブラインドレビューを約束しました。実際にはどのように進めればよいでしょうか。また、ブラインドレビューで解決できないことは何ですか？」
• 「レビュー担当者の1人が応募者と仕事上の関係にあります。どのようなルールにすべきでしょうか？」
• 「採択、不採択、補欠待ちのメールを書き、どの順番で送るかも教えてください。」

期待される出力：以下を含む選考計画です。

1. 指名された役割を含む、委員会のモデルと規模。
2. 明記された評価基準。
3. 匿名化の実施レベルと、どの段階で本人確認情報を再表示するか。
4. 利益相反に関する説明と、調停の代替手順。
5. ランキング前に明示する、審査ラウンドの構成と絞り込みルール。
6. トレードオフを記録したプログラム適合性の審査。
7. 補欠待ちの扱いと通知順序、およびメールの草案。
8. 次回開催に向けて記録する指標。

レビュー開始前に検証できるよう、セクションごとに提示してください。

参考資料

• references/committee-models-and-rubrics.md - 2種類の既存の評価基準を基準文言そのままで記載したもの、段階的選考における割合、文字評価尺度の集計方法、委員会の役割、および肯定・否定の採点例。
• references/decision-communication.md - 採択、不採択、補欠待ちのテンプレート、通知順序と匿名性解除の非対称性、講演者ごとの重複採択への対応、およびプロセスに必要なツール機能。
• references/program-fit-field-reports.md - プログラム適合性の確認項目：商業的な内容に関するルールを含む学びの応用可能性テスト、トピックの新鮮さと直前まで確保しておく枠、参加者のレベルが混在する場に向けた深度の勾配、対象者レベルの実態、およびブランドの約束の連鎖。各項目は未公開と明記されています。
• references/selection-evidence-and-gaps.md - 採択率と応募超過のベンチマーク、多様性に関するルールと目標、パネル構成のルール、およびこの分野で文書化されていない項目の明示的な一覧。

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

• samber/dev-event-organizer-skills@event-cfp-design - このスキルが実行する方針を定める公募を設計します。タイムライン、フォーム、公開する評価基準、匿名化方針などが含まれます。
• 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-sponsor-agreement - スポンサー関連講演者の上限を支える、編集上の独立性に関する条項を扱います。
• samber/dev-event-organizer-skills@hackathon-judging - イベント中に作成されたプロジェクトを、異なる評価基準と当日完結のスケジュールで審査します。講演応募のレビューとは別のものです。
• samber/dev-event-organizer-skills@workshop-program-design - ハンズオン形式の応募で生じる、講演応募にはない形式固有の検討事項を扱います。講師が提示された定員で実施できるか、演習が会場の規模に対応できるかなどです。