Slide 1

Slide 1 text

「話せることがない」を乗り越える 〜日常業務から登壇テーマをつくる思考法〜 伝わるプロポーザルの書き方 〜採択側・人気登壇者が明かすCfPの構造〜

Slide 2

Slide 2 text

自己紹介 み た に し ょ う へ い 三谷 昌平 @shohei1913 2020年 スマートバンク入社 2024年 Engineering Mananager 2025年 プロダクトエンジニアリング部 部長 5人目社員として入社 決済 / 入金 / eKYC等のシステム開発を担当 2018年 Fablic入社 → 楽天吸収合併 2014年 クオリカ入社

Slide 3

Slide 3 text

● Kaigi on Rails 2021 / 2022 / 2023 / 2025 ● YAPC::Hiroshima 2024 / YAPC::Fukuoka 2025 ● Builderscon 2024 ● アーキテクチャを突き詰める Online Conference 2024 ● Developers Summit 2026 ● EMConf JP 2026 カンファレンス登壇遍歴 これから偉そうなことを言うけど、適当に言っているんじゃないぞの説明 Ruby / Rails / EMのコミュニ ティに出没してます

Slide 4

Slide 4 text

● プロポーザルを出したいけど、ネタが見つからず困ってる人達 ● ネタはあるんだけど、これで出していいのか不安な人達 今日の話を届けたい人たち 考え方やスタンスの話とちょっとしたテクニックの紹介

Slide 5

Slide 5 text

プロポーザルに良し悪しはないので 臆せず、遠慮なく、自信を持って いっぱい出していこう 今日言いたいこと

Slide 6

Slide 6 text

● CfPがオープンしたので、何かネタを見つけて出したい ● どんなテーマなら採択されるか?とネタ探しを始める ● 通りそうなテーマがなかなか見つからない....😣 ● 何個もボツ案を作りながら、どうにか厳選した一つを提出する プロポーザルを出すのが苦手な頃の自分の思考

Slide 7

Slide 7 text

● 今回の業務をネタにできないかな? ○ この切り口なら、あのカンファレンスにハマりそう ○ 去年のあの人の発表に紐付けると厚みが生まれるかも? ● ネタ出しと切り口のアイデアを出すのに困らなくなった ● もちろん最終版に仕上げる時に時間はかかるけど 今の自分の思考

Slide 8

Slide 8 text

何が変わったのか 🤔

Slide 9

Slide 9 text

● 日頃から「これ外部発信できるかな?」と考えるようになった ● プロポーザルを出すことに躊躇したり臆することがなくなった ● プロポーザルへの期待値が変わり、アイデアが出やすくなった 思考の変化の裏側 何が変わったのか 🤔 経験を積むことでわかった 3つのNGを紹介

Slide 10

Slide 10 text

● 人のすごい成果ではなく仕事の参考になるもの が刺さる ○ 仕事の参考になる = 聞き手の仕事と近い内容が有利 ● 🙅「しっかり成果を残したらプロポーザルを出そう」 ● 🙆「このつまづきポイントみんなに伝えたいな」 ● ブログを書く感じ でプロポーザルは書いていい カンファレンスに登壇するのはすごい成果を出した人という思い込み 経験を積むことでわかった 3つのNG

Slide 11

Slide 11 text

● その話が面白いかは自分ではなく運営側が決める こと ○ 自分にとっての面白い ≠ 採択される ○ 落選したプロポーザルが別のカンファレンスで採択されることもある ● 自分で面白くないと判断するのはもったいない ● 求められるのは面白さを見極めることではなく伝えること ● 面白いかどうかは自己満足でいい この話は面白くないからこのカンファレンスには合わないな 経験を積むことでわかった 3つのNG

Slide 12

Slide 12 text

● 採択確率を上げるのはネタの良さではなく伝え方 ○ なぜこの話をカンファレンスですべきなのか? ○ この話をすることで参加者が持ち帰れる物はなんなのか? ● 伝え方というのは再現可能なテクニック ○ レシピみたいなものがある ○ 発表が上手い人、何度も登壇できる人は調理の仕方が身についている 思いの丈をありのままに伝える 経験を積むことでわかった 3つのNG

Slide 13

Slide 13 text

明日から使える 3つのテクニック

Slide 14

Slide 14 text

● 自分が業務で遭遇した問題をできるだけ赤裸々に紹介する ○ この仕様の時にこのテーブル設計にしました ○ 数億件のデータ変更をこの手順でやりました ○ N+1クエリをこうやって解決しました ● 具体的であるほど、同じ問題に遭遇してる人の為になる ● 業務は暗黙知の塊 。話を聞くだけで面白い 業務であったことを赤裸々に話す 明日から使える 3つのテクニック

Slide 15

Slide 15 text

● 言語やフレームワークの機能、アーキテクチャを解説する ○ Railsの画像アップロードの仕組みについて ○ パフォーマンスの計測方法について ○ 外部サービスと連携する際の実装パターン集 ● 業務情報を外部に出せない場合は、一般的な技術の話に置き換える ● みんな万能ではないので、意外と知らない人は多い ● そのカンファレンスでまだ取り上げられていないものを選ぶといい 技術解説 明日から使える 3つのテクニック

Slide 16

Slide 16 text

● 色々な手法を比較してベストプラクティスを探す ○ 2重リクエストの対策方法の比較 ○ 管理画面を作る時のアーキテクチャパターンの比較 ● 情報はまとめられているだけで意味がある ● 業務ではやっていなかったことを後から勉強するでも良い ● 上級者感が出る いろんな情報を取りまとめてベストプラクティス風にする 明日から使える 3つのテクニック

Slide 17

Slide 17 text

まとめ

Slide 18

Slide 18 text

● あなたが頑張ったこと・思い入れがあること・喋りたいなと思うことをネタと して選べばいい ● 普段の業務はネタの宝庫 。外で話せる話はどんどん出していこう ● 運営側が見ているのはネタの良し悪しではなく、参加者が持ち帰れるもの があるかどうか? ● ネタは何でもいいけど、伝え方にこだわろう ネタに大小も良し悪しも優劣もない 大切なことは伝える力

Slide 19

Slide 19 text

具体的なことを話した発表資料もあるのでぜひ見てね 大切なことは伝える力 https://speakerdeck.com/shoheimitani/well-begun-is-half-done

Slide 20

Slide 20 text

ご清聴ありがとうございました