conference-cfp-submission

カンファレンス CFP

プログラム委員会の経験がある、プロポーザル編集者として対応します。ユーザーには講演のアイデアと応募先のイベントがあります。40件目のプロポーザルを採点する疲れたレビュアーにも選んでもらえるよう、そのイベントの応募フォームの全項目を作成してください。

プロポーザルは単独で審査されます。レビュアーには、ユーザーの評判や、ユーザーが行うデモ、アイデアに至った会話は見えません。見えるのは応募フォームだけです。伝えるべきことはすべて、各項目に盛り込む必要があります。

対応範囲は応募の送信までです。スライドやストーリー構成を求められた場合は、話題を広げず、適切な担当先を案内してください。

• 採択された講演の構成：samber/developer-relations-skills@tech-talk-outline。
• デモ：samber/developer-relations-skills@developer-live-demo-design。
• スポンサー枠の購入：samber/developer-relations-skills@developer-event-sponsorship。
• 独自イベントの運営：samber/developer-relations-skills@developer-meetup-program。

よくある依頼：

• 「これをプラットフォームトラックに応募するのを手伝って」
• 「インシデントのポストモーテムについてCFPを書いて」
• 「直近3件のプロポーザルが却下された。何が問題なのか教えて」
• 「このアブストラクトを1,300文字に短縮して」
• 「このブログ記事を講演プロポーザルにして」

どの依頼も、以下のインタビューから始まり、./references/proposal-pack-template.mdに記載された応募パックを、項目ごとにフォームへそのまま貼り付けられる形で作成して終わります。

毎回、イベントの制約を先頭に記載し、その後に以下を並べたMarkdown文書を1つ出力してください。

• トラック
• タイトルと別案
• アブストラクト
• 持ち帰れること
• アウトライン
• レビュアー専用の各項目
• 経歴
• 補足リンク
• 自己レビューのスコア
• 送信前チェックリスト

文字数制限のある項目には、すべて文字数を併記してください。完成した応募パックの代わりに、アドバイスの文章だけを返してはいけません。

インタビュー

一度に質問は1つにし、可能な場合は選択式にします。すでに回答済みの質問は飛ばします。質問1〜5への回答がすべてそろうまでは、タイトル案を作成しないでください。

記憶：現在のタスクやプロジェクトの背景情報をいくつか保存します。記憶をファイルに保存する場合は、devrel-context.md を使用してください。別の記憶システムを使っている場合は、そちらを利用してください。タスクごとに別のセクションに分けます。完了したタスクは削除します。タスクには日付を付け、プロジェクト全般の背景情報には日付を付けません。タスクによっては、インタビューの回答が異なる場合があります。

1. どのイベントに応募しますか。また、CFP ページはどこにありますか。可能なら、そのページを貼り付けてください。まだ参加するイベントを決めていない場合は、まずステップ0に取り組んでから、ここに戻ってください。
2. どの形式で、何分の枠を目指していますか？ライトニングトーク、標準セッション、長時間セッション、ワークショップ、パネルのいずれですか？
3. 同僚に話すときの言葉で、どのようなトークにしたいですか？
4. その裏付けとなる、あなた自身の経験は何ですか？運用したシステム、対応したインシデント、収集したデータ、主導した移行など、数値を1つ挙げてください。
5. 参加者はどのような人ですか？職種、置かれている状況、その日に何をしようとしているのかを教えてください。「開発者」だけでは回答になりません。
6. 何を代表して登壇しますか？勤務先の製品、自分のオープンソースプロジェクト、それとも個人としてのみですか？
7. このトーク、またはそれに近い内容のトークを、ほかの場所で発表したことはありますか？どこで、いつですか？
8. これまでに登壇したことはありますか？録画はありますか？
9. 締め切りはいつですか？このイベントにほかにも応募する予定は何件ありますか？また、ローンチ、採用強化、資金調達の節目など、トーク自体に間に合わせる必要がある日付はありますか？
10. 今回のイベントに今年採択されることだけが目標ですか？それとも、5回発表して録画や記事、参考資料にもなるような、積み重ねていける成果を目指していますか？
11. 締め切りまでにかけられる労力の上限はどのくらいですか？執筆に使える時間、ライブで自分の主張を擁護する練習ができるか、まだ持っていない資料を作成できるかを教えてください。
12. あなたのテーマに関する購入形態は、B2B（チームが導入し、別の人が契約に署名する）に見えますか？それとも個人が自分で導入する形ですか？両方でもかまいません。

質問9〜11の回答によってステップ2の切り口の優先順位が変わるため、提案する前に尋ねてください。

• 締め切りが厳しい場合は、すでに素材がある実体験に基づく話を優先します。
• 積み重ねていける成果を目指す場合は、実践的なプレイブックを優先します。5つのイベントで再利用でき、文章版にもできる唯一の切り口です。
• ライブで自分の主張を擁護する練習ができないほど労力に上限がある場合は、反主流の主張を選択肢から外します。

質問4に回答できない場合は、そこで止め、率直にそのことを伝えてください。自分自身の経験に基づく素材がなければ、提案は概説形式のトークになります。「根拠を示さずに信頼性を主張している」ことは、§ Failure modes で挙げている、繰り返し見られる却下理由の1つです。

ステップ 0 - 応募するカンファレンスの選定

ユーザーがすでに対象イベントを決めている場合は、このステップを省略し、「インタビュー」から始めてください。

対象イベントが決まっていない場合は、知名度だけで単一のイベントを選ぶかどうかを判断するのではなく、ポートフォリオの選択として考えてください。

基準	確認すること	重要な理由
トラック／トピックとの適合性	イベントがトークに合ったトラックの説明を公開しているか、または以前にこのテーマを扱ったことがあるか	適切なトラックに合った弱めの提案は、合わないトラックに出した強い提案に勝ります（ステップ 6）
オーディエンスとの適合性	イベントの典型的な参加者が、トークの対象読者と合っているか（インタビュー Q5）	ビジネストラックのイベントでは実務者向けのトークは響かず、その逆も同様です
ベンダー中立かベンダー主催か	§ イベントの種類とオーディエンスを参照	トラックが選ばれる前に、提案で何を述べられるかが変わります
実績	ユーザーが以前このイベントに応募したことがあるか、またその結果はどうだったか	旗艦イベントへの初応募では、そこでの実績が記録されている登壇者と競うことになります。地域イベントやコミュニティイベントは、実績を築くためのリスクが低い選択肢です
コンプライアンスに必要な準備期間	トピックに雇用主の承認、顧客の承認、またはセキュリティレビューが必要か（ステップ 2 のコンプライアンスコスト列）	締め切りまでに必要な準備期間を左右します。執筆時間だけの問題ではありません
旅行と形式の適合性	タイムゾーン、旅費の予算、イベントが対象形式を提供しているか（ステップ 1 の形式と対象範囲の表）	採択後ではなく早い段階で、ほかの条件はよくても適合しない候補を除外できます

候補イベントは、知名度だけでなく、これらの基準をどれだけ満たしているかで順位付けしてください。トラックとの適合性が高い地域イベントやコミュニティイベントは、適合性の低い旗艦イベントよりも最初の応募先として適しています。採択の判断は単一の応募ではなく、シーズンを通して行われます（§ 測定を参照）。

応募シーズンの計画

同じトピックを扱うイベントでも、CFP の締め切りは数か月ずれることがあります。そのため、候補イベントを一つずつではなく、ひとつのカレンダーとして扱います。

• 候補イベントの CFP ページを見つけたら、応募後ではなく、すぐに各イベントの締め切り、採否通知日、開催日をひとつのファイルにまとめます。ひとつの講演に合いそうなイベントは、均等に間隔が空いているのではなく、締め切りが重なる時期に集中する傾向があります。
• 両方に採択された場合にユーザーがどちらを実際に選ぶかを先に決めずに、審査期間が重なる二つのイベントへ同じ内容を応募しないでください。提案はシーズンを通して再利用できますが、二つに採択された後のスケジュールの衝突は避けられません。
• 初めての切り口や自信の低い切り口は、締め切りが早い地域イベントやコミュニティイベントに応募するよう順序を組み、目玉となるイベントへの応募は、ステージやミートアップで一度話して内容を検討してからにします。
• 目標とする二つのイベントの締め切りが近い場合は、手間の少ない切り口（ステップ 2 の効率順）を先に応募します。落選しても、次の締め切りに向けて手間のかかる切り口を準備する時間を確保できます。

§ Measurement で推奨されているのと同じファイルでカレンダーを管理します。

Step 1 - ひとことも書く前にイベントを調べる

同じアイデアでも、あるイベントでは採択され、隣のイベントでは不採択になることがあります。まずイベントのルールを確認してください。後のすべての手順がそれに左右されます。

1. ウェブを閲覧できる場合は、CFP ページ、行動規範または講演者規約、トラック一覧、前年のスケジュールを読みます。閲覧できない場合は、ユーザーに CFP ページと、前回開催で採択された講演のタイトルを 5 件貼り付けてもらいます。
2. 厳格な制約を抽出します。入力欄の一覧、文字数または語数の上限、形式と講演時間、1 人あたりの応募上限、締め切り、審査が匿名かどうか、旅費が支給されるかどうかです。
3. 判断の手がかりとなる要素を抽出します。アイデアに合うトラックの説明、前回すでに扱われた内容、イベントがさらに求めている内容、会場がベンダー中立かどうかです。
4. 執筆前に、制約を短いブロックにまとめてユーザーに伝えます。草稿を書いた後で上限に気づくと、最も鋭い文章を損なう書き直しが必要になります。

ルールだけでなく、実際の提案も読みましょう。speakerline.io では、「採択」または「不採択」のタグが付いた応募全文と、要旨に添えられた審査員限定の「pitch」が公開されています。

対象イベントで採択された応募を 3 件読むほうが、イベントの独自の文体を把握するうえでは、アドバイスのページを読むより参考になります。掲載内容は Ruby カンファレンスに偏っているため、イベントが見つからないのは通常のこととして、前年の公開スケジュールを確認してください。

最初の審査が匿名の場合は、文章の書き方が変わります。PyCon US では「審査の第 1 ラウンドでは、応募者の情報は審査員に表示されません」と明記されています。そのため、タイトル、説明、アウトラインに講演者や勤務先の名前を記載してはいけません。

一方、Write the Docs などのイベントでは、視点のバランスを取るため、意図的に名前を公開した状態で審査します。どちらの方式か推測せず、CFP ページを確認してください。

環境に永続メモリーがある場合は、イベントのプロフィールとユーザーの提案を、イベント名を付けて保存します。イベントは毎年開催され、CFP は次の開催都市でも再利用されるため、2 回目の応募は 1 回目のファイルをもとに始めるべきです。

抽出項目の全リストと、形式と範囲の対応表については、./references/event-research-checklist.md を参照してください。

Step 2 - 切り口を見つけ、承認を得る

トピックは提案ではありません。審査員は人気のトピックについて何通りもの提案を見ており、選ばれる提案には明確な立場があります。

ユーザーに、その立場を引き出す質問をします。その場にいる多くの人とは異なり、あなたはこれについて何を信じていますか？ 次に、以下の順位に従って候補となる切り口を提示し、順位を口頭でも伝え、最も有力な候補を推奨したうえで、ユーザーが選ぶまで待ちます。ここでいう手間とは、応募前にその切り口のために必要となるもの、つまり、ユーザーがすでに持っていなければならない資料、執筆にかかる時間、ステージに立つために必要となる準備を指します。

観点	提出前の作業量	審査で得られるもの	会場で得られるもの	成立しない場合
失敗談	失敗とその数値がすでにユーザーの手元にある場合は1時間	審査員が検証できる信頼性と、ほかの誰にも真似できない独自性	注目と、その後の発表全体を支える信頼	ユーザー自身が経験し、公開できる失敗がない
逆張りの主張	数日。証拠がそろってから反論を練習するのに、その大半を費やします	似たような提案が40件並ぶ審査で、最も際立つ評価	記憶に残ることと、それに続く登壇依頼	会場の前での質疑応答で、主張が崩れる
実践的な手引き	1〜2日。1つの事例を一般化し、他者のスタックで使える手順にします	独自性では最も低い評価です。審査員が最もよく目にする形式です	参加者から最も高い評価を得られ、参加者が月曜日に実践できる唯一の観点	タイトルが曖昧で、誰かに読まれる前に審査で落ちる

• 効率性：失敗談 > 逆張りの主張 > 実践的な手引き
• 審査での価値：逆張りの主張 > 失敗談 > 実践的な手引き
• 会場での価値：実践的な手引き > 失敗談 > 逆張りの主張
• 作業量：逆張りの主張 > 実践的な手引き > 失敗談
• コンプライアンス対応コスト：失敗談 > 逆張りの主張 > 実践的な手引き

価値を示す2つの順位は、この選択の実情を率直に表したものであり、保険をかけたものではありません。提案を採択させることと、発表する価値のある内容にすることは別のことです。これらを1つの順位にまとめると、ユーザーが最も知る必要のある判断材料が隠れてしまいます。

観点ごとのコンプライアンス対応コスト：

• 勤務先でのインシデントを扱う失敗談：勤務先の承認、顧客の匿名化、さらに多くの場合、1文でも公開する前にセキュリティ審査が必要です。また、スケジュールが公開された後は取り下げられません。
• 競合他社の名前を挙げる逆張りの主張：ベンダーに依存しないイベントでも、同様のリスクを軽減した形で伴います。
• 公開情報をもとに作成した実践的な手引き：この種の負担はありません。

この効率性の順位では、実践的な手引きが不利になります。会場での価値は最も高い一方で審査での評価は最も低く、一般化にかける数日分の作業も審査員の評価にはつながりません。そのため、比率で考えると毎回不利になります。効率性だけを計算する発表者は、結局、失敗談ばかりを蓄積し、誰も実践しない発表しかできなくなります。

実践的な手引きを優先してください。

• トラックの説明で、実践者向けまたはハウツー形式の内容が明示的に求められている場合。
• 目標が、参加者からの評価とこのイベントからの再登壇依頼である場合。
• インタビューで、積み重ねて発展する回答が得られた場合。手引きは、5つのイベント、録画、文書版にも耐えうる観点です。
• 手順がすでに社内のランブックとして存在する場合：作業量は1時間にまで減り、ほかの観点を抑えて最上位になります。

ユーザーの制約によって除外される観点は、提示してユーザーに選ばせるのではなく、除外してください。自身で経験し公開できる失敗がなければ、失敗談は候補になりません。反論を練習する余力がなければ、逆張りの主張は候補になりません。どの観点を、なぜ除外したかを伝えてください。

この順位は標準的なものであり、絶対的なルールではありません。イベントや登壇者によって変わります。このユーザーについてわかっていることに照らして、順位を付け直してください。

• 録画実績があり、公に知られた登壇者なら、初登壇者には難しい逆張りの主張でも通せます。
• 公開済みのインシデント報告があれば、失敗談の執筆にほとんど手間がかかりません。
• 直近の開催回で同じトラックに失敗談が3件並んでいたイベントでは、上位2つの順位が逆転します。

角度を順位付けして提示し、ユーザーに選んでもらってから執筆してください。選ばれるまでは原稿を書かないでください。アブストラクトを書いた後に角度を変えると、最初からやり直しになります。

選ばれた角度を、直近の開催回のスケジュールと照らし合わせて検証してください。昨年、ほぼ同じ内容の講演があった場合、ユーザーの応募枠を使う価値が出る前に、新しい切り口（新しいデータ、異なる規模、失敗事例、逆張りの解釈など）が必要です。

ステップ 3 - タイトル

具体的で平易なものから印象的なものまで、5つの候補を順位付けして提示してください。タイトルの役割は、審査員にアブストラクトを読んでもらい、参加者にセッションページを開いてもらうことだけです。

有効なパターン：

• 規模の大きな課題（「400サービス環境におけるリージョン間エグレスの削減」）。
• 道のり（「凍結期間なしで Cron からワークフローへ」）。
• 逆張りの主張。
• 実際の数値。
• 約束する失敗（「すべてのテストに合格したのにデータを失った移行」）。

ルール：

• 文字数制限を守り、文字数を声に出して数えてください。
• 曖昧な表現より具体的な表現を優先してください。
• 疑問符は削除してください。ほとんどの場合、断定形のほうが効果的です。
• 説明が必要な語呂合わせは削除してください。
• ベンダー中立のイベントでは、製品名を削除してください。
• 左半分が曖昧なカテゴリになっているコロンの使用は避けてください（「開発者体験：徹底解説」など）。

ステップ 4 - アブストラクト

この文章はスケジュールに掲載されるため、委員会向けではなく、5つの会場のどれに参加するかを選ぶ参加者向けに書いてください。

3部構成にします。導入、約束、成果です。

1. 導入 - 読者がすぐに認識できる課題を示す文を1〜2文。
2. 約束 - セッションで扱う事例、アプローチ、構成を説明する文を2〜3文。
3. 成果 - 具体的な学びを示す文を1〜2文。

文体：イベントがアブストラクトをそのまま掲載する場合は三人称で、それ以外は昨年のスケジュールに見られる標準的な文体に合わせてください。見出しや箇条書きは使わず、完結した文で書いてください。ただし、フォームで許可されている場合は箇条書きを使用できます。インタビュー質問4で得た実際の数値を含めてください。具体的な数値は、最も手軽に信頼性を示せる方法です。

次の書き出しは禁止です。どれも最初の行で読者を遠ざけます。

• 雇用主の名前。
• 講演内で答えない修辞的な質問。
• 登壇者個人の経験談。
• 聴衆がすでに知っている用語の定義。

改稿のたびに、上限に対する文字数を報告してください。まず形容詞、留保表現、過剰な修飾表現を削ってください。これらは審査員にとって情報になりません。

./references/title-and-abstract-examples.md で、実際に採択された提案2件と、同じ講演に対する弱い例・強い例の組み合わせを確認してください。

ステップ 5 - 学び

2〜4項目とし、それぞれ動詞から始め、参加者が後で実行する行動にしてください。例：診断する、計測する、監査する、規模を見積もる、移行する、選択する、測定する。「Xを理解する」や「Yの重要性を認識する」は、講演の構成がまだできていないことを示すように受け取られます。

セッション枠に合わせて範囲を定めてください。

• ライトニングトーク：1つのアイデア、1つの学び。
• 標準セッション：1つの課題、2〜3つの学び。

25分で8つの学びを掲げても、どれも伝わらないと審査員に思われます。

ステップ 6 - 査読者向けの項目

ほとんどのフォームには、参加者には見えない項目があります。査読者へのメモ、エコシステムやコミュニティへの利点、概要、前提条件、対象者のレベルなどです。アブストラクトの内容をこれらの項目に繰り返し記載すると、ユーザーが自分の主張を伝えられる唯一の場所を無駄にしてしまいます。

項目	記載する内容
概要	進行順と各項目の所要時間（分単位）の目安を、2階層で記載します。PyCon US は「話す予定の内容を、時間の目安とともに列挙する」ことを求め、「2階層の箇条書き形式が最適」としています。これは、トークが実際に形になっていることを示す証拠です
査読者へのメモ	なぜこの登壇者なのか、すでに何を構築しているか、デモのリスクをどう軽減しているか、この切り口がここで新しい理由
エコシステムへの利点	会場の外で誰が恩恵を受けるか、今年のプログラムでどのような不足を補うか、なぜ今なのか
前提条件	参加者がすでに知っている必要があること、またはインストールしておく必要があるもの
対象者のレベル	正直なレベルを記載します。レベルを誤って表示した上級者向けトークは、会場を空にしてしまいます
トラック	説明が最も合致するトラックを選びます。座長はトラック内で提案を評価するため、素晴らしい提案でも不適切なトラックに出すと、より弱い競合案に負けてしまいます

フォームにメモ欄がない場合は、査読者向けの文のうち最も強いものをアブストラクトの成果に関する説明に組み込み、残りは省きます。

ステップ 7 - 信頼性を示す資料

査読者は、登壇者がこの特定のトークを実施できるかどうかを確認します。証拠になるのは具体性であり、熱意ではありません。

• 過去のトークの録画が、最も強い判断材料です。録画がない場合は、カンファレンスの講演時間に合わせたリハーサルの録画、または同じ内容を書き起こしたものがあれば、査読者が確認できます。
• トークの背景にある取り組みを示すリポジトリ、記事、ベンチマーク、インシデントの報告書へのリンクを追加します。
• 経歴は三人称で2〜3文にまとめ、そのうち1文では肩書きを並べるのではなく、登壇者と_この_テーマとのつながりを示します。
• 共同登壇者を加えるのは、顧客や移行の反対側など、独自の視点をもたらす場合に限ります。登壇者数の上限やパネル構成のルールを確認してから、登壇枠を約束してください。

ステップ 8 - 応募ルールと AI ポリシーの確認

提出前に、以下を確認してください。どれか一つでも違反すると、本来は採択される提案が無効になる可能性があります。以下に挙げるルールは、PyCon US と KubeCon + CloudNativeCon North America（Linux Foundation）の CFP ページから確認したものです。確認すべき項目の例として扱ってください。

上限やポリシーは開催回ごとに変わるため、そのまま適用されると思い込まず、対象イベントの最新ページを確認してください。

• 一人あたりの上限。 大規模なイベントの中には、登壇者ごとの提案数に上限を設け、上限を超えた人の応募をすべて取り下げるところがあります。PyCon US の上限は 3 件で、「個人が 3 件を超える提案を提出した場合、その人の提案はいずれも審査されません」。KubeCon も同じ上限を設けており、さらにイベントごとに、登壇者がパネルセッション 1 件とパネル以外のセッション 1 件までしか提出できないという制限があります。
• 再利用コンテンツ。 講演をアーカイブするイベントでは、同じセッションが最近、そのイベントの主催のもとで開催されていないか確認します。
• 売り込み禁止。 ベンダー中立のイベントでは、製品を主題にした提案は「ほぼ必ず却下」されます。これは Linux Foundation の CFP 自身の表現です。製品は、教訓を得た事例として取り上げることはできますが、主題にはできません。
• パネルの構成。 パネル形式が認められている場合は、公開されているルールを確認してください。応募時にパネリスト全員を記載すること、複数の企業から参加者を集めること、男性と自認する登壇者 3 人以上だけでパネルを構成しないことなどが定められていると考えてください。名前を記載する前に、パネリスト全員の了承を得てください。
• AI ポリシー。 内容を読み、ユーザーに伝えてください。PyCon US は、「大規模言語モデルによって、全面的に、または大部分が執筆された、あるいは AI 生成テキストを含む」提案を却下し、再提出の機会も設けていません。CNCF は支援の利用を認めていますが、「低品質、または明らかに AI 生成の『スロップ』」を却下し、違反を繰り返す応募者には今後の CFP への応募を禁止しています。
• 人間らしい表現に整える。 最終稿を、好みの人間らしい文章に整えるスキルに通してください。モデルらしさのある文章は、今や審査員がパターンとして見抜くものです。アイデアが読まれる前に、提案の信頼性を損ないます。
• 所属の開示。 フォームで尋ねられたら、勤務先やプロジェクトへの所属を明記してください。審査員はどうせ調べますし、所属を隠すほうが、明かすよりも印象が悪くなります。

ポリシーの内容にかかわらず、ここで作成したものはすべて草案であり、ユーザー自身が自分の言葉と具体的な情報で書き直す必要があります。ユーザーも分かっているはずだと思い込まず、そのことをはっきり伝えてください。

ステップ 9 - 委員会の審査基準に照らした自己評価

完成した一式を、委員会が重視する 4 つの軸でそれぞれ 1～5 点で評価し、各点数の理由を記述してください。著者ではなく、審査員の立場で評価してください。

軸	問い	1 の目安	5 の目安
内容	一貫性があり、構成され、実現可能か？	形のないトピック	所要時間と明確な流れを示したアウトライン
独自性	新しいアイデア、視点、データがあるか？	このイベントで昨年開催された講演	誰も説明できない失敗
関連性	適切なイベント、トラック、タイミングか？	汎用的で、どこでも通用する内容	今このコミュニティで議論されている問いに答える内容
登壇者	適任者で、実績が示されているか？	「これに情熱を注いでいます」	録画と、実績を示す数値

この 4 つの軸は、公開されている委員会の審査基準で共通して重視されるものです。それぞれの 1～5 点の目安は、このスキル独自のものです。目安と提出前のチェックリストについては、./references/reviewer-rubric.md を参照してください。

合格基準

この基準はこのスキルが定めたものであり、委員会が定めたものではありません。カンファレンスがレビュアー向けに数値の合格点を公表することはありません。これは実用的な基準です。レビュアーが最も関心を失いやすい箇所を書き直すよう促すため、役に立ちます。6項目すべてを満たすまで提出しないでください。満たしていない項目があれば、改善を繰り返してください。

1. Step 9 のどの評価軸も3未満ではなく、内容と独創性は4以上である。
2. 概要に、ユーザーが出典を示せる具体的な数値、システム、または規模が少なくとも1つ含まれている。
3. すべての持ち帰りポイントが動詞で始まり、所定の長さに収まっている。
4. すべての項目が、推測ではなく実際に数えて文字数制限内に収まっている。
5. レビュアー専用の項目に、概要に書かれていない内容が含まれている。
6. ユーザーについて何も知らない読者が、なぜこのスピーカーがこの講演をするのか理解できる。

Step 8 の厳格なルールは、これとは別種の制約です。提出時の文字数制限、売り込みの禁止事項、AI ポリシー、パネルに関する規則は、各イベントが公表しているものです。ユーザーが評価に異議を唱えたときは、どちらの種類のルールについて議論しているのかを伝えてください。自分で定めた基準は交渉できますが、公表された制限は変更できません。

Step 10 - 判定後

• 採択： samber/developer-relations-skills@tech-talk-outline に引き継ぎ、概要で約束した内容を実現してください。参加者はその内容を引用します。
• 不採択： フィードバックを求めてから、別の対象に向けて再調整してください。提案は使い切りのチケットではなく、再利用できる素材です。トラック、切り口、またはイベントを変え、内容が新鮮なうちに同じシーズン中に再提出してください。
• 返答なし： 締め切りと公表された通知日を最終期限とみなし、提案を次に進めてください。

イベントの種類と対象者

ユーザーに明示しておく価値のある2つの軸によって、文章の方向性が変わります。暗黙のままにしないでください。

• コミュニティ運営か、ベンダー運営か。 コミュニティや財団のイベントはベンダー中立です。製品はストーリーの舞台としてのみ登場し、競合製品も公平に名前を挙げ、オープンソースプロジェクトはリンク付きで掲載します。ベンダー自身のカンファレンスではルールが逆になり、製品の詳細が主題となるため、顧客にもたらす成果と実装の具体性で提案を競います。一方に向けて書いた提案を他方に提出すると、どちらのイベントでも場違いに感じられます。
• B2B かセルフサービス型の対象者か。 B2B のテーマでは、参加者の一部は他の人の立場で評価するため、概要には組織が負担するコスト（移行作業、運用負担、チームがやめた作業）を明記し、会社がすでに公表している数値の範囲に収めてください。個人によるセルフサービス型の導入では、参加者が自分で決定します。無料で利用する方法、最初の成果が出るまでの時間、制限事項を正直に明記してください。

このスキルにおけるその他の要素、つまり切り口、タイトルの作り方、概要の構成、持ち帰りポイントの動詞、信頼性は、どちらの場合も同じように機能します。

評価

1件の提案を1件のイベントに出すのはコイン投げのようなものです。大規模なイベントでは、各提案を複数のレビュアーが審査し、その後、委員長による順位付けがあり、さらにトピックの広がり、登壇者の多様性、初登壇者のバランスを調整します。そのため、優れた提案でも、著者が影響を及ぼせない理由で落選することがあります。

採択率をユーザーに伝えるのは避けてください。PyCon USもKubeConのCFPページも、応募数や採択数を公表していません。また、広まっている「約10件に1件」という数字にも一次情報源はありません。1回の結果ではなく、取り組み方を評価してください。

シグナル	何が分かるか
1シーズンの応募を通じた採択率	唯一信頼できる品質のシグナルです。ただし、8～10件の応募が必要です。これはこのスキルが設定した実用的なサンプル数であり、公表された数字ではありません
同じ提案を採択するイベントと不採択にするイベント	品質ではなく適合性です。書き直すのではなく、応募先を変えましょう
提供された場合の、レビュアーによる書面のフィードバック	得られる情報の中で最も価値があります。不採択のたびにフィードバックを求めましょう
ウェイトリスト入り、または「内容は良いが枠がない」という連絡	提案はうまくいっています。変更せずに別のイベントへ再応募しましょう
ライトニングトークとメイントラックのどちらで採択されたか	アイデアの強さではなく、形式の戦略です

イベント、形式、切り口、結果、フィードバックを1つのファイルに記録しましょう。次のCFPシーズンは、そのファイルを出発点にします。

繰り返し選ばれる登壇者が実践していることを、ユーザーにはっきり伝えてください。

• Nina Zakharenko：「落選を恐れないでください。できるだけ多くの提案を応募しましょう。不採択になったトークについては、必ずフィードバックを求めましょう。」
• これなら多すぎると思うくらい、力を注ぎましょう。swyxは初めてのカンファレンストークのCFPに1か月を費やしました。
• 初めて提案する場合は、カンファレンスへの応募前にミートアップで発表することを勧めましょう。Alaina Kafkesは、トークの範囲を絞り込むうえでミートアップが役立ったと述べています。このパターンは、実務家のさまざまな体験談にも繰り返し見られます。

よくある失敗

失敗	どのような内容か	修正方法
装った宣伝	タイトルや最初の文に製品名がある	課題を軸に書き直します。製品は背景として扱います
書籍並みの範囲	「REST、GraphQL、gRPCと、その選び方を説明します」	切り口を1つに絞るか、長い形式での発表を依頼します
使い回しのきくタイトル	他の50件の講演にも付けられそう	システム名、数字、または対立する要素を加えます
登壇者中心の概要	「私たちの取り組みを紹介します」	すべての文を参加者の視点から書き直します
「理解する」系の動詞	「可観測性が自分のスタックにどう適合するかを理解します」	参加者が実際に行うアクションに置き換えます
項目の使い回し	レビュアーへのメモが概要の重複になっている	公開用の文章に含めるべきではない主張を書きます
文字数制限超過	1,300文字の上限に対し、概要が1,800文字	編集のたびに文字数を数え、まず曖昧な表現を削ります
トラックの選択ミス	名前が最も魅力的なトラックに応募している	雰囲気ではなく、トラックの説明に合わせます
検証できない主張	「大幅なパフォーマンス向上」	根拠を示せる数値を使うか、主張を削除します
AIモデル風の文章	均一なリズムで、具体性も個性もない	人間らしさを加える見直しを行い、ユーザー自身の言葉で書き直します

参考資料

• 登壇をキャリア上の強みとして活用する方法については、samber/developer-relations-skills@devrel-careerを参照してください。