地に足の着いた議論をするために

筆者が、この連載の中で一貫して強調しているのは、まず対象を"見える化"して、全体構造をつかみ、その上で課題箇所などを特定して、ロジカルにものごとを判断していくという"モデル中心アプローチ"である。

関係者を集めて議論するにしても、徒手空拳でやると、参加者がそれぞれに宙を見て自分なりのイメージを浮かべつつ議論しているような風景になってしまうことが多い。言葉の上ではやりとりが成立しているかに見えるものの、なんとなく地に足が着いた議論になっていない。果たして同じものを意識してのかみ合った話になっているのかどうか怪しいところである。

状況の認識が異なれば、それぞれの要求は必然的に異なったものになり、合意の形成は難しい。このような空中戦状態を地上戦に落とし込むためには、全体を見渡すための共通の地図を作って、その上で課題となる箇所を指さしての議論にすることである。

"見える化"すべき対象は、例えば、経営戦略や事業戦略、業務の構造、要求の構造、組織や関係者の構造、情報システムの構造など様々なものがある。それらに対して、戦略マップや業務フロー、概念モデル、要求分析ツリー、組織図、ステークホルダーリスト、UMLをはじめとするシステム関連のダイヤグラムなど、"見える化"するための道具立てがある。

検討を進める中でこうしたモデルを目的に応じて適用することで関係者間での共通認識が醸成できる。特にこうしたモデルを作成する過程を共有すると即効性が高い。

今回は「要求開発」で利用するモデルの中で筆者がもっとも重視している「要求分析ツリー」をとりあげる。

要求分析ツリーとは

前回、ユーザの要求を鵜呑みにしてはいけないという話をした。要求仕様をまとめていく過程は、ともすると、関係者の要求を集めて、それに優先順位づけをするという作業で済ませがちである。個々の要求は、個々人の視野と個々人の理屈で作られたものであるので、それに応えることが組織全体としての目的に叶うかどうかは保証の限りではない。そこでそれらの要求がどのように全体の目的に適合するのかを"見える化"する方法として要求分析ツリーを用いる(図1)。

例えば、「登録画面に在庫を確認する機能がほしい」という非常に具体的で現場担当者に身近な要求があった場合に、それには「受付担当者の業務簡素化をしたい」といったより上位の要求(目的)があるだろう。さらにそれは、「受付時の顧客へのサービス向上をはかりたい」あるいは、「人件費を削減したい」というもう一段上位の目的につながるものであり、最終的には企業としての最上位の目的であろう「利益の向上」に何かの形でつながっていなければならない。

システムは、業務の目的を果たすための手段であるから、システム要求が直接に利益に結びつくわけはなく、その間には必ず何段階かのビジネス的な要求が挟まっている。そうした最上位目的(企業の場合は「利益拡大」がわかりやすい)へのN段論法をツリー構造で表現してその意図を明らかにしたのが要求分析ツリーである。

上下の要求の間は、それぞれが「目的」と「手段」という関係を維持しながら連鎖しており、図で言えば、最も左にある目的を達成する手段を段階的にブレイクしていくと、右にいくに従ってより具体的な手段となり、あるものはシステムの機能要求に展開される。

図中では、システム的な要求を黄色に色分けして明示するようにしている。ヒアリングでユーザから聞かされるシステム要求は、だいたいこの末端のレベルに位置している。

前回述べたのは、これをそのままシステム化するのではなく、その上位目的や意図を確認しなければならないということである。上位目的がつかめれば、実は語られた手段ではなく、別の手段の方がその目的をより効率よく達成できるかもしれない。ユーザから得るべきは、彼らが出した答えそのものではなく、そういう答えを出した背景なのである。

要求分析ツリーは、「目的」と「手段」という関係を連鎖してつながっているという点では、BSC(Balanced Score Card)と考え方が似ているが、これによって戦略を作るというようなトップダウン的な使い方ではなく、主に末端に散在する個々の様々なレベルの要求を上位目的につないでいって、全体の要求の構造を理解しようというボトムアップ的な使い方を意図している。

要求分析ツリーで"見える"もの

要求分析ツリーの構造について、もう少し説明を加えると、図の左の列にはプロジェクトで掲げられている「課題」を配置する。

「課題」は、一般に「○○できない」などネガティブな表現であらわされるが、「要求」とは裏返しの関係にあり、「○○したい」とすれば「要求」の表現になるので、ツリー内の「要求」として配置し、それと関連付けることができる。

また、それに対する「解決策」がプロジェクト発足時に仮説的にあげられていることがあるが、ツリーの右端レベルにくるような具体的な要求(手段)を適度にまとめたものが、「解決策」に対応するものになる。右端の列にプロジェクトとしての「解決策」を配置すれば、それらもツリー内の複数の「要求」と関連付けることができる。

こうすると、プロジェクトが発足したときに掲げられている「課題」、「解決策」やすでに数々あがっている「要求」がどのように関連しているのかが一望できるものになる。筆者は、プロジェクトがスタートして間がない時期に、主要な関係者による短時間のセッション形式でこの要求分析ツリーを作成することをお勧めしている。これによって、プロジェクトでこれから相手にしていく対象がどのようなものなのか、その全体像を理解できるようになるだろう。

ここで特に重視したいのは、ツリーの「枝ぶり」である。根元は「利益の拡大」につながっているのだが、どのような文脈(戦略)を辿って利益を拡大しようとしているのかが、その「枝ぶり」に表れる。

例えば、「高額商品で客単価を増やす」のか、「原価を落として低価格路線で顧客数を増やす」のか、どちらの枝(戦略)を選択するかで採るべき手段は異なり、結果としてITが提供すべき機能も変わってくる。

同じ枝の広がりにつながっている要求ならば、レベルが異なっても同様のシナリオで利益に貢献しようとする要求だと見なすことができるし、枝が異なれば、その意図は一致していないことになる。要求分析ツリー内の要求は、図に示したように、階層の左側から右に向かって

• 経営的要求:　経営的視点で売上やコストといった財務的な指標に関連する要求
• 業務的要求:　業務を管理していく視点ででてくる業務オペレーションに関する要求
• 現場的要求:　現場担当者の視点で出てくる具体的で詳細な要求

のように、内容を大分類することができる。

"声の大きい人"に振り回されるの防ぐ

このようにヒアリングする相手の立場(経営者、管理者、現場担当者)によって要求のレベルや表現は異なってくるのだが、構造化して扱えば、その間で戦略が共有されているのかどうかを見てとることができる。

プロジェクトの推進中にも、様々な立場の人たちが新たな要求を思いつき投げかけてくるだろう。非武装のままこうした要求にさらされているとそのひとつひとつに振り回されることになる。特に偉い人や声の大きい人の要求は、他の要求を押しのけて、いきなりトッププライオリティになってしまったりする。

要求の全体構造が共有されていれば、その要求がその中のどのあたりに位置するのかを確認したうえで、「戦略に合った要求なのか」、「他の要求に比べてどうなのか」、「同等の意図をもった代替案はないのか」といったことを落ち着いてロジカルに検討することができる。

縦割りで仕事を進めていると、お互いの目先の利害は必ずしも一致せず、それぞれの立場を主張し合うだけの議論に陥りがちである。全体の地図が見えて、その中で戦略が共有され、各要求の意図が共通理解できて初めて、自部門の多少の不都合を超えて、全体最適に向けた大人の議論ができるようになるのである。いかにして共通の基準を構築するかがカギを握っている。

*　*　*

さて、この連載の各回で述べてきたことは、個別に上流コンサルのTIPSととらえていただくのでも結構ではあるのだが、これらはすべてシステム企画(要求開発)プロセスでの活動として、体系化された要求開発手法の一部をなしている。

企業のIT投資は、必要に迫られた単なるシステム化が一巡して、経営や業務へのより戦略性の高いITの組込みへと向かっており、「要求開発」はそのための中核技術に位置づけられる。この機会に、「要求開発」という領域にも興味をもっていただき、要求開発アライアンスへのアクセスなどにより、さらに知識を深められることをお勧めして、この連載を結びたい。

トレーニングは投資ではありません。
SAPエデュケーションでは、包括的なエデュケーション・サービスをご提供します。