サポート終了言語で書かれた事業の時限

買収を検討している事業のコードを開いたとき、それが何年も前のバージョンの言語やフレームワークで書かれていることに気づく。それでもサービスは問題なく動いていて、収益も出ている。「動いているなら、まあ大丈夫だろう」――ここで判断を止めたくなります。しかし、動いていることと、これからも安全に動かし続けられることは、まったく別の話です。

買い手側の技術デューデリジェンス（買収前の精査）で必ず確認すべきなのが、その事業がどのバージョンの言語・ランタイム・フレームワークで作られているか、そしてそれらがすでにサポートの切れた「EOL」に達していないか、という点です。EOLとはEnd of Life、開発元による公式サポートが終了した状態を指します。EOLの技術で書かれた事業は、いまは動いていても、時限付きで保守不能・脆弱へと向かう資産です。この記事では、その時限をどう見抜き、どう価格に織り込むかを、技術デューデリジェンスの一点に絞って掘ります。

動いているコードにも「消費期限」がある

ソフトウェアは、一度完成すれば永遠に同じ状態で動き続ける、というものではありません。土台となる言語やランタイムには開発元が定めたサポート期間があり、その期間が過ぎると、新しい不具合が見つかっても修正が提供されなくなります。周辺のライブラリも、新しいバージョンにしか対応しなくなっていきます。つまり、書いた時点では最新だったコードも、時間の経過とともに静かに古び、いつか消費期限を迎えます。

この消費期限は、日々の運用ではまったく見えません。サーバーは今日も動き、利用者は普段どおりサービスを使えている。だからこそ、売り手も買い手も「動いているから問題ない」と考えがちです。しかし消費期限を過ぎた食品が、見た目は同じでも安全ではないのと同じで、EOLを過ぎた技術で動いている事業は、見た目の正常さの裏でリスクを溜め込んでいます。買い手が見るべきは、いま動いているかではなく、その土台の消費期限がいつ切れる（あるいはすでに切れている）かです。

EOLとは何か ── サポート終了が意味すること

EOLに達するとは、具体的には、開発元がそのバージョンに対して更新を出さなくなるということです。機能の追加が止まるだけなら大きな問題ではありませんが、深刻なのは、セキュリティ上の欠陥が見つかっても修正が提供されなくなる点です。世界中で使われている言語やフレームワークには、時間が経つほど新しい脆弱性が発見されます。サポート中なら修正版が配られますが、EOLのバージョンにはそれが来ません。穴が空いたまま塞げない状態に置かれるのです。

さらに、EOLの影響はセキュリティだけにとどまりません。周辺のライブラリやサービスが古いバージョンを切り捨てていくため、新しい機能を足そうとしても対応するライブラリが使えない、外部サービスとの連携が新しい方式に移行できない、といった形で、事業の成長そのものが縛られます。EOLの技術は、守りの面では脆弱になり、攻めの面では身動きが取れなくなる。買い手が引き継ぐのは、この二重の制約です。

一番怖いのは、脆弱性を塞げないこと

EOLの事業を買うことの最大のリスクは、買収後に重大な脆弱性が公表されたとき、それを正規の方法で塞げないことです。サポート中の技術なら、公式の修正を当てれば済みます。しかしEOLのバージョンには公式の修正が来ないため、選択肢は、自力でコードに手を当てて塞ぐか、あるいは急いで新しいバージョンへ移行するかの二択になります。どちらも、時間もお金もかかり、しかも事業が攻撃にさらされている最中に行うことになります。

個人情報を扱う事業なら、この脆弱性が漏洩事故に直結します。買った事業で情報漏洩が起きれば、対応の費用や信用の失墜を負うのは、旧オーナーではなく買い手です。「動いていたから買った」事業が、買った直後の脆弱性公表をきっかけに、収益源から負債へと反転する。これは想像上のリスクではなく、EOLの技術を放置した事業が現実に抱えている時限です。記録が残っていない事業ほど、いざ事故が起きたときに自分を守れないことは監査ログがない事業は自分を守れないで扱いましたが、EOLはその事故の確率そのものを押し上げます。

「バージョンを上げればいい」が通用しない理由 ── 連鎖する依存

EOLだと分かっても、「では新しいバージョンに上げればいい」と簡単に考える人がいます。ところが、これが一筋縄ではいきません。言語やフレームワークのバージョンを上げると、その上で動いている無数のライブラリも、対応するバージョンに合わせて上げる必要が出てきます。あるライブラリを上げると別のライブラリが動かなくなり、それを直すとまた別の箇所が壊れる。この連鎖が、移行を「一日の作業」から「数ヶ月のプロジェクト」に変えます。

特に、古い言語で書かれた事業ほど、その言語が最新だった時代のライブラリに深く依存しています。中には、すでに開発が止まって新しいバージョンが存在しないライブラリもあり、その場合は代替を探すか、自分で作り直すしかありません。なぜその技術やライブラリを選んだのかという当時の判断が記録に残っていれば移行の見通しは立てやすいですが、その理由が失われていると手探りになります。設計の理由が失われた状態の危うさは選定理由が失われたアーキテクチャの罠で扱っていますが、EOLからの移行はまさにこの罠と正面からぶつかります。

買う前にバージョンをどう棚卸しするか

では、買い手はこの時限をどう見抜くか。手順は、事業が依存している技術のバージョンを一つずつ棚卸しすることから始まります。使っている言語とそのバージョン、ランタイムやサーバーソフトのバージョン、主要なフレームワーク、そして依存しているライブラリの一覧。多くのプロジェクトでは、依存関係を管理するファイルにこれらが記録されているため、それを開けば全体像がつかめます。

棚卸しができたら、それぞれについて、開発元が公表しているサポート期限と照らし合わせます。すでにEOLに達しているもの、近いうちにEOLを迎えるものを洗い出し、それが事業の根幹に関わる部分なのか、周辺の一部なのかを見分けます。根幹の言語やフレームワークがEOLなら影響は甚大ですが、周辺の小さなライブラリなら差し替えで済むこともあります。この棚卸しは、コードの中身を読む精査と合わせて行うと精度が上がります。買収前にコードから何を読み取るかはサイト買収前に見るべきコードの兆候で整理しています。

移行コストの見積もり ── 時限をお金に換算する

EOLを見つけただけでは、判断はできません。大事なのは、その時限を解消する――つまり新しいバージョンへ移行する――のに、どれだけのコストと時間がかかるかを見積もることです。根幹の言語がEOLで、依存の連鎖が深く、設計の記録も残っていない事業なら、移行は大がかりなプロジェクトになり、その間は新しい機能の開発が止まります。この「移行に取られる期間、事業が前に進まない」という機会損失も、コストの一部です。

この移行コストは、買収後に必ず発生する支出として、事業の値付けに織り込むべきものです。売上や利益がどれだけ良くても、買った直後に大規模な移行を強いられるなら、その費用と期間の分だけ、事業の実質的な価値は下がります。EOLの技術で書かれた事業は、いわば「近い将来に一度、大きな修繕費がかかることが確定している中古物件」です。修繕費を見積もらずに買えば、あとで想定外の出費に苦しみます。技術的負債が値引きの根拠になる構造はSaaS売却で値引きされる技術的負債と同じで、EOLはその中でも期限が明確な、見積もりやすい負債です。

見積もりの精度を上げるには、移行の難しさを左右する要素を分けて考えると役立ちます。第一に、EOLになっている技術が事業の根幹か周辺か。根幹の言語やフレームワークなら影響は全体に及びますが、周辺のライブラリ一つなら差し替えで済むこともあります。第二に、その技術に依存しているコードの量と、他の部分との絡み合いの深さ。薄く広く使われているほど、移行の影響範囲は広がります。第三に、動作を保証してくれるテストがどれだけ揃っているか。テストがあれば移行後に壊れた箇所をすぐ発見できますが、テストがなければ一つずつ手で確認することになり、移行の時間は跳ね上がります。この三つを見れば、移行が数週間で済むのか、数ヶ月かかるのかの当たりがつきます。

そして忘れてはならないのが、移行を実際に担う人の問題です。古い技術で書かれた事業ほど、その技術を扱える人材が市場から減っています。買い手が自分で移行できないなら、外部に依頼することになりますが、EOLになるほど古い技術の場合、対応できる技術者を見つけること自体が難しく、費用も高くつきます。買収後に「移行しようにも、できる人がいない」という事態は、EOLの事業で起こりえます。だから買い手は、移行にかかる費用だけでなく、その移行を「誰が」行えるのかまで含めて、引き継ぎ後の体制を考えておく必要があります。技術の時限は、人材の時限と重なって効いてくるのです。

EOLは減点だが、値引きの交渉材料にもなる

ここまで読むと、EOLの事業は買ってはいけないように思えるかもしれません。しかし、そうとは限りません。EOLは確かに減点要素ですが、その時限を正確に把握し、移行コストを見積もれた買い手にとっては、価格を下げる交渉材料になります。他の買い手が「なんとなく古そう」で敬遠する事業を、移行コストを織り込んだ適正な価格で手に入れられるなら、それはむしろ機会です。

重要なのは、EOLというリスクを「見えないまま引き継ぐ」のか「見抜いて価格に反映する」のかの差です。前者は、買った後に想定外の修繕費として降りかかります。後者は、交渉のテーブルで正々堂々と値引きの根拠にできます。売り手がEOLを問題だと認識していない場合もあり、その場合は買い手が指摘することで、双方が納得できる価格に着地させられます。見抜く力があれば、EOLは避けるべき地雷ではなく、交渉を有利にする情報に変わります。

動いている今こそ、時限を数えておく

EOLの怖さは、問題が起きるまで誰も困らないところにあります。動いている限り、売り手も買い手も、その事業が時限を抱えていることを忘れていられる。だからこそ、買い手が買う前に、冷静にバージョンを棚卸しし、それぞれの消費期限を数え、移行コストを見積もっておくことに、大きな意味があります。この作業を怠れば、時限はいつか、買い手の手元で切れます。

動いているコードは、現在の安心を与えてくれますが、未来の安全までは保証しません。買い手が見るべきは、いま動いているかではなく、その土台があとどれだけ安全に使えるかです。この視点で技術の状態を体系的に精査したいときは、AI技術デューデリジェンスの考え方が参考になります。何を・どのバージョンまで見れば、買収後に時限が切れるリスクを事前に洗い出せるのかを、技術の側から整理しています（登録不要）。動いている今こそが、時限を数える最後の好機です。