技術DD は『買う側と売る側を守る』調査
M&A や出資前の技術デューデリジェンス(以下DD)は、隠れた技術的負債・セキュリティリスクを早期発見する重要なプロセスです。本記事では編集部の視点で、進め方を公開情報をもとに整理します。技術的負債との付き合い方 もご参考に。
DD の主要観点
(1) アーキテクチャ：合理性・スケーラビリティ。(2) コード品質：可読性・保守性。(3) インフラ：可用性・コスト。(4) セキュリティ：脆弱性・コンプライアンス。(5) 組織：エンジニアリングチームの能力。
アーキテクチャの評価
(1) システム構成図：現実との一致。(2) マイクロサービス vs モノリスの妥当性。(3) 技術選定の合理性。(4) スケーラビリティの試算。(5) 将来3年のリスク。マイクロサービス設計 もご参考に。
コード品質の評価
(1) 静的解析：SonarQube/CodeClimate。(2) テストカバレッジ。(3) コード重複率。(4) 技術的負債の見える化。(5) サンプリングでのコードレビュー。SQLアンチパターン もご参考に。
インフラの評価
(1) クラウド利用状況：マルチクラウド/単一。(2) IaC の有無：再現可能性。(3) 監視・ログ：観測性。(4) バックアップ・DR：可用性。(5) 月次コストと内訳。バックアップ&DR もご参考に。
セキュリティの評価
(1) 脆弱性スキャン：依存ライブラリ。(2) 過去のインシデント：原因分析。(3) SOC 2 / ISO 27001：認証取得状況。(4) 個人情報保護：GDPR/PIPL 等。(5) アクセス管理：IAM・SSO。Webセキュリティ実践 もご参考に。
組織の評価
(1) エンジニア数と構成。(2) キーパーソン：誰がいなくなると困るか。(3) 離職率：直近2年。(4) 採用力：今後のスケール能力。(5) 文化・プロセス：1on1/レビュー等。テックチームの作り方 もご参考に。
DD 報告書の構成
(1) エグゼクティブサマリ。(2) 強み。(3) リスク (Critical/High/Medium/Low)。(4) 推奨アクション。(5) 価格交渉への示唆。客観的な事実ベースで書くのが鉄則です。
失敗しがちなパターン
(1) 時間不足：通常2〜4週間。(2) 表面的なレビュー：深掘り不足。(3) セキュリティ過小評価。(4) 組織側を見ない：技術だけでなく人。(5) 政治的圧力：客観性を失う。対策は、(1)初期から関与、(2)サンプリング戦略、(3)外部監査併用、(4)1on1 実施、(5)独立性を保つ、です。