2014年に立ち上げ、2015年5月をもって一時休業していたエンジニアリングブログを再始動します。

アイリッジで技術広報を担当しています、野口です。 たまたま鳥のアイコンを使うことが多くなってきたので、鳥の人として認識されることが多いですが、 特にその鳥が好きというわけではありません。

なぜ始めるのか

一人でも多くの方々にアイリッジのエンジニアリングを知ってもらうため、このエンジニアリングサイトを始めます。

2015年までのエンジニアブログではコーポレートサイト中の1コンテンツとして、

  • マーケティングブログと共存
  • 毎週1回、マーケティングと交互に記事を書いていく
  • エンジニア全員持ち回りで書く
  • メールベースで社内レビューのファイナライズし、それをサイト担当者に渡してWordPressシステムに転記してもらう

という運用でやっていました。全員が順番に書くことを強制してしまったため、全員が1周するまでに長い時間がかかってしまい、 当初意欲的だったメンバーも記事を書くことに対するモチベーションが下がってしまっていました。

さらに組織の観点でも、2015年頃はエンジニアはその半分程度の15人強(全従業員数で30人弱)でしたが、今では40人近く(同66人。2017年7月末現在)と 2倍以上の規模に成長してきたため、過去にエンジニアブログをやっていたことも知らない社員も増えてきていました。 実際、過去のエンジニアブログに書かれているような内容を検索エンジンで検索したり隣の人に聞いたりしている様子に遭遇してこれは改善すべきだと思っていました。

このように規模が大きくなるにつれて、他のチームのエンジニアが何を考えて何をやっているのかが理解しづらくなってきたこともあり、 今このタイミングで再度立ち上げることにしました。

さらなるエンジニア組織の拡大を目指すため、社外のエンジニア関係者にも伝えていくことも狙いとしています。 エンジニアブログを休止している期間にも、アイリッジのQiita Organizationを開始したり、 社外技術勉強会の登壇/主催の回数を増やしてきたりしましたが、インターネット上の自社サイトに構築することにより、 アイリッジ内部で起きているエンジニアリングについて多くの人に伝えられるだろうと想定しています。

以上をまとめると、私たちがこのエンジニアリングサイトを始めるのは、社内外のエンジニアリングに関わる人たちのコミュニケーションを促進するため、ということです。

どのようにやるのか

前述の運用ポリシーで実践した経験を踏まえて、また前回と比べ温度感を揃えることに注意を払わなければならないので、 今回はいくつかの点を注意することにしました。

  • マーケティングブログ・コーポレートサイトからの分離
  • 本当に伝えたいことを伝えたいタイミングで伝えられるようノルマを低くする
  • 書きたい人を中心に書いてもらう
  • Git、Merge Requestを用いたレビューと記事公開フローの整備

順に説明します。

コーポレートサイトからの分離

元々考えていたことではあるのですが、新エンジニアリングブログはコーポレートサイトから分離し、運営していくことにしました。

狙いはいくつかあるのですが、コーポレートサイトは株主や顧客、転職希望者などエンジニアリングにそれほど興味のない閲覧者も多く、 さまざまなコンテンツが混ざっているため、サイトとしてのまとまりがなくなってしまっていた、ということです。

サブドメインを切り出すことで、これまでのURL (https://iridge.jp/blog_cate/marketing-blog/) と異なり、URLをすっきりすることもゴールにしています。 コーポレートドメインのサブドメインを使うことにしましたが、サブドメイン名を何にする考えることにしました。

結果的には eng.iridge.jp としたわけですが、社内でも何人かに聞かれたので、ここに理由を書いておきます。

サイト名を「iRidge Engineering」とすることにしました。日本語だと技術ブログやエンジニアブログ(前述の弊社で運用していたブログも 「エンジニアブログ」としていました)ということが多いので、この文脈で一番多く使われる表現は tech のようです。 一方海外に目を向けると、Techという表現はこの文脈でほとんど使われることはなく、ほとんどが engineering という単語が使われています。 technologyとengineeringとで何が違うのかについては記事が1つ書けてしまうので、ここでは触れません。

そこで、 engineering.iridge.jp でもよかったのですが、イベントでノベルティを配る機会も多くなり、短いURLがよいだろうという判断により そうなりました。次期リニューアル時にはまた変わるかもしれませんが、しばらくはこれで行こうと思いますので、ぜひ覚えてください。

ちなみに、 engengineer(s) の略ではなく、 engineering の略のつもりです。

投稿数のノルマを低くする

前回のブログは「毎週書く」というルールにしていました。当時の人数からすると3ヶ月に1回回ってくるという感じでローテーションが始まりました。 実際に始まってみると、書きたくない人が本業が忙しいという理由でその週がスキップになったり、(当時の)編集長がアサインのリスケジュールをしたりと いろいろなところに歪みを抱えていました。とりあえず1人1記事回すということを当初の目標にしていたため、最後に残った数人が書かないまま 部署内のブログに対する気持ちがフェードアウトしていきました。

そこで今回は、本当に伝えたいことを伝えたいタイミングでできるように設計しました。設計と言っても、過剰なノルマを持たないというシンプルなものです。 いろいろな人の目に留まるエンジニアリング記事を書くことは想定以上に大変です。特に個人でブログを通じて情報発信しているエンジニアが少ない弊社では 社外の人に見られるような記事を書くことが新鮮という組織固有の問題もあります。

そこで、サイト全体で月1本という、一見かなり低いKPI設定をすることにしました。エンジニアリング記事を書きたいという社員が 20人程度いると考え、1人あたり年1本書くかどうかというところに設定をしました。

書きたい人を中心に書いてもらう

企業のブログで記事を書きたいかどうかは個人の希望により人それぞれです。 個人の希望を尊重して、記事を書きたい人が記事を書くことで、よりよいコンテンツを提供しようと考えました。 記事を書きたくない人はそれ以外の業務でパフォーマンスを出してもらうようにします。 それが40人いる社員のうち、記事を書く人は20人くらい(上述)になるという算段です。

記事ワークフロー整備

まず、ブログシステムとして2014年当時はコーポレートサイトの一部としてWordPressを使わなければなりませんでした。 また、実際のオペレーションもアイリッジ社内のGitの導入状況も進行中であり、 Static Site Generator (静的サイトジェネレーター)も今ほど認知されていなかったため、 部署のグループアドレスへのメールベースでのワークフローを利用していました。

非常に効率が悪かったため、Git、Merge Request (GitLabにおける、GitHubなどでいうPull Request相当の機能) を用いたレビューとそれに続くCI/CDのワークフローを整備しました。

この3年の間にアイリッジの開発フローはめざましく進化を遂げ、Gitによるソースコード管理はもちろんCI/CDができるようになってきましたので、 エンジニアリングブログもコアサービスと同様にコードレビュー/CI/CDを実践することにしました。また、インフラには弊社構築システムで 実績のあるFirebase Hostingを使うことにしました。

  • Hugo (ブログシステム)
  • GitLab (コードレビュー)
  • GitLab CI/CD (継続的デリバリ)
  • Firebase Hosting (ホスティング)

その結果、以上の技術を使うことにしました。 TLS 1.0/1.1の無効化/PWA (Progressive Web Apps) なども取り入れたかったのですが、時間的な制約もあり、 今後のタスクとしました。

まとめ

以上、アイリッジのエンジニアリングブログを再始動するにあたり思いを書いてみました。 書き足りない部分もありますが、長くなってしまったので、このあたりで終えたいと思います。

弊社では社外勉強会・カンファレンスへの参加を推奨しており、本ブログの執筆エンジニアとこのブログをご覧いただいているみなさんとが オフラインでお会いすることもあるかと思います。 その折に、オンラインで書かれている内容をネタにきっかけに盛り上がっていただけるようやっていきたいと思いますので、今後にご注目ください。