How to create engineer portal site.

リクルートグループ初、エンジニアポータルサイトはどのように企画されたか

Tech Blogをポータルサイトに発展させるには《エンジニアサイト誕生の裏側 前編》

今回から3回に渡って、このリクルートライフスタイルのTech Blog、そしてTech Blogをなどを包括した「Recruit Lifestyle Engineer」サイト(以下、エンジニアポータルサイト)について、企画から実装までの裏側をお届けします。

第1回目は、リクルートグループ初のエンジニアのためのサイト、エンジニアポータルサイトが企画された経緯と意図についてです。

Tech Blogのリニューアル

遡ること6ヶ月前、2015年4月頃、Tech Blogをリニューアルする、という話が持ち上がりました。

2014年11月に旧Tech Blogが立ち上がってから4ヶ月、投稿された記事は4本しかありませんでした。Tech Blogの維持は既に様々な所で議論されているように、とても難しいことです。

どうすればみんながTech Blogを書いてくれるのか……。必死に考えて出た結論は単純でした。

ひとつは、執筆者をしっかりアサインし、書く習慣をつけ、Tech Blogで発信する面白さを知ってもらうこと。

そしてもうひとつが、Tech Blogをリニューアルし、執筆意欲を高めよう、というものでした。

採用サイトのリニューアルとシンクロ

時を同じくして、人事部でもエンジニア採用サイトのリニューアルの話が持ち上がっていました。リクルートライフスタイルには、かつてよりエンジニアのためだけの採用サイトがあったのですが、こちらも活性化が図れていなかったのでリニューアルすることになったようです。

リニューアルに合わせて、Tech Blogと採用サイトを連動させようという企画が持ち上がり、我々Tech Blogを主導しているエンジニアと人事、広報、採用サイトの制作会社の方など、10名を超える人間が集まりディスカッションの場が持たれました。

そこで持ち上がったのが、エンジニアポータルサイトの構想でした。

エンジニアが登壇したイベントやその資料、GitHubなどでOSS化されたプロジェクトのドキュメント、掲載された記事、採用情報、そしてTech Blogなど、リクルートライフスタイルのエンジニア情報がひとまとまりになったサイトです。

リクルートグループでエンジニアのためのサイトは史上初だったのですが、各セクションで協力して取り組むことになりました!

各セクションからの要望

Tech Blogをリニューアルするに当たって、我々エンジニアから持ち上がっていた最重要改善点は、GitHubで記事を編集・管理し、修正点をPull requestsでやり取りできるようにしたいということでした。GitHubで管理するということは、記事は必然的にMarkdownでの記述になります。

旧Tech BlogはWordPressで構築されていたのですが、エンジニアがTech Blogを書きたくない最も大きな理由が、そのCMSでした。わざわざ使い慣れたエディタからブラウザのエディタに移り、修正点をメッセンジャーでやり取りして公開する……。極めて非効率です。

しかし問題が生じました。Tech Blogは公開前に一応、広報セクションの確認を取る必要があるのですが、彼らは基本的にGitもGitHubも使えません。また、人事セクションも求人情報を更新する可能性がありました。

そこで、GitHubからWordPressに対して記事データをデプロイするようにしようかと考えましたが、スマートじゃない!

Middleman + GitHub + Jenkinsで擬似CMSを構築

色々調べまして、今回のような場合は、静的サイトジェネレーターとGitHubの組み合わせで幸せになれるのではないかと思いつきました!

GitHubの説明をすると、広報セクションや人事セクションの方も、ブラウザでの操作で直接ファイルを編集しエディタとして使ってもらうだけならできそうだということがわかりました。

参考にさせてもらったTokyo Otaku Modeさんでは、Node.jsベースのHexoという静的サイトジェネレーターを使っているようでしたが、今回はRubyベースのMiddlemanというものを使うことにしました。

GitHubとMiddlemanを単純に組み合わせて使うだけで、CMSの基本機能である動的ページ生成とエディタは再現できました。

CMSにある機能でまだ足りていないのは、プレビュー機能です。静的サイトジェネレーターの場合、buildしてプレビューするためにはローカル環境構築をしなければなりません。

これをなんとかブラウザのみで完結するために、サーバを3つ用意し、JenkinsでCIツールを作って指定したブランチをbuildするようにました。master、prev、devの3つです。

masterは本番サーバです。masterブランチをbuildしたデータが格納されます。

prevは、masterに公開する直前に最終確認するためのサーバです。previewブランチをbuildしたデータが格納されます。prevを挟むことでいま公開しようとしている記事だけを追加した場合を確認できます。

devは、下書きとその確認を行うためのサーバです。「articles/2015-01-01-***」というような名前のブランチの記事すべてがpushする度buildされるようになっています。

prevやdevサーバでもURLが生成されるので、メッセンジャーなどで共有することもできます。セキュリティのため、prevとdevにはIP制限をかけてリクルート社内および特定の場所からのみアクセスできるようにしました。

既存記事のMarkdown化

WordPressで書かれた旧Tech Blogの記事を移行するに当たって、Markdown化する必要に迫られました。

これについては、構造を整理し直したり、リンクを貼り直す必要があったため手動で行いました。

4記事だけだったので、可能だったが、数が膨大な場合はMarkdown化するツールなどを使うと楽かもしれません。

次回の記事では、具体的にMiddlemanでの実装をコードを交えつつお届けします。
さらに次次回の記事では、JenkinsとIP制限を施しているGitHub Enterprise、AWSの繋ぎこみとbuildする上での注意点などをお届けする予定です。

お楽しみに!

Tech Blog

(編集部)

株式会社リクルートライフスタイルのTech Blog編集部です。いま流行りのTechネタやちょっと使えるTipsなどをお届けしていきます。

NEXT