問29
頻出度★★★
現行システムの使用を開始してから10年が経過し, その間に業務内容も変化してきた。そこで, 全面的に現行システムを開発し直すことになった。開発者が, システム要求の分析と, それに基づく要件定義を行う場合, 開発者のシステム利用部門とのかかわり方として, 適切なものはどれか。
平成21年度 秋期 ITパスポート試験 問29
マネジメント系システム開発技術 › システム開発技術
この問題の解説と、これまでの解答の記録です。
解説
問 29
不正解ア
利用部門とのかかわりを避けると、業務の実態や現場の要求そのものが入手できません。要求分析で必要なのは「客観性」の名を借りた情報遮断ではなく、利用部門からの十分なヒアリングです。関与を断つほど要件の欠落・誤りが増え、開発後に使えないシステムになります。
- イ
正解 要件定義は「利用部門が本当に必要としている業務要求」を、開発者が漏れなく正しい形にまとめる工程です。10年で業務内容が変化している以上、正解を知っているのは日々その業務を回している利用部門であり、開発者だけでは要求の抜け・誤解を検出できません。そこで、まとめたシステム要件を利用部門と一緒に読み合わせ、認識の食い違いや漏れをその場で洗い出す「共同レビュー」を行います。共同レビューは、要件の妥当性を早い段階で確認し、後工程での手戻り (仕様変更・作り直し) を防ぐための標準的な進め方であり、同時に利用部門の合意 (承認) を得る場にもなります。したがって「システム要件は、システム利用部門と共同でレビューを行う」とする「イ」が適切です。
不正解ウ
システム要件は利用部門の業務要求そのものなので、開発者が単独で決定してよいものではありません。利用部門の意見を「参考」扱いにすると、要件が実際の業務と乖離し、受入テストや稼働後に大きな手戻りが生じます。要件は利用部門と合意し、承認を得て確定させる必要があります。
不正解エ
現行システムの操作マニュアルは「今のシステムができること」を書いた資料にすぎず、10年間で変化した現在の業務要求は反映されていません。これだけを基に機能を決めると、現行システムの制約や不要になった機能をそのまま引き継ぎ、全面的な再開発の目的を果たせません。
ここがポイント
- 要件定義では利用部門 (発注側・業務の当事者) が主役であり、開発者は要求を引き出してまとめ、共同レビューで妥当性の確認と合意形成を行う。
- 共同レビューは開発の早い段階で要件の誤り・漏れを発見し、後工程の手戻りコストを下げるための手法である。
用語