技術デューデリジェンスで分かる、プロダクトの運用可能性

技術デューデリジェンスは、最も流行しているアーキテクチャや、最も高いテストカバレッジを競う場ではありません。技術が理解可能な資産か、会社が運用を続けられるか、既知のリスクが取引や投資計画へ反映されているかを確認するものです。

優れた資料は、システムが完璧だとは主張しません。重要な判断、弱点、責任が見える状態であることを示します。

プロダクトの運用モデルから始める

どう作られたかを評価する前に、技術が何に責任を持つかを理解する必要があります。

冒頭の資料には、次を示します。

• 誰がプロダクトを使い、運用するか。
• 事業上重要なワークフロー。
• プロダクトが管理する情報。
• 重要経路にある外部システム。
• 停止、データ損失、誤動作の影響。
• 規制・契約上の制約。
• デプロイとサポートの方法。

この文脈がなければ、アーキテクチャ図はリスクに基づく判断ではなく、一般論の批評を招きます。

アーキテクチャの根拠

最新のシステム図には、顧客画面、社内ツール、サービス、データベース、キュー、外部依存、デプロイ環境といった重要な境界を示します。

レビューする人が、図と文章の判断を結びつけられるようにします。

• なぜこの境界があるか。
• どの部分が変更しにくいか。
• 状態はどこにあるか。
• どの依存が中核成果を止めうるか。
• どの部分を意図的に単純にしているか。
• 何を置き換える予定か。

複雑さは成熟度ではありません。明示的な境界を持つ小さなシステムは、誰も挙動を説明できない分散システムより安全なことがあります。

アクセスとデータの根拠

認証だけでは、情報が適切に保護されている証明になりません。

次を確認します。

• 役割と組織の境界。
• 特権アクセスとサポートアクセス。
• 機密データの一覧。
• 保存時・通信時の保護。
• 保持と削除の挙動。
• バックアップと復元の根拠。
• 本番データへのアクセスログ。
• 漏えい・インシデント対応手順。
• 顧客ごとの約束。

重要なのは、特定ベンダーやトークン形式を使っているかではなく、実際のプロダクトリスクに統制が合っているかです。

デリバリーと復旧の根拠

リリース基盤は、会社がプロダクトを制御したまま変更できるかを示します。

有用な根拠には、次が含まれます。

• コードが各環境へ届く方法。
• リリースを承認・開始できる人。
• 設定とシークレットの境界。
• データベースマイグレーションの挙動。
• 重要経路の自動チェック。
• リリースとインシデントの履歴。
• 顧客成果に結びついた監視。
• バックアップ復元や災害復旧訓練。
• 最近のロールバックや修復例。

Lane Technologiesでは、買収時の技術デューデリジェンスでリリース基盤が確認されました。価値は、特定ツールを導入していたことではありません。プロダクトデリバリーを信頼可能にし、会社の技術的な挙動を検証可能にしたことにありました。

コードと依存関係の根拠

ソースレビューは、重要な境界と変更コストに集中します。

• ビジネスルールがどこにあるか。
• アクセス判断が一貫して強制されているか。
• 重要な成果に信頼できる検証があるか。
• 同じ問題に複数の実装パターンが混在していないか。
• 重要な依存関係の状態。
• 小さな変更が不釣り合いなリスクを生む領域。
• 生成・継承されたコードに、明確な所有者とレビュー履歴があるか。

単一のカバレッジ数値では答えられません。お金の移動や認可を確認する精密な10件のテストは、浅いコンポーネントテスト数百件より強い根拠になりえます。

責任と継続性の根拠

一人が不在でも、会社は運用を続けられる必要があります。

知識を均等に分散する必要はありません。重要な責任とアクセスを見える状態にします。

• システム・運用文書。
• 重要な判断の意思決定記録。
• サービスと外部アカウントの所有者。
• オンボーディングと復旧手順。
• ベンダーと契約者の現在の責任。
• 知的財産の譲渡。
• オープンソース・商用ライセンスの一覧。
• 一人に依存する既知の領域への計画。

専門性があること自体はリスクではありません。会社がそれを特定・移転できないことがリスクです。

既知のリスクと改善

信頼できる技術チームは、時間があれば何を変えるか、どのリスクを受け入れているか、どの根拠があれば判断を変えるかを説明できます。

有用なリスク台帳には次を書きます。

1. 運用上の影響。
2. 現在の発生可能性と根拠。
3. 既存の統制。
4. 提案する改善。
5. コストまたは順序への影響。
6. 責任者。

これにより、投資家や買収者は、すべての不完全さに全面的な作り直しが必要だと決めつけず、必要な作業を評価できます。

読みやすいエビデンスルームを準備する

簡潔な技術エビデンスルームには、次を含められます。

• プロダクトと運用の概要。
• 現在のアーキテクチャ図。
• データとアクセスモデル。
• 環境とリリースの説明。
• インシデントと復旧の履歴。
• 重要なテストとセキュリティの根拠。
• 依存関係とライセンスの一覧。
• チームとアカウントの所有者。
• 既知リスクの台帳。
• 直近の技術計画。

各文書に所有者と改訂日をつけます。認証情報、本番シークレット、不要な顧客データは置きません。

結果は意思決定を支えるべき

良いデューデリジェンスは、次の状態を区別します。

• 通常の保守だけが必要な健全なシステム。
• 特定の修復可能なリスクを持つ価値あるプロダクト。
• 成長前に運用モデルを変える必要があるシステム。
• 取引条件を大きく変える技術的負債。

目的は、すべての技術リスクをなくすことではありません。プロダクトを運用する能力と改善コストを、合理的な事業判断ができるほど明確にすることです。