システム監査技術者 2021年 午後1 問02
システム再構築プロジェクトの企画段階の監査に関する次の記述を読んで、設問1~4に答えよ。
B社は、中堅の保険会社である。B社の情報システムは、構築時から長い間利用して老朽化しているシステムが多いので、3年ほど前から順次再構築を実施し、基幹系システムの再構築がほぼ終了した。次に、周辺システムのうち、ハードウェアのサポート切れが近づいている営業支援システムを再構築することになり、新たに“営業支援システムの再構築プロジェクト”(以下、当プロジェクトという)を立ち上げ、プロジェクト計画書(以下、計画書という)を作成したところである。B社の営業支援システムは、モバイルPCの活用を進めた十数年前に構築され、新商品への対応や利便性の向上のために、何度も改修が行われてきた。
これまで、B社の再構築プロジェクトでは、開発期間の長期化や予算の超過などの事例が幾つか発生している。そこで、監査部では、当プロジェクトを監査対象として、再構築計画の適切性についてシステム監査を実施することにした。
〔当プロジェクトの体制〕
当プロジェクトは、システム部で営業支援システムの保守を担当しているT課長がプロジェクトマネージャ(以下、PMという)を務めており、システム部のメンバ3名を含めたシステム化検討チームが計画書をまとめている。また、利用部門の代表である営業統括部のS課長とメンバ2名が、業務チームとして業務要求の取りまとめを行っている。
当プロジェクトは、毎月、PMが検討の状況をプロジェクト運営委員会に報告している。プロジェクト運営委員会は、営業担当役員、システム担当役員、営業統括部長、システム部長及びシステム企画課長で構成されている。
〔再構築計画の検討状況〕
B社では、これまでの基幹系システムの再構築で実施された手順を整理した“再構築実施要領”が作成されている。当プロジェクトは、この“再構築実施要領”に従い、次のように営業支援システムの再構築計画について検討を進めた。
(1) 現行システムの調査・分析
システム化検討チームは、現行の営業支援システムの基本設計書を基に機能一覧を整理した。
(2) 新システムの業務要求の洗い出し、優先順位付け
業務チームは、主な営業店や本社部門の各部にヒアリングを行い、再構築する営業支援システムの業務要求を“業務要求一覧”としてまとめた。利用部門の担当者からは、現行システムに大きな不満はなく、業務を大きく変えるようなシステム機能の変更は避けてほしいという意見が多かった。
(3) 再構築方式の検討
“再構築実施要領”には、標準的に定めた3方式の中から評価項目を定めて評価した上で、最適な方式を選択することが定められている。再構築方式の概要は、表1のとおりである。

〔予備調査の結果〕
監査部では、当プロジェクトで作成された計画書を閲覧し、内容が不明な点や記載が曖昧な箇所について、T課長にインタビューして確かめた。その結果、次のことが分かった。
(1) 営業支援システムの主管部署は営業統括部であるが、現行システム構築時の担当者は退職しており、営業統括部やそのほかの利用部門には、営業支援システムの業務機能の全体を把握している従業員がいない状況である。また、現行システムの開発を担当したベンダも既に保守業務から撤退し、現在は別のベンダが保守を担当している。しかも、保守用のドキュメントが不足しており、システム部にもシステム全体を理解している担当者がいない状況である。
(2) 業務チームがまとめた“業務要求一覧”は、現行システムに対する改善要望が中心なので、現行システムから変更不要な機能については、“現行どおり”と記載されている。
(3) 基幹系システムの再構築プロジェクトの実施時、経営陣からはコストの最適化を求められていた。一方で、営業支援システムは、今後B社の重要な戦略を担うシステムであり、特に、対面販売を代替することができる営業支援システムの実現を早期に達成する、というビジネス目標が、経営陣から提示されている。
(4) B社のシステム構築に関わる規程の中に“システム投資規程”があり、予算額に応じた決裁権限者などが定められている。
(5) 業務チームの検討結果を踏まえ、当プロジェクトは、リライト方式を選択してクラウドサービス上のシステム基盤に新システムを構築する方針で計画書を作成し、プロジェクト運営委員会への提出書類を準備中である。
〔本調査の計画〕
予備調査の結果を踏まえ、監査部では、本調査の監査手続書を作成するために、当プロジェクトの企画段階でのリスク及びコントロールを表2のようにまとめた。
監査部で検討している本調査の概要は、次のとおりである。
(1) 表2項番①について、プロジェクト運営委員会のメンバと、“システム投資規程”の決裁権限者とが整合しているかどうかを確認する。
(2) 表2項番②について、計画書の内容を見ると、コストに関する記述が中心で、再構築方式を決定するまでの検討が不十分ではないかという懸念がある。そこで、リスクに対応したコントロールが当プロジェクトの中で適切に検討されているかどうかを確認する。
(3) 表2項番③のリスクについて、計画書の内容を見ると、“現行を踏襲する”機能については、要件定義書にも具体的な要件は記載せず、“現行どおり”と記載する計画になっている。〔予備調査の結果〕(1)で判明した事実を考慮すると、設計工程及びテスト工程で問題が発生するリスクがある。
(4) 表2項番④について、リライト方式の具体的な手段として、現行のCOBOLから新しいシステム基盤の構築言語であるJavaへの変換ツールの採用が検討されている。このツールは、基幹系システムの再構築時に利用したもので、生産性向上が見込めるものである。ただし、システムを稼働させるためには、ソースプログラムの変換だけでなく、新しいシステム基盤であるクラウドサービスの機能に依存する事項の検討が十分かどうかを確認する。
設問1:
問題文を見る〔本調査の計画〕(1)について、監査部が確認しようとしている具体的な内容を50字以内で述べよ。
模範解答
予算規模に応じたIT投資の責任者がプロジェクト運営委員会のメンバとして参画していること
解説
解答の導き方
まず、表2の項番①では、企画段階の体制について「IT投資の意思決定に必要な情報が意思決定権をもつ者に適時に集約されない」というリスクを挙げています。その対策として、プロジェクト運営委員会に「IT投資の意思決定権をもつ者が参画している」ことが示されています。
したがって、監査で確認するのは、プロジェクト運営委員会が設置されているかどうかだけではありません。当プロジェクトのIT投資について、決定権をもつ者が委員会のメンバに含まれているかを確かめる必要があります。
その決定権をもつ者を特定する手掛かりが、予備調査の結果にあります。B社の「システム投資規程」には、「予算額に応じた決裁権限者などが定められている」とあります。つまり、誰が決裁権限者になるかは、プロジェクトの予算額によって変わる可能性があります。
そこで、当プロジェクトの予算規模に対応する決裁権限者を規程に照らして特定し、その人がプロジェクト運営委員会のメンバとして参画しているかを確認します。これにより、投資判断に必要な情報が、該当する決定権者に集約される体制かどうかを確かめられます。
誤りやすいポイント
- プロジェクト運営委員会の設置や、役員が参加していることだけを確認するのでは不十分です。規程上、当プロジェクトの予算規模に対応する決裁権限者が参加しているかが重要です。
- 委員会のメンバと決裁権限者を照合する際、役職名だけで判断しないようにします。システム投資規程で定められた権限と、実際の委員会メンバを対応させます。
- 「意思決定に必要な情報が集約されるか」というリスクだけを述べると、監査で確認する具体的な内容になりません。予算規模に応じた権限者の参画まで示す必要があります。
FAQ
Q: プロジェクト運営委員会に営業担当役員やシステム担当役員が参加していれば、確認として十分ですか?
A: 十分とは限りません。システム投資規程で、当プロジェクトの予算規模に対する決裁権限者を特定し、その人が委員会に参加しているかを確認します。
A: 十分とは限りません。システム投資規程で、当プロジェクトの予算規模に対する決裁権限者を特定し、その人が委員会に参加しているかを確認します。
Q: なぜ予算規模を確認する必要があるのですか?
A: システム投資規程では、予算額に応じて決裁権限者が定められているためです。予算規模が異なれば、確認すべき権限者も異なる可能性があります。
A: システム投資規程では、予算額に応じて決裁権限者が定められているためです。予算規模が異なれば、確認すべき権限者も異なる可能性があります。
Q: 委員会のメンバ構成を確認する目的は何ですか?
A: 投資判断に必要な情報が、決定権をもつ者に適時に集約される体制になっているかを確かめるためです。
A: 投資判断に必要な情報が、決定権をもつ者に適時に集約される体制になっているかを確かめるためです。
関連キーワード: IT投資管理、意思決定権限、決裁権限、予算承認、プロジェクトガバナンス
設問2:
問題文を見る〔本調査の計画〕(2)について、監査部が確認しようとしている具体的な内容を40字以内で述べよ。
模範解答
再構築方式を比較検討した際の評価項目に、ビジネス目標の視点があること
解説
解答の導き方
-
表2の項番②では、リスクとして「コストを必要以上に削減した結果、ビジネス目標に合致しないシステムになる」とされています。したがって、監査で確認すべきなのは、費用の安さだけで再構築方式を決めていないかどうかです。
-
本文では、経営陣が「対面販売を代替することができる営業支援システムの実現を早期に達成する」というビジネス目標を提示しています。再構築方式を選ぶ際には、この目標を実現できるかどうかも判断材料に含める必要があります。
-
表1では、リホストは短期間・低コストですが、新たな業務仕様の取込みが困難です。リライトも比較的短期間・低コストで実施できますが、新たな業務仕様の取込みには追加コストが発生します。一方、リビルドは新たな業務仕様を実現できますが、高コストで期間も長くなります。このように方式ごとの特徴は異なるため、コストだけでなく、ビジネス目標の実現可能性も含めて比較することが重要です。
-
表2のコントロールにも「コスト削減だけでなく、様々な角度から評価して再構築方式を決定している」とあります。そこで監査部が確認する具体的な内容は、方式の比較検討に用いた評価項目に、ビジネス目標の視点が含まれていることです。リライト方式を選択したこと自体の是非ではなく、その選択に至る評価が適切かを確かめます。
誤りやすいポイント
- 「コストだけでなく、品質や期間も評価すること」とだけ答えると、本文の中心的なリスクであるビジネス目標との不一致への対応が明確になりません。
- リビルド方式ならビジネス目標を実現できると決めつけるのは誤りです。問われているのは特定の方式を選ぶことではなく、方式の比較時にビジネス目標を評価しているかどうかです。
- 業務要求一覧を作成していることだけで、ビジネス目標に合致した方式選択ができているとは限りません。評価項目にその視点が含まれていることを確認する必要があります。
FAQ
Q: なぜ、リライト方式を選んだこと自体を確認するのではないのですか?
A: リライト方式が適切かどうかは、ビジネス目標やコスト、期間などを踏まえて比較した結果で判断されます。方式名だけでは、選定過程が適切だったか分からないためです。
A: リライト方式が適切かどうかは、ビジネス目標やコスト、期間などを踏まえて比較した結果で判断されます。方式名だけでは、選定過程が適切だったか分からないためです。
Q: ビジネス目標は、評価項目にどのように反映される必要がありますか?
A: 各方式が、対面販売を代替するシステムの早期実現にどの程度寄与するかを比較できる視点として含まれている必要があります。
A: 各方式が、対面販売を代替するシステムの早期実現にどの程度寄与するかを比較できる視点として含まれている必要があります。
Q: コストを評価すること自体に問題がありますか?
A: 問題ではありません。リスクは、コストを必要以上に優先し、ビジネス目標に合致するかどうかを考慮せずに方式を決めることです。
A: 問題ではありません。リスクは、コストを必要以上に優先し、ビジネス目標に合致するかどうかを考慮せずに方式を決めることです。
関連キーワード: 再構築方式、評価項目、ビジネス目標、リスク評価、コントロール
設問3:〔本調査の計画〕(3)について、次の(1)、(2)に答えよ。
設問3(1)
問題文を見る監査部が、設計工程で顕在化すると考えた、表2中のアに入れるべきリスクを、40字以内で述べよ。
模範解答
現行システムの要件を熟知している者がいないので、仕様を適切に確定できない。
解説
解答の導き方
-
問われているのは、表2の要件定義の妥当性に関するリスクのうち、設計工程で顕在化するものです。テスト工程のリスクは表2に記載されていますが、設計工程のリスクは空欄になっています。
-
予備調査では、現行システムを構築した担当者は退職しており、利用部門にも「業務機能の全体を把握している従業員がいない」と分かっています。さらに、保守用ドキュメントが不足し、システム部にも全体を理解している担当者がいません。つまり、現行システムの機能や業務上の要件を確認できる人・資料が十分ではありません。
-
その一方で、業務要求一覧では、変更しない機能を「現行どおり」と記載しています。この表現だけでは、現行機能の具体的な仕様が分からず、設計に必要な内容を特定できません。現行の要件を把握して確認できる人もいないため、設計工程で仕様を適切に確定できないリスクが生じます。
-
したがって、[ア]には、現行システムの要件を十分に理解する人がいないため、仕様を正しく定められないという趣旨を記述します。テスト工程のリスクとは異なり、こちらは設計の前提となる仕様を確定できないことが問題です。
誤りやすいポイント
- 「現行どおり」という記載を、現行機能の仕様が明確に定義されていることだと誤解しないようにします。具体的な内容が示されていなければ、設計の根拠として不十分です。
- テスト工程に関する「品質低下やスケジュール遅延」をそのまま[ア]のリスクにしないようにします。設問が求めているのは、その前段階である設計工程のリスクです。
- 問題の中心は、単にドキュメントが不足していることではありません。要件を把握する人も資料も不足している結果、設計に必要な仕様を適切に確定できないことがリスクです。
FAQ
Q: 現行システムに変更を加えない機能なら、詳しい仕様を書かなくても設計できますか?
A: いいえ。「変更しない」ことと「仕様が明確である」ことは別です。現行機能の具体的な内容が分からなければ、新システムで何を維持するかを設計できません。
A: いいえ。「変更しない」ことと「仕様が明確である」ことは別です。現行機能の具体的な内容が分からなければ、新システムで何を維持するかを設計できません。
Q: 要件を把握する人がいない場合、どの工程に影響しますか?
A: まず、要件を設計に落とし込む工程で、必要な仕様を確定できないおそれがあります。仕様が曖昧なまま進めば、後のテストにも影響しますが、この設問で[ア]に求められているのは設計工程でのリスクです。
A: まず、要件を設計に落とし込む工程で、必要な仕様を確定できないおそれがあります。仕様が曖昧なまま進めば、後のテストにも影響しますが、この設問で[ア]に求められているのは設計工程でのリスクです。
関連キーワード: 要件定義、現行機能、仕様確定、設計工程、システム再構築
設問3(2)
問題文を見る監査部が、テスト工程のリスクを引き起こす要因として考えたことは何か。40字以内で述べよ。
模範解答
業務要件が明確でないので、要件を充足しているかどうかのテストができないこと
解説
解答の導き方
この設問では、テスト工程で問題が起きるという結果ではなく、そのリスクを生じさせる原因を答えます。
本文では、業務要求一覧について、現行システムから変更しない機能は「現行どおり」と記載するとあります。さらに、要件定義書にも具体的な要件を記載せず、同じく「現行どおり」とする計画です。
しかし、現行システムについては、業務機能の全体を把握している利用部門の従業員がおらず、保守用のドキュメントも不足しています。そのため、「現行どおり」だけでは、機能が具体的にどう動くべきかを明確にできません。
要件が明確でなければ、テストで確認すべき内容や期待する結果を定められず、要件を満たしているかどうかを判断できません。したがって、テスト工程のリスクを引き起こす要因は、業務要件が不明確で、要件充足を確認するテストができないことです。
誤りやすいポイント
- 「テストが計画どおりに進まない」「品質が低下する」といった結果だけを書くと、リスクの原因を答えたことになりません。
- 「現行どおり」と記載すれば要件が定まると考えないようにします。現行の機能や動作が把握できていなければ、テストの基準になりません。
- 設計工程のリスクと混同しないようにします。この設問では、テスト工程で要件を満たしているか確認できない原因が問われています。
FAQ
Q: 現行システムと同じ機能を作る場合でも、要件を明確にする必要がありますか?
A: 必要です。「同じ」が何を指すのかを具体化しないと、設計やテストで正しい動作を判断できません。
A: 必要です。「同じ」が何を指すのかを具体化しないと、設計やテストで正しい動作を判断できません。
Q: テストが遅れることだけを書いてもよいですか?
A: いいえ。遅延はリスクが表面化した結果です。要件が不明確で、確認すべき内容や期待結果を定められないことが原因です。
A: いいえ。遅延はリスクが表面化した結果です。要件が不明確で、確認すべき内容や期待結果を定められないことが原因です。
Q: 「現行どおり」という記載は、なぜ問題になるのですか?
A: 現行機能を把握できる資料や担当者が不足しているため、その記載だけでは具体的な業務要件を特定できないからです。
A: 現行機能を把握できる資料や担当者が不足しているため、その記載だけでは具体的な業務要件を特定できないからです。
関連キーワード: 要件定義、業務要件、テストケース、期待結果、テスト基準
設問4:
問題文を見る〔本調査の計画〕(4)について、システム基盤に依存する事項に関して監査部が確認しようとしている内容を、35字以内で述べよ。
模範解答
セキュリティ、障害設計などの非機能要件の実現性が検討されていること
解説
解答の導き方
-
問われているのは、再構築方式そのものの選定理由ではなく、新しいシステム基盤に依存する事項について、監査部が計画書で何を確認するかです。
-
本調査の計画(4)では、リライト方式において、現行のCOBOLからJavaへの変換ツールを使うことが検討されています。ただし、本文には「ソースプログラムの変換だけでなく」とあり、プログラムを新しい言語に置き換える作業だけでは、システムの稼働に必要な検討は完了しないと分かります。
-
さらに、確認対象として「新しいシステム基盤であるクラウドサービスの機能に依存する事項」が挙げられています。つまり、クラウドサービスが提供する機能を使って、システムに必要な要件を実現できるかどうかが論点です。
-
こうした要件には、セキュリティや障害時の設計など、機能の実現だけではなくシステム全体の品質・運用に関わる非機能要件があります。したがって、監査部が確認するのは、非機能要件を新しいシステム基盤で実現できるかが検討されていることです。
誤りやすいポイント
- Javaへの変換ツールの性能や変換後のプログラムの品質だけを答えないようにします。本文では、変換だけでなくクラウドサービスの機能に依存する事項も確認対象としています。
- クラウドサービスの機能を列挙するだけでは、確認内容として不十分です。必要な要件をその機能で実現できるか、つまり実現性の検討まで含めます。
- 業務機能や業務要求の充足を中心に答えるのは避けます。この設問では、基盤に関係するセキュリティや障害設計などの非機能要件が焦点です。
FAQ
Q: 非機能要件とは、どのような要件ですか?
A: システムが提供する業務機能そのものではなく、セキュリティ、可用性、性能、障害時の動作など、システムの品質や運用に関わる要件です。
A: システムが提供する業務機能そのものではなく、セキュリティ、可用性、性能、障害時の動作など、システムの品質や運用に関わる要件です。
Q: なぜプログラムの変換だけでは不十分なのですか?
A: 変換ツールでプログラムを新しい言語に置き換えられても、クラウドサービスの機能を使ってセキュリティや障害時の設計などを実現できるかは、別に検討する必要があるためです。
A: 変換ツールでプログラムを新しい言語に置き換えられても、クラウドサービスの機能を使ってセキュリティや障害時の設計などを実現できるかは、別に検討する必要があるためです。
Q: クラウドサービスの機能に依存する事項は、いつ検討すべきですか?
A: 企画段階で確認しておくことが重要です。検討漏れがあると、開発段階で追加コストが発生するリスクがあるためです。
A: 企画段階で確認しておくことが重要です。検討漏れがあると、開発段階で追加コストが発生するリスクがあるためです。
関連キーワード: 非機能要件、クラウドコンピューティング、セキュリティ、障害設計、可用性




