買収候補のAIスタートアップから受けたデモは、驚くほどよく動いた。質問を打てば的確な草案が返り、画面も洗練されている。経営会議でも「これは伸びる」と評価は上々でした。しかし半年後、統合したはずのプロダクトの開発が思うように進まない。ちょっとした機能追加のたびに別の場所が壊れ、障害対応で現場が疲弊していく。中核を握っていたエンジニアが一人抜けた途端、誰も検索の仕組みに手を出せなくなった。デモで見えたのは表面の動きだけで、その裏側にどれだけの負債が積まれていたのかは、買ってみるまで分からなかった。

この「動いているのに、なぜ買収後に止まるのか」という不安は、コードとリポジトリの中身を見れば、かなりの部分を事前に言葉にできます。静的解析が示す危険な箇所、テストがどこまで守っているか、コミットが誰にどれだけ偏っているか、そして設計が人の頭の中だけにあるのか文書にあるのか。どれも技術者が実際にコードを読めば数字で拾える論点です。ここでは、非エンジニアの意思決定者にも伝わる形で、その見方と「買収後に効いてくる負債」の見積もり方を整理します。買収検討の初期に、DDが必要な案件かどうかの見立てから相談できる仕組みは AIテックデューデリジェンス で提供しています。

デモでは見えない4つの中身を、コードから読む

技術的負債という言葉は曖昧に使われがちですが、DDで見るべき中身は4つに絞れます。それぞれに「何を測るか」と「危険な兆候」があり、コードを開けば主観ではなく数字で拾えます。まずは全体像を一枚で押さえてください。この4つが、この後の実例でそのまま採点項目になります。

見る観点何を測るか危険な兆候
静的解析の重大度ツールが自動検出する不具合の深刻度別件数（Critical／High／Medium）Criticalが1件でも放置されている。Highが数十件たまり、警告に慣れて誰も直さない状態
テストカバレッジコードのうちテストで動作確認されている割合。全体ではなく層ごと（画面／サーバー／中核ロジック）に見る売上を支える中核ロジックが一桁%。テストが薄い箇所ほど、変更のたびに壊れる
コミット集中とバス係数変更履歴が誰にどれだけ偏っているか。「何人抜けたら開発が止まるか」を示すバス係数上位1名が7割超。特定領域を一人しか触れず、その領域のバス係数が1
ドキュメント負債設計意図・環境構築手順・仕様変更の記録が文書として残っているか動かし方が口伝でしか分からない。設計判断の理由がコードのどこにも書かれていない

4つに共通するのは、どれも「買った瞬間」ではなく「その後の開発速度」に効いてくる点です。静的解析とテストは障害の起きやすさに、コミット集中とドキュメント負債は人が抜けたときの止まりやすさに直結します。デモの完成度がいくら高くても、この4つが赤なら、統合後の一年で回収コストとして跳ね返ってきます。

静的解析とテストで「障害の起きやすさ」を測る

静的解析は、コードを実行せずに機械的に不具合の芽を洗い出す作業です。重要なのは総件数ではなく重大度の分布です。Medium（軽微な指摘）が数百件あっても実害は小さいことが多いのですが、Critical（重大な欠陥）が放置されているなら話は別です。セキュリティホールやデータ破損につながる箇所を「知っていて直していない」ことを意味し、開発チームが警告に麻痺しているサインでもあります。件数そのものより「Criticalをどう扱っているか」に開発文化が表れます。

テストカバレッジは、全体の平均値だけを見ると判断を誤ります。画面まわりのテストが手厚くても、売上を生む中核ロジックがほぼ無防備なら、危険はその中核に集中しているからです。だからカバレッジは層別に分けて見ます。とくにAIプロダクトの場合、検索や推論のパイプラインは入力次第で結果が揺れるため、ここが低カバレッジだと「直したつもりが別の入力で壊れる」が頻発します。カバレッジの低い層は、買収後に手を入れるたびに障害を生む「触りたくない場所」になり、開発速度をじわじわ削っていきます。

コミット集中とドキュメント負債で「人が抜けたときの止まりやすさ」を測る

コミット履歴は、その組織の弱点を正直に映します。変更の大半を一人が担っているなら、その人がプロダクトの生き字引です。頼もしく見えますが、買い手からすると「その一人が抜けたら開発が止まる」という一点集中リスクそのものです。これをバス係数という言葉で表します。ある領域を触れる人が一人しかいなければ、その領域のバス係数は1。仕様の理由も、落とし穴も、直し方も、その人の頭の中にしかない状態です。

ドキュメント負債は、このバス係数の低さを深刻にする増幅装置です。設計の意図や環境の作り方が文書に残っていれば、担当者が抜けても他の人が読んで引き継げます。しかし文書がなければ、知識は人と一緒に会社を去ります。DDでは、READMEだけで環境が立ち上がるか、なぜその設計にしたかの記録（設計判断のメモ）が残っているか、仕様変更の履歴を後から追えるかを確認します。ドキュメント負債は単体では地味ですが、キーパーソン集中と組み合わさったときに「引き継ぎ不能」という最悪の形になります。

サンプル案件で見る：数字が語る技術的負債

抽象論だけでは実感がわかないので、当社のサンプル報告書で使っている架空案件で通してみます。対象は株式会社ツギテ（従業員18名・エンジニア9名）、コンタクトセンター向けのRAG型応対支援SaaSを手がける会社です。買い手はこれを買収候補として検討している、という設定です。サンプル案件では実働14営業日・面談6本で、全4リポジトリ・約14.6万行のうち約18%のコードを精読して評価しました。その中の技術的負債に関する発見を、先ほどの4観点で並べます。

観点サンプル案件での実測読み取れること
静的解析Critical 3件を検出（未修正のまま放置）重大な欠陥を認識しつつ手当てされていない。品質管理の優先順位づけが機能していない兆候
テストカバレッジサーバー31%／画面12%／検索パイプライン8%最も価値を生む検索パイプラインが最も無防備。ここへの改修が障害を生みやすい
コミット集中CTOが71%、他5名で残り29%。検索パイプラインはバス係数1中核をCTO一人が抱える。CTO退職時に検索領域の開発が停止するリスク
ドキュメント負債設計判断・運用手順の文書化が不足（発見事項F-10）口伝依存。キーパーソン集中と重なり、引き継ぎが困難になる

数字を並べると、この案件の弱点がどこに集まっているかが一目で分かります。最も売上を支える検索パイプラインが、カバレッジ8%・バス係数1・ドキュメント不足という三重の負債を抱えている。つまり「一番大事な部分が、一番脆く、一番一人に依存している」構図です。デモでは検索精度の高さが評価されていましたが、その裏側はこういう状態でした。表面の完成度と中身の頑健さは、まったく別の話だということが見えてきます。

この負債は買収後の出費として概算できます。サンプル案件では、コミット71%集中とバス係数1の是正（知識移転・体制冗長化）に対する費用を、発見事項F-04として1,000〜2,000万円と見積もっています。ドキュメント負債の是正（F-10）は200〜400万円。これらはDDをせずに買った場合、買収後に発覚してそのまま買い手の追加負担になる性質のものです。事前に把握できれば、価格に織り込むか、クロージング前に売り手側で是正してもらうかを選べます。金額はあくまでサンプル案件での試算であり、実際の案件では規模と構造によって変わります。

キーパーソン集中に、買収後どう手を打つか

コミット集中とバス係数1が見つかったとき、買収そのものを止める必要は必ずしもありません。小さなAIスタートアップで中核が一人に集中しているのは、むしろ普通です。問題は「集中していること」ではなく「集中したまま統合してしまうこと」です。見つけた集中リスクを、統合計画の中で計画的にほどいていく。その打ち手は大きく3方向あります。実務では法務・人事と設計する領域なので、ここでは技術者観点での論点として整理します。

打ち手狙い技術DDで確認しておくこと
継続勤務のインセンティブ設計（ロックアップ）キーパーソンが一定期間は残り、開発を止めずに引き継ぎ期間を確保する誰が本当のキーパーソンか（肩書ではなくコミット履歴で特定）。何人を対象にすべきか
競業避止・秘密保持の取り決め中核知識が退職後にそのまま競合へ流れる事態を抑えるその人しか知らない領域（バス係数1の範囲）はどこか。守るべき知識資産の所在
PMIでの知識移転（バス係数の引き上げ）一人に集中した知識を複数人へ広げ、依存そのものを解消する移転すべき領域の優先順位（売上への近さ順）。ドキュメント化の対象と工数

3つの打ち手に共通するのは、まず「誰が本当のキーパーソンで、その人しか知らない領域はどこか」を正確に特定しないと設計できない点です。ここで効いてくるのがコミット履歴の分析です。肩書や自己申告ではなく、変更履歴という客観的な事実から特定するので、対象を絞り込めます。サンプル案件で言えば、CTOと検索パイプラインが最優先の保全対象になります。ロックアップと競業避止は法務・人事が主導する領域ですが、その前提となる「誰を・どの知識を守るのか」を技術の目線で示すのがテックDDの役割です。統合計画にこの優先順位を落とし込めば、買収後に慌てて属人化に気づく事態を避けられます。

コードの一部だけ読んで、全体を評価できるのか

「約18%しか読んでいないのに評価できるのか」という疑問はもっともです。全コードを精読するのは時間的にも費用的にも現実的ではなく、その必要もありません。ポイントは、どこを読むかの選び方にあります。静的解析とカバレッジ計測はツールで全体に一律にかけ、機械的に危険な箇所を絞り込みます。そのうえで人が精読するのは、売上に直結する中核ロジックと、静的解析が危険信号を出した箇所、そしてコミットが偏っている領域です。全体をならして読むのではなく、リスクの高いところに人手を集中させる。だからサンプル案件でも約18%の精読で、負債の所在を数字で示せています。読む範囲と、なぜそこを選んだかを報告書に明記するのが誠実なDDの条件です。

よくある質問（FAQ）

技術的負債は、社内のエンジニアでも評価できませんか

できる部分もありますが、いくつか壁があります。静的解析やカバレッジ計測はツールで測れても、「Critical 3件は買収を止めるほどか、価格調整で足りるか」といった経営判断への翻訳には、買収文脈での評価経験が要ります。加えて、社内エンジニアが評価すると本業の開発がその間止まり、対象会社の技術者に対して利害関係のない第三者として質問しにくい面もあります。サンプル案件のような規模で内製すると概ね2.5人月ほどかかり、会社総コスト換算で約500万円相当が目安です。専門家に出すのと社内で抱えるのとで費用は大きく変わらず、違うのは品質と本業への影響、という比較になります。

テストカバレッジは何%あれば安心と考えればよいですか

一律の合格ラインを引くことはおすすめしません。全体で80%あっても、売上を生む中核ロジックが10%なら危険は残るからです。見るべきは平均値ではなく分布で、「価値の高い層ほどカバレッジが高いか」が判断基準になります。サンプル案件のように検索パイプラインが8%という状態は、数字の低さそのものより「一番大事な場所が一番無防備」という配置が問題です。カバレッジは絶対値ではなく、どの層が薄いかと、その層が事業のどこに効くかをセットで読んでください。

キーパーソン集中が見つかったら、その買収は見送るべきですか

集中があるだけで見送りにする必要はありません。小規模なAIスタートアップでは中核が一人に集まっているのがむしろ一般的です。判断のポイントは、その集中を統合計画の中でほどける見込みがあるかどうかにあります。誰がキーパーソンかをコミット履歴で特定し、継続勤務の設計や知識移転の計画に落とし込めるなら、集中は「対処すべき課題」であって「撤退理由」ではありません。逆に、その一人が抜ける確度が高いのに手当ての目処が立たないなら、価格や条件に反映する論点になります。事実の特定と打ち手の設計をセットで検討するのが現実的です。

報告書には、見つかった負債を金額で書いてもらえますか

是正費用の直接見積として、算定根拠つきでレンジ提示します。サンプル案件では、キーパーソン集中の是正を1,000〜2,000万円、ドキュメント負債を200〜400万円といった形で、発見事項ごとに幅と前提を添えています。満額がそのまま価格交渉に通る性質のものではありませんが、「値引きの口実」ではなく「是正にいくらかかるか」という根拠のある数字なので、社内説明や売り手との条件交渉の材料になります。金額はあくまで対象会社の規模と構造に依存し、実案件では個別に積算します。

「デモは良かったが、買った後に開発が止まらないか」という一点が引っかかっているなら、その不安をコードのどこを見れば言葉にできるか、案件の見立てだけでも壁打ちにお使いください。静的解析・テスト・コミット履歴から技術的負債とキーパーソン集中を数字で可視化し、価格調整と統合計画の材料まで描く進め方は AIテックデューデリジェンス でご覧いただけます。

あわせて読みたい