プロポーザルの出し方・心構え

Table of Contents

1. Introduction

最近プロポーザルの出し方について話す機会が身近で増えました。私自身、過去にPHPカンファレンスなどの技術イベントで何度も登壇した経験があります。本記事ではそうした経験から得られたプロポーザルを書く上での心構えや具体的なTipsについて解説します。

また、多くの人が悩む「プロポーザルを出すネタがない」という課題に対する私なりの解決策も提示したいと考えています。

あくまで私個人の経験に基づく独断と偏見が多分に含まれている点、また、自分はこうありたいという理想を書いている点をご了承ください。

2. 今北産業

日々学んだことや取り組んだことをアウトプットしよう
アウトプットしたものを元に魅力的なプロポーザルを作ろう
カンファレンスに限らず積極的に打席に立とう

3. 今回のスコープ

本記事で対象とするカンファレンスは、主にPHPカンファレンスのような技術カンファレンスを想定しています。

一口にカンファレンスと言ってもその規模や目的はさまざまです。たとえば国際カンファレンスであれば一定の権威性がありますし、地方のカンファレンスであれば一般的な勉強会の延長線上にあります。本記事では特にカンファレンスの規模を区別せずに書いています。

また、トークの長さとしては15分〜30分程度のものをイメージしています。 5分程度のLTはゲーム性が異なると考えているため本記事のスコープ外とします。

4. 直近出したプロポーザル

4.1. 実例

直近の2025年前半に提出したプロポーザルを実例として紹介します。

PHPConで採択されたプロポーザルは次のとおりです。

PHPCon関西で不採択となったプロポーザルは次のとおりです。

https://fortee.jp/phpcon-kansai2025/proposal/rejected?q=takeokunn

VimConfではEmacsに関するテーマで応募しましたが、残念ながら不採択となりました。

4.2. ポリシー

これはあくまで私個人のルールなので参考にされてもされなくても構いません。

4.2.1. 絶対に登壇駆動でプロポーザルを出さない

「登壇駆動開発」という言葉もありますが、個人的にはそのやり方は好きではありません。登壇はあくまで日々の技術的な活動や学びのアウトプットを発表する場であるべきだと考えています。自分の経験や知見が十分に蓄積された結果としてプロポーザルがあり、その先に登壇がある、という順番の方がトークに説得力が増してよいものになると思っています。

4.2.2. トークのアウトラインの下書きは必ず作った状態で出す

プロポーザルを出す段階でトーク全体の構成や話す内容がある程度固まっている状態にしています。具体的には、話したいことのキーワードを並べるだけでなく、セクションごとの構成やそれぞれのセクションで何を伝えたいのかを箇条書きで書き出しています。アウトラインがしっかりしていればプロポーザルの文章も書きやすくなるという利点もあります。

4.2.3. トーク内容を最低でも6割以上理解している状態のときのみ出す

自分の基準としては、トーク内容の6割以上はすでに自分の言葉で説明できる状態であることを目安にしています。残りの4割はプロポーザルが採択されてから資料を作成する過程で調査・学習することで補っています。不足している知識を学習しつつ、当日のトーク準備にも十分に時間を割けるよい配分だと考えています。

4.2.4. 採択されたトークを使い回さない

一度話した内容を別のカンファレンスで再度プロポーザルとして出すのは、原則として行わないようにしています。自分自身にとって新しいテーマに挑戦し続けることが成長に繋がると信じています。これは単に「常に新しいテーマで話すのがかっこいい」という私自身の価値観に基づいているだけで、トークを再演すること自体を否定するものではありません。

5. なぜプロポーザルを出すか

プロポーザルについて2023 - 作文術とかにもあるとおり、プロポーザルを出すメリットはいくつもあります。

プロポーザルを書くことで自分の知識や知見が整理される
カンファレンスで話すと注目される
コミュニティへの貢献
自己ブランディング
新しい挑戦へのきっかけ

一方、プロポーザルを出すこと自体のデメリットは、登壇準備に時間がかかることくらいで他に特にないと考えています。たとえ採択されなかったとしてもプロポーザルを作成する過程で得られるものは大きいです。

6. プロポーザルを通すのに必要な要素

プロポーザルが採択されるためには、主に3つの要素が重要だと考えています。

根本的な内容の良さ: トークテーマそのものに価値があり聴衆にとって有益な情報が含まれているか
プロポーザルの質: 伝えたい内容が魅力的かつ分かりやすく文章に落とし込まれているか
運営側との音楽性の合致と運: カンファレンスのコンセプトや他の登壇者とのバランス、そして最後は運

このうち、3つ目の「運営側との音楽性の合致と運」は自分ではコントロールが難しい要素です。これについて「運営の苦悩」といった文脈で語られることもありますが応募者側からすると知る由もない部分です。

しかし、カンファレンスによってはイベント運営側が登壇者に期待することを公開していたり、採択基準を明示していたりする場合もあります。これらを事前に確認することで、「音楽性の不一致」をある程度は避けられるかもしれません。

とはいえ、プロポーザルが採択されるかどうかの8割は、1と2、つまり「内容の良さ」と「プロポーザルの質」で決まると私は考えています。これらは日々の努力で十分にカバーできる領域であり、この2点に焦点を当てて解説していきます。

7. プロポーザルを出すまでのフロー

7.1 フロー図

理想はブログという形でアウトプットすることですが、OSSへのコントリビュート、雑誌や書籍の執筆など形式は問いません。私自身も実際には、「5 プロポーザル作成 > 登壇」の後に「4 ブログにまとめる」という順番になるなど柔軟に対応しています。

これ以降、本記事では「アウトプット」を「ブログ記事を書く」こととして説明します。

graph TD;
    subgraph 日々の活動サイクル;
        A["1 生産的な活動"] --> B{"2 アウトプットと<br>Next Action決定"};
        B --> C["3 Next Actionの実行"];
        C --> B;
    end;

    B -- "知見が溜まったら" --> D["4 ブログに纏める"];
    D --> E["5 プロポーザル作成"];
    D --> F["勉強会で登壇する"];

    subgraph 登壇サイクル;
        E --> G["登壇する"];
        G --> H["フィードバックを貰う"];
    end;

    H -.-> A;

7.2. 各ステップ解説

このフローのポイントは、登壇をゴールにするのではなく、日々の学習とアウトプットの延長線上にプロポーザルを位置付けている点です。この点については、コントリビュートで沢山の人が救われる。mattn氏が語る、好循環を実現するアウトプット活動の仕組みにもまとめられています。

7.2.1. 何か生産的な活動をする

すべての始まりは日々の生産的な活動にあります。業務での課題解決、新しいライブラリの試用、個人開発でのツール作成、OSS活動など、何でも構いません。たとえば、ハマったエラーとその解決策をメモする、読んだ技術記事の要約と感想を書くといったより小さな一歩でもまったく問題ありません。

重要なのはここでの活動が後のアウトプットの種になるという点です。

7.2.2. 纏まった形でアウトプットをしつつ、Next Actionを決める

活動で得た知見はどんなに小さくてもアウトプットすることが重要です。 Zennのスクラップや短いブログ記事あるいは社内のドキュメントでも構いません。この際、Next Actionを言語化することで次に何をすべきかが明確になります。

7.2.3. Next Actionをさらに実行して、纏まった形でアウトプットする

決めたNext Actionを実行し再び作業していきます。この「活動→アウトプット→次の活動」というサイクルを繰り返すことで、1つのテーマに関する知見が雪だるま式に増えていきます。

7.2.4. ひととおり形になったらブログに纏める

サイクルを何度か繰り返し知見がある程度の塊になったら、それらを体系的に整理し1つの長文ブログ記事として公開します。このブログ記事が後のトークの土台となります。

7.2.5. 4のブログの内容をプロポーザルにする

ここまで来ればプロポーザル作成はそれほど難しくありません。ブログ記事の導入部分がプロポーザルの概要になり、目次がトークのアウトラインになり、結論が聴衆へのメッセージになります。すでに質の高いインプットとアウトプットが手元にあるため、自信を持ってプロポーザルを提出できるはずです。

このサイクルを回し始めることこそが「プロポーザルのネタがない」という悩みを解決する、もっとも確実な方法です。

8. どこに対して努力すべきか

これまでのフローを踏まえた上で、プロポーザルの採択率を上げるためにどこに努力を集中させるべきか、3つのポイントに絞って解説します。

8.1. レギュレーションとゲーム性を理解する

プロポーザルがどのようなルールで審査されるのか、その「レギュレーション」と「ゲーム性」を理解する必要があります。

最低限、次の点は必ず確認するとよいでしょう。

募集要項を熟読すること: ターゲット層、求めているテーマ、文字数制限、記載すべき項目など、運営側が提示している情報を読む
審査基準を把握すること: カンファレンスによっては審査基準を公開している場合があるので、どのような点が評価されるのかを事前に調査する
過去の採択プロポーザルを読むこと: 採択プロポーザル一覧が公開されていることが多いので、どのようなテーマや書き方のプロポーザルがとおりやすいのか、傾向を把握する

たとえば、VimConfでは匿名ではなく応募者自身の活動を見ることを重視しています。

逆にKaigi on Railsは匿名性を重視しており応募者を一切見ないという方針のようです。

それぞれのコミュニティでどのような点が重視されているのかを見極める必要があります。

8.2. 質の高いブログ記事を増やす

プロポーザルの元ネタは日々の活動サイクルから生まれるブログ記事です。質の高い記事をコンスタントに生み出すために、私は次の点を意識しています。

8.2.1. 2種類の記事を書き分ける

質の高いブログ記事を生み出すためには、目的の異なる2種類の記事を戦略的に書き分けるアプローチが有効です。

1つは、日々の活動で得た小さな発見やTipsを記録する「技術メモ」です。これらのメモは、情報の鮮度が高いうちに将来の自分のための備忘録として、あるいは小さな知見の共有として気軽に書き留めます。この段階では完成度よりもスピードを重視します。これは、Zettelkastenでいうところの「fleeting note」にあたります。

そして、これらの技術メモがある程度の量になった段階でそれらを素材として体系的に再構成し、背景やストーリーを肉付けした「長文ブログ記事」を作成します。この長文記事こそが、カンファレンスのプロポーザル提出の際に直接のネタとなります。これは、Zettelkastenでいうところの「permanent note」にあたります。

org-roamで記事を管理しGitHub Actionsで適切に公開するにも書いたとおり、個人的にはZettelkastenで管理をするとこのサイクルを回しやすいと考えています。

8.2.2. 想定読者を明確にし、フィードバックを積極的に活用する

記事を執筆する上で「誰に、何を伝えたいのか」という想定読者を明確に設定することは重要です。想定読者を具体的にイメージすることで、メッセージがより深く的確に伝わる記事になります。

この段階で読者からよいフィードバックを得られていれば、それは記事のテーマや内容が魅力的であることの証左です。もしその上でプロポーザルが採択されなかったとしても「今回は運営側と音楽性が合わなかっただけだ」と自信を持って割り切ることができるはずです。

8.3. 魅力的なプロポーザルの書き方を学ぶ

プロポーザルのレギュレーションにも依りますが、次のようなことを明確に書いた方がよいです。

アウトラインを最初に提示する
「誰が、何を得られるのか」を明確にする
過去の採択プロポーザルから学ぶ

Googleで検索すればプロポーザルの書き方に関する記事が山のように見つかります。

AIにレビューしてもらってもいいし、同僚やコミュニティで相談しながら作るのもいいでしょう。私の場合、プロンプトを作り込んでAIからフィードバックをもらいながら書いています。

1%でも当選する可能性を上げるという意識で取り組んでいます。

9. 落ちた時に考えるべきこと

プロポーザルが採択されない時はいつだって辛いものですが、その原因が「自分の努力不足」なのか、それとも「採択者との相性や運の問題」なのかを切り分けて考えるようにしています。

9.1. トークテーマの魅力（内容の良さ）

提案したテーマそのものについて再度考えてみます。

そもそもこのトークテーマは採択メンバーにとって本当に魅力的だったか
ブログ記事が自分が想定していた読者からよい評判を得られていたか

想定していた読者からよい反応が得られていた場合は採択者との方向性が合わなかったと割り切れますし、そもそも反応が悪かったのであれば諦めもつきます。

9.2. プロポーザルの完成度（質の高さ）

登壇経験が豊富な友人やコミュニティの仲間、同僚などにプロポーザルを読んでもらい、率直なフィードバックをもらうのがよいでしょう。

フォーマットを満たしていたか
伝えたい内容がプロポーザルの文章で十分に表現できていたか

9.3. 採択メンバーとの相性と運

こればかりは自分ではコントロールできない領域です。カンファレンス全体のテーマ構成と合わなかった、競合するプロポーザルに負けた、採択者の琴線に触れなかったなどさまざまな理由が考えられます。

ベストを尽くして臨んだ結果不採用になったのであれば潔く諦めるくらいの気持ちでいるのがちょうどよいと思います。

9.4. 不採択になったプロポーザルの活かし方

プロポーザルを書いた時間が無駄になることは一切ありません。その経験を次に活かせばよいのです。

リジェクトコンに出す
別の勉強会で発表する
改善して再挑戦する

このように次の一手を考えることで、不採択という経験もアウトプットサイクルの一部として次への布石とできます。

10. プロポーザルのネタがない時に考えるべきこと

「プロポーザルに出すようなネタがない」という悩みは多くの場合、ただの思い込みです。何かに取り組んでいれば、誰しも次のサイクルを日常的に無意識に回しているはずだからです。

何か生産的な活動をする
活動を文章でアウトプットし、Next Actionを決める
Next Actionをさらに実行して、纏まった形でアウトプットする

色々な人の話を聞いている限り、体系的なアウトプットをしていないために知識が整理されず、登壇のネタにできていないだけということが多い印象です。そういう場合は友人やコミュニティの仲間に、自分がどのようなテーマで登壇できそうか、今何に取り組んでいるのかを話して、思考を整理する手伝いをしてもらうのがお勧めです。

カンファレンスの本筋とは少し違う内容でも親和性があれば採択されることも多いので「ネタがまったくない」ということはほぼないはずです。もし本当に話すことが何もないと感じるのであれば、それは新しい挑戦ができていないということなのかもしれません。

11. その他

最後にプロポーザルに関してよく議論されるいくつかのトピックについて、私の個人的な見解を述べます。

11.1. 「プロポーザルの審査側を経験した方がよい」というアドバイスについて

このアドバイスは一度審査側を経験することで「運営側との音楽性の合致と運」という要素を肌で感じられるという点では有益だと思います。

しかしプロポーザルの採択率を上げるという観点では、その効果は限定的だと考えています。なぜなら、採択されるプロポーザルの多くは公開されており、それらを分析することで審査基準や傾向は十分に学習可能だからです。

審査側を経験するよりも応募者としてプロポーザルを書く努力を重ねる方が採択率向上への効果は高いというのが私の意見です。

11.2. LTについて

本記事ではスコープ外としましたが、LTにはLTの戦い方があります。 LTは5分という短い時間で聴衆の心を掴む必要があり、技術的な深さよりも、面白さやインパクト、共感を呼ぶストーリー性が重視される傾向があります。お祭りのような側面も強く個人的にはあまり得意ではありませんが、短い時間で自分の考えを凝縮して伝えるよい訓練になることは間違いないでしょう。

11.3. 経験の浅い人にこそプロポーザルを出してもらいたい

経験の浅い方やこれからコミュニティで活動していきたいと考えている方にこそ、積極的にプロポーザルを出してもらいたいと私は考えています。

プロポーザルを書くという行為は「自分が今、何に取り組んでいるのか」「次にどういうことをやりたいのか」といったことを言語化する絶好の機会になります。採択されるかどうかはあくまで結果論であり、その過程で得られる経験は無駄にはなりません。

質の悪いプロポーザルを出してもどうせ採択されないだけです。あれこれ気にせずまずは提出してみてフィードバックのループを回していくのがよいでしょう。

12. おわりに

atusyさんの宝くじに当たる方法を思い出して、明日も頑張ることにしたという記事が好きです。宝くじは買わなければ当たらないように、プロポーザルも出さなければ採択されることはありません。

「打席に立って、きちんとヒットを打つ」ということを再現性高く繰り返すのが、かっこいい生き方だと私は思います。チャンスは逃さないようにしていきたいものです。

また、ベテランの中には無責任にアドバイスはするものの、自らは行動しない人が多いように感じます。「他人にアドバイスをするからには、まず自分が行動で示すべきだ」というのが私の価値観なので、これからもプロポーザルを出し打席に立ち続けたいという思いを込めてこの記事を書きました。

偉そうなことを書きましたが自分自身も徹底できていない点が多いので引き続き精進します。