下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・試行錯誤の瓦礫の記録

トップ > 参加しました > カンファレンスの審査委員として6年で約400件のプロポーザルに投票コメントをしたときの観点

カンファレンスの審査委員として6年で約400件のプロポーザルに投票コメントをしたときの観点

参加しました

筆者はDevelopers Summit（デブサミ）のコンテンツ委員を2021年から2026年まで6年連続で務め、約400件のセッション公募（プロポーザル）に投票コメントを行ってきました。 投票の際にどのような観点を意識してきたのか、自分用のメモをまとめておこうと思います。 カンファレンス登壇に挑戦する方やイベント運営に関わる方のヒントになれば幸いです。

はじめに

注意事項・免責

  • あくまで委員の1人である @yuzutas0 の個人的な意見であり、カンファレンス全体を代表する公式見解ではありません。 審査では他の委員や運営メンバーのコメントが加味されるので「この記事の内容を満たしているか」と「実際に採択されるか」は必ずしも直結しません。

  • 毎回全ての観点でチェックしているわけではありませんし、無理に100点を目指すようなものでもありません。 「個人開発者が土日で試せるTips紹介」と「100人規模の開発プロジェクトの事例共有」と「◯◯技術を紹介する入門講演」と「◯◯職のキャリアを語るトーク」では重視すべき観点が異なるからです。

  • 個別のセッションやプロポーザルを称賛・非難する意図の記事ではありません。 あくまで約400件のセッション案に対して「自分が気になることが多かったポイント」をとりまとめたものです。

  • 「上から目線」に感じさせてしまう箇所があったら申し訳ありません。 応募者と審査委員は対等な関係（むしろ主役は応募者）であり、そこに上下関係はないので、なるべく誤解を招かないように注意しているつもりではあります。 ただ、「投票・審査をする立場」で「登壇のクオリティを追求する」という文脈上、「こうすればもっと良くなるのに」といった表現をせざるを得ないので、その点はご理解いただけますと幸いです。

  • 万が一、不適切・考慮不足だと感じさせてしまう点があれば、それは筆者個人の責任によるものです。 どうぞ筆者個人宛てにご指摘のコメントをいただけますと幸いです。

挑戦する人が一番えらい！

大前提として「応募する」「CfPを出す」といった挑戦は、素晴らしいことだと思います。 Web業界はオープンに情報を共有しあうことで発展してきました。 フリーライドするだけではなく、コミュニティの一員として貢献しようという姿勢は、それだけで称賛されるべきです。 だからこそ「素材が良いのにここがもったいない」「相談してくれたらアドバイスできたのに」というケースを少しでも減らせるように、参考情報として活用いただければと期待しています。

「登壇者」側の立場で書いた記事はコチラ

私が「登壇者」側の立場で意識していることは、以下のポストで紹介しています。 改めて読み返すと、本記事では同じことを「審査員」の立場で書き直しているだけだなと思いました。 これからカンファレンス登壇を行うという人は、ぜひ以下も読んでいただければと思います。

yuzutas0.hatenablog.com

yuzutas0.hatenablog.com

投票にあたって気にしていたこと

①聞き手が明日からアクションできるか

私がCfPを読むとき、真っ先に頭に浮かべる問いは「このセッションを聞いた人が、明日から行動を変えられるか？」です。 いくらセッションを視聴しても、その後の1人1人の行動やアウトプットが変わらないのであれば、無駄とまでは言いませんが、ちょっともったいないですよね。 何かしら聞き手のプロジェクトやキャリアに持ち帰られるような「再現性のある内容」のほうが価値は高いだろうなと考えています。

「xxをやりました」で終わるのではなく「あなたもxxをやりましょう」までメッセージして、聞き手の行動を変えられると最高です。 「この話を聞いた人たちに、明日から何をしてほしいか？」を考えてみると良いかなと思います。

追記：「固定観念に囚われずに解釈してね」というヒント集が以下です。

②キーメッセージが定まっているか

メインとなる具体的なキーメッセージを絞り込んで、そこを深掘りしてくれるセッションだと分かりやすいですね。 登壇者本人の話したいことが「100」あるとして、30分や45分のセッションだと聴講者に「5」伝われば十分だと思います。

私は5分のLTでスライド60枚を話したことがあるので、あまり他人のことは言えないのですが、ついつい色々と詰め込みたくなってしまうんですよね。 複数の大きなテーマを全部話そうとすると、1つ1つの内容が薄くなってしまい、聴講者が知見を持ち帰るのは難しいのではないかと考えています。

テクニックというか裏技としては「後から読み直したくなる体系的なスライド」を見せつつ「シンプルなフレーズを要所で繰り返す」という方法が（一応）あります。 私がデブサミ2018夏でアンケート満足度1位（後のベストスピーカー相当）を取ったときは200枚のスライドの途中で「DataとOpsを繋げよう」を度々メッセージしてゴリ押しました。 ただ、これは相当に中身が充実していないと使えないテクニックなのと、下手に真似しても逆効果になってしまうことのほうが多いので、禁術だとは思っています。

https://speakerdeck.com/yuzutas0/20180727?slide=89

③どんな課題を、どう解決したか

問題解決型のセッションの場合、「○○という課題にどう立ち向かったか」や「○○を実現するには何が必要か」といった核が明確だと魅力的です。

  • 課題が切実であるほど惹かれます。「この課題にずっと悩まされてきた」といった強い問題意識に基づいたセッションは、聞き手にも刺さりやすいと考えるからです。
  • 技術面あるいは組織面で工夫したこと、こだわったこと、苦戦したこと、有効だったアプローチなどが明確だと良いですね。泥臭い部分まで見えると、聞き手にとって学びが多いセッションになるのかなと思います。

「◯◯をしました」だけだと、聞き手が「はぁ、そうですか」で終わってしまい、ちょっぴり物足りなさを感じてしまうかもしれません。 「××を導入しました」しか書いていないと「なぜわざわざ導入したのだろう？」「それで何が嬉しいんだろう？」「導入時にトラブルはなかったのだろうか？」といった疑問が湧きます。 単に「導入して終わり」であれば、公式ドキュメントのチュートリアルを読み上げれば良いだけなので、そのセッションならではの話を聞けると嬉しいなと思います。 「こういう課題があったからxxを導入した」「xxを導入するにはこういうネックがあって、こうやって泥臭く解決した」といった実践的な話のほうが、個人的には好みです。

私の登壇資料を例に挙げると「NoCodeツールを使いました」ではなく「1年で決済サービスを立ち上げるスピード感」「決済機能以外のオペレーションにまでシステム開発工数を投下する余裕がない」と背景を伝えた上で「だからNoCodeを使った」「このツールをこう組み合わせてこの業務をシステム化した」と具体的に説明した後、「NoCodeツールだと追加要望に耐えられなくなった」「こういうタイミングでこういう順番でシステムを移行した」まで紹介し、「新規事業の立ち上げにおけるNoCode活用の勘所」を包括してノウハウ化しました。 ここまで話せば「この発表と同じようにあの案件でNoCodeツールが使えるかもしれないぞ」「NoCodeツールの検討時には必ずこのスライドを読もう」といった参考にできますよね。

speakerdeck.com

④どんな成果を出せたか

Before / Afterで「こう変わった！」をバシッと示せると分かりやすいですね。データやベンチマークがあるとさらに説得力が増します。 数字で示せるならそれが一番分かりやすいですし、定量的に示せない場合でも、具体的なエピソードがあると伝わりやすいかなと思います。

成果は大きければ大きいほど、魅力的だと考えています。 「5案件やりました」より「200案件やりました」のほうが、コツがパターン化されているだろうなと期待できます。 「10%改善しました」より「500%改善しました」のほうが、クリティカルなポイントを抑えているだろうなと期待できます。 「検証しました」より「本番環境の3割に展開しました」のほうが、実際に使う上で相性の良い箇所・悪い箇所まで学べるだろうなと期待できます。 「1時間の作業が30分になりました」より「2週間の作業が3時間になりました」のほうが、「時間を確保できなくて諦めていた作業」を土日で試せるのではないかと期待できます。 言いたいことは「小手先の数字を調整して上手くアピールしましょう」ではなく「普段から業務の成果にこだわろうぜ」です。

登壇者の立場だと「現在進行系で取り組んでいること」を話したくなりますし、そもそもの登壇目的が「現在進行系の取り組みをアピールするため」であったりします。 一方で、取り組みとしては中途半端な時期であったり、「むしろこれからが本当に学びを得るタイミングなのでは？」といった状態だと、聴講者が困惑してしまうのかなと思います。 「ダイエットに成功した人の事例」を聴きたい人は沢山いるはずですが、「まだ痩せていない人の語るダイエット論」を聴きたい人はそこまで多くないのではないでしょうか。

こういうタイミングで登壇を重ねたり過剰な外部評価を受けてしまって、根気強く本業を進められなくなってしまい、かえって業務成果が遠ざかってしまったという人を見たこともあります。 「今の状態だと表面的な話で終始してしまっている印象を受ける」「むしろ3年後に振り返りを聞きたい」「ポテンシャルがあるからこそ今の状態で通すのは勿体ない」というパターンには警戒しています。 論文を投稿した後に学会で発表したり、業務をやり抜いた後に成果報告をするようなイメージですかね。 ダイエットを語るのは、ダイエットに成功してからのほうがカッコいいのではないでしょうか。

私の登壇資料を例に挙げると「4ヶ月で19チームからの120依頼を捌いてコンバージョンを2.8倍に増やした」「未経験の新人が3,500テーブル10万カラムのレガシーシステムに数カ月でキャッチアップした」「1年で300案件のデータ集計業務に対応した」「1営業日あたり2件のシステム障害に対応した」「毎年の売上が3倍、四半期ごとにメンバーが2倍に増えていく急成長組織を立て直した」「ピーク時間帯のレスポンスタイムを400倍改善した」「KPTの付箋がProblemだらけだったのをKeepだらけに変えていった」といった切り口でアピールしていました。 ※ちなみに私1人の成果ではなくチームの成果です！大事なので一応！

speakerdeck.com

⑤位置付けを俯瞰できているか

どの部分の話をするかが明確だとイメージをしやすいです。 「この業界の、この会社の、この業務の、このシステムの、この部分について話す」という説明が一言あるとありがたいなと思います。

応募した人は当事者ですから、自分では分かっているかもしれません。 しかし、説明がないと聴講者に位置付けが伝わりにくいということもあります。

「大企業のシステム再構築の話」を期待してセッションを聴いたのに、中身が「ある部署の簡易ツールを若手が1ヶ月で置き換えた話」だったら、あまり良い反応は得られないでしょう。 同じように「この会社ならモバイルアプリの話だと思ったのにDBの話しか出てこなかった」といった期待ズレも時折見かけます。 そのセッション内容や取り組みが悪いというわけではなく、取り組みの位置付けが明記されていないせいで、セッションに対する期待がズレてしまうのです。

なので、取り組みの位置付けについては、一言書いておくに越したことはないと思います。 自分の仕事の位置付けを客観的に話すことは、上司への成果報告でも、他部署・他職種との連携でも、転職面接でも求められることなので、カンファレンス登壇を練習機会にできると良いですね。

また、応募した人が全体像を把握できていないまま業務を進めており、位置付けを正確に説明できないというケースもあります。 このケースでは「そもそもの取り組みが局所最適化されており、全体最適になっていない」と聴講者に感じさせてしまうので、あまり良くないかなと思います。 SNSやアンケートで「自部署だけならこれで良いだろうけど、他部署にとっては迷惑じゃない？」「話題のツールを使えば良いってものじゃないでしょ」とツッコミが入る恐れがあります。 資料作成や質疑応答を通して「もしかして俺の視野って狭かった？」「他部署にヒアリングしようかな」と気付けるのも登壇の醍醐味ではありますが、できれば応募前に自分で気付けるほうが良いでしょう。

⑥具体的な事業や技術に言及しているか

最新技術の派手な紹介ではなくても、「具体的」というだけで魅力的に思えることがあります。 「自社でアジャイルな文化を醸成しました」だけだと、「よく聞く話ではあるかな」「この会社にとっては新鮮だろうけど10年前から資料も書籍も無数にあるよね」とは思ってしまいます。 ところが「◯◯業界でアジャイルな文化を醸成した」とか「◯◯ツールでアジャイル文化を加速した」といった切り口があると、「聞きたい！」「なるほどね〜」と興味を惹かれやすくなります。

なぜかと言うと「実践に繋げやすいから」「深堀りしやすいから」ですね。 事例や技術、手法が具体的であればあるほど、聴講者がプラクティスを真似したり、他のコンテンツと比較して考察を深めやすいのかなと思います。 ふんわりした成功談や一般論だけだと、聴講者がどこまで再現できるのか見えないので、票を入れづらくなってしまいます。

⑦手を動かしているか／手を動かせるか

デベロッパーズサミットなので、デベロッパー（作り手）のためのイベントであってほしい、と期待しています。 デベロッパーに向けてデベロッパーが話をする場であってほしいです。 だから「手を動かして実践した事例」や「手を動かして真似できるプラクティス」を共有するセッションのほうが好ましいと感じます。

人材の採用や育成、キャリアや働き方、組織設計やカルチャーを扱うテーマであっても同じです。 実践した話、実践できる話のほうが、机上の空論より魅力的です。

「こういうものを作りました」「こういうアクションを行いました」まで言い切るほうがカッコいいなと思っています。 「こういうアーキテクチャで設計しましょう」「こういうサンプルコードを実装しましょう」まで提示できるほうがクールだなと思っています。 せっかくデベロッパーの話を聞くなら「経験と実践にもとづいている活きたノウハウ」「実装まで見据えたガイド」のほうが有益だと考えています。

手を動かして（＝実践して）初めて気付けることは沢山あります。 「一見すると簡単そうな実装だと思ったら、トラップを踏み抜いてしまって苦労した」という苦い経験は、デベロッパーなら誰もが通った道ではないでしょうか。 その経験をした後に、実装していない人が「こんなの簡単でしょ」「これが大事だよね」と言っているのを聴いても「そこじゃないんだよな〜」と冷ややかな目で見てしまうはずです。

抽象的な概念や用語、「◯◯が大事だ」といった論説や問題提起で終わってしまうのは、それと同じことかなと思います。 一見するとそれっぽい話になるかもしれませんが、実践している渦中の人たちから見ると、やはり内容としては浅く感じてしまうのではないでしょうか。 「デベロッパーなんだから手を動かしてなんぼやで！」「自論を語りたければ事例紹介の最後の1ページに詰め込むんやで！」という点は掲げたいと考えています。

⑧汎用的な学びに言い換えられるか

デブサミの公募セッションでは「宣伝」ではなく「知見を共有する場」であってほしいと期待しています。 スポンサーセッションやベンダー主催イベントは別に存在します。「この枠だからこそ聞ける話」を優先したいと思っています。

「自社の宣伝色が強いのではないか」「特定の製品を導入するという結論ありきの話ではないか」と感じてしまうような内容は投票しにくいのが正直なところです。 特定の製品やサービスありきの話になっていないか、「このツールを使うと便利です」で終わってしまっていないか、は気になります。

もちろん個々のテクノロジーにはそれぞれに独自の特徴がありますし、それらの技術を活かしたり組み合わせることも、エンジニアリングの醍醐味の1つではあります。 その年を代表するようなテクノロジーであれば、サービス名をタイトルに入れたほうが、参加者にコンセプトを伝えやすくなるのも事実です。

なので、特定の製品を取り上げること自体は問題ないのですが、事例から「汎用的な学び」を抽出してメッセージするといった調整をするのがポイントですね。 セッションを聞いた人が「この発表は製品Aの事例だけど、製品Aを使っていない人も絶対に聞いたほうがいい！」と周りに紹介したくなるような内容だと最高です。

⑨このタイミングでその話を聴きたいか

年に1回のカンファレンスは、その年の技術トレンドを切り取る「スナップショット」のような役割を持っていると私は考えています。 「このタイミングで話すことの意義」が明確になっていると良いですね。 「◯◯技術が登場してから10周年」であれば、前年でも翌年でもなく、その年に話したいでしょうし、その年に聞きたいですよね。

また、技術トレンドには成熟度があります。 登場初期は「こういう技術があります」「試してみました」という紹介だけでも有益ですが、数年経つと当たり前になってしまいます。 そうなると「実務での泥臭い工夫や試行錯誤」「一定期間運用してからの振り返り」のほうが求められるのかなと思います。 実践事例が増えてくると今度は「よく聞く話ではあるかな」「既存コンテンツとの差分が明確だと分かりやすいかも」と感じてしまうことがあります。 さらに一周すると「あえて今だからこそ定番テーマを振り返る」という内容が絶賛されることもあります。

節目や差分を意識しすぎて説明が過剰になると逆効果なので、CfPでは「さらっと一言だけ触れておく」くらいが適正ボリュームかなと思います。 「AIエージェントに開発を任せるときにテストが不十分だとトラブルになる」「だから改めてテストコードについて学ぼう」みたいな一言があるだけでも十分です。 「テストコードを解説します」だけよりも、このタイミングで話を聴くことの意義が伝わります。

⑩この登壇者からその話を聴きたいか

セッションの価値は「テーマ」だけで決まるのではなく、「テーマ」と「登壇者」の組み合わせで決まると考えています。 「分野Aと分野Bの組み合わせなら（我が社が｜私が）強いんですよ」「だからこの話をするなら私が適任なんですよ」という自己PRが添えてあると、説得力や納得感がありますね。

これは決して「メガベンチャーや有名企業だから良い」という意味ではありません。 「無名のスタートアップならでは」「土日の趣味開発者ならでは」の観点もあるはずです。

もちろん「このテーマなら著名な開発者に話してほしいな」と推薦コメントが挙がることもあります。 特定領域で実績を積んでいる方、過去の登壇で評価が高かった方、書籍執筆の実績がある方であれば、誰もが「この人がこの話をしてくれるなら楽しみだ」と思うはずです。 それはそれとして、無名には無名の戦い方というものがありますし、誰もが最初は無名だったはずなので、なにごとも工夫次第です。

⑪話す内容がイメージできるか

CfPを見た時点で「当日どんな話が聞けそうか」がイメージできるかどうかは、ついチェックしてしまうポイントです。 CfPには「目次」と「各パートの概要」まで書いてあると最高ですね。 具体的なアジェンダ案やキーワードが盛り込まれていると安心できます。

yuzutas0.hatenablog.com

「○○についてお話しします」程度のざっくりした説明しか無いと、「で、具体的には何を話すのだろう？」とモヤモヤしてしまいます。 「Aを進めるときのコツを解説します」だけだと肝心の「コツの中身」が分からないので、発表の良し悪しを判断できません。 「Bを実装したときのアーキテクチャを解説します」だけで、肝心のアーキテクチャが添付されていないと、設計内容の良し悪しを判断できません。

「この記載だけだとちょっとイメージできないかも」「ここがハッキリ書いてあれば推せるのにな…惜しいな…」という提案は毎年あります。 過去の私の投票を読み返すと「具体的にどんな話になるのかアジェンダ案もほしかった」「このフォームの内容だけだと判断しかねる」「採択するには少し不安」といったコメントが度々登場します。

具体的な内容が見えず、何を話すのかが想像しにくいと、残念ながら選定のテーブルに載せること自体が難しいなと感じています。 情報不足で審査員からは判断のしようがないからです。 CfPのタイトル案が抽象的であったり、詳細が書かれていないと「内容が分からないので採択できない」ということになってしまいます。

応募時点で「詳細なアジェンダ案」まで書き出せば、審査員もイメージしやすいですし、応募者自身も自分の考えを整理できるはずです。 私自身もよくあることなのですが、自分では整理できているつもりでも、いざスライドを作り始めると「何をどう話せば良いんだっけ」と迷ったり、「やっぱり方針転換したい」と思ってしまうことがあります。

あるいは、参考資料としてスライドやブログ記事が添付されていて、そこに具体的な内容が書かれていると判断しやすいかなと思います。 参考資料が添付されていれば、少なくとも私は全てに目を通しています。 パワーポイントファイルだと手元で開きにくかったり端末によってレイアウトがズレたりするので、個人的にはPDFやURLのほうが嬉しいです。

⑫フィードバックとブラッシュアップを経ているか

既にテックブログに記事があるとか、過去のカンファレンスで登壇実績があるとか、何らかの形でコミュニティからフィードバックを得ていると安心感があります。 過去に似たテーマで複数のアウトプットを出している場合、「今回も同じような資料や内容になるのかな」と方向性や品質水準が掴みやすいです。 素材が良ければ良いほど「この内容で一度ブログ記事を書いてフィードバックをもらってみてほしいな」「ブラッシュアップしたらもっと良くなるのでは」と思うことはあります。

個人的な意見ですが「大きなイベントで初登壇デビューする」「誰にも言わずに温めてきたアイデアをカンファレンスでお披露目する」といった「一発逆転狙い」は典型的なアンチパターンだと考えています。 緊張して上手く話せなかったり、トーク内容が荒削りで質疑応答がしどろもどろになってしまったりと、後から思い返すと「うわあああああ」と叫びたくなるような黒歴史になってしまいがちです（体験談）。 仕事の段取りと同じで「小規模な勉強会のライトニングトークで場馴れしてからステップアップする」「個人ブログで反響を得た内容をカンファレンスで話す」といった進め方を推奨します。 「誰にも評価されていなかったことがカンファレンスに登壇したら評価されるようになる」というよりも「以前から一部で評価されていたことがさらに広まる」ほうが実態に近いのではないでしょうか。

伝えたいニュアンスは「先送り」（反響を得てから◯ヶ月後に挑戦しましょう）ではなく「行動量」（もったいぶらずに今すぐ大量にアウトプットしてフィードバックを浴びましょう）です。 ITシステムを作るときにビッグバンリリースではなく毎週小さくリリースする、ITシステムを直すときにビッグリライトではなく毎日小さくリファクタリングするのと同じですね。 コツコツと出していれば「大きな失敗はしないだろう」という安心感がありますし、テストできていないと「大丈夫かな」と不安に思います。 もし不安にならないなら、それはそれでデベロッパーとしてどうなのかなとも思います。

特にこのパートは（他のパートもそうかもしれませんが）人によって賛否両論あると思います。 登壇者の視点だと「挑戦するから機会を得られる」「機会を得るから本気になれる」「恥をかくから学べる」という側面もあります。 イベント運営としては「気軽に応募してね」というスタンスのほうが健全です。応募の量が多いほど、参加者の裾野が広いほど、質の高いコンテンツも多くなります。 それはそれとして、私の審査コメントでは「一通り記事が揃っているので安心感がありますね」「過去の登壇資料めっちゃいいですね」「登壇経験ナシだけど大丈夫かな」とは書いてしまいます。

⑬職場で上司・先輩のレビューを突破できる状態か

会社に就職すると、上司・先輩が新入社員の書いた文章をレビューする、という場面があると思います。 「このままの文章だとちょっと良くないかもね」というケースで、レビューを通して、仕事のスタンスや専門知識をインストールしていくわけですね。 このステップを突破している人、まだ突破していないけど登壇に向けたレビュー体制を確立できている人（＝上司や先輩のサポートを受けている人）だと、安心感があります。

「上司や先輩から細かいレビューを受けたほうが良さそうかも」「登壇が公開処刑になりそうでマズいかも」「社内のミスと違って守ってくれる人はいないけど大丈夫かな」と思ってしまうと、投票しにくいのが正直なところです。 例えば、生成AIが出力した「**」がそのまま残っていたりすると、本番のスライドでも目立つミスをしてしまわないかな、と不安になってしまいます。 また、GitとGitHubの違いを理解できていなさそうだったり、用語の使い方が少し独特だったり、視座が低い（ちょっと自分本意すぎるかも？な）主張だったりすると、大丈夫かなと気になってしまいます。

「上司や先輩の細かいレビューが必要な人」はカンファレンス登壇をする前に、まずは1人前の社会人になることを、そして1人前の専門家になることを目指すのが筋でしょう。 あるいはせめて上司・先輩に登壇を応援してもらい、適切なレビューを受けられるように、社内の関係性を築くところからスタートだと思います。

念のために補足ですが、わざわざCfPで「上司や先輩にサポートを受けています」と書かなくて良いです。 「レビューを受けてブラッシュアップした状態」「上司や先輩から120点と認めてもらった状態」のCfPを提出しましょう。

⑭全体のバランスが偏っていないか

応募者からは「運」としか言いようがないのですが、良いセッションであっても「カンファレンス全体のバランス」を考慮して投票しないというケースがあります。 例えば「似たテーマが集中しすぎた」「他のテーマが魅力的すぎて票を使い切ってしまった」などの理由によって、やむなく採択を見送るケースが（悲しいことに）存在します。

「毎年デブサミで聞きたい定番ネタ」や「その年ならではのトレンドネタ」がちゃんとラインナップに入っているか、といった全体のバランスも意識して投票しています。 LLMが注目された年には「最低1本はLLMを組み込んだプロダクトの事例紹介が欲しい」というコメントをしました。

だからこそ、もし応募が採択されなかったとしても、それはセッション内容が「ダメだった」とイコールではない、ということだけは知っておいてほしいです。 むしろ「俺のセッションを落とすなんてバカなことをしたなぁ」と嘲笑うように、別の場所でアウトプットを出してバズらせるくらいの心意気が丁度良いと思います。

他に審査委員として意識していたこと

審査委員として以下のような点を意識していました。 このあたりは社会人の会議スキルと言いますか、なるべく多くのステークホルダーがなるべく幸せになるようにベストを尽くしてきたつもりです。

①全てのセッションに事前コメントをつける

他メンバーは50件中10件など、注目したセッションに絞って事前にコメントを記載しておき、ミーティングの場で追加の議論を行っていました。 私は業務との調整が難しく、ミーティングに欠席・途中参加・早退となることが多かったので、言いたいことは先に全部コメントを書いておきました。 結果として他メンバーが議論をするための叩き台として機能していたように思います。 業務調整面でご迷惑をおかけしてばかりで申し訳ないなと思いつつ、その弱みを補う形で、自分なりに委員会に貢献してきたつもりです。 必ずしもお互いの関係値が深くない状態で協力しあうわけですから、表面的な振る舞いではあっても「きちんと貢献しますよ」というスタンスを示すことは大事だと考えています。

②なるべく票を分散させる

他メンバーの投票が一部のセッションに偏っていたら、なるべく票をバラけさせるようにしていました。 審査員1人あたりの持ち票数が限られているので、投票先が偏ってしまうと、候補が減り過ぎてしまう恐れがあるからです。 全体を見渡すと「良さげなセッションなのに投票がない（または少ない）」というケースが度々発生するので、せっかくなら沢山のセッションが候補に残るほうが良いかなと思っています。 運営が意図を汲み取ってジャッジできるように「良い内容だと思いますが、票をバラけさせるために、このセッションには投票しないでおきます」とコメントを残すようにしています。

追記：同じ委員のbroccoli氏からのツッコミ。確かに。

③ディスカッションの場で補足説明や解説を行う

他メンバーに比べて相対的に私が詳しい領域の場合、技術面やトレンドの解説を行いました。 話し合いの場で「あまり理解されていなさそうだな」と感じたときに挙手して解説を行う流れです。

キーワードとしては主に、SRE、IaC、CI/CD、クラウドインフラ、DevOps、アジャイル、スクラム、リーン、組織開発、採用・育成、EM/CTO、アーキテクチャ、マイクロサービス、データテクノロジー、データサイエンス、機械学習、キャリア、転職、フリーランス、起業、個人開発、プロダクトマネジメント、事業開発、グロースあたりですかね。こうやって並べると胡散臭いですね。 「海外でこういう議論や事例があります」「その流れを組んだ取り組みなのだと思います」といった形で、応募者の文章を補足していました。 単に感想や自論を語るだけだったら審査員としてのバリューを出せないので、こういう部分が期待されているのかなと自分なりに意図を汲んで動いていました。

自分が説明できない分野については「◯◯さんの意見を伺いたいです」とコメントしていました。 もちろん私も（実態が伴っているかは別として）「業界を代表するデベロッパーの1人」という扱いをしていただいている以上、分野を問わず、自分なりに可能な範囲で用語を調べたりツールを試したりはします。 ただ、「用語を知っている」「ツールを使ったことがある」のと「コミュニティでの議論や温度感まで把握している」「各社の実践状況や課題感まで見通せている」にはギャップがあります。 リアルな情報を引き出すには、やはり各分野の第一人者に直接語ってもらうほうが筋が良いと考えています。

④条件付き採択を提案する

応募時の文章だけを見ても、他メンバーがピンと来ていないときに「この観点で話せば反響があるのでは」「ここだけ変えれば良いのでは」「ここに絞り込めば良いのでは」と提案をしていました。 他メンバーが「確かにその観点なら聞いてみたい」「グッと良くなりますね」と納得してくださって、一気に投票が増えたこともありました。 着地としては「この観点で話してもらうように打診しましょう」という条件付きの採択になります。

これは私自身がデブサミのベストスピーカー受賞（正確にはアンケート満足度1位）の経験者だからこそ出せるバリューかなと思います。 「せっかく素材が良いのに、その切り口だと魅力が伝わらなくて勿体ない！」と思ってしまうことは度々あります。 「来年こそはカンファレンスの公募開始と同時にCfP添削イベントを開きたいな〜」と話しては毎年忘れてしまっているので、さすがに来年こそは……？

⑤有名人投票に「待った」をかける

過去の登壇者や業界の著名人など、運営メンバーや審査委員が信頼しているような人のセッションについて「Aさんの話だったら聞きたいよね」といったコメントが挙がることがあります。 もちろんクオリティが伴っているのなら良いのですが「CfPの内容がちょっと不十分じゃないかな」と思えるケースもあり、そういうときは「待った」をかけます。 「適当なCfPでもAさんなら通してOK」という関係性はあまり健全ではないと思っています。そういう成功体験を得てしまうと、ご本人にとっても良くないことだと思います。 周りの全員が受け入れモードで「Aさんなら良いよね」と話している中で「いやー、どうですかねー」と言い出せる人はあまり多くないので、言える人が言うしかないでしょう。 「Aさんには自分もお世話になりましたし、きっとこういう話をしてくれるでしょうけど、それはそれとして、このCfPで通すのはちょっと厳しくないですか」とコメントしています。

⑥ダイバーシティへの配慮については賛成も反対もしない

相対的に男性の登壇者が多くなりがちな業界なので、ダイバーシティ、特に女性の登壇について考慮する場面はゼロではありません。そこまで多くもないですが。 私自身も、若手時代に有名な企業に所属していたからこそアウトプットに注目してもらえた側面があるので、一部の人が下駄を履かせてもらうことについては否定できません。 誰かを意図的に優遇しようがしまいが、無意識のうちに別の誰かを優遇しているだろうからです。

むしろ個人的にこれはデブサミの良い部分だと思っています。 ベンダー主催のカンファレンスと違って、子連れで参加しても罪悪感を覚えないように配慮されていますし、スーツでも私服でもジャージでも気兼ねなく質疑応答できる雰囲気が良いですね。 「フロントエンドのセッションだけ」「大企業の事例だけ」「著名人の発表だけ」に絞らないのと同じように、登壇者の性別についてもバランスを取ることは自然な流れだと思います。

それはそれとして「最低限のクオリティは担保すべきだ」とも思っています。 なので、他の人たちがダイバーシティ観点に言及している場面では、意図的にノーコメント（沈黙）を貫き、セッション内容についてのみコメントしています。 あとぶっちゃけ、氏名や写真や言動がどれだけ女性らしく見えても、本人が自己開示しない限り、私には性別を判断できないので、余計なことを言うのは抵抗感があるな〜とも思っています。 かといって登壇者の属性が露骨に偏ったらそれはそれでネガティブでしょうから、ある程度は割り切って誰かが決めるしかないんでしょうけどね。

おわりに

あなたが取るべきNext Action

他人に指摘しておきながら自分ができていないというのはカッコ悪いので「この記事を読んだ人」へのNext Actionを提示しますね。

  1. 読者全員に対して提案したいのですが、「今の担当業務」を書いて、生成AIに「この業務で圧倒的な成果を出してカンファレンスで登壇したい。どのような成果を目指すべきか。どのようなCfPになりそうか。この記事の指摘事項に注意しながらプランを練りたい。」と渡してみてください。
  2. あなたがCfPに応募する立場であれば（＝カンファレンスが近づいているタイミングであれば）、「自分のCfP草案」と「この記事のURL」を生成AIに渡して、各観点のスコアをつけてもらい、ブラッシュアップに向けたアドバイスをもらいましょう。
  3. あなたがCfPを審査する立場であれば、この記事を叩き台にして「賛成する箇所」「反対する箇所」を書き出してみましょう。それらを生成AIに渡して「自分なりの審査ポイント」をまとめ直してもらいましょう。「その審査ポイント」と「審査対象のCfP」を生成AIに渡して、各観点のスコアとコメントの草案を作ってもらいましょう。

こうして書き出すと「ゆずたそCfPレビューAI」みたいなWebサイトなら簡単に作れそうですね。 デブサミ以外のカンファレンスだと、また違う評価ポイントになりそうな気もしますが……。

おまけ①：印象に残っているセッション

おまけとして、ちょっとした小話を。

公募セッションではないのですが、デブサミ2022のGitLab社のセッションが特に印象に残っています。 2021年10月のキックオフ会議で私が「コロナ禍においてGitLab社のリモートワーク事例はぜひ日本中のデベロッパーたちに共有すべきだ」と強く提案しました。 正確なスケジュールや前後関係までは把握できていませんが、おそらくスポンサーセッションの詳細が確定する前だったはずです。 他の運営メンバーも覚えていないでしょうし、登壇したご本人たちも私のことなど知る由もないでしょう。

codezine.jp

この登壇者2名が監修しているのが以下の書籍です。 デブサミを運営している翔泳社さんから2023年9月に出版されて、多くの日本企業がリモートワークを推進するためのヒントになりました。 詳しい事情や経緯までは存じ上げないものの、流れとしては上記セッションがきっかけとなって出版企画が立ち上がったと考えるのが自然でしょう。 間接的にではありますが、私のコメントが巡り巡ってこうしたアウトプットに繋がったのだと思うと、誇らしい気持ちになります。

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ

Amazon

デブサミに限らずですが、審査委員会は「これをもっと世に広めるべきだ」という技術、事例、ノウハウを水面下で後押しできる立場だと思っています。 ある意味では登壇者よりも業界に（内容によっては日本全体に）インパクトを与えることができる役割です。

実質的にはボランティアのようなものです。謝礼はいただいていますが、金額としてはあってないようなものです。 登壇者や著者のように目立つ存在ではありませんし、目立つべきでもありません。 自分の貢献内容を周囲に認知していただく機会もありません。わざわざ認知したりアピールする必要もないでしょう。

しかし、業界の先輩方から多くを与えていただいた分だけ、今度は後輩たちに多くを与えていかなければいけないと考えています。 私も自分が知らないところで諸先輩の皆様に水面下で支援していただき、下駄を履かせてもらっていたのだと思っています。 その上で期待に応えて評価を得られるかどうかは最終的には本人次第ではありますが……。 少なくともポテンシャルのある登壇者を舞台に上げるところまでは、審査委員が果たすべき使命であり、業界に対するコントリビューションだと思います。

だからこそ検討委員会が無責任なディスカッションをしているとイラッと来ますけどね。国家試験の検討材料になる自覚が本当にあるのかよ、居酒屋の雑談じゃねぇんだよ、後工程に迷惑をかけるんじゃねぇよと。

おまけ②：私がデブサミに期待していること

運営メンバーから「今年のデブサミに期待していること」という質問を毎年受けています。 私は毎回同じ回答をしているので、改めて文章にしておきます。 翔泳社の近藤さんたちには「そういえば去年も同じことを言っていたな」「こいつは毎回ブレずに同じ回答をしているな」と思ってもらえているはずです。おそらく。

この話をするには、私とデブサミの出会いから説明しなければいけません。 私が新卒1年目のときに開催されたデブサミ2015にて、リクルートMTLの黒田樹さん（@i2key）が登壇していました。 「社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について」というタイトルで、アンケート満足度1位（ベストスピーカー）を受賞しています。 私自身はデブサミには参加していなかったのですが、後からその登壇資料を読んで「自分はこういう仕事がしたくて入社したのだ」と感激しました。

www.slideshare.net

さらにその後のデブサミ2015夏では、直属の上司だったリクルートR-Techの志田さんが登壇しました。 「経営のアジリティを支えるDevOpsと組織」というタイトルで、アンケート満足度2位だったそうです。 担当業務の意義を理解しきれずに反発していた当時の自分にとって、自分たちがいかに価値のある挑戦をし、業界にインパクトを与えているのかを学ばされました。

www.slideshare.net

黒田さんも志田さんもSIer / ITコンサルティング会社で基礎スキルを徹底的に磨いた背景があり、その上で今の活躍をしている、という話を教えてもらいました。 そこで「まずは基礎スキルを徹底的に鍛えよう」「そしてデブサミで発表できるような成果を出そう」「自分もベストスピーカーを目指そう」というキャリアの目標を設定しました。

その後、新卒3年目に担当したプロジェクトで「これならデブサミの1位を狙える」という成果を出すことができました。 「Rebuild Team - 急成長プロダクトのDev&Opsで生じる悪循環とその解決策」という登壇資料で紹介しています。タイトルは黒田さん登壇のオマージュです。 SPI Japan 2017というカンファレンスの登壇資料で、主催者からは「これをデブサミではなくうちで話してくれてありがとうございます（笑）」と言われたのを覚えています。

speakerdeck.com

デブサミ2018の登壇に向けて、2017年の夏に10本のLT発表、2017年の秋に3本のカンファレンス登壇を行い、1つは賞を取るという中間目標を設定しました。 3本のうち1つが前述のSPI Japan 2017です。もう1本がPyCon JP 2017で、目標設定した通りにベストトークアワード優秀賞（2位）を受賞できました。 PyCon JP 2017の登壇をきっかけにして社内外から次々に相談やチャンスが舞い込み、残念ながらデブサミ2018で登壇する余裕はなくなってしまいました。 そのときに打ち込んだ仕事が今日までのキャリアにそのまま繋がっています。

speakerdeck.com

その後、当時デブサミのコンテンツ委員会だった黒田さんからの推薦で、デブサミ2018夏に登壇する機会をいただきました。 奇しくも（経緯を考えると必然ではあるのですが）2015夏の志田さんと同じ登壇枠です。 ここでは「事業のグロースを支えるDataOpsの現場」という登壇を行いました。タイトルは志田さん登壇のオマージュです。 この登壇でアンケート満足度1位（翌年以降のベストスピーカー賞に相当）を取ることができました。

speakerdeck.com

その年度末に紆余曲折あってリクルートを退職することになりました。 デブサミで受賞できたことも1つの節目になったように思います。

yuzutas0.hatenablog.com

ということで、私にとってデブサミとは「ロールモデルを見つける場」「業界で活躍するための登竜門」です。 私がデブサミに期待することもまた同じです。 世のデベロッパーにとって「ロールモデルを見つける場」「業界で活躍するための登竜門」であってほしいと期待しています。

聴き手として参加して「こういう仕事をやってみたい！」と憧れを持ち、デベロッパーとして成長した上で、登壇者として参加して「こういう仕事をやってみたよ！」と発信する。 そんなポジティブなサイクルを回しながら、業界発展を牽引できる場であってほしいと期待しています。

おまけ③：デブサミ2026登壇のご案内

ということで、憧れている先輩方（増井さん、t-wadaさん）に対して、私が根掘り葉掘りヒアリングする枠を設けていただきました！ 「最前線で10年走り続けるための秘訣」「大量のインプットとアウトプットを習慣化するコツ」を一緒に学びましょう！

kazaneya.com

業界を盛り上げていきましょう！

以上、デブサミのコンテンツ審査における私なりの観点をつらつらと書いてみました。 繰り返しになりますが、これはあくまで私個人の「私的な振り返り」であって、公式な審査基準とは全く異なります。 「こんな見方もあるんだな〜」「確かにこの部分は大事かもね〜」程度に受け取っていただければと思います。

実際には全ての観点で100点を取るような完璧なセッションが存在するわけではありません。 相対評価の中で「どのセッションを優先するか」を判断しています。 また、私が推したセッションが必ずしも採択されるというわけでもありません。 他の委員の方々は私とは違った視点を持っていますし、年によって議論の内容もけっこう変わったりします。 「これは聞きたかったけどな〜」「あれを落とさざるを得ないのか〜」と内心ショックを受ける場面もありました。

どのセッションも応募者の方々の熱意が伝わってきて、全部採択したくなるのが本音です。 枠に限りがある中で「デブサミらしさ」を大切にしながら、参加者にとって価値のあるプログラムを組むために、議論を重ねてきたつもりです。 幸いデブサミは登壇後にスピーカーの方々から「発表してよかった」「刺激になった」という声を聞くことも多く、微力ながら良い場作りに貢献できているのかなと感じています。

来年まで私が委員をやるのかは不明（さすがに7年連続は多すぎるかも？）なので、残念ながら来年はこの記事が役に立たなくなるかもしれません。 それはそれとしてCfPを採択する側の見え方を知っておくと、参考になる部分もあるのではないかと思います。 皆様のカンファレンス登壇やコミュニティ運営の参考としていただければと思います。ぜひ一緒に業界を盛り上げていきましょう！

最後までお読みいただき、ありがとうございました。