DeNA Engineers' Blogをリニューアルしている話

@mazgiです。
これはDeNA Advent Calendar 2018の3日目の記事です。

せっかく社のBlogを書くことになったので社のBlogリニューアルについてご紹介します。 今日2018/12/03現在みえているこのBlogのリニューアルを「Engineers' Blog編集委員会(仮)」という有志の横断的な組織で進めていてだいぶ形になってきました。
(Advent Calendarには間に合いませんでした)

きっとこんな見た目になります!
we-just-building-new-dena-engineers-blog.screenshot.png

技術Blogやオウンドメディアの長期運用あるあるな話としてどなたかのご参考になればという気持ちで書かせていただきます。

なぜリニューアルするのか?

リニューアルする理由をざっと書き出すと次の3点です。

  • もっと活性化してほしい
  • 機能追加やシステム更新がつらくなってきた
  • オンプレミスでのセルフホスティングをやめたい

順にご説明します。

もっと活性化してほしい

今のこのBlogはMovable Type製なのですが、全社員にアカウントが払い出されているわけではなく、初めて記事を書くときにBlog専用アカウントを申請する運用になっています。
また書いてから公開されるまでのフローは整備されてはいるのですが当事者以外からはなかなか知ることができず、その結果新たに「Blogを書いてみようかな」と思ったときに「どうやって書くんだろう?」「どういう内容ならOKなんだろう?」「誰にレビューお願いすればいいんだろう?」といった疑問が心理的障壁になっていることがわかりました。

これを解消するため前述の「Engineers' Blog編集委員会」で「もっと気負わず思いついた時に誰でも記事を書けるようにしたい!」と話し合いました。

機能追加やシステム更新がつらくなってきた

DeNAは元々腕利きのPerl Mongerな方々が集まっていた会社でもありこのBlogのシステムは2010年頃にMovable Typeで構築されたようです。
ところでDeNAは来年2019年で20周年だそうです。IT企業として20年、すごいですね!老舗ですね!
この機会に技術Blogもシステム刷新してもいいのではないでしょうか?

前述の活性化を行うにしてもイマドキな方が色んな方に書いていただけそうですし、長く運用できそうです。
Blog編集委員会では「新し目で運用負荷低い仕組みを目指しましょう」と話し合いました。

オンプレミスでのセルフホスティングをやめたい

20世紀からWebサービスを作っておられる多くの会社がそうだと思いますが、DeNAもオンプレミスとパブリッククラウドを併用している会社です。
しかしこの度パブリッククラウドに完全移行することが決まりました :tada:
ところで2010年頃に構築されたBlogのサーバーは? ...オンプレミスです。移行しましょう!

編集委員会でも「パブリッククラウド上でサービスするのは当然としてインスタンス立てたくないね」と話し合いました。

ちなみに全社インフラのクラウド移行については弊社オウンドメディア@ITでも記事にしていただいていますのでご参照ください。
また、2019年2月のTechConでも紹介される予定ですのでこちらもぜひご参加ください。

どうやってリニューアルを進めているか?

先ほど上がった理由をブレイクダウンし、それぞれの課題を解決する方法を考えていきます。

どうやってもっと活性化しやすくするか?

まず、Blogシステムの概観をどうすれば活性化しやすいくなりそうか話し合いました。

世の中には色々な素晴らしいBlogサービスやCMSが存在することも改めて確認し、同時にエンジニアリングやデザインのリソースが少し取れそうだったので自前実装という道も生まれました。
これらの状況を加味した上で自由度とセキュリティ担保や今後の運用とを秤にかけ「薄く自前実装しよう」という方針が決まりました。

それが今の私たちにとって、システム面でも文化や雰囲気の面でも、もっともバランスの良い形に思えたのです。

まず"書きやすいシステム"にする

技術Blogの主なWriterとなるエンジニアが"書きやすいシステム"について考えた結果以下を決めました。

  • 普段使っているGitHub(Enterprise)に集約しよう
    • 記事内容はもちろん、記事執筆のフローもGitHub的にしよう
    • Pull Request -> Review && Merge -> CI/CD で記事が公開されるようにしよう
  • Markdownで書けるようにしよう
    • フォーマットの好みは色々あれどMarkdownは大抵の人が書いたことあるはず
  • 社内向けBlogを併設してもっと気軽に記事を書けるようにしよう

GitHubへの集約ですが、この画像のようなリポジトリのmasterにMarkdownで書かれた原稿がMergeされると公開されるようにしました。
(Private Repositoryですが全社員がメンバーとして設定されています)
we-just-building-new-dena-engineers-blog.0090.png

レビューは何かを開発するときと同じようにPull Request上で行えますが、Push毎にこのように記事をプレビューできる専用のURLが発行されます。
we-just-building-new-dena-engineers-blog.0050.png

このプレビュー用URLは社内から誰でも閲覧できるので例えば法務や広報といった、GitHubアカウントを持っていない方にもレビューに参加していただけます。

最後の「社内向けBlog」については、「『社名とともに世界に公開される』と考えると気後れしてしまうかもしれないけど、社内限定公開なら何書いても恥ずかしくないよね!」という気持ちで作ることにしました。

  • 「内容軽すぎない?」=>「1 tip(s)だけでも大丈夫です、社内限定公開なんで」
  • 「これ社外秘かも...」=>「社内の人が知ってて大丈夫なら書いて大丈夫です、社内限定公開なんで」
  • 「社内のあれこれ知らないと伝わらない」=>「読む人みんな知ってるので書いてください、社内限定公開なんで」

という感じで記事を書くハードル下げられるといいな!と思ってます。
社内向けBlogも公開Blogもリポジトリが異なるだけで仕組みや原稿フォーマットは一緒なので、社内限定記事を公開記事に変換する時はリポジトリ間でファイルをコピーするだけです。
社外秘な社内限定記事は後日社外秘じゃなくなるように編集して公開すればいいですし、社内知識が前提となっている社内限定記事は先に社内知識を説明する記事を公開すればいいですよね!

"書きやすい雰囲気"にする

DeNAで掲げている「DeNA Quality」の1つに「透明性」があります。
言葉通り「正直でオープンなコミュニケーション」を是とするいたって真っ当な姿勢なのですが、今回の一連のBlogリニューアルの動きとしてもこの「透明性」を強く意識しています。

リソースのほとんどはGitHubに集約され、全社員がアクセスできます。
we-just-building-new-dena-engineers-blog.0030.png

タスク一覧や進捗はGitHub Projects(カンバン)上で公開されており、自由にカードやIssueを作ることができます。
we-just-building-new-dena-engineers-blog.0040.png

SlackでのやりとりもPublic Channel上で行われ、
we-just-building-new-dena-engineers-blog.0080.png そのままでは流れ去ってしまうSlackコメントは必要に応じてGitHubのIssueコメントとして蓄積されます。
we-just-building-new-dena-engineers-blog.0081.png そしてGitHubでのコメントや色々なアクティビティはSlackのPublic Channelに通知されます。
we-just-building-new-dena-engineers-blog.0082.png

DeNAでは開発業務に従事していない方などGitHubアカウントを持っていない方もいるのですが、Slackアカウントは全員が持っているので、誰でもこれらの情報にアクセスしコメントすることができます。

こうやって記事やレビュー内容だけに留まらず経緯までオープンかつ正直に残しておくことで、今だけではなく将来にわたって「あ、こんなカジュアルでいいんだ」と感じてもらえたらいいな!と思っています。

どうやって機能追加やシステム更新を行いやすくするか?

まずどんなシステムにしてどんなサービスを使ったところで、そのままではいずれ機能追加が行えなくなり更新がつらくなると考えています。
それはきっと避けられないのでしょう。

なのでせめて2018年に考えられる継続的にアップデート可能な"オープンな普通の仕組み"を作ろうと努めました。
具体的には以下のツールやサービスを組み合わせてBlogを構成しました。

HugoとTerraformはOSSですし、その他のXaaSはどれも有名で調べればすぐに情報が得られます。
また2030年くらいまでにはBlogのリニューアルが避けられなくなるかもしれませんが、むしろもっと短いイテレーションで頻繁にシステム構成自体を再考し更新し続けられたらうれしいですね!

パブリッククラウド上でどのような構成にするか?

今からオンプレミスのサーバーを新規構築しないのは当たり前として、Blog編集委員全員に「インスタンス立てたくない!」という強い気持ちがあり、サーバーを立てない前提で話が進みました。
これだけ色々なマネージドサービスが提供されている2018年にBlogのためにサーバーを運用するリソースはもったいないですね。
そのリソースはDeNAのサービスを使ってくださっている皆さまのためにもっと違う形で使いたいものです。

構成は前述の通りなのですが、それぞれ以下のような点を考慮しました。

Markdown

平易なテキストフォーマットなので他のシステムへの載せ替えも容易。

Hugo

Apache 2ライセンスのOSSでライセンス上の検討事項が少ない。
Golang製でバイナリファイル1つで動く。バイナリさえ保持しておけば先々「本体は入手できてもライブラリが入手できない」といった事態を避けられる。

GitHub Enterprise / CircleCI Enterprise

DeNA内で標準的に利用されており世間的にもデファクトスタンダードと言える。

Terraform

MPL 2ライセンスのOSS。
Hugo同様Golang製でバイナリファイルといくつかのモジュールだけあれば動く。
IaCのとても著名なツールと言え情報も多い。

AWSの各リソース

AWS自体はいうまでもなく世界有数のクラウドサービスプロバイダで情報が大変多い。
もちろんDeNA内でも広く使われている。

Blog閲覧時のアクセス経路は、公開/社内向けそれぞれ以下の通り。

公開Blog: Browser -> CloudFront -> S3
社内向けBlog: Browser -> CloudFront -> WAF -> S3

更新時はCircleCI上でHugoにより生成されたHTML, CSS, JavaScriptなどをS3にアップロードしている。

さいごに

いちばん最初に載せさせていただいたかっこいいBlogテーマはデザイン担当の方が作ってくださいました!
(かっこいいので再掲)
we-just-building-new-dena-engineers-blog.screenshot.png

Blogリニューアルの初期は仮テーマということにして私が作ったテーマで実装してたんですけど、見比べていただけるとどれくらいかっこよくしていただいたかわかると思います(

そして残タスクはデータ移行。。
どんなシステム刷新も最後に残るのはデータ移行ですね。
完全な自動マイグレーションは難しそうなので今色々とディスカッションしてます。
we-just-building-new-dena-engineers-blog.0010.png

DeNA「Engineers' Blog編集委員会(仮)」ではこのように技術Blogのリニューアルを検討中です :muscle:
Slackでコミュニケーション取ったり、
we-just-building-new-dena-engineers-blog.0020.png 意見はフィードバックいただいたり、
we-just-building-new-dena-engineers-blog.0070.png we-just-building-new-dena-engineers-blog.0060.png オフラインで集まったり、 we-just-building-new-dena-engineers-blog.0100.jpeg

進めていますので次は「リニューアルしました!」とご報告できることを楽しみにしています。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る