エンジニアの執筆・登壇支援の取り組みの紹介

はじめに

DMMグループ Advent Calendar 2024の23日目の記事です。

プラットフォーム開発本部の いっぬ（@yuyu_hf）です。

本記事では、プラットフォーム開発本部やDMMで社外向けに開催しているGoのイベント「DMM.go」で試験的に導入している社内のエンジニア向けの執筆・登壇支援の取り組みについて紹介します。

本記事のGoal

以下の3点について紹介します。

• アウトプットの支援として何が必要か社内のエンジニアにヒアリングした結果
• 実際に用意したアウトプットの支援の仕組み
• 支援を受けた人からの反響

取り組みを始める前の課題感

社内のエンジニアの人数に対して仕事内容の社外へのアウトプット数が少ない

DMMには様々なプロダクトがあり、それぞれのプロダクトを開発するエンジニアチームが社内にあります。 例えば、プラットフォーム開発本部では50以上のマイクロサービスを持ち100人以上のエンジニアが所属しています。 厳密に比較したわけではありませんが他社と比較してもエンジニアの総数は少なくないです。

社内のエンジニアの総数と比べてエンジニアの仕事内容の社外へのアウトプットが少ないことに気づきました。 例えばDMM Advent Calendarでいえば1枚25枠を全て埋められない年が続いていたり、DMM主催の社外の勉強会イベントでは登壇希望者が少ないときもありました。

試しにDMMの開発組織と同程度の規模の他社のアウトプット数と比較したところDMMの2倍のアウトプット数があり、弊社は組織の規模に対してアウトプット数が少ないと感じました。

アウトプット内容とそれを見た人の期待値とのギャップを減らしたい

DMMのアウトプットの内容とそのアウトプットを見た人との期待値にギャップがあることを感じていました。 実際にDMM主催の勉強会で配布した参加者アンケートにも「期待していた内容と違った」という意見がありました。

実際に意見があった例でいうと弊社では外部向けにDMM.goというGoの勉強会を開催しています。 Goの勉強会なのでGoの話を聞きたい！と思って参加してくださる方が多いと思います。

DMM.goではDMMのプロダクトで利用しているGoの話を発表する登壇者の方が多いです。 発表するときに前提となるプロダクトについての話をしすぎてしまい発表でGoの話の割合が少なくなることもありました。 Goの話を聞きたいと思って参加してくれる人がほとんどなので結果として勉強会に参加していただいた方の満足度を下げてしまいました。

登壇経験が少ないと発表を見てくれる人の期待値にまで気を配ることは難しいと思うので何らかの仕組みで解決したいと思っていました。

アウトプットの炎上を防ぎたい

アウトプットが少ない理由として炎上することを恐れてアウトプットしたいけどできていない人が多いのでは、と予想していました。

弊社でのプチ炎上例でいうとプログラミング言語の良し悪しを比較した技術ブログがあります。

言語比較をするときに〇〇のほうが良いみたいな言い方をしてしまうと一方の言語にネガティブな意見を言うことになり、当然ですが普段その言語を好んで使っている人から批判が殺到します。 そのため、比較をするときには具体的な根拠を用意したり、コンテキストを明確にするなど、他者から見ても比較結果について納得してもらえる内容作りが必要です。

アウトプットに慣れていなかったりエンジニア界隈の雰囲気をよく知らない人だと 何をすると炎上するかわからないので結果としてアウトプットしないになるのかなと思いました。

課題を可視化するために各チームにヒアリングを実施

私の予想はあくまで予想なので、実際に社内のエンジニアにヒアリングをして実態を調査することにしました。

課題を可視化するためにプラットフォーム開発部内の13グループに登壇するときに問題になる点があるかについて以下の3つの観点でアンケートを取りました。

カテゴリー	想定回答例
リソースの問題	・プロジェクトが忙しくて発信に割く時間がない
技術的な障壁	・発信できそうな技術的なネタがない ・レガシーシステムの改善しているため、すでにノウハウが世の中にありそう ・新しい技術や概念を取り入れられていない
心理的な問題	・外部登壇となると緊張してしまうメンバーが多そう ・マサカリが飛んでくるのが怖い

リソースの問題

弊社では業務時間内に外部発表の資料の作成や発表練習をできます。

プロジェクトが忙しくて発信に割く時間がないなどチームのリソースの都合で外部発表の工数が割けず、外部発表したいけどリソースの都合でできない人がいるか調査しました。

ヒアリングしたところ緊急のプロジェクトが無いときであれば13グループ中 11グループで工数を割くことが可能と回答しました。

リソースの問題は無いと結論づけました。

技術的な障壁

プラットフォーム開発本部では古いプロダクトを開発していたり、そのプロダクトをリプレースしていることもあって業務内容的にアウトプットする内容があるか調査しました。

ヒアリングしたところ13グループ中 11グループが技術的障壁は無い、発表する内容はあると回答しました。

当初の予想どおり古いプロダクトを開発していることが原因でアウトプットしにくいという声がいくつか上がっていたり、 一部のグループでは業務内容的にDMMとして公開できない内容を扱っているため外部に公開しづらいというケースもありました。

技術的な障壁もほぼ無いと結論づけました。

心理的な問題

外部発表するハードルの高さや炎上するリスクを不安に感じてアウトプットに抵抗感があるか調査しました。

ヒアリングしたところ13グループ中 9グループが心理的な問題はある、と回答しました。具体的な問題を以下に抜粋して紹介します。

• 外部発表だと内容の作り込みのハードルが高いから社内勉強会でアウトプットの練習をしている
• 過去に技術ブログが炎上しているのを見かけてアウトプットが怖くなった
• 発表慣れしていないメンバーがいる

リソースの問題と技術的な障壁と比べると、心理的な問題を課題として抱えているチームが多いことに気づきました。

執筆・登壇支援

ヒアリング結果を元に支援チームで議論した結果、心理的な問題を解決することにしました。 アウトプットの怖さを減らすためにアウトプット内容を練るところからアウトプット資料を完成させるところまで支援チームのメンバーがサポートする「並走の仕組み」を用意しました。

「並走の仕組み」の仕組みについて具体的に説明します。

「並走の仕組み」の申し込み

「並走の仕組み」は以下のようなGoogle Formから申し込みを受け付けています。

工夫した点として、申し込みでは「支援を受けたい人」を指名できます。

DMMには各技術領域について詳しい人がいますが、レビューを希望する人と同じチームや事業部にいないこともあります。 「並走の仕組み」では申し込み時点でレビューを受けたい人を指名してもらい、レビューを希望する人に代わってレビューを受けたい人が所属するチームや事業部に交渉し、レビューをお願いできるか交渉します。

「並走の仕組み」の内容

外部登壇するときの「並走の仕組み」を例として説明します。

「並走の仕組み」では以下の3回のレビューを実施しています。

1. 初回面談（発表するアイデアの深掘り）
2. 中間レビュー（作成中のスライドのチェック）
3. 最終レビュー（完成したスライドのチェック）

初回面談（発表するアイデアの深掘り）

初回面談では事前に提出してもらったアイデアに対してレビュアーが質問しながら深掘りをします。

深掘りの観点は以下の2つです。

• 発表するアイデアがイベントの趣旨に合っていることを確認する
• 発表するアイデアに新規性やその人なりのオリジナリティがあるかを確認する

よくある深掘りはその人なりのオリジナリティがあるかどうかの確認です。

アイデアの段階では「XXXを使った」くらいの内容で他の人でも発表できそうな内容になっていることがあります。 実際に話を聞いてみると「XXXを使う必要があったプロダクト特有の事情」や「XXXを使ってみたその人なりの感想」など、 その人にしか説明できない内容が出てくるので「今話された内容を発表内容に入れてみるのどうですか？」と提案したりします。

中間レビュー（作成中のスライドのチェック）

中間レビューでは作成中のスライドの内容をチェックします。

レビューの観点は主に以下の4つです。

• 書いてある内容や技術的な単語の利用方法に誤りが無いこと
• 特定の技術への根拠の無いネガティブな意見など、炎上しそうな発言が無いこと
• 発表内容が登壇するイベントの趣旨と合っていること
• 発表内容を見たレビュアーが疑問に思ったことを質問して回答できること（マサカリを投げられそうであれば想定されるマサカリについても言及します）

例えば「発表内容を見たレビュアーが疑問に思ったことを質問して回答できること」ではレビュアーが作成中の発表スライドを見ながら質問をして回答できるかを確認します。

よくある質問例を以下にまとめました。

• 発表内容が「XXXを採用した話」ですが技術選定でXXXを採用した理由は何ですか？
• XXXを採用するときに別の採用候補はありましたか？　もし比較をしていたら比較検討結果も教えてください。
• 実際に使ってみてどうでしたか？　良かったところや悪かったところがあれば教えてください。
• 今あらためて技術選定するとしたら何を使いますか？　その理由も教えてください。

質問に対してすぐに回答できれば問題ないです。「今話してもらった回答をスライドに載せるのどうですか？」と提案したりします。 すぐに回答できなければレビュー後にあらためて考えてもらったり、業務内容であれば所属しているチームに持ち帰ってチームメンバーに確認してもらいます。

最終レビュー（完成したスライドのチェック）

最終レビューでは発表内容に言及することはほぼなく、スライドのデザインや発表時間についてレビューをすることが多いです。

実際にレビューした内容をいくつか載せます。

• P10のスライドに貼ってあるコードのスクショが小さいです。登壇する会場でスライドを映したときに文字が小さくて読めないのでスクショのサイズを大きくしましょう。
• 発表するときの台本に「インフラをTerraformで管理してGitHubからterraform apply...」と書いてありますが、読み上げるときのスライドのインフラのアーキテクチャ図にGitHubのアイコンが無いです。口頭だけで言及したものをその場で理解することは難しいのでアーキテクチャ図にGitHubのアイコンを追加するのはどうですか？
• 発表時間をオーバーしそうで削れる内容も無いなら自己紹介スライドや会社紹介スライドを減らすのはどうですか？

「並走の仕組み」の結果

「並走の仕組み」ではDMM主催の外部向け勉強会への登壇 11件、カンファレンスでの外部登壇 3件の登壇をサポートしました。

例えば、「並走の仕組み」で支援した1人の24新卒のエンジニアの方は2024年11月に開催されたCloudNative Days Winter 2024のLTセッションでDMMのプロダクトのインフラをIaC化した話について登壇しました。

実際に「並走の仕組み」を利用した人の感想

実際に「並走の仕組み」を利用した人からの評価を紹介します。

「並走の仕組み」を受けた人からの評価

「並走の仕組み」を利用した14人中 14人が発表内容のクオリティが上がった、また支援を受けたい、と回答しました。

「並走の仕組み」の良かったところ

「並走の仕組み」の良かったところで実際にいただいた意見をいくつか抜粋して紹介します。

• チーム外の人との壁打ちの機会が大変良かった。チーム内での壁打ちも効果はあるが、ある程度前提知識を持っている人のみなのでわかりにくいところに気付きにくいです。このような機会はぜひ設けていただきたい。
• 発表資料の中間レビューで「ここの話は面白いと思う」という指摘をもらえたのがよかったです。 自分で作っていると面白いのかわからなくなっていくので、普段goを触っている人や登壇経験者からのフォローはとても参考になります。
• 壁打ちでスライド情報の取捨選択が明確にできた。発表のノイズになる情報は削減して、参加者が興味を持つ部分を厚くできたと思う。また他発表者とバッティングする内容は表現を変えて、お互いの良さを打ち消さないようにできたと思う。

「並走の仕組み」の良かったところの意見で多かったのは、支援対象者や所属するチーム内に無い意見をもらえたことです。

支援している中で、支援対象者から説明された発表内容を技術的に深掘って聞いてみると、最初に説明された内容より技術的に工夫された点が多く見つかりました。 おそらく支援対象者や所属するチームでは当たり前のことかもしれませんが、レビュアーのように初めて聞く人にとっては面白い内容で 「今話してもらった内容すごい面白いと思うんですけど、発表内容に入れないんですか？」と指摘することがたびたびありました。

「並走の仕組み」の改善点

「並走の仕組み」の改善点で実際にいただいた意見をいくつか抜粋して紹介します。

• 自分の話したい内容が相手の聞きたい内容とは限らない、あるいは業務上で得た知識の中で発表に使えそうな内容は他にもあったかもしれない、と思うと、発表内容を決める時に最近の業務内容の洗い出しとかから始めるのはアリかもしれません。
• 今回はLTでも時間オーバーが多かったので時間を意識できる支援はあるとよいかもしれない。

「並走の仕組み」の改善点の意見で多かったのは、発表内容のアイデア出しからの支援の希望です。

今まで実施した支援では支援対象者にアイデアを持ってきてもらって、その内容について技術的なレビューを実施していました。

支援する中で支援対象者のアイデアが発表時間に対して内容が多く、発表時間を考慮してやむ無く内容を削ることがよくありました。 内容を削ってしまったために本来話したかった内容を全て伝えられなかったという意見もあったので、 支援対象者に複数アイデアを持ってきてもらって登壇時間を考慮したアイデアの選定のサポートができれば良かったと思っています。

支援後のアンケート結果の一部を紹介

おわりに

本記事ではDMM社内で試験的に実施している執筆・登壇支援について紹介させていただきました。

現在社内の14人のエンジニアの方々に利用していただいております。 目標として100人のエンジニアの執筆・登壇支援ができるように活動を続けていきます。 支援の内容は引き続きアップデートし、その結果も社外に公開していくので続報をぜひお待ちください。