IPO準備会社の現場をのぞくと、本当に多くのシステムが動いています。会計システム、販売管理システム、購買管理システム、在庫管理システム、給与計算システム、経費精算システム、ワークフロー、CRM、SFA、BIツール、銀行API、クラウドストレージ、チャットツール。挙げていけばきりがありません。
創業期や成長初期には、これらは「業務を早く回すための道具」として導入されるのが普通です。ところが、IPO準備に入った瞬間、システムは単なる便利な道具では済まなくなります。
問われ始めるのは、たとえば次のような点です。
- 売上は正しく計上されているか
- 請求データと入金データは整合しているか
- 仕入・外注費・経費は、承認された取引だけで記録されているか
- 在庫、固定資産、給与、引当金、税金計算の基礎データは信頼できるか
- 誰がマスタを変更したのか
- 誰が承認したのか
- 誰がデータを出力し、どの資料を使って月次決算や開示資料を作成したのか
これらを説明できなければ、決算、監査、内部統制、開示、投資家説明という土台そのものが揺らいでしまいます。
IPO準備におけるIT統制は、IT部門だけが向き合えばよい論点ではありません。会計・決算・業務フロー・権限責任・情報セキュリティ・委託先管理・開示体制を一本につなぐ、経営インフラの論点だと考えています。
IT統制は「システムを入れること」ではない
IPO準備の現場でよく出会う誤解があります。IT統制を「新しい会計システムやERPを導入すること」だと捉えてしまうケースです。
もちろん、システム導入そのものは重要です。Excelや紙、属人的な手作業だけで、成長企業の月次決算、予実管理、内部統制、開示対応を支え続けるには、どうしても限界があります。
しかし、システムを導入しただけでIT統制が整うわけではありません。むしろ、導入したことで新しいリスクが顔を出すこともあります。
- 誰でも売上マスタを変更できてしまう
- 退職者のアカウントが残ったままになっている
- 管理者権限を持つ人が多すぎる
- 承認ワークフローを通さずに例外処理ができてしまう
- CSVで出力したデータをExcelで加工し、その加工過程が残っていない
- システム間の連携エラーに誰も気づかない
- クラウドサービスのバックアップ責任を会社側が理解していない
- ベンダーのSOCレポートは入手しているが、自社で確認すべき統制を見落としている
こうした状態では、システムがあること自体が、内部統制上の安心材料にはなりません。
IT統制の目的は、システムを導入することそのものではありません。システムを通じて処理される業務とデータが、承認された範囲で、正確に、完全に、適時に、改ざんされず、後から検証できる状態で処理されるようにすること。ここに本来の狙いがあります。
なぜIPO準備でIT統制が重要になるのか
IPO準備では、何よりも数字の信頼性が問われます。
売上、原価、在庫、固定資産、給与、経費、債権債務、資金繰り、KPI、予実差異、事業計画、開示資料の基礎情報。これらの多くは、何らかのシステムから生まれてきます。
だからこそ、システム上の権限管理やデータ管理が弱いと、会計上の誤り、不正、決算遅延、監査対応の遅れ、開示資料の誤りへと、そのまま波及してしまうのです。
月次決算を毎月きちんと実施できれば、経営者は判断材料となる数字を手元で把握でき、予算対比を通じて原因や次の打ち手まで確認できるようになります。ただし、それは販売・回収、仕入・支払、経費・生産といった動きを、適時かつ正確に記帳する体制があってこそです。
つまり、月次決算の精度は、会計システム単体で決まるものではありません。その前段にある販売、購買、在庫、給与、経費精算、資金管理といった各システムの統制に支えられています。
IPO準備では、直前々期末までに基本的な管理体制を整え、直前期には上場会社と同水準の管理体制で一定期間の運用実績を示すことが求められます。これはIT統制についても同じです。申請直前にアクセス権限表を慌てて整えても、運用実績が伴わなければ、監査や審査の場での説明はどうしても弱くなります。
IT統制は、上場直前に駆け込みで整えるものではありません。システムを使った業務が日々動いている以上、早い段階から設計し、運用し、証跡を残していく。その積み重ねが必要になります。
現行の内部統制制度で押さえておきたい前提
財務報告に係る内部統制の基準・実施基準は、2023年4月に改訂されました。改訂後の基準・実施基準は、2024年4月1日以後に開始する事業年度から適用されています。金融庁はこの改訂を踏まえ、内部統制報告制度に関するQ&A等についても改訂を行っています。
出典:金融庁|「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について(意見書)」の公表について
出典:金融庁|「内部統制報告制度に関するQ&A」等の改訂について
改訂後の基本的枠組みでは、内部統制の目的として「業務の有効性及び効率性」「報告の信頼性」「事業活動に関わる法令等の遵守」「資産の保全」が示されています。そして、その基本的要素として「統制環境」「リスクの評価と対応」「統制活動」「情報と伝達」「モニタリング」「ITへの対応」が位置づけられています。
ここで見落としたくないのは、ITが独立した技術論点ではなく、内部統制を構成する基本的要素の一つとして扱われている点です。
言い換えれば、IT統制は会計システムの権限設定だけの話ではありません。次のような問いが、まとめて投げかけられることになります。
- 経営者がIT利用方針を持っているか
- どの業務をシステム化し、どの業務を手作業で管理するか判断できているか
- IT利用によって生じる新たなリスクを把握しているか
- IT全般統制とIT業務処理統制に関する方針・手続を定めているか
- ITが財務報告、業務運用、情報伝達、モニタリングにどう関わるかを理解しているか
IT統制は「3層」で整理すると見通しがよくなる
IPO準備でIT統制を考えるときは、次の3層に分けて捉えると、議論が一気に整理しやすくなります。
| 区分 | 役割 | 主な論点 |
|---|---|---|
| IT全社統制 | 会社全体・グループ全体のIT利用方針や管理体制 | IT戦略、IT予算、情報システム体制、IT規程、教育、セキュリティ方針 |
| IT全般統制 | IT業務処理統制が継続して有効に機能するための基盤 | 開発・変更管理、アクセス管理、運用管理、バックアップ、委託先管理 |
| IT業務処理統制 | 業務プロセスに組み込まれたシステム上の統制 | 入力チェック、承認ワークフロー、マスタ管理、エラー処理、処理の完全性・正確性 |
IT全社統制は、会社やグループ全体のIT方針にあたります。経営者がITに関する戦略・計画を定め、IT環境を理解し、手作業とIT統制それぞれの利用領域を判断し、ITを使うことで生じる新たなリスクを考慮する。こうした営みが含まれます。
IT全般統制は、システムが安定的・継続的に正しく動くための土台です。システム開発・変更、運用管理、アクセス管理、外部委託契約などが典型例といえます。
IT業務処理統制は、販売、購買、在庫、給与、経費、会計といった業務プロセスに組み込まれた統制です。入力情報の完全性・正確性・正当性、例外処理、マスタデータ管理、認証や操作範囲の限定などが、ここに当たります。
この3層を分けずに議論を進めると、「システム部門がやるべき話」「経理が確認すべき話」「経営者が決めるべき話」が混ざり合ってしまいます。
IPO準備では、IT統制を技術部門だけに委ねるのではなく、CFO、経理、経営企画、内部監査、法務、人事、情報システム、そして現場部門が連携しながら整理していくことが欠かせません。
すべてのシステムを同じ深さで評価する必要はない
IT統制を整えようとすると、社内のすべてのシステムについて詳細な評価が要る、と身構えてしまいがちです。
しかし、IPO準備で本当に大切なのは、財務報告、月次決算、開示、重要な業務プロセスに影響するシステムから優先して整えていくことです。
IT統制の評価では、すべてのシステムを一律に評価対象とするのではなく、論理的に対象を絞り込むことで効率化が図れます。とりわけIT全般統制の評価範囲は、評価対象となる業務プロセスに組み込まれたIT業務処理統制から逆算して決める考え方が有効です。
たとえば、次のようなシステムは優先度が高くなります。
- 売上計上に使う販売管理システム
- 請求・入金消込に使うシステム
- 在庫数量や原価計算に関係するシステム
- 仕入・外注費・購買承認に関係するシステム
- 固定資産台帳や減価償却計算に使うシステム
- 給与計算・勤怠管理・人件費計上に使うシステム
- 経費精算・支払承認に使うシステム
- 会計システム
- 連結パッケージや開示資料作成に使うツール
- KPIや事業計画の基礎データを集計するBI・DWH
反対に、財務報告へ直接影響しない補助的なツールであれば、同じ深さで評価する必要がない場合もあります。
大切なのは、次のような問いに具体的に答えられることです。「このシステムが止まると、どの業務が止まるのか」「このシステムのデータが誤ると、どの勘定科目や開示情報が誤るのか」「このシステムの権限が不適切だと、どの不正や誤謬が起こりうるのか」。こうした問いに自分の言葉で答えられるかどうかが、評価範囲を見極める軸になります。
クラウド時代の落とし穴|「SaaSなら安心」ではない
近年、IPO準備会社の多くがクラウドサービスを利用しています。
会計、販売、購買、在庫、勤怠、給与、経費精算、契約管理、電子署名、ワークフロー、CRM、SFA、BI、データ連携。複数のSaaSを組み合わせて業務を回す会社は、もはや珍しくありません。
クラウドサービスには、導入スピード、拡張性、可用性、保守負担の軽減といった大きなメリットがあります。一方で、内部統制の観点からは、次の問いが必ず残ります。
- クラウド事業者が担う統制はどこまでか
- 利用会社が担う統制はどこからか
- SOCレポートで何が確認でき、何が確認できないか
- アプリケーション設定、権限付与、マスタ変更、データ出力、バックアップ、ログ確認は、それぞれ誰の責任か
- 障害時、サイバー攻撃時、契約終了時に、データをどう守るか
クラウドや外部データセンターにインフラ運用を委託していても、企業は自己の責任で内部統制を評価しなければなりません。SOCレポートによって一部の評価手続を代替できる場合はありますが、SaaSだからといって、すべてのIT全般統制をSOC1に依拠できるわけではありません。開発・変更管理、ユーザーID管理、日常的なバックアップや復旧など、自社で整備・運用すべき統制は確実に残ります。
「クラウドだから、ベンダーが全部やってくれている」。この理解は、率直に言って危ういものです。クラウド時代のIT統制では、ベンダー任せにせず、自社の責任範囲をはっきりさせておくことが何より重要になります。
アクセス権限管理|最初に整えるべき統制
IT統制のなかで、まず最初に整えたいのがアクセス権限管理です。
理由はシンプルです。誰がシステムに入れるのか、誰が何を変更できるのかが曖昧なままでは、どれほど優れた業務フローや承認規程を整えても、実務上の統制が抜け落ちてしまうからです。
IPO準備会社で特に問題になりやすいのは、次のような状態です。
- 退職者や異動者のアカウントが残っている
- 複数人で共通IDを使い回している
- 管理者権限を持つ人が多い
- 経理担当者が販売マスタや商品マスタを自由に変更できる
- 営業担当者が請求済みデータを修正できる
- 承認者が自分で申請し、自分で承認できてしまう
- 外部委託先や開発会社のアカウントが常時有効になっている
- 権限表が、現行の組織図や職務分掌と一致していない
アクセス権限管理では、本番稼働しているプログラム、データ、マスタデータ、システムユーティリティへのアクセスを制限することが基本になります。あわせて、ユーザーID申請を適切な者が承認し、人事異動・退職に伴う見直しも含めて定期的に確認し、セキュリティ上の問題事象を重要度に応じて経営者等へ報告する。この一連の流れが大切です。
IPO準備会社であれば、少なくとも次の管理は行っておきたいところです。
- 入社時に、必要な権限だけを付与する
- 異動時に、旧権限を削除する
- 退職時に、速やかにアカウントを停止する
- 管理者権限を限定する
- 四半期または半期ごとに権限棚卸を行う
- 共通IDを原則廃止する
- 外部委託先のアカウントに期限を設ける
- 重要システムには多要素認証を検討する
- 権限申請、承認、設定、棚卸の証跡を残す
アクセス権限管理は、地味に見えるかもしれません。しかし、ここがIPO準備におけるIT統制の出発点になります。
変更管理|システム変更を「誰かが直した」で済ませない
次に押さえておきたいのが変更管理です。
システムの仕様、計算ロジック、承認ルート、マスタ項目、データ連携、帳票、会計仕訳連携。これらを変更すると、業務処理や会計数値にそのまま影響が及びます。
たとえば、次のような変更は会計・決算に直結します。
- 売上計上タイミングに関するシステム設定の変更
- 請求書発行ロジックの変更
- 在庫評価や原価計算ロジックの変更
- 給与計算・社会保険料計算設定の変更
- 経費精算の勘定科目自動判定ルールの変更
- ワークフロー承認ルートの変更
- 会計システムへの仕訳連携設定の変更
- 連結パッケージや開示用データ出力フォーマットの変更
変更管理で肝心なのは、変更前に目的、影響範囲、承認、テスト、本番反映、事後確認がきちんと管理されていることです。
開発・変更管理では、実際に変更プログラムが登録された履歴などのリストを母集団として把握しておかなければ、母集団の完全性・網羅性が保てません。アクセス管理についても、ユーザーID一覧表から変更案件を抽出し、承認済み申請書や情報システム部門の確認証跡を確かめる、といった手続が考えられます。
SaaSの場合、会社がソースコードを書き換えないため、変更管理は不要だと思われがちです。しかし、SaaSであっても変更管理は必要です。
- 承認ルートの設定変更
- 権限ロールの変更
- マスタ項目の追加
- API連携設定の変更
- 会計連携ルールの変更
- バージョンアップ時の影響確認
- 新機能の有効化
- 外部アプリとの連携許可
これらはすべて、業務と会計数値に影響しうるものです。
「開発していないから変更管理は不要」ということにはなりません。クラウド時代には、むしろ設定変更、連携変更、権限変更こそが管理すべき対象になります。
マスタ管理|小さな変更が、大きな誤りになる
IPO準備会社で見落とされやすいのが、マスタデータ管理です。
取引先マスタ、商品マスタ、単価マスタ、勘定科目マスタ、部門マスタ、従業員マスタ、固定資産マスタ、銀行口座マスタ、承認ルートマスタ。これらは、日々の処理の前提そのものです。
マスタが誤っていれば、その後の取引処理は自動的に誤っていきます。
- 取引先の請求条件が誤っている
- 商品単価が古いままになっている
- 税区分が誤っている
- 勘定科目連携が誤っている
- 給与計算上の従業員区分が誤っている
- 部門コードが古い
- 固定資産の耐用年数や償却方法が誤っている
- 銀行口座マスタが不適切に変更されている
これらは、単なる入力ミスでは済みません。大量の取引に波及し、月次決算や開示資料の誤りへとつながっていきます。
マスタ管理では、申請、承認、登録、変更履歴、定期棚卸を整えておく必要があります。とりわけ、支払先口座、商品単価、会計連携、給与・人事情報など、不正や財務報告への影響が大きいマスタは、重点的に管理しておきたいところです。
データ連携|API・CSV・Excelの「境目」がリスクになる
IPO準備会社では、複数のSaaSを組み合わせて業務を回すことが多くなっています。
- 販売管理から会計へ売上仕訳を連携する
- 経費精算から会計へ経費仕訳を連携する
- 給与計算から会計へ人件費仕訳を連携する
- 在庫管理から原価データを取り込む
- CRMからKPIを集計する
- 銀行データを会計システムに取り込む
- BIツールで経営会議資料を作成する
このとき、リスクが顔を出すのは、システムとシステムの境目です。
- API連携が止まっている
- CSV出力の対象期間が誤っている
- 同じ取引が二重に取り込まれている
- 手作業でExcel加工した際に行が欠落している
- マスタコードの不一致で一部データが除外されている
- 連携エラーが出ているのに誰も確認していない
- データ加工の過程が残っていない
こうした状態では、システムそのものが正しくても、出来上がる決算資料は誤ってしまいます。
データ連携では、少なくとも次の統制を備えておきたいところです。
- 連携対象データの範囲を明確にする
- 件数、金額、期間、対象会社、対象部門を照合する
- 連携エラーを確認する
- 手作業加工がある場合は、加工前後の証跡を残す
- Excelやスプレッドシートの計算ロジックを保護する
- 誰がデータを出力し、誰が加工し、誰がレビューしたかを残す
- BIやKPI資料についても、元データとの整合を確認する
IT統制では、システム内の処理だけでなく、システムの外に出た後のデータの扱いまでが管理対象になります。
EUC・Excel管理|「最後にExcelで壊れる」会社は多い
IPO準備会社では、システム化が進んでいても、最後の集計や調整をExcelやスプレッドシートで行っているケースが少なくありません。
- 売上集計
- KPI集計
- 引当金計算
- 税効果計算
- 固定資産管理
- 在庫評価
- 連結精算表
- 開示資料の基礎表
- 資金繰り表
- 予実管理資料
これらは、EUC、つまりエンドユーザーコンピューティングの領域に属します。
Excelを使うこと自体が問題なのではありません。問題は、重要な計算や開示数値の作成に使われているにもかかわらず、それが管理されていないことです。
- 計算式が壊れている
- 前月ファイルをコピーして、不要な行が残っている
- リンク切れが起きている
- 担当者しか分からない加工がある
- 保護されていないセルを誰でも変更できる
- バージョン管理がない
- レビュー証跡がない
表計算ソフトを使う場合でも、計算シートへのアクセス制限、計算ロジック変更時の事前・事後承認、計算結果に対するレビューといった対応が、IT業務処理統制として重要になります。
IPO準備では、「システム化されていないから統制は不要」とはなりません。むしろ、システムの外にあるExcelこそ、誤りが生まれやすい重要な統制対象なのです。
ログ管理|「集めるだけ」では統制にならない
ログ管理も、クラウド時代の重要な論点です。
ログを取得している会社は増えています。しかし、取得しているだけでは、内部統制としては不十分です。
- どのログを取るのか
- どの期間保存するのか
- 誰が見るのか
- どの異常を検知するのか
- 異常時に、誰へ報告するのか
- ログが改ざんされないよう、どう保全するのか
- 監査や内部監査の場で提示できるか
これらが定まっていなければ、ログは「何かあったときに見るかもしれない記録」のままで止まってしまいます。
IPO準備会社で特に管理しておきたいログには、次のようなものがあります。
- 管理者権限の利用ログ
- ユーザーIDの作成・変更・削除ログ
- マスタ変更ログ
- 承認ルート変更ログ
- 重要取引の修正・削除ログ
- 会計仕訳の修正ログ
- データ出力ログ
- 外部委託先や開発会社のアクセスログ
- ログイン失敗や不審アクセスのログ
- API連携エラーログ
ログ管理の目的は、監視そのものにあるわけではありません。異常を早期に把握し、原因を追跡し、財務報告・業務・情報セキュリティへの影響を評価できる状態をつくること。ここに本来の狙いがあります。
委託先管理|外部に出しても、責任は消えない
クラウドサービス、データセンター、開発会社、保守会社、給与計算会社、BPO会社、決算支援会社。IPO準備会社は、実に多くの外部委託先に依存しています。
しかし、業務を外部へ委託しても、内部統制上の責任までなくなるわけではありません。
外部委託している業務であっても、経営者はそれを内部統制の評価範囲から除外することはできません。委託業務の内容によっては、委託先からの報告と基礎資料の整合性確認、自社でのサンプリング検証、SOCレポートの利用などを検討する必要が出てきます。
委託先管理では、次の観点を整理しておきたいところです。
- 委託先の選定基準
- 委託業務の範囲
- セキュリティ要件
- サービスレベル
- 障害時の対応
- データの保存場所
- 再委託の有無
- 監査権・報告義務
- SOCレポート等の入手可能性
- 契約終了時のデータ返還・削除
- インシデント発生時の通知義務
クラウドサービスについても、利用規約やSLAだけで済ませるのではなく、自社の重要業務や会計処理にどの程度影響するサービスなのかを踏まえて確認しておくことが大切です。
サイバーリスクは、上場準備会社にとっても現実の経営リスク
IPO準備会社にとって、サイバーリスクは「大企業だけの問題」ではありません。
ランサム攻撃、サプライチェーン攻撃、委託先を狙った攻撃、システム脆弱性の悪用、内部不正、ビジネスメール詐欺、リモートワーク環境への攻撃。これらは、成長企業にも十分に起こり得ます。
IPAが公表した「情報セキュリティ10大脅威 2026」では、組織向けの脅威として、ランサム攻撃、サプライチェーンや委託先を狙った攻撃、AIの利用をめぐるサイバーリスク、システム脆弱性を悪用した攻撃、内部不正による情報漏えい等が挙げられています。
出典:IPA(情報処理推進機構)|情報セキュリティ10大脅威 2026
また、経済産業省は、サイバー攻撃の多様化・巧妙化や、サプライチェーンを介した被害拡大を踏まえ、経営者が認識すべき事項やCISO等に指示すべき事項をまとめた「サイバーセキュリティ経営ガイドライン」を改訂しています。
出典:経済産業省|「サイバーセキュリティ経営ガイドライン」を改訂しました
IPO準備会社でサイバーインシデントが起きると、次のような影響が広がっていきます。
- 月次決算が締まらない
- 請求・入金管理が止まる
- 在庫・出荷・購買が止まる
- 顧客情報や取引先情報が漏えいする
- 監査証拠が取得できない
- 主幹事証券や監査法人への説明が必要になる
- 事業計画の前提が崩れる
- 開示リスクやレピュテーションリスクが発生する
サイバーリスクは、情報システム部門だけの問題ではありません。事業継続、財務報告、開示、企業価値、投資家からの信頼に関わる、れっきとした経営リスクです。
IPO準備会社が整えるべきIT統制の「順番」
IT統制は、すべてを一度に整えようとすると、現場が疲弊してしまいます。だからこそ、優先順位をつけることが重要です。
1.システム棚卸とデータフローを作る
まずは、自社がどのシステムを使っているかを棚卸します。
- システム名
- 利用部門
- 業務目的
- 管理責任者
- 利用者数
- 管理者権限者
- 外部委託先
- 財務報告への影響
- 連携先システム
- 出力データの利用先
この棚卸がないと、IT統制の評価範囲そのものを決められません。
2.財務報告・月次決算に重要なシステムを特定する
次に、売上、原価、在庫、固定資産、給与、経費、支払、会計、連結、開示、KPIに影響するシステムを特定します。
すべてのシステムを同じ深さで見るのではなく、財務報告や開示に影響するシステムから優先します。
3.アクセス権限を整える
ユーザーID、管理者権限、退職者アカウント、共有ID、外部委託先IDを確認します。
特に、マスタ変更、仕訳修正、支払データ作成、承認ルート変更、データ出力に関わる権限は、重点的に確認します。
4.変更管理を整える
システム変更、設定変更、マスタ変更、連携変更、帳票変更について、申請、承認、テスト、本番反映、事後確認のルールを定めます。
SaaSであっても、設定変更やバージョンアップの影響確認は欠かせません。
5.データ連携とEUCを管理する
API、CSV、Excel加工、BI集計、連結パッケージ、開示基礎資料について、元データから最終資料までの流れを確認します。
件数・金額の照合、エラー確認、加工履歴、レビュー証跡を残します。
6.ログ・バックアップ・障害対応を整える
ログは取得するだけでなく、誰が確認し、どの異常を報告するかまで決めておきます。
バックアップも「取っている」だけでは足りません。実際に復旧できるかどうかを確認します。クラウドサービスの場合は、自社がバックアップやデータエクスポートをどう担保するかもあわせて検討します。
7.委託先管理を整える
クラウド事業者、開発会社、保守会社、BPO先について、契約、SLA、セキュリティ要件、SOCレポート、障害時対応、監査対応を確認します。
8.内部監査・J-SOXへ接続する
最後に、IT統制を内部監査やJ-SOX評価へ接続します。
IT統制は、「整えたつもり」では不十分です。運用テスト、証跡確認、不備改善、ロールフォワード評価、監査法人との協議に耐える形にまで仕上げていく必要があります。
システム導入のタイミングにも注意が必要
IPO準備の途中で、基幹システムや会計システムを入れ替える会社があります。
これは必要な場合もありますが、タイミングを誤ると大きなリスクになります。
- N-1期に会計システムを入れ替える
- 申請期直前に販売管理システムを変更する
- 監査対応の最中にERP導入を始める
- データ移行の検証が不十分なまま本番稼働する
- 旧システムと新システムの残高整合が取れていない
- 新システムの権限設計が間に合っていない
- 新旧システムの監査証跡が分断されている
こうした状態に陥ると、決算、監査、内部統制評価のいずれもが不安定になってしまいます。
システム導入は、単なるITプロジェクトではありません。IPO準備会社では、会計方針、業務フロー、職務分掌、権限設計、データ移行、監査証跡、月次決算、開示スケジュールにまで影響が及びます。
したがって、IPO準備中のシステム導入では、次の観点を事前に整理しておきたいところです。
- どの決算期に本番稼働するか
- 旧システムのデータをどこまで保存するか
- 移行データの完全性・正確性をどう検証するか
- 新システムの権限設定を誰が承認するか
- 変更管理の証跡をどう残すか
- 監査法人へ、どのタイミングで説明するか
- 本番稼働後の不具合が決算へ与える影響をどう管理するか
システム導入は、早ければよいというものではありません。IPOスケジュールと決算・監査スケジュールに照らし合わせ、いつ、どの範囲で、どのリスクを許容して進めるのか。これを経営判断として決めていく必要があります。
IT統制でよくある失敗
IPO準備会社がIT統制を整える際には、次のような失敗がよく見られます。
システム一覧はあるが、財務報告への影響が整理されていない
単なるシステム台帳だけでは不十分です。どのシステムが、どの業務、勘定科目、開示資料、KPIに影響するのかを整理しておく必要があります。
管理者権限が多すぎる
便利だからという理由で、多くの社員に管理者権限を付与している会社があります。管理者権限は通常権限とは分けて管理し、利用者、利用理由、利用ログ、棚卸まで行う必要があります。
退職者・異動者の権限が残っている
人事異動や退職と、システム権限の変更が連動していない会社では、不要な権限が長期間にわたって残り続けます。人事・情報システム・各部門の連携が欠かせません。
SaaSのSOCレポートを過信している
SOCレポートは有用です。しかし、会社側の権限管理、設定管理、マスタ管理、バックアップ、データ出力管理までは、カバーされないことがあります。自社の責任範囲を確認しておかなければなりません。
Excel加工がブラックボックスになっている
システムから出したデータが正しくても、Excel加工で誤れば、最終数値は誤ります。EUC管理は、決算早期化・監査対応・開示品質に直結します。
ログはあるが、見ていない
ログを取得していても、確認ルールや異常時の報告ルートがなければ、統制としては機能しません。
IT部門と経理部門が分断されている
IT部門はシステムの安定稼働を見ており、経理部門は会計数値への影響を見ている。両者が分断されていると、システム変更が会計処理に与える影響を見落とすことになります。
システム導入がIPOスケジュールと整合していない
基幹システム入替、ERP導入、会計システム変更は、監査対応や内部統制評価に大きく影響します。導入時期は、IPOロードマップと合わせて検討すべきです。
経営者がIT統制に関与すべき理由
IT統制は、一見すると専門的な領域に映ります。
しかし、経営者が関与しなければ、IPO準備に耐えうるIT統制を作ることはできません。
なぜなら、IT統制の本質は、どのリスクを取り、どのリスクを抑えるかという経営判断そのものだからです。
- どのシステムを基幹システムと位置づけるか
- どの業務を標準化するか
- どのデータを経営管理に使うか
- どの情報を投資家説明に使うか
- どのサイバーリスクを優先して対策するか
- どのタイミングでシステム投資を行うか
- どの範囲を内製し、どの範囲を外部委託するか
- どの責任者にIT管理を担わせるか
これらは、IT部門だけで決められるものではありません。
IPOを目指す会社にとって、IT統制は守りの作業であると同時に、成長を支える管理の仕組みでもあります。正確なデータがなければ、事業計画もKPIも予実管理も投資家説明も成り立ちません。システムが止まれば、決算も開示も止まります。情報漏えいが起きれば、信用と企業価値に影響が及びます。
経営者には、IT統制を「監査法人に言われたから整えるもの」と捉えるのではなく、「投資家から選ばれる会社になるために、データと業務の信頼性を支えるもの」と捉えていただきたいと考えています。
まとめ|クラウド時代のIT統制は、経営・会計・業務・セキュリティをつなぐ
IPO準備におけるIT統制は、システム導入やセキュリティ製品の選定ではありません。
IT統制とは、会社の業務、会計処理、月次決算、監査、内部統制、開示、事業継続をつなぐ仕組みです。
クラウドサービスを利用していても、自社の責任は残ります。SaaSを使っていても、権限管理、設定管理、マスタ管理、データ連携、ログ確認、バックアップ、委託先管理は必要です。
システムが自動で処理していても、その処理が正しく設計され、正しく変更され、正しく運用されているかを確認しなければなりません。Excelやスプレッドシートを使っている場合も、重要な計算や開示資料に影響するなら、当然、統制対象になります。
IPO準備で問われるのは、「どのシステムを使っているか」ではありません。「どの業務と数字が、どのシステムとデータによって支えられているか」を説明できることです。
IT統制が整っている会社は、月次決算が安定し、監査対応が進み、予実管理が機能し、開示資料の基礎データにも信頼性が生まれます。
一方で、IT統制が弱い会社は、見た目にはシステム化が進んでいても、数字の根拠、承認の証跡、変更の履歴、データの完全性、委託先の管理を説明できません。
クラウド時代のIPO準備では、IT統制を「専門部門の技術課題」ではなく、「資本市場に対して説明可能な会社をつくるための経営課題」として捉える必要があります。
IPO準備に向けたIT統制・システム管理でお悩みの方へ
IT統制は、会計システムだけを見ていても整いません。
販売、購買、在庫、固定資産、給与、経費、資金管理、会計、連結、開示、KPI、クラウドサービス、外部委託先、そしてExcel管理まで含めて、業務フローとデータの流れを丁寧に整理していく必要があります。
犬飼公認会計士・税理士事務所では、IPO準備を単なる上場審査対応とは捉えていません。会社を資本市場に耐える経営体へと整えるプロセスとして捉え、月次決算、業務フロー、規程・職務分掌、IT統制、J-SOX、会計・税務、監査法人対応を横断して整理します。
自社のクラウドサービス利用状況、アクセス権限、データ連携、Excel管理、委託先管理、監査対応上の課題を棚卸ししたい場合は、現在のシステム構成と業務フローをもとに、優先して整えるべき論点を確認することができます。
IPO準備・IT統制・内部管理体制に関するご相談は、犬飼公認会計士・税理士事務所HPのお問い合わせページよりご連絡ください。
本記事の振り返り
| 論点 | 重要なポイント |
|---|---|
| IT統制の本質 | システム導入ではなく、業務とデータが正確・完全・適時・検証可能に処理される仕組みを整えること |
| IPO準備での重要性 | 売上、原価、在庫、給与、経費、会計、KPI、開示資料の信頼性が、システムとデータに依存する |
| IT全社統制 | 経営者がIT戦略、IT利用方針、ITリスク、管理体制を定める、会社全体の統制 |
| IT全般統制 | 開発・変更管理、アクセス管理、運用管理、バックアップ、委託先管理など、IT業務処理統制を支える基盤 |
| IT業務処理統制 | 入力チェック、承認ワークフロー、マスタ管理、例外処理、認証・操作範囲限定など、業務プロセスに組み込まれた統制 |
| 評価範囲 | すべてのシステムを同じ深さで見るのではなく、財務報告・月次決算・開示に影響するシステムから優先する |
| クラウド利用 | SaaSやクラウドでも、自社側の権限管理、設定管理、データ管理、バックアップ、委託先管理は残る |
| アクセス権限 | 退職者ID、共有ID、管理者権限、外部委託先ID、権限棚卸を重点管理する |
| 変更管理 | システム変更だけでなく、SaaS設定変更、承認ルート変更、API連携変更、マスタ変更も管理対象になる |
| データ連携 | API、CSV、Excel加工、BI集計では、件数・金額・期間・エラー・加工履歴の確認が重要 |
| EUC管理 | Excelやスプレッドシートが重要な計算・開示資料に使われる場合、計算ロジック、アクセス、レビュー、版管理が必要 |
| ログ管理 | ログは取得するだけでなく、確認対象、保存期間、異常時報告、改ざん防止を設計する |
| 委託先管理 | 外部委託しても内部統制上の責任は消えず、契約、SLA、SOCレポート、自社側統制を確認する必要がある |
| サイバーリスク | ランサム攻撃、サプライチェーン攻撃、内部不正、AIリスクなどは、決算・開示・企業価値にも影響する経営リスク |
| 経営者の役割 | IT統制はIT部門任せにせず、成長、会計、開示、事業継続、投資家説明を支える経営課題として関与する |