存在が割と謎なアドカレでなんか書けと突然言われたので、会社でエンジニアブログを立ち上げよう！となった時に立ち上げ、運用まで軌道に乗せた時に感じた事、思ったことをつらつらと書きます。
３日目担当の渋谷某社でゲームエンジニアをしているAzukiです。よろしくお願いします。
さて、突然ですが僕が働いている会社ではエンジニアの正社員が少ないという問題が出てました。
そのため、「エンジニア広報に力を入れよう！」という話になり、その一環でエンジニアブログを作って発信する習慣をつけようじゃないかという事になりました。幸か不幸かその一連の担当を任せてもらえる事になったので伸ばすために意識した事などを紹介します
1.エンジニアブログとしての軸（方向性）を決める
ブログを作る前に会社の広報の方たちと相談をしました。
皆さんご存知の通り、世の中にはエンジニアブログというものはかなりの数があります。
有名なところだとクックパッドさんだったりメルカリさんだったり。かなり記事の内容もボリュームがあるし更新頻度も高いです。すごい。
ゲーム業界でもテックブログはよく見ますし、実際の開発について書かれてるブログも多く、とても参考になります。
そんな中でエンジニアブログを作り、伸ばしていくにはどうしたら良いのか、というのをまずしっかり相談する事にしました。所謂生存戦略ですね。
とはいえ、ゲームの新規プロジェクトの話は書きにくい（情報漏洩の観点とか）ですし、運用プロジェクトだと結構古い技術だしなぁ…と悩んだのですが結果、
エンジニアはわからない事ググる→ググった時の検索上位が日本語だと嬉しいよね という話になり
UnityとかCocosとかゲーム系の情報で、ググった時に検索上位が日本語じゃないもの且つ、自社でノウハウがあるもの を記事にする事にしました。
また更新頻度が低いとブックマークなどもしてくれないので、最低でも２週間に１本くらいのペースで出そう。という事にしました。
本当は毎週書きたいのですが書いてくれる人だったり文化として根付いてないうちにそんな急ペースでやっても誰もついてこなくなるのが実情だろうなという事もあり、無理せずにできる範囲で２週間に１本にしました。
2.記事の品質を保つように意識
インターネットには皆さんご存知だとは思いますが間違った情報であったり、正しいけど雑な記事というのは結構あります。
個人ブログなどではまぁそこまで大きな問題ではないのですが、エンジニアブログは会社のブログとして出すので、適当な事は書けません。
誤った内容の記事を出してしまうと「この会社はそこまで技術強くないな」 という印象を持たれる可能性があり、ブログのせいでエンジニアからのイメージが悪くなる恐れがあります
そのため、立ち上げたブログでは原則としてエンジニアによる記事のダブルチェックと、広報の方にもチェックをしてもらい両方OKが出たら公開、という流れにしました。
エンジニアが読む記事という事でちゃんと正しい事が書かれているかをエンジニアのチェックで担保し、
読みやすさ、会社として出す上で問題ないかを広報の方に見てもらってます。
手間は掛かりますが記事のクオリティのバラツキを抑える意味でも大切なポイントだと思ってます。
３.記事の対象者を冒頭で伝える
エンジニアブログを訪れる大半の方はエンジニアだと思うのですが、エンジニアにもレベルの差が当然あります。
例えばUnityで作ったプロジェクトをAndroidでビルドする！という記事を書いたとして、
読む相手がUnityの存在をこの記事で知るかもしれないし、Unityは知っているけどAndroidビルドはした事ないとか、いろんなレベルの方が記事を見る可能性があります。
記事として書く上で、まずUnityとは！ Androidとは！ ビルドとは！ AndroidSDKとは！と、いちいち解説していたらとんでもなく長くなりますし、内容の本質であるビルドをする手順を知りたいだけの人にとっては早く本題書けやという気持ちになるだけでクソまとめサイトを読んでいる気分になってしまいます。（いかがでしたでしょうか？
なので出す記事は全て、どの程度のユーザーに対して向けた記事であるということをなるべく記事の序盤で伝えるようにしました。
例えば先ほどの例だと記事の最初の方に
・この記事ではUnityをインストール済みで基本的な操作は理解している人向けに解説します
みたいな一文を加えています。
また、導入の手順がしょっちゅう変わるようなSDKであったり、情報が古くなった時にこの手順でやられると困る、みたいな手順に関しては公式のスタートガイドのページを貼ったりしておくようにも心がけました。
4.社内で文化として根付かせる
これはまだ実現できてない事ではあるのですがエンジニアブログは一人だけでは絶対に回りません。書いてもらう様に依頼したり書く時間を業務として割いてもらえる様な理解が必要です。
幸い私の会社ではその辺の理解はあったためスムーズでしたが、まだ書いてもらう文化は浸透していないのが現状です。
なので更新の度に会社のSlackなどで告知をしたりして、会社としてこんな事をやっているんだと言う当事者意識を持ってもらえるよう動くのが大切です。
また、エンジニアブログの編集長的な人間は必要ですが記事のリリース手順やブログのメンテナンス手順などはしっかりドキュメント化しておき、属人化させないようにしましょう。編集長的な人間が辞めた瞬間に更新止まるエンジニアブログとか、よく聞く話かと思います。
まとめ エンジニアブログを作る意義
駆け足でエンジニアブログ作る上で意識した点を紹介しましたが如何でしたでしょうか。事例の一つとして参考にしていただければと思います。
正直任せられた時は「会社のエンジニアブログを作る上で自分個人にメリットはあるのか？」と思っていたのですが、個人ブログよりも伸びやすいので書いた記事がいろんな人に見てもらえると言うのはメリットの一つだと思います。また業務としてアウトプットができる（仕事の時間を使える）と言うのも良くて、アウトプットの習慣付けにもなります。
勿論、記事に関してコメントをしてくれる方や日に日に上がるPV数などもモチベーションに繋がると思います。
後はまぁ、転職の時とか見せれるものが増えるので多少は有利になるんじゃないでしょうか（知らんけど）
まぁまぁ駄文ですがこの記事が誰かの参考になれば幸いですー。