「ガイド」における「要求の体系化」と「ビジネスアナリシス」A021

今回は「ユーザのための要件定義ガイド」P118の「4.2.1要求の体系化(BR.2.1)」について意見を述べたいと思います。

 

ガイドではまず、このように書かれています。

(1)要求全体の整合性を分析し評価する

 

【解決したい問題】

■抽出した要求が全体として効果的かつ必要十分なものになっていない

 •目的に合致しない要求が多くある

 •もっと効果的な手段がある。

 •膨らむ要求を捨てられない

要求の抽出結果には、各ステークホルダの思いが反映されることがある。それらは、経営者や業務部門長の思いと異なったり、目的を達成するための効果的な要求になっていなかったりすることがある。上位目的を意識したサブゴール(下位目的)の抽出や手段の抽出を行うようにと、前述のビジネス要求の獲得時に述べている。基本的な考え方は同じであるが、ここでは、抽出した要求全体を体系的に整理し全体としての整合性、十分性を再確認することを提示している。

 

勘どころ① 要求を構造化する

 

要求の構造は 「ビジネス要求の獲得」でも説明している。すべての要求を「目的」「手段」に区別して、経営レベルの要求から現場レベルの要求を関係付けて図4.14のように構造化する。

 

ガイドでは、「要求の抽出結果には、各ステークホルダの思いが反映されることがある。それらは、経営者や業務部門長の思いと異なったり、目的を達成するための効果的な要求になっていなかったりすることがある。上位目的を意識したサブゴール(下位目的)の抽出・・・(以下略)」と述べられていますが、このことが前提としているのは「要求の抽出行為が関係者からランダムに集められている」ことが前提になっています。

 

 

筆者は、2022401日のブログ「ステークホルダー」と「要件定義」と「ビジネスアナリシス」A015においてステークホルダーの抽出にビジネスアナリシス手法を用いて下記プロセス階層レベル(下記図1)に従って構造的にアプローチする方法を提案しました。これは、「要件抽出」についても同様(ステークホルダー以上)に当てはまります。

図1

 

要求は各階層から抽出されるのですが、図2のように階層が下がるごとにネズミ算的に数が増えて行きます。

図2

読者におかれてはもうお分かりだと思いますが、一旦ランダムに抽出された多くの要求をガイドの中の図4.14のように構造化し直すことは非常に困難であり、実際には不可能だと思います。

従って、要求抽出はビジネスアナリシス手法に従い、プロセス階層レベルの上位から開始し、下位に順次下がって行くトップダウン手順で実施することが肝要と言えます。下位レベルから要求を抽出するときには、その上位要求を伝えた上で、上位要求を充足するためにはどのような要求があるのかを抽出します。勿論、下位のレベルにおいては当該レベルでの固有の要求も当然あるので、上位要求からの流れの中で抽出する要求と、個別要求は分けて管理します。

 

ガイドでは次のように続きます。

勘どころ② 妥当性の観点から真の目的を見極める

 

「妥当性」とは、図4.14にあるように、構造を下から上に検証することである。下位の 「手段」や 「サブ目的」が上位の「目的」に対して妥当な要求になっているかということである。「手段」や 「サブ目的」が達成したい「目的」に対し効果を上げるものになっていれば妥当であると判断できる。例えば、図4.15左側に示すように、「コストダウンのために自動集計する機能を作りたい」という要求が上がったとする。この要求を目的と手段に分けると、「コストダウン」が目的であり、「自動集計する機能を作りたい」が手段ということになる。ここで目的と手段の関係を考える必要がある。「自動集計にした場合、従業員一人当たりの1日の作業時間 (人件費)はどのくらい削減できるか」と「自動集計を実現するために必要な投資金額」を数値化する。そして、双方の金額を比較して「投資に見合う目的か」を検討する。もし、目的が投資に見合わないのであれば、現場が 「自動集計する機能を作りたい」と主張した 本当の目的が違うところにないかを掘り下げる必要がある。例えば、以下のようなやり取りだ。

 開発側 「自動集計するとどれだけコストダウンするのですか」

 利用者 「毎日一人が3時間かけて実施していた作業が減ります」

 開発側 「一人のためですか?目的は他にありませんか」

 利用者 「集計データをいち早く顧客に提供できます」

 開発側 「早く集計データを提供すると、どんなメリットがあるのですか」

 利用者「(顧客の)機会損失が低減します。ひいては顧客満足度が向上します」

 

この検討結果を表現したものを図4.15に示す。

 

ここで問題になるのは、ランダムに抽出された(下位の)要求からその上位要求を見つけるという作業をすることになっている訳ですが、ランダムに抽出された要求の中から、ここに書かれた「開発側と利用者」のやりとりの対象とする要求を一つ一つ見つけ出す作業が必要になります。言うまでもなく、この抽出とトレース作業も実際に行うには大きな困難が伴ういます。

ビジネスアナリシス手法に基づき、上位要求から下位要求へ流れの中で抽出を行っていれば、こうした作業は「個別要求」として管理されているものに対して行えばよく実効性が高まります。

 

ガイドは更に以下のように続きます。

勘どころ③ 十分性の観点からより効果的な手段がないか検討する

「十分性」とは、図4.14にあるように、構造を上から下に検証することである。上位の「目的」に対し下位の「手段」や「サブ目的」が必要十分であるかということである。抽出された「手段」や「サブ目的」だけで「目的」を達成することができるか、「目的」を達成するために必要な「手段」や「サブ目的」がまだ不足しているのではないかを検証することである。

目的から手段を抽出することは、前述「「4.1.4手段の抽出 (1)目的・目標を意識して手段を抽出する」の「勘どころ 手段の十分性から他の手段がないか検討する」で述べているので、そちらを参照していただきたい。

 

この点についても、ビジネスアナリシス手法による上位要求からの構造的アプローチを採用していれば、要求抽出作業自体が十分性を検証しながら進められるので、後から上記の検討を行う必要がなく効果的だと考えます。

 

 

因みに、本節の最後に掲載されているサントリーシステムテクノロジー株式会社の「リザルトチェーン手法」でも、トップレベル目標(文中では「最終成果」)からスタートし階層構造的にシステム機能へ落とし込む手法が紹介されています。