さて、前回からの続き。

社運をかけて招集された nowa の開発チームは、プログラマ、ディレクター、デザイナー、マークアッパ、どれをとっても精鋭チームというべき豪華な面子が勢揃いしていた。

一方の「旧ブログ」チームは、それまで一人でブログを支えて続けていたベテランのエンジニアが辞め、あとを僕ともう一人とで継いだものの、その片方の人も別会社に移って行ってしまって、エンジニアは僕一人だけになっていた。マネタイズのプランもなくただの金食い虫だった「旧ブログ」には大した長期戦略も与えられず、広告営業案件の狩り場と化して、宣伝用のブログパーツばかり作らされていた。

基本的に旧ブログチームの役割はディフェンスで、フォワードの nowa チームが次世代ブログを立ち上げ、準備が万全になるまで、ライブドア最大の資産である現行ブログのユーザとコンテンツを守りきるのが僕らの役目だと考えていた。

ただこの時点で、先に挙げた nowa 開発理由のいくつかには気になる部分もあった。
プロダクト自体は悪くないと思った。企画も、システムの設計も。
  • ただ、これは現行ブログとは全く違ったサービスになるだろう。違うものでなければ新しくつくる意味はないし、だからこそ、現行ブログのユーザを全移行させるというプランとは相性が悪い。

  • ターゲットが異なるのであれば、nowa のユーザは現行ブログからの移行組に頼るのではなく、新規に開拓する必要がある。確かにライブドアというブランドは現状役に立たなそうだけど、かといって、「8ヶ月で50万ユーザ獲得」とぶち上げた目標は、何のプロモーションもなしに達成できる規模のものだろうか?
    ライブドアは実はプロモーションはあまり強くない。「精鋭チーム」と言っても、内訳は皆ものを作る職種の人達ばかりだ。nowa に限らず、この会社は「いいものをつくっていればユーザは自然に集まってくる」という仮定に頼りすぎている気はずっとしていた。
    (皮肉なのは、これが、ライブドアを虚業と批判していた人達の考えていたライブドア像とは真逆なことだよね。)

  • 一から作り直せば色々なことが解決するというのは、たいていの場合、幻想だ。そのメリットとデメリット、そして本当に一から作り直すしか手はないのか、の見積もりにはまだ見落としがある気がした。



そこで、ディフェンス業務の合間を縫って、まず「どのページが更新されたら、どのページとどのページを連動して更新しなければいけないか」を算出するメソッドを作るところから、徐々にシステムの改造をはじめていった。全再構築をしなくても関連するページが同時更新されるようになって、リンク切れは徐々に減っていった。

次に、あちこちに散らばっていたファイル書き出し機能を一カ所ににまとめ、htmlのレンダリング機能と、ファイル書き出しの機能とを分離した。そうすることで、レンダリングの結果をその場で表示する(動的)のも、ファイルに書き出す(静的)のも、キャッシュに一時保存するのも、全て同じところで処理できるようになった。

そうして、段階的にブログエンジンを動的化するプロジェクトがはじまった。

最初は記事更新時に html を書き出し、閲覧時はそれを読み出すだけだったのを:

rebuild3

まず第一段階では、閲覧頻度が低いファイルの書き出しをサボって、オンデマンド方式にした。更新時はファイルを書き出すこともあるし、消すだけのこともある。最初のアクセスの時にもし目的のファイルがなければ一回だけ動的生成、以降はその時に書き出したファイルを参照する。

rebuild4

再構築の大部分がファイルを消すだけの処理になったため、この時点で再構築が爆速になった。

第二段階では、これを全ページに適用し、書き出し先をファイルではなくキャッシュにかえた。これにより、記事更新や再構築は、ただのキャッシュを消す処理に置き換わった。

rebuild5

キャッシュをグループ化して管理する方法や、動的化に伴う負荷対策についての膨大な技術的あれこれについてはここでは省略するが、この作業が完了した時点で、livedoorブログは事実上、動的生成エンジンに生まれ変わっていた
livedoor Blogの挑戦:再構築をなくします! 第三弾(完)(2008年8月)
なんかノリが徹夜明けっぽいけど、徹夜明けかなこれ…

そして最後に、管理画面が完全にリニューアルされた。新しくなった管理画面には、もう「再構築」の文字はどこにもなかった。
生まれ変わった「livedoor Blog」と、ちょっとしたスタッフロール (2009年1月)



この頃までには、僕一人だった開発担当は 8人ぐらいのチームへ変わっていた。

大型のネットワークストレージがキャッシュサーバ群に置き換えられただけではなく、画像専用のストレージも内製の分散ストレージに置き換えられた。文字コードも、EUC から utf8 へと変わった(※1)スパムフィルタを強化して不要な負荷が排除された。また、メンバーIDとブログIDを分離することにより、同じシステム内に他社向けのブログを同居させてasp提供できるようにもなったし、一人で複数のブログを管理することなども可能になった。

10万行近くあるブログのコードの半分以上は書き替わったと思う。

逆に言えば、それでも半分近くの、特に基本的なクラス構成は、オリジナルの構造を保っていた。 5年も前の基本設計がそのまま残るというのは、webアプリケーションの世界では大したものだ (※追記:そんなに古くもなかったらしい)。家のリフォームで言うなら、それはとても古い家だったけれど、屋台骨はしっかりとしていたので、匠は屋台骨を再利用し、それ以外の外装と内装を全て作り替えたのだ。
そして、なんということでしょう、誰もがもう捨てるしかないと思っていたブログシステムは、ユーザ移行も長期メンテもせずに2010年代のモダンなシステムに生まれ変わったのでした。



開発者なら誰しも一度は「あー、もう全部捨てて一から作り直したい!」と叫んだ経験があるだろう。
その選択が正しいことも勿論あるのだが、多くの場合、それは期待しているほどの「銀の弾丸」ではない。作り直すうちに、結局過去と同じような道を辿り、過去と似たような問題が発生し、時間とコストだけかかってだいたい元と同じ程度にしがらみを抱えたコードが完成する。そしてその間は、外から見るとただの停滞期間だ。重要なのはしがらみを捨て去ることではない。そのしがらみをいかに受け止められるかだ。

プロの道は、自身の「一から書き直したい衝動」をどれだけ客観的にコントロールできるか、本当にコストをかけないといけない重要なものが何なのか見極められるかどうかの道であると言っても過言ではない。

そしてライブドアにとってその重要なものとは、ライブドアブログの何百万かのユーザ (と、コンテンツ) だった。そのユーザを別なサービスにまとめて強制移行させるというのは、ちょっと大雑把すぎるプランだったと思う。
(いや、僕もけっこう一から書き直しちゃうタイプなんだけど、それに対するユーザ側のコストの見積もりにだいぶ誤差があったんじゃないかな…)

こういう時に僕がよく使うのは、(家のリフォームじゃなくて) 列車と乗客のたとえだ。

たくさんの乗客を乗せて走っているライブドアブログという列車がある。ただ、牽引しているのは老朽化した蒸気機関車で、そろそろ車体を新しくしないといけない時期に来ている。
nowa 移行プランとはつまり、次の駅に最新式のピカピカの電車を用意しておいて、そこでいったん乗客をおろし、隣の新しい電車に乗り換えてもらう、という話だった。

ここで注意したいのは、乗客達は、列車が走り続けているかぎり気軽に列車 (サービス) を乗り換えることはないということ。ただ、一度プラットフォームに降りる機会を与えてしまうと、そのままふらっとどっかへ消えてしまって、元の列車にも新しい列車にも乗ってこない可能性が少なからずあるということだ。

乗客を下ろさないようにするためには、とにかく列車を走らせ続けることが第一だ。ただ、かといってあまりにも設備がオンボロなままだとさすがに列車を乗り換える人も出てくる。
それを解決するために僕らが選択したのは、列車を走らせたまま車体をリニューアルする、という手法だった。アクロバティックな手法ではあるけど、こちら側が手間をかけることで、乗客側の手間は0にすることができる。

まず、蒸気機関車の動力をまるごと入れ替えた。外側は蒸気機関車の見た目のまま、乗客には気づかれずに内部だけ最新式の電気機関に置き換えたのだ。(それなんて銀河鉄道999?)

次に、今度は中身をそのままにして、外装だけ最新式のピカピカの車体に取り替えた。

結局乗客達は一度も席を立つことのないまま、気がつくと、旧式の蒸気機関車に乗っていたはずがいつの間にか最新式の電車の客室に座っていた。


この列車は少なくともあと何年かは問題なく走り続けられる。走らせながら車体を交換する技術も身につけたから、こまめに交換を続ければ半永久的にだって走り続けられるだろう。

確かに車体の性能だけでいえば、隣のホームに止まっていたあっちの最新式の(からっぽの)電車の方が上だったかもしれない。でももしあの駅で「この列車はここで車庫に入ります。先へ行くには隣の列車に乗り換えて下さい」とアナウンスしていたら、たぶん乗客の半分は、そのままその駅で降りてしまっていたんじゃないだろうか。

およそたいていのことは、技術で実現できる。でもユーザを集めてくることは、技術だけでは無理だ。
(エンジニアリングの良し悪しと、サービスの成功不成功にあまり相関性がないというのの最たる例が、初期の Google の話だろう。)



さて一方、立ち上げ直後から nowa は、ドリームチームゆえの「船頭多くして船山に登る」という罠にはまっていた。次世代ブログというものについて、皆がそれぞれ少しづつ違ったものを思い描いていた。その後、開発は良い速度で進みはじめたけれど、フォーカスと、それから肝心のユーザを集めてくる見通しには欠けていたと思う。

「8ヶ月で50万ユーザ獲得」という目標の達成は、案の定絶望的だった。(※2)

それに加え、現行のブログシステムが老朽化していて後がない、という前提が覆ってしまったことで、nowa の開発を継続する必然性は少なからず失われてしまった。

まあ、同じコンセプトで先行した VOX も失敗したことを考えると、ライブドアという組織に特有の問題があったのではなくて、単純に企画が時代にあってなかったのが大きいのかなと思う。

新規開発をいったんやめ、「波」がくるまで粘り強く運用を続けていれば巻き返しのチャンスはあったかもしれない。ただ、既にサーバ台数は最小コストで維持できる閾値を超え、稼働させるだけで毎月コストがかさんでいく状態になっていた。飛行機で言えばすでに離陸決定速度 (V1) を超えてしまっていた。やめるか、やってブレークさせるか、の二つしかもう選択肢は残されていなかった。



ここまでが、「旧ブログ」チームのエンジニアとしての僕から見た nowa の話だ。こっちに nowa チームだったエンジニアの回想もある。

ただし、当ブログも上の @kyanny のブログも、どちらもエンジニア視点で書かれたもので、経営上のハイレベルなディシジョンについての知識は抜け落ちていたり誤解していたりする可能性があることはあらかじめ補足しておきたい。開発部自体がサービスを作ったりやめたりする判断をすることはない。

もうすこしビジネス上の上位レイヤーを含めた事情を知っている @sasakill が近々失敗カンファレンスで nowa についての話をするらしいので、彼がそこでどういう話をするのかたのしみである。



ちなみにアメーバなうがでてきたとき、ちょうどエイプリルフールの時期だったのでその企画として一日だけ nowa を復活させ、nowa のロゴの a だけ黒塗りで消して「うちも『now』作りました!」ってリリースを出すというアイデアも出ました。

実は密かに「あれ?久しぶりに使ってみたら nowa 結構アリじゃね??」みたいな声がユーザから沸き起こって、なし崩し的に nowa 復活!!…みたいな筋書きも空想してたんですが、アホみたいなのでやめろっておこられてボツになりましたとさw


--

※1 実はある時点から、新しく作られるブログの文字コードは euc-jp から utf-8 に変わった。いまでも、古くからある euc-jp のブログと新しい utf-8 のブログのデータが内部で混在している。抽象化レイヤを一枚かませることで一緒に扱うことができるようになっているのでけっこう技術的に面白いところなんだけど、リンクできる資料がないな。これは社内勉強会ぐらいでしか表にでてないんだっけなぁ…

※2 「8ヶ月で50万ユーザ」という目標設定が最初からピントを外していた件に関しては昔ここにも書いた
ちなみにこの「8ヶ月で50万ユーザ獲得」という無茶ぶりを背負わされたディレクターの主な一人は色々と面白い人で、主に馬鹿関係の担当業務のほか、四コマ漫画化ネタとかバカ日本地図とかでも有名だ。
ただ、10万人規模までのニッチで面白いサービスを作る人と、100万ユーザ超のメインストリームのコモディティを作る人は、別なんじゃないかって気はするなw
nowaはそんなに馬鹿っぽくなかった。

※追記 実は2005年頃にいちど大リニューアルをしてコードは書き直されていたらしい。まあ僕はブログ担当としては3代目だか4代目ぐらいなのでね、サーバ1台からスタートしたというライブドアブログの壮大な叙事詩の中では、ここに書いた出来事はほんの小事件にすぎない。でもまあ、そのあたりは nowa との対比という話から外れるし、もっとふさわしい人達が別に書いてくれると思うのでそれに期待しよう。