「財務や法務のデューデリジェンス（DD）は専門家に任せた。でも、買った会社のシステムって、いったい何を・どこまで見ればいいのか」——M&Aの買い手側で、IT面の調査だけがぽっかり抜けている、という相談をよく受けます。

IT デューデリジェンス（IT-DD）が薄いまま買収を進めると、クロージング後に「基幹システムが特定の社員のExcelマクロ頼みだった」「ライセンスが実は無効だった」「サーバーの保守が切れていた」といった“想定外”が次々に噴き出します。そのたびに数千万円規模の追加投資や、統合（PMI）の遅延を招きかねません。

結論から言えば、ITデューデリジェンスの進め方の核心は、「買収後に効いてくるIT論点を、統合を前提に、買う前に洗い出しておく」ことです。本記事では、公的・専門家の解説に加え、私たちキュリオシティが情報システム領域のBPR（業務改革）やシステム統合支援の現場で使っている「現状調査の観点」を買収前調査に転用する形で、情報システムの何を・どう見るかを具体的に解説します。

結論：IT-DDの進め方とは「買収後に効くIT論点を、統合前提で先に調べる」こと

ITデューデリジェンスを「システムの粗探し」だと捉えているうちは、うまくいきません。IT-DDの目的は、次の3つを買収前に見極めることです。

• 隠れたコスト：買収後に必要になる更新・改修・保守の追加投資はいくらか
• 事業継続リスク：担当者の退職やシステム老朽化で、業務が止まらないか
• 統合の難易度：自社（買い手）のシステムと、どれだけスムーズに統合できるか

つまりIT-DDは、単独で完結する調査ではなく、その先にあるPMI（買収後統合）を見据えた“準備作業”です。買収後にシステムをどう統合するかという出口から逆算するからこそ、買収前に「何を見るか」が定まります。この視点が抜けると、調査項目を機械的に埋めるだけの“やっただけIT-DD”に終わります。

進め方は大きく6ステップ（①調査チーム発足→②NDA締結→③調査方針・開示請求リスト作成→④開示資料分析→⑤ヒアリング→⑥報告・取引条件への反映）です。以下、その前提となる「見るべき5領域」から順に見ていきます。

そもそもITデューデリジェンス(IT-DD)とは｜財務・法務DDとの違い

デューデリジェンスとは、M&Aの買い手が対象会社の実態やリスクを買収前に精査する調査全般を指します。財務DD・法務DD・税務DD・ビジネスDDなどがあり、その一領域がIT-DD（ITデューデリジェンス）です。

IT-DDは、対象会社の情報システム・IT資産・運用体制・セキュリティを調べ、「買ったあとで困らないように、システム面のリスクとコストを先に把握する」ことを目的とします。他のDDとの関係は次のように整理できます。

特に財務DDとIT-DDは相互補完の関係にあります。会計や販売のデータがどのシステムでどう作られているかを見ることで、財務数値の真正性やシステム起因の不正リスクまで検証できるからです。なお、IT-DDは調査対象がIT領域に限られるため、財務・法務DDに比べれば買い手の自社人員でも着手しやすい一方、リスク評価のツボは経験がないと外しがちで、実務では外部の専門家を起用するケースが一般的です。

なぜIT-DDは後回しにされ、PMIでつまずくのか

多くのM&Aで、IT-DDは財務・法務の陰に隠れて薄くなりがちです。そこには構造的な理由があります。

1. IT論点が「定性的で見えにくい」から

財務や法務は数字と書面で語れますが、ITの実態は「担当者しか分からない」「ドキュメントがない」といった定性的な世界に埋もれています。開示資料をそろえても、実際の運用は現場ヒアリングでしか見えません。だからこそ後回しにされ、結果としてPMIの初日に問題が噴き出します。

2. 中小企業では「IT担当が兼務・不在」だから

中小企業では、社長や経理部長がITを兼務していたり、そもそも専任のIT担当がいなかったりするケースが少なくありません。この場合、社内ヒアリングだけでは実態がつかめず、外部ベンダーを巻き込まないと本当のリスクが見えてきません。

3. 「調べる」と「統合する」が分断されているから

IT-DDで見つけたリスクが、統合フェーズに引き継がれず、報告書の中で眠ってしまう。するとPMIの失敗事例で繰り返し登場する「システムが統合できずシナジーが出ない」という事態に直結します。IT-DDは、発見したリスクをそのまま統合課題に翻訳できて初めて意味を持ちます。

ITデューデリジェンスで情報システムの「何を見るか」｜5つの調査領域

ここが本記事の核心です。買収前に情報システムの何を見るのか。私たちが情シスBPRやシステム統合支援の現場で使っている現状調査の観点を、買収前調査（IT-DD）向けに5つの領域へ整理しました。

①基幹システム（安定性・拡張性・属人代替）

販売・会計・生産などの基幹システムが、事業の規模と成長に耐えられるかを見ます。チェックすべきは、ERPの種類・バージョン・カスタマイズの度合い、そして「そのシステムが本当に業務を回しているのか」です。現場では、基幹システムがあるはずなのに、実際の受発注や原価管理はExcelやAccessの属人的なマクロで代替されている、というケースが珍しくありません。この“見かけの基幹システム”を見抜けるかどうかが、IT-DDの精度を左右します。

②ソフトウェアライセンス・IT契約

使っているソフトウェアのライセンスが、契約上・台数上、適正に保有されているかを棚卸します。買収後に効いてくるのは、未使用ライセンス（無駄なコスト）、シャドーIT（無許可のSaaS）、そしてEOL/EOS（サポート終了）を迎えた製品です。特にライセンスや保守契約が「M&A後も同条件で継続できるか（チェンジ・オブ・コントロール条項がないか）」は、法務DDと連携して必ず確認します。外部委託しているシステムは、その契約を買収後も継続できるか、切り替えるといくらかかるかまで見ておきます。

③IT運用体制と属人化

誰がシステムを運用しているのか。内製か外注か、専任のIT人材はいるのか、特定の担当者に知識と権限が集中していないか——IT運用の属人化は、事業継続リスクそのものです。ドキュメントが整備されておらず、サーバーの構成やアカウント管理を特定の1人しか把握していない場合、その人の退職で業務が止まりかねません。属人化そのものの解き方は業務の属人化を解消する進め方にまとめていますが、IT-DDの段階では「属人化の程度」と「代替可能性」を評価しておくことが肝心です。

④情報セキュリティ

セキュリティは、買収後に自社のレピュテーションリスクへ直結する領域です。ウイルス対策・暗号化・パッチ適用の状況、セキュリティポリシーの有無、ID・アクセス権の管理、インシデント対応フロー、そして過去の漏えい事故の有無を確認します。現場でよく見つかるのは、退職者のアカウントが残ったまま、アクセス権が一度も棚卸されていない、というものです。買収後にこうした不備が原因で情報漏えいが起きれば、責任は買い手に及びます。社内でのAI活用も広がる中、生成AI利用も含めた要件は生成AIのセキュリティ対策も参考にしてください。

⑤ITコスト・技術的負債・統合親和性

最後に、ITコストの妥当性と、統合のしやすさを見ます。事業規模に対してITコストが高すぎないか——逆に、「規模に照らしてITコストが少なすぎる」ケースも要注意で、必要な投資を先送りにしてきた“技術的負債”が隠れているサインです。あわせて、自社システムとのデータ形式・コード体系の違い、継続利用と切り替えのどちらが現実的かという統合親和性を評価します。継続・切り替え・並行稼働のどれを選ぶかは、（1）データ形式・マスタコード体系の一致度、（2）切り替えにかかるコストと期間、（3）業務を止められる許容停止時間、の3軸で判断すると整理しやすくなります。ここが、後述するシステム統合（PMI）の難易度を左右します。

ITデューデリジェンスの進め方6ステップ

調査領域が定まったら、次は進め方です。専門家の解説と私たちの実務をもとに、6ステップで整理します。

1. 調査チームを発足する：買い手のIT担当に、外部のIT専門家（ITとM&A双方の言語が分かる人材）を加える。
2. NDAを締結し、情報管理体制を整える：システム情報は機微情報の塊です。開示情報の管理を徹底します。
3. 調査方針と開示請求リストを作る：出口（統合方針）から逆算し、業種・規模に応じて「何を見るか」を絞り込みます。開示を請求する代表的な資料は次のとおりです。

4. 開示資料を分析する：資料からリスクの仮説を立て、不足情報を面談用の質問に落とします。
5. 面談調査（ヒアリング）を実施する：CIO・IT部門長・実務担当者、必要なら外部ベンダーにもヒアリングします。ここが最重要で、資料だけでは見えない属人化や運用の実態はヒアリングでしか掴めません。
6. 報告書にまとめ、取引条件に反映する：発見したリスクを、価格交渉・クロージング条件に反映するとともに、そのままPMI（統合）の課題台帳に引き継げる粒度で書き残します。

ポイントは、ステップ6で「報告書を納品して終わり」にしないことです。発見事項を「1課題1行」で残しておけば、統合フェーズでそのまま実行タスクに変換できます。この引き継ぎ設計の全体像はPMIの進め方｜100日プランで解説しています。

現場事例｜情シスBPRの「現状調査」を買収前調査に応用する

ここからは、私たちが実際に支援した情報システム領域のBPR・システム統合の案件をもとにした一次情報です（守秘のため、業界・規模・症状・打ち手のみを記載し、社名・数値は伏せています）。

支援先の状況：中堅の卸・サービス業で、情シス体制が実質1〜2名という会社の現状調査を行いました。BPRの現状調査として棚卸を進めたところ、買収前調査（IT-DD）でも“地雷”になり得る論点が、まさに前述の5領域に沿って次々に出てきました。

• 基幹：基幹システムは導入済みだったが、実際の受注・在庫は担当者個人のExcelブックで管理され、基幹への入力は“事後の転記”になっていた（＝見かけの基幹システム）。
• ライセンス：ライセンスを棚卸すると、使っていない有償ソフトの契約が残る一方、部門が独自契約したSaaS（シャドーIT）が複数見つかった。基幹の保守はすでにサポート終了（EOS）が近づいていた。
• 属人化：サーバーの管理者パスワードとクラウドの管理アカウントを、退職間近の1名しか把握しておらず、構成図も更新が止まっていた。
• セキュリティ：アクセス権が入社以来一度も棚卸されておらず、退職者アカウントが有効なまま残っていた。

私たちがやったのは、これらの発見事項を「症状・影響・打ち手・担当・期限」の1課題1行の台帳に落とし込み、「クロージングまでに手当てすべきこと」「統合の集中実施期（おおむね100日）でやること」「その後に送ること」に仕分けることでした。

定量面でも示唆がありました。数値は伏せますが、棚卸しの結果、保有ライセンスのうち一定割合が未使用または重複契約であると判明し、契約見直しだけで年間のIT固定費を1〜2割圧縮できる見立てが立ちました。一方で、EOS間近の基幹保守と退職者アカウントの放置は、そのままにすれば買収後に数百万〜数千万円規模の緊急対応（緊急更改・漏えい対応）につながりかねないリスクとして、買収前に価格・条件へ織り込む対象に格上げしました。

こうした「圧縮できるコスト」と「先送りされた負債」が同時に見つかるのは、情報システム領域のBPR・統合支援の複数案件に共通する傾向です。BPRの現状調査で使う観点は、そのまま買収前のIT-DDに転用できます。逆に言えば、IT-DDを“買収前に行う情シスの健康診断”と捉えると、何を見るべきかがぶれません。台帳運用の限界とツール化はPMIの進捗管理ツール比較も参考にしてください。

IT-DDと「システム統合(PMI)」の切り分け

ここで混同しやすいのが、「IT-DD（買収前の調査）」と「システム統合（買収後の実行）」の違いです。両者は地続きですが、フェーズも目的も異なります。

IT-DDはあくまで「調べる」フェーズです。実際にシステムをどう統合するか（継続・切り替え・並行稼働の判断や、データ移行・権限設計）は、買収後のシステム統合として別途進めます。統合フェーズの手順は経営統合の進め方で、組織・制度・システムの統合手順として解説しています。IT-DDの役割は、この統合を「初日から迷わず動ける状態」にしておくことにあります。

費用相場と期間の目安

IT-DDの費用と期間は、対象会社の規模やシステムの複雑さで大きく変わります。あくまで一つの目安ですが、AGSコンサルティングなどM&A・IT-DDを手がける専門会社の公開解説では、次の水準が示されています。

• 費用：数百万円程度が中心。システムがシンプルな中小企業向けの簡易診断であれば数十万円から実施できるケースもあります。
• 期間：おおむね2ヶ月程度。財務DD・法務DDと並行して進めるのが一般的です。

注意したいのは、IT-DDを削って“見つけそこねた”リスクの代償です。買収後にサーバー入れ替え・セキュリティ基準の統一・会計データ統合などが必要になると、追加投資は数千万〜億円規模に膨らむこともあります。IT-DDの費用は、この“想定外”を買収前に価格へ織り込むための保険と考えると、費用対効果が見えてきます。中小企業ならではの勘所は中小企業のPMIも合わせてご覧ください。

よくある失敗と回避策

• 財務・法務DDだけで、IT-DDをやらない → 出口（統合）から逆算し、IT論点を必ずスコープに入れる。
• 開示資料の分析だけで済ませる → 属人化・運用実態はヒアリングでしか見えない。CIO・実務者・外部ベンダーに必ず話を聞く。
• 調査項目を機械的に埋める → 「買収後に効くか」で優先順位を付け、致命的なリスクに焦点を絞る。
• 報告書を納品して終わりにする → 発見事項を「1課題1行」で残し、PMIの課題台帳へ引き継ぐ。
• IT-DDと統合作業を混同する → 「見極める」と「統合する」を分け、それぞれに担当と期限を置く。

事業承継に伴うM&Aでは、承継後に何から着手すべきかという視点も欠かせません。詳しくは事業承継後の経営で最初にやることを参照してください。

まとめ｜ITデューデリジェンスは「統合を前提に、買う前に診る」

ITデューデリジェンスの進め方は、高度な技術ではなく、買収後に効いてくるIT論点を、統合を前提に、買う前に洗い出しておくという段取りに尽きます。

• IT-DDの目的＝隠れたコスト・事業継続リスク・統合難易度を買収前に見極めること
• 見るべきは5領域＝基幹システム／ライセンス・契約／運用体制と属人化／セキュリティ／コスト・統合親和性
• 進め方は6ステップ。最重要はヒアリング、そして発見事項をPMIの課題台帳へ引き継ぐこと
• IT-DD（調べる）とシステム統合（統合する）は切り分けて設計する

IT-DDで見えた課題を、統合の初日から動く力に変えたい方へ。買収後のPMIを台帳ベースで管理し、DDの発見事項をそのまま100日プランのタスクへ落とし込めるツール「PMI Manager」のサービス紹介資料を無料で配布しています。

▶ PMI Manager サービス紹介資料（無料ダウンロード）

自社のケースで「IT-DDで何を見るべきか」「発見した課題をどう統合に活かすか」を整理したい場合は、PMIコンサルティングのページもご覧ください。現場主義×AIの視点で、IT-DDから統合までをご支援します。まずは相談したいという方は、無料相談からお気軽にお問い合わせください。

監修：大槻 伸夫（キュリオシティ株式会社 代表取締役CEO）
事業承継・M&A後の統合（PMI）、業務改善・BPR、情報システム領域の現状調査・システム統合支援、生成AI導入支援を軸に、現場主義×AIで中堅・中小企業の経営を支援。