Part2　4種類の要求を区別する

　今回は、BABOKで示された要求についての考え方を紹介しよう。前回は一貫して「要求」という言葉を使ってきたが、「要件」という類似の言葉もある。みなさんの現場では、これらの言葉を使い分けているだろうか。筆者の場合、二つの言葉に次のような意味を持たせて使い分けている。

　「要求」は、利用部門などから出てきた整理されていないあいまいな要望（単に要望ということもある）、もしくは、その要望を利用部門などが自ら整理したものだ。そこには主観的な思いが入っている。それに対して「要件」は、利用部門に属さないITエンジニアなどの第三者が、要求を客観的に分析し取りまとめたものである。

　これは筆者の考え方であり、異なるイメージを抱いている人もいるだろう。実際に、筆者が関係したプロジェクトでは、メンバーによって異なる意味で要求と要件を使うケースがあった。さらに、二つの言葉を区別せずに使うメンバーがいたこともある。

　そんな状態ではコミュニケーションミスが発生し、プロジェクトが混乱を来すことになる。例えば、利用部門の担当者が思いつきで要求を挙げてきたとき、1人のITエンジニアが「“要件”が追加された」と報告したとする。それを伝え聞いた別のITエンジニアは、客観的に分析した上で取りまとめられた要件が追加されたのだと勘違いし、影響範囲の調査を始めたり要件定義書を修正したりする、という具合だ。

　これはやや極端な例だが、要件定義までの上流工程では、要求や要件といった言葉で表される概念を混同することなく、プロジェクトチーム全体で明確なイメージを共有した上で、使い分ける必要がある。

4種類の要求を区別する

　BABOKでは、要件という言葉を使わず、「要求（Requirements）」で統一している。その代わりに、「優先順位付きの（Prioritized）」や「承認された（Approved）」という形容詞を付けて区別している。承認された要件定義書に記述されたものであれば、「承認された要求」と表すわけだ。こう表現すれば、誤解を生まないだろう。

　さらに注目したいのは、要求を「ビジネス要求」「ステークホルダー要求」「ソリューション要求」「移行要求」の4種類に分けて整理したことである（表1）。どの要求にも、「優先順位付きの」や「承認された」といった形容詞を付けることができる。

表1●BABOKにおける要求の体系

BABOKでは要求を、「ビジネス要求」「ステークホルダー要求」「ソリューション要求」「移行要求」の大きく四つに整理している。ビジネス要求やステークホルダー要求を具現化する「ソリューション」の基になるのがソリューション要求と移行要求、という関係である。この表の「内容」と「具体例」は、分かりやすさを重視して、BABOKの定義ではなく筆者の言葉を用いて表現した

[画像のクリックで拡大表示]

　一つ目のビジネス要求は、組織全体としてのビジネス目標、ビジネスニーズなどを示したものである。例えば、「来年度の第1四半期末までに、販売管理業務のコストを2割削減したい」といった具合だ。これはエンタープライズアナリシスの活動で定義する。

　このビジネス要求を踏まえて、利用部門などのステークホルダーが個別に出してくる要求が、ステークホルダー要求である。「販売管理担当者の人員削減は、1割にとどめたい」「取り扱い品目の変更に伴う作業の手間を減らしたい」といったものだ。これを定義する活動は要求アナリシスである。

　ビジネス要求とステークホルダー要求を具現化するのに必要となる、組織・業務・システムが実現すべきものが、ソリューション要求だ。これはさらに「機能要求」と「非機能要求」に分けられる。機能、非機能の分け方は、ITエンジニアの方にとって馴染みがあるだろう。機能要求は、「すべての社内システムの品目マスターを、一括変更できるようにしたい」のように機能そのものに言及したもの。一方の非機能要求は「毎週月曜日の朝9時に、前日まで1週間分の売り上げや在庫のデータを分析できるようにしたい」という具合で、キャパシティ、性能、セキュリティ、可用性、ユーザーインタフェースなどの機能以外に関する要求である。これらも要求アナリシスで定義する。

　ソリューション要求の裏に隠れているのが、「移行要求」である。これは、現状からあるべき姿への移行を円滑に進めるために、ソリューションが満たすべき条件を意味する。例を挙げると、「今年度の第3四半期中に組織の体制を見直し、第4四半期に新しい業務とシステムを試行する」といった具合で、スケジュールに関することが多い。この移行要求は、ソリューションのアセスメントと妥当性確認で定義する。

逐次参照し、従来のやり方を改善

　最後に、現場におけるBABOKの活用法について触れたい。

　ITエンジニアにとってBABOKで最も重要なのは、全体構成を把握することだと思う。全体構成を頭に入れた上で、実際に要件定義までの上流工程を進めるとき、自分やチームメンバーが担当している作業は、BABOKのどのタスクに該当するのかを考える。そして逐次、BABOKの内容を参照し、そのタスクを行うにはどんなインプットがそろっていなくてはならないか、どういうテクニックが有効か、注意点は何か、どんなアウトプットを作成するか、どういうタスクに引き継ぐか──といったことを明確にする。そうして、ソリューション企画や要件定義などのやり方を改善していくといいだろう。

　その際、従来のやり方では、BABOKのどのタスクを実施していなかったのかを調べるのもお勧めである。実施していないタスクを付加することが、要件定義までの上流工程の改善につながる。

　ただしプロジェクトごとに、BABOKで定義しているタスクのすべてを行う必要はない。BABOKは、さまざまなケースを想定した汎用的な知識体系である。つまりプロジェクトによっては、あまり必要のないタスクも存在する。実情に合わせて、実施すべきタスクを取捨選択したい。