要件定義の目的

現在プロジェクトマネジメントを実作業でやっているので、気がついたことを備忘録として少しずつメモしていきます。
当たり前のことも、敢えて１つ１つメモしていきます。
※当たり前のことでも、一度書くか書かないかで、理解度が変わるんです！（by Ｊカビ）

目的

要件定義の目的は、「システム化する範囲」（スコープ）を決め、「ユーザと合意する」こと。

スコープとは？

ユーザは、システム化するか否かに関係なく、「何かしたいこと」というものがあります。
ビジネス的な価値を生む「何か」をしたいと考えています。
ここでは、この「何か」を「ビジネス要件」と呼称します。

一方、ベンダとしては、その「ビジネス要件」をシステム化することを生業としますが、何でもシステム化すればよいというものではない。
要件によっては、システム化しない方がよいものもあります。
なので、「ビジネス要件」のうち、どれをシステム化するかを決めなければいけません。
「ビジネス要件」のうちでシステム化する範囲のことを、「スコープ」と呼称します。

「スコープ」と「ユースケース」の違い

オブジェクト指向開発手法などでは、ユーザに提供する価値ということで、システム化する範囲・システム化する要件のことを「ユースケース」と呼称します。

以下は私の個人的意見ですが、「スコープ」はマネジメントの視点から見た「管理対象」としての範囲、「ユースケース」は開発者の視点から見た「開発対象」としての要件、という違いがあると思っています。
意味は同じだけれども、視点が違うのだと認識しています。

ユーザとの合意

つい開発者としての経験が強いと、スコープをベンダ側で決めて、ユーザにＯＫさせればよいと考えがちなのですが、それではユーザが「押しつけられたもの」と認識し、関係が悪化することがあります。
そもそも、「ユーザがやりたいこと」をシステム化するための範囲を決めることなのですから、ユーザがＯＫしないものはＮＧですよね。
また、ユーザとの合意ができていないと、後で要件を「ひっくり返され」、スケジュールがタイトになったり、マネジメントが難しくなったりします。
あくまで、「ユーザと合意」することが必要です。

【今回の参考文献】

『日経SYSTEMS』２００９年７月号、「アンチパターンで習得する上流工程テクニック」を参考にさせていただきました。