システム監査技術者 2019年 午後1 問03
基幹システムのオープン化の監査に関する次の記述を読んで、設問1~5に答えよ。
B社は、中堅の機械メーカである。B社では、メインフレーム上に、販売、購買、生産管理のサブシステムで構成される基幹システム(以下、現行システムという)を構築し、運用・保守を行っている。これまではメインフレームを更新しながら使用してきたが、昨年社長から情報システムのコスト削減を指示された。また、メインフレームの技術者を維持することが今後困難になると想定されることから、B社情報システム部は、基幹システムをオープン化する検討を始めた。
〔B社基幹システムのオープン化〕
情報システム部は、早期にコストを削減すること、オープン系システムのノウハウが不十分であることなどを考慮した結果、B社基幹システムの再構築を次の2段階に分けて実施することにした。
・第1段階:現行システムのインフラをオープン化し、本番稼働した後、オープン系システムのノウハウを蓄積する。
・第2段階:システム機能の再配置、業務処理の最適化など、業務機能を見直す。
情報システム部は、第1段階のB社基幹システム再構築(以下、本システム再構築という)計画を取りまとめて、B社の経営会議に提案する予定である。
〔本システム再構築計画に関するシステム監査〕
B社におけるシステム再構築が20年ぶりということもあり、B社監査部はコスト超過、稼働遅れなどが発生するリスクが高いと判断し、本システム再構築計画についてシステム監査を行うことにした。
監査チームは、現行システムの状況及び本システム再構築計画の検討過程について、予備調査として情報システム部と利用部門へのヒアリングを行った。その結果は、次のとおりである。
(1) 情報システム部へのヒアリング結果
① 現行システムの状況
・情報システム部では、現行システム構築後、継続的に機能・画面・帳票の追加、変更などの保守業務を行っている。
・現行システムのソフトウェア資産は、全て最新のソースプログラムが保管されている。
・現行システムのドキュメントは、システム構築時の要件定義書、機能設計書及び詳細設計書が全て保管されている。
・大きな機能追加の際には、追加機能の設計書を作成している。しかし、その他の機能変更の際には、担当者の判断でソースプログラムにコメントを追加する場合もあるが、設計書の更新までは行っていない。その結果、設計書の内容と実際の機能仕様・プログラム仕様とが必ずしも一致していない状態となっており、保守業務ではテスト工程で発生したエラーの原因解析に手間取るケースもある。
・情報システム部では、部員の異動に加え、各サブシステムの部分的な機能追加、機能変更を繰り返してきたことから、現行システム全体の機能要件及び業務要件について精通した部員がいない。
② 本システム再構築計画の検討過程
・情報システム部の検討チームでは、数社のITベンダに本システム再構築の提案を依頼し、提示された幾つかの案を比較検討した。その結果、本番稼働までの期間とコストを重視して、現行システムのソフトウェア資産を流用する、いわゆる“リホスト”と呼ばれる方法を選択した。
・本システム再構築の方針は、表1のとおりである。

③ 本システム再構築の概要
本システム再構築は、分析工程、設計工程、製造工程、テスト工程の順に実施する。各工程における実施内容は表2のとおりである。

(2) 利用部門へのヒアリング結果
・現行システムが利用部門の要望に合わせて機能追加、機能変更を行ってきていることから、現時点では大きな不満や重要な機能不足は認識されていない。
・本システム再構築計画について、情報システム部から現行の機能要件を踏襲するという説明を受けており、特に問題はないと認識しているので、利用部門はテスト工程から参画する計画である。
・現行システムは構築当初から時間がたっており、その間の業務変更などによって、現在では使用されていない機能・画面・帳票も存在する。
〔想定されるリスクと本調査での確認ポイント〕
監査チームは、予備調査の結果を基に、本システム再構築計画に関して想定されるリスクについて検討を行い、本調査での確認ポイントを表3のとおりまとめた。
設問1:
問題文を見る表3項番1について、監査チームが、分析工程における情報システム部の計画の詳細に関して確認すべき具体的な内容を、40字以内で述べよ。
模範解答
未使用の機能・画面・帳票について、再構築対象範囲からの除外を検討していること
解説
解答の導き方
-
表3項番1で問題にしているのは、現行のソフトウェア資産をそのまま流用した場合に、再構築コストが過大になるリスクです。したがって、確認するのはコスト削減の一般論ではなく、どの資産を再構築の対象にするかという分析工程の計画です。
-
表2の分析工程では、ソフトウェア資産を調査して「再構築対象範囲を決定する」とされています。このため、資産を一律に引き継ぐのではなく、必要なものと不要なものを分ける計画があるかを確かめる必要があります。
-
その判断材料は、利用部門へのヒアリング結果にあります。そこには「現在では使用されていない機能・画面・帳票も存在する」とあります。これらまで再構築対象に含めると、利用されていないものにも変換やテストなどの作業が発生し、コストが増えるおそれがあります。
-
したがって、分析工程の計画については、未使用の機能・画面・帳票を再構築対象から外すことを検討しているか確認します。設問では、その具体的な確認内容を述べればよいです。
誤りやすいポイント
- 「現行資産を流用する」という方針から、すべての資産を必ず移行すると考えてしまうことです。分析工程で対象範囲を決めるため、不要な資産を除外できるかも確認対象になります。
- コスト超過のリスクに対して、予算の管理方法やITベンダとの契約内容を答えてしまうことです。この設問は、分析工程での再構築対象範囲の決定に関する確認を問うています。
- 利用部門に大きな不満がないという情報だけで、現行機能をすべて残すべきだと判断することです。使用されていない機能・画面・帳票があるという情報も合わせて考える必要があります。
FAQ
Q: 「機能要件の変更なし」とあるのに、未使用の機能を対象外にしてよいのですか?
A: その方針だけで一律に決めるのではなく、実際の利用状況を分析し、不要な機能などを対象外にすることを検討しているか確認します。
A: その方針だけで一律に決めるのではなく、実際の利用状況を分析し、不要な機能などを対象外にすることを検討しているか確認します。
Q: 未使用の画面や帳票も、なぜ確認対象になるのですか?
A: プログラムだけでなく画面や帳票も再構築に関わる資産です。使われていないものまで対象にすると、その分の作業が増え、コスト超過につながるおそれがあるためです。
A: プログラムだけでなく画面や帳票も再構築に関わる資産です。使われていないものまで対象にすると、その分の作業が増え、コスト超過につながるおそれがあるためです。
Q: この設問では、未使用の資産を必ず除外すると答えるのですか?
A: 必ず除外すると断定するのではなく、再構築対象範囲からの除外を検討しているかを確認する、と答えるのが適切です。
A: 必ず除外すると断定するのではなく、再構築対象範囲からの除外を検討しているかを確認する、と答えるのが適切です。
関連キーワード: システム再構築、資産移行、対象範囲、要件分析、コスト管理
設問2:
問題文を見る表3項番2について、監査チームが、分析工程の実施内容に関して追加確認すべき具体的な内容を、45字以内で述べよ。
模範解答
プログラム変換ツールのトライアル対象範囲が狭過ぎたり、偏ったりしていないこと
解説
解答の導き方
-
表3項番2で問題となっているのは、製造工程でプログラム変換ツールによる変換作業に問題が起き、本番稼働が遅れるリスクです。したがって、監査では、製造工程に進む前に変換作業の問題をどれだけ把握できる計画になっているかを確認する必要があります。
-
表2の分析工程では、「実際に幾つかのプログラムを変換し、変換の可否及び精度を確認する」とあります。このトライアルは、変換ツールが使えるか、変換結果が適切かを事前に確かめるためのものです。
-
しかし、トライアルで対象にしたプログラムが少なすぎると、変換しにくいプログラムが含まれていても発見できない可能性があります。また、対象が特定の種類のプログラムに偏っている場合も、現行資産全体にある多様な変換上の問題を把握できません。
-
トライアルの結果を受けて設計工程でツールのカスタマイズ内容や手作業で作成する範囲を決めるため、分析工程のトライアル対象が適切でなければ、後工程の作業量や期間の見積りも不正確になります。そこで、対象範囲が狭すぎず、特定の種類に偏っていないことを確認します。
誤りやすいポイント
- トライアルを実施する計画があることだけで十分と考えないことが重要です。実施するだけでは、対象の選び方が適切かどうかは分かりません。
- 「変換の可否及び精度を確認する」という目的だけに注目し、トライアル対象の範囲や偏りを見落とさないようにします。
- 製造工程で問題が起きるリスクへの対策として、テスト工程の内容を答えないようにします。確認すべきなのは、分析工程のトライアルが変換上の問題を事前に発見できる対象設定になっているかです。
FAQ
Q: トライアル対象のプログラム数が多ければ、十分な確認になりますか?
A: 数だけでは判断できません。対象に種類の偏りがなく、変換の難しさなどの違いを把握できる選定になっていることも必要です。
A: 数だけでは判断できません。対象に種類の偏りがなく、変換の難しさなどの違いを把握できる選定になっていることも必要です。
Q: なぜ対象の偏りが問題になるのですか?
A: 特定の種類だけを試すと、別の種類に固有の変換上の問題がトライアルで見つからず、製造工程で初めて発覚するおそれがあるためです。
A: 特定の種類だけを試すと、別の種類に固有の変換上の問題がトライアルで見つからず、製造工程で初めて発覚するおそれがあるためです。
Q: トライアル結果は後工程にどう影響しますか?
A: 結果を踏まえて、ツールのカスタマイズ内容や手作業で作成する範囲を決めます。トライアルの対象が不適切だと、後工程の作業範囲や期間の判断にも影響します。
A: 結果を踏まえて、ツールのカスタマイズ内容や手作業で作成する範囲を決めます。トライアルの対象が不適切だと、後工程の作業範囲や期間の判断にも影響します。
関連キーワード: プログラム変換、トライアル、サンプリング、リスク評価、移行計画
設問3:
問題文を見る表3項番3について、監査チームが、手作業で作成したプログラムを含む現新比較テストが計画どおりに進まないと考えた理由を、50字以内で述べよ。
模範解答
設計書が最新ではないので、現新比較テストで不一致発生時に、原因解析に時間を要するから
解説
解答の導き方
-
設問は、手作業で作成したプログラムも含めた現新比較テストが、計画どおりに進まないと考えた理由を問うています。現新比較テストでは、現行システムと再構築後のシステムの処理結果を照合するため、不一致があれば原因を調べる必要があります。
-
情報システム部へのヒアリングでは、機能変更のたびに設計書を更新していたわけではなく、「設計書の内容と実際の機能仕様・プログラム仕様とが必ずしも一致していない」とされています。つまり、設計書を調べても、実際の現行システムの動きをすぐには把握できない場合があります。
-
さらに、保守業務では「テスト工程で発生したエラーの原因解析に手間取るケースもある」と分かっています。現新比較テストで不一致が起きた場合も、設計書と実際の仕様のずれが原因解析を難しくし、時間を要することが予想されます。その結果、テストが計画どおりに進まないと考えられます。
誤りやすいポイント
- 手作業で作成したプログラムがあることだけを、遅延の理由にしないようにします。設問が問うのは、そのプログラムを含む現新比較テストの進行が遅れる理由です。
- 現新比較テストで不一致が発生すること自体ではなく、不一致の原因を調べるのに時間がかかる点まで説明する必要があります。
- テスト工程の予備期間があるかどうかは監査上の確認ポイントです。設問は、テストが計画どおりに進まないと考えた理由を問うています。
FAQ
Q: 設計書が保管されているなら、原因解析に使えるのではありませんか?
A: 設計書は保管されていますが、機能変更のたびに更新されておらず、実際の機能仕様・プログラム仕様と一致しない場合があるため、原因解析にそのまま使えるとは限りません。
A: 設計書は保管されていますが、機能変更のたびに更新されておらず、実際の機能仕様・プログラム仕様と一致しない場合があるため、原因解析にそのまま使えるとは限りません。
Q: 現新比較テストで不一致が出た場合、なぜ原因解析に時間がかかるのですか?
A: 現行システムの実際の仕様を設計書から確認できないと、不一致がどこから生じたのかを特定するために、プログラムなどを調べる手間が増えるからです。
A: 現行システムの実際の仕様を設計書から確認できないと、不一致がどこから生じたのかを特定するために、プログラムなどを調べる手間が増えるからです。
関連キーワード: 現新比較テスト、設計書、機能仕様、原因解析、テスト工程
設問4:
問題文を見る表3項番4について、監査チームが、適切なリスク軽減策として想定したと考えられる施策について、45字以内で具体的に述べよ。
模範解答
設計工程にも利用部門が参画し、プロトタイプなどで早期に操作性を確認してもらう。
解説
解答の導き方
-
利用部門はテスト工程から参画する予定ですが、操作性の問題がその段階で初めて分かると、修正や再確認が必要になり、テストの遅れにつながるおそれがあります。テスト工程で確認するだけでなく、より早い段階で利用部門に操作性を確かめてもらう対策が必要です。
-
そこで、設計工程にも利用部門に参画してもらい、プロトタイプなどを用いて、画面の見やすさや操作のしやすさを早期に確認します。利用者の意見を設計に反映できれば、ユーザ受入テストで問題が初めて見つかるリスクを軽減できます。
誤りやすいポイント
- 「利用部門がテスト工程に参画する」だけでは、操作性の問題を早期に発見する対策にはなりません。設計段階で確認することがポイントです。
- 現行機能を踏襲することと、操作性が現行と同じであることは別です。ユーザインタフェースが変わる以上、実際に利用する人による確認が必要です。
- 「利用部門に説明する」だけでは、操作性を実際に確認したことになりません。プロトタイプなどを用いて、早い段階で具体的に操作してもらう施策が適切です。
FAQ
Q: なぜ、テスト工程から利用部門が参画するだけでは不十分なのですか?
A: テスト工程で初めて操作性の問題が判明すると、修正や再テストが必要になり、スケジュールに影響する可能性があるためです。
A: テスト工程で初めて操作性の問題が判明すると、修正や再テストが必要になり、スケジュールに影響する可能性があるためです。
Q: プロトタイプを使う目的は何ですか?
A: 完成前の画面や操作の流れを利用部門に確認してもらい、使いにくさを早期に把握して設計へ反映することです。
A: 完成前の画面や操作の流れを利用部門に確認してもらい、使いにくさを早期に把握して設計へ反映することです。
Q: 現行機能を踏襲するなら、操作性も問題ないのではありませんか?
A: 機能が同じでも、画面や操作方法が変われば使い勝手は変わることがあります。機能の確認とは別に、操作性の確認が必要です。
A: 機能が同じでも、画面や操作方法が変われば使い勝手は変わることがあります。機能の確認とは別に、操作性の確認が必要です。
関連キーワード: プロトタイピング、ユーザビリティ、ユーザ受入テスト、画面設計、リスク軽減策
設問5:
問題文を見る表3項番5について、監査チームが、情報システム部の対応計画に関して確認すべき事項を一つ挙げ、40字以内で具体的に述べよ。
模範解答
要件定義書や設計書を整理し、最新の要件や仕様を反映する計画が存在すること
解説
解答の導き方
-
表3項番5では、本システム再構築の後に予定されている第2段階が円滑に進まないリスクを取り上げています。第2段階では「システム機能の再配置、業務処理の最適化など、業務機能を見直す」ため、現行システムの機能や業務要件を正確に把握できることが前提になります。
-
ところが、情報システム部には「現行システム全体の機能要件及び業務要件について精通した部員がいない」とあります。さらに、機能変更時に設計書が更新されず、「設計書の内容と実際の機能仕様・プログラム仕様とが必ずしも一致していない」状態です。したがって、現在の資料だけでは、実際の仕様や業務上の要件を正確に把握しにくいと分かります。
-
要件や設計の根拠が不明確なままでは、第2段階で機能を見直す際に、何を維持し、何を変更するかの判断が難しくなります。そのため、監査チームは、情報システム部が要件定義書や設計書を整理し、現状に合った要件・仕様を反映する計画を立てているか確認すべきです。
誤りやすいポイント
- ソースプログラムが保管されていることだけで、現行システムの要件や仕様を把握できると考えないようにします。資料と実際の仕様に不一致があるため、資料の整理・更新が必要です。
- 「第2段階に向けた対応計画」を、担当者の育成や要員確保だけに置き換えないようにします。本文では、設計書の更新不足と、機能要件・業務要件に精通した部員がいないことが具体的な問題として示されています。
- 資料を単に保管し直すだけでは不十分です。最新の要件や仕様を反映し、第2段階で使える状態にする計画かどうかが確認点です。
FAQ
Q: 要件定義書や設計書は保管されているのに、なぜ整理・更新が必要なのですか?
A: 構築時の資料は保管されていますが、その後の機能変更が設計書に反映されていないためです。保管されていることと、現状を正しく示していることは別です。
A: 構築時の資料は保管されていますが、その後の機能変更が設計書に反映されていないためです。保管されていることと、現状を正しく示していることは別です。
Q: 第2段階では、なぜ最新の要件や仕様が重要なのですか?
A: 第2段階では業務機能を見直すため、現行の機能や業務要件を把握できなければ、変更の要否や範囲を適切に判断できないからです。
A: 第2段階では業務機能を見直すため、現行の機能や業務要件を把握できなければ、変更の要否や範囲を適切に判断できないからです。
Q: ソースプログラムにコメントを追加していれば、設計書の更新は不要ですか?
A: いいえ。本文では、コメント追加が担当者の判断に委ねられる場合があり、設計書と実際の仕様が一致していないとされています。計画的に資料を整備し、最新の要件や仕様を反映する必要があります。
A: いいえ。本文では、コメント追加が担当者の判断に委ねられる場合があり、設計書と実際の仕様が一致していないとされています。計画的に資料を整備し、最新の要件や仕様を反映する必要があります。
関連キーワード: 要件定義、設計書、業務要件、仕様管理、システム再構築




