譲渡の前に行う、売り手側のITデューデリジェンス

売り手側のITデューデリジェンスとは、譲渡を考えている会社が、買い手の調査の前に自社のシステムを点検しておく準備のことです。システムの構成、ライセンスと契約、セキュリティ、データ、システムの担い手を確かめ、譲渡の前に直すものと、直さずに開示するものに分けておくと、買い手の調査を落ち着いて受けられます。

売り手側のITデューデリジェンスとは

ITデューデリジェンスは、一般には買い手が対象の会社のシステムを調べる調査を指します。何を調べるかはITデューデリジェンスでは何を見るのかで説明しています。

売り手側のITデューデリジェンスは、同じ観点を、売り手が自ら先に確かめるものです。セルサイド・デューデリジェンスと呼ばれることもあります。目的は、自社のシステムの良し悪しを採点することではなく、買い手の調査で問われそうな点を事前に把握し、説明できる状態にしておくことです。

なぜ譲渡の前に点検しておくのか

買い手の調査は、限られた期間の中で、資料の依頼と質問が続く形で進みます。その場で初めて問題に気づくと、資料をそろえる時間が足りなくなったり、説明が後手に回ったりします。

譲渡の前に点検しておくと、次のような準備ができます。

• 買い手から依頼されそうな資料（システムの一覧、構成の図、契約書、規程など）を前もってそろえる
• 直せる点は、譲渡の手続きが進む前に直しておく
• 直さない点は、影響と今後の対応の考え方を整理し、説明できるようにしておく

譲渡の前の準備の全体は、M&Aの前に整えておきたい、データとシステムのことで扱っています。この記事では、システムの点検に絞って説明します。

何を点検するのか

点検の観点は、買い手の調査とほぼ同じです。主に確かめることを表にまとめます。

システムの構成とライセンス

まず、社内で使っているシステムとサービスを洗い出し、一覧にします。部署ごとに契約したクラウドのサービスや、担当者が個人で使い始めたツールが抜けやすいため、請求の記録やカードの明細からも拾います。

ライセンスは、契約している数と、実際に使っている人の数が合っているかを確かめます。自社のサービスにオープンソースソフトウェアを組み込んでいる場合は、そのライセンスの条件に沿った使い方になっているかも見ます。

契約

サービスやソフトの契約が会社の名義になっているか、期間と更新の条件はどうかを確かめます。会社の支配権が変わったときに、相手の承諾が要る、または契約を解除できると定めた条項（チェンジオブコントロール条項）があるかも見ます。

外部の会社に開発を頼んだソフトは、知的財産権の帰属が契約でどう定められているかを確かめます。権利が開発した会社に残る契約になっていることもあります。契約の解釈にかかわる点は、弁護士などの専門家にご確認ください。

セキュリティとデータ

退職者のアカウントが残っていないか、管理者の権限を持つアカウント（特権ID）を誰が使っているか、多要素認証を使っているか、バックアップから戻せることを確かめたことがあるか、を点検します。過去の情報漏えいや不正アクセスの有無と、その後の対応の記録も整理しておきます。

データは、個人情報や取引先から預かった情報が、どこに、どの形で置かれているかを確かめます。取得したときの説明や、委託先との受け渡しの方法も、買い手から問われやすい点です。個人情報の扱いが法令に沿っているかの判断は、弁護士などの専門家にご確認ください。

担い手

システムの運用を、社内の誰が、どの範囲で担っているかを確かめます。1人の担当者や、特定の外部の会社に頼りきっている場合は、手順書や引き継ぎの資料を整えておくと、買い手の不安を和らげる材料になります。

買い手から依頼されやすい資料は何か

買い手の調査では、最初にまとまった資料の提出を求められるのが一般的です。システムについては、次のような資料を求められることがあります。前もってそろえておくと、調査の初めの時期を落ち着いて進められます。

• システムとクラウドのサービスの一覧（名前、用途、契約の名義、費用、担当）
• システムの構成の図と、データのつながりの図
• 主な契約書（開発の委託、保守、クラウドのサービス、ソフトウェアの使用許諾）
• 情報セキュリティの規程、アカウントの管理の手順、バックアップの手順
• 過去の事故や障害の記録と、その後の対応
• システムの運用の体制（社内の担当、外部の委託先）

資料がない項目は、無理に新しく作り込むより、現状をありのままに一覧にしておくほうが、説明の食い違いを防げます。

直すものと、開示するものをどう分けるのか

点検で見つかった点は、すべてを譲渡の前に直す必要はありません。費用と時間、影響の大きさを見て、直すものと、直さずに開示するものに分けます。

• 譲渡の前に直すもの：少ない費用と時間で直せて、放置すると事故につながりやすいもの。退職者のアカウントの削除、契約の名義の変更、多要素認証の設定、ライセンスの数の調整などが当たります
• 直さずに開示するもの：直すのに大きな費用や長い期間がかかるもの。古いシステムの作り直し、システムの統合の方針にかかわる見直しなどです。直すかどうかは、譲渡の後の方針を決める買い手の判断にかかわるため、現状と影響を説明できるようにしておきます

開示しないまま譲渡が進むと、後から問題が見つかったときに、譲渡の契約の表明保証の条項との関係で問題になることがあります。何をどこまで開示するかは、M&Aの助言者や弁護士などの専門家と相談して決めてください。

点検はどう進めるのか

点検は、次の順に進めるのが一般的です。

1. 点検の範囲を決める。システムが事業の中心にある会社は深く、依存の小さい会社は要点に絞る
2. システムとサービスの一覧、構成の図、契約書、規程を集める
3. アカウントと権限、バックアップ、更新の状況などを、設定の画面や記録で確かめる
4. 見つかった点を一覧にし、直すものと開示するものに分ける
5. 直すものに担当と期限を決めて直し、直した記録を残す
6. 開示するものは、現状と影響、今後の対応の考え方を文書にまとめる

譲渡の検討は、社内でも知っている人が限られる時期に進みます。点検に協力してもらう社員の範囲と、点検の理由の伝え方は、事前に決めておきます。

点検を自社の担当者だけで行うと、見慣れた設定の問題に気づきにくいことがあります。第三者に点検を頼む場合は、その相手がシステムの開発や運用に関わっていないかを確かめておくと、結果の客観性を説明しやすくなります。考え方はシステム監査の独立性で扱っています。

点検の結果は、譲渡の後にも使える

点検でまとめた一覧や構成の図は、譲渡の後のシステムの統合の計画の材料にもなります。買い手にとっては、どのシステムを残し、どれを寄せるかを考える手がかりになります。統合の進め方は、買収の後のシステム統合（PMI）をどう進めるかをご覧ください。

当社のご支援

アメリア・テクノロジーは、譲り渡す側からのご依頼でも、システム監査としてITデューデリジェンスを行い、直すものと開示するものの整理をお手伝いします。当社が開発・運用に関わったシステムは監査の対象にしません。監査の担当と改善の担当は分け、直す作業を当社に頼むことは条件にしません。同じ取引で買い手側の調査はお受けしません。フロレンティナが同じ案件に関わる場合は、その立場と当社との関係を着手の前に書面でご説明し、ご了承をいただいてから始めます（中立を保てない場合や、お客様が望まれない場合はお受けしません）。連携の内容はフロレンティナとの連携をご覧ください。