はじめに
技術系カンファレンスでは、一般公募（プロポーザルの募集）を行い、運営が審査して採択をする形式があります。
プロポーザルを見たり、運営側として採択を決めたりするときに、「これってテーマは良さそうなんだけど、伝えたい内容が少し見えてこないから採択できないかな…」と思うものが多数あります。
そこで、私がプロポーザルを作成する際に気をつけていることや運営側として気にしていることを言語化してみたいと思います。あくまでも私の主観ですので、その点はご了承ください。
なお、私がどんな立場なのか（プロポーザルの応募者やカンファレンスの運営実績など）については、本記事末尾の注釈で紹介しています。（応募者実績*1、運営者実績*2）
ちなみに、私がコンテンツ委員を担当しているDevelopers Summit 2026では、現在プロポーザルを募集しています（Developers Summit 2026のサイトはこちら）。本記事を読んでブラッシュアップした上での応募をお待ちしております。
目次
カンファレンス運営者としてセッション採択時に注目している点
運営として応募数が多いと非常に採択が大変です。そんな中、注目している点をお伝えします。なお前提として、特定の分野や技術に特化したイベントではなく、想定参加者が比較的幅広いが故にニッチな技術があまり採択されづらいイベントを想定しています*3*4。
主語が「私」になっているか
意識されていないことが多いのですが、主語が「私」になっているかどうかは、最初に気にします。事例系の発表の場合は特に気になります。
主語が「私」ではなく「私の会社」となっていた場合、発表内容が技術の共有ではなく会社のアピールになってしまう可能性が高くなります*5。
そして会社のアピールがメインとなってしまうと、聴講者が持ち帰るものが少なくなってしまいます*6。
また主語が「私」ではないと、実際の発表でも「私がやったこと」という話し方にならず、熱のこもった発表にならなかったり、棒読みのような発表になる傾向があります。
このような点から、主語が「私の会社」となっている場合は、最初に弾いてしまう可能性が高くなります。
聴講者に向けて問題提起ができているか
問題提起がプロポーザル内に入っているかもポイントです。問題提起が入っていないと、聴講者は何を学びに持って帰ってもらえるかが分かりづらくなります。
雑な言い方をすると、問題提起のないプロポーザルは「俺の自慢話を聞け」と言っているようなものです。自慢話を聞いてありがたがるのは、その発表者のことをよく知っているコアな人だけです。万人にはなかなか刺さりづらいです。
聴講者にも刺さる問題提起をした上で、それを解決するための方法を伝える形になっていると、プロポーザルを採択するかどうかの議論上にあがりやすくなります。逆に、問題提起がないと、最初に不採択を決定したり、有力な候補としてに残る可能性が低くなります。
ただし、カンファレンスのジャンルによっては問題提起が不要な場合があります。言語系のカンファレンスのように、特定の技術についての発表を歓迎しているイベントでは、問題提起がなく技術的な内容の共有だけでも採択される可能性が上がるでしょう。
発表内容を表しているタイトルになっているか
プロポーザルがたくさんあると、時間の都合上、どうしても運営は中身を細かく見ることができません。そのため、まずタイトルで判断します。その際に、発表内容を表しているタイトルになっているかは重要です。
例えば、「チームの2年間の取り組みについて」というタイトルを見たらどう思うでしょうか？興味が惹かれるでしょうか？
カンファレンスの運営は採択可否を判断すると同時に、どのようなコンテンツなら多くの人に参加してくれるだろうかと考えます。そして、参加者がまず確認するのはタイトルです。そのタイトルを疎かにしてはいけません。
個人的には、短くて発表内容が表現できていないよりは、長くなってでも内容がわかるタイトルの方が好みです。
具体的な内容が書かれているかどうか
採択の判断をする際に最終的に重要になるのが、具体的な取り組みの記載です。
非常に良い問題提起をしていても、具体的にどのように行ったのかが「詳しくは発表当日にお伝えします」などになっていては、採択することが難しくなります。
アジェンダ程度だとまだ具体的ではなく「本当に採択しても大丈夫か？」と不安になります。当日の発表内容の抜粋をプロポーザル内に書くぐらいでちょうど良いと思います。
また、過去に同様の発表をしている場合は、その発表資料を参考内容として貼っておくのも良いでしょう。
技術的な学びがありそうか
技術カンファレンスを運営する以上、技術的な要素も当然気にします。
単なる「⚪︎⚪︎をやってみた」といった発表だと、ツールや手法の紹介になってしまいます。また、技術的要素が無いと、単なるポエム的な発表になってしまう可能性があります。
そうではなく、直面している課題に対して技術的にどのように乗り越えたのかが書いてあると、採択したいと思えるでしょう。
泥臭さや弱みを見せているか
個人的な好みの範疇かもしれませんが、泥臭さや弱みを見せているプロポーザルは好感が持てます。
成功体験だけを書いていると、聴講者は「あのチームだからできたんだよ」と思ってしまうかもしれません。プロポーザル内で、苦労した点や工夫した点を書いていると、聴講者も追体験がしやすくなり、より学びが持ち帰りやすくなるでしょう。また、そのようなプロポーザルは自ずと、主語が「私の会社」とならなくなります。
泥臭さや弱みを見せているプロポーザルは、他の選考委員との話し合いの場に、私から採択をオススメしやすい気がします。
プロポーザル応募者として、プロポーザル記入時に心がけていること
今度はプロポーザル応募者として、どんなことを心がけてプロポーザルを書いているかお伝えします。もちろん、先ほどまで書いた、採択側が注目している点は前提の上での話です。
セッション内容の1行目に問題提起を書く
私のプロポーザルでは、問題提起から始まります。特に、共感されるような問題提起を心がけます。
例えば、Regional Scrum Gathering Tokyo 2025での私のプロポーザルでは以下の1行から始まります。
手間暇かけて実装し、沢山のケースをテスト実行し、やっとの思いでリリースした機能が、顧客に受け入れられず利用されなかった経験はありませんか？
「あーわかるわかる」と運営に思ってもらえれば、その後の文章が長くても読み込んでもらいやすくなります。
プロポーザル内容には、発表資料化の一歩手前の文章を書く
「カンファレンス運営者として」の方にも書きましたが、プロポーザル内容は具体的に書いてあった方が良いです。そこで私は、発表資料化の一歩手前の文章を書くようにしています。
Regional Scrum Gathering Tokyo 2025での私のプロポーザルでも、説明のために画像もふんだんに取り入れています*7。
採択後は、プロポーザルの記載内容を持ってきて、そこに肉付けするだけで発表資料が出来上がっていたりします。
場合によっては、発表資料作成の時間よりも、プロポーザル作成時間の方が長くなっているかもしれません。
採択者が分かる単語を用いて書く
採択者は全知全能の神ではありません。たとえその分野に秀でている人であっても知らないことはあります。そのような場合でも内容が分かるようにプロポーザルを書きましょう。
たまに、専門用語をたくさん並べて「これらについての解説を発表の中で行います」と書いているプロポーザルを見かけますが、そのような書き方は避けた方が良いです。発表内容如何の前に、そもそもの発表の機会を貰えない（採択されない）でしょう。
タイトルにポップでキャッチーなキーワードを入れる
タイトルの作成には印象に残るようなキーワードを入れるのを心がけます。
例えば、Regional Scrum Gathering Tokyo 2025での私のプロポーザルのタイトルは以下です。
シフトライトなテスト活動を適切に行うことで、無理な開発をせず、過剰にテストせず、顧客をビックリさせないプロダクトを作り上げているお話
ちょっと長いタイトルですが、個人的には「ビックリさせない」をキーワードにしたつもりです。それも「びっくりさせない」ではなく「ビックリさせない」です*8。
あとは、文の構造として「重文」になるように心がけている気もします。普通は重文を避けるべきだと思いますが、セッションタイトルに重文を使うと、読み上げ時にリズム感が生まれ、印象が残るような気がしています。*9
本ブログ記事のタイトルも、最初は「プロポーザルを書くときや審査するときに意識していること」でした。それよりは「プロポーザルを書くときに心がけ、採択するときに注目していること」の方が、読み上げる際の区切りがハッキリして、リズム感があるような気がしませんか？*10
自分視点での話を書く
自分視点での話を書いた方が良いです。特に、自分の専門性を発揮して書けると良いでしょう。
自分のチーム全員で行った施策の場合、さも自分がやったかのように書くのは難しく感じるかもしれません。その際は、チームで行った施策という説明に加えて、自分から見えた考えを足すと良いです。
例えば、Regional Scrum Gathering Tokyo 2025での私のプロポーザルの場合、Feature Toggle (Flag)というチームの施策を、シフトライトなテスト活動という視点で語っています。
おわりに
今回は、プロポーザルを書く上でのちょっとしたコツを書いてみました。本当は、プロポーザルを書く前に行う、カンファレンス選びなどの戦略もお伝えできればと思ったのですが、文字数が多くなってしまうので、今日は書きません*11。いずれ書くかもしれません。
プロポーザルを書く上での参考記事
プロポーザルを書く上で参考になる記事を紹介します。
yuzutas0.hatenablog.com
私と同じくDevelopers Summitのコンテンツ委員である、ゆずたそさんの記事です。私と似たような観点を持ちつつ、見ている箇所が少し違うことが分かるかと思います。
sizu.me
プロポーザルを書き始める前の心構え的な内容が載っています。私の発表内容は、この記事にある中だと「ニッチ枠」だと思っています。
note.com
公開式のプロポーザルとしての意識すべきことが書かれています。また、RSGTやScrum Festでのフォーマットに沿ったアドバイスが書かれています。記事内に書かれている「よく「全部ネタバレするくらい書いてください」とフィードバックします。」という言葉はすごい同意です。
blog.takanorip.com
各見出しはどれも同意ですが、特に「審査員へのラブレター」「LLMは使うな」は、応募者側としても採択者側としてもすごい分かります。
最後に1つお知らせです。
現在、Developers Summit 2026の公募セッションの募集中です。
event.shoeisha.jp
私はDevelopers Summit 2026のコンテンツ委員ですので、本記事に書いたような観点で確認する予定です。ただし、コンテンツ委員は私だけではないですし、数多くの応募があるイベントですので、「記事に書いてあったポイントを全部書いたのに落選した！」「記事に書いてあるポイントを守れていないのに採択されたプロポーザルがある！」といったクレームは止めてください。
とはいえ、本記事をきっかけに、採択をしたくなるようなプロポーザルがさらに増えてくれることを願っています。
