はじめに

エンジニアがブログや登壇などを通して外部に知見を発信することは、企業の技術ブランディングだけでなく発信者本人の成長にもつながる重要な活動です。

しかしながら、Engineering Manager（以下、EM）やDevRel、DevHR等のエンジニア採用に関わる方々には「自社エンジニアがなかなか外部に技術発信してくれない」という悩みを持つ方も少なくありません。

私が先日参加した Kaigi on Rails 2025 感想戦*1 というエンジニアイベントでもまさにその声が聞こえてきました。

パネルディスカッションで @joy_P_joy さんが提起してくれた「この程度の内容じゃ登壇できない症候群をどう打破するか」というお題に対して、EMとしての自分のアンサーがあるので近々ブログ書きます（宣言）#after_kaigionrails

— なおぱー (@naopr) 2025年10月9日

エンジニアにやる気がないわけではなく、そこには3つの壁が存在します。

このエントリでは、EMとして私がこれまで行ってきた「エンジニアの外部への技術発信を自然に生み出す仕組みと支援のコツ」を紹介します。

• はじめに
• 外部への技術発信を阻害する3要因
  • 1. 発信することの価値がわからない
  • 2. 何を発信すればいいかわからない
  • 3. 一歩を踏み出せない
• おわりに

外部への技術発信を阻害する3要因

エンジニアが外部への技術発信をなかなかしてくれないとき、その原因は大きく3つあります。

1. 発信することの価値がわからない
2. 何を発信すればいいかわからない
3. 一歩を踏み出せない

これら3つの課題に対処すれば、発信をしてくれるエンジニアは確実に増えます。

次のセクションから個別に説明します。

1. 発信することの価値がわからない

外部への技術発信を阻害する課題を分類すると最も大きな分類はエンジニアのモチベーションの有無になりますが、そもそもモチベーションのないエンジニアにはどうサポートすればよいでしょうか。

このエントリの冒頭で説明したような技術発信の価値を伝えて納得してもらえればよいのですが、それほど簡単にはいかないことが多いです。

EMとしてこの課題に対して最初にやるべきことは、「エンジニアの評価項目に技術発信を組み込む」ことです。

エンジニアの技術発信が会社にとって利益があるのであれば、個人のモチベーションに頼るのでなく評価システムに組み込むことで技術発信を業務の一環として認識してもらうことが重要です。

例えば、メルカリさんが公開しているエンジニアの評価制度では、MG3グレードのContinued Learning項目に以下のような記載があります（太字は筆者によるもの）。

プロダクトの価値向上のために新たな分野を学習してチームに貢献している。知識や技術を他のメンバーに教えたり共有している。技術発信の重要性を意識し、社内外問わず有益な情報を発信している。

そしてもう1つ重要なのは、EM自身も外部発信することです*2。

メンバー向けには発信が大事と言っているのに、EM自身がそれをやっていなければ説得力がありません。 自身が外部発信することで得られた学びやフィードバックをメンバーに伝えることで、空虚な理想論ではなく熱量を持ったメッセージとして受け取ってもらえます。

2. 何を発信すればいいかわからない

外部への技術発信のモチベーションはあるものの、発信するネタがないと思っているエンジニアも多いです。

もしくは、ネタ候補はあるものの「この程度の内容では価値がないのでは…」と不安になってしまう声もよく聞きます。

技術発信に慣れていないエンジニアにとって、自身の業務で経験した内容が発信するネタになるかどうか判断するのは難しいです。

そのため、他のエンジニアやEMが「その経験（学び）を外部発信してみたら？」と本人に伝えてあげることをおすすめします。

私は現職で技術ブログのネタを貯めておくNotionデータベースを作り、誰でもSlack投稿に特定のスタンプをつけるだけでそのデータベースに自動的にアイテムが追加される仕組みを構築しました*3。

また、1on1の中で個別に「その成果ブログに書いてみたらどう？」と意識的に声がけするようにしています。

若手エンジニアにとって、業務で経験したことのどこまでが自社のドメインに閉じたトピックでどこからが汎用的なトピックなのか判断がつかないことがあるので、必要があれば私からざっくりと「アウトライン案」「想定読者」「コアな情報価値」の3つを伝えることで構成のイメージを持ってもらいます。

3. 一歩を踏み出せない

技術発信のモチベーションもネタ候補もあるエンジニアが、最後の一歩を踏み出せないでいる原因として「過度な完璧主義」と「炎上への不安」があります。

これらを緩和するためには「EMがエンジニアと伴走する」ことが大事です。

成果物を作成する過程をエンジニア1人に背負わせるのでなく、案出しや壁打ち、レビューや発表練習などを通じて一緒に内容をブラッシュアップしていくことでエンジニアが安心感を持って発信することができます。

私の取り組みの例として、新卒エンジニアに現場.sinsotsuというイベントに登壇してもらったときには、下記のアクションを通じて発表まで伴走しました。

• 発表ネタのブレインストーミング
• 発表までのスケジュール作成
• アウトラインのレビュー
• スライドのレビュー

また、レビューの際には発信することに対してエンジニアがネガティブな感情を抱かないよう下記のポイントに注意しています。

• ネガティブなフィードバックだけでなく、ポジティブなフィードバックを必ずつける
• 些末な言い回しの指摘を避け、本人が伝えたいことが正しく伝わるかどうかという一点に集中する
• レビューが遅いとマインドシェアを別のものにとられてしまうので、最速でフィードバックを返す

加えて、発信を後押しするような制度があるとよりよいです。

私の所属する会社では、エンジニアが査読付きのカンファレンスで登壇する際に参加費や交通費を会社が負担する制度があります。

私は来月KomeKaigiというカンファレンスに登壇するのですが、開催地の新潟までの往復の交通費を会社が負担してくれることでプロポーザルを出すモチベーションが上がりました。

おわりに

エンジニア組織や個人に外部アウトプットをする文化・習慣を定着させることは一朝一夕にはできません。

しかし、EMとしてアウトプットを行いたくなる制度・仕組みを作ったり日々の1on1でメンバーに働きかけることで、着実に発信文化は醸成されるものです。

あらためて、このエントリで伝えたかった3点を挙げておわりとします。

• 評価制度として発信の価値を明示する
• ネタ発掘とテーマ設計を支援する
• 発信への不安を伴走で越える