TechTargetジャパン
ERP
ERP
事例
プロジェクトで要件変更の発生を避けるには

「ビジネス要件」に関する誤解を解く

プロジェクトで要件変更の発生を避けるには

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

公開 2009年07月07日 07時30分

更新 2012年09月04日 17時58分

著者

Robin F. Goldsmith

[TechTarget]

印刷する Googleで優先するソースとして追加

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

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

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

ATMの例

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

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

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

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

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

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

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

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

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

クリープの2つのシナリオ

　ATMのケースで、前者のリスト項目をすべて満たしているが、後者のリスト項目は満たしていないということがあり得る。この場合、そのATMは価値を提供しない。そこで失敗を克服しようと追加要件が定義され、この事態はクリープと呼ばれることになる。そのプロセスは決まって試行錯誤となり、一般には明確に表現されていない「本当の」ビジネス要件を満たすことで価値が提供されるまで、製品の機能追加が繰り返し試みられていく。多くのプロジェクトでは、この種のクリープは一般的な反復型開発の過程の中で発生する。そのために、クリープと見なされないかもしれない。

　少し違うシナリオも考えてみよう。われわれが開発した、前者のリストの要件を満たすATMシステムを顧客が承認したとする。その後この顧客が、例えば指紋や網膜のスキャンによる生体認証（バイオメトリクス）機能をATMに搭載することを要求する。これは典型的なクリープといえる。開発チームメンバーからは、「要件は確定済みだと思っていたのに、ここにきて大幅に変わった」という声が上がるだろう。この種の機能追加を行う場合、最初からその機能が必要なことが分かっていた場合と比べて、ずっと多くの時間と費用が掛かるのは間違いない。

　どちらのクリープも一般的に、絶えず変化するビジネス環境に原因があるとされる。率直に言って、「変更もクリープも避けられない」とあきらめているケースが多い。要件を確定させることはできないというこの前提は、開発方法論の「ベストプラクティス」とされているものの一部のベースになっている。しかし、その内実は、要件を発見することを放棄し、変更とその結果としてのクリープを自ら招いているにすぎない。

　ここで指摘しておきたいのは、「本当の」ビジネス要件は、それを満たそうとしてわれわれが考えるものとまったく同じだということだ。実際、「本当の」ビジネス要件を明確に特定していれば、製品設計にばかりこだわるのではなく、多方面に目配りできていたかもしれない。その中にはバイオメトリクスも含まれる。バイオメトリクスは、「顧客の本人性と口座を確実、迅速、簡単に確認する」ことを可能にするものだからだ。

要件のクリープの原因

　要件に関するほとんどの書籍でも一般的な言葉の使い方でも、要件として言及されているのは「製品の要件」だ。多くの場合、「要件」とだけ呼ばれているが、「製品の要件」「システムの要件」「ソフトウェアの要件」「機能的な要件」（これに対応する「非機能的な要件」）と明確に表される場合もある。時には、実際は製品の要件を指しているのに、「ビジネス要件」とされていることもある。

　広く受け入れられている従来のモデルでは「ビジネス要件」という言葉を使うものの、この場合のビジネス要件は「詳細度や抽象度の違いにかかわる言葉」と思われているにすぎない。つまり、従来のモデルでは、ビジネス要件は抽象度の高い、あいまいなもので大抵は目的と考えられている。これが詳細な製品要件に分解されるというわけだ。このため、詳細な要件があれば、それは製品の要件と見なされ、抽象度の高いあいまいな要件があれば、それはビジネス要件と見なされる。

　通説では、クリープは十分に明確でない、あるいは十分にテスト可能でない（製品の）要件に起因するということになっている。通常、テスト可能性の欠如は、その明確さの欠如が原因だ。だが、明確さとテスト可能性は重要ではあるものの、クリープの多くは製品の要件がその明確さやテスト可能性の度合いにかかわらず、「本当の」ビジネス要件を満たしていないために発生する。また、「本当の」ビジネス要件が適切に定義されていないという問題もある。

　“何が必要となるのか”という「本当の」ビジネス要件が分かっていなければ、“どのように実現するか”という製品の要件をいかに詳細に規定しても補うことはできない。要件のクリープを避けるには「『本当の』ビジネス要件は、抽象度の高いあいまいなものではなく、詳細に定義しなければならない」ことを理解することが肝心だ。

　「本当の」ビジネス要件は製品の要件に分解されるわけではなく、両者は質的に異なっている。「どのように」という方法や在り方は「何を」という目的によって規定される。「いつ」「何を」が適切に定義されていなければ、「どのように」は仮定を根拠にするしかない。これに対し、詳細な「本当の」ビジネス要件は製品の設計にマッピングされ、その設計においてはクリープはまず発生しない。

モデルを変える

　従来の要件管理の方法論は、ユーザー、顧客、あるいはステークホルダーの要件を把握する必要性を認めており、方法論によってこうした要件に対処できると想定しているといえるだろう。しかし、要件のクリープは依然として発生しており、それは従来のモデルには「ユーザーの目的が、われわれが作れる製品の詳細要件に分解される」という間違った思い込みがあるからだ。

　このため、要件定義のための最も一般的な質問（「何を求めているか」）は、実はステークホルダーに自分のニーズを満たすであろう製品を記述・設計するよう促すことになる。このように「どのような製品が必要か」という観点が前面に出ると、目指すべきビジネス成果、つまり、製品が価値を提供するために達成しなければならないビジネス成果を適切に発見する妨げになる。また、こうした観点が前面に出ると顧客ニーズの掘り下げが浅くなりやすく、顧客の協力を得る妨げになり、かえって反発を買うことになりがちだ。これも、価値の提供につながるビジネス成果の発見を困難にする。

　こうしてクリープが発生してしまうが、皮肉にも、それが結果的に「本当の」ビジネス要件の発見につながることもよくある。これまで見てきた現状を踏まえつつ次の3つの方法を利用することで、非常に効率の悪いクリープの試行錯誤の多くを避けることができる。

適切なモデルを採用することで「本当の」ビジネス要件の発見に当初から取り組むことができ、クリープの結果としてこうした要件を模索することを迫られるという回り道をしないで済む
ビジネスについて学習するとともにビジネス担当者への観察眼を磨けば、ニーズを彼らの視点から理解するのに役立つ
強力な「問題ピラミッド」ツールを、問題、影響金額、原因、ビジネス要件（問題を解決して価値を提供するための）を直接かつ正確に特定するのに役立てることができる

　われわれは通常、詳細な「本当の」ビジネス要件を製品の機能にマッピングし、この機能がこれらの要件を満たして価値を提供できるようにすることで要件のクリープを回避できる。

本稿筆者のロビン・F・ゴールドスミス氏は法学博士で、1982年からコンサルティング会社Go Pro Managementの社長。ビジネスおよびシステム担当者向けに要件分析、品質保証・テスト、ソフトウェア調達、プロジェクト管理・統括、定量評価、プロセス改善、ROIに関するコンサルティングと研修を提供している。方法論の「Proactive Testing」と「REAL ROI」を開発。近著に「Discovering REAL Business Requirements for Software Project Success」（Artech House Publishers刊）がある。

印刷する

この記事の著者

Robin F. Goldsmith

プロジェクトで要件変更の発生を避けるには

ATMの例

クリープの2つのシナリオ

要件のクリープの原因

モデルを変える

この記事の著者

関連記事

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

プロジェクトで要件変更の発生を避けるには

ATMの例

クリープの2つのシナリオ

要件のクリープの原因

モデルを変える

この記事の著者

関連記事

プロジェクトマネジャーはCEOの最良の友

ソフトウェアのプロジェクト管理に「実験」の余地を

【Q＆A】ソフトウェア開発における効果的な顧客コミュニケーション

ITプロジェクトはなぜ失敗するのか

プロジェクトマネジャーに贈るプロセス改善事例

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓