Hard Things About テックブログ
今日はテックブログの話をしよう。
マネジメントについての自己啓発書を読むたびに、私は「なるほど。しかし、本当に難しいのはそこじゃないんだ」と感じ続けてきた。
テックブログという単語に対するわたしの正直な感情はこれだ。どうやったら上手くテックブログが回るかのノウハウはネット上で多く流通している。ただ、本当に難しいのはそこじゃないんだ。多くのノウハウは「すでにそれなりに上手く行っている状態」が前提のものが多い、それは全く止まっているものを動かすのにあまり役に立たない。
ミラティブは、2021年に年間を通してエンジニアが継続的にアウトプットし続けることができた。これについて、世界の多くのエンジニアに有益な情報を提供できたなら幸いである。
わたしがここ1年で経験した、あるいは学んだことをここにまとめる。本稿はテックブログをどう運用しているかを経営職の視点でまとめたものである。
ただし、こういう困難な経験から得られる教訓もあるし、有益な助言もある。
先に結論を言う。テックブログを運営するとは、経営陣のコミットが必要であり、エンジニア組織を構築することであり、ソフトウェア的な企業文化を醸成することである。
テックブログ
その概要
テックブログはエンジニア発信の場であり、採用や広報にも利用される。
BASEさんによると
一方、長続きさせるのがめちゃくちゃ難しい施策である。
効果を定量的に測るのが難しい
エンジニアを巻き込むのが難しい
優先度が永遠に上がらない
書くネタがない
書くのが面倒
挫折しがち
なにが難しい？
「各人から見ると優先度が高くない」かつ「効果を定量的に測れない」、これは意思決定、タスク優先度、モチベーションのあらゆることに悪影響を及ぼす。
（一部を除き）エンジニアからあまり協力を得られない
経営陣の理解を得られない
（言い出した）採用担当ですら優先度が上がらない
「めちゃくちゃ効果がある」割に誰から見ても常に優先度が4〜5番目になる。そして効果を定量的に測れないと何が起きるか？
無限に頑張る or 全くやらない
普通は無限に頑張らないだろうからやらなくなる
やっていることに意味があるかないかわからない
モチベーションが上がらない
優先度が最低になる
スタートアップのエンジニアはタスクの優先度付けをしたり、KPIの達成に対してPDCAを回すような思考に馴れている。そもそも、偉大なプロダクトを生み出すためにジョインしたのであって広報をしたいわけでもインフルエンサーになりたいわけでもない。このような性格の人材に対して、テックブログはいかにも相性が悪い。貢献度の高い優秀なエンジニアほど効果不明な施策には付き合わない。
「面接は協力してくれるのになぜ記事を書いてくれないのか？」それは面接は比較的受動的なワークで、それほどマインドシェアを奪われないからだ。効果測定も極めて容易で、組織に対して直接的な影響が出る。一方、記事の執筆は創作活動であり、能動的なアクションが必要になる。こういう類のものは優先度が高く設定されているか、優先度が低くても自然に行われるような環境を作らなければならない。
じゃあどうする？
次の3点が重要である
経営陣がエンジニア採用にコミットする
内発的なモチベーションをつくる
アウトカムで判断しない
テックブログを『動かす』
経営とエンジニア採用
「経営陣がエンジニア採用にコミットする」とは次のことではない。
経営陣が積極的にエンジニアをダイレクトリクルートする
エンジニア採用は積極的にエンジニアを巻き込む
エンジニア採用に積極的に資金を投下する
例えば次のようなことを表す。
経営チームにCTOを置き全権を渡す
CTO自身が多くの時間と労力を割く
事業計画を下方修正しその分をエンジニア採用のリソースとする
エンジニアの働きやすさを中心に置いた人事制度の設計および文化の構築
経営陣にできる最大のエンジニア採用施策はエンジニア採用の優先度を無理やり引き上げることで、これは短期の事業成長を犠牲にすることと同義である。テックブログの優先度が4〜5番目になるのは経営陣がそういう風にしているからであって、エンジニアの責任でも採用担当の責任でもない。
内発的なモチベーション
テックブログはトップダウン的なマネジメントあるいは外発的なモチベーションで成立しない。
業務命令
手当
評価
内発的なモチベーションを生み出す仕組みが必要だ。
記事を書くことそのものが楽しい
記事を書く過程で振り返ったり、調べたり、FBを受けて成長できる
社内や社外から「いいね！」を貰えるのが嬉しい
組織に貢献している（！）実感がある
セルフブランディングできる
何回も書くと記事を書く能力が以前よりも上がっている、より上手く、より速く書けるようになる
周りがみんな書いているから自分も書いてみようと思う
これはコミュニティマネジメントである。エンジニアの最優先かつ大部分の仕事はプロダクト開発だろうから、優先度が高くなくても効果が目に見えなくてもインセンティブがなくても、自然と何度も行いたくなるような状態をつくることが重要である。
アウトカムを見ない
次をやるべきではない。
PVを見る
効果を定量的に測る
定量的な結果をもとに意思決定する
これは新規事業を始めた直後にボトムラインを気にするくらいに問題がある。次の順にやっていくのが良い。
記事を書いて公開する
社内で「いいね！」する
これらを無理なく継続的に行えるようになるまで繰り返す
テックブログ最大の困難はアウトプットし続けることが難しいということなので、どうしたらアウトプットを継続できるかだけを考えたほうが良い。
最初に問題になるのはエンジニアのライティング能力である。つまり書けない、あるいは書き方を忘れている。
極端なことを言うと、採用に全く効果がなくても記事を執筆、公開し続ける状態にもっていく必要がある。
いくつかのトピック
その他のトピックを紹介する
やらないという判断
スタートアップでは採用広報よりもプロダクトグロースの方が圧倒的に重要かもしれない。その場合、やらないという判断は必ずしも悪ではない。
エンジニアの思考プロセス
エンジニアは「採用のためだけのアクション」が嫌いである。採用以外に何でも良いから効果がある、レバレッジがかかるようなやり方が良い。優先度が高くなくてもコスパが良いのならやる気になる。
会社の指針
セルフブランディングを奨励するような組織でないと機能しないだろう。また管理部のバックアップは必要である。「記事は書いてくれ、ただし名前は出すな、絶対に炎上するな、自分で判断しろ」これで創作活動をするのは無理だ。
ほとんど文化の問題であり時間がかかる
これは覚悟するしかない、また経営陣がコミットする理由でもある。
ミラティブの事例
ミラティブテックブログ
2021年12月時点、CTOはほぼなんもやっていないし言ってないけどなんかみんな勝手に書いてくれる（ありがとうありがとうありがとう）
採用にめちゃくちゃ効果あります！
いくつかのナラティブ
テックブログ自体は2019年から始まっているが、わたし（当時クライアントグループのマネージャー）が引き継いだのは2020年の秋頃から。コロナ禍が始まったあたりで採用のペースを落としたため、一時期止まっている。
ブログを作ったのはわたしではなく、Co-Founder CTOの偉大な業績である。ありがとうありがとうありがとう。文化的にはエンジニアの裁量が大きく働きやすい組織だが、アウトプットしない期間があったため諸々忘れてしまっていた。
止まっているものを動かすのはタフな仕事だ。「それ効果あるんですか？」わかる。わかるわ。わたしもそう思う。とはいえ結局当たり前のことを当たり前にやるしかない。
結果、定量的になにかがすぐに変化したわけではないが、定性的には明らかに手応えがあった。面談をすると読んできてもらえることが多い。候補者体験は確実に改善した。
そもそも我々のミッションは『わかりあう願いをつなごう』、その行動指針は『わかりあおうとし続ける』。発信することは我々の大義であるし、エンジニアとしても自然の行動である。
いくつかの工夫
一般的なプラクティスを実践している
誰がいつ書いても良い
書いたら他のエンジニアからレビューをもらう（数分から数時間以内）
公開したら「いいね！」
いくつかマネジメント上の工夫を入れている。例えば、目標設定に関して
目標の置き方
会社全体としてこれくらい出したい（月に3本とか）を設定しておく
グループごとに目標を設定しておく（バックエンドは月に1本とか）
これを3〜6ヶ月先くらいまで見通して置く
目標を置く理由
締切があるほうが人は動く。誰もがダイエットしたいと思っても目標がなければアクションはしない
グループごとに設定すればチームで解決する動きを作ることができる。「今月行こうと思ってたけどちょっと苦しい」「自分いけるわ」。
目標を達成することは楽しい、スタートアップはそういう人材が集まっている
無理のないソフトな目標
エンジニア一人あたり半年に1本は書けるだろう（半年に1本も書けないとするとそれはなにか別の問題を示唆している）
半年間ずっと忙しいという状況のメンバーはいないだろう（半年間ずっと忙しいのであればやはりそれは別の問題を示唆している）
執筆者に温度差が出るのは仕方がない、熱心な人を大切にしよう
また、その他の工夫をいくつか紹介する。
1次情報はなるべく含まないようにする
ダメというわけではない、CTOか広報担当がチェックすればもちろん良い。ただ「チェックが必要」となると書くのが面倒になってしまう、気軽に書けて気軽に出せるほうが良い。
タスクとしての取り扱いについて
テックブログはいつ書くべきか。いつ書いても良い。ただこれをタスク（バックログ）として扱うかはかなり微妙である。結論としては、個人のやりやすさに合わせることにした。つまり自由にして良い。隙間時間に書く人もいるし、とある一日を「執筆の日」にした方がやりやすい人もいる。執筆は創作活動だからそのやり方はクリエーターとチームに委ねると良い。
感謝する
誰かが記事を書いたら書いたこと自体に「いいね！」しよう
記事を公開したら「いいね！」しよう
「いいね！」してくれた他の部署のメンバーに感謝しよう
もし他の部署の人がテックとは無関係ななにかをパブリッシュしたら？そう「いいね！」しよう
キャズムを超える
最初はCTOがフルコミットする。その次はマネージャーの協力をもらう。その次はマネージャーではない『アーリーアダプター』の協力をもらう。そうやって少しずつ坂道を登るように進める。早い段階でスケールアウトしても上手くいかない。これは根気のいる仕事だ。
テックブログの運用はコミュニティサービスを作ることと同じだ。「書くと楽しい！」「書き続けたい！」「誰も見てくれなくても、何の役に立たなくても楽しい！」そういう状態を作るのだ。採用施策を考えるのはこの後で良い。
おわりに
なぜ『HARD THINGS』っぽい論調なのか。特に意味はない。
内発的なモチベーションが大事と書いたが、外発的なモチベーションに意味がないわけではない、むしろ重要である。これはどこかで書きたいと思う。
We are hiring!
ミラティブは組織運営もコミュニティマネジメントとして行うという、ミッションとの一貫性を持った会社です！
エンジニアをめっちゃ募集中です！デザイナーもめっちゃ募集中です！というかあらゆるポジション大募集中です！
この記事が気に入ったらサポートをしてみませんか？