morimorihogeです。涼しくなってきた！これで生きていける！ありがたい。
noteでこんな記事がbuzzっていました。
テックブログは続かない - 何サイトか潰した後にブログが有名な企業に転職しての気づきと反省
ちょくちょく話題に上がる技術ブログ続かない問題ですね。昔から1年に1度くらいはこの手の話題が出ますが、今年は感染症の関係でF2Fコミュニケーションを取るハードルが上がったことからも、技術ブログにもスポットライトが当たっているのかもしれませんね。
というわけで、続かないと言われているテックブログを続けているTechRachoの中の人として「ワイにも言わせてくれ」と感じることがあったので筆を執りました（Twitterだと長くなりすぎた、とも言う）。
※普段は「技術ブログ」の用語を使っていますが、本記事では元記事に合わせて「テックブログ」表記で統一します
立ち位置紹介
はじめましての人向けにさらっと僕の立ち位置やTechRachoの現況について書きます。
morimorihogeって何者？
BPS株式会社という50名程の開発会社で10人ほどのWebシステム開発チームのチームリーダーをやっています。
直上の上長は役員陣なので、中小企業の部長職という感じのイメージで、受託開発案件の要件ヒアリング/見積からシステム設計・開発・インフラ設計・構築といったエンジニア仕事、採用及びチームメンバーの評価・相談など手広くやっています。
どんな仕事をしているかなどは以前書いた記事を参考にして頂ければと思います。
本ブログ：TechRachoについてはそうした通常業務を行う傍らで僕自身が会社に対して「やりたい」と言って続けてきたプロジェクトで、4～5年前くらいから正式に予算を付けて平日毎日更新を続けています。
こちらの歴史的経緯などは以下の記事を見ていただければまとまっています。
現在のTechRacho運営体制
TechRachoのサイト運用は現在僕が全体の責任者となりつつ、八田（hachi8833）がTechRacho専属の編集・執筆担当として行われています。
その上で、週1回の定例MTGとして代表の渡辺、採用担当の大場、SEO担当のメンバーが加わったメンバーで方向性・タスク優先順位などを話し合っています。
サイト改善（デザインや機能修正）という点で手を動かすリソースとしては、社内メンバーの通常業務にスキマ的な稼働空きが出たときに対応している状況で、ebiやスギムラ、スギヤマに対応してもらっていたりすることが多いです。
最近だとアドベントカレンダー的なイベントで夏のTechRachoフェアをやったりしました。
元記事に対して感じたことなど
元記事をベースに僕の意見などをまとめていきます。
「採用としてのテックブログの意義」について
「採用としての」ということであれば概ね同意します。エンジニア視点からは承服しかねる部分もあるかもしれませんが、論理の流れとしては問題ないし、納得できるかと思います。
僕は自分のチームの採用も見ているのですが、ここ最近のITエンジニア採用界隈は概ね2回、多くて3回程度の面接で採用の可否を決めないといけない状況で、ほとんどお互いの情報がない所からスタートして双方がマッチングするかどうかを調整するにはあまりにも短いと感じます。
一方で、面接回数を増やすというのも双方負担が大きいです。求職者は通常2社以上同時に就職活動しますし、企業側も2名以上同時並行で採用活動を行っているため「お互い気のすむまで事前調整を行う」というのは「双方合意に至らなかった面接・調整にかかった人的・金銭的コスト」とのトレードオフでもあります。
また、職務経歴書や企業HPなどに現れにくい「その人・その会社の文化（ノリ、とも言う）」については実際に話してみたりといった「近い（今風に言うと密な）」コミュニケーションをしないと触れることすら困難です。
求職者が会社選び（辞めるときも）をするときのポイントは「金」「人間関係（同僚や考え方など）」「仕事内容」と言われますが、企業ブログは「人間関係」に相当する部分を企業側から発信する手段としてコスパが良いと思います（求職者の人数によらず記事執筆コストが固定のためスケールメリットがある）。
※「仕事内容」についてはNDAや権利周りの問題もあり充分には書ききれないこともあるため、業種や職務内容による
自社のノリを発信しておくことで、そのノリに共感してくれる人は呼び込み、共感しない人は応募自体を避けてくれると採用の命中率が上がるので最高ですよね。
そこまで行かなくても新しい応募者との面接の度に同じことを話す手間を軽減するという点でも即物的なメリットはあると思います。貴重かつ有限な面接の時間の価値は最大化したい。
一方で「採用としての」という単語を外したテックブログの「意義」については他にも色々書きたいことがあるのでそちらは後述したいと思います。
「テックブログが死ぬ要素」について
こちらはもう10年以上死屍累々を積み上げてきた業界なので、失敗パターンとしては成熟しているように思います。
ただ、後述しますが「執筆者にとってメリットを提供する」ことが全てのエンジニアに響くわけではない点については見落としがちかもしれません。
「テックブログの開設・継続は経営層案件」について
予算を組んでちゃんとリソースを積め、というのはホントその通りで、TechRachoも平日毎日更新できる体制にするには執筆・編集専任担当のJOINが不可欠でした。
「社内稟議を通すのが面倒だから空き時間でやる」というやり方がプロトタイピングとして始めるのに容易いのは否定しませんが、社内稟議を通すために作った説明・説得のための資料は後々協力者を募ったり、社内向けに説明するときにも使えるので無駄にはなりません。
また、こうした資料を作る・作れる人が解説したテックブログの方向性を引っ張っていく人になるので、そこまでのやる気が発起人にあるか、という点でも経営層案件にまで引っ張っていった方が責任者がなあなあにならなくてよいと思います。
目的を持ってプロジェクトを進めるには責任の所在が明確な体制の方が良いのは確実で、「やりたいよね」という空気が集まった合議制は一見良さそうにも見えますが、細かい方向性のすれ違いが起きるとそこから破綻してしまう可能性もあります。
この辺りTechRachoではどうしているかについては「意義」とも関連してくるので後述します。
全体的な感想
「テックブログを採用・広報ツールとして運営する」という視点であれば全体的に納得のできる内容でした。採用担当や経営層向けには理解・納得してもらえるのではないでしょうか。
一方で、自分の中にあるエンジニアの視点からすると言いたいことが色々ありましたｗ。
ただ、元記事を書いている久松さんは実は僕の大学院時代の先輩で面識があり、普通にエンジニアとしても仕事のできる方です。元記事はメインターゲットがエンジニア向けじゃないのでこういう書き方になった、ということだ思います。
＃ 元記事を読んで「うーん」となったエンジニアな人もいるかと思いますが、あくまで人事・採用担当者向けの視点で書いたらこういう書き方になった、ということは頭に入れておいて良いと思います。少なくともエンジニア職のことを全く理解していない人が書いた記事ではない、ということで。
元記事になかったエンジニア視点や自分の考え
元記事に対して僕の視点から「ちょっと自分＆TechRachoの考えとは違うかな」と思ったことを中心にまとめてみます。
テックブログの「意義」について
そもそもテックブログの「意義」が立場によって見ているものが違うことがありますので、その不整合については考慮すべき部分だと思います。
単に「テックブログやるよ、協力してね」と声をかけるだけだと、立場によって色々な「意義」を読み取っていくと思います。
- 人事・採用担当者：会社のプレゼンスUP、求職者向けの採用アピール
- 社内エンジニア：技術ノウハウ公開による世間やコミュニティへの貢献、自己のプレゼンスUP
- 後輩の育成を命じられた先輩エンジニア：後輩教育がてら、やってもらったことを技術記事にまとめさせて説明・文章力を鍛えてもらおう
これらは一例で、その他にもあるかもしれませんし、会社によってはまた違ったパターンがあると思います。問題なのはこれらそれぞれの思惑が競合せずに回っているときは問題がないのですが、いざ衝突したときには不満になりがちということです。
例えば、元記事の「テックブログが死ぬ要素」にある以下の項目なんかは各々が考える「テックブログの意義」のすれ違いが起こりそうな所です。
- 濃密すぎる文章チェック・法務チェック
- 採用担当：広報の一環としてやってるんだから、当然内容のチェックはするし修正も入れるよ！
- エンジニア：技術の話なら自由に書いてよいと言われたから書いたのになあ。そもそも文章にまで修正を入れられてしまったらそれは俺の文章じゃないよ・・・もう嫌な思いするの嫌だし書かんとこ（モチベーション↓↓↓
- （上記とは逆に）チェックが皆無で内容がしょぼく、社内外にディスブランディングとなって「投稿したら負け」という雰囲気になる
- 採用担当：技術記事の良し悪しはよくわからないのでエンジニアサイドでクオリティチェックはお願いしたい！（ので内容のチェックはシニアエンジニアお願いね！という丸投げ）
- シニアエンジニア：えっ。それって仕事増やされただけやないですか・・・。そもそも技術記事のレビューなんて普段の業務でやってなかったし匙加減とかわからんでホンマ（よくわからんので素通ししとこ）
- ジュニアエンジニア：シニアエンジニアが忙しそうなので書いてほしいって採用担当にお願いされたからたくさん記事を書くぞー（既に他サイトであるような入門記事の焼き直しが多発して品質・採用ターゲット面での魅力がなくなる）
- （ヘッドハンティング対策で）完全匿名にする
- 採用担当：他社からの引き抜きに利用されたら嫌なので匿名で書いてね！
- エンジニア：匿名だと自分のプレゼンスUPに繋がらないので、それなら個人ブログに書くわ
じゃあどうすればいいのかというと、サービスを設計する時と同様に、自社テックブログの価値や主要顧客を明確にすべき、というのが僕の考えです。
例えば、TechRachoでは4年前のテコ入れ時にリーンキャンバスを作成しました。
※公開用に一部編集しています＆内容が4年前基準になっているので今だとちょっとそぐわない部分があるかもしれません
ここで特に大事なのは「1：課題」と「2：顧客セグメント」で、僕はこれだけでも明確に文書化すべきだと考えています。
例えば、TechRachoは
- Web開発を主業とするエンジニア
- 転職先を検討中のエンジニア
- Web開発の発注先を検討中の顧客
という優先順位をつけ、中堅エンジニア層をメインターゲットにしつつ、求職者や顧客向けはサブターゲットとして方向性を定めました。そのため「採用向けもターゲットに含まれるテックブログだけど、あくまで舵取りや価値観はエンジニア視点」というポジション取りになっています。
結果、エンジニアとしては自分自身の属性がメイン顧客となるので「自分や同僚が読みたいと思う・助けになるような記事＝テックブログに適した記事」となり、読者のイメージがつきやすいというのはメリットかもしれません。
一方で、このやり方は純粋な採用ターゲットとして考えたとすると投資効率が悪いかな？と感じることもあります。
採用ターゲットが先にあるのであれば、テックブログに手を出すよりも先に、求職者が見るような媒体にお金を払ってインタビューPR記事を出稿してもらったり、慣れているライターに採用ターゲットな記事を書いてもらって広告に投資するという手なんかが考えられます。このやり方だと広報として表に出す情報として内容の統制が取れますし、品質面でも有利な面はあるでしょう。
たまたま社内エンジニアにテックブログに興味のあるメンバーがいて、採用ターゲットの記事執筆に快く協力してもらえるなら最高ですが、そうでない場合には無理にテックブログという体裁にこだわり過ぎない方が目的に沿った投資ができるんじゃないかな、というのが僕の意見です。
いや、他の施策はもうやってるし、自社エンジニアの成長にも利用できるからテックブログでやりたいんだ！という場合には、せめてエンジニアサイドのマネージャーにちゃんと現実的に回せるのかをヒアリングしてみるのが良いと思います。いきなりやると燃える可能性がより高まります。
技術記事を書くことを全エンジニアの業務にすべきなのか問題
そもそも多くの会社において、エンジニアはシステムの開発や運用・保守を行うために雇用していますし、従業員サイドもそのつもりで雇われていると思います。そして、スキルもそれに準じています。
元々技術ブログを個人で書いていたり、趣味で技術系同人誌を書くような一部の意欲の高い人を除き、職業エンジニアは通常業務として不特定多数が読むことを前提とした文章を書く訓練を受けていませんし、その人がスキルアップしたいポイントであるとも限りません。
これがEM（Engineering Manager）やテックリード、エンジニア上がりのPM（Product Manager）やCTOであれば、技術啓蒙活動や社内外の合意形成のために「人に刺さる・伝える」文章を書く機会ができて鍛えられていく（かつ弱いなら伸ばすべき）かもしれませんが、そうでない大部分のエンジニアのうち、記事執筆に興味のない人にとっては業務時間を使って良いという前提が付いたとしても魅力的に感じない可能性を考慮に入れるべきです。
ましてや突然経営層から「テックブログでは全員採用担当、全員広報担当だから業務命令だ、書け」と好きでもない仕事を強要されてしまった場合、会社に対するエンゲージメントは確実に低下するでしょう。
※入社する前からエンジニアの必須業務として記事執筆業が明示されている場合は問題ないと思いますが、かなり例外的な例でしょう
いや、エンジニアだって今は人に伝わる文章を書かないと仕事できないから無駄ではないぞ？という声もあるかもしれませんが、職業エンジニアがclosedな開発プロジェクトで書く開発チームに伝われば良い（誤解があっても直接フォローできる）IssueやPRの文章と、どこからマサカリが飛んでくるかわからないインターネットに晒す文章では勘所が大きく異なります。最低限の文章力レベルでは確かに共通する部分があるかもしれませんが、それは特殊スキルというよりは一般的な国語力とか教養レベルなのではないでしょうか。
実際、弊社社内でも記事を率先して書いてくれない人の文章力がないかといえば全くそんなことはなくて、むしろ業務ではとても丁寧でいい感じのIssueやPR、ドキュメントを書いてくれる人が多数います。
そんなわけで、技術記事執筆の能力とエンジニアとしての業務文章力はそこまで強い相関がないし、記事執筆能力は通常業務では保有してなくても困らない（ので積極的に伸ばすメリットを感じにくい）というのが僕の観測範囲での感想になります。
そんなわけで、TechRachoでは一時期記事執筆を強制した時期もありましたが、今では「強く推奨する」程度に留めつつ、興味はあるけどきっかけがないと手が出しにくい、という人向けにアドベントカレンダー等の企画を行ったり、執筆ガイドラインや記事ネタの選び方などを社内で啓蒙しています。
テックブログ運営サイドからするともっとみんなにたくさん記事を書いてほしいという気持ちは常にあるのですが、無理やり記事執筆を迫ることで逆に鬱陶しがられたり、関わるとめんどくさいチームだなと思われない匙加減が大事だと思っています。
色々と紆余曲折や施策を試しても来ましたが、今はふとプロジェクトの合間で手が空いたときに「書いてみるかな」と思ってもらえるくらいの存在感と、書こうと思ったときに執筆負担を少なくするための準備をしておくことか運営としてできることなのかな、と思っています。
※TechRachoではエンジニアが慣れ親しんだMarkDownで入稿できるようにスタイルガイドを社内Docbaseに用意しています
執筆者へのインセンティブ設計について
そもそも記事執筆するスキルがある人でも「所属している自社の技術ブログに技術記事を書くこと」が魅力に感じないことがあります。
社内レビューなどを気にせず自由に書きたいという人にとっては「その会社に所属しているいちエンジニア」としてよりも「エンジニア個人」として記事を書く方が気楽という話もありますし、例えば個人開発しているOSSプロジェクトなどについて書いたりする場合、会社と個人が明確に切り離されている方がうれしい、と思うこともあるでしょう。
こうした「記事は書けるけど自社テックブログには書かない」という人に書いてもらえるようにするには、内容のレギュレーションハードルを下げたり、OK/NGな内容を明確化しつつも「個人ブログ（Qiita等の外部サービスを含む）で書くよりも自社テックブログで書く方が利点がある」と思わせる何かを運営側で用意する必要があるでしょう。
それは、運営の内情や思いを伝えて共感してもらうことだったり、より多くの読んでほしい人に読んでもらえるサイトの知名度があることだったり、後述するインセンティブの話になってくるでしょう。
※この辺あまり気にせず「いいよいいよ」と書いてくれる人もそれなりにいるので勘違いしがちですが、運営側からなあなあにしてはいけない部分じゃないかなと思っています
※社内勉強会で話した資料より。どれくらいまで広い内容が許容されるのかは運営側から積極的に出すようにしています
そして、執筆者へのインセンティブですが、これは公平性の点から考えると色々と悩ましい問題を秘めています。
まず、元記事にもあるように前提として業務時間を使って記事を執筆して良いというのは大前提とします。ここには特に議論の余地はないでしょう。
しかし、今度は業務時間を使って記事執筆の時間が取れる人と時間が取れない人の間で不公平が発生します。どちらも業務命令通りの仕事をこなしているのに、技術記事執筆タスクを割り当てられた人はそうでない人に比べて追加のインセンティブをもらうことになりますので、極論「開発業務をやるよりも、技術記事をひたすら執筆している方がインセンティブの分だけお得」ということになってしまいます。
本来エンジニアを雇用している目的である開発業務と、（エンジニアにとっては）サブで行っている広報・採用施策としての記事執筆で、もらえる報酬が後者の方が大きいというのは明らかに問題ですよね。
特に弊社の場合は「技術記事は率先して書かないけど仕事はできるエンジニア」というのが結構な割合で在籍しているため、こうしたインセンティブ設計の導入は慎重にならざるを得ませんでした。
これは、10人以下くらいのベンチャー・小企業であればこうした不公平感は気持ちの一体感とかノリで合意形成することもできるかと思いますが、人数が増えてくると不満が上がってくる可能性があるでしょう（弊社内でインセンティブを話題にしたときにこうした議論がありましたので、実際に議論に上がったことです）。
この辺り、既に社内全体で記事執筆に対するインセンティブのコンセンサスが取れている場合は問題ありませんが、新規導入しようとすると問題になりがち、ということで。
また、元記事では「所属チームにカンファレンス旅費等で還元する」という方法もあるかもしれませんが、これは不満の向かい先が個人からチームに行くだけで、やはり根本解決にならないでしょう。チームごとに記事執筆に時間を取りやすいチームとそうでないチームができるので「あのチームだけ優遇されてずるい」となりそう。
この辺りは正直100%の人たちが納得する仕組みを新規で作るのはどうやっても難しいのですが、それまで真面目に会社の売上や出力に貢献してくれてきた人のモチベーションを不用意に下げるようなことは気を付けたいですね。
そんな背景もあり、TechRachoでは現在金銭的評価に直接結びつくインセンティブという形ではインセンティブを用意していません。ただ、せっかく書いてくれるひとには何かできたらいいな、という所から、ちょっと良い自社ブランドボールペンを書いてくれた人に配ったりなどささやかな対応を試みたりしています。
2018年のアドベントカレンダーの際に作成したTechRachoボールペン。「もらったらうれしいし、邪魔にもならない」という要件から独断と偏見でLAMYのSafariを配りました（単価がお高くてイベント等での一般配布はしていません。持ってたらレアモノ）
まとめ
エンジニア採用は需要に対して供給が間に合っていない状況が続いているため、採用施策の一手としてテックブログを検討するのは方法論としては妥当ですが、実際にやろうとするときはエンジニア側の思いも大事にしてほしいな、という気持ちから色々と自分の考えを書いてみました。
全外注などに極振りしない限りはテックブログ運営には自社エンジニアの協力が必要不可欠なので、採用担当の思いが走り出したいという気持ちをぐぐっとこらえつつ、社内エンジニアにもそれとなく意見を聞いてみたりするのが良いと思います。目的と手段を取り違えないようにしたいものですね。
ではでは。年に1～2回くらいはこの手の記事を自分の考えのまとめとして書くのは悪くないと思っていた所なので、ちょうど良いタイミングでした。また半年くらい過ぎたらこの手のネタを話題にすることがあるかもしれません。