技術的負債を返済するための3つのアプローチ
まず和田卓人氏は、事業とシステムとの間の乖離から生まれる技術的負債を返済するためのアプローチとして、リファクタリング・リアーキテクティング・リプレイスを挙げた。
リファクタリングがコードを末端からコツコツと綺麗にしていくローリスク・ローリターンなアプローチであるのに対し、対称的なのがリプレイス（リライト）。このシステムはダメだと判断したら、リセットしてゼロから書き直すため、一般的には成功確率は非常に低いアプローチだと言われていると、和田氏は説明する。
「リプレイスは手を出すと非常に痛い目を見ることが多いハイリスク・ハイリターン。そこで、全部リセットしてゼロから書き直すのではなく、大きいものを小さいものに分割しながら、段階的に置き換えていく中庸なアプローチが必要になってきます。それがリアーキテクティングです」（和田氏）
この3つのアプローチに関して、VOYAGE GROUPの事業会社がどんな戦略で立ち向かっていったのか。「fluct」「ECナビ」「サポーターズ」というサービスのシステムをもとに、具体的な事例が語られた。
大規模システムを止めずにリアーキテクティングを実現
fluctはWebメディア向け広告配信サービス。メディア側で利用するSSP（Supply-Side Platform）と呼ばれる広告配信システムを提供している。月間広告配信330億imp以上、1万サイト以上に利用されている。
fluctの事例を紹介したのは、ローンチから10年近く携わっている須藤洋一氏。仕事も育児も全力投球、Go、Erlang、Perl、PHP などを使い、バックエンドからUIまでこなすエンジニアだ。
fluctでは、新しい機能を追加する際に、旧システムの一部を移し替えている。つまり、どの広告枠に何の広告を出すかという広告配信設定に対して、リアーキテクティングを行っている。
当時の広告配信設定は、バイナリシリアライズフォーマットで書かれた約1GBある設定情報にスキーマがなく、データを使う広告配信サーバーのソースコードを見ても、データの中身がわかりにくい状態だった。
「そこで、Protocol Buffersというバイナリシリアライズフォーマットで、スキーマ定義言語で隙間を定義。一部のデータ新しいものをProtocol Buffersで書いたスキーマに基づいて、シリアライズしてファイルを作りました」（須藤氏）
この対処法で、広告配信サーバー側でどんなデータが入っているかわかるようになり、スキーマに対して単体テストも行えるようになった。
「設定情報ファイルが約1GBくらいあったこと、配信サーバーがたくさんあることの複雑さを解消するために、新旧両方の設定を並行稼動しながら、少しずつ置き換えていきました」（須藤氏）
fluctが多くのサイトで使われているサービスであるがゆえに、サービスを一切止めずに修正を加えていく必要があったのだという。
「高い信頼性と可用性が求められるサービスにおいて、サービスを止めずに新旧を連携させ、並行稼動で段階的に新の割合を増やしていく。まさにリアーキテクティングですね。fluctは非常に高可用性が求められるサービスですが、それをサービスの停止なしで成し遂げた事例として大変参考になると思います」（和田氏）
