セッション概要
登壇資料
はじめに
先日2月13日〜2月14日で開催されたDevelopers Summit 2025へ登壇しました。私にとっては技術系カンファレンスにおける初めての登壇の機会となりました。
この記事では、登壇のきっかけから、テーマ決定、準備、登壇を通して感じたことなどをお伝えします。今後カンファレンスに登壇したいと思っている方の参考になれば幸いです。
登壇のきっかけ
会社として、カンファレンスに協賛する目的はいくつかありますが、弊社では下記のような目的で協賛しています。
- ◎ 会社として、技術に投資・貢献しているというブランディング目的
- ◎ 登壇機会の提供
- ○ 会社としての技術力アピール (いずれ◎にしていきたい)
- ○ (登壇者以外の)カンファレンス・技術交流への参加促進
- ○ 直接のエンジニアの採用機会
- △ 直接のプロダクトの紹介機会
そして、「やっぱりエンジニアカンファレンスといえば、デブサミでしょ！」となり、デブサミへの協賛を決めました。（部長が）
誰が登壇しようかという話になり、私に決まりました。
「しまてつ」は私の社内でのあだ名です。
決定の経緯はいくつかあったようですが、
- 世間的に耳目を集めやすいDevOpsという領域に携わっている
- 登壇という良い経験を積んでもらいたい
- 世の中に、「しまてつ」を自慢したい
といった感じでした。3点目は非常に光栄ですね。
また、デブサミで登壇するにあたって、下記のような観点もありました。
今回のデブサミのテーマの「ひろがるエンジニアリング」っていうテーマ的にも、やっぱ課題解決ってのは技術で解決するものだけじゃないっていうところでDevOpsの取り組みは良いなとも思ってたところがあります！
テーマ決定までのプロセス
登壇テーマを決めるにあたって、まず翔泳社の方と30分ほどディスカッションしました。最初に候補として挙がったのは以下の2つでした。
- ゼロからDevOpsを始めた話
- ゼロからテックブログを始めた話
この中で、他社も抱えているような共通の課題感をターゲットにできることから「0から1人で始めたDevOpsの取り組み」をテーマに決定しました。
登壇する以上、聞いてもらえるような内容にしたいですよね。今回のセッション会場のキャパが300人というのもあるので、それなりの人数に聞いてもらえるようなテーマにする必要があります。
テックブログやアウトプットを行う人は多いですが、テックブログの運営側の場合、聞いてもらえる人のパイは少なそうですよね。また「アウトプット奨励」みたいなテーマにするのも考えましたが、そういった発表や記事は多くあるので、埋もれやすいです。
DevOpsであれば、弊社特有の環境（小規模） で、1人でゼロから始めた事例とすることで、「大規模な事例に尻込みするような人にも共感を得られそう」という狙いがありました。
また、ディスカッションでは、CodeZine編集長の近藤佑子さん に同席していただきました。弊社の内情を知らない中で、短い時間で納得感のある着地となり、編集の力を感じました。あれは何て言えばいいのだろうか。洞察力なのだろうか。本当にすごかったです。
準備の進め方
スライド作成のプロセス
まずはプロットを作り、都度フィードバックをもらいながらスライドに落とし込んでいきました。スライドや発表の組み立て方については↓の記事が参考になるのでぜひ読んでみてください。
準備のポイント！
発表の組み立て方とかはいろんなブログや書籍があると思うので、そちらに譲るとして、私が感じた大事なところをお伝えします！！
権威づけをする
体験談や実践例の発表は参考になりますよね。書籍からだけでは学べない、実際の事例ならではの温度のある話が聞けます。ただ、自身の体験談ばかりだと「それってあなたの感想ですよね？」になってしまいます。そのため、自身の体験談と書籍や論文の引用をうまく織り交ぜながら発表することが重要です。今回私も、書籍やDORAの各種レポートを読み漁り発表に使える材料を探していきました。
たくさん準備する
当たり前のことですが、準備はやっぱり大事です。しっかり準備したけど、緊張してうまく話せない発表と、準備していなくてうまく話せない発表では、受け手の印象は大きく変わります。今回は発表練習を合計で10回ほど行いました。
発表練習をしすぎない
「おいおい、矛盾してるじゃん」と言われそうですが、ちゃんと理由があります。発表するのが嫌になるほど練習するのはやめた方がいい です。発表に新鮮味がなくなってしまいます。発表している人自身が楽しそうに話していると聴いている方も嬉しくなりますよね。
実際私も最後の2回くらいの発表練習は辛くなってしまいました。そのため、登壇当日の発表練習は1回きりにして、「あとは登壇を楽しもう！」 という気持ちで臨みました
登壇後のAsk the Speaker
デブサミでは登壇後に登壇者に質問ができる、Ask the Speakerというコーナーがあります。ここで何名かの方と登壇後にお話しできました。
新卒エンジニアの方からの質問が多かったのも印象的でした。新卒でこういった技術カンファレンスに参加していて素晴らしいなと感じました。（私は最近ようやく参加し始めたので）
正直「1人も話せなかったらどうしよう」と非常に不安だったので嬉しかったです！来てくださった方々ありがとうございました 🙏
これを読んでいるみなさん、ぜひカンファレンス中1回でもいいので、登壇した方に質問や感想を伝えにいってあげて欲しいです！「質問しなきゃ！」って思うと大変なので、ぜひ感想だけでも伝えてあげてください！
登壇して得たもの・今後の課題
得たもの
今回の登壇を通して、「正確性」と「わかりやすさ」のバランスを取る難しさを強く感じました。組織や施策の実態を詳細に話したい一方で、深く入りすぎるとどうしても話す内容が偏りすぎてしまいます。30分という時間制限の中で何を削って何を伝えるのか、かなり悩みながら取捨選択していきました。
特に社内での発表と異なる点として、聴きに来てくれる人がどんな人なのか予想がつかないことです。ふわっとしたイメージはありますが、完全に掴み切れるものではないので、丁寧に前提を揃えにいく必要があります。
例えば、このスライドでFourKeysの計測を1つに絞った話が出て来ます。
そこまで違和感はありませんが、「なぜリードタイムを選んだのか」 という疑問が浮かぶかもしれません。実は、リードタイムを選択したのには明確な理由があります。
下記のスライドを引用して、
キーメトリクスには計測難易度があります。ハイパフォーマンスな組織は全ての指標が高いという結果が出ています。逆に言えば、極論どれか1つだけを定点観測すれば十分では？ということで、スライドでは最も簡単な指標であるデプロイ頻度を計測しています。
しかし当時の弊社のリリース頻度は週1固定でした。これを変更するには開発以外の部署との調整も必要で、初手で取り組む改善としては難易度が高くなってしまいます。そこで、手軽に始められるように次点で計測しやすいリードタイムを測定対象としました。
という形で説明できます。しかしこのスライドはまだ序盤なので、ここの厚みを出しすぎてしまうと全体のバランスも悪くなりますし、尺の都合もあったので省略しました。聴き手にとってそこまでノイズになる部分ではなかったというのもあります。疑問に感じた人には質問しに来てもらうのがいいだろうとも思いました。
DevOpsで言えば、DORAやFourKeysといった単語、リリーストグルやWIP制限といったプラクティスは当然のものとして扱うのか、それとも概要くらいは説明すべきかは悩みました。
次回に向けた改善点
今回は「2日目の後ろから2番目」というほぼ最後の登壇だったため、緊張でほとんど他のセッションの内容が頭に入ってこなかったというのが正直なところです。次回登壇するなら、もう少し早い時間帯のセッションを選んで、イベント全体を楽しめるようにしたいと思いました。
これを読んでいるプレイヤーの方へ伝えたいこと
機会があればぜひ手を挙げましょう。これは登壇に限りません。私のキャリアに対する考え方は、計画的偶発性理論に起因しています。私はキャリアが偶然の出来事の積み重ねによって決定されると考えています。つまり運次第です。しかしその運を意図的に引き寄せることはできます。そのためには、やはり常にチャレンジしていくしかないと思っています。
今回の登壇も偶然の出来事です。たまたま、自分の入社した会社がデブサミに協賛して、たまたま、そのとき自分のやって来たことがそれなりの成果が出ていて、たまたま上長が自分を指名してくれたのです。
でも、日々新しいことにチャレンジし続けることで、DevOpsを始めて、信頼されて、「こいつならやってくれる」と思ってもらえたことで、今回登壇の機会を得られたのだと思っています。
たくさんチャレンジして、たくさん失敗しましょう！
まとめ
今回のデブサミ登壇は、初めての経験として非常に学びが多いものでした。準備やリハーサルの進め方、フィードバックの活用、当日の緊張感、そして登壇後の振り返りまで、すべてが今後につながる経験になったと感じています。
また機会があれば、次回はよりリラックスしてイベント自体も楽しめるような登壇をしてみたいと思います！
イベントページ
今回弊社展示ブースで、ノベルティのモデルを務めたちゃこまろさん
私の推しは躍動感溢れるこの写真です。
Discussion