その経験、プロポーザルで伝わっていますか？ デブサミ2027コンテンツ委員が明かす「選ばれるプロポーザル」の作り方

【デブサミ2027連動企画】コンテンツ委員会が明かす「選ばれるプロポーザル」の作り方 ～テーマから審査基準まで！プロポーザルの疑問に答える座談会【Developers Online #4】～

「もったいないプロポーザル」の共通点とは？

言語カンファレンスとの違いは「知らない人」に向けて書けるか

　特定言語のカンファレンスと総合カンファレンスのデブサミとでは、プロポーザルの書き方にどのような違いがあるのか。ブロッコリー氏は、該当言語特有の技術に詳しくない層に向けて書く姿勢が肝要だと答える。自身が言語系カンファレンスへ応募する際にも、「JavaやJUnitの知識はあっても、ソフトウェアテストの専門知識は持たない読者」を想定しているという。特定技術を知っている前提で書かれた文章は、理解のハードルが上がり、採択につながりにくくなる。

　ゆずたそ氏も同様の見解を示す。言語特化のトピックが選出される例もあるが、デブサミは特定言語を専門とするイベントではない。一歩引いた視点を持ち、他言語を扱うエンジニアでも思わず聴講したくなる切り口や、「今こそ学ぶべき理由」を提示することが望ましい。同じ実践内容であっても、見せ方を工夫するだけで聞き手に与える印象は一変するとゆずたそ氏は指摘する。

AIが削ってしまう「泥臭さ」と「その人らしさ」

　生成AIを対話相手（壁打ち相手）として活用しながらプロポーザルを作成する応募者も増えている。ブロッコリー氏が警鐘を鳴らすのは、一見整っていても「自分事」として伝わってこないケースだ。書き手本人の熱量が希薄化し、表層をなぞっただけの無機質な文章になりやすいという。

　ブロッコリー氏は、「私やゆずたそ氏は、むしろ『泥臭さ』を高く評価している。『ここは失敗したが、この工夫によって乗り越えられた』という生々しい試行錯誤を聞きたい。生成AIで文章を一気に整えると、その泥臭い過程が削ぎ落とされてしまう恐れがある」と語る。

　ゆずたそ氏は、生成AIが大量出力した低品質な文章を指す「AIスロップ（AI slop）」という表現を取り上げた。画一的に量産された文章に見えると、審査側には「直接話を聞きたい」という動機が生まれにくい。Markdownのアスタリスク記号が不自然に残っていたり、主張の核心が見えなかったりするプロポーザルも、AIの出力を精査せずそのまま提出した際によく見られる傾向だという。

　ゆずたそ氏は、「私たちは『生身のエンジニアの体験』を求めてカンファレンスに集まっている。だからこそ審査でも『人間が紡いだプロポーザル』を期待している。『この人の話をじっくり聞いてみたい』と感じさせる文章であってほしい」と訴えた。

　両氏は普段、生成AIとどのように向き合っているのか。ブロッコリー氏は、自身が実際に手を動かしていない領域についてAIに書かせないよう徹底している。AIが文章を生成すると、未経験の事柄まで実践したかのように誇張されかねないためだ。「プロポーザル添削くん」においても、具体的な代案テキストは出力せず、改善の視点やフィードバックのみを返す仕様に設計されている。

　一方のゆずたそ氏は、AIが作成した文章を必ず音読し、不自然な点がないか入念にチェックしている。意図とズレた表現が紛れ込むのは人間が書いた文章でも同様であり、QA（品質保証）の観点を持って文章の品質検証を行うべきだと語った。

パターン1：「詳しい内容は当日お話しします」では選べない

　イベントの後半では、ブロッコリー氏が生成AIを用いて作成した架空の「もったいないプロポーザル」3例をもとに、両氏による具体的な講評が行われた。

架空のプロポーザル例・パターン1（内容が薄い・具体性がない）

　1つ目のプロポーザルは、モノリスからマイクロサービスへのリアーキテクチャを題材としたものだ。概要文に見られる「阿鼻叫喚の地獄絵図」という煽り文句について、ブロッコリー氏は「表現としてのインパクトはあるものの、現場で何が起きたのかが具体的に見えてこない」と指摘する。さらに大きな問題として挙げられたのが、「詳しい内容は当日お話しします」と結ばれている点だ。

　ここでブロッコリー氏は、翔泳社刊行の書籍『野蛮なアジャイル［サイボウズ発！］組織の常識を覆した反骨のスクラム実践記』の著者である天野祐介氏が提唱する「ネタバレ上等」の姿勢を引用した。デブサミの公募枠は、約80件の応募に対して採択が10件前後（約1割）という狭き門だ。映画の予告編のように核心部分を出し惜しみして落選してしまえば、セッションの機会そのものを失ってしまう。

　ゆずたそ氏も、応募者と審査側の間に生じる「情報の非対称性」を課題に挙げる。提示されたプロポーザルからは、アーキテクチャ移行の背景や目的、システムの規模、事業の業界や組織体制、移行期間、プロジェクト人員といった前提条件が一切読み取れない。データマイグレーションの手法なのか、データベース設計なのか、組織再編の話なのかも曖昧なままだ。

　このような記述では、誰にどのような学びをもたらす発表なのかを審査側が測ることはできない。マイクロサービスへの移行はすべての現場が経験しているわけではないからこそ、そこには貴重な独自知見が眠っている。ゆずたそ氏は、獲得した教訓を最後まで言語化し、「どのような課題を持つエンジニアに、どんな解決策を提示するのか」を明確に書き切ってほしいと要望した。

　具体性を高めるアプローチとして、ブロッコリー氏は発表スライドの初稿を先行して作成することを推奨する。発表全体の骨組みを可視化してからプロポーザルへ反映させれば、自ずと解像度の高い記述になる。対してゆずたそ氏は、提出前に社内の同僚へ10分程度プレゼンしてみる手法や、ホワイトボードに思考を書き出す方法を提示した。声に出して説明することで、自身が本当に伝えたい論点が浮き彫りになるという。