「ビジネス要件」に関する誤解を解くプロジェクトで要件変更の発生を避けるには

要件定義が重要視されているにもかかわらず、プロジェクトでのクリープ（要件の変更）が発生するのはなぜか。その原因と対策を紹介する。

[Robin F. Goldsmith，TechTarget]

　ほとんどのプロジェクトでは、「要件のクリープ（確定したはずの要件の変更）」が発生する。クリープは、予算やスケジュールの超過を招く大きな原因であり、これらの問題はストレスやミスにつながるほか、評判を傷つけてしまう。では、どうすれば要件のクリープとその影響を避けられるのか。

　数十年にわたって要件定義が重要視されてきたにもかかわらず、クリープは依然としてプロジェクトトラブルのもととなっている。「システム分析」「構造化分析」「オブジェクト指向分析」「ビジネス分析」など、呼び名が何であれ、こうした「要件」分析手法は、要件定義を多少改善させただけであり、要件のクリープを大幅に減らすには至っていない。

　クリープが相変わらず発生しているのは、こうした従来のアプローチでは、わたしが「本当の」ビジネス要件と呼んでいる重要な要素が見落とされているからだ。おなじみの例を見てみよう。

ATMの例

　要件について講演したり書いたりする際に、ATM（現金自動預け払い機）を例に取り上げる人が驚くほど多い。そこでATMの例を独自に作る代わりに、わたしはそうした専門家が挙げる典型的な要件の一部をリストにまとめてみた。それによると、ATMは以下の要件を満たさなければならない。

• 顧客にカードの挿入を求める
• 暗号化されたカード番号とIDデータを磁気ストライプから読み取る
• 顧客にPIN（個人識別番号）の入力を求める
• 入力されたPINを、計算されたPINまたはファイル上のPINと照合する
• 預金か支払金を受領する
• 現金を10ドル紙幣で払い出す
• 選択された口座の残高を表示する
• 指定された金額を顧客の口座間で移動する
• 利用明細を発行する
• 顧客のカードを返却する

　尋ねると、ほとんどの人がこれらは要件だと賛成してくれる。

　これらが要件だとした場合、以下の項目はどうだろうか。

• 顧客が自分にとって便利な時間と場所で、安全に他人に知られずに銀行サービスを利用できるようにする
• 顧客の本人確認と口座照合を確実、迅速、簡単に行う
• 顧客が通常の銀行口座取引を迅速、正確、安全に行えるようにする
• 取引の際に、書面による取引の証拠を顧客に提供する

　後者の方が「本当の」要件だというのが、わたしの主張だ。これらはビジネスにおける成果であり、達成された場合に（要件として見れば、満たされた場合に）価値を提供する。こうしたビジネス要件とは、ユーザー、顧客、あるいはステークホルダーが求める要件だ。このため、以下ではこれらの言葉を「ビジネス」と同義に扱う。ビジネス要件は概念的なものであり、ビジネス環境の中に存在するため、発見しなければならない。「本当の」ビジネス要件を満たすために取り得る方法はたくさんある。

　これに対し、前者のリストは、実は製品やシステムの要件だ。こうした要件を満たすことで価値を提供できるのは、そうすることが、ユーザー、顧客、ステークホルダーが求める「本当の」ビジネス要件を満たす場合に限られる。

　ここで、よく聞かれそうな2つの質問にあらかじめ答えておこう。まず、「本当の」とカギカッコを使っているのは、記事の最終的な要件に従ってイタリックやボールド、下線を使わないようにフォーマットが変わっても、影響されない方法で強調して目立たせるためだ。最初の要件は一般的に、正確で完全なものになるまで見直しが加えられ、クリープのプロセスで必要と判断された追加や変更が行われたりする。

　次に、ユースケースを使っている人はユースケースとはユーザー要件であり、「ユーザー要件とは、ユースケースだと考えることが多い」とわたしは認識している。実際、ユースケースはユーザー要件やビジネス要件の記述に利用できるフォーマットだ。だが、ユースケースでは一般に、製品やシステム、ソフトウェアの想定される使い方が記述されている。

関連ホワイトペーパー

バイオメトリクス認証 | オブジェクト指向 | プロジェクトマネジメント | 品質管理 | システムトラブル