ビッグバン式の全面再構築をせずにレガシーソフトウェアを刷新する

確立された企業のほとんどに、一つはあります。みんなが内心うんざりしているソフトウェアです。遅くて、見た目もひどく、半数の社員は誰も直さなかったバグの回避策を知っていて、それを理解していた唯一の人は2019年に去りました。衝動はいつも同じです。すべて燃やして新しく作り直そう、と。そしてその衝動こそ、たいていの場合、優れた企業が一年と少なからぬ大金を無駄に失う、まさにその道筋なのです。

大規模な作り直しが失敗するのを何度も見てきたので、私はそれに対して反射的な警戒心を持っています。創業者がきしむ受注システムや年代物のシフト管理ツールを見せ、ため息をつき、こう言うのです。「いっそ全部入れ替えたい」と。いつかはそうなるかもしれません。しかし全面再構築、つまり古いシステムを引き抜き、並行してピカピカの新システムを作り、スイッチを切り替える――これはソフトウェア全般で最もリスクの高い動きの一つです。費用がかさみ、約束よりはるかに長くかかり、その間ずっと目隠しで進むことになります。古いシステムが十五年もの間ひそかに処理してきたあらゆる奇妙な例外ケースを、新しいものがすべて拾えることをただ祈りながら。

良い知らせは、ビッグバン式の再構築はほぼ唯一の選択肢ではなく、最善であることもまれだということです。もっと穏やかな刷新の道があります。段階的で、後戻りでき、作業中も稼がねばならない事業に優しいやり方です。本稿はその道についてのガイドです。本当に直すべきものをどう見分けるか、システム全体を止めずに痛む部分をどう置き換えるか、そして全面再構築が本当に正しい判断となるのはいつかを解説します。

ビッグバン式の再構築はなぜこれほど魅力的で、これほど危険なのか

全面再構築が誘惑的なのは、白紙の状態を約束するからです。レガシーの混乱はなく、妥協もなく、最新ツールで正しく作られた新鮮なコードベース。ホワイトボードの上では当然に見えます。しかし現実には、何年も積み重なった業務ロジックを作り直すことに署名しているのです。その多くは文書化されておらず、一部は去った人々の頭の中だけに生きている――その間も時計は進み、請求書は届きます。

より深い罠は並行世界の問題です。置き換えを作る数か月から数年の間、二つのシステムを抱えます。古いほうは今も事業を回さねばならず、新しいほうはまだ準備ができていません。事業が必要とするあらゆる変更は二度行う必要があり、さもなければ新システムは公開する前から現実に取り残されます。チームは両方を生かし続けて燃え尽きます。そして新システムがすべてをこなすまで誰も切り替えを許されないため、早期の成果も、フィードバックも、動く証拠もありません。あるのはただ、たった一度の巨大な、オール・オア・ナッシングの公開日へ向けた、長く不安な待ち時間だけです。

ここには業界でよく知られた言い伝えがあり、それは当然のものです。二つ目のシステム、壮大な作り直しは、見積もりの三倍の時間がかかり、置き換える対象より少ない機能で到着する癖があります。見積もりが外れるのは人々が不注意だからではありません。古いシステムが静かに正しくこなしている小さな事柄のすべてを、最初の時点では誰も見通せないからです。

「レガシー」が本当に意味するもの（古さの話ではない）

私たちはレガシーという言葉を、まるで単に「古い」という意味であるかのように使います。そうではありません。十年動いているソフトウェアの多くはまったく問題ありません。退屈で、安定し、支払い済みで、仕事をこなしています。年数だけでは何かに手を出す理由になりません。この分野全体で最も高くつく誤りは、静かに動いていたものを、古びて見えるという理由だけで刷新することです。

ソフトウェアがレガシーの名に値するのは、それが積極的にあなたの邪魔をするときです。誰も完全には理解していないために安全に変更できないとき。今や依存しているツールに接続できないとき。一人だけがそれを生かし続けられる唯一の人であるとき。あまりに遅く、もろいために、チームがその周りに回避策の一大民間伝承を築き上げているとき。それが本当の定義です。書かれた年ではなく、それが今日あなたに課すコストと、明日へ持ち込むリスクなのです。

何かに手を触れる前に診断する

一行が書き換えられる前に、痛みが実際どこにあるかの正直な地図が必要です。たいていの場合、みんなが嫌うシステムは80パーセントは問題ありません。トラブルはいくつかの特定の場所に集中しています。遅い画面が一つ、壊れた連携が一つ、二重入力を強いるワークフローが一つ――そしてその数か所がほぼすべての苦情を生んでいます。それらを見つければ、プロジェクト全体を見つけたことになります。

それらを見つける方法は、まず技術監査ではありません。会話です。毎日それを使う人々と腰を据えて、どこが痛むかを尋ねましょう。どこで待つのか。何を入力し直すのか。つらいから何を避けているのか。公式システムを回避するために、どこで個人用の表計算をつけているのか。それらの回避策は宝です。一つひとつが、直す価値のある問題を正確に映し出すレントゲン写真です。

• 人々が最も不満を漏らす画面や手順――理論上ではなく、実際の日々の業務において。
• 二つのシステムが互いに話さないために、データが二度入力されるすべての場所。
• 壊れた、あるいは初めから存在しなかった連携。ツール間の手作業のコピー＆ペーストを強いるもの。
• 一人だけが操作や修理の仕方を知っているすべて――あなたの単一障害点。
• 本当に問題のない部分。守って、そのままにしておけるように。
• 現行システムが到底成長して対応できない、来年に事業が必要とするもの。

これを正直に行うと、プロジェクトはたいてい縮みます。「全部入れ替える」と言って入ってきた経営者が、直すべきは三つだと気づいて出ていきます。それは失望ではなく、安堵です。直せる三つのことは、今四半期に終えられるプロジェクトです。全面置き換えは、生き延びられないかもしれない一年です。

ストラングラー手法――一度に一つずつ置き換える

これを安全に行うパターンがあり、少し不気味ですが記憶に残る名前がついています。ストラングラー手法です。絞め殺しの木にちなみます――木に巻きつき、徐々にその構造を乗っ取り、やがて新しい成長が独り立ちし、古い幹が消える、あのつる植物です。ソフトウェアに当てはめると、その考えは見事に実用的です。古いシステムを一度の英雄的な交換で置き換えるのではありません。その周りに新しいものを一つずつ育て、誰も必要としないものが古いほうに何も残らなくなるまで続けるのです。

実際にはこう進みます。痛む部分を一つ選びます。たとえば、みんなが嫌う請求モジュールです。その部分だけの現代的な置き換えを作ります。請求処理を新モジュールへ振り向け、その他すべては古いシステム上で手つかずのまま動かし続けます。しばらく様子を見ます。確かなものになったら、古いシステムのその部分は静かになり、次の部分へ移ります。古いシステムは、一度に叩き壊されるのではなく、ろうそくのように徐々に縮んでいきます。

これが再構築よりはるかに安全なのは、どの一歩も小さく、稼働中で、後戻りできるからです。決して目隠しで進むことはありません。新しい各部分はすぐ実運用に入るので、本当に機能するかをすぐに知れます。何か問題が起きても、リスクにさらしたのは一つのモジュールだけで、事業全体ではありません。直している間はたいてい古い経路へ戻れます。最後に一度の恐ろしい公開ではなく、道中で成果を得られます。そして事業はその間ずっと、いつも通り回り続けます。

そのリズムは実際どう見えるか

1. 1
   最も痛く、最も自己完結した部分を選ぶ

   痛みが大きく、境界がきれいなものが欲しいのです。大いに痛み、他のすべてに指を突っ込んでいないモジュール。それが最初の標的です。
2. 2
   古いシステムの前に薄い層を置く

   小さなルーティング層が、どの要求を古いシステムへ、どれを新しい部分へ送るかを決めます。これが他のすべてを可能にする継ぎ目です。
3. 3
   その一つの部分だけを作って公開する

   一つのモジュールを置き換え、実際の利用者の手に渡し、その一切れの作業だけをそこへ振り向けます。何年ではなく数週間で――しかも残りのシステムは一切動いていません。
4. 4
   安定させてから、次の部分へ移る

   新モジュールが信頼されたら、対応する古いシステムの部分が休眠します。次の痛む部分で繰り返し、進みながら学びます。
5. 5
   空になったら古いシステムを退役させる

   やがてレガシーシステムは、誰も頼っていない状態になります。そのときだけ電源を切ります――静かに、騒ぎなく。重要なものはすべてすでに移っているからです。

再構築と何が違うかに注目してください。恐れるべきたった一度の公開日はありません。維持すべき並行世界もありません。新システムは三週目から本番にあり、自らの存在価値を稼ぎ、あなたに学びを与えています。延び続ける公開を研究室で待っているのではありません。

そもそも置き換える必要すらないこともある

何かを置き換える前に、古いシステムが置き換えを必要としているのか、それとも単に孤島であるのをやめる必要があるだけなのかを問う価値があります。「新しいシステムが要る」という問題の驚くほど多くは、実は「うちのシステムは互いに話さない」という問題です。古いソフトウェアは仕事ぶりは申し分ありません。ただサイロに座り、人々に手作業でデータを出し入れさせているだけなのです。

そうした場合、最も安く速い解決は新しいシステムではありません。橋です。古いソフトウェアを接続で包みます――他のツールと自動的にデータを交換させる連携と、人々が実際に触れる部分のための最新の層を上にかぶせるのです。古びたエンジンは下で動き続け、チームはきれいな表面とコピー＆ペーストの終わりを手にします。華やかではありませんが、取り組み全体で一ユーロあたりの見返りが最も高いことがよくあります。

全面再構築が本当に正しい判断となるとき

このガイド全体で大規模な再構築から思いとどまらせてきたので、公平を期しましょう。ときにはそれが本当に答えです。どれだけ継ぎ当てや橋渡し、一つずつの置き換えをしても救えないほど土台が腐っていることがあり、そうでないふりをするのは、死体を支えるために金を使いながら避けられないものを先延ばしにするだけです。

正直な兆候は具体的です。システムの土台となっている技術が死んでいる、あるいは死にかけている――サポートなし、セキュリティ更新なし、それを扱える者が誰も残っていない。事業が根本から変わり、古いモデルがもはや現実にまったく対応しない。あるいはシステムが絡まりすぎて、小さな変更でも無関係な場所を日常的に壊す――これはたいてい、そもそもストラングラー手法を行うためのきれいな継ぎ目がないことを意味します。これらのうち二つか三つが同時に当てはまるとき、段階的な作業はもはやより安全な選択ではなくなります。

そして、たとえ最終的に作り直すとしても、先に段階的な作業をやっておくことの静かな見返りがあります。そこへ着くころには、最初よりはるかにシステムをよく理解しているのです。置き換えた各モジュールが、元の作者が決して書き残さなかった何かをあなたに教えてくれました。その知識に裏打ちされた再構築は、初日の楽観だけで打ち上げられたものとはまったく別の、はるかに安全な生き物です。

誰も口にしない部分――結局は人がほとんど

技術ガイドが飛ばすことがあります。古いソフトウェアを刷新する最も難しい部分は、たいていコードではありません。何年もかけてそれに適応してきた人々です。彼らはその癖を知っています。その奇妙なショートカットに体が覚えています。客観的に優れた新モジュールでも、最初の二週間はかえって悪く感じられることがあります。単に不慣れだからです。それを無視すれば、完璧な技術移行でさえ失敗しかねません。

段階的な手法は、ここでもほとんど偶然に助けになります。変化が一度に小さな一片ずつ届くので、人々はある月曜の朝にすべてを学び直すよう求められる代わりに、徐々に吸収していきます。日々の利用者を早くから巻き込みましょう。完成前の置き換えを彼らに形づくらせましょう。新しい請求画面の設計を手伝ったチームはそれを擁護し、頭に落とされたチームは、たとえ同一でも反感を抱きます。刷新とは、ソフトウェアの衣をまとった変化管理プロジェクトなのです。

よくある質問