エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

テックブログなにもわからないけど知見をまとめて人類に貢献したい

こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。

以前からテックブログ自体の記事をどこかで書きたいなと思っていたところに、 テックブログをテーマにしたイベントが開催されると知り、 ちょうどいいタイミングだったので書くことにしました。

f:id:fukubaya:20210521130029j:plain
チームスマイル・いわきPITは、福島県いわき市のエンターテイメント専用施設である。『PIT』は「Power Into Tohoku!」の頭文字。本文には特に関係ありません。

なんでテックブログを書くの?

事業の利益に直接繋がる訳でもない*1のに、 テックブログを書いて公開するのはなぜでしょうか。 各社で違いはあると思いますが、エムスリーで何件か記事を書いてきた経験から考えてきたことをまとめてみようと思います。

会社とその雰囲気を知ってもらう

多くの会社はエンジニアの採用における広報的な役割としてテックブログを運営しているようです。

まずは会社の存在を知ってもらえないと、就職/転職活動の選択肢にもなってもらえないですし、 全く知らない会社より名前だけでも見たことある会社の方が採用においては有利だと思います。 実際、採用面接やカジュアル面談でも、テックブログを見たことある方が増えているようで、 エムスリーを知ってもらう役割を果たせていると感じます。

また、ブログ内容から、どんな技術を使っているのか、どのような体制で開発しているか、などが伝わるのも 採用の面では役立つはずです。 例えば、エムスリーの場合は言語やフレームワーク、インフラの選定はチームの裁量に任せられていて自由であることが、 多種多様な記事が公開されていることから伝わると思います。

また、個別の記事の中身だけでなく記事の傾向なども雰囲気が伝わる一助になるはずです。 例えば、「こんな内容でもOKされてるの?」と感じてもらえれば、エンジニアの裁量とか社内の自由度は想像できると思います。 僕はインフラ、フロントエンド、バックエンド、QA活動など書きたいことは何でも書いているので、 やりたいことは何でもやらせてもらっているのも伝わると思います*2

実質社内ドキュメント

以前、別の記事でも書きましたが、 開発の成果をまとめてテックブログとして公開すれば、 社外に知見を公開できるのと同時にそのままチーム向けのドキュメントとして機能します。 どうせ書くなら社内にも社外に役に立つ形になっていた方がお得です。

実際に、途中から新たに加入したメンバーやインターン生が最初に読む文書として最適です。 なにより半年後の自分が思い出す時にありがたみを一番感じます。

外部に公開するするつもりで書くと、分かりやすくなるように整理したり、 不足している記述を足したり、ドキュメントとしての充実度が向上します。 ドキュメントだと思って書けば、業務としてテックブログを書く意義も出てくるのではないかと思います。

個人プレゼンスの向上

今の時代、一生同じ会社にいるとは限りません。 何らかの理由で転職したり、独立したりすることはあると思います。 そうでなくても、社外でもよく知られていること自体が、会社の知名度向上や、 社内での自分の評価につながったりするので、個人としても利点はあると思います。 プロジェクト終了ごとに記事を書いておけば、実質職務経歴書です。

個人的には、以上のようなモチベーションもあるので、 テックブログは匿名で書けと言われたら、僕は積極的に記事を書くことはないでしょうし、 書きたいことは個人ブログとかQiitaを優先することになると思います。

ググっても見つからない記事を書く

「書きたいことを書く」のは大前提として、 その上でどのようなトピックを選べばいいのか思いつかないことが多いと思います。

僕は「ググっても見つからなかった」記事になるようにすることを意識しています。 何かを知りたいと思った時に「ググっても見つからなった」ような記事が、読みたい記事のはずです。 ググっても見つからなかったら記事にするチャンスです。

「ググっても見つからない」にもいろいろあって、

  • 新しい技術だからまだ記事が少ない
  • 個別の要素としては記事があるけど、それらをまとめた記事が少ない
  • 昔のバージョンの古い記事はあるけど最新のバージョンの記事が少ない
  • 具体的な(コードを含むとか、運用中の画面キャプチャとか)事例を紹介する記事

これらの要素を1つもしくは複数持つ記事が「ググっても見つからない」記事だと思います。

なお、記事がバズるかどうかはたくさんの人にウケるかどうかであって 「ググっても見つからない」からと言ってバズるとは限りません。 ごく一部の職種や環境に当てはまる人にだけウケる記事になることもありますが、 書く段階では分からないですし(自分ではメジャーだと思っていた)、 そのような人にも役立つならば、書く意義はあると思います。

でもだいたい誰かが書いている

しかし残念ながら、似たような内容は思いついた時点ですでに誰かが書いています。 特に今回のような、新技術の解説とかではない、意見やアイディア、まとめが中心の記事はその可能性が高いです。

したがって、自分の記事の独自性を出すためには、過去の関連記事はある程度読む必要があります。 今回も記事を書くにあたって、いくつか読みました。 読んだ内容を参考にトピックや視点を広げたり、どの点で差異が出せそうかを考えます。

どんなテーマを選べばいいの?

書く内容が思いつかなくて書けない、ということも多いと思うので、 よくあるテーマを実際の記事と合わせて分類してみました。 こういうテーマだと記事にしやすいし、需要もあると思います。

作ってみた!

業務内/業務外で作ってみたシステムやツールなどを紹介する記事です。 テックブログとしては一番メジャーだと思います。 作ってみた背景、目的、仕様、構成と順に紹介していけばそれだけで十分です。

新しい技術試してみた!

新しい技術を試してみて、使うまでの流れや事例をまとめる記事です。 試した事例が少ないことが価値になるので、いずれ普及してしまうと読まれなくなってしまいますが、 その時点では需要が高いので多く読まれると思います。 ただ紹介するだけでなく、最後に所感(こういう用途には使える、こういう場合は他の方法がよいなど)を書いておくと独自性が高まります。

AIチームだと、論文紹介と簡単な実験結果を載せる記事もあります。

忘れていつもググっちゃう!

どうしても覚えられなくていつもググっちゃうコマンドとか仕様はないでしょうか? 毎回ググるんだったら、いっそ自分でまとめてしまおう、というのがこのパターンです。 このような記事は、みんないつもググっちゃうのでGoogle検索からの流入が多く、長期に渡ってPVを稼げます。 しかもいつもググっちゃうので、そのたびに「またこのエムスリーの記事だ」と思ってもらえるので 広報効果も高いと思います。

ぼくがかんがえたさいきょうのやり方

変化が激しいため、何がベストプラクティスか、が常に変わってしまう、 一定に決まらないような話題に対して、現時点でこれがベストと考える例をまとめて提示する記事です。 「自分で考えるベスト」という点においてマサカリが飛んでくる恐さもありますが、 その分オリジナリティが出て興味を持ってもらえる可能性も高いです。

やらかした!

みんな他人の失敗話が大好きです。失敗話というだけでとりあえず見てもらえる可能性が上がるでしょう。

完全に同じ失敗は他人には経験できないので、失敗事例というだけで多くの人にとって貴重な資料です。 ちゃんと原因分析して考察も加えれば、広く役立つ記事になります。

うちではこういうことやってます!

チームを運用する上での取り組みの紹介です。 どの会社でも似たようなチーム運用上の課題はあって、それらを改善する取り組みは需要があると思います。

こういう組織でやってます!

組織紹介です。 何回も書けるような記事ではないですが、会社の雰囲気、仕事のやり方を知る上では一番分かりやすい記事だと思います。 はてブはつきにくいですが、Facebookのシェア数は伸びやすいです。 現場の技術者よりもチームリーダーや管理職のような組織運営を担当する方々にウケるのかもしれません。

それ以外にもいっぱい!

記憶を元に分類してみましたが、過去記事を並べてみると、 ここまで挙げた分類に含まれないような記事もたくさんありました。 この多種多様具合が僕は好きです。 分類はあくまで参考情報で、これにとらわれず書きたいと思ったことを書くのが一番よいと思います。

テックブログの運用

書きたい人が書きたい時に書く

現在、エムスリーでは当番制にしたり、目標本数やスケジュールなどは設定していません。 したがって、1週間に2回投稿がある日もあるし、何もない週が続くこともあります。 僕は個人的には、継続的な投稿よりも内容の方が重要だと思っているので、 書きたい内容を書きたい時/書ける時に書けるのが自分には合っていると思います。 締切とか当番が設定されているとやる気が出ません。

なお、エムスリーでもAdvent Calendarは実施しており、12月は毎日投稿があります。 事前に担当者を募集するとすぐに埋まるので、今は当番制にしても回るのかもしれません。

個人的には、Advent Calendarは業界全体でたくさんの記事が同時期に公開されるため競争率が高く、 読んでもらう機会が相対的に減っていると思っています。 むしろまだ盛り上がる前の11月とか、 完走して業界全体でネタが尽きている1月に毎日投稿した方が効果が高いのではないかと思いますが、 祭りに参加して盛り上げる側面もあるので難しいところですね。

強い人がレビューしてくれる

下書きの記事を専用slackチャンネルに投げると、強い人がレビューしてくれます。 間違っている点を先に指摘してもらえる安心感と さらにコンテンツを充実させてくれるアドバイスがもらえるので、このステップは重要だと思います。

最終的にはVPoEの山崎がOKと言えばOKなので、公開までに時間がかかることはありません。

公開タイミング

自分の記事は、勤務日の休憩時間に見てもらう想定で11:00公開が多いですが、特に決まりはないです。 深夜を避ければいつでもいいと思います。

We are hiring! & 告知

一緒に参加してくれる仲間を募集中です。お気軽にお問い合わせください。

jobs.m3.com

「企業によるブログを活用した技術情報のアウトプット」をテーマにしたオンラインイベント(無料)が5/24に開催され、 VPoEである山崎が登壇します。本記事で興味を持っていただいた方はぜひご覧ください。

*1:開発者向けサービスではチュートリアルとして書いた記事などがそのままサービス利用につながることもあります。

*2:決してやらされている訳ではありません