無料で情報を見る

システム開発・導入プロジェクトの監査｜要件定義から移行判定まで

読了 約19分監修 iAudit 編集部

稼働予定日まで残り 3 か月。基幹システム刷新プロジェクトの定例会で配られた進捗報告は、どのページを開いても信号が緑でした。ところが会議の後、経理部の課長が内部監査部の担当者を呼び止め、小声でこう言います。「新しい仕訳の承認画面、まだ一度も触らせてもらっていないんです」。

内部監査部長のもとには、同じ週に社長から一言が届いていました。「稼働前に内部監査の目も入れておいてほしい」。けれども部内には開発経験のある人がおらず、「今から入って何を見ればよいのか」「止める権限もない監査部が口を出してよいのか」と議論が続きます（本記事の事例はすべて架空のモデルケースです）。

システム開発・導入プロジェクトは、完成してから監査したのでは手遅れになりやすい領域です。稼働後に見つかった統制の欠落は、改修費用だけでなく、財務報告の誤りや業務停止となって表に出ます。この記事では、プロジェクトの途中から内部監査が関与する際の考え方と、要件定義から移行判定、稼働後までのフェーズ別の監査ポイントを整理します。

この記事の要点

  • 金融庁の実施基準は、IT全般統制の例として「システムの開発、保守に係る管理」を挙げ、開発・調達時の承認、導入前の試験、データ移行時の誤謬防止、利用者教育などを留意点として示しています
  • プロジェクト監査は「完成品の検査」ではなく、各フェーズの判断が根拠を持って行われているかを確かめる活動です
  • 内部監査はプロジェクトの意思決定者にならず、アドバイザリーとアシュアランスの境界を業務開始前に取り決めます
  • 重点は、統制要件の織り込み、要件とテストのつながり、データ移行の完全性・正確性、事前に合意された移行判定基準の 4 点です
  • 稼働後は、暫定権限の解除と、変更管理・運用管理への引き継ぎまでを確認して監査を閉じます

なぜシステム開発プロジェクトを内部監査が見るのか

実施基準が示す「開発・保守」の位置づけ

金融庁企業会計審議会の「財務報告に係る内部統制の評価及び監査に関する実施基準」は、ITに係る全般統制の具体例として、システムの開発・保守に係る管理、システムの運用・管理、内外からのアクセス管理などシステムの安全性の確保、外部委託に関する契約の管理の 4 つを挙げています。開発・保守が先頭に置かれているのは偶然ではありません。実施基準は、ITに組み込まれた業務処理統制は「一旦適切に組み込めば継続して機能する」性質を持つ一方、変更の段階で必要な統制が組み込まれなかった場合には有効性が保証されなくなる、と説明しています。

つまり、自動化された統制の品質は、開発の時点でほぼ決まります。監査人向けの記述では、開発・調達・変更について事前に適切な管理者の承認を得ていること、開発目的に適合した手法が適用されていること、導入前に十分な試験が行われ利用部門とIT部門の適切な管理者が承認していること、過程が記録・保存されること、データを移行する際に誤謬・不正等を防止する対策が取られていること、利用者が計画に基づく教育研修を受けていること、が留意点として挙げられています。これが、プロジェクト監査の最低限の物差しになります。

「稼働後に直す」が高くつく理由

開発の後工程になるほど、欠陥の修正は高くつきます。要件定義で「承認者と起票者を同一人物にできない」と一文書けば済んだことが、稼働後には画面・権限・帳票・過去データの改修に広がります。さらにJ-SOXの評価では、期中に基幹システムが切り替わると、旧システムと新システムの両方で統制を評価する必要が生じることがあります。稼働直後に統制の不備が見つかれば、期末までに是正と運用実績の蓄積が間に合うかという問題にもなります。

もう一つの理由は、プロジェクトには「楽観的な報告」が構造的に生まれやすいことです。進捗報告の作成者は、遅れを報告すれば自分の管理能力が問われる立場にあります。経営陣が独立した目を求めるのはこのためで、内部監査は、報告の根拠となる事実を確かめる役割を担えます。

システム管理基準との関係

経済産業省の「システム管理基準」（2023 年 4 月改訂）は、ITガバナンスとITマネジメントの実践規範をまとめたもので、ITマネジメントの領域にプロジェクトマネジメントや企画・開発・運用・保守などのプロセスを含んでいます。2024 年 12 月には、財務報告に係るIT統制の観点から整理した「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」も改訂されました。監査項目を一から考えるより、これらを参照して自社版の監査プログラムを作るほうが抜けを防げます。基準の全体像はシステム監査基準・システム管理基準の要点で解説しています。

関与の型と独立性：監査部は「止める人」ではない

3 つの関与の型

プロジェクトへの関与には、大きく 3 つの型があります。規模やリスク、監査資源に応じて使い分けます。

関与の型 内容 長所 注意点
継続関与型 ステアリングコミッティにオブザーバー参加し、各フェーズの終了時に所見を報告 早期に指摘でき、手戻りが小さい プロジェクトの一員と見られやすい。発言が意思決定と受け取られないよう議事録で立場を明記
フェーズゲート型 要件定義完了・テスト完了・移行判定前など、節目ごとに短期の監査を実施 資源が読みやすく、独立性を保ちやすい ゲートの日程変更に合わせる柔軟さが必要
稼働後監査型 稼働後 3〜6 か月で、統制の定着と移行結果を監査 事実に基づいて評価できる 指摘の多くが改修を要し、是正コストが大きい

リスクの高いプロジェクトでは、フェーズゲート型を基本に、移行判定の前に重点を置く組み合わせが現実的です。監査計画の立て方は個別監査計画と監査プログラムの設計も参考にしてください。

独立性と客観性の線引き

IIAの「グローバル内部監査基準」は、基準 2.2「客観性の防御」で、内部監査人が過去 12 か月以内に責任を有していた活動にアシュアランス業務を提供する場合、客観性が侵害されていると推定されるとしています。プロジェクト監査に置き換えると、監査人が要件の決定や設計の承認に加わってしまうと、その後の監査で自分の判断を評価することになります。

そこで、業務開始前に「監査部は意見を述べるが、承認・判定はしない」ことを文書で合意します。移行判定会議に出席する場合も、判定者ではなく「判定基準の充足状況について所見を述べる立場」と明記します。助言中心の関与であればアドバイザリー業務として位置づけ、後に同じ領域でアシュアランスを行う際に担当者を替えるなどの配慮をします。詳しくは内部監査のアドバイザリー業務をご覧ください。

フェーズ別の監査ポイント

5つの区間に分かれた道とゲートで各フェーズの確認点を示す図
プロジェクトを区間に分け、各ゲートで判断の根拠を確かめる考え方を示しています。監査は完成品の検査ではなく、次に進む判断が根拠を持って行われたかを見る活動です。

プロジェクトの呼び方は開発手法によって異なりますが、監査の観点はおおむね次の表のように整理できます。アジャイル型の開発でも、各スプリントの受入れや、リリース判定に同じ問いを当てはめられます。

フェーズ 主なリスク 確認する資料 監査の問い
企画・承認 目的や費用対効果が不明確なまま着手する 企画書、投資稟議、承認記録 誰が、何を根拠に、どの金額まで承認したか
要件定義 統制要件・非機能要件の欠落、利用部門の合意不足 要件定義書、業務フロー、合意記録 業務処理統制と権限設計が要件に書かれているか
設計・開発 要件からの逸脱、職務分掌の崩れ 設計書、レビュー記録、開発環境の権限一覧 開発者が本番環境に手を加えられない構成か
テスト 網羅性不足、利用部門の受入れ形骸化 テスト計画、要件対応表、不具合一覧、受入れ承認 要件ごとにテストがあり、残存不具合が評価されたか
データ移行 移行漏れ・変換誤り・不正な書換え 移行計画、変換ルール、件数・金額の突合表 移行結果を業務部門が照合し、承認したか
移行判定・稼働 基準を満たさないまま稼働、切戻し不能 判定基準、判定会議の議事録、切戻し計画 基準は事前に合意され、判定は基準に照らして行われたか
稼働後 暫定措置の放置、運用への引継ぎ漏れ 障害記録、暫定権限一覧、引継ぎ書 暫定措置は期限内に解消され、通常の統制に戻ったか

企画・承認：投資判断の根拠を確かめる

最初に見るのは、プロジェクトの目的と承認の記録です。投資額が職務権限規程のどの決裁区分に当たり、正しい決裁者が承認したか。費用が増えた場合に、誰の承認で予算を変更するのか。こうした基本が曖昧なプロジェクトは、後の判断もぶれやすくなります。パッケージやSaaSを導入する場合は、選定の比較記録と、委託先の評価（SOC報告書の入手可否など）も確認します。委託先評価の観点は委託先管理の監査で整理しています。

要件定義の監査：統制要件と非機能要件が抜けていないか

業務処理統制を「要件」として書かせる

要件定義書は、利用部門の要望を集めた文書になりがちです。監査で確認したいのは、その中に統制要件、つまり誤りや不正を防ぐための仕組みが書かれているかです。たとえば、入力時のチェック（必須項目、範囲、重複）、承認のワークフローと承認者の条件、マスタ変更の承認、自動計算のロジック、インタフェースの件数照合、エラー時の処理などです。これらは稼働後にITを利用した業務処理統制（ITAC）として評価される対象になります。ITACとITGCの関係はITACとITGCの違いをご覧ください。

実務では、既存の業務記述書やRCMから「現行システムで自動化されている統制」を一覧にし、新システムでどう実現するかを要件と突き合わせる方法が有効です。現行の統制が新システムで手作業に戻るなら、その手作業の担当者と記録方法も決めておく必要があります。

権限設計と職務分掌

権限（ロール）の設計は、要件定義から設計の段階で決まります。起票と承認、マスタ登録と取引入力、支払データ作成と送信といった組合せを、1 人が持てない設計になっているかを確認します。テストの便宜で広い権限を付与したまま本番に移行する例は多く、要件段階で「稼働時の権限は職務分掌表に基づき付与する」ことを決めておくと防げます。権限付与後の監査手順はアクセス管理の監査手順で解説しています。

非機能要件

性能、可用性、バックアップ、ログの保存期間、セキュリティなどの非機能要件は、利用部門から出てきにくい要件です。情報処理推進機構（IPA）は「非機能要求グレード」を公開しており、項目の抜けを確認する道具として使えます。また IPA の「ユーザのための要件定義ガイド 第2版」は、要件定義で発注者側が陥りやすい問題と対応をまとめています。監査では、これらを参照して、少なくとも「障害時にどこまで遡ってデータを戻せるか」「ログをどれだけの期間、誰が見られるか」が決まっているかを確かめます。

テストの監査：件数ではなく「つながり」を見る

要件とテストの対応表

テスト工程の報告では「テストケース 3,000 件、消化率 98%」といった数字が並びます。しかし件数が多くても、統制要件に対応するテストが含まれていなければ意味がありません。監査では、要件ごとにどのテストケースで確認したかを示す対応表（トレーサビリティマトリクス）を求め、統制要件に対応するテストの有無を確認します。対応表がなければ、統制要件を 10〜20 件抜き出し、該当するテスト結果を探す方法でも実態がつかめます。

利用部門の受入れテストと承認

実施基準は、導入前の試験結果が「利用する部門の適切な管理者」と「IT部門の適切な管理者」により承認されていることを留意点に挙げています。受入れテストをベンダーやIT部門が代行し、利用部門は承認欄に押印するだけという形は、この趣旨に沿いません。冒頭のモデルケースのように、経理担当者が承認画面を触っていない状態は、受入れが形骸化している兆候です。

残存不具合の扱い

稼働時点で不具合がゼロになることはまれです。重要なのは、残った不具合を重要度で分類し、稼働への影響と回避策を評価したうえで、誰かが受け入れを判断していることです。次の記入例のように、監査調書では「数」ではなく「判断の根拠」を記録します。

確認項目 確認結果（記入例） 評価
統制要件とテストの対応 統制要件 42 件中 39 件に対応テストあり。3 件（マスタ変更承認ほか）は未実施 要是正
受入れテストの実施者 経理部の仕訳承認テストはベンダーが代行。経理部はテスト結果の閲覧のみ 要是正
残存不具合 重要度 A 0 件、B 5 件。B の 5 件は回避手順を定め、業務部長が受入れを承認 概ね適切
テスト環境のデータ 本番の個人データを加工せずに使用。アクセス者の範囲が未定義 要改善

データ移行と移行判定の監査

移行データの完全性・正確性

データ移行は、財務報告への影響が最も直接的な工程です。旧システムの残高や未決済取引が、漏れなく、正しく新システムに移ったかを確かめる必要があります。監査で確認する基本は、件数の一致（完全性）、金額・数量の合計の一致（正確性）、変換ルールの妥当性、そして照合を誰が行い誰が承認したか、の 4 点です。

旧データベースから新データベースへのデータ移行と照合を示す図
旧システムから移したデータを、件数と金額の両面で照合する流れを示しています。IT部門の変換作業とは別に、業務部門が残高を突き合わせて承認することが移行の信頼性を支えます。

照合はIT部門の変換ツールが出力する「成功件数」だけに頼らず、業務部門が旧システムの試算表や補助元帳と新システムの残高を突き合わせる形にします。移行作業中にデータを直接書き換える権限を持つ人が、自分で照合結果を承認していないかも確認します。移行は通常 1 回限りの作業であるため、作業ログと照合記録を調書に残せる形で保存してもらうことが重要です。

移行判定（Go/No-Go）の監査

移行判定は、稼働を決める会議体の判断です。監査の焦点は、判定そのものの是非ではなく、判定基準が事前に合意され、その基準に照らして判断されたかにあります。判定当日に基準を作ると、「稼働日を守る」ことが実質的な基準になりがちです。次のチェックリストを移行判定の 2〜4 週間前に当ててみてください。

  • 判定基準（テスト完了率、残存不具合の許容水準、移行リハーサル結果、体制準備）が文書化され、判定会議の前に承認されている
  • 移行リハーサルを本番相当のデータ量で実施し、所要時間と照合結果が記録されている
  • 切戻し（旧システムへの復帰）の判断基準、手順、判断期限が決まっている
  • 旧システムの停止後も、参照や再計算に必要な期間はデータを保全する計画がある
  • 稼働直後の問合せ・障害対応の体制（ハイパーケア）と連絡網が決まっている
  • 利用者の教育が計画どおり実施され、受講状況が把握されている
  • 本番稼働時の権限付与が、職務分掌表に基づく申請・承認を経ている
  • 判定会議の議事録に、基準ごとの充足状況と、未充足項目を受け入れた理由と責任者が残る

判定会議で基準を満たさない項目があっても、条件付きで稼働することはあり得ます。その場合、誰がどの条件で受け入れたかが記録されていれば、後に問題が起きても原因と責任を追えます。監査部は、判定者ではなく基準の充足状況について所見を述べる立場を保ちます。

稼働後の監査：暫定措置を「通常の統制」に戻す

ハイパーケア期間の確認点

稼働直後は、障害対応のために例外的な措置が取られます。IT部門への広い権限付与、データの直接修正、手作業での補正仕訳などです。これら自体はやむを得ない場合がありますが、期限と記録がないまま続くと、統制の抜け穴になります。稼働後の監査では、暫定権限の一覧と解除日、データ直接修正の申請・承認記録、補正仕訳の根拠と承認を確認します。

運用・変更管理への引継ぎ

プロジェクトが解散すると、システムは運用部門と保守の体制に引き継がれます。このとき、変更管理の手続、バックアップやジョブの監視、障害の記録方法が決まっていなければ、稼働後のIT全般統制が機能しません。引継ぎの完了は、プロジェクト監査の終点であると同時に、通常のITGC監査の起点でもあります。以後の確認は変更管理の監査手順とIT運用管理の監査で扱う領域になります。

J-SOX評価との調整

期中に財務報告に関連するシステムが切り替わる場合、評価範囲や評価時期への影響を、早めにJ-SOX事務局と監査法人に共有します。旧システムでの統制の運用期間、新システムでの運用実績の蓄積期間、移行そのものを統制として評価するかどうかなど、決めることは多くあります。最終的な判断は、自社と監査人との協議によります。

よくある失敗と対策

失敗1：進捗報告書だけで評価する

緑信号の報告書を読み、担当者に聞き取りをして終える監査です。進捗報告は作成者の見立てであり、証拠ではありません。報告の根拠となる課題一覧、不具合一覧、テスト結果を直接確認します。

失敗2：監査人が設計レビューの承認者になる

好意で設計書にコメントを重ねるうちに、「監査部の了承済み」と扱われる例です。コメントは所見として文書で渡し、承認欄には署名しません。

失敗3：統制要件を利用部門任せにする

利用部門は業務の効率を優先して要件を出すため、承認や照合の要件が抜けやすくなります。現行のRCMから統制を一覧化し、新システムでの実現方法を確認する手順を早い段階で入れます。

失敗4：データ移行の照合をIT部門の「成功件数」で済ませる

変換ツールの成功件数は、ツールが処理した件数に過ぎません。業務部門が会計残高と照合し、差異の原因を説明できることを確認します。

失敗5：稼働後に監査を閉じてしまう

稼働日を終点にすると、暫定権限やデータ直接修正の放置を見逃します。暫定措置の解消と運用への引継ぎを確認するまでを監査範囲に含めます。

よくある質問

Q1. 開発の専門知識がない内部監査部門でもプロジェクト監査はできますか？

できます。プロジェクト監査の多くは、承認・合意・照合の記録という「判断の根拠」を確かめる作業で、プログラムの中身を読む必要はありません。技術的な判断が必要な部分は、IT部門以外の専門家や外部の支援を部分的に使う方法もあります。

Q2. アジャイル開発でも同じ監査ができますか？

フェーズの名前は変わりますが、問いは同じです。バックログに統制要件が入っているか、各リリースの受入れを誰が判断したか、本番反映の手続が承認されているかを確認します。リリースの頻度が高い場合は、個々の変更ではなく、自動化されたパイプラインの承認や権限の設計を重点的に見ます。

Q3. パッケージやSaaSの導入でも監査は必要ですか？

必要です。プログラムを作らなくても、設定（パラメータ）、権限設計、データ移行、インタフェースは自社で決めます。実施基準も、パッケージ・ソフトウェアをそのまま利用するような比較的簡易なシステムの場合には、IT全般統制に重点を置く必要があることに留意するとしています。

Q4. 移行判定で「No-Go」を進言すべきと感じたら、どうすればよいですか？

監査部は判定者ではないため、「稼働すべきでない」と判断を代行するのではなく、「基準のこの項目が未充足で、このリスクがある」と事実とリスクを明確に伝えます。重大と考える場合は、監査規程に定めた報告経路に従い、経営者や取締役会・監査委員会等に速やかに報告します。

まとめ

システム開発・導入プロジェクトの監査は、完成品の検査ではなく、各フェーズで行われる判断が根拠を持っているかを確かめる活動です。実施基準が示す承認、導入前の試験と承認、データ移行時の対策、利用者教育を物差しに、統制要件の織り込み、要件とテストのつながり、データ移行の照合、移行判定基準の事前合意の 4 点に重点を置きます。監査部は判定者にならず、所見を述べる立場を守ることが、稼働後の監査の信頼性も支えます。

次の一歩として、進行中のプロジェクトがあれば、移行判定基準が文書化されているかを確認してみてください。関連記事としてITGCとSOC報告書の見方、変更管理の監査手順、システム監査基準・システム管理基準の要点もご覧ください。

プロジェクト監査の設計や監査プログラムの整備について支援が必要な場合は、お問い合わせからご相談ください。

参考資料

#ITGC#監査計画

関連記事

内部監査の情報サイトから、実務の基盤へ。

信頼できるナレッジと実務ツールで、内部監査の価値をさらに高めます。

資料請求 お問い合わせ