SaaS売却で値引きされる技術的負債
SaaS事業の売却交渉で、数字の詰めがほぼ終わったあとに、買い手側のエンジニアがリポジトリを覗いた瞬間から空気が変わる、という展開があります。解約率も、継続課金の積み上がりも、単価の推移も、売り手が丁寧に整理してきた資料のとおり。それでも、買い手のCTOが「ローカルで動かすまでに何日かかりますか」と尋ねたあたりから、価格の話が静かに巻き戻り始める。
売り手からすると、これは理不尽に見えます。動いているのだから、いいじゃないかと。実際、そのSaaSは今日も止まらず動いていて、毎月きっちり課金が走り、顧客も普通に使っています。何ひとつ壊れていない。それなのに、なぜ値段が下がるのか。
ここには、売り手と買い手がまったく違う問いを立てているという、SaaS売買特有のズレがあります。この記事では、技術的負債がどういう経路をたどって値引き幅という具体的な金額に化けるのかを、依存関係・テスト・環境再現性という3つの入口から順に分解していきます。
買い手が見ているのは「今動いているか」ではない
まず、この一点を押さえないと以降の話が全部ズレます。
売り手が証明しようとしているのは、たいてい「このプロダクトは動いています」です。稼働率、障害件数、サポート問い合わせの少なさ。どれも誠実な数字ですし、そこに嘘はありません。
一方で、買い手が知りたいのはそこではありません。買い手が本当に確かめたいのは、「明日から自分たちが、このコードに機能を足せるか」の一点です。
理由は考えてみれば単純です。買い手はそのSaaSを、今の状態のまま冷凍保存するために買うわけではありません。買収後には必ず、やりたいことがあります。自社プロダクトと繋ぐ、料金プランを組み替える、エンタープライズ向けの権限管理を足す、法改正に対応する。買収の意思決定は、たいていその「やりたいこと」の実現期待値の上に立っています。
そして、その「やりたいこと」に着手できるまでの時間は、プロダクトによって天と地ほど違います。リポジトリをクローンして半日で最初のプルリクエストが出せる事業もあれば、最初の1行を書くまでに3ヶ月かかる事業もある。同じ売上・同じ顧客数でも、この時間差がそのまま価格差になります。
ここで重要なのは、技術的負債が「減点項目」ではないという理解です。減点というと、テストで100点から引かれていくイメージになりますが、実際に起きていることはもっと即物的です。買い手は買収後に自分たちが払うことになる工数を、前もって価格から差し引いているだけです。負債の返済費用を、買い手が肩代わりする。だから、その分を先に価格から引く。値引きではなく、費用の付け替えです。
継続課金モデルの評価では、どうしてもARRを粉飾していないかという数字側の検証に注目が集まりますが、数字が全部正しかったとしても、この工数の付け替えは別枠で発生します。数字の正しさと、負債の重さは、独立した二つの軸です。
依存ライブラリのEOLは、最初の一手を止める
買い手のエンジニアが最初に開くファイルは、だいたい決まっています。package.json、composer.json、requirements.txt、Gemfile.lock。呼び名は違っても、やることは同じで、この事業が何に乗っかっているかの一覧を見ています。
EOLは「動かなくなる日」ではなく「直せなくなる日」
ここでよくある誤解を先に潰しておきます。EOL（End of Life）を迎えたランタイムやフレームワークは、その日を境に動かなくなるわけではありません。EOLの翌日も、翌年も、たいてい普通に動きます。
EOLが意味するのは、そこから先、脆弱性が見つかっても修正版が出てこないということです。動くけれど、直せない。この状態は、平時にはまったく困りません。困るのは、重大な脆弱性が公表された日です。
その日が来ると、選択肢は2つしかありません。放置して顧客データを危険に晒すか、バージョンを上げるか。SaaSは他社の業務データを預かっている以上、前者は事実上選べません。つまりEOLのランタイムを抱えた事業は、いつ発火するか分からない、しかも発火したら必ず対応せざるを得ない作業を、日程未定のまま抱えていることになります。
買い手から見ると、これは「いつか降ってくるが、金額も時期も自分では選べない工数」です。見積もれない工数ほど、価格交渉では保守的に、つまり厚めに積まれます。
メジャーバージョン遅延は、複利で膨らむ
もう一段やっかいなのが、メジャーバージョンの遅延です。
フレームワークのメジャーアップデートは、多くの場合、飛び級ができません。3から7へ一足飛びに上げることはできず、4、5、6と順番に上げていく必要がある。そして各段階に破壊的変更があり、それぞれで動作確認が必要になります。
ここが複利です。1つ遅れると、次のバージョンを上げるコストも一緒に遅れて積み上がる。2年放置したツケは2年分ではなく、その間に出たメジャーバージョンの数だけ、掛け算で乗ってきます。しかも周辺のプラグインやライブラリも同時に上げる必要があり、そのうちいくつかは開発が止まって代替を探す羽目になる。
「あとでまとめてやります」が最も高くつく領域が、依存管理です（そして、まとめてやる日は永遠に来ないことも、だいたい知られています）。
買い手が実際に見るもの
DDの現場で確認されるのは、おおむね次のあたりです。
- ランタイム・フレームワークのバージョンと、その公式サポート期限。EOL済みか、あと何ヶ月でEOLか
- 最新メジャーバージョンとの世代差。何世代遅れているか
- lockfileが存在し、コミットされているか。なければ、そもそも「今動いている構成」を再現する手段がありません
- 依存の脆弱性スキャン結果。件数そのものより、放置されている期間のほうが見られています
- 開発が停止した依存の有無。リポジトリの最終コミットが数年前のライブラリが基幹部分にいると、代替探しという青天井の作業が発生します
このうち、売り手が事前に手を打っておく価値が最も高いのはlockfileです。これが無い事業は、買い手が最初のビルドを通す段階で「本番と同じ構成を作れない」という壁に当たり、そこから先の検証が全部ぐらつきます。
テストがない事業は、変更のたびに全額を賭けている
テストの不在は、負債の中でも特に金額換算しやすい項目です。
テストは品質保証ではなく「変更許可証」
テストというと品質を担保するものというイメージが強いのですが、M&Aの文脈では役割が違います。買い手にとってテストは、「触っても壊れていないことを、リリース前に確認できる」という許可証です。
テストがない状態で機能を追加するとき、開発者は毎回、そのプロダクト全体を暗黙的に賭けています。この変更が既存のどこを壊すかを、誰も機械的には知らない。分かるのは、リリースして顧客が使ったときです。リグレッションの検知装置が、顧客のクレームになっている状態と言い換えてもいい。
この状態のSaaSで買い手が取れる合理的な行動は、ひとつしかありません。変更を最小限にして、恐る恐る触ることです。つまり、買収の動機だったはずの「やりたいこと」に、着手できなくなる。買い手はこれを織り込んで値段を出します。
カバレッジ率という数字の罠
ここで、テストが「ある」ことを主張する売り手が出してくる数字がカバレッジ率です。これがまた曲者で、カバレッジはコードが実行されたかどうかしか測っていません。
実行されたが、結果を何も検証していないテストは、カバレッジを稼ぎます。全部の関数を呼ぶだけ呼んで、assertが1行も無いテストスイートは、実在します。カバレッジ80%という数字と、変更しても壊れないという安心感の間には、必ずしも関係がありません。
買い手が見るのは、率ではなく「売上が止まる導線にテストがあるか」です。課金処理、認証、契約更新、Webhookの受信。ここが守られていれば、他が手薄でも、買い手は変更に踏み込めます。逆に、この導線が素手で触る状態なら、カバレッジが何%だろうと評価は変わりません。
CIが回っているかどうか
テストが書かれていることと、テストが実行されていることも別問題です。リポジトリにテストコードはあるが、CIが数ヶ月前から落ちたままで誰も直していない、という構成は珍しくありません。この場合、テストは資産ではなく、「壊れているのに壊れたままにされている」という運用文化の証拠物件として機能してしまいます。負債より、そちらの印象のほうが価格に効きます。
ちなみに、AIに任せて短期間で組み上げたプロダクトは、コードの見た目が整っている一方でテストだけが丸ごと無いという偏りが出やすく、Vibe Codingによる技術的負債が問題になるケースの多くは、この「読めるが、変えられない」形をしています。
環境構築が属人化していると、開発速度はゼロから始まる
3つ目が、地味なわりに最も直接的に効く項目です。
買い手のエンジニアが最初にやる作業は、機能追加ではありません。そのプロダクトを自分の手元で動かすことです。そして、ここにかかった日数が、買い手にとって最初の実測データになります。
「READMEのとおりにやったら動く」は、意外と少数派
長く一人か少人数で運用されてきたSaaSでは、環境構築の手順が明文化されていないことがよくあります。書いてはあるが、2年前に書かれたきり更新されていない。そのとおりにやると、途中で必ず止まる。
止まる理由は毎回違いますが、結論は同じです。動く環境が、この世に1台のノートPCの中にしか存在しない。そのPCには、誰かが何年か前に手で入れた設定や、どこにも記録されていない環境変数や、うろ覚えの回避策が積み重なっていて、本人ですら再現手順を説明できません。
この状態のプロダクトは、買い手から見ると「引き継げるかどうかが、その人の記憶に依存している」ことになります。M&Aの引き渡しで最も避けたい形です。
再現性を測る具体的な問い
実務では、次のような問いで確認されます。
- 新しいマシンで、ゼロから開発環境を立ち上げるのに何時間かかるか。「やったことがない」という答えが返ってきたら、それが答えです
- 本番環境の構成は、コードとして記述されているか。手作業で作られたサーバーは、壊れたときに同じものを作り直せません
- 本番へのデプロイは、コマンド一発か、手順書か。手順書の場合、その手順を最後に実行した人が売り手本人なら、引き渡し後の最初のデプロイが最初の事故になります
- 本番と同じ構成のステージング環境があるか。無ければ、買い手は本番で試すことになります
売り手側の防衛策としては、環境構築をワンコマンドに寄せておくことが、費用対効果で群を抜いています。丸ごと書き直す必要はなく、動く手順を再現可能な形で固定するだけで、買い手の「最初の1日」の体験が変わる。これは、売却後に無限に発生する問い合わせを防ぐという意味でも効きますし、引継ぎマニュアルを整備しておくことが売り手自身を守るという構図と、まったく同じ話です。
負債は、どうやって金額になるのか
ここまでの3項目が、実際にどう価格へ落ちるかを整理します。
第1層：返済工数そのもの
最も分かりやすい層です。EOLのランタイムを上げるのに何人月、テストを主要導線に入れるのに何人月、環境構築を再現可能にするのに何人月。それを買い手の人件費単価で掛け算する。これが値引きの土台になります。
この層は、売り手にとって実はいちばん健全な引かれ方です。金額の根拠が明確で、交渉可能で、なにより自分で先に返済すれば消せるからです。
第2層：ロードマップの遅延コスト
見落とされがちなのがこちらです。返済作業をしている期間、買い手は買収の目的だった機能開発に着手できていません。
買収の意思決定が「来期からこの機能を出して単価を上げる」という前提で通っていた場合、負債返済に半年かかるということは、その収益計画が半年後ろにずれるということです。事業計画上、これは工数よりずっと大きい金額になることがあります。人件費は月単位ですが、機会損失は事業のトップラインで効いてくるからです。
第3層：不確実性プレミアム
そして、最も高くつくのがこの層です。
買い手が負債の規模を把握できているなら、第1層と第2層で見積もりが立ちます。問題は、負債の全体像が見えないときです。人は、見えない範囲を楽観的には見積もりません。「ここまで雑なら、見えていないところも同程度に雑だろう」という推定が働き、価格には保守的なバッファが乗ります。
そして、このバッファは売り手が反論しにくい性質を持っています。「そんなことはない」と主張するには、見えていないことを見せる必要があり、それはつまり、売り手自身が把握していない何かを証明しろという話になるからです（悪魔の証明に近い）。
ここが、この記事で最も伝えたい構造です。値引きの大部分は、負債の量ではなく、負債の不確実性から来ています。技術スタックの選択そのものが評価を動かすという観点ではレガシースタックの議論がありますが、同じスタックでも、状態を説明できる事業とできない事業では、値段がはっきり分かれます。
売り手は、全部返済しなくていい
ここまで読むと、売却前に負債を全部返さなければいけないように見えますが、そんなことはありません。というより、それは合理的ではありません。
負債を返済する工数は、売り手にとっても実費です。1,000万円の値引きを避けるために1,200万円分の工数を投じるなら、値引きを受け入れたほうが得です。返済すべきかどうかは、常にこの引き算で決まります。
そのうえで、費用対効果が明確に高い打ち手は、次の3つに集約されます。
- 依存関係の棚卸し表を作る。主要な依存について、現在のバージョン、最新バージョン、EOL日、上げる場合の想定影響を1枚にまとめる。作業自体は1日で終わり、これがあるだけで第3層の不確実性プレミアムが大きく縮みます
- 売上が止まる導線にだけテストを入れる。全体を網羅する必要はありません。課金・認証・契約更新の3点に絞れば、現実的な工数で「変更許可証」が発行できます
- 環境構築をワンコマンドにして、他人のマシンで検証する。自分のPCで動くことは何の証明にもなりません。第三者の環境で、手順書どおりに立ち上がることを一度確認しておく。ここで詰まった箇所が、そのまま買い手が詰まる箇所です
共通しているのは、どれも「負債を消す」のではなく「負債を可視化する」施策だという点です。返済ではなく、開示。買い手が知りたいのは、負債がゼロであることではなく、負債の輪郭がはっきりしていることだからです。
買い手側から見た場合も、話は対称です。技術的DDで確認すべきなのは、コードの美しさではありません。「自分たちのエンジニアが、このコードで何日目に最初の機能をリリースできるか」という、たった一つの問いに答えられる材料を集めることです。そして、その問いに対する最も正直な答えは、質問ではなく実演から出てきます。売り手に環境構築を横で見せてもらう1時間は、資料を10冊読むより多くを教えてくれます。
引かれているのは、負債ではなく「分からなさ」
技術的負債があること自体は、恥ずかしいことでも、異常なことでもありません。売上が立っているSaaSは、例外なく、どこかの時点で「今は動くことを優先する」という判断をしています。その判断があったから事業が生き残ったのであって、負債は事業が生きてきた証拠のようなものです。
問題は、その負債が売り手自身にも見えていないまま、交渉のテーブルに載ることです。買い手が値引きの根拠として持ち出す負債の多くは、売り手が隠していたものではありません。売り手も知らなかったものです。だから、その場で反論できない。反論できないから、買い手の見積もりがそのまま通る。
数字を1年かけて磨き上げてきた売り手が、リポジトリの状態を一度も棚卸ししないまま交渉に臨むのは、あまりにもったいない話です。継続課金の数字を整えるのに比べれば、依存の一覧を作り、主要導線にテストを入れ、環境構築を手順化する作業は、はるかに短時間で終わります。
自分が何年もかけて育てたSaaSに、正当な値段がつかない理由が、「聞かれたときに答えられなかったから」だとしたら、それは技術の問題ですらありません。売却を考え始めた日に、まず自分のリポジトリをクローンし直して、まっさらな環境で立ち上げてみてください。そこで自分が何時間詰まるかが、買い手が見ている数字そのものです。
技術的負債の棚卸しを終えたら、それが売却額にどう跳ね返るのかを具体的な数字で確かめたくなります。SaaS事業売却の無料査定で、想定売却額のレンジを試算できます（登録不要）。
