Tech DD（テクニカルデューデリジェンス）の成否は、評価項目の網羅性と優先順位付けで決まります。チェックリストなしにTech DDを実施すれば、コード品質の致命的な欠陥を見落としたまま投資判断を下すリスクが生じます。本記事では、コード品質・インフラ・チーム・データの4領域にわたる実務で使えるチェックリストを提供し、スコアリングシートによる統合評価の方法まで解説します。
Tech DDチェックリストの使い方
本チェックリストは4つの評価領域（コード品質・インフラ・チーム・データ）で構成され、各項目に必須・推奨・任意の3段階の重要度を設定しています。DDのスコープに応じて対象項目を調整してください。
| スコープ | 対象項目数 | 所要日数（目安） | 適するケース |
|---|---|---|---|
| 簡易DD（必須のみ） | 20〜25項目 | 3〜5日 | シード〜シリーズA投資、小規模M&A |
| 標準DD（必須＋推奨） | 35〜45項目 | 7〜14日 | シリーズB以降の投資、中規模M&A |
| フルDD（全項目） | 55〜70項目 | 14〜30日 | 大型バイアウト、戦略的買収 |
簡易DDでも必須項目を漏れなく確認するだけで、投資判断の精度は大幅に向上します。一方、フルDDでは任意項目まで含めた網羅的な評価を行い、買収後の統合計画（PMI）に直結する知見を得ることができます。
コード品質・アーキテクチャのチェックリスト
コード品質とアーキテクチャは、対象企業の技術資産の「健全性」を測る最も基本的な領域です。ここでの発見が、投資後の技術的負債の返済コストを左右します。
| # | チェック項目 | 確認方法 | 重要度 | リスク判定基準 |
|---|---|---|---|---|
| 1 | コードベースの規模・言語構成 | cloc等でLOC計測、言語比率を確認 | 必須 | Green: 主要言語が明確 / Yellow: 3言語以上が混在 / Red: 未把握 |
| 2 | テストカバレッジ | CI/CDレポート、カバレッジツール | 必須 | Green: 70%以上 / Yellow: 40〜70% / Red: 40%未満 |
| 3 | 静的解析の導入・結果 | SonarQube等のレポート確認 | 必須 | Green: Critical 0件 / Yellow: Critical 5件以下 / Red: 6件以上 |
| 4 | デプロイ頻度 | CI/CDログ、Git履歴 | 必須 | Green: 週1回以上 / Yellow: 月1〜3回 / Red: 月1回未満 |
| 5 | CI/CDパイプラインの構成 | 設定ファイル確認、実行ログ | 必須 | Green: 自動化済 / Yellow: 部分的 / Red: 手動デプロイ |
| 6 | アーキテクチャドキュメント | ドキュメント有無・更新日確認 | 必須 | Green: 最新版あり / Yellow: 1年以上未更新 / Red: 存在しない |
| 7 | マイクロサービス/モノリス構造 | リポジトリ構成、通信パターン | 推奨 | Green: 意図的な設計 / Yellow: 移行途中 / Red: 偶発的分散 |
| 8 | 依存ライブラリの更新状況 | Dependabot、npm audit等 | 必須 | Green: 3ヶ月以内 / Yellow: 6ヶ月以内 / Red: 1年以上未更新 |
| 9 | 技術的負債の管理状況 | Issue tracker、TODOコメント数 | 推奨 | Green: 定期的に返済 / Yellow: 認識はある / Red: 未管理 |
| 10 | コードレビューの実施率 | PRのレビューコメント履歴 | 必須 | Green: 全PRにレビュー / Yellow: 80%以上 / Red: 80%未満 |
| 11 | ブランチ戦略 | Git Flow/Trunk-based等の確認 | 推奨 | Green: 明確なルール / Yellow: 暗黙のルール / Red: ルールなし |
| 12 | API設計の一貫性 | エンドポイント設計の確認 | 推奨 | Green: 設計規約あり / Yellow: 部分的 / Red: 規約なし |
| 13 | モニタリング・ログ基盤 | APMツール、ログ管理の確認 | 必須 | Green: 統合監視 / Yellow: 部分的 / Red: 未導入 |
| 14 | 障害対応プロセス | インシデント記録、ポストモーテム | 推奨 | Green: 体系化済 / Yellow: 属人的 / Red: 未定義 |
| 15 | パフォーマンステスト | 負荷テスト結果、ベンチマーク | 任意 | Green: 定期実施 / Yellow: 不定期 / Red: 未実施 |
特に注目すべきは項目2（テストカバレッジ）と項目8（依存ライブラリ）です。この2つがRedの場合、買収後に数ヶ月単位の「負債返済期間」が必要になるケースが大半です。詳細な技術的負債の定量評価については技術的負債のスコアリング手法もご参照ください。
インフラ・セキュリティのチェックリスト
インフラとセキュリティは、技術資産の「持続可能性」と「リスク」を評価する領域です。クラウド時代においては、コスト構造の可視化が特に重要になります。
| # | チェック項目 | 確認方法 | 重要度 | リスク判定基準 |
|---|---|---|---|---|
| 1 | クラウド利用状況 | 利用サービス一覧、構成図 | 必須 | Green: 構成図あり / Yellow: 部分的 / Red: 未文書化 |
| 2 | 月額インフラコスト推移 | 過去12ヶ月の請求データ | 必須 | Green: 売上比10%以下 / Yellow: 10〜20% / Red: 20%超or急増 |
| 3 | IaC（Infrastructure as Code）導入率 | Terraform/CloudFormation等の確認 | 必須 | Green: 80%以上 / Yellow: 50〜80% / Red: 50%未満 |
| 4 | DR/BCP体制 | 復旧計画書、RTO/RPOの定義 | 必須 | Green: 定義・訓練済 / Yellow: 定義のみ / Red: 未定義 |
| 5 | 脆弱性スキャン | スキャン結果、実施頻度 | 必須 | Green: 月次以上 / Yellow: 四半期 / Red: 未実施 |
| 6 | アクセス制御・IAM | 権限設計、最小権限の原則 | 必須 | Green: 最小権限 / Yellow: 過剰権限あり / Red: 共有アカウント |
| 7 | 暗号化対応 | 通信・保存データの暗号化状況 | 必須 | Green: 全面対応 / Yellow: 部分的 / Red: 未対応 |
| 8 | コンプライアンス認証 | SOC2, ISO27001等の取得状況 | 推奨 | Green: 取得済 / Yellow: 取得予定 / Red: 未検討 |
| 9 | バックアップ体制 | バックアップ頻度、復元テスト | 必須 | Green: 日次+復元確認済 / Yellow: 日次のみ / Red: 不定期 |
| 10 | ネットワーク分離 | VPC設計、セグメンテーション | 推奨 | Green: 適切に分離 / Yellow: 部分的 / Red: フラット構成 |
| 11 | シークレット管理 | Vault/SSM等の利用状況 | 推奨 | Green: 管理ツール利用 / Yellow: 環境変数 / Red: コード内にハードコード |
| 12 | SLA・可用性実績 | 稼働率データ、障害履歴 | 推奨 | Green: 99.9%以上 / Yellow: 99〜99.9% / Red: 99%未満 |
インフラコスト（項目2）がRedに該当する場合、クラウド移行の失敗やアーキテクチャ設計の問題が潜んでいる可能性が高いです。セキュリティの詳細評価についてはセキュリティDDの記事で掘り下げています。
チーム・組織・プロセスのチェックリスト
コードは書き直せますが、チームの再構築には時間がかかります。M&Aにおいてチーム評価が軽視されるケースは多いですが、PMI（買収後統合）の成否はチームの質で決まると言っても過言ではありません。
| # | チェック項目 | 確認方法 | 重要度 | リスク判定基準 |
|---|---|---|---|---|
| 1 | エンジニア人数・構成 | 組織図、職種別人数 | 必須 | Green: バランス良好 / Yellow: 偏りあり / Red: 重要職種が欠如 |
| 2 | 離職率（過去12ヶ月） | HR データ | 必須 | Green: 15%未満 / Yellow: 15〜25% / Red: 25%超 |
| 3 | キーパーソンの在籍年数 | 経歴確認、面談 | 必須 | Green: 2年以上 / Yellow: 1〜2年 / Red: 1年未満or退職予定 |
| 4 | 採用パイプライン | 採用実績、候補者プール | 推奨 | Green: 安定採用 / Yellow: 苦戦中 / Red: 採用停止・困難 |
| 5 | 開発手法 | スプリント記録、ボード確認 | 推奨 | Green: Agile定着 / Yellow: 形式的 / Red: 手法未定義 |
| 6 | ドキュメンテーション文化 | Wiki/Confluence等の活用状況 | 必須 | Green: 体系的に管理 / Yellow: 部分的 / Red: ほぼなし |
| 7 | 技術的意思決定の記録 | ADR（Architecture Decision Record）の有無 | 推奨 | Green: ADRあり / Yellow: 議事録程度 / Red: 記録なし |
| 8 | オンボーディングプロセス | 新人の立ち上がり期間 | 推奨 | Green: 体系化済 / Yellow: OJTのみ / Red: 未整備 |
| 9 | バス係数（Bus Factor） | 各領域の担当者数 | 必須 | Green: 各領域2名以上 / Yellow: 一部1名 / Red: 複数領域で1名 |
| 10 | 外注・委託の比率 | 契約形態、内製率の確認 | 必須 | Green: 内製80%以上 / Yellow: 50〜80% / Red: 50%未満 |
| 11 | 技術スタックの市場性 | 採用市場での人材供給量 | 推奨 | Green: 人材豊富 / Yellow: やや限定的 / Red: 希少スキル依存 |
| 12 | エンジニア満足度 | サーベイ結果、Glassdoor等 | 任意 | Green: 高評価 / Yellow: 平均的 / Red: 低評価・不満多数 |
バス係数（項目9）と離職率（項目2）の組み合わせは特に危険です。「特定領域を1人しか理解していない＋その人物が退職リスクあり」はM&Aにおける最大のリスク因子の一つです。チーム評価の深掘りについてはTech DDにおける「人」の評価を参照してください。
データ・AI資産のチェックリスト
データとAIモデルは、近年のTech DDで最も重要性が増している評価領域です。特にAIを事業の核としている企業では、学習データの品質や権利関係が企業価値に直結します。
| # | チェック項目 | 確認方法 | 重要度 | リスク判定基準 |
|---|---|---|---|---|
| 1 | データの種類・量・取得方法 | データカタログ、取得経路の確認 | 必須 | Green: カタログ整備済 / Yellow: 部分的 / Red: 未把握 |
| 2 | データパイプラインの構成 | ETL/ELTフロー図、ツール構成 | 必須 | Green: 文書化・自動化 / Yellow: 部分的 / Red: 手動・属人的 |
| 3 | データ品質指標 | 完全性・正確性・鮮度の計測 | 必須 | Green: 定量管理 / Yellow: 定性把握 / Red: 未管理 |
| 4 | データのプライバシー対応 | GDPR/個人情報保護法対応状況 | 必須 | Green: 法令準拠 / Yellow: 対応中 / Red: 未対応 |
| 5 | データの独自性・競争優位性 | データソースの希少性評価 | 推奨 | Green: 独自データ保有 / Yellow: 一部独自 / Red: 公開データのみ |
| 6 | AIモデルの精度・評価指標 | 評価レポート、A/Bテスト結果 | 必須 | Green: 定期評価 / Yellow: 初回のみ / Red: 未評価 |
| 7 | 学習データの権利関係 | ライセンス、利用規約の確認 | 必須 | Green: 権利クリア / Yellow: グレー領域あり / Red: リスクあり |
| 8 | モデルの再学習・運用体制 | MLOpsパイプラインの有無 | 推奨 | Green: 自動化済 / Yellow: 手動 / Red: 再学習未実施 |
| 9 | データリネージの可視化 | リネージツール、ドキュメント | 推奨 | Green: ツール導入済 / Yellow: 手動管理 / Red: 未管理 |
| 10 | データガバナンス体制 | ポリシー、責任者の有無 | 推奨 | Green: 体制構築済 / Yellow: 部分的 / Red: 未整備 |
AI企業の評価では、モデル精度（項目6）よりも学習データの権利関係（項目7）とデータパイプライン（項目2）の方が長期的な企業価値への影響が大きいケースが多々あります。データ資産の評価とAI資産の評価はそれぞれ専門記事で詳しく解説しています。
スコアリングシートの活用法
4領域のチェックリスト結果を統合し、定量的な投資判断材料にするためにスコアリングシートを活用します。各領域を100点満点で評価し、投資目的に応じた重み付けで加重平均を算出します。
| 評価領域 | 配点 | 重み付け（標準） | 重み付け（AI企業向け） |
|---|---|---|---|
| コード品質・アーキテクチャ | 100点 | 30% | 25% |
| インフラ・セキュリティ | 100点 | 25% | 20% |
| チーム・組織・プロセス | 100点 | 25% | 20% |
| データ・AI資産 | 100点 | 20% | 35% |
スコアリングの計算フローは以下のとおりです。
【スコアリング計算フロー】
[各領域のスコア算出]
|
├── コード品質: Green=10点 / Yellow=5点 / Red=0点 を項目ごとに採点
├── インフラ: 同上
├── チーム: 同上
└── データ: 同上
|
v
[加重平均の算出]
|
総合スコア = コード x 0.30 + インフラ x 0.25 + チーム x 0.25 + データ x 0.20
|
v
[判定]
|
├── 80点以上 --> 低リスク（投資推奨条件を満たす）
├── 60〜79点 --> 要注意（改善計画の策定が必要）
└── 60点未満 --> 高リスク（投資見送りまたは大幅な減額交渉）ただし、スコアが高くても特定項目がRedの場合は個別に精査が必要です。たとえば、総合スコアが82点でも「キーパーソンの退職予定」がRedであれば、そのリスクは加重平均では見えません。スコアリングはあくまで全体像の把握に使い、個別のRed項目は別途リスク評価を行うべきです。
まとめ――チェックリストは「出発点」であり「完成品」ではない
チェックリストは評価の出発点として有用ですが、すべてのリスクを定量化できるわけではありません。組織文化、経営陣の技術理解度、チームのモチベーション――こうした「チェックボックスでは測れないもの」が、買収後の統合を左右することは珍しくないのです。
「チェックリストを埋めること」が目的化した瞬間、Tech DDは形骸化します。チェック項目はあくまで「正しい問いを立てるための道具」であり、その先にある文脈の理解こそがTech DDの本質です。
要点を振り返ります。
- 4領域（コード品質・インフラ・チーム・データ）で評価項目を網羅する
- 重要度（必須/推奨/任意）でスコープに応じた項目選定を行う
- Green/Yellow/Redの3段階判定で定量化し、加重平均で総合スコアを算出する
- スコアが高くても個別のRed項目は別途精査する
- チェックリストで測れない定性的リスクこそ、経験豊富な評価者の判断が必要
Tech DDの実施やチェックリストのカスタマイズについては、DE-STKまでお気軽にご相談ください。
FAQ
Q: Tech DDのチェックリストには何項目くらい必要ですか？
標準的なTech DDでは、コード品質・インフラ・チーム・データの4領域で合計50〜60項目が目安です。簡易DDでは必須項目のみ20〜25項目に絞り、フルDDでは任意項目も含め70項目以上を評価します。
Q: Tech DDのスコアリングはどのように行いますか？
各領域を100点満点で評価し、投資目的に応じた重み付け（例: コード品質30%・インフラ25%・チーム25%・データ20%）で加重平均を算出します。総合スコア80以上を低リスク、60未満を高リスクと判定するのが一般的です。
Q: チェックリストだけでTech DDは完結しますか？
チェックリストは評価の出発点であり、それだけでは不十分です。定量的な指標では捉えきれない組織文化やチームのモチベーション、経営陣の技術理解度なども含めた総合的な判断が必要です。