&N 未来創発ラボ

野村総合研究所と
今を語り、未来をみつめるメディア

はじめに

近年、デジタルサービスや生成AIの普及やDX(デジタルトランスフォーメーション)の進展により、企業の競争力の確立や事業戦略の実現においてITは増々不可欠な要素となっています。こうした流れを受け、M&AにおいてもITがその成否を左右する要因となりつつあります。しかし、ITデューデリジェンス(ITDD)は、事業や財務のデューデリジェンスと比較して、優先度が低く設定されがちです。さらに、情報統制の制約からITの専門知識を持たないM&Aの担当者が実施せざるを得ないケースもあります。
そのため、「どのような内容を確認し、どのように進めれば良いか分からない」「ITDDを実施したものの、PMI(Post Merger Integration)において想定外の課題に直面した。次回は改善できないか」といった悩みを抱える方も少なくありません。
本記事では、自社でITDDを実施する場合、外部の専門家に依頼する場合にかかわらず、適切な進め方と、その実行におけるポイントを解説します。

ITデューデリジェンスの必要性

昨今のビジネス環境において、ITは事業継続性および競争力の根幹を成す要素です。買収後に期待されるシナジー効果や企業価値の向上を実現できるか否かは、対象会社のIT環境が健全であるか、そして事業戦略と整合しているかに大きく依存します。
ITDDの主な目的は、M&Aの意思決定に必要な判断材料を短期間で収集し、PMIに向けた課題を明確にして必要な施策や予算・期間の見積りなどの初期計画の策定に繋げることです。具体的には、対象会社のIT資産やシステム構成、利用しているサービス、運用の実態、IT組織などを調査し、リスクや追加対応が必要になりそうな点を事前に把握します。
ITDDを実施しない場合、買収後に予期せぬ多額のIT投資の発生や、システム統合計画そのものの頓挫などのリスクが顕在化する可能性があります。例えば、老朽化した基幹システムが事業継続に深刻な支障をきたす、あるいはセキュリティ対策の不備が大規模な情報漏洩を引き起こすといった事態は、企業価値を大きく損なう要因となり得ます。
買収後に「想定外」の事態を回避するためには、効率的かつ効果的なITDDを通じて、課題の優先度と対応時期を明確に整理しておくことが、M&Aの成功確度を高める上で極めて重要です。

ITデューデリジェンスの進め方

では、具体的にどのような手順で進めればよいのでしょうか。ここでは、ITDDの基本的な5つのステップを解説します。

図1 ITDDの進め方

Step0では、顧客基盤拡大や業務効率化・コスト削減といった案件の目的、およびスキーム(カーブアウト、株式譲渡など)や統合方針(スタンドアローン、統合など)といった案件の特徴に基づいて、重点的に確認すべき論点を整理します。案件の目的が顧客基盤拡大の場合は「データの持ち方や項目定義に致命的な違いがないか」に焦点を当てるなど、限られた時間とリソースでどこを深く見るかという方針を策定します。
次にStep1では、調査項目を洗い出し、調査項目に合わせて対象会社に開示依頼を行う資料一覧/IRL(Information Request List)を整理します。例えば、自社のセキュリティ基準との乖離を確認するために「情報セキュリティポリシー・規程」、主要ベンダーとの契約形態などを確認するために「外部委託先情報」などをリストアップし、優先度と共に提示します。
続いてStep2では、資料の収集と読込みに加えて、Q&A(書面での質疑応答)やインタビューを通じて、資料だけでは分からない情報や資料から読み取れるリスクの背景、運用実態などを深掘りします。対象会社の担当者が多忙であったり、機密保持の観点から現場担当者を巻き込めなかったりすることによりインタビューが実施できないケースがあるため、Q&Aを最大限に活用します。
Step3では、調査結果を踏まえて、課題やリスクを抽出・整理します。抽出した課題・リスクについては、M&Aそのものを中止すべき重大な欠陥(ディールブレイカー)か運用レベルの課題かなど、ビジネスへの影響度で分類したうえで、対応の優先順位や具体的な対策を検討します。
最後にStep4では、リスク対応に必要なコストと期間を算出し、「クロージングまでに必須のセキュリティ対策」や「3年計画でのクラウドサービス適用によるコスト低減」といった実行計画(ロードマップ)に落とし込みます。これらは、買収契約の交渉や買収後のPMI計画、中長期的なIT戦略策定の重要なインプットとなります。

ITデューデリジェンスにおける失敗例

前章で解説した5つのステップに沿ってITDDを実施した場合でも、買収後に重大な問題が発覚することもあります。本章では、ITDDにおける代表的な失敗事例をご紹介します。

失敗例1:セキュリティ対策の不備に起因する事業停止と信頼失墜

ある企業では、ITDDにおけるセキュリティ対策の評価が表面的なものに留まり、買収後に潜在していた脆弱性が露呈しました。結果としてサイバー攻撃を受け、顧客情報漏洩や基幹システムの業務停止を引き起こしたのです。これにより、顧客からの信頼を失い、ブランドイメージを損ない、企業価値の向上どころか、むしろ低下させる結果を招きました。

失敗例2:老朽化したシステムによる統合計画の遅延とコスト増大

別の事例では、買収後になって対象会社が極めて老朽化した基幹システムを運用していることが判明しました。買収前から刷新の検討自体はされていたものの対応は先送りされ、停止リスクを抱えたまま長年放置されていたのです。その結果、業務への影響を最小限に抑えながらシステムを統合することが技術的に難しいと分かり、統合計画は大幅に遅延しました。さらに二重運用を余儀なくされ、当初見込んでいたコスト削減効果は得られず、システム改修や運用維持に多額の追加コストが発生する事態に陥りました。加えて、当該システムは刷新自体も容易ではなく、今後もリスクを抱えたまま運用せざるを得ない状況となりました。

失敗例3:IT人材の流出による事業計画の停滞と競争力低下

ある案件では、買収後になって対象会社で多くのIT人材やキーパーソンがすでに退職していることが判明しました。加えて、設計書などのドキュメントも更新されておらず、ノウハウが退職者に属人化していたのです。その結果、買収後にシステム改修や機能拡張を担う人材やノウハウが不足し、既存システムの改修は計画どおりに進みませんでした。統合後の競争力の源泉となるはずの機能拡張も停滞し、最終的に、当初の事業計画の実現が難しくなるなど、市場での競争力低下を招く状況に陥りました。

これらの失敗は、ITDDが「限られた期間」と「限られた情報」の中で進めざるを得ないことに起因するケースが少なくありません。M&Aでは交渉上の駆け引きもあり、譲渡額に影響し得る情報が十分に開示されないこともあります。そのため、ITDDで全てを完璧に見抜くことは現実的ではありません。だからこそ、制約を前提に進め方を工夫し、重大リスクの見落とし確率を下げることが重要です。

ITデューデリジェンスで失敗しないための4つの重要ポイント

前章で触れた制約を踏まえて、実務において特に押さえておきたい4つのポイントをご紹介します。

重要ポイント①:目的から逆算して、重要論点を絞り込む

私たちがご相談をいただく中でも、全てのシステムや規程等を網羅的にチェックすることに注力するあまり、肝心なリスクの特定が疎かになっているケースをよく見かけます。限られた期間で成果を出すには、M&Aの目的から逆算して調査を行うことが不可欠です。例えば、買収の目的が顧客基盤獲得の場合には、会員データや個人情報の管理状況を最優先にするなど、ディール全体への影響度が低い項目の調査に時間をかけすぎず、本質的なリスクを見極めることに注力すべきです。

重要ポイント②:資料が十分には開示されない前提で動き、仮説思考でリスクの当たりをつける

実務上、対象会社から必要な資料がすべてスムーズに開示されるケースは決して多くありません。資料の提供を待つのではなく、限られた情報から仮説を立てて動くことが重要です。例えば、「長年大規模な刷新がされずに利用されてきたシステム」であることが分かれば、「度重なる改修でシステムの構造が複雑化・肥大化し、容易に手が出せない状態になっていないか?」という具体的な当たりをつけることができます。その仮説をもとにインタビュー等で事実確認を行うことで、効率的に実態へ迫ることが可能になります。

重要ポイント③:表面的な調査に閉じず、見えないリスクを炙り出す

「これまでシステムが安定稼働している」「設計書類が揃っている」などの表面的な調査だけでは、落とし穴にはまる可能性があります。私たちがよく遭遇するのは、ドキュメントと実態が乖離している、システム構造が複雑に絡み合って(スパゲッティ化して)いるなどのケースです。このような深層にある「見えないリスク」を見落とすと、買収後のシステム統合作業が想定以上に難航したり、追加の改修・刷新コストが膨張したりする可能性があります。技術的な観点については、社内のIT部門や外部の専門家と連携して、実態を評価することも重要です。

重要ポイント④:リスクの検出に留めず、意思決定に必要な「コスト」や「期間」に変換する

システムの不備のリストアップで終わらないよう、重要度の高いリスクに対して優先的に「いつまでに、どの程度の投資が必要か」を具体化し、ビジネスへの影響(買収価格の調整や契約条件の織り込み等)に変換して提示します。このように、単なる技術的な課題の指摘ではなく経営層が具体的な判断を下すための情報に翻訳することで、初めてM&Aの意思決定を支えることができます。

前述の4つのポイントはいずれも重要ですが、特に①「論点の絞り込み」と③「見えないリスクの炙り出し」はITの実態を踏まえた判断が必要となり、IT知見が不足すると優先順位の誤りや重大リスクの見落としに繋がりやすい領域です。本章ではこの2点に焦点を当てて解説します。

論点の絞り込み

限られた期間で重要な項目への調査リソースを集中させるためには、まずITDDにおける主要な調査観点を把握しておく必要があります。一般的には、表1のような観点が挙げられます。

表1 主要な調査観点の例

M&A案件の目的や特徴を踏まえ、膨大な確認項目の中から優先的に検証すべき重要課題(キーイシュー)を絞り込みます。まず、案件のタイプによらず共通して重要度が高いテーマとして、「セキュリティ/プライバシー保護」が挙げられます。サイバー攻撃による事業停止や情報漏洩に伴う損害賠償・ブランド毀損は、買収後の企業価値を大きく損なう要因となるためです。したがって、脆弱性対策やインシデント管理の実態などは、必須の検証項目となります。
そのうえで、表2のように案件個別の特徴や目的に応じた項目の重要課題を整理します。例えば、対象事業を親会社から切り出す「カーブアウト」案件で、かつシステムも独立させる「スタンドアローン」を目指す場合、システム分離にかかるコストと期間の精査が最重要論点の一つとなります。具体的には、親会社等の基幹システムからの移行対応や、移行期間中の移行支援を含むサービス提供契約/TSA(Transition Service Agreement)の条件などが挙げられます。
このように、案件の特性に合わせて重要な調査項目を整理することで、リスクの高い領域にリソースを集中させることが可能になります。

表2 案件の目的/特徴に応じた、重要な調査項目の例

見えないリスクの炙り出し

リスク管理においてよく参照されるFAIR (Factor Analysis of Information Risk) モデルではリスクを「損失規模」と「損失事象発生頻度」を用いて定量的に評価します。一方で、限られた期間と情報の中で実施するITDDにおいては、実務での評価作業をより効率的に行うため、NRIではリスクの「影響度(重要度)」と対応の「緊急度」に基づいて評価するフレームワークを活用しています。以下の例のように、個々の発見事項について「重要度」と「緊急度」からリスクレベル(S, A, B, C等)を判定してマトリクスに落とし込みます。これにより、「買収前に是正が必須か」「PMIの3年計画の中で対応すればよいか」といった具体的な対応方針と時期を明確にしていきます。リスクレベルや重要度、緊急度の考え方は、各案件の特徴を踏まえて定義します。

図2 リスクマトリクスのイメージ

対象会社の業種やビジネスモデルによって、発見事項に対するリスク評価が異なることがあります。対象会社が異業種の場合には、業界特有のITリスクや規制要件を理解しておくことが不可欠です。自社の基準だけで判断せず、対象会社の特性に合わせた物差しを持つことが重要です。
例えば対象会社が「ITを競争源泉とする企業」である場合、各リスクレベルに対応する課題として表3のような項目が挙げられます。「外部監査で指摘された脆弱性が未対応のままである」といったサイバー攻撃対策の不備に加えて、「特定の技術者の離職により開発が止まる」といった人材リスクは、買収後の成長を阻害し投資対効果を大きく下げる可能性があるため、最優先の対応項目と位置付けてロードマップを策定します。

表3 各リスクレベルに該当する課題の例

ITデューデリジェンス実施に向けた体制の構築

ITDDを実施する際には、体制構築も重要なポイントになります。
まずは、可能な限り早い段階で自社のIT部門を巻き込むことを検討しましょう。買収後のシステム統合の実務を担うIT部門が早期に関与することで、「自社のセキュリティ基準とのギャップ」や「システム連携の難易度」といったPMIに向けた具体的な課題をクリアにすることに寄与します。また、個別の案件が動く前に、自社のIT部門の協力を得て「対象会社に開示依頼を行う資料一覧(IRL)」や「最低限クリアすべきセキュリティ要件」などを汎用的なガイドラインとして整備しておくことも有効です。これにより、初期検討段階ではM&Aの担当者のみで一次スクリーニングを行い、詳細検討フェーズからIT部門が合流するといった柔軟な対応が可能になります。
しかし、M&A案件は機密性が高く、インサイダー取引防止の観点から、初期段階で社内の多くの人を巻き込むことが困難であるケースも少なくありません。ITDDにはシステム構成、開発言語、セキュリティ、ITコストなど、多岐にわたる専門知識が不可欠であるため、M&Aの担当者だけで調査を行うと、前述の失敗事例のような問題を引き起こすリスクが高まります。
こうした「社内リソースを巻き込めない」状況では、外部のITDD専門家(ITコンサルタントなど)を活用することが有効な選択肢となります。外部専門家であれば、機密性を保ちつつ、客観的な視点と豊富な経験に基づき、効率的かつ高精度でリスクを洗い出すことが期待できます。外部の専門家に依頼する際は、ビジネス目的に合致したより精度の高い調査と評価に繋げるために、依頼の目的を明確に伝えることが重要です。例えば、「今回のM&Aで最も達成したいことは何か?」「最も避けたいリスクは何か?」といった依頼の目的や期待を明確にしておくことを推奨します。

おわりに

近年、ビジネスのあらゆる側面でITの重要性が増しており、M&AにおいてもIT環境の健全性や事業戦略との整合性が成功の鍵を握るケースが増えています。競争力を維持・強化するためには、M&Aの目的に応じた適切な観点で対象会社のIT環境を調査・分析し、潜在的なリスクや課題を早期に把握することが不可欠です。
特に、ITが競争力の源泉となるような企業のM&Aにおいては、システムの表面的なスペック情報だけでなく、将来の拡張性を左右するアーキテクチャーの構造や、マニュアルには書かれていない現場の運用実態、そして特定のキーパーソンに依存していないか、といった組織・人材にまで深くメスを入れる高度な専門性が必要です。このようなケースでは、ITとデューデリジェンス両面の知見に長けた専門家に依頼することを視野に入れるべきでしょう。
NRIでは、ミッションクリティカルなシステムやクラウドネイティブなシステムの開発・運用実績や、自社サービスの提供を通じて培った豊富なIT知見と、数多くのM&A支援実績を保有しています。この知見に基づき、ITDDからPMI計画策定、システム統合までを一気通貫で支援するサービスを提供しています。
M&AにおけるITDDの進め方や、買収後のPMIに関する課題をお持ちの方は、ぜひお気軽にご相談ください。

プロフィール

  • 出井 智のポートレート

    出井 智

    ITアーキテクチャーコンサルティング部

    1992年NRIに入社。ソフトウェア企画・開発・運用の経験を経て、システム企画・構想・開発・保守に従事し、近年はコンサルティング業務に従事し、ITDD、プライバシー保護、PMO支援などの領域に取り組む。

  • 野村 敏弘のポートレート

    野村 敏弘

    ITアーキテクチャーコンサルティング部

    2016年NRIに入社。システム基盤の開発・運用の経験を経て、IT戦略策定やシステム化構想・計画策定、PMO支援などのコンサルティング業務に従事。近年は、ITDD、データアーキテクチャー、デジタルレジリエンスなどの領域に取り組む。

  • 宮腰 諒志のポートレート

    宮腰 諒志

    ITアーキテクチャーコンサルティング部

    国内SIerを経て、2025年NRIに入社。システム開発・運用を経験し、入社後はシステム化構想・計画策定、アーキテクチャー標準策定などのコンサルティング業務に従事。ITDD、デジタルレジリエンス、AIアーキテクチャーなどの領域に取り組む。

※組織名、職名は現在と異なる場合があります。