IT全般統制は、買収した会社が子会社になる場面で驚くほど見落とされています。最近、M&Aのご相談をお受けする中で、気になっていることがあります。買収する側もされる側も、財務デューデリジェンスやビジネスデューデリジェンスにはかなりの時間と予算をかけるのに、IT統制の観点はほとんど検討されないまま契約が進んでしまうケースが多いということです。
J-SOX対応のための内部統制構築という話は、上場準備や上場後の文脈でよく出てきます。ですが、そこで語られる内部統制は財務報告プロセスの統制が中心で、IT統制、とりわけIT全般統制の話は驚くほど手薄になりがちです。ふだんはこの手薄さが表面化しないまま済んでいる会社も多いのですが、M&Aで会社を買って上場子会社にした瞬間、この手薄さが一気に表に出てきます。
本稿では、IT全般統制において、上場子会社になった時に起こる問題と、その対応について説明します。
この記事を読んでわかること
- M&Aで上場子会社になった瞬間、なぜIT全般統制の負担が急に発生するのか
- 買収した既存システムが「統制を意識していない」状態になりやすい理由
- 上場子会社が実際に対象になる範囲と、そこで起きる現場の摩擦
- 買収前のデューデリジェンスで、IT統制の観点をどう組み込んでおくべきか
M&Aが増えるほど増える、上場子会社化とIT全般統制のセット問題
M&Aによる事業拡大は、いまや珍しい話ではありません。事業シナジーや顧客基盤、時には相手先が持つプラットフォームそのものを目当てに、買収が実行されます。後継者不在による事業承継の受け皿として、あるいは新規事業を自社で一から立ち上げるより早いという理由で、買収という選択肢を取る上場企業も増えています。
こうした流れ自体は、悪いことではありません。むしろ、買い手にとっても売り手にとっても合理的な選択であることが多いはずです。ただ、この合理性の裏側で、静かに積み上がっていく負債のようなものがあります。それがIT全般統制です。
ただ、買収の意思決定の場面で評価されるのは、たいてい「その会社を買うことでどんな価値が得られるか」という視点です。事業シナジー、顧客基盤、システム資産。これらは前向きな評価軸として当然大事なのですが、逆に「買った後、その会社にどんな義務が発生するか」という視点は、どうしても後回しにされがちです。
その代表がIT全般統制です。買収した会社が、財務報告に重要な影響を持つ「重要な構成単位」に該当すると判断されると、親会社と同じようにIT全般統制の評価対象に組み込まれます。
どこからが「重要」とみなされるかは会社ごとの状況によって変わりますが、少なくとも「うちは規模が小さいから関係ない」と決めつけるのは危険です。
重要かどうかの判断は、買収した側が決めることではなく、会計監査の枠組みの中で決まっていくものだからです。
売上や資産規模だけを見て「うちは親会社の中では小さい方だから対象にならないだろう」と考えるのも、実はあまり当てにできません。重要性は金額的な大きさだけでなく、事業内容や不正リスクといった質的な面も踏まえて判断されるものだからです。
つまり、M&Aを実行する時点で、買収先が将来「重要な構成単位」になり得るかどうかを意識しておかないと、後になって「え、うちも対象なんですか」という状態から準備を始めることになります。
ゼロから準備を始めるのと、あらかじめ心づもりがあった状態で始めるのとでは、負担がまったく違います。この構図は、JSOXのIT統制対応でつまずく会社に共通する、現場の落とし穴でも触れた「会計側とIT側のすれ違い」がM&Aというタイミングで一気に噴き出したものと捉えると分かりやすいと思います。
買収したプラットフォームが「統制を意識していないシステム」である理由
買収先の会社が非上場企業だった場合、その会社が使っているシステムは、IT統制（IT全般統制・業務処理統制）を意識せずに作られ、運用されていることが殆どです。
これは上場していない会社にとってはごく自然なことです。なぜなら、非上場企業において誰がどのシステムにアクセスできるか、システムの変更はどう承認されているか、外部委託先はどう管理されているか。こうした記録を細かく残しておく必要が、そもそもなかったからです。
具体的には、次のような状態が「統制を意識していないシステム」にはよく見られます。
- 経理や営業のメンバーが、共有アカウントで基幹システムにログインしている
- 退職した社員のアカウントが、削除されずにそのまま残っている（→アカウント棚卸のやり方）
- システムの改修・設定変更が、誰の承認もなく担当者の判断だけで行われている（→変更管理と監査証跡）
- 外部の開発会社に開発及び運用を委託しているが、その内容をほぼ把握していない（→SOC1レポートで委託先を評価する）
どれも、非上場企業のあいだは特に問題として扱われてこなかったはずです。日々の業務は問題なく回っていたわけですから、当然といえば当然です。上場子会社になった瞬間に何が求められるようになるのか（アクセス管理・変更管理・運用管理・外部委託管理の4カテゴリ）はIT全般統制とはで整理しているので、あわせてご覧ください。上場子会社になる前後で、求められる運用の水準はこれだけ変わります。
| 非上場だったころ動けば良い。権限管理は属人的、変更は担当者の裁量で完結 | → | 上場子会社になってから誰が何にアクセスできるかの記録が必須。変更には承認と証跡が要る |
自社でシステムを運営していたある会社が上場企業に買収され子会社になった例を紹介します。この会社は会計監査で「IT全般統制の評価をしたい」と監査法人から依頼がありました。しかし、権限管理の記録もなければ、変更履歴を追う仕組みもない、という状態であったため、ゼロから体制を作らなければならず、監査対応そのものが止まりかけました。
私自身、こうした案件に関わっていて感じるのは、M&AにおいてIT統制が意識されるケースはかなり少ないということです。明らかに重要性がない場合ならさておき、重要性がある子会社でも会計処理の統合のみを意識して、IT統制は無視されるケースが多いと考えられます。
上場子会社になった瞬間に、何が対象になるのか
J-SOXは、単体の会社ではなく連結ベースで評価対象を決める制度です。ですから、買収した子会社が重要な構成単位に該当すれば、親会社が整備しているのと同じ水準のIT全般統制を、その子会社自身も整備し、評価される立場になります。
評価対象になるということは、その子会社のIT統制の状況が、グループ全体の内部統制報告書に組み込まれ、監査法人のレビューを受ける立場になるということです。買収してから初めて迎える決算までに間に合わせなければならない場面も多く、猶予はそれほど長くありません。またこの評価は一度整えたら終わりではなく、毎期継続して求められます。単発の作業ではなく、これから先ずっと運用し続ける体制と理解しておいたほうが良いでしょう。
ゆえに、J-SOXや内部統制が重要になってくることを見越して、M&Aの前段階から親会社側・子会社側の双方で調整を進めておくことが望ましいでしょう。ここを飛ばしてしまうと、後で痛い目を見ることになります。
仕組みがそもそもない会社に、IT全般統制を教え込む難しさ
アクセス管理・変更管理・外部委託管理といった統制が難しいのは、システムがすでに動いているからではありません。買収先の会社には、こうした統制を運用する「仕組み」そのものが、そもそも存在していないケースがほとんどだからです。
これは、IPO準備の初期段階に近い体験です。IPOを目指す会社が最初にぶつかるのも、技術的な難しさというより、「なぜこんな手続きをいちいちやらなければいけないのか」を、経営陣から現場の担当者まで一人ひとりに理解してもらうという、地道な教え込みの作業です。
買収されてすぐの会社にも、同じことが起こります。「これはルールだから、やらなければいけない」という前提そのものを、組織に一から浸透させる必要があるのです。
しかも、買収された側の現場からすると、この動きは「今まで何の問題もなく回っていたのに、なぜ急に手続きが増えるのか」としか見えません。会計側からすれば「統制上、必要な手続き」として求めているのに、現場からすれば「余計な作業が増えた」としか感じられない。「今まで問題なく回っていた」という現場の感覚自体が、実はそもそも統制の仕組みがなかったことの裏返しなのですが、そのことは現場からは見えません。同じ手続きを、片方は財務報告の信頼性を守るための当然の一手だと考え、もう片方は降ってきた余計な仕事だと感じている。この温度差こそが、買収直後の現場で摩擦を生む正体です。この構図は、会計担当者とエンジニアの「すれ違い」とも共通しています。
| 会計側の受け止め財務報告の信頼性を担保するために必要な、統制上当然の手続き | / | 現場側の受け止め買収されたとたんに降ってきた、意味の分からない余計な作業 |
同じ手続きを見ていても、立っている場所が違えば、まったく違うものに見えてしまうわけです。
実際、このすれ違いのしわ寄せで子会社側の担当者が疲弊し、最終的に離職してしまうケースも見てきました。ある案件では、買収された会社の経理担当者が「正直、何をどうすればいいのか分からない」という状態になってしまい、結局コンサルが急遽入って手当てすることになりました。
親会社側も、買収直後は説明やコントロールにまで手が回らないことが少なくありません。とくに、東証グロース市場では2030年に上場維持基準が「5年で時価総額100億円以上」に強化される予定で、この基準を満たすためにM&Aによるスケールアップを選ぶスタートアップが増えています。
このような急ぐ動機から生まれるM&A案件ほど、監査対応やPMI(買収後の統合プロセス)にかけられる予算が確保されておらず、しわ寄せが大きくなりがちです。
PMIにおけるシステム連携は、それ自体が大変な作業です。とくに、買収した会社のシステム基盤が複数にまたがっていて、なおかつ自社の経理業務や業務プロセスに密接に組み込まれている場合、統合の難易度は一段と上がります。IT全般統制の構築は、このPMIの一部として発生するコストです。買収を決める段階で、このコストをあらかじめ織り込んでおかないと、後になって「想定外の支出」として扱われることになります。
このコストには、外部のコンサルに支払う費用だけでなく、社内の人員をどれだけ割り当てるかという話も含まれます。ただでさえ買収直後は、契約書の整理や取引先への挨拶など、やることが山積みです。そこにIT全般統制の構築が加わることから、体制を組む段階で人員計画に織り込んでおかないと、結局は特定の担当者に負担が集中してしまいます。
実際、株式会社メロンが上場子会社になった際の事例でも、月次決算の早期化（2週間程度から4〜5営業日へ）や役員会への報告体制の整備、連結決算対応、内部統制の報告などに加え、IT全般統制の対応なども含めて対応しました。このような仕組みづくりも合わせて対応していくことが、管理体制の構築には重要になります。
📥 買収先のIT統制の状況は、チェックリストで把握できます
確認の抜けを防ぐため、ITGCの自己点検用チェックリストを土台にしてみてください。
→ ITGCチェックリスト（自己点検用）を見る
買収前のデューデリジェンスで確認しておくべきこと
ここまで読むと、「では買収前に何を見ておけばいいのか」という話になります。
小規模のM&Aにおけるデューデリジェンスというと、財務デューデリジェンスと労務デューデリジェンスに終始してしまうことが、実務ではまだまだ多いように感じます。しかし、ITデューデリジェンス、つまり買収先のシステムがどこまで統制を意識した作り・運用になっているかを確認する作業も重要かと考えられます。
買収前の段階で、最低限これだけは確認しておくと良いでしょう。
- 対象会社が、どのシステムをどんな業務に使っているか（システム構成の棚卸）
- システムの開発体制やセキュリティ確保をどのように行っているか
- それぞれのシステムで、権限管理がどのように行われているか（共有アカウント・退職者アカウントの有無を含む）
- システムの変更履歴・アクセスの記録が、どこまで残っているか
- 外部委託先との契約内容をそもそも記録出来ているか
買収後に慌てて着手するコストと、買収前に確認しておくコストを比べれば、後者のほうがずっと小さくて済みます。M&A前のITデューデリジェンスの段階からご相談いただくケースも増えています。
M&A後のIT全般統制構築でお困りの方へ
上のチェック項目をテンプレート化したものや、買収前のITデューデリジェンスから上場子会社になった後の体制構築まで、会計士とシステム監査技術者の両方の視点でサポートします。まずはお気軽にご相談ください。
まとめ
上場子会社になった瞬間に困るのは、制度を知らないことではありません。困るのは、既存のシステムが統制をまったく前提にせずに作られている、という現実にいきなり向き合わされることです。
買収前のデューデリジェンスにIT全般統制の視点を入れておくかどうかで、買収後の負担の大きさはかなり変わります。もし直近でM&A・子会社化に関わる案件があるなら、まずは対象システムのアクセス管理・変更管理の状況を、一度棚卸ししてみることから始めてみてください。
M&Aの現場では、どうしても事業シナジーや財務数値の話が主役になります。IT全般統制は、契約が終わったあとになって初めて主役に躍り出る、地味だけれど避けて通れないテーマです。買収を決める前の段階で、この視点を持っておけるかどうか。それだけで、買収後の半年間の忙しさがまったく違うものになると、私は考えています。
関連記事
- IT全般統制（ITGC）とは？4つの領域と実務対応｜このシリーズの入り口。IT全般統制の4領域を先に押さえたい人向け。
- J-SOXのIT統制とは？対象範囲・担当部門・対応手順を解説｜J-SOXの中でIT統制がどこに位置するかを整理した記事。
- アカウント棚卸のやり方｜監査を通す業務プロセスと証跡の残し方｜買収先で起きがちな「退職者アカウント残存」への具体的な対処。
- IT全般統制の変更管理｜GitHubのプルリクエストが監査証跡になる仕組み｜買収したシステムの変更が承認なしに行われている場合の、証跡の考え方。
- IT全般統制：SOC1レポートのあるシステムを選ぶべき理由｜委託先のシステムを評価する際に必要なSOC1レポートの解説。
- 監査で指摘されるIT統制不備トップ10｜監査で指摘されるよくある不備を、10個の実例で確認できる記事。
