テックブログ、登壇、イベント…会社で技術広報を継続して行うためのガイドライン
※こちらの記事はZeals Advent Calendarの記事となります。面白そうなので参加してみる
みなさんこんにちは。
チャットボット開発のスタートアップ…から最近転職した福本です。
転職してからブログをサボっていたのですが（すいません）、新しい職場にも徐々に慣れてきたので、ブログに限らず今後もアウトプットを続けていればと思っております。
さて、今回はタイトルにもある通り「技術広報」についてです。
前職であるZealsではそれなりに技術広報活動に打ち込み、テックブログをほぼ毎週の頻度で更新したり、情報を発信していく文化をそれなりに作ることができたと自負しております。
活動結果の一例として、例のテックブログランキング の記事では運営約1年で46位に食い込んだりもしました。今Zealsのテックブログはだいたい月5,000PVほどみたいです。
最初のなにもない状態からこの状態を作り上げるのは本当に大変だったのですが、工夫したことや取り組みについて語る機会が無くなりそうなので、この場で共有できればと思います。
企業における技術的な情報発信の取り組みは、まだ世の中にベストプラクティスが存在しないですし、何らかの形で読んで頂いた者方のお役に立てれば幸いです。
TL; DR
- 企業にとってエンジニアからのプレゼンスを向上させることは急務
- 論理と感情の両面から継続させる仕組みを作ろう（ナッジ）
- 仕事一般では当たり前なことが逆効果になることもある
- 情報発信も立派な開発者コミュニティへの還元
- おまけに参考にした記事とか本がいっぱいあるよ
（※TL;DRはあまりポジティブには捉えられない表現だそうで注意）
なぜ今、企業が技術情報を発信すべきなのか
さて、具体的な話に入る前に、なぜ技術広報などという面倒くさいことに取り組む必要があるのかについてご説明します。
背景
技術広報のメリットをお伝えする前に、現在の開発者市場に関する前提を揃えておきましょう。
エンジニア採用のコスト増加
改まって言うことではありませんが、エンジニア採用のコストは日に日に高まっています。事実として”有効求人倍率”が7~8倍という話もありますが、これは質を無視したインデックスであり「良いエンジニアに来てほしい」と、何らかのボーダーを設ける企業にとっては、肌で感じる採用の難易度はこの限りではないでしょう。
また、忘れられてしまいがちですが、採用コストが増加すると「エンジニアに去られてしまうコスト」も無視できなくなります。Web系の企業だと勤続年数2~3年前後が平均のようですが、一人あたりの採用コストが数百万円~ということを考慮すると、少しでも長く活躍してもらえる環境を作る必要があります。
なので、頑張って新しいエンジニアを獲得するのももちろん大事ですが、それ以上に、自社のエンジニアメンバーにもっと目を向け、市場価値を向上させられる環境を整備することも重要です。
時間の限られた採用選考の場と違って、コミュニケーションを取れる頻度は自社メンバーの方が高いはずですしね（そういう意味では、恒常的にエンジニアの抜けていることは組織の状態が良くないバロメーターと言えるかも知れません）。
開発者向けのマーケティングコスト増加
現代のWeb開発における開発者体験の向上速度は、過去のそれとは比べ物になりません。クラウドやコンテナにCIなんてもはや当たり前 of 当たり前で、NewRelicやDatadogなどの外形監視、FirebaseやAmplifyなどのmBaas（←この言い方するヤツいんのかな…??）など、2~3年前にはあまり名前を聞かなかったツールが次々に登場し界隈を賑わせています。
これは僕個人の解釈ですが、開発者市場におけるツールの流行り廃りの独特な速度は、エンジニア特有の情報収集方法に起因しているのではないかと考えています。具体的に言うと「push型ではなくpull型で情報を集める」という点です。
先程のサービスもそうですが、開発者向けサービスの多くは、Webサイトにサービスの説明やプランごとの金額、そして導入方法のドキュメントなどが詳細に書かれていて、自分たちで情報をキャッチアップしてツール選定→見積→構築を進められるものが多いです。
一方、マーケティングツールや採用媒体などを見てみると、Webサイトに掲載された情報は”機能概要”と”価格例”などに留まっており、基本的には「問い合わせ→アポで商品説明して見積」というpush型のやり方を踏襲せざるを得ません（偏見）。
つまり、開発者向けツールに関しては、直接的なプロモーションを仕掛けて流行らせることが非常に難しい、ということが言えるのではないかと思います。これらを踏まえると、開発者に対してのマーケティングは非常に難易度が高いですし、ここにマーケティングを行う人材の確保を考慮すれば、今後も非常に厳しい状況が続くことが予測されます。
企業が技術広報に取り組むメリット
ある程度現状について整理したところで、とりあえず思いつくメリットをそれっぽく並べてみました。気をつけたいのは、どれもこれもかなり長期的な取り組みになるということです（詳しくは後述）。
エンジニア採用のコスト削減
- 母集団形成：採用チャネル増加、認知向上による面談機会の創出etc…
- ミスマッチ減少：自社の技術スタックやレベル、文化への理解向上
- メンバーのキャリア形成：情報発信を通じてのメンバーの市場価値上昇
自社サービスやAPIの利用促進（※開発者向け事業の場合）
- 認知向上：チャネル増加、事例の創造、商談機会の創出
- 市場の獲得：開発者から先導で市場へ参入（例：Slack）
工夫したこと
さて、ここからが本編です。
実際に僕が技術広報を担当していたときは「最初は自分が積極的にアウトプットを出して、感覚が掴めてきたら社内のメンバーに依頼する」という形式を取っていました。
とはいえ、しっかりと品質を担保しつつ人に動いてもらうというのは非常に難しいので、その中で工夫したことを振り返ってみます。
チケットを切ってメンバーに依頼する
技術広報に関するタスクを依頼する際は、開発タスクと同じようにしっかりとチケットを切ってアサインする方法が良いでしょう。
なぜなら、担当エンジニアの工数確保もありますが、それ以上に、彼らに言い訳を与えてあげる必要があるためです。
エンジニアの主業務はあくまで開発です。
その主業務たる開発タスクですら遅延することがありますから、「今週は登壇スライドを作らないと」とチームに言わせてあげられる環境を作らなければ、技術広報に協力することはメンバーにとって、ただただ”損”になってしまいます。
チケットを作るのは面倒くさいですが、一度作ってしまえば使い回しができます。また、「想定するターゲット層」などの項目の設定や「進め方」の子タスク化をすることで、アウトプットの質や進め方を一定担保することも可能です。
実際に用いていたチケットのサンプル（テックブログ用）がありますので、よろしければご活用ください。
別の業務上インセンティブを組み込む
少し難しい表現ですが、「技術広報以外のメリット」を技術広報タスクに盛り込んであげると、スムーズにコトが進みます。
例えば、以下のサービスアーキテクチャ図の記事は、複雑になりつつあるアーキテクチャを、社内のオンボーディング資料や採用面談時のスライドに活用することを目的として執筆を開始しました。
これについては、行動経済学における”時間割引”の概念で完全に説明できます。未来は不確実性に満ちているので、ヒトは将来得られる報酬を現在得られる報酬より低く見積もるのです。
技術広報のメリットを感じるのは気の長い話なので、経営陣に技術広報への投資を説明したり、メンバーにメリットを理解し行動してもらうのは非常に難しいです。
長期的なメリットの訴求も重要ですが、目の前のメリットにすり替えて紐付けたほうが手っ取り早く話が進んだります。すり替える先は、採用/教育やオンボーディングなどがオススメです。
発信をメンバー個人の資産にする
こちらも先ほどの項目と近い概念なのですが、ブログや登壇スライドは個人の資産として還元できるようにしましょう。
例えば、ブログ記事内では執筆したメンバーの名前を明記してGithubやTwitterのアカウントをリンクしてあげたり、登壇資料を個人のSpeakerDeckやSlideShareのアカウントにアップロードしてもらうようにする、といったことが挙げられます。
企業におけるプロダクト開発は事業の成長のために行われますが、それと同時に、エンジニアにとっても日々の開発の中で技術力を上げ、市場価値を高める機会となります。
技術広報においても同じようなエコシステムを形成することで、協力してくれるエンジニアの方とWinWinの関係を築く事ができます。
”貢献感”を演出する
テックブログの公開や登壇の資料/写真は、全力でスタンプ・コメント・シェアで歓迎して、”会社やチームに貢献した感”を演出しましょう。
協力してくれたエンジニアが心理的に「貢献して良かった」「楽しかった」と感じることも、引き続き協力してもらえる要因になります。
特にブログや登壇を始めたばかりのときは、PVは月間二桁の状態はザラです。誰も見てくれないものを作り続けるのは、精神がゴリゴリ削られてツラいので、せめて社内では厚く祝福してあげましょう。
このように、明確なインセンティブを用意せずに経済主体の行動を誘導することを”ナッジ”といいます。本来であれば、技術広報への貢献もしっかりと可視化して、評価制度に反映するのが理想ですが、なかなか環境がそこまで整備されていない企業も多いと思いますので、その場合は工夫してカバーしましょう。
責任者を立てる
これは仕事全般に共通しますが、誰が責任を持って技術広報を進めるのかを決めましょう。技術広報には、継続と細かな改善が必要なものが多く、責任の所在を曖昧にすると宙に浮いてしまいがちです。
投資を理解させる必要があるため、CTOやVPoEなどの経営陣に近い立場のメンバーが責任を持つのが一番ベストですが、それが難しい場合は社内で別のエンジニアにお願いしましょう。
また、大人スタートアップではよくある話ですが、CTOやリードエンジニアの方が既に業界で高い業影響力を持っている場合は、自社で無理に内製化せずに相乗りしてしまうのも手です（ただし属人化します）。
アンチパターン
ここからは、始めたばかりのときにハマりがちな落とし穴やあるあるなミス、あるいは「やりがちだけど一考の余地あり」なものを挙げていきます。
担当を当番制にして回す
ブログ記事や登壇を当番制にして、とりあえず公平にメンバーで順番に回していくというやり方です。これは始めたての時によくあるやり方ですね。
これには２つの罠があって、まず「①発信すること自体が目的になり、イマイチな状態でアウトプットする可能性が高まる」という点です
ネタには鮮度がありますから、アウトプットするタイミングを固定してしまうのはよくありません。どうしても持ち回りにしないといけない事情があるのであれば、メンバー間でスケジュールを調整できる仕組みを作りましょう。
そして、もうひとつ「②エンジニアの状態は常に公平ではない」ということです。少し難しい表現ですが、これはいわゆる”公平と公正の違い”で完全に説明できます。
エンジニアによって、能力や好み、あるいはアサインされている開発タスクの数や難易度は異なります。その中で思考停止して「技術広報の依頼を均等に割り当てる」のは、「開発タスクを上から順番に均等にアサインする」ようなものです。
責任者は各エンジニアのタスク感や指向性、今後の見据えているキャリアなどをある程度把握して、適切に割り振って上げる必要があります（その代わり、コードを書くことも情報発信を行うことも両方評価してあげましょう）。
ただし、あまりこの点を考慮しすぎると依頼が偏重してしまう可能性があります。細かく個人単位で指名する方法にしたり、チーム単位でアサインして調節機能はチーム内で持たせるなど、ある程度コントロールできる工夫が必要です。
既に開発組織のレベルが高く、「これ知見なんでテックブログで記事書きます」というような声がエンジニアから勝手に出てくると理想ですが、そうでない場合は、このような工夫をしていく必要があるでしょう。
発信内容の過度なマイクロマネジメント
エンジニアが出してくれたアウトプットに対して、ひたすら「てにをは」レベルのレビューをつらつらと並べ立てるのは、個人的にはあまり良くないと考えています。
（※イメージ）
「〜ということで○○します」←ここに読点を入れる
「だ。」←ですます調に統一する
…etc（あと10個くらいSlackに並ぶ）
なぜかというと、「ヒトの脳みそはポジティブな反応よりネガティブな反応の方を大きく捉えてしまう」ため、エンジニアが「次も頑張ってアウトプットしよう」と思えなくなってしまうと感じるからです。
これについては、行動経済学で言うところの”プロスペクト理論”と”損失回避バイアス”でほぼ説明できると考えています。
すごく雑に説明すると、「ヒトは利得よりも損失の方を大きく評価してしまい、損失を積極的に避けて動くようにできている」という話です。
技術広報に話を戻しましょう。仮に「てにをは」レベルの細かい指摘がたくさんあっても、本来はアウトプットを出してくれたことの方が圧倒的に良いことなはずです。
（※本来脳が受けるべき刺激量）
アウトプットしてくれたこと＞＞＞＞＞＞（越えられない壁）＞＞＞＞＞＞指摘をうけたこと
しかし、細かい指摘をたくさん受けるとこの構造が逆転してしまい、「指摘をたくさん受けた、自分をアウトプットは良くなかったのか」と感じてしまいます。
（※実際に脳が受けった刺激量）
指摘をうけたこと＞＞アウトプットしてくれたこと
また、レビュワーが細かい指摘に終止するのは”自転車置き場の議論”で時間の無駄です。時間を使うなら、それにふさわしい大きなテーマに使いましょう。
ただし勘違いしないでいただきたいのは、この話に「言葉狩り」や「指摘をするな」といった、安い気遣いの意図はありません。
さも当然のように期日を忘れたり、外部に出すに値しないドラフトを上げるといったことを何度も繰り返す場合は、「それは良くないですよ」としっかりと伝えてあげる必要があります。
明確なKPIを追う
これは諸説あるでしょう。僕が技術広報をはじめたときは、KPIを明確には追いませんでした。
ちなみに、ここで言うKPIとは「PV数」や「シェア数」などの数値を指しています。このような中間的な指標を置いたほうが、改善や仮説検証を回していけるイメージがあるでしょう。
KPIを置かなかった理由としては、「エンジニア市場を鑑みた時に、KPIを追うと本末転倒な結果になる」と考えたからです。
もう少し踏み込んで説明します。前提として、経験年数やスキルなどの質（少し強引な表現）が高いエンジニアの方達と、そうでない未経験者や入門者の方達（もちろんダメという意味ではない）の数を比較すると、後者のほうが圧倒的に多いのではないか、という感覚がありました。
参考になりそうな資料が見当たらなかった（ご存知の方居れば教えてください）のでなんとも言えないのですが、Googleでプログラミング関連の検索をすると上位にプログラミングスクールの記事が出てくることが多いのは、そういった一面もあるのかなと考えています（同じくスクールをdisる意図はない）。
（※ただし、僕の利用可能性バイアスである可能性もあります）
そのような状態で、「PV数」や「シェア数」などの絶対数の大きさを追う指標を置けば、「経験の浅い方向けのアウトプットをたくさん行う」ことが正義となり、多くの企業で技術広報の目的である「レベルの高いエンジニアの採用」や「自社APIの先進的な活用」を達成することが難しくなります。
しかし、これは企業のフェーズや技術広報の目的によって異なるため、この考えが一概に正しいわけではありません。ポテンシャル層の採用を強化したい企業もあれば、高い質のアウトプットがある程度確約されていて、このような心配は無用な企業もあるでしょう。
「どんなエンジニアに、自社の存在をどう認知してほしいか」を常に考えることが重要です。
「ネタがない」を理由にしない
前提として、せっかく始めたアウトプットを途中で放り出すというのは、逆効果となってしまうため非常によくありません。これは、メドピアで技術顧問をしていただいているwillnetさんがブログで端的に答えてくれています。
ブログを継続して書き続ける文化がないと逆効果です。例えば最終更新日が1年以上前のテックブログだと「あーこの会社はブログエントリを継続する暇もないくらい忙しいんだな」と判断される可能性があります。
なので頑張って継続していこうねという話ですが、「ネタがなくて…」という声を多く聞きます。気持ちはとてもわかります。
しかし、実は開発業務を行っていれば、なんでもない作業も価値になり得ます。これは決して精神論を説きたいわけではありません。
大元のネタは「rails g migrateしたので備忘録書いた」とか「bundle installしたらmysql2でコケたから作業ログを出す」とか、そういう簡単なもので全然構わないわけです。これくらいの作業は日常的に行われると思います。
「いやお前、さっき経験の浅い人向けのアウトプットがどうとか言っただろ、数行で矛盾してやがる」と言う声が聞こえそうです。
しかし、腕の見せどころはここからです。モノには”切り口”という概念があります。
例えば、「rails g migrateした後、Rails内部ではどんな処理が行われるか調べてみた」とか「bundle installでmysql2でコケた理由をケース別に徹底的に調べた」なんて話に膨らませてみても面白いでしょう。社内で簡単なアンケートを取ったりして、独自性を出してみても良いです。
開発者体験が日々向上する裏で、ツールやフレームワークが一体何をしているのか知る機会は意外に多くありません。色々な視点を持つことで、工夫して良いアウトプットをすることはいくらでもできます。
さいごに
さて、本編は以上です。
最後までお付き合いいただき、ありがとうございました。
なぜこんなに長い文章を書いてしまったのかというと、技術広報に力をいれる企業が増えることは、開発者市場の盛り上がりに繋がると考えているためです。
普段何かの問題にぶつかって、GoogleやTwitterなどのインターネットの海にひたすら検索クエリを投げ込むエンジニアは非常に多いでしょう。もちろん僕もその一人なのですが、検索結果にでてくる記事や資料の（ほぼ）すべてが、この世の誰かが書いたものだと考えると非常に感慨深いものがあります。
ラリー・ペイジとセルゲイ・ブリン、人類史上最高の辞書をありがとう
こうやって欲しい情報にたどり着ける現状が当たり前じゃないよなと思いつつも、そこに自分も貢献できることに僕はすごくワクワクします。ちょうどOSSのコミットに近い感覚でしょうか。
この記事を読んで、情報発信することに少しでも前向きになった企業やエンジニアの方が少しでもいらっしゃれば幸いです。
ここで私の黄金律を紹介しよう。
一つ目は「自分がして欲しいことを人にもしてあげよう」
二つ目は「自分のすることに誇りを持て」
三つ目は、「そして、楽しめ」-『Just for fun』 Linus Torvalds
そして、最近お会いしていない方＆まだお会いしたことがない方も、割とフッ軽なので気軽にご連絡ください。エンジニアリングに関わるお悩みなど、ぜひお話しましょう。
おまけ
参考にした記事
技術広報の仕事論系
登壇系
ブログ系
コミュニティ系
参考にした本
仕事論系（広報・採用・エンジニアのキャリア）
資料・文章作成系
