技術デューデリで見られること

技術デューデリジェンスという言葉には、身構えさせるところがあります。実際にはコードの一行ずつを審査されるわけではなく、限られた時間で「このプロダクトと組織に、将来どんなリスクがあるか」を推し量る作業です。

本記事では、投資家や買い手が何を確かめようとしているのかを、質問の意図から整理します。調達前にやっておく準備の手順は資金調達前に整えておきたいプロダクトと技術面の準備にまとめているため、ここでは「見る側が何を見ているか」に絞ります。

見られているのは完成度ではない

まず押さえておきたいのは、評価されるのが技術の高度さでも、コードの美しさでもないということです。見る側の関心は、おおむね次の三つに集約されます。

• 事業計画にある成長を、この構成と体制で支えられるか
• 買収や増資の後に、想定外の追加投資が必要になる要素はないか
• 特定の個人が離れたときに、開発が止まらないか

言い換えると、見られているのは把握の度合いと再現性です。課題があること自体は織り込み済みで、成長中のプロダクトに課題がないほうが不自然です。問題視されるのは、把握していない課題が調査の過程で出てくることです。

この違いは回答の仕方に表れます。「決済まわりの重複処理に既知の課題があり、暫定の運用対策を取っていて、調達後の四半期で改修する計画です」という回答と、「特に問題は認識していません」と言った後に調査で同じ課題が見つかる展開では、受け取られ方が違います。後者は、その一件だけでなく「ほかにも知らないことがあるのでは」という疑いを生みます。

よく問われる論点

実務でよく確認される領域を、質問の意図とあわせて整理します。

この表の右列が、実際に評価されている内容です。左列の質問に答えるだけでなく、右列の懸念に答える形で説明すると、会話が速く進みます。

答えに窮しやすい質問

経験上、準備が手薄になりやすく、その場で答えに詰まりやすい質問がいくつかあります。

「この部分を触れるのは何人ですか」 機能ごとに担当が固定されている体制では、特定の領域を一人しか触っていないことがあります。これ自体は小規模なら普通のことですが、把握していないと答えられません。事前に、領域ごとに「触ったことのある人」を数えておくと、そのまま回答になります。

「環境を一から作り直せますか」 本番環境が手作業の積み重ねでできている場合、再構築の手順が誰の頭の中にもないことがあります。完全な自動化までいかなくても、手順が文章か設定ファイルとして残っているだけで回答は変わります。

「復元を試したのはいつですか」 バックアップを取っているかは多くの会社が答えられますが、復元を実際に試したかとなると答えが止まります。取得しているだけで復元できないバックアップは、ないのと大きく変わりません。

「この外部サービスが止まったら何が起きますか」 決済、認証、メール配信、AIのAPIなど、依存先は多岐にわたります。それぞれについて、止まったときの影響範囲と代替の有無を整理しておくと、非機能要件への理解を示すことにもなります。

「その数字はどう計算していますか」 技術の質問ではありませんが、技術側に投げられることが多い問いです。指標の定義と計算方法が、担当者によって違わないことが確かめられます。

生成AIが関わる部分の扱い

近年、確認項目として加わってきたのが、開発に生成AIをどう使っているかです。ここでの論点は、使っているかどうかではなく、次の三点です。

• 生成された成果物が、人のレビューを経て採用されているか
• 利用したサービスの規約と、入力内容の扱い（学習への利用の有無など）を確認しているか
• 社内ルールが文章として存在し、実態と一致しているか

プロダクトの機能として外部のAI APIを使っている場合は、これに加えて、費用が利用量に比例して増える点と、提供事業者の仕様変更に対する備えが問われます。また、顧客のデータを外部のAPIに送っているなら、何を送っているか、利用規約上それが許されているか、顧客に説明しているかが確認されます。ここは技術というより契約と個人情報保護の領域に踏み込むため、専門家の確認を得ることをおすすめします。開発工程での生成AI活用の原則は生成AIを開発工程に組み込むに、データの扱いはスタートアップのセキュリティと個人情報保護にまとめています。

直前の準備で間に合うもの、間に合わないもの

現実的な話として、調査が始まると決まってから整えられるものと、そうでないものがあります。

直前でも間に合うもの：構成図、指標の定義書、既知の課題の一覧と対応計画、権限の棚卸し、依存している外部サービスの一覧、契約書の整理。これらは棚卸しと文書化の作業であり、数週間で形になります。

間に合わないもの：障害の記録、変更の履歴、テストの蓄積、検証と配信の自動化（CI/CD）、レビューの運用。これらは日々の積み重ねの結果であり、直前に作ると「直前に作った」ことが分かります。

したがって、後者は調達やM&Aのためにやるものではなく、開発を続けるための運用として先に入れておくものです。結果として調査に耐える状態になっている、という順序が自然です。逆に言えば、後者が整っていないことに調査の場で気づいたなら、それは調査対応の問題ではなく、日常の開発の問題です。

分からないことを分からないと言える状態にする

最後に、態度の話をします。調査の場で最も避けたいのは、答えに詰まったときに推測で答えることです。後の確認で食い違いが出ると、その一点だけでなく、他の回答の信頼性も下がります。

「今は把握していないので、確認して回答します」と答えられることが重要です。そのためには、外部の開発パートナーを使っている場合、調査期間中に短時間で確認が取れる関係が要ります。契約に、資料提供や質問対応をどう扱うかが書かれているか、事前に確かめておいてください。

技術デューデリの準備をどこから始めるか、あるいは現状で何が説明できない状態かを外部の目で確かめたい場合は、開発チーム構築支援やWebシステム開発の観点から状況を伺います。お問い合わせからご相談ください。ご相談・お見積りは無料です。

なお本記事は一般的な情報です。契約、知的財産、個人情報の取り扱いに関わる事項は、個別の事案について弁護士等の専門家にご確認ください。