システム開発プロジェクトの監査について
AI生成の参考答案(架空)
問題・答案ともに独自教材です。実際のIPA過去問・公式解答ではありません。年度・季節は教材の整理用ラベルです。論述構成を学ぶために過去問AIが生成した架空の参考例で、合格を保証するものではありません。論述の骨格・業種事例の参考としてご活用ください。
問題概要
システム監査人は、組織のシステム開発プロジェクトが、事業目標・コスト・スケジュール・品質・リスクの観点で適切に統制されているかを評価することが求められる。
全文を表示
業種を選択してください
製造業の参考答案例
約 2,939 字序論(設問ア)
私が携わったシステム監査の対象は、中堅自動車部品メーカB社における製造実行管理(MES)刷新プロジェクトである。B社は年商約280億円、従業員数約1,000名、国内2工場・海外1工場を持ち、車載コネクタ・センサ部品の受託製造を主力とする。私はB社内部監査部所属のシステム監査人として、本監査の主任監査人を担った。 監査の対象プロジェクトは、20年運用してきたCOBOL基盤のMES を刷新する24か月のプロジェクトで、開発予算は約20億円、ピーク時のメンバ数は約60名(社内30名・外部委託30名)であった。プロジェクトの背景はIATF16949改訂版への対応、改正電子帳簿保存法対応、海外工場の追加対応の3つが同時進行する複合的な要請であった。 監査の背景は3点である。第1に、本プロジェクトの予算超過リスクが過去の同規模プロジェクトの実績から30%程度想定され、原価管理体制の妥当性確認が経営課題化した。第2に、製造物責任法(PL法)に基づくロットトレーサビリティ要件をプロジェクトが確実に満たすか、内部監査として独立検証する必要があった。第3に、IATF16949 改訂版の外部監査に先立ち、内部監査でプロジェクトの認証維持リスクを評価することが経営計画に明記された。 これらを踏まえ、本監査は経営監査計画の最重点項目に位置付けられた。
本論(設問イ)
私が実施したシステム開発プロジェクト監査の手続内容は、「リスクアセスメントに基づく重点監査項目の選定+計画・実行・受入段階の独立検証」を核とする構成である。具体的には、(1)プロジェクト計画の妥当性、(2)外部委託管理、(3)PL法対応のトレーサビリティ機能の品質、(4)IATF16949改訂版適合性、(5)コスト管理体制、の5つを重点監査項目として選定した。 計画上で重視した点は3つである。 第1に、「IATF16949改訂版・PL法に基づくリスクアセスメント」である。製造業のシステム開発監査は、業界要請(IATF16949)と法令要請(PL法)の両面からのリスク評価が必須となる。私は、(a)IATF16949の予防処置プロセスをプロジェクトの計画書とマッピングし、対応漏れを検出、(b)PL法のロットトレーサビリティ要件をプロジェクトの要件定義書と突合、(c)これらのリスクを「高・中・低」に分類し、高リスク領域に監査工数を集中、の3点でリスクアセスメントの精度を担保した。製造物責任法(PL法)・改正電子帳簿保存法・改正フロン排出抑制法・化学物質排出移動量届出制度(PRTR)の4法令への適合性を継続的に検証した。 第2に、「外部委託管理の独立検証」である。本プロジェクトは外部委託30名と社内30名が並行作業する構造で、外部委託の品質管理が IATF16949 認証維持に直結する。私は、外部委託管理を独立した重点監査項目とし、(1)外部委託先のセキュリティ管理状況の独立確認、(2)成果物の品質基準と検収プロセスの妥当性確認、(3)知的財産権の取扱いと機密保持の遵守状況確認、の3点を監査手続として整備した。 一つ目の困難は、プロジェクトメンバとの独立性の確保であった。社内のITサービスマネージャがプロジェクトのキーマンとなっており、資料入手そのものではなく、監査人が設計・承認に参加して自分の仕事を監査することが独立性上の懸念だった。私は、(a)監査権限に基づき原本・ログを直接入手し、PM経由の資料とも照合して証拠の選別を防止、(b)監査人とプロジェクトメンバの個別面談を二者以上の同席で実施、(c)監査調書の最終取りまとめを別部署の監査人がレビューする運用、の3点で独立性を担保した。システム監査基準・IIA国際監査基準への準拠を運用上の必須要件とした。 二つ目の困難は、改正電子帳簿保存法対応の検証範囲であった。本プロジェクトのスコープは MES 刷新だが、電子帳簿保存法対応の周辺機能(スキャナ保存・検索要件)がプロジェクト外で進行しており、相互の整合性確認が困難であった。私は、(1)電子帳簿保存法対応の周辺プロジェクトもサンプリング監査の対象に含める、(2)MES プロジェクトと周辺プロジェクトの整合性ギャップを内部監査特有の論点として整理、(3)税務調査リスクへの影響を経営層に直接報告する経路を整備、の3点で検証範囲を拡大した。 第3に、「監査調書の継続改善」である。監査計画段階で監査調書の標準テンプレートを整備し、各監査手続の結果を統一フォーマットで記録した。
結論(設問ウ)
策定した監査計画の実行に向けて、私は次の取組みを行った。 指摘・改善提言の取りまとめにあたり、リスクアセスメントで「高」と評価した重点監査項目のうち、5つの指摘事項を経営層へ報告した。具体的には、(1)外部委託先2社の機密保持運用に IATF16949 要請を満たさない点、(2)PL法対応のロットトレーサビリティ機能の単体テストで欠陥密度が業界平均比約1.8倍、(3)改正電子帳簿保存法対応の周辺プロジェクトとの整合性ギャップ、(4)コスト管理体制で外部委託工数の見える化が不十分、(5)IATF16949予防処置プロセスのプロジェクト計画書への反映漏れ3件、を指摘した。改善提言として、(a)外部委託管理の標準フレームワーク整備、(b)PL法対応機能の追加品質ゲート設置、(c)周辺プロジェクトとの統合管理体制構築、を提示した。 関係者との合意形成では、プロジェクト管理部・製造部・品質保証部・情報システム部の4部門との協議が課題となった。特にプロジェクト管理部からは「監査指摘事項の対応で当初計画のスケジュールが遅延する」との強い反対が表明された。私は、(1)指摘事項を「即時対応必須」「次回ゲート前対応」「次期プロジェクト対応」の3段階に分類、(2)即時対応必須事項のみに絞ってプロジェクトへ反映、(3)是正予算と実施責任は執行部門が経営承認を得て決定し、監査側は期限と証拠で追跡する運用、の3点を提示し利得構造を組み込んだ。約3か月の協議を経て、プロジェクト管理部は監査指摘の主体的対応部門となった。 評価点は、本監査で IATF16949 改訂版の外部監査リスクを事前に検出し、外部監査での重大指摘ゼロに貢献できた点である。さらに、PL法対応のロットトレーサビリティ機能の欠陥密度を改善提言後3か月で業界平均水準まで引き下げ、プロジェクト全体の品質を向上できた。改正電子帳簿保存法対応の整合性ギャップも事前に解消し、税務調査リスクをゼロに抑えた。 欠陥密度低下は試験が十分だった証拠と合わせて評価し、試験範囲が狭くなった結果でないことを確認した。税務を含む全リスクがゼロになったとは報告しない。 改善点は、改正電子帳簿保存法対応の周辺プロジェクトとの整合性確認に当初想定の1.5倍の工数を要した点である。これは、プロジェクトスコープ外の関連プロジェクトとの相互依存を計画時に十分に評価できていなかったことに起因する。今後は、システム開発監査の計画段階でプロジェクトスコープ外の関連プロジェクトを体系的に棚卸しし、整合性確認を計画時に予算化する仕組みを内蔵する必要がある。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
建設業の参考答案例
約 3,014 字序論(設問ア)
私が携わったシステム監査の対象は、中堅ゼネコンK社における工事原価管理システム刷新プロジェクトである。K社は売上高約3,300億円、従業員数約2,300名、年間施工件数約145件で、土木・建築両事業を持つ。私はK社内部監査部所属のシステム監査人として、本監査の主任監査人を担った。 監査の対象プロジェクトは、18年運用してきた基幹システムを刷新する36か月のプロジェクトで、開発予算は約26億円、ピーク時のメンバ数は約55名(社内30名・外部委託25名)であった。プロジェクトの背景は改正建設業法(働き方改革関連法の建設業適用)への対応、建設キャリアアップシステム(CCUS)連携、品確法の入札評価点向上の3つが同時進行する複合的な要請であった。 監査の背景は3点である。第1に、労働基準法の建設業への時間外労働上限適用日(2024年4月)が固定の外部期限として課されており、対応遅延の経営影響が重大で、進捗管理体制の妥当性確認が経営課題化した。第2に、本プロジェクトは開発委託者とは別に、業務データを提供する主要協力会社30社と専門工事会社約450社が間接的に関与する複雑な構造で、外部委託管理の独立検証が必要となった。第3に、建設業界全体に対するランサムウェア攻撃が増加しており、本プロジェクトのセキュリティ管理体制の妥当性検証が経営計画に明記された。
本論(設問イ)
私が実施したシステム開発プロジェクト監査の手続内容は、「期限駆動型のリスクアセスメント+多階層外部委託管理の独立検証」を核とする構成である。具体的には、(1)プロジェクト計画の妥当性(労働基準法の建設業への時間外労働上限適用日への対応)、(2)外部委託管理(業務連携先の主要協力会社30社と専門工事会社約450社)、(3)CCUS連携の品質、(4)セキュリティ管理体制、(5)コスト管理体制、の5つを重点監査項目として選定した。 計画上で重視した点は3つである。 第1に、「労働基準法の建設業への時間外労働上限適用日への対応リスクのアセスメント」である。施行日2024年4月は固定の外部期限で、対応遅延は罰則対象となる。私は、(a)施行日からの逆算スケジュールで「N-12か月」「N-6か月」「N-3か月」「N-1か月」のマイルストーンを設定し、各マイルストーンでの進捗状況を独立検証、(b)CCUS API 仕様変更時の改修対応の遅延リスクを継続評価、(c)品確法の入札評価点に影響する施工実績データ移行の品質を独立検証、の3点で期限駆動型のリスクアセスメントを確立した。建設業法・労働基準法・労働安全衛生法・品確法・建設リサイクル法の5法令への適合性を継続的に検証した。 第2に、「多階層外部委託管理の独立検証」である。本プロジェクトは主要協力会社30社と約450社の専門工事会社が業務連携する複雑な構造で、外部委託管理の盲点が生じやすい。私は、外部委託管理を独立した重点監査項目とし、(1)業務連携先30社のセキュリティ管理状況の独立確認、(2)サブコン連携APIの品質基準と運用状況の独立検証、(3)機密情報の流出リスクを「元請→サブコン」「サブコン間」の両軸で評価、の3点を監査手続として整備した。 一つ目の困難は、サブコン約450社の監査範囲の絞り込みであった。すべてのサブコンを監査対象とするのは現実的でなく、リスクベースの絞り込みが必要であった。私は、(a)サブコンを「リアルタイム連携先」「日次バッチ連携先」「ファイル交換のみ」の3クラスに分類、(b)リアルタイム連携先50社を必須監査対象、(c)残りはランダムサンプリングで5%を抽出して監査、の3点で監査範囲を効率化した。システム監査基準・IIA国際監査基準・IPA「中小企業の情報セキュリティ対策ガイドライン」への準拠を運用上の必須要件とした。 二つ目の困難は、改正個人情報保護法対応の検証であった。現場のウェアラブル端末からのバイタル収集データは個人情報に該当し、改正個人情報保護法の利用目的特定原則と就業規則との整合性を確認する必要があった。私は、(1)個人情報保護管理規程とプロジェクト要件定義書の突合、(2)バイタルデータの利用目的が就業規則に明示されているかの独立確認、(3)個人情報の保有期間・廃棄手順の独立検証、の3点で改正個人情報保護法対応を監査した。 第3に、「監査調書の継続改善」である。監査計画段階で監査調書の標準テンプレートを整備した。
結論(設問ウ)
策定した監査計画の実行に向けて、私は次の取組みを行った。 指摘・改善提言の取りまとめにあたり、リスクアセスメントで「高」と評価した重点監査項目のうち、6つの指摘事項を経営層へ報告した。具体的には、(1)労働基準法の建設業への時間外労働上限適用日への進捗が「N-6か月」マイルストーンで遅延、(2)CCUS API 仕様変更時の改修体制の不備、(3)サブコン50社中12社のセキュリティ管理が IPA ガイドライン水準未達、(4)現場ウェアラブル端末のバイタルデータの利用目的が一部就業規則に未反映、(5)ランサムウェア対策のオフラインバックアップが部分的に未整備、(6)コスト管理体制で外部委託工数の見える化が不十分、を指摘した。改善提言として、(a)期限駆動の進捗管理強化、(b)サブコン向けセキュリティ支援プログラム、(c)就業規則と要件定義書の継続的整合性確認、を提示した。 関係者との合意形成では、プロジェクト管理部・土木事業部・建築事業部・人事部・情報システム部の5部門との協議が課題となった。特に人事部からは「就業規則の改訂は労使協議が必要で、短期対応は困難」との強い反対が表明された。私は、(1)就業規則改訂を「即時対応必須」項目から「3か月以内対応」項目に移行、(2)対応中の暫定措置として個別同意書取得を運用、(3)是正予算と実施責任は執行部門が経営承認を得て決定し、監査側は期限と証拠で追跡する運用、の3点を提示し利得構造を組み込んだ。約3か月の協議を経て、人事部は監査指摘の主体的対応部門となった。 評価点は、本監査で労働基準法の建設業への時間外労働上限適用日への進捗遅延を事前検出し、対応強化により施行日への確実な対応に貢献できた点である。さらに、サブコン12社のセキュリティ強化を改善提言後6か月で完了し、業界全体のセキュリティ水準向上に貢献した。品確法に基づく入札評価点も「IT 整備状況」項目で前年比約15ptの向上を達成した。 改善点は、サブコン約450社のうちランダムサンプリングで抽出した監査対象に偏りが生じ、業種別・地域別のリスクの一部を見落とした点である。これは、サブコン構成の多様性を計画時に十分に評価できていなかったことに起因する。今後は、サブコンサンプリング設計を業種・地域・規模で層別化し、リスク見落としを抑制する仕組みを内蔵する必要がある。 この経験から私が得た本質的な学びは、建設業のシステム開発監査においては『サブコン構成の多様性』をサンプリング設計の独立変数として体系評価する必要があるとの確信である。私は今後、改正建設業法・建設キャリアアップシステム運用要領・労働安全衛生法・国土交通省BIM/CIM活用ガイドラインの継続遵守を担保しつつ、サブコンサンプリング設計の多層化(業種・地域・規模)を監査標準として堅持したい。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
金融業の参考答案例
約 2,755 字序論(設問ア)
私が携わったシステム監査の対象は、地方銀行L行における融資管理システム刷新プロジェクトである。L行は預金量約4.0兆円、従業員数約1,950名、本支店約150拠点を擁する地方銀行である。私はL行内部監査部所属のシステム監査人として、本監査の主任監査人を担った。 監査の対象プロジェクトは、22年運用してきた融資管理・担保管理・債務者管理を統合した基幹システムを刷新する36か月のプロジェクトで、開発予算は約48億円、ピーク時のメンバ数は約85名であった。プロジェクトの背景は金融庁監督指針の改訂(事業者の本業支援要請)、改正資金決済法対応、AML/CFTガイドライン強化の3つが同時進行する複合的な要請であった。 監査の背景は3点である。第1に、金融庁監督指針が「ITサービス継続管理態勢」を重点監査項目に位置付けたことを受け、本プロジェクトの可用性・継続性管理体制の独立検証が経営課題化した。第2に、FISC安全対策基準への準拠を確実にする内部監査が金融庁検査の前提条件となっていた。第3に、AML/CFT検知機能の改修が本プロジェクトに含まれ、検知精度の独立検証が必須となっていた。
本論(設問イ)
私が実施したシステム開発プロジェクト監査の手続内容は、「金融機関監督指針・FISC基準準拠の独立検証+AML/CFT検知精度の客観評価」を核とする構成である。具体的には、(1)プロジェクト計画の妥当性、(2)FISC安全対策基準への準拠状況、(3)AML/CFT検知精度の独立検証、(4)外部委託管理、(5)コスト管理体制、の5つを重点監査項目として選定した。 計画上で重視した点は3つである。 第1に、「金融庁監督指針・FISC安全対策基準への適合性」である。金融機関のシステム開発監査は、規制要請への適合性が最重要となる。私は、(a)金融庁監督指針の各項目をプロジェクトの WBS とマッピングし対応漏れを検出、(b)FISC安全対策基準の項目別に対応状況を独立検証、(c)これらのリスクを「高・中・低」に分類し、高リスク領域に監査工数を集中、の3点でリスクアセスメントの精度を担保した。銀行法・金融商品取引法・改正資金決済法・AML/CFTガイドライン・FISC安全対策基準の5規制への適合性を継続的に検証した。 第2に、「AML/CFT検知精度の独立検証」である。AML/CFT検知ロジックの精度は規制対応の中核で、内部監査としての独立検証が必須となった。私は、AML/CFT検知精度の独立検証を独立した重点監査項目とし、(1)過去2年から正常・異常の取引を層別抽出し、独立した担当者が根拠付きでラベルを確認して再実行し、本系の結果と突合、(2)異常取引を分母に見逃し率、正常取引を分母に誤検知率を求め、別系との一致だけを正解としない、(3)検知ロジックの改修履歴と検知精度変化の相関を独立評価、の3点を監査手続として整備した。 一つ目の困難は、内部監査人としての独立性確保であった。本プロジェクトは情報システム部主導で進行しており、私が開発判断へ関与すると自己監査になる懸念があった。資料の直接入手自体は独立性を損なわず、十分な証拠を得るために必要だった。私は、(a)原ログと承認履歴を監査権限で直接入手し、管理委員会の報告資料と照合する運用、(b)監査人と情報システム部メンバの個別面談を経営監査部の同席で実施、(c)監査調書の最終取りまとめを外部監査法人がレビュー、の3点で独立性を担保した。システム監査基準・IIA国際監査基準・金融庁の監督上の着眼点への準拠を運用上の必須要件とした。 二つ目の困難は、FISC安全対策基準の改訂対応の検証であった。FISC安全対策基準は監査期間中に改訂され、当初の監査計画と実際の準拠要件に乖離が生じる事象が発生した。私は、(1)FISC基準改訂内容を72時間以内に分析し、監査計画への影響を評価、(2)改訂後の基準項目を監査手続に追加、(3)外部監査法人と改訂対応について継続協議、の3点でFISC基準改訂への対応を整備した。 第3に、「監査調書の継続改善」である。監査計画段階で監査調書の標準テンプレートを整備した。
結論(設問ウ)
策定した監査計画の実行に向けて、私は次の取組みを行った。 指摘・改善提言の取りまとめにあたり、リスクアセスメントで「高」と評価した重点監査項目のうち、5つの指摘事項を経営層へ報告した。具体的には、(1)FISC安全対策基準の改訂項目への対応漏れ7件、(2)AML/CFT検知の誤検知率が業界平均比約12%高い、(3)外部委託先2社の機密保持管理が FISC 基準未達、(4)改正資金決済法対応のAPI連携範囲が運用解釈に未対応、(5)コスト管理体制で外部委託工数の見える化が不十分、を指摘した。改善提言として、(a)FISC基準改訂の継続モニタリング体制、(b)AML/CFT検知ロジックの精度改善プログラム、(c)外部委託先の FISC 準拠状況の年次評価制度、を提示した。 関係部門との合意形成では、営業統括部・リスク統括部・コンプライアンス部・情報システム部の4部門との協議が課題であった。特にコンプライアンス部からは「金融庁検査の前に内部監査指摘事項の全件対応は工数が過大」との強い反対が表明された。私は、(1)指摘事項を「即時対応必須(金融庁検査前)」「次回監査前対応」「中長期改善」の3段階に分類、(2)即時対応必須事項のみに絞って優先対応、(3)是正予算と実施責任は執行部門が経営承認を得て決定し、監査側は期限と証拠で追跡する運用、の3点を提示し利得構造を組み込んだ。約3か月の協議を経て、コンプライアンス部は監査指摘の主体的対応部門となった。 評価点は、本監査で FISC 基準改訂への対応漏れを事前検出し、金融庁検査・FISC外部監査でいずれも重大指摘ゼロに貢献できた点である。さらに、AML/CFT検知の誤検知率を改善提言後6か月で業界平均水準まで引き下げ、規制対応力を向上できた。 改善点は、FISC安全対策基準の改訂対応に当初想定の1.5倍の工数を要した点である。これは、FISC基準の改訂頻度を計画時に過小評価していたことに起因する。今後は、FISC基準改訂の影響を月次でモニタリングし、監査計画に継続反映する仕組みを内蔵する必要がある。 この経験から私が得た本質的な学びは、金融機関のシステム開発監査においては『FISC安全対策基準の改訂頻度』を監査前提の独立変数として継続評価する必要があるとの確信である。私は今後、銀行法・金商法・FISC安全対策基準・AML/CFTガイドラインの継続遵守を担保しつつ、FISC基準改訂の月次モニタリングを監査標準として堅持したい。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
流通・小売の参考答案例
約 2,763 字序論(設問ア)
私が携わったシステム監査の対象は、全国食品スーパーM社における基幹店舗システム刷新プロジェクトである。M社は年商約2,000億円、店舗数約200店、従業員数約6,300名(パート含む)を擁する地域密着型食品小売である。私はM社内部監査部所属のシステム監査人として、本監査の主任監査人を担った。 監査の対象プロジェクトは、19年運用してきたPOS・在庫管理・発注・本部マスタの4機能を統合した基幹店舗システムを刷新する30か月のプロジェクトで、開発予算は約32億円、ピーク時のメンバ数は約55名であった。プロジェクトの背景は改正食品衛生法のHACCP制度電子化、輸送能力の制約への対応、食品ロス削減推進法に基づく自治体への廃棄量公表の3つが同時進行する複合的な要請であった。 監査の背景は3点である。第1に、200店舗の段階移行の進捗管理体制の妥当性が経営課題化していた。第2に、衛生管理計画に従う確認・記録を移行中も続ける必要があり、移行品質の独立検証が必要となった。第3に、産直サプライヤ約280社との API 連携の品質管理が、輸送能力の制約への対応の中核となっていた。
本論(設問イ)
私が実施したシステム開発プロジェクト監査の手続内容は、「段階移行進捗管理+多階層外部委託管理の独立検証」を核とする構成である。具体的には、(1)プロジェクト計画の妥当性、(2)HACCP制度対応の品質、(3)200店舗段階移行の進捗管理、(4)外部委託管理(サプライヤ280社含む)、(5)コスト管理体制、の5つを重点監査項目として選定した。 計画上で重視した点は3つである。 第1に、「改正食品衛生法のHACCP制度対応の独立検証」である。衛生管理計画で定める確認・記録を紙による代替も含めて続ける必要があり、移行品質の独立検証が必須となった。私は、(a)HACCP電子記録機能のテストケースとカバレッジを独立検証、(b)パイロット店舗での実証データを別系統で再実行し連続性を確認、(c)保健所監査を想定した第三者検証を必須化する、の3点でHACCP連続性を独立評価した。改正食品衛生法・食品ロス削減推進法・食品表示法・改正物流効率化法の4法令への適合性を継続的に検証した。 第2に、「200店舗段階移行の進捗管理の独立検証」である。段階移行は3段階(5店舗→30店舗→50店舗ずつ全店)で計画されており、各段階での進捗・品質管理体制が経営課題となった。私は、(1)各段階の Go/No-Go 判定基準を独立検証、(2)パイロット店舗での障害発生時の対応体制を独立評価、(3)新旧両系統の本部マスタ整合性を独立確認、の3点を監査手続として整備した。 一つ目の困難は、200店舗の段階移行進捗の同時的な独立検証であった。すべての店舗を監査対象とするのは現実的でなく、サンプリング設計が課題となった。私は、(a)店舗を「都市部」「郊外」「地方」の3グループに層別化、(b)各グループから20%の店舗を抽出して必須監査対象、(c)残り店舗はリスクベースで抽出して追加監査、の3点で監査範囲を効率化した。システム監査基準・IIA国際監査基準・IPA「中小企業の情報セキュリティ対策ガイドライン」への準拠を運用上の必須要件とした。 二つ目の困難は、産直サプライヤ約280社の API 連携品質の独立検証であった。サプライヤ側のシステム成熟度が大きく異なり、連携品質の客観評価が困難であった。私は、(1)サプライヤを「リアルタイム連携」「日次バッチ」「ファイル交換」の3クラスに分類、(2)各クラスから取引件数と機密情報量を基にリスクの高い10社を必須監査対象、(3)連携API応答時間・データ精度・継続性を独立検証、の3点でサプライヤ連携品質を客観評価した。 第3に、「監査調書の継続改善」である。監査計画段階で監査調書の標準テンプレートを整備した。
結論(設問ウ)
策定した監査計画の実行に向けて、私は次の取組みを行った。 指摘・改善提言の取りまとめにあたり、リスクアセスメントで「高」と評価した重点監査項目のうち、5つの指摘事項を経営層へ報告した。具体的には、(1)パイロット5店舗でのHACCP記録の整合性検証が一部不足、(2)段階移行のGo/No-Go判定基準が文書化されていない、(3)産直サプライヤ12社の連携品質が業界水準未達、(4)新旧本部マスタの整合性監視ジョブの設計不備、(5)コスト管理体制で外部委託工数の見える化が不十分、を指摘した。改善提言として、(a)HACCP記録の連続性検証プロセスの標準化、(b)段階移行のGo/No-Go判定基準の文書化、(c)サプライヤ連携品質の年次評価制度、を提示した。 関係部門との合意形成では、プロジェクト管理部・店舗運営部・商品部・サプライチェーン部・情報システム部の5部門との協議が課題となった。特にサプライチェーン部からは「サプライヤ12社の品質強化対応はサプライヤ側コストが過大」との強い反対が表明された。私は、(1)サプライヤ側の品質強化に対する技術支援プログラムをM社主導で運営、(2)対応コストの一部を M社のサプライチェーン部予算で補填、(3)新システムの物流効率化効果の一部をサプライチェーン部のKPIに加算する配賦ルール、の3点を提示し利得構造を組み込んだ。約3か月の協議を経て、サプライチェーン部は監査指摘の主体的対応部門となった。 評価点は、本監査でHACCP連続性の課題を事前検出し、移行期間中の保健所監査・税務調査でいずれも重大指摘ゼロに貢献できた点である。さらに、段階移行のGo/No-Go判定基準の文書化により、各段階の意思決定品質が向上し、200店舗の段階移行を計画通り30か月で完了できた。 Go/NoGoの記載だけでなく、判断に使った試験結果と未解決欠陥の承認を確認した。改善策の運営と費用配分は執行部門が決め、私は是正後の証拠を追跡した。 改善点は、産直サプライヤ12社の品質強化対応プロセスの設計に当初想定の1.6倍の工数を要した点である。これは、サプライヤエコシステムの技術成熟度の多様性を計画時に十分に評価できていなかったことに起因する。今後は、サプライヤ向けの品質支援プログラムを業界団体と協働で運営し、対応工数を継続的に効率化する仕組みを内蔵する必要がある。 この経験から私が得た本質的な学びは、流通業のシステム開発監査においては『サプライヤエコシステムの技術成熟度の多様性』を計画前提の独立変数として体系評価する必要があるとの確信である。私は今後、改正食品衛生法HACCP・食品表示法・食品ロス削減推進法・改正物流効率化法の継続遵守を担保しつつ、業界団体との協働サプライヤ品質支援を監査標準として堅持したい。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
通信業の参考答案例
約 2,880 字序論(設問ア)
私が携わったシステム監査の対象は、地域通信キャリアN社における顧客管理(CRM)・課金システム刷新プロジェクトである。N社は売上高約2,500億円、従業員数約3,100名、ISP契約数約140万、モバイル契約数約180万を擁する地域通信事業者である。私はN社内部監査部所属のシステム監査人として、本監査の主任監査人を担った。 監査の対象プロジェクトは、16年運用してきたCRM・課金・故障受付の3機能を統合した基幹システムを刷新する28か月のプロジェクトで、開発予算は約55億円、ピーク時のメンバ数は約90名であった。プロジェクトの背景は改正電気通信事業法の「外部送信規律」対応、PSTN廃止に伴うIPフォン移行(2027年まで)、5G・MEC等の新サービス追加対応の3つが同時進行する複合的な要請であった。 監査の背景は3点である。第1に、改正電気通信事業法の外部送信規律は施行日が固定の外部期限として課されており、対応遅延の経営影響が重大であった。第2に、モバイル・ISPの計320万契約すべての通信情報の機密性が電気通信事業法・通信の秘密で守られる必要があり、本プロジェクトのセキュリティ管理体制の独立検証が必要となった。第3に、NIS2指令(欧州重要インフラ規制)に準じたサイバー耐性の高度化が新たな経営課題となっていた。
本論(設問イ)
私が実施したシステム開発プロジェクト監査の手続内容は、「規制対応期限駆動型のリスクアセスメント+通信の秘密保護の独立検証」を核とする構成である。具体的には、(1)プロジェクト計画の妥当性、(2)改正電気通信事業法の外部送信規律対応、(3)通信の秘密保護体制、(4)NIS2指令準拠のサイバー耐性、(5)コスト管理体制、の5つを重点監査項目として選定した。 計画上で重視した点は3つである。 第1に、「改正電気通信事業法・電波法対応のリスクアセスメント」である。改正電気通信事業法の外部送信規律は施行日が固定の外部期限で、対応遅延は規制違反となる。私は、(a)施行日からの逆算で「N-6か月」「N-3か月」「N-1か月」のマイルストーンを設定し進捗状況を独立検証、(b)顧客同意管理機能の品質を独立評価、(c)同意取り消し請求処理の24時間以内対応体制を独立確認、の3点で期限駆動型のリスクアセスメントを確立した。電気通信事業法(外部送信規律を含む)・電波法の適用要件への対応を継続的に検証した。 第2に、「通信の秘密保護体制の独立検証」である。本プロジェクトは顧客の通信メタデータを取り扱うため、通信の秘密保護が法令上の中核要件となる。私は、通信の秘密保護を独立した重点監査項目とし、(1)通信メタデータへのアクセス権限を最小権限の原則で設計しているかの独立確認、(2)アクセスログの保存目的・期間・権限と検査時の根拠確認可能性の独立評価、(3)通信内容と通信メタデータの分離設計の独立検証、の3点を監査手続として整備した。 一つ目の困難は、モバイル・ISPの計320万契約の同意取得プロセスの監査範囲であった。すべての契約者を監査対象とするのは現実的でなく、サンプリング設計が課題となった。私は、(a)契約者を今回対象の「モバイル」「ISP」の2サービス別に層別化、(b)各サービスから1,000契約者をランダムサンプリングし、同意取得の有効性を独立確認、(c)同意取り消し請求の処理時間を全件監査、の3点で監査範囲を効率化した。システム監査基準・IIA国際監査基準・経済産業省サイバーセキュリティ経営ガイドラインへの準拠を運用上の必須要件とした。 二つ目の困難は、NIS2指令準拠の評価方法であった。NIS2指令はEU法令でありN社は直接適用対象ではないが、業界の標準として位置付けられている。評価基準の客観性確保が課題となった。私は、(1)NIS2指令の各要請を IPA ガイドライン・経済産業省ガイドラインとマッピング、(2)業界標準としての位置付けを明示した上で評価基準を整理、(3)外部監査法人のレビューを必須化する運用、の3点で評価の客観性を担保した。IoTセキュリティガイドラインへの整合性も同フレームで管理した。 第3に、「監査調書の継続改善」である。監査計画段階で監査調書の標準テンプレートを整備した。
結論(設問ウ)
策定した監査計画の実行に向けて、私は次の取組みを行った。 指摘・改善提言の取りまとめにあたり、リスクアセスメントで「高」と評価した重点監査項目のうち、5つの指摘事項を経営層へ報告した。具体的には、(1)外部送信規律対応の進捗が「N-3か月」マイルストーンで遅延、(2)社内の24時間処理基準を超えた同意取消しがあり、(3)通信メタデータへのアクセス権限の一部が最小権限原則未準拠、(4)NIS2指令準拠のサイバー攻撃通知プロトコルの未整備、(5)コスト管理体制で外部委託工数の見える化が不十分、を指摘した。改善提言として、(a)期限駆動の進捗管理強化、(b)同意取り消し処理の自動化、(c)アクセス権限の継続的見直し制度、を提示した。 関係部門との合意形成では、コンシューマ事業本部・法人事業本部・運用本部・情報システム本部の4本部との協議が課題であった。特に運用本部からは「アクセス権限の継続的見直しは運用負荷を増大させる」との強い反対が表明された。私は、(1)アクセス権限見直しを四半期1回の自動化プロセスとして整備、(2)見直し工数を情報システム本部予算で全額補填、(3)新システムの規制対応効果の一部を運用本部のKPIに加算する配賦ルール、の3点を提示し利得構造を組み込んだ。約3か月の協議を経て、運用本部は監査指摘の主体的対応部門となった。 評価点は、本監査で改正電気通信事業法施行日への進捗遅延を事前検出し、対応強化により施行日への確実な対応に貢献できた点である。さらに、同意取り消し処理の自動化により、運用開始3か月で全件24時間以内処理を達成できた。総務省検査でいずれも重大指摘ゼロに貢献した。 権限見直しの設計・予算は執行部門が承認する改善計画とし、監査側は実施しない。固定電話は別対象とし、同意だけが外部送信規律の対応手段とは扱わなかった。 改善点は、NIS2指令準拠の評価基準の客観性確保に当初想定の1.4倍の工数を要した点である。これは、欧州法令を業界標準として評価する手法の確立が計画時には未整備であったことに起因する。今後は、NIS2指令を含む海外規制の影響評価フレームを社内標準として整備し、評価の客観性と効率性を両立させる仕組みを内蔵する必要がある。 この経験から私が得た本質的な学びは、通信業のシステム開発監査においては『欧州法令(NIS2指令)の業界標準化評価手法』を監査前提の独立変数として体系整備する必要があるとの確信である。私は今後、電気通信事業法・電波法・通信の秘密保護・改正電気通信事業法(外部送信規律)の継続遵守を担保しつつ、海外規制影響評価フレームの社内標準整備を監査標準として堅持したい。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
公共・自治体の参考答案例
約 2,903 字序論(設問ア)
私が携わったシステム監査の対象は、人口約80万人を擁するW県における住民記録・税務システム刷新プロジェクトである。W県は職員数約3,700名、年間予算規模約6,500億円の県で、県庁所在地に中核市1市を含む。私はW県監査委員会事務局所属のシステム監査人として、本監査の主任監査人を担った。 監査の対象プロジェクトは、18年運用してきた基幹システムを刷新し、ガバメントクラウド準拠の標準準拠システムへ移行する36か月のプロジェクトで、予算は約85億円、ピーク時のメンバ数は約100名(県職員30名・市町村職員30名・外部委託40名)であった。プロジェクトの背景は地方公共団体情報システム標準化に関する法律の対応期限(2025年度末)、改正個人情報保護法対応、ガバメントクラウドへの移行の3つが同時進行する複合的な要請であった。 監査の背景は3点である。第1に、原則の移行目標に対する計画管理が必要で、対応遅延は重大な政治・行政リスクとなる構造があった。第2に、本プロジェクトは県内40市町村との共同利用基盤の構築を含み、複雑な多者間プロジェクトの進捗管理体制の独立検証が必要となった。第3に、改正個人情報保護法および官民データ活用推進基本法に基づく住民データ保護要請への適合性を独立検証する必要があった。
本論(設問イ)
私が実施したシステム開発プロジェクト監査の手続内容は、「期限駆動型のリスクアセスメント+多者間プロジェクトの独立検証」を核とする構成である。具体的には、(1)プロジェクト計画の妥当性(標準化期限への対応)、(2)ガバメントクラウド準拠の品質、(3)市町村共同利用の進捗管理、(4)住民データ保護体制、(5)コスト管理体制、の5つを重点監査項目として選定した。 計画上で重視した点は3つである。 第1に、「地方公共団体情報システム標準化に関する法律の期限への対応リスクアセスメント」である。原則2025年度末の移行目標に向けて個別計画の管理が必要で、対応遅延は重大な政治リスクとなる。私は、(a)期限からの逆算で「N-12か月」「N-6か月」「N-3か月」のマイルストーンを設定し進捗状況を独立検証、(b)ガバメントクラウドの標準仕様変更時の改修対応の遅延リスクを継続評価、(c)市町村側の対応状況を独立確認、の3点で期限駆動型のリスクアセスメントを確立した。デジタル社会形成基本法・地方公共団体情報システム標準化に関する法律・改正個人情報保護法・官民データ活用推進基本法の4法令への適合性を継続的に検証した。 第2に、「住民データ保護体制の独立検証」である。改正個人情報保護法および官民データ活用推進基本法に基づく住民データ保護は、自治体システム監査の中核となる。私は、住民データ保護体制を独立した重点監査項目とし、(1)住民データへのアクセス権限の最小権限原則の独立確認、(2)業務単位でのアクセス制御の独立評価、(3)法令上の根拠・利用目的・提供先・同意を用いる場合の取得記録を個別に照合、の3点を監査手続として整備した。 一つ目の困難は、県内40市町村の進捗・対応状況の同時的な独立検証であった。すべての市町村を監査対象とするのは現実的でなく、サンプリング設計が課題となった。私は、(a)市町村を「人口規模」「財政力指数」「IT 体制成熟度」の3軸で層別化、(b)各層別から30%を抽出して必須監査対象、(c)残り市町村はリスクベースで5%を抽出して追加監査、の3点で監査範囲を効率化した。システム監査基準・総務省「地方公共団体における内部統制制度の導入・実施ガイドライン」・地方自治法に基づく内部統制制度への準拠を運用上の必須要件とした。 二つ目の困難は、ガバメントクラウドの標準仕様変更への対応の独立検証であった。標準仕様書は監査期間中に複数回改定され、当初の監査計画と実際の準拠要件に乖離が生じる事象が発生した。私は、(1)標準仕様変更内容を72時間以内に分析し監査計画への影響を評価、(2)変更後の仕様項目を監査手続に追加、(3)デジタル庁との改訂対応について継続協議、の3点で標準仕様変更への対応を整備した。 第3に、「監査調書の継続改善」である。監査計画段階で監査調書の標準テンプレートを整備した。
結論(設問ウ)
策定した監査計画の実行に向けて、私は次の取組みを行った。 指摘・改善提言の取りまとめにあたり、リスクアセスメントで「高」と評価した重点監査項目のうち、6つの指摘事項を県議会・経営層へ報告した。具体的には、(1)標準化期限への進捗が「N-6か月」マイルストーンで遅延、(2)ガバメントクラウド標準仕様変更への対応漏れ5件、(3)市町村のうち8団体で進捗遅延、(4)住民データの業務単位アクセス制御の設計不備、(5)官民データ活用の住民同意プロセスの一部未整備、(6)コスト管理体制で外部委託工数の見える化が不十分、を指摘した。改善提言として、(a)期限駆動の進捗管理強化、(b)ガバメントクラウド標準仕様変更の継続モニタリング体制、(c)市町村別の進捗支援プログラム、を提示した。 関係主体との合意形成では、住民課・税務課・健康福祉部・情報システム部、および県内市町村との協議が課題であった。特に大規模市からは「県主導の監査指摘事項の市町村への押し付けは地方自治の本旨に反する」との強い反対が表明された。私は、(1)市町村への指摘事項を「県全体に関わる事項」と「市町村独自の事項」に分離し、後者は市町村側で自主判断、(2)県は技術支援・情報提供に徹する役割、(3)市町村への支援プログラムを県予算で運営し、市町村側のコスト負担を回避、の3点を提示し利得構造を組み込んだ。約4か月の協議を経て、県内市町村は監査指摘の主体的対応主体となった。 評価点は、本監査で標準化期限への進捗遅延を事前検出し、対応強化により期限(2025年度末)への確実な対応に貢献できた点である。さらに、ガバメントクラウド標準仕様変更への対応漏れを事前解消し、デジタル庁検査でいずれも重大指摘ゼロに貢献した。 県は調整者、市町村が住民記録の実施主体である。既存3軸の層別に、遅延履歴と外部委託依存度を加えて標本を再選定した。各証拠は対象期間・抽出数・原本所在を調書に残す。 改善点は、市町村別の進捗状況の独立検証に当初想定の1.5倍の工数を要した点である。これは、市町村構成の多様性を計画時に十分に評価できていなかったことに起因する。今後は、市町村サンプリング設計を人口規模・財政力・IT成熟度で多層化し、独立検証の効率と網羅性を両立させる仕組みを内蔵する必要がある。 この経験から私が得た本質的な学びは、自治体DXのシステム開発監査においては『市町村構成の多様性』をサンプリング設計の独立変数として体系評価する必要があるとの確信である。私は今後、デジタル社会形成基本法・地方公共団体情報システム標準化法・改正個人情報保護法・行政手続法の継続遵守を担保しつつ、市町村サンプリング設計の多層化(人口規模・財政力・IT成熟度)を監査標準として堅持したい。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
IT・情報サービス業の参考答案例
約 2,349 字序論(設問ア)
私が担当したのは、独立系SaaSベンダBB社における基幹SaaSプラットフォーム全面再構築プロジェクトに対するシステム監査である。BB社は売上高約240億円、従業員数約1,200名で、中堅企業向け統合業務SaaSを国内約4,800社に提供している。BB社はISMS認証(ISO27001)およびプライバシーマークを継続維持し、個人情報保護法に基づく内部統制を整備している。私はBB社内部監査部のシニアシステム監査人として、2022年から本監査を統括した。 監査対象プロジェクトは、(1)既存モノリシックSaaSをハイパースケーラ前提のクラウドネイティブ基盤へ全面再構築、(2)契約継続中の4,800社への業務影響をゼロに抑制、(3)ISMAP(政府情報システムのためのセキュリティ評価制度)準拠による中央省庁向け参入要件の確保、(4)改正電気通信事業法の外部送信規律対応、の4要件を24か月・予算42億円で達成する計画であった。 監査の主要観点は、(1)プロジェクト計画の妥当性(4,800社の段階移行計画の論理的整合性)、(2)プロジェクト統制の有効性(プロジェクトマネージャ・チーフアーキテクトのガバナンス体制)、(3)リスク管理の網羅性(SLA99.95%維持・解約率維持・ISMAP登録完遂の3指標のリスク管理)、(4)コンプライアンス対応(ISMAPを参考に適用性を整理した社内チェックリスト1,300項目・外部送信規律対応の進捗)の4点であった。これら多面的な観点に対し、システム監査基準・システム管理基準に基づく独立検証を実施した。
本論(設問イ)
私が策定した監査計画は、「監査観点別×リスク強度×サンプリング設計」のマトリクスを核とする設計である。具体的には、(1)プロジェクト計画妥当性は段階移行計画の論理的整合性に対するレビュー、(2)プロジェクト統制有効性は経営会議議事録・週次進捗会議議事録の分析、(3)リスク管理網羅性はリスク登録簿の継続更新状況のレビュー、(4)コンプライアンス対応はISMAPを参考に適用性を整理した社内チェックリスト1,300項目の対応状況の独立検証、の4観点を継続評価する仕組みを設計した。 策定で重視した点は3つである。 第1に、「ISMAP管理基準の独立検証」である。ISMAP準拠は中央省庁向け参入要件であり、ISMAPを参考に適用性を整理した社内チェックリスト1,300項目の対応状況の独立検証を監査計画の中核に位置付けた。具体的には、監査作業上の独自分類としてチェックリストを「ガバナンス」「リスクマネジメント」「マネジメント基盤」「情報セキュリティ管理基準」「クラウド情報セキュリティ管理基準」の5カテゴリに整理し、各カテゴリの監査チェックリストをシステム監査基準に基づき策定した。これにより、ISMAP登録完遂への進捗を客観的に評価する構造を担保した。 第2に、「4,800社の顧客影響評価」である。SaaS再構築の失敗は顧客解約リスクに直結するため、業務影響度の独立検証を監査計画に組み込んだ。具体的には、業務影響度上位500社のうちサンプリング50社の顧客側システム部門責任者へヒアリングを実施し、SaaS再構築への懸念・期待・準備状況を独立収集した。これにより、プロジェクト側の顧客影響評価の妥当性を独立検証する経路を確保した。さらに、顧客解約率の継続モニタリングについてもサンプリング独立検証を実施し、プロジェクト側の数値の妥当性を担保した。 第3に、「ハイパースケーラ依存リスクの統制評価」である。プロジェクトはハイパースケーラ複数社への分散配置を前提としているが、ハイパースケーラ側の仕様変更速度がプロジェクト計画の前提条件となるため、ハイパースケーラ依存リスクの統制有効性を独立検証した。具体的には、ハイパースケーラ複数社のロードマップ更新状況とプロジェクト計画への反映状況を四半期ごとに評価し、計画前提と実態の乖離を継続検出する仕組みを設計した。これにより、プロジェクト後期での計画前提崩壊リスクを早期検出する構造を担保した。
結論(設問ウ)
監査では、指摘の件数だけでなく、統制基準・入手証拠・影響・改善責任者を対応付けて報告した。顧客移行の承認記録には、性能試験が未完了でも切替可とした記録があり、可用性の契約に反するリスクを指摘した。また、権限棚卸しの台帳と実アカウントが一致せず、退職者の管理権限が残る例を確認した。外部送信の調査票には、実際のブラウザで発生する送信先が未記載であり、説明内容との乖離があった。 私は、移行ゲートで未完了試験と承認者の判断を明示し、重大な未解決事項がある波は延期することを提言した。権限は人事台帳との定期突合、削除期限、例外の承認を定める。外部送信は実通信を採取して調査票と比較し、対象情報・送信先・目的と対応方式を法務が確認するよう求めた。是正の設計や運用を私自身が担当することは避けた。 開発部は日程への影響を懸念した。私は重要な指摘を切替前、軽微な事項を期限付きの後続対応に分ける案を示した。リスク受容は事業責任者と経営層が決定し、監査はその根拠を記録することで合意した。修正後は試験報告書、削除ログ、送信一覧の差分を取得して再検証し、文書の提出だけで完了とは扱わなかった。 四半期100項目の抽出を8回行っても、重複がなければ最大800項目であり、1,300項目全てを検査したとは報告できない。監査台帳には読んだ証拠と未検査範囲を残し、高リスク統制を優先した理由を説明した。結果は重大・軽微・観察事項に分けて経営層へ直接報告した。今後は標本の重複と未検査領域を四半期ごとに見直し、監査の範囲を過大に表現しない運用を続ける。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
医療・ヘルスケアの参考答案例
約 2,317 字序論(設問ア)
私が担当したのは、500床規模の地域基幹病院T病院における電子カルテ刷新プロジェクトに対するシステム監査である。T病院は病床数約500床、医師数約180名、看護師数約540名、職員数約820名を擁し、年間外来約42万人・入院延べ約18万人を取り扱う急性期病院で、地域医療支援病院の認定を受けている。私はT病院内部監査室のシニアシステム監査人として、2022年から本監査を統括した。 監査対象プロジェクトは、(1)既存電子カルテ(導入から13年・サポート期限終了)を次期電子カルテへ全面刷新、(2)月次ダウンタイム上限30分以内・診療記録移管完全性100%、(3)医療情報システムの安全管理に関するガイドライン第6.0版完全準拠、(4)医療DX令和ビジョン2030に対応するHL7 FHIR標準API基盤の実装、の4要件を18か月・予算28億円で達成する計画であった。 監査の主要観点は、(1)プロジェクト計画の妥当性(診療科別・記録種別の段階刷新計画の論理的整合性)、(2)プロジェクト統制の有効性(事務職を含む全職員820名・地域連携医療機関340施設・電子カルテベンダのガバナンス体制)、(3)リスク管理の網羅性(月次ダウンタイム上限・診療記録完全性・医療情報セキュリティの3指標のリスク管理)、(4)コンプライアンス対応(医療情報システム安全管理ガイドライン第6.0版・3省2ガイドラインの進捗)の4点であった。これらの観点に対し、システム監査基準・医療情報システムの安全管理に関するガイドラインに基づく独立検証を実施した。
本論(設問イ)
私が策定した監査計画は、「監査観点別×医療事故リスク強度×サンプリング設計」のマトリクスを核とする設計である。具体的には、(1)プロジェクト計画妥当性は段階刷新計画と診療継続性との整合性に対するレビュー、(2)プロジェクト統制有効性は事務職を含む全職員820名・地域連携医療機関340施設との合意形成プロセスのレビュー、(3)リスク管理網羅性は診療事故リスクへのリスク管理状況のレビュー、(4)コンプライアンス対応は医療情報システム安全管理ガイドライン第6.0版の対応状況の独立検証、の4観点を継続評価する仕組みを設計した。 策定で重視した点は3つある。 第1に、「医療情報セキュリティの独立検証」である。医療情報システムの安全管理に関するガイドライン第6.0版および3省2ガイドラインの完全準拠は、医療法・個人情報保護法に基づく法令要件であり、独立検証を監査計画の中核に位置付けた。具体的には、ガイドラインの「企画管理」「事業者管理」「システム運用管理」「物的・人的安全管理」「技術的安全管理」の5カテゴリに整理し、各カテゴリの監査チェックリストを医療情報システムの安全管理に関するガイドラインに基づき策定した。これにより、医療情報セキュリティへの対応漏れを客観的に評価する構造を担保した。 第2に、「診療継続性の独立検証」である。電子カルテ刷新の失敗は医療事故リスクに直結するため、診療継続性の独立検証を監査計画に組み込んだ。具体的には、月次ダウンタイム上限30分以内の遵守状況を毎月独立検証し、診療科ごとの代替手順(紙運用)の準備状況をサンプリング独立検証した。さらに、診療部・看護部・薬剤部・検査部の事務職を含む全職員820名のうちサンプリング50名へのヒアリングを四半期実施し、プロジェクト側の合意形成評価との乖離を継続検出する仕組みを構築した。 第3に、「地域連携医療機関との連携監査」である。医療DX令和ビジョン2030対応のHL7 FHIR標準API基盤は地域連携医療機関約340施設との連携を前提としているため、連携状況の独立検証を監査計画に組み込んだ。具体的には、地域連携医療機関340施設のうちサンプリング30施設へのヒアリングを四半期実施し、プロジェクト側の地域連携評価との乖離を継続検出する仕組みを設計した。これにより、地域連携医療機関との合意形成プロセスの妥当性を独立検証する経路を確保した。
結論(設問ウ)
監査結果では、移行した診療記録の件数だけを確認し、本文や添付検査結果の不一致を確認していないことを指摘した。完全性100%というプロジェクト報告は証拠が足りなかった。また、紙への切替訓練は医師中心で、夜勤の看護師や薬剤師へ手順が届いた記録が不足していた。委託先の緊急保守権限には、利用後の失効確認がないものがあった。 私は、元記録ID・患者ID・日時・内容ハッシュ・添付ファイルを新旧で全件突合し、変換が必要な項目は承認済み対応表で検証することを提言した。単純な件数一致だけを完全性の根拠としない。紙運用は職種・勤務帯ごとに訓練し、処方の重複や転記漏れを防ぐ照合手順を加える。保守権限は期限付き発行と利用記録、終了時の無効化確認を求めた。 診療部は訓練のために業務を止められないと反対した。私は全職員同時ではなく、勤務帯別の小規模訓練を積み重ね、未参加者には補講を設ける案を提示した。実施と予算は病院執行部が決め、監査は参加記録と実演結果を確認することで合意した。ベンダには突合処理の結果と例外一覧を提出させ、私が選んだ標本を再実行して一致を確認した。 全件突合が終わるまでは完全性100%を承認せず、不一致の原因と解消証拠を台帳で追跡した。理事会には重大な指摘と残余リスク、期限、責任者を報告し、未解決のまま切替えるかの判断は理事会に委ねた。改善点は、ガイドラインの医療機関向け要件と事業者向け要件を一括で扱っていたことである。適用対象と改訂時点を整理し、共同で担う統制の証拠を双方から取る監査へ改めた。
試験制度・公式過去問の確認: IPA 情報処理技術者試験