「レガシー」なシステムと戦うために必要なのは、「技術」だけではない

こんにちは、エンジニアのgamiです。

ソフトウェア開発の世界にいると、「〇〇というシステムはかなりレガシー化している」といった言葉を耳にすることがよくあります。実際に過去に僕自身が関わったシステムにも、これは「レガシー」と言えそうだぞ、というものがいくつかありました。（それはそれはレガシーだったのですが、語ると長くなるので別の機会に。）

一方で、あるシステムが「レガシー」かどうかを定量的に評価する標準指標のようなものが広く普及しているわけでもありません。ソフトウェア開発に関わったことがない人からすると、「レガシーシステム」とはどんなもので、何が問題で、どう対応すればいいのか、というのがわかりにくい状況であると感じます。

もちろん、そもそも問題が無ければ対処する必要もありません。しかし、たとえば経産省が公開しているDXレポートでは、「約7割の企業が老朽システム（レガシーシステム）がDXの足かせになっていると感じている」とされています。

（DXレポート 経済産業省）

最近、僕は『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』という本を読んでいます。VOYAGE GROUPのエンジニアたちが、数ある自社システムの開発や運用について話した、非常に現場感ある対談が6つ収録されています。中でも、第3章の「VOYAGE MARKETING - 20年級大規模レガシーシステムとの戦い」（以下、「VOYAGE MARKETING」）では、レガシーシステムの一例とその戦い方が詳しく描写されていました。まさにレガシーシステムとは何かを理解するための教科書として使えそうな内容です。

今回は、この「VOYAGE MARKETING」をガイドラインにして、レガシーシステムとは何かについて考えていきます。

「レガシー」なシステムとは何か？

「VOYAGE MARKETING」では、「ECナビ」にまつわるシステムが「レガシー」として取り上げられています。そのレガシーさは、たとえば次のように表現されています。

・日本のネット黎明期からずっと続いている老舗のサービス
・テーブル数にして1200という巨大で複雑化したレガシーシステム
・「システムを全体的に把握していた人は、誰もいませんでした」
・「既存のシステムを変更していこうと思うと、既存の領域を入念に調べ上げないといけない。しかし、それだとスピードが出ないから、既存は修正せず、機能追加していく」
・「（事業拡大の）歴史による技術的負債が、いまのビジネスに顕著に負の影響を与えており、事業課題として認識されていました」

まとめると、「歴史的経緯によって、システムが巨大化複雑化し、全体を把握できなくなった結果、場当たり的な機能追加が行われるようになっている状態」といった具合でしょうか。システムとは当然「作って終わり」ではなく、事業の変化にともなって新機能がどんどん追加されていきます。その中には当初の予定にはない機能も多く含まれ、初期のシステム設計では想定されていないような発展の仕方をすることもあります。使われ続けるシステムというのは、「その機能群を実現するシステムをゼロから作ったらこうなる」という理想状態からどんどん乖離していく宿命を抱えています。その乖離が大きくなりすぎた状態が、「レガシー」と形容されるシステムの一般的なイメージです。

さらに、レガシーシステムの何が問題であるかについては、次のようなエピソードが紹介されています。

「収益が上がるからこういうサービスを作りたいけど、実現する方法はありませんか」という話を開発に持ちかけたら、それに対して「〇〇という技術的要因で困難」とか、「それをやるには目玉が飛び出るような工数が必要」とか、「現状がこうだから不可能」とか。レガシーシステムを抱える現場で交わされるやり取りが日常的にありました。

レガシーシステムの大きな問題点は、「既存のシステムに悪影響を与えずに新機能を開発するためのコスト」が膨れ上がっていくということです。気付かないうちにジワジワと開発スピードが落ちていき、身動きが取れなくなっていくわけです。

「どこから手を付けるか？」という大問題

「VOYAGE MARKETING」では、レガシーシステムが目指すシステムの理想状態について、たとえば次のように書かれています。

・次の5年のビジネスを止めないシステム
・カオスなアプリケーション群をどうダイエットするか

レガシーシステムの克服では、ビジネスの拡大を止めないために、巨大化複雑化したシステムをどうダイエットするかを考える必要があります。もちろん、「運動したら痩せる」というような単純な話にはならず、事業や機能を整理しながら、無駄な部分を消していき、必要十分なサイズのシステムに徐々に作り変えていくというプロセスを踏むことになります。

一方で、全体を把握できなくなったレガシーシステムは、「どこをどう変更したら壊れるかよくわからない」という恐ろしさを抱えています。その不確実な恐ろしさを前にして、どのようにレガシーと戦っていけばいいんでしょうか？

この「レガシーと戦うときに何から始めるべきか？」という点がかなり具体的に書かれていたのが、「VOYAGE MARKETING」の最も価値ある情報だと僕は感じました。この本の中では、ECナビの開発チームが優先度高く取り組んだこととして、次の2点が挙げられていました。

1つは、ひたすら「現状把握」をしにいったということです。

具体的には、一般的なサーバーの構成図やネットワークの構成図を描き、サーバーごとの役割を解き明かしていくという作業です。さらに、その中で実際にどのようなサブシステムが動いているのか、管理画面やユーザー向けの画面にどんなものがあるのか、など洗い出していきました。データベースのテーブルとして何があり、それがどういう役割を持っているのかを調べました。

巨大で複雑なシステムを前にすると、それを無視して「ゼロから作り直したい。。。」という気持ちになりがちです。一方で、実際に事業的価値を生み出している現行のシステムの詳細を把握することなしに、その価値を維持したまま新システムとしてアーキテクチャを設計し直すということは不可能です。逆に、既存システムに対する認識をクリアにしていくことで、開発チーム内での齟齬が減り意思決定のスピードが早くなったり、他のチームを説得しやすくなったりします。

2つ目が、インフラをコントロール可能な状態にすることです。そのためのソリューションとして、オンプレ前提で組まれた既存システムをAWSに移行するという大戦略を立てたことが紹介されています。

アプリケーションエンジニアの手でサービスを運営していく未来のためにはブラックボックス化が一番困る、という判断です。手順書と手作業によるサーバー構築では早晩ブラックボックス化してしまうので、最初からインフラ構成をバージョン管理システム上で運用できる状態にはしておきたいと考えました。（中略）それまでの「インフラ専任エンジニアによる手順書と手作業によるサーバー構築」という状態が残ると運営しにくくなるので、それを避けたかったのです。

インフラをクラウドに移行し、開発チームだけでコントロールできるようにすることで、現状把握や改善のスピードを上げていこうとしたわけです。世の中の対レガシープロジェクトではクラウドを利用すること自体が目的化しがちですが、冷静な課題認識から血の通った意思決定としてのクラウド移行が語られており痺れました。ちなみに、「なぜクラウドインフラを使うと開発チームでインフラをコントロールしやすくなるのか」を理解するにはおそらくDevOpsやIaC（Infrastructure as Code）について知る必要がありますが、長くなるので別の機会に譲ります。

他にも「事業葬り/機能葬り/コード葬り」の3つに分けてシステムをダイエットした話や、技術的負債を返済するという意思決定をどのように通したのかなど、価値あるトピックがたくさん書かれています。詳細はぜひ本書を読んでみてください。

Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち

「技術的負債」は必ずしも技術的問題ではない

最後に、レガシーシステムと密接に関係する「技術的負債」という言葉について補足します。「VOYAGE MARKETING」でも、「技術的負債」という言葉がしばしば登場します。

この「技術的負債」についてはソフトウェア業界においてある種の誤解を帯びながら語り尽くされており、検索すれば玉石混交の記事がヒットします。『エンジニアリング組織論への招待』の著者である広木大地さんの記事では、その誤解も含めて「技術的負債」という言葉の意味するところがわかりやすく解説されています。

"技術的負債"論の道案内 - アーキテクチャの資本コストと情報の非対称性 - Qiita

上記記事では、「技術的負債」という言葉は「不可解な開発速度の低下」を説明しようとしている、という前提をおいています。その上で、次のように問題の本質を指摘しています。

　経営者とエンジニアの間において、想定する見積りに誤差がでる理由は、お互いの間に存在する情報の非対称性にあります。この格差が存在しなければ、お互いの見積りの間に差は生まれません。
　このように経営者とエンジニアの間に存在する
　　・追加機能の情報非対称性
　　・アーキテクチャが見えないという情報非対称性
という２つの情報非対称性がこそが、「技術的負債」を「技術的負債」と呼ばせている「隠れた原因」です。
　情報の非対称性の解消は、本書の定義する「コミュニケーション」そのものです。「技術的負債」というキーワードをめぐるハレーションは、コミュニケーションミスの累積であり、組織的な構造の問題なのです。

「VOYAGE MARKETING」でも、こうした情報の非対称性から来る問題について言及されています。

ECナビの場合にレガシーシステムと向き合ううえで本当に厄介だったのは「技術的負債のあれこれ」ではなかったのかもしれません。むしろ問題は、「必要十分な事業要件、システム要件、システム本体が何であるかを誰も定義できないこと」だったんですよ。

「技術的負債がある」と言われるとき、その問題は純粋に「技術」によって解消できると誤解されがちです。一方で、システムの理想状態というのは当然、技術的な観点からのみ導かれるものではありません。どの機能が重要で、どの程度のリスクが許容されるかなど、事業上の意思決定の積み重ねの上に、「必要十分なシステム」がどういったものかが定義されていきます。

「VOYAGE MARKETING」の中でも、実際に開発チームが「技術的負債の蓄積」を経営上の課題として捉え、他のチームとの「コミュニケーション」によって情報の非対称性を解消していく様子が紹介されています。こうしたシステムとコミュニケーションを巡る話は、「DXとは経営や組織の変革である」という話に通じているように思います。

外注プロジェクトでの「技術的負債」との戦い方

以上が、今回書きたかった話でした。

蛇足として、「VOYAGE MARKETING」では語られていなかった「外注システムとレガシー克服」について考えたことを載せておきます。

特に開発側とビジネス側の両トップが週次でMTGして負債返却と新規開発のバランスを取っていた話が、「技術的」負債を単に技術的課題ではなく経営的課題として捉える必要があることを物語っていて良い。
逆に開発を外注してる系のレガシーシステムで同じことをどう実現するかは、かなり難問な気がする。

— gami@デジタル教育系YouTuber兼エンジニア (@jumpei_ikegami) February 23, 2021

「VOYAGE MARKETING」の例では、社内の開発チームがレガシーシステムと戦っていました。一方、世の中の多くのレガシーシステムは、いわゆるSIerや受託開発会社に開発や保守運用が外注されていることでしょう。こうした外注されたレガシーシステムの場合、戦い方はより複雑になるはずです。

外注によって問題が複雑化するのは、発注者と受注者との間で利害が一致しないというところに一番の要因があります。一般的な契約形態では、システムの受注者側に「技術的負債を返済する」ということへのインセンティブが自然には働きません。極端に言えば、工数見積による保守契約を前提にした場合、受注者からすれば「新機能開発に時間がかかればかかるほど儲かる」という状況にさえなります。つまり、技術的負債をたっぷり抱えた状態を維持し続けたほうが、見積もりも膨れ上がり、売上が上がるというわけです。さらには、「全体を誰も把握できないシステム」の方が他の開発会社によるリプレースの難易度が上がるので、ベンダーロックインしやすくなるという事情もあります。

この問題に対処するには、おそらく2つの方向性があります。

1つは、発注者側にシステム開発の責任者を（できれば経営レベルで）置き、開発プロジェクトに対するガバナンスを強力に効かせられるようにする、というアプローチです。責任者がシステムの現状把握を徹底的に行い、「技術的負債」を評価できるようになる状態を目指します。その上で、「技術的負債」を返済することを目的としたプロジェクトを立ち上げて受注者側の見積もりを取るようなアプローチです。

しかし、前述した利害の不一致を根本的に克服できるような方法ではなく、茨の道ではあります。また、プロジェクトが終了してしまうとまた技術的負債を無計画に積み上げてしまうなど、継続的な返済活動が見込めない恐れがあります。

2つ目は、発注者と受注者でレベニューシェアをするような契約形態を採用する、というアプローチです。受注者側に「開発スピードを維持すること」のインセンティブを契約レベルでもたせることができれば、同じ目線で意思決定ができるようになります。もちろん、そのような契約はまだまだ一般的ではなく、契約締結やプロジェクト進行の難易度は上がります。

一方で、「VOYAGE MARKETING」で語られている次のような開発文化を当然のものにしていくためには、自社の採用プロセスによって開発エンジニアのカルチャーマッチを見極め、同じ組織の中に自己組織的な開発チームをもつ必要があると強く感じます。

コード葬りは本当に随時やっていて、いまはもうパッケージアップデートのときにガーデニング感覚でやる風土が出来上がっています。新しい機能追加をすることになって関連するサブシステムを最初に調べたら余分なコードがあったので、それを最初に消してからPull Requestを作ったり、Pull Request後に消したり、ケースバイケースで普段のコーディングの中でやっている感じです。

レガシーシステムへの対処について考えた場合も、やはり理想的には徐々に内製開発におきかえていくというアプローチが有効であるように思います。とはいえこれがすぐにできたら苦労しないという話は大いにあるので、「外注システム開発×レガシーシステムとの戦い」を描いた書籍が執筆されることを願うばかりです。（すでにあったら教えて下さい！）