投資活動は現在低迷していますが、2023年には回復する見込みです。そして、投資が活発化すれば、M&Aも活発化します。あなたの組織とコードは、あなたの番が来た時にテクニカルデューデリジェンスを通過できるでしょうか？
まずは良い点から始めましょう。投資家がテクニカルデューデリジェンス（TDD）を進めている場合、おそらく合格するでしょう。製品市場適合性、財務状況、競争上の差別化といったテストを十分にクリアしているため、投資家はより詳細な調査に着手したいと考えています。
あまり良くないニュースもあります。ビジネステストは合格しても、TDDでは不合格になる企業があります。特に技術系ではない経営幹部にとって、コード検査プロセスはまるで…まるで別の言語で行われる監査のように、そして絶え間なく時を刻む大きな時計のように感じられるかもしれません。決して楽しいものではありません。
当社は、3人規模のソフトウェア企業から数千人の開発者を抱える企業まで、数千億ドル規模の取引のコードを分析してきました。20万人以上の開発者が書いた合計40億行のコードを分析し、その貢献度を検証してきました。
このデータセットから、今すぐ自問自答できる8つの質問を抽出しました。TDDが近い将来に導入される予定がなくても、これらの質問に適切な答えを用意しておくことで、コードベースの健全性を確保できます。
TDDの簡単な入門
先に進む前に、ソフトウェアの技術的デューデリジェンスについてもう少し詳しく説明します。
- TDD は、従来のソフトウェア企業と、カスタム作成されたソフトウェアによって実現される非ソフトウェア企業に適用されます。
- 従業員または請負業者によって書かれたコードの検査が含まれます。
- TDD は社内の専門家または専門コンサルタントによって実施されます。
- 投資家や買収者、特に大規模でエリートな投資家や買収者は、定性的なインタビューを補完するために、定量的なコードスキャンの実施を求めることがあります。投資家が取引において保証保険（RWI）を希望する場合、このようなコードスキャンは事実上必須となります。
TDD の目標は次のとおりです。
テッククランチイベント
サンフランシスコ | 2025年10月27日～29日
- コードベースが投資に十分安全であるかどうかを判断して、取引のリスクを軽減します。
- 取引が成立した場合の改善の機会を特定します。
「コードベース」と呼ぶのは、拡大鏡の下にあるのはソースコードだけではないからです。ドキュメント、プロセス、そして最も重要なのは、ソフトウェア開発者も検査対象となります。TDDの機能的範囲には、コード品質、コードセキュリティ、知的財産、DevOps、IT、そして場合によっては製品管理も含まれます。
コードの品質だけではないので、これらすべての領域を網羅してコードベースの健全性について話します。
質問 1: 何に取り組んできましたか?
組織が最も重要なソフトウェア製品に取り組んでいることを確認することは、取引のリスクを軽減する上で重要な要素です。
これは当然のことのように聞こえるかもしれませんが、時には、企業が新製品の開発に取り組んでいると主張していても、実際には主要クライアント向けのカスタム開発にほとんどの時間を費やしていたり、ほとんど何も開発していなかったりすることがあります。
ある企業の2年間にわたるソフトウェア開発の例を考えてみましょう。作業量には周期性（夏季に増加）があるだけでなく、特に2022年には大幅に減少しています。
重要な点: ここでも、TDD のすべての質問でも、どのような回答でも試験に合格できる可能性があります。
これがTDDテーマ1につながります。TDDの最も重要な部分は、コードベースの状態が組織のビジネス目標と一致していることを確認することです。例えば、米国の教育ソフトウェア企業では、新学期の開始に伴う顧客への影響を最小限に抑えるため、夏季に開発量を増やし、秋季に開発量を減らすという周期的なソフトウェア開発が一般的です。
質問 2: コードベースにはどの程度のユニット テストがありますか?
私たちは、保守性や拡張性などの基準を含む基礎的なコード品質と、製品がユーザーにとってどのように機能するかという機能的なコード品質を区別することを好みます。
「技術的負債」とは、基礎となるコードの不完全さを別の言い方で表したものです。
コードベースの基礎となるコード品質が完璧であるものは存在しないため、すべてのコードベースには技術的負債があると言えるでしょう。技術的負債がなければ、何もリリースされず、開発チームはコードの修正にのみ取り組むことになります。
これは、TDD テーマ 2 につながります。コードベースの健全性は状況に依存し、TDD をクリアするために必要な「万能」なレベルはありません。
問題は、技術的負債の量が、コードベースと会社の段階、規模、そして業種に適切であるかどうかです。写真から植物を識別する作業に5人の開発者が取り組んでいるシリーズA企業（もしあなたの会社なら、ぜひ声をかけてください！）は、規模を調整した場合でも、後期段階にある大規模なフィンテック企業よりも、はるかに多くの技術的負債を抱えていると予想されます。
技術的負債の中でも特によくあるのは、テスト、特にユニットテストの不足です。ユニットテストは開発者が迅速にコードを書くための助けとなるため、ユニットテストの欠如はチームの速度に悪影響を及ぼします。
しかし、技術的負債の解消に投資するには時期尚早かもしれません。まだ製品市場適合性の向上や新機能の改良に取り組んでいる段階であれば、ユニットテストの追加は時間の無駄であり、過剰なエンジニアリングのリスクを示唆することになります。
勤勉さにおいては、コードベースのテスト レベルにどのように到達したか、またそれがアプリケーションによってどのように異なるかを説明するよう求められます (うまくいけば、質問 #6 を参照してください)。
質問 3: セキュリティ プログラムは会社の成熟度に適合していますか?
私たちのデータは明白です。ほぼすべてのソフトウェア製品にはセキュリティ上の脆弱性があります。
技術者以外の方には意外に聞こえるかもしれませんが、ソフトウェアエンジニアは、コードを出荷しながらすべてのセキュリティ問題が本番環境に到達するのを防ぐことは事実上不可能であることを知っています。投資家や買収者もこのことを熟知しています。そのため、彼らは潜在的なセキュリティ問題の数と深刻度に関心を持ち、取引後のクリーンアップを最優先に考える一方で、セキュリティリスクを文脈の中で捉えます。
新興企業、新製品、そして低リスク／規制の少ない業界を対象とする製品の場合、一般的に高いレベルのセキュリティリスクは許容されます。そのため、他の種類の技術的負債と同様に、セキュリティリスクへのアプローチが、貴社の事業段階、規模、そして業種にどのように合致しているかを説明することが求められます。
現在239件のセキュリティ警告がある企業の例を、コードに導入された時期別にグラフ化しました。239件の警告のうち、過去6ヶ月間に導入されたのはわずか12件、つまり5%です。つまり、セキュリティ警告の95%は6ヶ月以上コードに存在し、45%は2年以上コードに存在していることになります。
このデータから、既存のセキュリティ警告の発見と修正が優先事項ではないことが明らかです。TDDの合格にそれが許容されるかどうかは、ビジネスコンテキストによって異なります。
質問 4: 建物内にその分野の専門家はいますか?
投資家や買収者はコードだけを気にする、というのはよくある誤解です。そして、これがテーマ3につながります。コードベースがTDDをクリアするために最も重要な要素は、コードを作成または保守した開発者が現在も会社で活躍しているかどうかです。
開発者はその理由を知っています。どんなに優れたドキュメントがあっても、コードは文脈やニュアンス、状況に大きく左右されるため、完璧にコード化することは不可能です。コードに積極的に関わっていたエンジニアがいなくなった場合、新入社員のトレーニングには数ヶ月、あるいはそれ以上かかる可能性があります。この遅延は製品ロードマップの目標、ひいてはTDDの成功にも影響を与える可能性があります。
技術系以外で最も近い例は小説の執筆でしょう。たとえ全ての草稿が揃っていたとしても、著者を交代させると執筆速度は劇的に低下し、質と一貫性も著しく低下します。
TDD の例を以下に示します（名前は変更され、データはスタイル設定されています）。このグラフは、開発者のこれまでの作業量、在籍期間、最後にコーディングしてからの経過時間に基づいて、各開発者の作業状況を示しています。
たとえば、Grace はコードへの貢献度が 5 番目に高く、会社に在籍して 328 日が経ち、コード スキャンが行われた当日にコードを記述しました (最後のコーディングから 0 日)。
この図から、コードへの貢献度上位4名が組織を去っている可能性が高いことが明確に分かります。これは取引にとってリスクとなります。コードオーナーは、開発者がなぜ退職したのか（管理部門、製品部門、または他の部門に異動していないと仮定した場合）、そして退職前に会社が知識移転をどの程度適切に行っていたのかを説明できるようにしておく必要があります。
質問 5: 使用しているサードパーティのコードをご存知ですか?
これは引っ掛け問題です。なぜなら、すべてのサードパーティ製コードを把握している人はいないからです。本当の質問は、「サードパーティ製コードの大部分について、リスクを把握し、管理していますか？」ということです。
話を戻しましょう。エンジニアリングチームが新しい製品を開発する際、「構築するか、購入するか」という決断に直面します。「構築」とは、チームがコードをゼロから作成することを意味します。「購入」とは、第三者や組織、つまりサードパーティが作成したコードを使用することを指します。
サードパーティのコードを使用する最も一般的な方法は、商用ライセンスを使用するか、オープンソースコードを参照することです。オープンソースコードは、品質を維持しながら製品ロードマップを迅速に進めるための優れた方法であるため、非常に普及しており、商用コードの96%がオープンソースコードに部分的に依存しています。
問題は、サードパーティのコードには大きなリスクが伴うということです。外部コードは古くなったり、セキュリティ上の脆弱性を含んでいたり、商業的に危険なライセンスが適用されたりする可能性があります。知的財産法の講義で退屈な思いをさせるつもりはありませんが、オープンソースコードの中には、コードを無料で配布しなければならないという厳格な規定が付いているものがあります。これは「コピーレフト」ライセンスと呼ばれます。
開発者は誰でもGitHubやGitLabにアクセスしてオープンソースコードをダウンロードでき、サードパーティのコードの「目次」に追加することなくそうすることができます。つまり、実際には、テクノロジー企業の100%が何らかの未知のオープンソースコードを使用していると考えて間違いないでしょう。
幸いなことに、オープンソースやサードパーティのリスクのほとんどは契約締結後に修正可能なので、未知のライセンスやリスクの高いライセンスが契約を破棄する要因となることは通常ありません。しかし、エンジニアリング部門が使用しているライセンスを把握しておくことは、常に適切なタイミングです。
質問 6: コードベース間で観察された変動を説明できますか?
これまで、コードベースをモノリシックな視点、つまり組織全体のコードを一つのエンティティとして捉えてきました。セキュリティ警告の数や実施されたテストの量などは、コード全体を総合的に見ることで検討できる要素です。
しかし実際には、ほとんどすべての企業のコードは単一のエンティティとしてではなく、サブグループの形で存在します。コードはリポジトリに保存され、1つまたは複数のリポジトリがアプリケーションを構成します。これらのアプリケーション自体は、ライフサイクルの異なる段階にあり、ビジネスにおける重要度も異なります。
潜在的な投資家は、コードベースの構築と保守においてこれらの要素を考慮していることを理解したいと考えるでしょう。エンジニアリングリソースの配分は、計画的かつ綿密に行っていますか？コード品質への投資は、ピーナッツバターのようにばらばらに広げるべきではありません。
売り手がよくある誤解は、古いコードベースが新しいものよりも「見栄えが悪い」（つまり、技術的負債が多い）と会社の評判が悪くなるというものです。しかし、実際はその逆です。ライフサイクルの段階が全く異なるにもかかわらず、品質レベルが同じコードベースが複数ある場合、投資家にとって危険信号となります。
世界がコードで動いており、プログラマーに依存しているのと同じくらい、開発者はビジネスに必要なレベルを超えてコードの品質を向上させる傾向があるからです。（これは理解できる、そして歓迎すべき特性です。結局のところ、コーディングは職人技ですから。）優れた組織は、機能提供のペースと基盤となるコード品質の間で、思慮深くトレードオフを行うことができます。
弊社のデータから得られた、特異な変動の一例をご紹介します。これは、同じ企業が所有する5つのアプリケーションの技術的負債の平均レベル（高いほど悪い）です。どのアプリケーションが将来の投資家から最も注目を集めたか、お分かりでしょうか？
質問 7: 財務部門はテクノロジー負債の防止と修復にどれくらい投資していますか?
これらの質問を読むと、TDDは技術チームだけのものだと思われがちです。CEOやCFOの中には、議論をエンジニアリング部門に任せきりにし、さらに悪いことに、物事がうまくいかないとエンジニアリング部門を責める人もいます。
賢明な投資家ならご存知のとおり、現実はTDD テーマ #4 でもあります。コードベースの健全性は、エンジニアリングだけでなく組織全体によって推進されます。
営業、財務、製品、CEO、エンジニアリング責任者はそれぞれ、たとえば、エンジニアリングが毎年ロードマップの一定の割合をセキュリティ警告の発見と修正に投資することを許可するかどうかや、営業がロードマップに関して土壇場で要求し、コードベース投資の優先順位が下がった場合にどうするかなどの決定に貢献できます。
さらに一歩進んで考えてみましょう。コードベースの健全性が低いのは、多くの場合、エンジニアリングではなく他のチームに「起因」しています。私たちの経験上、開発者はほとんどの場合、コードをより良くしたいと考えています。
したがって、デューデリジェンス セッションで質問に答える責任がある技術リーダーであれば、ストレスがたまる作業ではありますが、深呼吸をして、それが自分だけの問題ではなく、組織全体に関する会話であることを思い出してください。
質問 8: 学び、成長する準備はできていますか?
TDD は滅多に楽しい経験ではないと、率直に申し上げたいと思います。出口戦略や次の資金調達ラウンドに進むには、信じられないほどの努力と犠牲が伴います。そして、これほど大きなリスクを伴う外部の人間に自分の成果を評価するのは、神経をすり減らす以上の苦痛です。
技術的な質問に加え、TDD がリーダーシップチームの評価でもあるため、さらに難しくなっています。リーダーシップチームは、皆さんがどのように対応したか、回答がどれだけデータに基づいているか、そしてリスクと改善策をどれだけ慎重に評価したかを評価します。
私たちからの最良のアドバイスは、面接官と「同じテーブルに座っている」と想像することです。コードベースの現状、強み、改善点を把握するための演習に、面接官と共に取り組んでいるのです。
もちろん、取引が成立するまでは、交渉には双方の立場があることは承知しています。しかし、TDDまで到達できれば、取引成立のための他の条件は満たされている可能性が高いでしょう。あなたが思慮深い問題解決者であり、コードベースの状態を的確に把握し、フィードバックを受け入れる姿勢を示すことで、投資家や買収者は、あなたが避けられない改善を主導できるという確信を持つでしょう。そして、それは取引成立の可能性をさらに高めるだけです。
結論は
デューデリジェンスが間近に迫っているなら、これらの質問について一晩だけでも考えておくことで、最終的に直面した時に、より適切な対応ができるようになります。そして、少しでも楽にするために、直面する可能性のある質問をさらに網羅したチェックリストを用意しました。
要約:
- テーマ 1: TDD の最も重要な部分は、コードベースの状態が組織のビジネス目標と一致していることを確認することです。
- テーマ 2: コードベースの健全性は状況に依存し、TDD をクリアするために必要な「万能」なレベルはありません。
- テーマ 3: コードベースが TDD をクリアするための最も重要な要素は、コードを作成または保守した開発者がまだ会社で活動しているかどうかです。
- テーマ 4: コードベースの健全性は、エンジニアリングだけでなく組織全体によって推進されます。
たとえ技術デューデリジェンスのプロセスが近々導入される予定がなかったとしても、これらの質問は経営陣が定期的に検討し、組織の慣行を調整するために活用する上で有益なものです。優れた投資家が重視するコードベースの健全性に関する基本的なテーマは、優れたビジネスを支えるコードの作成に役立つ運用上および戦略上の意思決定でもあるからです。
技術デューデリジェンスを受けるスタートアップのための準備チェックリスト
