以下の内容はhttps://nealle-dev.hatenablog.com/entry/2025/04/30/152806より取得しました。


テックブログ開設からの1年を振り返る 〜アドカレ、評価、そして妖怪テックブログ〜

プラットフォーム開発Gの菊地(@_tinoji)です。

ニーリーのテックブログを始めて1年が経ったので、振り返りをまとめておこうと思います。

なぜテックブログを始めたのかについては、最初に投稿した記事に書いてあるのでそちらをお読みいただけると。

こういう振り返り記事は、これからテックブログを開設しようとしている人などを想定して「こういう良いことがあるからやろうよ!」という示唆に富んだものが多いと思うのですが、なんかうまく書けなかったのでやめました()。運営した人間が思いつくまま書いた随筆としてお楽しみください。

定量面振り返り

総投稿数は54でした。1年=約52週として、「毎週投稿しつづけました!」と言いたいところですが、めちゃくちゃばらつきがあります。
もちろんアドカレによるものですね。アドカレについては次のセクションで触れます。

月別投稿数

総PVは約6万でした。1記事あたり1,000PV超えで、企業のテックブログとしてはかなり読まれているのでは!? (と思っていたのですが、Findyさんの振り返りを見てみたら3倍以上のPV数で驚愕しましたw)

特に汎用的なノウハウ記事には投稿から期間が経っても継続してアクセスがあり、「誰かの役に立っていそう!」という実感があります。素敵です。

総はてなブックマーク数は2401でした。 1記事あたり平均で約44。バズるかどうかはほとんど意識していませんが、やはり人気エントリー等に入るとものすごくPVが伸びますし、社内で盛り上がって良いですね!

初めてのアドベントカレンダー

1年目の大きなイベントといえばやはりアドベントカレンダーで、運営していた自分は12月はほとんどアドベントカレンダーをやっていた記憶しかありません。
正直10月あたりまであまりやる気持ちはなかったのですが、ブログ開設2ヶ月で毎週投稿が途切れてしまい、9月10月には月に1本だけという状況が続いたので実施に踏み切りました。

結果としては29記事を投稿でき、初めてのアドカレにしては上々だったのではないでしょうか。期末の忙しい時期に書いてくれた皆さんに感謝です。

qiita.com

メンバーのアイデアで土日は投稿しないことに。レビューする側としても助かりました。

アドベントカレンダーに対して自分が懸念していたのは「同じ日に大量の記事が投稿されるから、食い合ってあまり読んでもらえないのでは?」という点ですが、これは杞憂でした。逆にアドベントカレンダー期間は明らかにアクセスが多く、はてなブックマークも多くなる傾向にありました。やはりお祭りなんですね。

テックブログ運営側の観点としてアドベントカレンダーが良いのは、当たり前ですが「この日に書く!」というコミットメントがある点ですね。平時では「このネタいいと思うのでブログ書きませんか?」→「手が空いたら書きますね!」ぐらいのコミュニケーションに留まるので、運営側は待つしかありません。そして「手が空く」という現象はなかなか起きませんw カレンダー上に誰が何を書くのかが埋まっているのは、なんというか、心理的にとても安心でした。

テックブログ(を含む外部発信活動)と評価

ブログや登壇といった活動のインセンティブ設計をどうするのか、というよく議論される命題があります。よくあるのは、直接的に個人の目標・ミッションには含めず、会社のValuesなどに紐づく行動評価の中で(ある意味加点要素的に)扱うというものでしょうか。各社様々な工夫をされていると思います。

ニーリーの場合、半期ごとにミッションを設定してその評価で査定が行われるのですが、テックブログなどの外部発信活動を明確にミッションとして定義しています。当然ではありますが以下のような意図です。

  • 個人ミッションに定義するほど、会社にとって重要な課題であると認識してもらう。
  • 明確に業務として扱い、他のタスクよりも優先度が低くなりすぎることを防ぐ。
  • 力を入れれば加点評価されるという構造にし、モチベーションに繋げる。

評価の方法ですが、活動種別によるポイント制を基本にしています。ざっくり言うと、テックブログ = 1pt、外部登壇 = 3pt のように概ね労力に連動するような形です。もちろん同じ登壇と言ってもLTと40分セッションでは全然違うので、そこは評価者と相談のうえ変動可能にしています*1

さて、この評価制度がうまくいっているかについてですが、少なくとも継続的な発信が行われているという点では一定ワークしていると言えるでしょう。最近自分が難しいと思うのは、「ネタの生まれやすさ」がチームや役割によってかなりの差があることです。

カテゴリ別の投稿数を見ていただければ分かるように、SREが突出して多く、これは弊社においてSREが比較的ネタの生まれやすい領域だからです。AWS上でインフラを構成すると大抵ちょっとぐらいはハマるので共有したくなるtipsが生まれますし、監視ツール・CI/CDといった要素も汎用的な知見が得られることが多いです。必然的に発信しやすい領域にいるメンバーは、ポジティブに活動しやすい傾向にあるでしょう。

一方で、(本来もっともコアな領域であるはずの)アプリケーションの機能開発領域は、もちろんそれぞれの案件で様々な面白さがあるものの、「汎用的な知見」まで見出すことができるケースは多くはありません。また、そもそも利用者の限られたtoBのアプリケーションもあるので、あまり何でもかんでもオープンにしたいわけでもありません。この領域にいるメンバーは、「発信はしたいけどネタが、、、」という苦しい状況になりがちなのは間違いありません*2

最近はQAやデータ基盤なども増えてきました。

この辺の絶妙なアンフェアさには僕自身まだ解を出せてはいないのですが、最近少しずつプロダクトエンジニアリング系などで「このテーマならあの人が話せそう!」というイベントのキャッチアップが進んでおり、登壇ネタの方でカバーが進んでいくのかなと予想しています*3。そして、そういったサポートをしていくことが、ミッションを設定させてもらった側の責務とも言えそうです。

「妖怪テックブログ」の必要性

テックブログを含む発信活動に力を入れていることを、嬉しいことに外部の方が知ってくれていることも増えてきて、「継続のコツはなんですか?」と聞かれることがたまにあります(こんなこと聞かれるなんて1年前には夢にも思いませんでした)。

そのときは「妖怪テックブログの存在ですね」と答えています。妖怪テックブログとは、目が合うと「テックブログ書きませんか?」「今度こういうイベントがあるので登壇しませんか?」と必ず言ってくるヤバい人のことです。僕です。外部発信が盛んに行われている会社には必ず1人くらいいるんじゃないでしょうか?

立ち上げ期にはそういった存在が絶対必要です。会社のフェーズにもよるのかもしれませんが、「テックブログ開設したから、後はみんなで好きに書いてね〜」で進むことは基本ありません。甘い考えは捨てて妖怪テックブログをアサインしてください。「でも、その人がいなくなったら止まっちゃうじゃん」という一見それらしい視点も捨ててください。妖怪テックブログを生み出すことだけに集中してください。

選出のポイントは妖怪性です。例えばあなたがCTOだとして、その人をアサインした数ヶ月後に「あいつと目が合うとテックブログ書けって言われるから怖い。ワイCTOなのに、、、」というイメージが湧くかを重視してください。

Geminiに描いてもらった「妖怪テックブログ」の絵。ここまでの妖怪性は不要です。

テックブログによって何が変わったのか

因果関係については推測の域を出ませんが、テックブログを含む発信活動が盛んな領域のポジションほど、採用媒体における返信率が高いという傾向があります。ポジションによってなんと倍以上違うこともあります。

繰り返しですが因果関係は分からず、たまたまそのポジションで転職顕在層が多かったのかもしれません。ただ、スカウト時に添えられるコンテンツの選択肢が多いのは武器になっていますし、スカウトを受けて会社を調べたときに自分のポジションに関係する技術発信が多いのは明らかなポジティブ要素です。

自分が採用も担当しているので生々しい返信率の話を出してしまいましたが、何にせよ「ニーリーの開発組織の透明性が上がった」ことは間違いなく、これはこのブログを始めたときに目指していたことです。1年でここまで実感できるとは思っていなかったので、日々発信を続けてくれた皆さんに改めて圧倒的感謝ですm

おわりに

ニーリーの外部発信のすごいと思うところは、発信されたコンテンツからちゃんとカルチャーが滲み出ていることです。これがどういうことかと言うと、発信を目にして「いいな」と思ってくれた方は、ニーリーのカルチャーに合う可能性が高いということです。

テックブログだけでなく、公式note登壇スライドを見て、少しでもシンパシーを感じた方はぜひカジュアル面談にお越しください。

jobs.nealle.com

サボっていてまだ求人票が無いのですが、妖怪テックブログもといTechPRな方や、採用・組織開発を行うDevHRな方もめちゃくちゃ欲しています。どちらも1人目ポジションです!ぜひ一緒にやりましょう!


*1:この変動幅に基準を設けることは難しい(例えば参加者がXX人以上なら〜というような基準が必ずしもフェアとは言えない)ので、あえてラフにしています。前例が溜まっていくことで判断がしやすくなっていくという前提で割り切っています。

*2:なのでポジションによってミッションのウェイトに差をつけたり、もちろん個人レベルで他に集中してほしいことがあるときは入れなかったりと、柔軟に対応しています。

*3:あとは技術寄りすぎない比較的ラフな内容も増やしていきたいところです。「テックブログ」と呼称していますが、Nealle Developer's Blogという名前にしたのは、テックじゃない内容でもOKにしたかったからだったりします。




以上の内容はhttps://nealle-dev.hatenablog.com/entry/2025/04/30/152806より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14