ITパスポート 2013年 秋期 問02

株式注文時の責任者承認の例外ルールの把握段階【ITパスポート 解説】

正解の理由

• 業務要件の定義（業務要件定義）：業務で何を実現するか、どんなルールや制約があるかを整理する工程。ここでビジネスルール（業務の判断基準や例外処理）を明確にします。
• 今回の不良は運用テスト（運用テスト：運用に近い環境で実際の業務を想定して行うテスト）で発見されています。運用テストで出る「業務の抜け」は、最初の業務要件定義が不十分だったことを意味します。したがって、正しくは最初の段階である ア で把握しておくべきでした。

解法ステップ

1. 問題文から「例外ルール」がどの性質かを判定する
   • これは技術的仕様ではなく、誰がどのように判断・承認するかという業務ルールです。
2. 各選択肢の工程の意味を確認する（簡潔に）
   • 業務要件の定義：業務の目的やルールを決める段階
   • システム要件の定義：業務を実現するためにシステムが何をすべきかを決める段階
   • ソフトウェア要件の定義：ソフトウェア単体での具体的な機能・仕様を決める段階
   • システムテスト要件の定義：どのようなテストを行うかを決める段階
3. 業務ルールはどの段階で確定すべきかを照らし合わせる
   • 業務ルールは最上流の「業務要件」で決まるため、ここで把握しておく必要がある。
4. よって答えは ア（業務要件の定義）。

選択肢別の誤答解説

• ア：正しい選択肢です。業務ルール（例外含む）は業務要件定義で明らかにします。ここで抜けがあると下流工程すべてに影響します。
• イ（システムテスト要件の定義）：システムテスト要件は「どのようにテストするか」を決めます。何をテストすべきかは業務要件やシステム要件が前提です。業務ルールそのものを決める工程ではありません。
• ウ（システム要件の定義）：システム要件は「業務を実現するためにシステムがどう振る舞うか」を決めます。業務ルールが既に確定していればここで具体化しますが、業務ルール自体を定義する場所ではありません。
• エ（ソフトウェア要件の定義）：ソフトウェア要件はソフトウェア製品側の細かな仕様（画面振る舞い、入力チェック等）を決めます。業務ルールはさらに上流で確定しておかねばなりません。

よくある誤解

1. 「例外ルールはテスト段階で見つければ十分」
   • テストで見つかっても遅いことが多いです。業務の判断基準が後から変わると設計・開発の手戻りが発生します。業務要件段階で洗い出すことが肝心です。
2. 「システム設計者が業務の詳細を全部把握すべき」
   • システム設計者（ベンダ）は業務専門家ではありません。顧客側（業務担当）が業務ルールを伝え、ベンダは聞き取り・確認して文書化するという協働が必要です。
3. 「業務要件は曖昧でも下流で調整できる」
   • 曖昧さは誤解とコスト増を招きます。特に例外や承認フローは明確にしておくべきです。

補足コラム

• 要件定義フェーズでの業務ヒアリング項目例：通常処理、例外処理、承認者、権限、手順、判断基準、ログ記録の有無
• 要件トレーサビリティ：業務要件→システム要件→ソフトウェア要件→テストケースへ一つひとつ紐づけることで、どの仕様がどの業務ルール由来かを追えるようにします。
• ドキュメントと合意（サインオフ）：業務側の承認（サインオフ）を明確に取ることで、後から「知らなかった」を防ぎます。
• ユーザー受入テスト（UAT：User Acceptance Test）を早めに実施し、実業務の担当者に確認してもらうことも効果的です。

FAQ