平成25年度 秋期 ITパスポート試験 問2 解説 要件定義の段階

プロジェクトにおけるルールの定義漏れを防ぐには、まず開発の出発点である業務要件の定義において、現場のルールを漏れなく洗い出すことが不可欠です。システム化する前の段階で、誰がどのような権限を持ち、どのような例外処理が発生するのかという業務の実態を整理できていなかったことが、今回の不良の根本的な原因です。

業務のルールは誰が決定するものか

システム開発において、要件定義は大きく分けて、業務要件、システム要件、ソフトウェア要件の順に進んでいきます。この中で、最も上流に位置するのが業務要件の定義です。

業務要件の定義とは、新しいシステムを使ってどのような業務を実現したいのか、そのために必要な業務の流れやルールを明確にする工程です。今回の問題にある「責任者承認における例外ルール」は、証券会社であるA社特有のビジネスルールであり、エンジニアリングの知識ではなく、A社の業務知識に基づいて定義されるべき内容です。

システムを構築するB社がこのルールを把握できていなかったということは、A社が自社の業務フローを整理してB社に伝えるこの最初の段階で、定義が不十分だったことを意味します。

工程ごとに定義される内容の違い

なぜ他の選択肢ではないのかを理解するために、それぞれの工程で何を決定するのかを整理します。

業務要件の定義

システムを利用する側の視点に立ち、業務の目的、範囲、ルール、運用体制などを決めます。今回のような「誰が承認するか」「例外時はどうするか」といった業務ロジックは、すべてこの段階で確定させます。

システム要件の定義

業務要件を実現するために、システムにどのような機能を盛り込むかを決めます。また、性能（処理スピード）、信頼性（止まりにくさ）、セキュリティといった、目に見える機能以外の側面（非機能要件）についても検討します。

ソフトウェア要件の定義

システム要件を実現するために、ソフトウェアがどのようなデータの処理を行い、どのような画面や帳票を出力するかといった詳細な仕様を決めます。

システムテスト要件の定義

構築されたシステムが、システム要件を満たしているかを確認するためのテスト計画を立てる工程です。ここではテストの実施方法や判定基準を決めますが、ここでルールそのものを作るわけではありません。

開発工程における「手戻り」の教訓

今回の問題では、プロジェクトの最終盤である運用テストの段階で、最上流工程である業務要件の不備が見つかりました。これはシステム開発において最も避けたい事態の一つです。

運用テストは、実際に業務を行うユーザー（A社）が、システムが自分たちの仕事に使えるかどうかを確認する最終チェックです。ここでルール漏れが発覚すると、プログラムの修正だけでなく、設計のやり直し、場合によってはデータベースの構造変更など、膨大な修正作業（手戻り）が発生します。

この問題の教育的な意図は、上流工程でユーザー側が自分たちの業務を正しく棚卸しし、ベンダと共有することの重要性を理解させることにあります。システムを作るのはベンダですが、どのようなルールで業務を回すかを決めるのは、あくまで発注者であるユーザー側の責任であるという点が、ITパスポート試験でもよく問われる重要なポイントです。

参考リンク

• ITパスポート試験 令和3年度秋期 分類：ストラテジ系 問2
• 要件定義で爆死しないために、意識していること。
• システム開発における「共通フレーム」とは？