ほとんどのプロジェクトでは、「要件のクリープ(確定したはずの要件の変更)」が発生する。クリープは、予算やスケジュールの超過を招く大きな原因であり、これらの問題はストレスやミスにつながるほか、評判を傷つけてしまう。では、どうすれば要件のクリープとその影響を避けられるのか。
数十年にわたって要件定義が重要視されてきたにもかかわらず、クリープは依然としてプロジェクトトラブルのもととなっている。「システム分析」「構造化分析」「オブジェクト指向分析」「ビジネス分析」など、呼び名が何であれ、こうした「要件」分析手法は、要件定義を多少改善させただけであり、要件のクリープを大幅に減らすには至っていない。
クリープが相変わらず発生しているのは、こうした従来のアプローチでは、わたしが「本当の」ビジネス要件と呼んでいる重要な要素が見落とされているからだ。おなじみの例を見てみよう。
要件について講演したり書いたりする際に、ATM(現金自動預け払い機)を例に取り上げる人が驚くほど多い。そこでATMの例を独自に作る代わりに、わたしはそうした専門家が挙げる典型的な要件の一部をリストにまとめてみた。それによると、ATMは以下の要件を満たさなければならない。
尋ねると、ほとんどの人がこれらは要件だと賛成してくれる。
これらが要件だとした場合、以下の項目はどうだろうか。
後者の方が「本当の」要件だというのが、わたしの主張だ。これらはビジネスにおける成果であり、達成された場合に(要件として見れば、満たされた場合に)価値を提供する。こうしたビジネス要件とは、ユーザー、顧客、あるいはステークホルダーが求める要件だ。このため、以下ではこれらの言葉を「ビジネス」と同義に扱う。ビジネス要件は概念的なものであり、ビジネス環境の中に存在するため、発見しなければならない。「本当の」ビジネス要件を満たすために取り得る方法はたくさんある。
これに対し、前者のリストは、実は製品やシステムの要件だ。こうした要件を満たすことで価値を提供できるのは、そうすることが、ユーザー、顧客、ステークホルダーが求める「本当の」ビジネス要件を満たす場合に限られる。
ここで、よく聞かれそうな2つの質問にあらかじめ答えておこう。まず、「本当の」とカギカッコを使っているのは、記事の最終的な要件に従ってイタリックやボールド、下線を使わないようにフォーマットが変わっても、影響されない方法で強調して目立たせるためだ。最初の要件は一般的に、正確で完全なものになるまで見直しが加えられ、クリープのプロセスで必要と判断された追加や変更が行われたりする。
次に、ユースケースを使っている人はユースケースとはユーザー要件であり、「ユーザー要件とは、ユースケースだと考えることが多い」とわたしは認識している。実際、ユースケースはユーザー要件やビジネス要件の記述に利用できるフォーマットだ。だが、ユースケースでは一般に、製品やシステム、ソフトウェアの想定される使い方が記述されている。
動画の重要性 「増している」が85% 動画コンテンツの内製化率は前年比倍増――アライドアーキテクツ調査
アライドアーキテクツが「企業のDX推進における動画活用の実態調査 2021」を実施。デジタ...
これもアマゾンエフェクト? 米国で激減するあの人名の話
マーケターの頭の片隅を刺激するトピックをインフォグラフィックスで紹介。
電通「2020年 日本の広告費」 総広告費は大幅減でもインターネット広告費は成長を維持
2020年の日本の総広告費は6兆1594億円で前年比88.8%。東日本大震災があった2011年以来9...