システム監査技術者 2011年 午後1 問03

解答の導き方

1. まず、リスクの原因となる記述を確認します。X社は「自社の標準様式」で要件定義書を作成し、データモデルについては「概念データモデルとしてE-R図」を作成しました。一方、T社は「論理データモデルの記載内容の一部を含んだ独自のフォーマット」を想定していました。ここから、両社で必要な記載内容や詳細さの認識が異なっていたと分かります。
2. この違いは、単に書式が違うという問題にとどまりません。どの用語をどの意味で使うか、設計に必要な情報をどこまで記載するかについて認識が合っていないと、要件定義書を読む側が内容を異なる意味に受け取るおそれがあります。
3. X社はT社の指摘を受けて要件定義書を追加・修正しています。しかし、監査部はなお「基本設計以降の工程でリスクが顕在化するおそれがある」と考えています。したがって、修正後も両社の理解が十分に一致していない場合、要件定義書を基に進める基本設計で、設計内容について誤解が生じることがリスクです。

誤りやすいポイント

• リスクを「要件定義書の様式が異なること」だけで終わらせないようにします。様式の違いから、内容や記載レベルの認識にずれが生じ、設計で誤解が起きるという影響まで述べる必要があります。
• 「要件定義書を修正したのでリスクはなくなった」とは判断できません。修正の事実だけでは、T社とX社の間で理解が一致したことまでは確認できないためです。
• 「開発が遅れる」「費用が増える」といった一般的な影響ではなく、設問で示されたデータモデルの認識相違が、基本設計以降にどのような問題を招くかに焦点を当てます。

FAQ

解答の導き方

1. 問われているのは、要件定義書の内容に相違が見つかったとき、監査部がどのような改善を提言すべきかです。注目するのは、単に記載内容を修正したかどうかではなく、相違が生じた原因です。
2. 本文では、データモデルについて「記載内容、記載レベル」にT社とX社の認識の相違があったとされています。具体的には、X社は「概念データモデルとしてE-R図」を作成した一方、T社は「論理データモデルの記載内容の一部を含んだ独自のフォーマット」を想定していました。両者で、データモデルに何をどの程度記載するかについて理解が異なっていたと分かります。
3. この相違は、書式の違いだけとは限りません。「概念データモデル」や「論理データモデル」などの用語が指す内容について、両者の理解が異なっていれば、要件定義書を修正しても、基本設計以降で成果物の内容や粒度に再び食い違いが生じるおそれがあります。
4. そこで改善策では、個々の記述を直すだけでなく、関係者が使う用語の意味や定義を共通に理解しているか確認することが重要です。使用する用語の意味や定義が一致しているかを確かめる、という提言につながります。

誤りやすいポイント

• 「X社の標準様式を使ったこと」が問題の中心だと考え、書式の統一だけを提案しないようにします。本文で問題になっているのは、記載内容や記載レベルについての認識の相違です。
• 「データモデルを追加・修正すること」だけでは、相違の原因が解消されたとは限りません。用語の意味や定義が共有されているかまで確認する必要があります。
• 「E-R図を作成すること」や「論理データモデルを必ず作成すること」を提言する設問ではありません。どの成果物を作るかではなく、用語の理解が一致しているかを確認する改善策が求められています。

FAQ

解答の導き方

誤りやすいポイント

• 「要件定義書の作成はX社が担当する」という記述だけを見て、要件定義の責任もX社にあると考えること。
• X社が作成した要件定義書をT社がレビューしたかどうかだけに注目し、T社が要件を決定する責任を持っているかを見落とすこと。
• システム部が要件定義に直接関与していない点を、この設問の中心的な確認事項とすること。ここでは契約形態から、発注者であるT社の責任を確認する点が重要です。

FAQ

解答の導き方

誤りやすいポイント

• 「システム部が要件定義に参加していない」とだけ述べると、確認すべき事項ではなく、状況の指摘にとどまります。
• 製造管理部がレビューしたという事実だけで、技術面の確認も済んでいると判断しないようにします。本文では、製造管理部はシステム基盤に依存する箇所を判断できないとしています。
• X社が作成したことだけを問題にするのも適切ではありません。確認すべきなのは、基盤に依存する記述のレビューが実際にどう行われたかです。

FAQ