採用のために技術ブログを書くわけじゃない。

広木です。

いろいろ、時が流れるとそのときどきの時代背景のようなものやコンテクストが失われてしまうことがよくあります。すると、手段が目的化するとか主客の転倒などが起きてしまい物事がうまくいかないなんてことになります。

たとえば、採用支援をしているとエンジニア採用をするために、エンジニアブログをやろうとするがあまりうまくいかないという話をよく聞きます。

なかなか書いてくれるエンジニアがいなかったり、いても他のエンジニアブログみたいにバズったりするわけじゃないしなどなどです。

これも主客の転倒が起きているんだと思います。

実際は別にどの会社もエンジニアを採用するためにエンジニアブログを書いているわけじゃないのです。書きたいから書いているし、役に立つから書いているし、そういう発信があるから良さそうな文化を感じ取ってたまたま採用につながることもあるだけなんです。これは結構当たり前のことではあるんですが、忘れられがちなので心に留めておければなと思っています。

ブログはそもそもWeb + Log が略された用語です。Web上で何かの記録やメモを残すアプリケーションが出自の言葉です。

日記ともちょっと違って、本来日記なんて誰にも見せるものじゃないですよね。日誌とかの方が近いかも知れません。

ソフトウェアエンジニアとくにWeb黎明期のエンジニアたちは、自分たちの開発記録や学んだことやはまった問題の解決策などを「記録」して公開することが多くありました。

誰かが同じ問題に出くわしたときの解決策になってもらいたいという利他的な側面とそれをまとめることによって自分自身の学習メモとしてはかどるという2つの理由が初期のモチベーションだったかと思います。

次第にブログは、個人的なニュースメディアとなり、情報発信の手段となり、自己顕示欲やキャリア獲得の手段にもなってきました。でも、それは主な目的と言うよりも副次的な効果にすぎませんでした。

人間の脳みそは管のようなところがあって、アウトプットがないとインプットがはかどらないところがあります。アウトプットするところを決めると、そのためにインプットが自然とできたり、逆にインプットが多くなると自然とアウトプットしたくなるものです。

このような学習のサイクルの中で技術的なブログは執筆され、多くの人に役に立つことが生まれフィードバックを受けてさらに書きたくなるというサイクルの中で技術コミュニティは育ってきたところがあります。

これは、たとえばOSS活動やGitHub上での個人開発がキャリアをつくるためではなくソフトウェアを通じて何かの問題を解決したいというのが目的であるのと似ています。

技術ブログもOSSも研究発表も何かアウトプットしていくことはそのアウトプットの価値自体がもたらす成果のために行うのであって、それによってキャリアを獲得したり、エンジニアを採用したりと言ったことはあくまで副次的な結果に過ぎません。

それを忘れて、「採用強化のためにエンジニアブログを書こう」とすると途端に何を書いたら良いかわからなくなるんです。自社の魅力を伝えようとか、すごくバズる記事を書こうとかそういう風に主客の転倒が起きてしまい、そう考えるととんでもなく難しいことのように感じられ、また自分の日々の仕事とは連続性のないことのように感じられてしまうからです。

それは間違いです。

いや、それが器用にもできる人しかいなければ、別にそれをしても悪いこととは言いません。

エンジニアブログを書くというのは、その会社にいる人々がどのような問題をどんな風に考え、どう解決してきたかについての記録でよいのです。それは泥臭くてもかっこ悪く見えても問題ありません。ほぼすべての価値あるエンジニアリングは泥臭くてかっこ悪いもんです。

でも、そういう様子はきっと誰かが見ています。その誰かというのは、今とちょうどその会社に入社しようかどうか悩んでいる誰かかも知れないし、いつか顧客になってくれる人かも知れません。別にたくさんのひとにバズる必要は無いのです。

認知だけが得たいのなら、広告を打つ方がコストパフォーマンスがよいです。

そうではなくて、インプットしたものをアウトプットすること、解きたい問題について考えた記録であれば、その会社の知的な活動の記録が漏れ出てきて、社内の様子や開発者の文化資本が自然と発露するはずです。その情報が、たまたま内定出した人のクロージングに役に立ったり、エンジニアのなかでのブランド力やコミュニティの中でのポジショニングに役に立つのです。

では、どうやったらエンジニアブログが活性化する文化を創れるのか。

それはまずは、SNSで見つけたかっこいい記事のイメージを忘れてください。そういうのを書くのが目的ではありません。

Qiita Teamでもコンフルエンスでも良いのでまずは、インプットしたことをアウトプットする習慣をつけるところから始めましょう。最初からオープンにzennやqiitaでも結構です。

最初に書いてみるのは、読んだ本やブログの感想やまとめでもいいです。自分のために書くので、誰も読まなくても良いです。

次に、問題に出くわしたときに調べた過程や勘違いしていたこと、調べた内容、結果をまとめてみましょう。

さらに疑問を持って解決まで調べてみましょう。たとえば、Golangでsliceにたいするappendの挙動ってどうなってるんだろう？とかDockerコンテナってなぜ環境を分離できるんだろう？とかなぜ起動が速いんだろうとか。そういうのでもいいです。

その疑問を実際に試して、記録に残してみましょう。そういうのでいいんです。

次第に、それになれてくるとブログに書きたいことが生まれます。インプットのサイクルが回るようになったからです。アウトプットするとフィードバックがもらえるようになります。1件でも何かリアクションがあると結構うれしいはずです。何百件もいりません。

無理に採用のためとか言わずに自分にとって考えたこと、インプットしたこと、まとめたこと、調べたことを外に書き留めることとそれを奨励する文化を創るところから始めましょう。