Tech DDの成功は「何を見るか」と同時に「どのくらいの期間で見るか」というスコープ設計で決まります。「なんとなく2週間くらいで」と漠然と始めるDDは、必ず範囲の逸脱か見落としのどちらかを起こします。本記事では、1週間・2週間・1ヶ月の3つの標準スコープそれぞれについて、日別・週別のプロセス、チェックリスト、必要な体制、そしてスコープ選定の判断基準を整理します。

Tech DDのスコープを決める3つの判断基準

Tech DDのスコープ設計は、(1)投資額・取引の重要度、(2)対象企業の技術複雑性、(3)利用可能な時間とリソースの3つの軸で決めます。投資額が大きい案件では見落としのコストが膨大になるため長期スコープが、投資額が小さい場合は機会損失を避けるため短期スコープが適します。また対象企業の技術複雑性(マイクロサービス数、データ量、AI利用度)が高いほど、深掘りに時間を要します。

スコープが不適切な場合のリスクは2方向に発生します。過大なスコープはDDコストと時間の膨張を招き、買収競合に先を越されるリスクを生みます。過小なスコープは重大リスクの見落としを招き、PMI段階で「こんなはずでは」という状況を生みます。どちらに傾いてもペナルティは大きいため、冒頭のスコープ選定が最初の重要な意思決定となります。

スコープ期間費用目安評価領域数適するケースアウトプット
クイック1週間150〜300万円4〜5領域シード・Aラウンド投資Red Flag中心の簡易レポート
標準2週間400〜700万円7〜8領域中型M&A、Bラウンド以降領域別評価+統合レポート
フル1ヶ月1,000〜2,000万円10領域以上大型M&A、戦略的買収詳細レポート+PMI提言

1週間スコープ――クイックアセスメント

1週間スコープは、限られた時間でRed Flagを洗い出すクイックアセスメントです。シード・シリーズA投資や、LOI締結前のスクリーニング段階で用いられます。全領域を浅く見るのではなく、4〜5領域に絞り込んで致命的リスクの有無に集中します。

具体的な日別プロセスは以下の通りです。Day 1-2はスコーピング、NDA締結、資料収集を実施します。対象企業への資料請求リスト(RFI)を送付し、コードへの読み取りアクセス、アーキテクチャ図、組織図、インシデント履歴を受領します。Day 3-4はコードレビューとインフラ概観を実施します。主要リポジトリを静的解析ツールに通し、GitHubの活動統計、デプロイ履歴、主要サービスのSLO達成率を確認します。Day 5はCTO・リードエンジニアへのインタビュー(2〜3時間)と、Red Flag中心のレポート作成です。

1週間スコープで「捨てる」領域は、データ資産の深掘り、セキュリティ監査、組織文化の評価、AI/ML固有領域の詳細評価です。これらは必要なら後日の追加DDで対応します。

#確認項目Red Flag基準
1主要リポジトリへのアクセス可否アクセス拒否
2アーキテクチャ図の存在と正確性図が存在しない
3コード複雑性の平均値関数平均>20
4テストカバレッジ概観40%未満
5古い依存ライブラリの比率30%以上
6デプロイ頻度月1回以下
7直近6ヶ月のインシデント件数重大障害3件以上
8MTTRの実績1日以上
9CI/CDパイプラインの有無存在しない
10監視・可観測性ツール導入導入なし
11クラウド/オンプレ構成不透明
12主要人材の在籍期間キー人材が半年未満
13ドキュメント整備状況ほぼ存在しない
14外部ベンダー依存度単一ベンダー依存
15セキュリティインシデント履歴未対応の重大事象あり

2週間スコープ――標準デューデリジェンス

2週間スコープは、ミドル〜レイトステージ投資や中型M&Aで最も広く使われる標準的なDD期間です。クイックアセスメントよりも領域数を増やし、データ資産やセキュリティ基礎にも踏み込みます。

Week 1は情報収集と定量分析のフェーズです。RFI送付、NDA下でのコードアクセス確保、静的解析ツール実行、インフラ・監視ツールのログ収集、組織図とスキルマップの受領を並行実施します。週後半には、コード品質・デプロイ頻度・MTTR等の定量指標を揃え、一次所見を抽出します。

Week 2はインタビュー、データ/AI評価、統合レポート作成のフェーズです。CTO・VPoE・セキュリティ担当・データ担当への個別インタビューを計6〜10時間行い、定量データの「なぜ」を言語化します。データ/AI領域では、主要データセットの量と品質、パイプラインの健全性、モデルがある場合は概観評価を実施します。週末にリスクマトリクスと提言を含む統合レポートをドラフトします。

領域Week 1確認項目Week 2確認項目
コード品質静的解析、複雑性、カバレッジ主要モジュールの設計思想
インフラ構成図、クラウド費用スケーラビリティ、災害対策
開発プロセスCI/CD、デプロイ頻度ブランチ戦略、レビュー文化
運用監視、アラート、MTTRインシデント事後分析
セキュリティ基礎既知脆弱性、認証基盤ポリシー、アクセス制御
データ資産データ量、スキーマデータ品質、系譜、権利
組織・人材構成、スキルマップキーパーソン依存、離職率
知的財産特許、OSSライセンス商用利用制約、コンプラ

2週間スコープでは約30〜35項目の確認を実施し、領域別評価と統合所見を含むレポートを納品します。PMI計画の初期インプットとしても活用可能な粒度です。

1ヶ月スコープ――フルデューデリジェンス

1ヶ月スコープは、大型M&Aや戦略的買収で用いられるフルDDです。10領域以上をカバーし、セキュリティ監査、データ/AI資産の詳細評価、組織文化の深掘りまで踏み込みます。

Week 1: 全領域の情報収集と初期分析を実施します。RFIリストは50項目以上に及び、対象企業の協力体制構築が必須です。技術スタック、人員、財務、セキュリティポリシー、法務書類を一式受領します。Week 2: 技術チームへの深掘りインタビューとコード詳細レビューです。CTOに加えてシニアエンジニア、QAリード、SREリードへの個別インタビューを実施し、コードはSonarQube等の自動解析に加えて手動レビューも行います。Week 3: セキュリティ監査とデータ/AI資産の詳細評価です。ペネトレーションテスト、クラウド設定監査、データ系譜調査、モデル独立評価を並行実施します。Week 4: リスク評価統合、レポート作成、PMI提言策定です。前週までの所見をリスクマトリクス化し、投資判断材料と統合戦略を含む最終レポートを納品します。

主要タスク想定所要人日
Week 1情報収集、RFI回収、初期分析15〜20人日
Week 2インタビュー、コード詳細レビュー20〜25人日
Week 3セキュリティ監査、データ/AI評価25〜30人日
Week 4統合分析、レポート、PMI提言15〜20人日

フルスコープでは50〜60項目の確認を実施し、全領域の詳細評価を含むレポートを納品します。PMI初期90日計画と統合後18ヶ月の技術ロードマップのドラフトも含めることが一般的です。

Tech DDの実施体制とチーム構成

必要な体制はスコープに比例します。共通する役割はDDリード(進行管理と最終レポート責任)、バックエンド/フルスタックエンジニア(コード評価)、インフラエンジニア(構成・運用評価)、データ/AIスペシャリスト、セキュリティ専門家です。

スコープDDリードエンジニア専門家合計人日合計
クイック(1週)1名1名02名10人日
標準(2週)1名2名1名(データ)4名40人日
フル(1ヶ月)1名3名2〜3名(データ、セキュリティ、AI)6〜7名120人日
【Tech DDタイムライン比較】

1週間スコープ:
Day 1 | スコーピング・RFI送付
Day 2 | 資料収集・アクセス確保
Day 3 | コードレビュー・静的解析
Day 4 | インフラ概観
Day 5 | インタビュー・レポート
------+---------------------------------

2週間スコープ:
Week 1 | 情報収集 --> 定量分析 --> 一次所見
Week 2 | インタビュー --> データ評価 --> 統合レポート
-------+---------------------------------

1ヶ月スコープ:
Week 1 | 全領域情報収集
Week 2 | 深掘りインタビュー・コード詳細
Week 3 | セキュリティ監査・データ/AI評価
Week 4 | リスク統合・PMI提言
-------+---------------------------------

※ いずれのスコープでも、最終日は必ずレポート納品と
   フィードバックセッションに充てます。

対象企業とのコミュニケーション設計

Tech DDは対象企業の協力なしには成立しません。RFI(Request for Information)リストは、必要最小限かつ優先度付きで送付するのが鉄則です。「全部出してください」と依頼すると相手の工数を過剰に奪い、協力関係を損ねます。まずはアーキテクチャ図、組織図、主要KPIといったトップダウンの資料を依頼し、DD進行に応じて詳細を追加請求します。

インタビュー設計では、「誰に・何を・どの順番で聞くか」を事前に整理します。一般的な順序はCTO(全体像)→シニアエンジニア(実装詳細)→SRE/運用(本番運用の現実)→データ/セキュリティ専門家(固有領域)です。各インタビューは60〜90分を目安とし、録画の可否を事前に確認します。

機密情報の取り扱いは、NDAと併せてデータルーム(仮想データ共有環境)の構成を事前合意します。コードへのアクセスは読み取り専用、ログはマスキング、個人情報を含むデータは匿名化した上で提示——こうした取り扱いを書面化することで、対象企業の不安を軽減し協力を得やすくなります。

まとめ——スコープの選択自体が最初の意思決定

「完璧なDDを目指して期間を延ばす」より「目的に合ったスコープで早く判断する」方が、多くの場面で価値があります。スコープ設計はDDの技術課題ではなく、経営判断の一部です。

  • スコープは投資額・技術複雑性・利用可能リソースの3軸で決める
  • 1週間はRed Flag中心、2週間は領域別評価、1ヶ月はPMI提言まで含む
  • 体制はスコープに比例。フルDDでも7名以内が現実的な上限
  • RFIは優先度付きで段階的に、インタビューは順序設計が鍵
  • スコープ選定はDD開始前の最も重要な意思決定

DE-STKでは、1週間・2週間・1ヶ月のスコープ別にTech DDサービスを提供しています。投資テーマや取引規模に応じた最適なスコープ設計からご相談ください。

よくある質問(FAQ)

Q1. Tech DDの標準的な期間はどのくらいですか?

投資額や対象企業の複雑性に応じて1週間〜1ヶ月です。シード・シリーズA投資では1週間のクイックアセスメント、中型M&Aでは2週間の標準DD、大型M&Aでは1ヶ月のフルDDが一般的です。スコープ選定時には、投資額だけでなく対象企業の技術複雑性と利用可能リソースも考慮します。

Q2. Tech DDに必要なチーム構成は?

最小構成はDDリード1名+エンジニア1名の2名体制です。標準的には3〜5名(DDリード、バックエンドエンジニア、インフラエンジニア、データ/AI専門家)で実施します。フルDDではセキュリティ専門家を加えた6〜7名体制が一般的です。

Q3. Tech DDで対象企業にどこまで情報開示を求められますか?

NDA締結の上、ソースコードへのアクセス、インフラ構成図、チーム構成、開発プロセスのドキュメントなどを求めます。コードアクセスが得られない場合は、インタビューとアウトプット分析で代替評価する手法もあります。対象企業の協力度が高いほどDD精度は上がるため、情報開示の枠組みは信頼関係構築の一環として設計します。