技術デューデリジェンスの全体像と7つの評価軸

技術デューデリジェンス（以下、技術DD）という言葉が指す範囲は、語る人によって異なる。「コードのレビューをすること」という人もいれば、「エンジニアと話すこと」という人もいる。この曖昧さが、技術DDを「やった気になったが何も見えていなかった」という結果を生む。

本稿では、技術DDの定義・範囲・評価軸の構造を整理する。各評価軸の具体的な手法や質問例は既存の専門記事に委ね、ここでは「技術DDとはどういう営みか」という概念的な地図を提供することに絞る。

技術DDとは何か：財務DDとの対比から考える

財務DDは「どれだけ稼いでいるか、これからどれだけ稼げるか」を問う。技術DDが問うのは「その事業を支える技術基盤が、将来の成長と価値実現に耐えられるか」だ。

両者の関係を整理すると、財務DDが成果の評価であるのに対し、技術DDは成果を生み出す仕組みの評価だ。事業計画が「ユーザーを3年で10倍にする」と書いていても、そのスケールに対応できるアーキテクチャかどうか、組織にその能力があるかどうかを判断するのは財務DDにはできない。

技術DDが独立した評価プロセスとして必要な理由はここにある。

技術DDが扱う範囲：3つのよくある誤解

技術DDの範囲を正確に理解するために、よくある誤解から入る。

誤解1：「コードを読む作業」である

コードは技術DDの一部に過ぎない。むしろ、コード以外の情報——デプロイ頻度・離職率・インシデント対応の仕組み——の方が、技術組織の実態を映すことが多い。コードだけを見て「品質が高い」と判断しても、それを書いたエンジニアが全員退職予定なら技術資産の価値は大きく変わる。

誤解2：「エンジニアが担当する専門業務」である

技術DDの多くは、非エンジニアでも実施できる。組織・プロセス・技術方針の評価は構造化されたインタビューで行えるし、定量指標（デプロイ頻度・離職率）は数字として確認できる。コードやアーキテクチャの深掘りには技術専門家が必要だが、それは技術DDの全体ではない。

誤解3：「リスクを見つける作業」である

技術DDはリスクの洗い出しだけでなく、価値の評価でもある。独自のデータ資産・希少な技術力・競合に模倣困難なアーキテクチャが存在するなら、それはバリュエーションの根拠になる。「何が問題か」だけでなく「何が優位性か」を問うことが、完全な技術DDだ。

7つの評価軸：何を評価するか

技術DDを構成する評価軸は、整理の仕方によって異なるが、実務的な網羅性という観点から以下の7軸が使いやすい。

軸	問い	重複しがちな誤解
1. アーキテクチャ	将来の成長に耐えられる構造か	「今動いているか」と混同される
2. コード品質	技術負債の種類と規模はどの程度か	「きれいなコードか」という審美的評価になりがち
3. インフラ	可用性・コスト・ロックインリスクは	クラウドを使っていれば安全という誤解がある
4. セキュリティ	認証・データ保護・脆弱性管理は適切か	コンプライアンス書類だけで判断される
5. 開発プロセス	組織として持続可能な開発速度があるか	個人の能力と組織のプロセスが混同される
6. 技術組織	キーマン依存・スキル分布・採用力は	コードの質だけで組織を評価してしまう
7. 競合優位性	技術上の差別化は模倣困難か	「技術が最新か」という表面的な評価になる

7軸の関係性：独立ではなく連動している

7軸は独立した評価項目ではなく、相互に連動している。例えば：

コード品質が低い → テストがない → デプロイが怖い → デプロイ頻度が下がる（プロセス軸に影響）
キーマン依存が高い → 離職リスクが高い → コード品質の維持が困難（コード品質軸に影響）
アーキテクチャに問題がある → スケール時にコスト爆発 → インフラコストが読めない（インフラ軸に影響）

評価のときに重要なのは、各軸を個別にスコアリングするだけでなく、どの軸の問題が他の軸にどう波及しているかを読むことだ。クリティカルな問題は、多くの場合、複数の軸が連鎖している。

評価の深度：「何をどこまで見るか」を決める

技術DDに使える時間とリソースは有限だ。全軸を同じ深さで評価しようとすると、すべてが浅くなる。重要なのは「何をどこまで見るか」の優先順位付けだ。

深度の決定には、主に2つの軸がある。

投資ステージ・案件規模

シード段階では軸6（技術組織）と軸7（競合優位性）を重点的に見ることが多い。コードはこれから書き直すが、人とコンセプトは変えにくいからだ。シリーズA以降は全軸をバランスよく評価し、M&Aや大型ラウンドでは外部専門家を起用して深掘りする。

事業の技術依存度

「AI・MLが競合優位の核だ」と主張するスタートアップは、軸7（競合優位性）の深度を特に上げる必要がある。「SaaSの標準的なCRUDアプリだ」という場合は、軸6（技術組織）と軸5（開発プロセス）の評価に集中するのが効率的だ。

各軸の詳細：専門記事へ

7軸それぞれの具体的な確認項目・推奨質問・判断基準については、別記事で詳しく扱っている。

コード品質と技術負債（軸2）

「技術負債」という言葉は多義的で、語る人によって意味が異なる。投資判断に使えるフレームワークとして再整理したのが「技術負債」の正体とスタートアップで問題になるパターンだ。4象限の分類と「良い負債と悪い負債の見分け方」を扱っている。

全7軸のチェックリスト（軸1〜7）

DDで確認すべき具体的な項目を軸ごとに整理したのが投資家が実施すべき技術デューデリジェンスの全項目だ。アーキテクチャ・コード品質・セキュリティ・開発プロセス・技術人材・IP・プロダクト指標の7領域をカバーしている。

非エンジニアによる評価（軸5・6）

コードを読まずに技術組織を評価する方法を扱ったのが買収前に技術組織をどう読むかだ。面談前の定量指標確認から4軸による論点整理、PMI設計への活用まで解説している。

技術DDをどう投資・買収判断に結びつけるか

技術DDの最終的なアウトプットは「この会社の技術は良いか悪いか」という判定ではない。以下の3つを投資・買収判断に渡すことが目的だ。

クリティカルリスクの特定: 投資判断そのものを左右するリスク（例：法的問題、修復不可能な技術負債）
条件交渉の材料: バリュエーション・クロージング条件・投資後のマイルストーンに反映できる発見事項
PMI・バリューアップ計画の設計根拠: 投資後にどこから優先的に手を入れるかの優先順位付け

「問題を見つけて投資を止める」のではなく、「リスクの規模と解消可能性を把握し、投資条件と投資後計画に反映する」——これが技術DDの本来の役割だ。

完璧な技術基盤を持つスタートアップは存在しない。重要なのは、経営チームが自社の技術リスクをどの程度正確に把握していて、どんな解消計画を持っているか、そして投資家がそれを投資判断に正しく組み込めているかだ。

Tied株式会社では、VC・事業会社のM&A担当者向けに技術デューデリジェンス支援を提供しています。詳細は投資家向けサービスページをご覧ください。