採用のために技術ブログを書くわけじゃない。
広木です。
いろいろ、時が流れるとそのときどきの時代背景のようなものやコンテクストが失われてしまうことがよくあります。すると、手段が目的化するとか主客の転倒などが起きてしまい物事がうまくいかないなんてことになります。
たとえば、採用支援をしているとエンジニア採用をするために、エンジニアブログをやろうとするがあまりうまくいかないという話をよく聞きます。
なかなか書いてくれるエンジニアがいなかったり、いても他のエンジニアブログみたいにバズったりするわけじゃないしなどなどです。
これも主客の転倒が起きているんだと思います。
実際は別にどの会社もエンジニアを採用するためにエンジニアブログを書いているわけじゃないのです。書きたいから書いているし、役に立つから書いているし、そういう発信があるから良さそうな文化を感じ取ってたまたま採用につながることもあるだけなんです。これは結構当たり前のことではあるんですが、忘れられがちなので心に留めておければなと思っています。
ブログはそもそもWeb + Log が略された用語です。Web上で何かの記録やメモを残すアプリケーションが出自の言葉です。
日記ともちょっと違って、本来日記なんて誰にも見せるものじゃないですよね。日誌とかの方が近いかも知れません。
ソフトウェアエンジニアとくにWeb黎明期のエンジニアたちは、自分たちの開発記録や学んだことやはまった問題の解決策などを「記録」して公開することが多くありました。
誰かが同じ問題に出くわしたときの解決策になってもらいたいという利他的な側面とそれをまとめることによって自分自身の学習メモとしてはかどるという2つの理由が初期のモチベーションだったかと思います。
次第にブログは、個人的なニュースメディアとなり、情報発信の手段となり、自己顕示欲やキャリア獲得の手段にもなってきました。でも、それは主な目的と言うよりも副次的な効果にすぎませんでした。
人間の脳みそは管のようなところがあって、アウトプットがないとインプットがはかどらないところがあります。アウトプットするところを決めると、そのためにインプットが自然とできたり、逆にインプットが多くなると自然とアウトプットしたくなるものです。
このような学習のサイクルの中で技術的なブログは執筆され、多くの人に役に立つことが生まれフィードバックを受けてさらに書きたくなるというサイクルの中で技術コミュニティは育ってきたところがあります。
これは、たとえばOSS活動やGitHub上での個人開発がキャリアをつくるためではなくソフトウェアを通じて何かの問題を解決したいというのが目的であるのと似ています。
技術ブログもOSSも研究発表も何かアウトプットしていくことはそのアウトプットの価値自体がもたらす成果のために行うのであって、それによってキャリアを獲得したり、エンジニアを採用したりと言ったことはあくまで副次的な結果に過ぎません。
それを忘れて、「採用強化のためにエンジニアブログを書こう」とすると途端に何を書いたら良いかわからなくなるんです。自社の魅力を伝えようとか、すごくバズる記事を書こうとかそういう風に主客の転倒が起きてしまい、そう考えるととんでもなく難しいことのように感じられ、また自分の日々の仕事とは連続性のないことのように感じられてしまうからです。
それは間違いです。
いや、それが器用にもできる人しかいなければ、別にそれをしても悪いこととは言いません。
エンジニアブログを書くというのは、その会社にいる人々がどのような問題をどんな風に考え、どう解決してきたかについての記録でよいのです。それは泥臭くてもかっこ悪く見えても問題ありません。ほぼすべての価値あるエンジニアリングは泥臭くてかっこ悪いもんです。
でも、そういう様子はきっと誰かが見ています。その誰かというのは、今とちょうどその会社に入社しようかどうか悩んでいる誰かかも知れないし、いつか顧客になってくれる人かも知れません。別にたくさんのひとにバズる必要は無いのです。
認知だけが得たいのなら、広告を打つ方がコストパフォーマンスがよいです。
そうではなくて、インプットしたものをアウトプットすること、解きたい問題について考えた記録であれば、その会社の知的な活動の記録が漏れ出てきて、社内の様子や開発者の文化資本が自然と発露するはずです。その情報が、たまたま内定出した人のクロージングに役に立ったり、エンジニアのなかでのブランド力やコミュニティの中でのポジショニングに役に立つのです。
では、どうやったらエンジニアブログが活性化する文化を創れるのか。
それはまずは、SNSで見つけたかっこいい記事のイメージを忘れてください。そういうのを書くのが目的ではありません。
Qiita Teamでもコンフルエンスでも良いのでまずは、インプットしたことをアウトプットする習慣をつけるところから始めましょう。最初からオープンにzennやqiitaでも結構です。
最初に書いてみるのは、読んだ本やブログの感想やまとめでもいいです。自分のために書くので、誰も読まなくても良いです。
次に、問題に出くわしたときに調べた過程や勘違いしていたこと、調べた内容、結果をまとめてみましょう。
さらに疑問を持って解決まで調べてみましょう。たとえば、Golangでsliceにたいするappendの挙動ってどうなってるんだろう？とかDockerコンテナってなぜ環境を分離できるんだろう？とかなぜ起動が速いんだろうとか。そういうのでもいいです。
その疑問を実際に試して、記録に残してみましょう。そういうのでいいんです。
次第に、それになれてくるとブログに書きたいことが生まれます。インプットのサイクルが回るようになったからです。アウトプットするとフィードバックがもらえるようになります。1件でも何かリアクションがあると結構うれしいはずです。何百件もいりません。
無理に採用のためとか言わずに自分にとって考えたこと、インプットしたこと、まとめたこと、調べたことを外に書き留めることとそれを奨励する文化を創るところから始めましょう。
コメント
注目のコメント
ほんとにいい話ですね。テックブログで「Pythonでグラフ書く記事？ダメダメ。レッドオーシャンでPV取れないから別のテーマにしてくれる？」なんて言われたら、しんなりしちゃいます。
私テックブログ読むのけっこう好きで、嬉しかったこととか、自分が自然とやってることは外から興味のある人が見たときに知りたいことなんじゃないか？というものでも良いんじゃないかなと思います。いずれにせよSEOでPVを稼がなきゃというものではないので、長文ではなくて、３見出しくらいで終わる編集後記のコメント程度のミニ記事でもいいはずです。
例えば、、
苦戦してるのSlackの分報に投げてたら、先輩がさっとZoomでVisual studio のLiveShare使ってモブプロしてくれて、こんな感じで乗り越えました！とか、会社のイメージは固いけど実はSREチームあって僕３人のうちの１人でGCP使ってて、この本のここ実戦で役立ちました、セーフ！とか、うちのSlackでよく使われているスタンプを抽出してランキングしたら、やっぱりあれが一番でした、とか。
トピックとはウラハラですが、採用目的でしたら、Gaudiy広報の山本花香さんが書かれているやり方が参考になると思います。それでも、がっちりマネする必要はないと思います。私は職業でブログ書いていますが、このようなことはしておりませんし、できないなぁと尊敬します。
https://blog.allstarsaas.com/posts/keep-writing
より、以下引用です。広木さん登場しております😁
-----------------------
目標は「まず継続する」で始まっているので、一旦は「週1本」です。みんなが始めやすく、気負わずに続けられるようにしたかったので。もちろん、Google Analyticsやはてなブックマークなどの数値は見ていますが、追ってまではいないですね。
継続した発信を考えると、スケジュールを決めてノルマ化しがちだと思うのですが、私としてはその考え方から改めないといけないのでは、と考えています。廣木大地さんの『エンジニアリング組織論への招待』を読んだ時、アジャイルに進めることはブログ運営でも同じだ、と感じたんです。いい話でした。カッコイイ内容を書こうと思うと、ほとんどの人は萎縮しちゃうのですよね。弊社では、自分が調べたことは他の誰かも調べるはずだから、そういうのを書いていこうと言ってます。
