システム要件定義で利用者はどう関わるべきか
ITパスポート試験 令和8年度 問52 ／ システム開発技術 › システム開発技術
過去問にチャレンジ
業務システムの開発において，開発者がシステム要件定義を実施する場合，利用者の関わり方として，最も適切なものはどれか。
- ア
開発者が行うシステム要件のレビューに参加し，妥当性を確認する。
- イ
開発者に全て任せ，その決定に従う。
- ウ
システムの保守が可能かどうかを見極める。
- エ
システム要件の技術的な実現性を検証する。
会話形式の解説
講師今回は、開発者がシステム要件定義を進めるときに、利用者がどう関わるのが適切かを問う問題です。システム要件定義は、システムに必要な機能や性能などをはっきりさせる工程です。利用者と開発者の役割分担に注目して考えてみましょう。
受験者開発者が要件定義をするのなら、専門知識のない利用者は任せたほうがうまくいく気もします。でも、全部任せるのは少し不安です。
講師その不安は正しい感覚です。開発者は技術には詳しいですが、利用者の業務や現場の課題に詳しいとは限りません。利用者が関わらないと、業務要件の誤りに気づく人がいなくなり、業務に合わないシステムができてしまうおそれがあります。ですから、開発者に全て任せてその決定に従うという選択肢は不適切です。
受験者では、利用者は何を確かめればよいのでしょうか。保守ができるかどうかや、技術的に実現できるかどうかを確認する選択肢もあって、どれもしっかりした関わり方に見えます。
講師そこが引っかけどころです。保守が可能かどうかは技術面から判断する事柄で、開発者や保守担当者の役割です。要件が技術的に実現できるかの検証も、開発者など技術側の役割になります。利用者には技術知識が前提とされていないので、これらを利用者の役割とするのは役割分担が逆なのです。
受験者なるほど。利用者が確かめるのは技術面ではなく、業務の面ということですね。
講師そのとおりです。要件が業務の実態やニーズに合っているかを確かめられるのは利用者です。保守性に関しても、利用者が確かめるべきなのは、むしろ実際の業務で運用できるかという点です。
受験者それなら、開発者が行うシステム要件のレビューに参加して妥当性を確認するという選択肢が、利用者の立場に合っていると思います。
講師正解です。利用者がレビューで確認することで、認識のずれや要件の抜け漏れを早い段階で見つけられ、完成するシステムの品質も高まります。要件定義では、利用者が業務の視点で確認に関わることが欠かせません。
受験者選択肢の作業が業務の視点で行うものか、技術の視点で行うものかを見分ければよいのですね。
講師はい。この問題では、実現性や保守性といった技術寄りの言葉が開発側の役割を示していました。ただし、あくまで目安として使ってください。また、全て任せるのように利用者が関わらない選択肢は、要件定義の問題では誤りになるのが基本です。
まとめ
システム要件定義は、システムに必要な機能や性能などを明確にする工程です。開発者は技術に詳しい一方で、利用者の業務には詳しいとは限らないため、要件が業務の実態やニーズに合っているかは利用者がレビューで確認する必要があります。技術的な実現性や保守性の判断は、主に開発側の役割です。開発者に全てを任せると、業務に合わないシステムができるおそれがあります。利用者が早い段階で確認することで、認識のずれや抜け漏れを防ぎ、品質を高められます。
解答・解説
正解はアです
この問題のテーマ
システム要件定義を開発者が進めるときに、利用者がどう関わるのが適切か、つまり利用者と開発者の役割分担を問う問題です。
解き方の考え方
まず、システム要件定義はシステムに必要な機能や性能などをはっきりさせる工程だと押さえます。次に、利用者は業務をよく知る立場で、開発者は技術に詳しい立場だという役割の違いを考えます。そのうえで、各選択肢の作業が「業務の視点で確かめること」なのか「技術の視点で判断すること」なのかを見分けます。利用者の立場にふさわしい関わり方を述べたものが正解です。
選択肢ごとの解説
- ○ア 開発者が行うシステム要件のレビューに参加し，妥当性を確認する。システム要件のレビューに参加して妥当性を確認するという関わり方は適切です。開発者は利用者の業務や現場の課題に必ずしも詳しくないため、要件が業務の実態やニーズに合っているかは利用者が確かめる必要があります。利用者が確認することで、認識のずれや要件の抜け漏れを早い段階で見つけられ、完成するシステムの品質も高まります。
- ×イ 開発者に全て任せ，その決定に従う。開発者に全てを任せてその決定に従うという姿勢は不適切です。利用者が関わらないと、業務要件の誤りに気づく人がいなくなり、業務に合わないシステムができてしまうおそれがあります。要件定義は、利用者が主体的に関わるべき工程です。
- ×ウ システムの保守が可能かどうかを見極める。システムの保守が可能かどうかを見極めることは、利用者ではなく開発者や保守担当者の役割です。保守性は技術面から判断する事柄です。利用者が確かめるべきなのは、むしろ実際の業務で使いこなせるかという点です。
- ×エ システム要件の技術的な実現性を検証する。システム要件が技術的に実現できるかを検証するのは、開発者など技術側の役割です。利用者には技術知識が前提とされておらず、業務面から要件の妥当性を確認する立場にあります。技術面の検証を利用者の役割とするのは役割分担が逆になっています。
補足
この種の問題では、選択肢の作業が「業務の視点」と「技術の視点」のどちらで行うものかを見分けると、素早く判断できます。「実現性」や「保守性」といった技術寄りの言葉が出てきたら、開発側の役割ではないかと疑ってみましょう。また、「全て任せる」のような利用者が関わらない選択肢は、要件定義の問題では誤りになるのが基本です。
POINT
- システム要件定義は、システムに必要な機能や性能などを明確にする工程です。
- 利用者は、要件が業務の実態やニーズに合っているかを、レビューを通じて確認する役割を担います。
- 技術的な実現性や保守性の判断は、主に開発側の役割です。
- 利用者が早い段階で確認することで、認識のずれや抜け漏れを防ぎ、システムの品質を高められます。