はじめてのIT-DD発注ガイド——非エンジニアがシステムDDを外注する進め方

経営企画の担当者が、上司から「対象会社のITも一応見ておいて」と言われて固まる場面を、筆者は何度も見てきた。財務や法務なら顧問の税理士・弁護士という相談先が思い浮かぶ。だがシステムとなると、社内にエンジニアもいなければ、誰に何を頼めばいいのかの見当もつかない。サーバーの話なのか、セキュリティの話なのか、それとも毎月払っているクラウド代の話なのか——言葉の粒度すら掴めないまま、とりあえず数社に相見積もりを取ろうとして、返ってきた見積書を見比べても何が違うのか分からない。

IT-DD（システムDD、ITデューデリジェンス）の発注が難しいのは、発注者自身が「何を調べてほしいか」を言語化できないからだ。財務DDなら「正常収益力を見てほしい」と言える。だがITは、見るべき領域が基幹システム・技術的負債・セキュリティ・開発組織・SaaSのコストと幅広く、しかもそれぞれ専門性が分かれている。全部に同じ深さで踏み込めば費用は跳ね上がり、絞りすぎれば肝心のリスクを見逃す。発注者に必要なのは、自分でコードを読む知識ではなく、「どの領域に重心を置き、何を外に出し、何を自社で確かめるか」を判断する地図だ。IT-DDそのものの中身——調査範囲や典型的な盲点——はIT-DDとは何かの記事に譲り、ここは発注する側の立ち回りに絞る。

あなたが今抱えている案件で、「IT-DDで何を確認したいのか」を一文で言えるだろうか。それとも、業者に「一式お願いします」と丸投げしようとしていないだろうか。

「ITが分からないから全部プロに」と考えると、費用が膨らむだけでなく、発注者が報告書を理解できないまま受け取って終わる。逆に、非エンジニアでも自分の手で確かめられる領域は意外と多い。まず、その線をはっきりさせておきたい。

外注すべきは、専門的な判断が要る領域だ。基幹システムが事業を支えきれているか、技術的負債がどれだけ将来コストとして潜んでいるか、セキュリティの防御態勢に穴がないか、開発が特定のエンジニアに属人化していないか、SaaSの構成とコストが事業規模に見合っているか——これらは、コードや運用の中身を読み解く経験がないと評価できない。ここを素人判断で済ませると、買収後にPMIで跳ね返ってくる。

一方、発注者が自社で集められる情報もある。たとえば対象会社が契約しているSaaSの利用料一覧。経理の支払明細や法人クレジットカードの明細を時系列で並べれば、IT専門家でなくても「毎月どんなツールに、いくら払っているか」は把握できる。退職した社員のアカウントが残っていないか、管理者権限を誰が持っているかといったアカウント管理の状況も、対象会社の総務や情シス担当に質問票で聞けば、相応に見えてくる。こうした一次情報を発注者側で先に揃えておくと、外注先の作業は「判断」に集中でき、結果として見積もりも下がる。

この線引きは絶対ではない。買い手側にIT経験者が一人でもいれば、自社で見られる範囲は広がる。逆に対象会社のシステムが事業の中核そのものなら、SaaSコストの整理すら外注に含めて精度を上げたほうがいい場合もある。自社対応と外注の一般的な切り分けは自社か外注かの記事に整理しているので、IT以外の領域も含めて線を引きたいときに読んでほしい。

相見積もりを取っても、金額だけ見比べていては選べない。同じ「IT-DD一式」でも、調査の深さがまるで違うからだ。非エンジニアの発注者でも、次の4点を聞けば、見積もりの中身を比較できる。

まず確かめたいのが調査範囲、つまり5領域（基幹システム・技術的負債・セキュリティ・開発組織・SaaSコスト）のどこまで含むのかだ。意外なことに、「全部見ます」と言う業者ほど各領域が浅いことがある。次に、ソースコードまで見るのかを聞く。ドキュメントとヒアリング中心なのか、実際にコードをレビューするのかで精度は変わるが、コード監査は精度が上がるぶん費用も上がるので、案件の性質で要否を決めればいい。三つ目に、セキュリティ診断の有無を確かめる。脆弱性スキャンやペネトレーションテストを含むのか、それともヒアリングで「対策していますか」と聞くだけなのか——この差は大きい。そして四つ目が、PMIの統合コスト試算まで出るのかどうか。リスクの指摘で終わるのか、「買収後にシステム統合へいくらかかるか」の概算まで出すのかを、ここで切り分けておく。

最後の「統合コスト試算」が、発注者にとっては最も価値が出やすい。IT-DDの本当の目的は、アラ探しではなく「買収後にそのITと一緒にやっていけるか、いくらかかるか」を見積もることだからだ。リスクのリストだけ渡されても、価格交渉には使いにくい。「この技術的負債を解消するのに買収後◯◯万円」と金額に翻訳されて初めて、提示価格を動かす材料になる。

費用そのものの相場観——簡易レビューで数十万円、標準的なIT-DDで100万〜300万円前後、コードレビューや第三者診断まで含めると300万円超——はDD費用相場の記事に整理している。ここで強調したいのは、金額の大小よりも「その金額で何が含まれ、何が含まれないか」を見積書の段階で確定させることだ。スコープが曖昧なまま発注すると、「それは追加です」と後から請求が膨らむ。

「ITが分からない発注者が、安い業者を選んだら品質が落ちるのでは」——もっともな心配だ。だが安さと品質がトレードオフになるのは、人の作業と機械でいい作業を分けずに、すべてを人月で積み上げるからだ。IT-DDの工程を分解すると、AIに任せてよい部分と、経験者でないと務まらない部分にきれいに分かれる。

AIで圧縮できるのは、定型的な情報処理だ。契約書や利用規約のスクリーニング——支配権変更で失効する条項がないか、ライセンスの利用範囲を超えていないかを、大量の文書から拾い出す作業。システム構成図や運用ドキュメントの横断整理。SaaSの課金明細を名寄せして、どのツールにいくら払い、いつ急増したかを分析する作業。これらは従来、ジュニアのコンサルが何十時間もかけていた工程で、ここをAIで圧縮すれば、その分の人件費が見積もりから消える。

一方で、AIに渡せない判断がある。IT-DD特有なのは、AIが扱えるのは「履歴に残った形式知」だけで、リスクの多くはそこに残らない暗黙知に潜む点だ。たとえばコミット履歴をAIに解析させると、「誰がどのファイルを何回触ったか」は集計できる。だが、それは属人性の影ではあっても実体ではない。実際には、コミット数の少ないベテランが設計の意図を一人で握っていて、量産的なコミットを積むメンバーはその枠内で手を動かしているだけ、という構図がよくある。コミット数だけ見れば「分散している」ように映るのに、抜けたら止まるのは前者だ。この逆転は、本人や周囲に「なぜそう作ったのか」を聞いて初めて見える。同じく、そのコードの品質が本当に問題なのか中小では許容範囲なのか、あるシステムが止まったとき業務がどれだけクリティカルに止まるのか——こうした評価は、コードの外にある事業文脈と照らさないと出ない。AIは「サポート切れのライブラリが12個ある」とは出せても、「そのうち事業に致命的なのはこの2個」とは判断できない。後者の線引きには、最低でも数件のIT-DDを回した経験が要る。

• AIが握る：契約書・利用規約のスクリーニング、ドキュメントの横断整理、SaaS課金明細の分析・異常検知、コミット履歴の集計（誰が・どこを・何回）
• 人（経験者）が握る：コミット数の裏にある設計意図と属人性の見極め、コード品質の妥当性判断、業務クリティカル度の評価、マネジメントインタビュー、最終判断

この分担があるから、非エンジニアの発注者でも、大手にフルスコープで頼むより安く、しかも品質を落とさずにIT-DDを回せる。工程ごとに「どこを機械が、どこを人が」を切り分ける考え方の全体像はAIで安く速いのに品質が落ちない理由の記事で開示している。発注前に「なぜ安くて品質が保てるのか」を腹落ちさせたい方は、そちらを先に読んでほしい。

IT-DDの報告書を受け取って「リスクがあると分かりました」で止めてしまっては、かけた費用が回収できない。発見した論点は、価格交渉か契約条項のどちらかに必ず落とす。これが発注者の最後の仕事だ。

典型的な反映の仕方は、おおむね三つに分かれる。一つは、属人化したキーエンジニアのリテンション（残留）を契約条件にすること。主要機能を特定の人物が一人で抱えている場合、その人が抜ければシステムは事実上止まる。だから一定期間の残留と引き継ぎを、株式譲渡契約の前提条件やアーンアウトに組み込む。二つ目は、技術的負債を価格に反映すること。買収後に古いシステムの刷新が避けられないなら、その想定コストを買収価格から差し引く交渉材料にする。三つ目は、シャドーITやライセンス違反といったクリーンアップを表明保証や前提条件に入れること。

ここで、発注者が陥りやすい二つの極を指摘しておきたい。一つは「動いているから大丈夫」という思い込みだ。デモで正常に動いていても、その裏でサポート切れのライブラリが使われていたり、たった一人のエンジニアが支えていたりする。「今動いている」と「これから問題が起きない」は別の話だ。もう一つは逆方向で、中小案件で過剰なコード監査を発注してしまうこと。買収額が数千万円規模の案件で、数百万円のフルコード監査をかければ費用倒れになる。論点を「この案件の急所はどこか」に絞り、そこにだけ深く踏み込むのが、発注者の腕の見せどころだ。

価格への落とし込みそのものに自信がなければ、買収価格の決め方の記事もあわせて読むといい。IT-DDの発見をバリュエーションの前提にどう織り込むかは、財務DDの数字と並べて考える論点だ。

ここまで「論点を絞れ」と繰り返してきたが、絞ることと省くことは違う。絞るのは深さの配分で、省くのは領域そのものを見ないことだ。非エンジニアの発注者が最も迷うのが、どの領域なら削っていいのかの判断だろう。

筆者の経験では、案件の性質で削っていい領域は変わるが、セキュリティ診断だけは安易に省くべきでないと考えている。技術的負債やコード品質の精査は、システムが事業の中核でない案件なら簡易レビューに留めても大きな失敗にはなりにくい。だがセキュリティは、過去のインシデントや認証情報の流出が、買収後に時限爆弾として顕在化する。しかも被害が出れば金額が読めない。「ヒアリングで対策状況を聞いただけ」で済ませた結果、買収後に痛い目を見た例を、筆者は複数知っている。

セキュリティの調査をどこまで踏み込むか——ヒアリングで足りるのか、脆弱性スキャンが要るのか、第三者のペネトレーションテストまで必要かは、対象会社が扱うデータの機微さで変わる。サイバー領域に特化した調査の設計はサイバーDDの記事に、SaaS事業を対象にするときの指標の見方はSaaSのDD指標の記事に整理している。発注の前段で「そもそもM&A全体を誰に頼むか」から迷っているなら、はじめてのM&A・誰に頼むかの記事を起点にするといい。