技術DD・デューデリジェンス
SaaSの技術DDで見る5つのポイント
小規模〜中規模のSaaS・WebサービスのM&Aでは、 「売上は悪くないが、技術的に持てるのか」が最大の論点になります。 本記事では、実務で技術DDを行う際に必ず見る5つの観点と、 それをどのように意思決定に落とし込むかを整理します。
この記事の前提
- 月商数十万〜数百万円規模のSaaS・Webサービスを想定
- 売り手・買い手ともに、専任のCTOやSREチームがいない前提（少人数開発）
- 「技術的に運用しきれないリスク」を事前に見極めたい買い手側のニーズを想定
1. 技術スタックとアーキテクチャ
最初の観点は、「どの技術で、どのような構造で作られているか」です。 ここでは良し悪しというより、自社のチームが持てるかどうか を判断するための情報整理が中心になります。
- フロントエンド・バックエンド・インフラの主要技術
- モノリスかマイクロサービスか、レイヤー分割の有無
- 主要な外部SaaS・ミドルウェアへの依存関係
ここで重要なのは、「理想的な構成かどうか」よりも「自社で安全に運用できる射程にあるか」です。多少の古いスタックであっても、 チームの経験と合っていれば大きな問題ではないケースも多くあります。
2. コード品質と設計方針
次に見るのは、ソースコードそのものです。 行数やファイル数といった表面的な情報だけでなく、「変更がどれだけ怖くないか」 を中心に評価します。
- 責務ごとにファイル・コンポーネントが分割されているか
- コピー＆ペーストの多用や、巨大なGodクラスの有無
- 命名規則・ディレクトリ構造に一貫性があるか
- ビジネスロジックとUIロジックが混在しすぎていないか
完璧なクリーンアーキテクチャを求める必要はありませんが、「どこを触れば何が起きるかが読み取れるか」は重要です。ここが読めない場合、 買収後の機能追加や法対応のたびに大きなリスクを抱えることになります。
3. テストとリリースプロセス
SaaSを引き継いだあと、安全に変更できるかどうか を左右するのがこのパートです。 テストコードの有無だけでなく、実際の運用フローも含めて確認します。
- 単体テスト・統合テスト・E2Eテストの有無とカバレッジ感
- 本番リリースまでの流れ（ブランチ運用・レビュー・CI/CD）
- 障害発生時のロールバック手順や対応フロー
テストが薄い場合でも、「どの範囲からテストを足せば現実的か」を見立てることで、買収後1〜2年の改善ロードマップに落とし込むことができます。 その意味で、技術DDは「買わないためのチェック」だけでなく、「買ったあとにどう改善するかの設計」でもあります。
4. インフラ構成と運用コスト
インフラは、毎月の固定費と運用リスク に直結します。 Cloud Providerやマネージドサービスの選定だけでなく、 実際の課金状況や監視体制も含めて確認します。
- 本番・ステージング環境の有無と分離のされ方
- インフラコストの大まかな内訳と、売上に対する比率
- 監視・アラート・ログ収集の有無
特に小規模SaaSでは、売上に比してインフラコストが高止まりしているケースも少なくありません。 技術DDでは、「構成を少し整理するだけでどの程度コストを落とせるか」の見込みまでセットで評価することが重要です。
5. セキュリティと継続性（バス係数）
最後に、サービスを安心して預かれるか という観点で、 セキュリティと「人」にまつわる継続性を確認します。
- 認証・認可まわりの実装と、権限設計の有無
- 個人情報・決済情報などセンシティブデータの扱い
- ドメイン・リポジトリ・各種SaaSの権限管理と引き継ぎのしやすさ
- バス係数（特定の1人が抜けた瞬間にサービスが止まるリスク）の大きさ
セキュリティは「完璧かどうか」ではなく、「重大な穴がないか」「どこから手当てすべきか」を見極めることが現実的です。技術DDのレポートでは、 優先度順に改善案を提示することで、買収後の投資計画づくりを支援します。
技術DDの結果をどう意思決定につなげるか
技術DDのゴールは、「買う／買わない」だけではありません。 実務では次のような形で意思決定につなげていきます。
- 買収の是非そのもの（地雷案件でないか）の判断
- 価格レンジの調整（技術負債や追加投資コストを織り込む）
- 買収後1〜2年の技術投資計画・チーム体制の見立て
- 契約条件（表明保証・移行期間・オーナーの関与期間など）への反映
ライチョウテックパートナーズでは、 こうした技術DDの観点を「投資判断にそのまま使えるレポート」として整理し、買い手・売り手・仲介の三者が同じ前提に立てるよう支援しています。