前回のコラムでお伝えしたのですが、PMBOK第7版ではプロジェクトマネジャーが価値にまで責任を持つべきと書いてありますが、価値の多くはプロジェクト終結後に発生するので、その価値にプロジェクトマネジャーが責任を持つのはなかなか難しいことではないでしょうか。

さらに終結後の価値を評価する方法（もしくはプロセス）には何も触れられていませんね。PMBOKですからプロジェクト終結後のことが記述されないことは仕方ないですね。さらにこれではプロジェクトマネジャーが価値に責任をもつことは到底無理と言わざるを得ないのではないでしょうか。

一方、ビジネスアナリシス知識体系（BABOK）では、プロジェクト終結後の実現価値を明確にし、不測（価値の実現がされていない）場合の対処方法までしっかりと記述されているので紹介したいと思います。

BABOKガイドの「ソリューション評価」という知識エリアがそれに該当します。

こと知識エリアには次の5つのタスクがあります。

• ソリューションパフォーマンスを測定する
• パフォーマンス測定結果を分析する
• ソリューションによる限界を評価する
• エンタープライズによる限界を評価する
• ソリューションの価値を向上するためのアクションを推奨する

5つのタスクを順番に解説します。

1.　タスク「ソリューションのパフォーマンスを測定する」

まず、測定項目を決める必要があります。
ビジネス・ゴール、目標、ビジネス・プロセスなどから測定項目を作成します。
意外と日本でなじみが薄いのがビジネス・プロセスのパフォーマンス目標です。BPMなどを利用してビジネスプロセスの改善が叫ばれていますが、ワークフローの順番などの改善が主でプロセスを計測しているのをあまり聞いたことがありません。ビジネスプロセスを改善するのにプロセスのパフォーマンス（実行時間やTATなど）を測定することが必須なのです。
有名な格言に「測定できないと改善できない（If you can’t measure it, you can’t improve it）」がありますが、日本の多くの企業ではDX（デジタルトランスフォーメーション）はまだまだ先の話のようです。
サンプルサイズ、頻度、鮮度などを考慮しながら測定結果を収集します。（詳細は省略）

アウトプットの測定結果は次の「パフォーマンス測定結果を分析する」タスクに渡されるのみならず「現状を分析する」タスク（知識エリア：戦略アナリシス）にも渡されることがあります。
これは、現行のソリューションの欠陥改修などのスモールプロジェクトの最初のインプットとして使われる場合、また作成したソリューションのパフォーマンスが期待を満たしていないためさらなる追加作業が必要な場合にも使われます。

2.　タスク「パフォーマンス測定結果を分析する」

パフォーマンス測定結果がそのままソリューションの価値に関する決定につながることはめったにありませんので、測定結果の意味するところを解釈（データ分析）することが重要です。
ソリューションのパフォーマンスの良し悪しと価値の大小は直接関係しないものです。
この時、測定結果を知識エリア「戦略アナリシス」で作成された「潜在価値」をレファレンスとしてと比較します。
潜在価値に見合うパフォーマンスが出ていれば良いのですが、そうでなければ．．．、次のふたつのタスクでそれを評価します。少しお待ちください。
そのために得られた測定結果（データ）をもとに潜在価値と比較します。単純な場合はQ C７つ道具のヒストグラム、管理図、散布図程度でも結構です。複雑になれば、必要に応じて傾向分析、回帰分析（最小二乗回帰）などのデータ分析も行ないます。そのためには測定結果が正確で信頼できるものでなければいけません（当たり前ですが）。

アウトプットの分析結果をソリューションの立場とソリューション以外（主にエンタープライズ側）の2つの視点で評価します。それが次の２つのタスクです。

3.　タスク「ソリューションによる限界を評価する」

手短に言えば（ITシステムの場合）欠陥のアセスメントそのものです。欠陥数（1000ライン当たりまたはファンクションポイントあたり）、欠陥の深刻度、再発可能性等です。そしてビジネスへの影響も評価します。修正が必要か、ワークアラウンドで回避できるのか、許容範囲なのかを判断します。

この結果（タスクのアウトプット）は「ソリューションのパフォーマンスを測定する」タスクのアウトプット同様に「現状を分析する」タスク（知識エリア：戦略アナリシス）にも渡されることがあります。

このタスクはプロジェクト（出荷前）に行うテスト担当者の作業ではなく、主に運用時にビジネスアナリストが行います。運用時の場合、プロジェクトマネジャー同様にテスト担当者（プロジェクトメンバー）も解散していません。

4.　タスク「エンタープライズによる限界を評価する」

このタスクでは、ソリューション以外の問題をアセスメントします。

インプットに「現状の記述」があることが重要です。そしてこの現状は「戦略アナリシス」で宣言しているように「チェンジの開発および実装が行われている間、エンタープライズの現状が変わらずにいることはほとんどない」つまりプロジェクト開始時点ではなく、運用時での「現状」なのです。この変化の激しい状況では数カ月前に記述した「（旧い）現状」はほとんど意味がありません。ソリューションを評価する時点での「現状」がインプットとなります。

この知識エリアで最も重要なことはプロジェクト開始時点で定めたビジネス価値を単純に実現しているのかを求めるのではなく、外部・内部環境が変化してしまっている状況においてもビジネス価値を確保するための仕組みになっているということです。

的（マト）に狙いを定めて砲弾をうち、単純にどれだけ的の中心に当たるのかを競うのではなく、的そのものが動いているのです。その動く標的を追尾しながら標的に当てることです。
すなわち、単純な大砲ではなく、最新鋭の（追尾機能を備えた）ミサイルのようなものです。

ですからこのタスクのアウトプットも「現状を分析する」タスクにも使われます。

このタスクは次の様なことを行います。

• 組織文化のアセスメント：人がエンゲージされているのか、組織文化がチェンジを受け入れられる状態なのか
• 組織構造（公式、非公式）がチェンジに適切なのかのアセスメント
• 運用のアセスメント：　人事管理、スキルとトレーニング、ツールとテクノロジーは適切に配備されているのか

アウトプットの多くは「現状を分析する」タスクへのインプットとなります。

5.　タスク「ソリューションの価値を向上させるアクションを推奨する」

このタスクでは推奨案を作成します。

「何もしない」という推奨案もあります。十分に価値が実現されている場合や、チェンジをする労力・コストに比べてチェンジの価値が見合わない場合です。ソリューションに関係するチェンジへの態度、認識、関与をマネジメントするために組織的変革を推奨することもあります。

ソリューションが陳腐化すれば、ソリューションの廃止・リプレースを推奨します。

価値を実現するためには事前に正しくビジネス価値を定義することのみならず、外部・内部環境（現状）が変化する状況においても価値を確保する仕組みになっていることが極めて大切です。

新しいプロジェクトマネジメント知識体系第7版には価値実現が最も重要と謳っていますが、残念ながらプロジェクトは価値を所与の条件として受け入れることでしかなく、それを実現する仕組みがまだ完全ではないようです。価値実現を確実にするためにはビジネスアナリシスの知識体系が補完することになるのではないでしょうか。

ご存知だと思いますが、PMBOK（プロジェクトマネジメント知識体系）が第7版になりました。

内容は従来（第6版）までの知識エリア・プロセス中心の記述から大きく変わり、原理・原則の基づいた知識体系になりました。そのためかなり戸惑う人が多いのではないでしょうか。その原理・原則は13個あります。

従来のPMBOKガイドでは、成果物（プロセスのアウトプットとして）に焦点を当てていましたが、第7版では成果物よりも価値提供に焦点を当てています。
すなわち価値提供に焦点を当てることで、現代のプロジェクトを取り巻く複雑性や変化に対応し、真に成功と言えるプロジェクトを実現しようとしているわけです。
原理・原則のなかで、最も重要なのは「価値に焦点を当てる」ことです。
ただ、価値は通常プロジェクトが完了してから発生するものなので、その価値の実現にプロジェクトマネジャーが責任を持つことは難しいのではないでしょうか（特にウォーターフォールの場合）。

そこにはビジネスアナリストの関与が不可欠なことが示唆されます。プロジェクトマネジャーが退任した後に価値の実現を確認できるのはビジネスアナリストの存在が不可欠になります。

言い換えると、PMBOK第7版では、プロジェクトの成功（すなわち価値実現）にはビジネスアナリシス（またはビジネスアナリスト）との協働がより重要になったと言えるのではないでしょうか。

PMBOK第7版における価値の意味を深堀りすることでビジネスアナリシスとの協働の重要性を確認してみます。

PMBOKで、「多くのプロジェクトがビジネス・ケースに基づいて立ち上げられる。」と明記されているのでお分かりのように、プロジェクトはビジネスケースからスタートします。そのビジネス・ケースを作成するのは実はビジネスアナリストです。これはビジネスアナリシスの立場および欧米のプロジェクトマネジメントでは当たり前のことですが、日本のPMBOKの読者（PMP資格保持者）の多くはこの辺の事情をあまりよくご存じないかもしれません。PMBOKに書かれていることすべてをプロジェクトマネジャーが行うものだと誤解しているかもしれません。

また、「プロジェクトの正当性はビジネス・ニーズとつながっている」とビジネス・ニーズの重要性を強調していますが、これも実はビジネスアナリストが定義するものです。ビジネスアナリシス知識体系（BABOK）第3版では、「ビジネス・ニーズとは、エンタープライズが直面する、戦略的に重要な問題または機会である。」、「ビジネス・ニーズの定義は、多くの場合、あらゆるビジネスアナリシス作業の中で最も重要なステップである。」と明言しています。すなわちビジネスアナリストがビジネス・ニーズを正しく定義することがプロジェクトの正当性につながるわけです。

すなわち、ビジネスアナリシスの立場でもビジネス・ニーズの定義は最重要で、それを明確にしてビジネス要求が作成され、成功要因等を追加明記してビジネス・ケースというドキュメントを作成します。プロジェクトは、ビジネスアナリストが作成したビジネスケースを基にプロジェクト憲章が作られそれからプロジェクトがスタートするわけです。

これだけ見ても、あたらしいPMBOK（第7版）はその裏にビジネスアナリシスの影響が極めて大きいことがお分かりいただけれると思います。ビジネスアナリストがビジネス・ニーズを定義しない限りプロジェクトは開始しないのです。

• プロジェクト・スコープ・マネジメント
• プロジェクト・タイム・マネジメント

 知識エリア：　5．プロジェクト・スコープ・マネジメント：（続き）

 今週は「5.4　WBS作成」を取り上げますが、その前に、プロジェクトのフェーズについて簡単に振り返ります。

PMBOKガイド第5版2.4.2ではプロジェクト・フェーズについて解説があり、その中で「予測型ライフサイクル」（つまりウォーターフォールのこと）があります。

　要件定義　→　実現可能性　→　計画策定　→　設計　→　建設　→　試験　→　引渡し

「それぞれのフェーズではプロジェクト・アクティビイティやプロジェクトマネジメント・プロセスのサブセットに焦点を当てている。」（PMBOK第5版）となっています。

BABOKでもこのフェーズの考え方は重要です。ただ誤解しがちなので注意していただきたいことはBABOKの知識エリアはプロジェクトのフェーズとは関係ないことです。「エンタープライズアナリシス」「要求アナリシス」という知識エリアの名称はフェーズを意味しているものではありませんのでご注意ください。

例えば、ウォーターフォール型のフェーズとして下記のように考えてみましょう。実際の例に近いと思います。

• ビジネス分析フェーズ（ビジネス環境を分析しビジネス要求からビジネスケースをまとめます）
• 業務分析フェーズ（業務を分析し、業務フロー、ステークホルダー要求をまとめます）
• システム要求フェーズ（業務要求から、システムへの要求を作り上げます）

など
これらのフェーズを例にして、「WBS作成」そしてプロジェクト・タイム・マネジメントを解説していきます。

PMBOK第5版　5.4　WBS作成

インプットで重要なのは当然「要求事項文書」で、その内容は先号で解説したように、ビジネス要求事項、ステークホルダー要求事項、ソリューション要求事項などです。

これらのインプットからアウトプット「スコープ・ベースライン」を作成するのですが、なかなかピンとこないのではないでしょうか。PMBOKだけでこのWBSを考えるのは少し難しいと思います。

そこで、関連するビジネスアナリシス/BABOKのタスクを見ていきます。それは知識エリア「計画とモニタリング」の「2.3ビジネスアナリシスのアクティビティを計画する」タスクです。

[図のクリックで拡大表示]

この図の解説（左側の真ん中）にあるように、この計画タスクは、

• ビジネスアナリシスの成果物を識別し、
• BA活動の作業スコープを決め、
• ビジネスアナリストがどの活動をいつするかを決定し、
• ビジネスアナリシスの作業を見積もります。

[図のクリックで拡大表示]

そして、アウトプットは「ビジネスアナリシス計画（2.3）」と言いますが、その中味は

• 作業スコープ
• 成果物WBS
• アクティビティリスト
• 各活動と各タスクの見積り　　です。

このタスクの要素（中央のコラム）の4番目を注目してください。

.4　ビジネスアナリシスのアクティビティの決定
WBSを活用する
ワークパッケージ、アクティビティリスト
－成果物ベースのWBS
－フェーズ、反復、リリース毎に成果物、活動、
タスクを特定する

とありますから、先ほどのフェーズの例を考えます。

• ビジネス分析フェーズ
• 業務分析フェーズ
• システム要求フェーズ

とした場合、フェーズごとの成果物として下図のようなものが考えられます。

成果物もしくはワークパッケージとして、

ビジネス分析フェーズ成果物としては、

• ビジネスニーズ
• 前提条件
• 必要な能力、．．．

などがあります。

[図のクリックで拡大表示]

業務分析フェーズでは、

• 業務フロー図
• 業務一覧
• ビジネスルール一覧、．．．など

となります。

PMBOKのプロセス「5.4WBS作成」のイメージがわいてきたのではないでしょうか。

続いてプロジェクト・タイム・マネジメントを簡単に解説します。

プロジェクト・タイム・マネジメント：

フェーズごとに各成果物WBSに関してそれを作成するためのアクティビティをまとめます。この際に、フェーズ、成果物、アクティビティ（さらにその下のタスク）を次の図のような構造にまとめると便利です。

上記成果物を作成するためのアクティビティをリスト化しますから、具体的には次の図のようなアクティビティが考えられます。

2番目の「業務分析フェーズ」でのアクティビティと成果物の関係は次の図のようになります。

このように、成果物をアクティビティにつなげていけばよいのです。

さらに、アクティビティの詳細は下位レベルをタスクとして定義することもできます。

アクティビティ「ビジネスルールの識別」の下位には次の2つのタスクがあります。

• ビジネスルールの収集
• ビジネスルールの文書化

アウトプットのビジネスルール一覧を作成し、また業務フロー図にも「ビジネスルール」を追加します。

必要に応じて、タスクをさらに下位のサブタスクに分解することも可能です。

少し早足でしたが、プロジェクト・スコープ・マネジメントとプロジェクト・タイム・マネジメントに関してBABOKとの関連を解説しました。
プロジェクトにおいて、超上流工程を実施するためには、BABOKの知識エリア/タスクが不可欠なことがお分かりいただけましたでしょうか。

長くなりましたので、連載はいったんこれにて休止とさせていただきます。

長らくのご愛読に感謝申し上げます。
尚、今号の解説で使用した図は弊社「要求プロセス基礎」コースの一部です。本コースの詳細につきましては、下記URLのWebページのコースカタログをご覧ください。

http://kbmanagement.biz/wordpress/?page_id=275

• プロジェクト・スコープ・マネジメント
• プロジェクト・タイム・マネジメント
• プロジェクト・コミュニケーション・マネジメント

最初のプロジェクト・スコープ・マネジメントを見ています。

知識エリア：　5．プロジェクト・スコープ・マネジメント：

今週は「5.2要求事項収集」を取り上げます。

5.2　要求事項収集

このプロセスはPMBOKの歴史の中でも比較的新しいプロセスで第4版から登場しました。そして最新の第5版ではその内容、インプット、アウトプットが大きく変わっています。

まず、第4版の「5.1要求事項収集」プロセスと第5版の「要求事項収集」プロセスを比較してご覧ください。

[図のクリックで拡大表示]　　　　　　　　　　　　　　　　　　　　[図のクリックで拡大表示]

中央のツールと技法は8項目から11項目に増強されていますが大きな変更はありません。
大きく異なるのは第4版で「5.1要求事項収集」プロセスのアウトプットだった「要求事項マネジメント計画書」が、第5版では「5.2要求事項収集」プロセスのインプットになっている点です。

先週ご紹介したように「要求事項マネジメント計画書」の構成要素は以下のとおりです。

• 要求事項に関する活動の計画、追跡、および報告の方法
• コンフィギュレーション・マネジメントの活動。
• 要求事項の優先順位づけプロセス
• プロダクトの評価基準およびそれを使用する理由
• トレーサビリティ構造。どの要求事項の属性がトレーサビリティ・マトリクスに取り組まれるかを反映する。

最初の「要求事項の関する活動計画、追跡、および報告の方法」は広い意味でBABOKの「2.3ビジネスアナリシスのアクティビティを計画する」タスクのアウトプット「ビジネスアナリシス計画」に相当します。BABOKを知らないとこの構成要素の意味が分かりにくいのではないでしょうか。

そして、上記計画書をインプットとして「5.2要求事項収集」プロセスは実行され、そのアウトプットが「要求事項文書」と「要求事項トレーサビリティ・マトリクス」が作成されます。最初の「要求事項文書」の内容は

• ビジネス要求事項
• ステークホルダー要求事項
• ソリューション要求事項
• 移行要求事項
• その他

ビジネスアナリシス/BABOKを少しでもご存知の方には大変お馴染みの4つの要求のカテゴリーがそのまま出てきました。では、この「5.2要求事項収集」というプロセスはこの4種類の要求事項を全部作成するのでしょうか？
BABOKをご存知の方なら誰でも、

• 「引き出し」はいつ、誰がやるの？
• 「要求アナリシス」はどのプロセスで実行するの？
• 「要求の優先順位づけ」を行うプロセスは？
• 「要求の検証」は実施しなくてよいの？
• 「要求の妥当性」はどうするの？
• ．．．

と疑問を持たれるのではないでしょうか。

実は先週解説したように、プロジェクトマネジメントのPMBOKはプロジェクトマネジメントのプロセスだけを扱っていて、プロダクト指向のプロセスには何も触れていません。そのため、このような形になってしまいます。4種類の要求はまさにプロダクト指向のプロセス（のアウトプット）です。それを扱っているのが、ビジネスアナリシス/BABOKで、PMBOKとBABOKで明確に2つを分担していることになります。

これをわかりやすく図示すると次のようになります。ご覧ください。

ビジネス要求事項はBABOKの「エンタープライズアナリシス」の活動で作成され、ステークホルダー要求事項とソリューション要求事項はBABOKの「要求アナリシス」の活動で作成され、そして移行要求事項はBABOKの「ソリューションのアセスメントと妥当性確認」の活動で作成されます。それら4種類の要求事項はすべてビジネスアナリストが作成します。

[図のクリックで拡大表示]

PMBOKではプロジェクトマネジメントのプロセスとして、ビジネスアナリストが作成した4種類の要求事項を収集するプロセスを定義しています。言い変えると、PMBOKの「5.2要求事項収集」というプロセスは、ビジネスアナリシスのBABOKおよびその活動を実施するビジネスアナリストの存在を前提にしたプロセスである、といえます。ですからプロセス名は「引き出す（elicit）」ではなく、「収集する（collect）」となります。ビジネスアナリストが要求を引き出し、要求に優先順位をつけ、要求を分析し、要求を検証し、要求を妥当性確認し、要求を文書化した「ビジネス要求」「ステークホルダー要求」などを、プロジェクトマネジメントとして「収集（collect）」し、要求事項文書（アウトプット）としてまとめ上げるプロセスです。要求事項文書はビジネスアナリシス/BABOKでは「要求パッケージ」と称する場合があります。具体的には、BRD（ビジネス要求文書）、SW要求仕様書、プロダクトのロードマップ、RFI/RFP/RFQなどが該当します。

重要なので繰り返します。PMBOKはプロジェクトマネジメントのプロセスのみを対象にしています。プロダクト指向、特に要求に関する部分はビジネスアナリシス/BABOKが担っています。プロジェクトを成功に導くためにビジネスアナリシスが不可欠な主要な理由です。

• プロジェクト・スコープ・マネジメント
• プロジェクト・タイム・マネジメント
• プロジェクト・コミュニケーション・マネジメント

まず、最初のプロジェクト・スコープ・マネジメントを見ます。

知識エリア：　5．プロジェクト・スコープ・マネジメント：

「5.1　スコープ・マネジメント・計画」（プロセス）は、プロジェクト・スコープを定義し、妥当性を確認し、コントロールする方法を文書化するのですが、そのアウトプットの一つに、「要求事項マネジメント計画書」があります。その構成要素として、下記5点があげられています。

• 要求事項に関する活動の計画、追跡、および報告の方法
• コンフィギュレーション・マネジメントの活動。
• 要求事項の優先順位づけプロセス
• プロダクトの評価基準およびそれを使用する理由
• トレーサビリティ構造。どの要求事項の属性がトレーサビリティ・マトリクスに取り組まれるかを反映する。

このアウトプット「要求事項マネジメント計画書」は第4版から登場したのですが、大変わかりにくいアウトプットです。しかも第4版ではなんと「5.1要求事項収集計画」プロセスのアウトプットとなっていましたのでなおさらです。おそらくPMP資格保持者で正しく理解されている方は少ないのではないでしょうか。 なぜそんなに難しいのでしょうか。理由は簡単です。計画の対象となる実行系のプロセスがPMBOKのスコープ外（PMBOKには何も記述されていません）だからです。

これは、PMBOKの歴史上共通認識ですが、プロジェクトのプロセスには通常次の2つのカテゴリーがあります（PMBOKの第3章を参照）。

• プロジェクト・マネジメント・プロセス
• プロダクト指向プロセス：プロジェクトのプロダクトの仕様を決め、具現化する

PMBOKは最初のプロジェクト・マネジメント・プロセスのみを扱っていて、残りのプロダクト指向プロセスは何も触れていません。そして「要求事項マネジメント計画書」の構成要素がプロダクト指向プロセスを対象としているからです。例えば、コンフィギュレーション・マネジメントの対象はプロダクトのコンフィギュレーション・マネジメントですし、「要求事項の優先順位づけプロセス」もプロダクトの要求事項の優先順位だからです。ですからPMBOKだけを見ていてもそのアウトプットの意味するところが分からないのは当然なのです。

つづいて、ビジネスアナリシスの知識体系BABOKで該当するタスクを見てみましょう。

BABOKの知識エリア「ビジネスアナリシスの計画とモニタリング」の「2.5要求マネジメントプロセスを計画する」タスクとそのアウトプット「要求マネジメント計画」です。

アウトプットの「要求マネジメント計画」の構成要素は下記の4点です。

• トレーサビリティの構造化アプローチ
• 要求属性の定義
• 要求の優先順位づけプロセス
• 要求変更プロセス

[図のクリックで拡大表示]

殆どPMBOKの「要求事項マネジメント計画」と同じですが、上記4つの構成要素が各々次の実行系タスクのインプットになります。

• 4.2要求のトレーサビリティをマネジメントする
• 3.2引き出しのアクティビティを主導する
• 6.1要求に優先順位を付ける
• 4.1ソリューションスコープと要求をマネジメントする

このように、計画するタスクに対して実行系のタスクが存在し対応しているので何を計画するのかがわかります。つまり、BABOKはプロダクト指向のプロセス（タスク）だから実行系タスクが存在します。プロジェクトマネジメントの場合は計画プロセスに対して実行系プロセスがプロダクト指向プロセスになるとPMBOKには何も記載されていませんから、訳が分からなくなってしまいます。

それに対して、ビジネスアナリシスのBABOKでは計画タスク（プロセス）に対して実行系タスクがしっかり対応しているので安心です。ところで、一つの計画タスクに対して4つの実行系タスクが対応しているのはそれだけでも複雑です。できることなら計画タスクと実行系タスクが1対1に対応しているともっとすっきりすると思いませんか。BABOKの中でもわかりにくいタスクの一つです。実は、これも意外な理由があります。それは最近のソフトウェア開発環境のツールとの密接な関係です。特に要求マネジメントツール（RMツール）との関係が重要です。

BABOKでは要求は各タスクを実行すると、その状態が変化するという考え方をします。例えば、「6.1要求に優先順位を付ける」タスクを実行したアウトプットは要求[優先順位付き]です。「6.5要求を検証する」タスクのアウトプットは要求[検証済み]です。約10種類の状態がBABOKでは定義されています。別の言い方をすると要求はその状態が変化する、すなわちライフサイクルがありそれを管理する必要があるといことです。ではどのように10種類にも及ぶ要求の状態を管理すればよいのでしょうか。もはやエクセルで管理できるレベルではありません。それを可能にするのが最近台頭しつつあるRM（要求管理）ツールです。特に北米ではRMツールの使用がすでにポピュラーになっています。

RMツールの例です。要求の状態が[表明された][確認された]などがあるのがわかると思います。また、上段には要求の属性として、「優先度」「リスク」「難易度」「安定度」などが表示されています。このように、要求の状態や、属性の捕捉状況を管理して表示してくれますから便利です。

[図のクリックで拡大表示]

同じRMツールで、トレーサビリティを表示している例です。左の列が「ステークホルダー要求」で、上のリストが「ソリューション要求」の例です。緑の矢印が2つの要求間のリンクを表しています。赤い表示はステークホルダー要求に対して対応するソリューション要求が何もリンクされていないことを示してくれて大変便利です。

[図のクリックで拡大表示]

「2.5要求マネジメントプロセスを計画する」タスクはこのRMツールと密接な関係があります。アウトプットの「要求マネジメント計画」はこのRMツールの設定にそのまま使えます。例えば、当該プロジェクトで管理する要求の属性を決めれば、このRMツールに入力します。要求の引き出し活動ではその属性を捕捉しながら、RMツールに属性情報を入力します。要求プロセスで要求の状態の変化（ライフサイクル）もRMツールが自動的に管理してくれます。また、トレーサビリティも決めたやり方でRMツールを設定すれば、自動的にトレースを管理してくれ、リンクされない（トレースされない）要求を一目瞭然に表示してくれます。そうです、このタスクはRMツールのためにあるタスクだといえます。そう思うと大変便利なタスクです。

BABOKもPMBOKもRMツールを表面には何も出していませんので、一見大変わかりにくいタスク（プロセス）ですが、最近のRMツールのためにあると思えばよいのです。

今週は、逆にビジネスアナリシスを実践したらどれだけメリットが出るのかを考えてみましょう。赤字プロジェクトを減少することだけがビジネスアナリシス導入の効果なのでしょうか。まだほかにも大きな効果が期待できます。ビジネスアナリシスの代表的な特徴とそれによるメリット（効果）を紹介します。

 ビジネス要求を明確にする：

システムインテグレーターのプロジェクトマネジャーは意外と顧客案件のビジネス要求を知らないものです。例えば、弊社のビジネスアナリシス研修で参加者によく聞く質問です。

読者の皆様もお考えください。

「現在、あなたの参加しているプロジェクトの本当の目的（理由）を知っていますか？」
例えば、

• ビジネスの売上金額（増）
• ビジネスの利益（増）
• 新製品・サービスの提供とそれによる売り上げ・利益
• など。

ユーザー企業の読者なら、当然ご存知の方が多いと思います。しかしシステムを構築する立場のシステムインテグレーターのプロジェクトマネジャーの場合、プロジェクトの品質（Quality）、コスト（Cost）、納期（Delivery）に関して責任があるので、コストは当然管理するためにもしっかり把握しているはずです。しかしプロジェクトの結果、顧客はビジネスでいくらの売り上げを増加しようとしているのか、ビジネスの利益をいくら増加しようとしているのか（それがビジネス要求です）など、までは把握していないことが多いようです。

では、システムインテグレーターのプロジェクトマネジャー（またはビジネスアナリスト）が顧客のビジネス要求を明確にできるようになるとどのようなメリットがあるのでしょうか。BABOKのエンタープライズアナリシスの知識があれば、顧客にビジネスの真のニーズに気づいてもらえるようになります。RFPに書いていないより重要なビジネス機会を得るかもしれません、また、目の前の小さな課題を解決することが大きなコスト削減につながる可能性が明確になるかもしれません。

RFPが常に正しい要求を書いてあるとは限らないのです。顧客のRFPが正しくないこともありうるという事に気づくことも重要です。ですからRFP通りにシステムを構築しても顧客満足につながらないこともあります。

これは、有名な狩野モデルです。ビジネスアナリシスを実践することにより、RFPにかかれていない真のビジネス要求を明確にすることができると、その効果は計り知れません。顧客は自分たちの考えていた以上のビジネス成果が出せることがわかったり、自分たちの考えていたのと異なるやり方の方が、より低コストでビジネス要求を満たせることがわかったりします。まさに、図の「喜びのニーズ（魅力的品質）」が実現することになります。その時のシステムインテグレーターのプロジェクトマネジャー/ビジネスアナリストの立場はどうなるでしょうか。顧客からの信用が飛躍的に高まることになるでしょう。提案価格はもはや大きな問題ではありません。価格競争から脱却することが可能です。十分なマージンのある見積もりを提示することもができます。競合上の優位性が確立されます。

先週のシステムインテグレーターの場合はプロジェクトの本当の目的を把握していたのでしょうか。はなはだ疑問ですね。

特に効果の著しい知識エリアとタスク

• 知識エリア「引き出し」
• 要求に優先順位を付ける
• 要求を妥当性確認する
• 要求のトレーサビリティをマネジメントする
• 要求を割り当てる

知識エリア「引き出し」はBABOKの最大の特徴です。下記9つの豊富な引き出しテクニックを推奨しています。

• ブレーンストーミング
• 文書分析
• フォーカスグループ
• インターフェース分析
• インタビュー
• 観察
• プロトタイピング
• 要求ワークショップ
• 調査とアンケート

ビジネスアナリシスの研修で聞く質問です。読者もお考えください。

「あなたは上記9つの引き出しテクニックの中で、いくつのテクニックを使用していますか？」

使えるテクニックが少ないと、引き出せる情報が限られてしまいます。先週のシステムインテグレーターの例ではプロジェクトメンバーはいくつのテクニックを使って要求の引き出しを行ったのでしょうか。興味のある点ですが公表されていないのでわかりません。

BABOKの場合、大事なことは「引き出し」がタスクではなく、独立した知識エリアとなっていることです。それだけBABOKにおいて「引き出し」が重要視されていることを意味します。

プロジェクトマネジメントの知識体系PMBOK第5版では、プロセス「5.2要求事項収集」が該当します。知識エリア「プロジェクト・スコープ・マネジメント」の中の一つのプロセスとして扱っています。このプロセスは重要なので第4版から追加されたのですが、その扱いはBABOKほど重くありません。また、「引き出し」と「要求事項収集」という用語の違いにも注目してください。「収集」は既にある物を単に集めることです。要求事項がすでに明確に存在することを暗示しています。一方、BABOKの「引き出し」は「潜在的なものを外に取り出す」という意味で、顧客の気が付いていない潜在的な要求を引き出すことまで意味します。ですからBABOKでは、「ビジネスアナリストは真のニーズを引き出すことに責任を負う」（BABOKガイドP3）とまで宣言しているのです。読者の皆様のプロジェクトでは、ステークホルダーの真のニーズを引き出すことに責任を負っているのはどなたでしょうか？　責任者は明確になっていますか？

「引き出し」能力（テクニックを伴うスキル）が十分に高ければ、先週の不採算プロジェクトの要因だった「現行機能調査不足」等が解消できるのがわかると思います。さらに、顧客の気の付いていない真のニーズまで明確にすることが可能です。

次の「要求に優先順位を付ける」タスクでは、主にビジネス価値をベースに優先順位を付けます。ビジネス価値の少ない要求は実装から外されるだけでなく、分析の対象からも外されます。

三番目「要求を妥当性確認する」タスクでは、ビジネス要求（ビジネスケース）に貢献するステークホルダー要求、ソリューション要求のみに絞られますから、いわゆる金メッキ的な要求が入り込む余地がありません。スコープクリープを未然に防ぐことが可能です。

四番目の「要求のトレーサビリティをマネジメントする」タスクでは、すべての要求がビジネス要求からソリューションコンポーネントまでをトレースすることを確実にします。ムダのない（使われない機能）ソリューションを構築できることになります。

これら3つのタスクが実行できれば、すべての要求がビジネスに価値をもたらし、スリムで無駄のないソリューションにつながることがわかると思います。

五番目は「要求を割り付ける」タスクです。このタスクはソリューションの価値を最大化するために、ステークホルダー要求、ソリューション要求をソリューションコンポーネントとリリースに割り付けます。ソリューションコンポーネントはITとは限りません。ビジネスプロセス、ビジネスルール、組織構造、アウトソース、などが対象です。すべての要求をITに割り付けるとコストが高くなります。コストパフォーマンスを最大化するように、IT以外のソリューションコンポーネントにも割り当てるのです。結果、コストはかなり減少するはずです。ただ、システムインテグレーターの立場とは利害が相反することがありますから注意が必要です。システムインテグレーターはやはり、ITコストを押し上げる方向に動きます。自社の売り上げを第一に考える傾向があるのはやむを得ないことかもしれません。「要求を割り当てる」タスクの目的はソリューションのビジネス価値を最大化することです。システムインテグレーターの売り上げを最大化するのではありません。もしこれが実現できれば、大きな顧客満足につながります。先週のシステムインテグレーターの例では、どこにも顧客の満足を向上することが経営の指標にないのは大変残念に思います。

では、上記のようにビジネスアナリシスが実践できプロジェクトが成功し、顧客のビジネスへの貢献が顕著になったあかつきには、どうなるでしょうか。システムインテグレーターの立場も大きく向上するでしょう。プロジェクトマネジャーの地位も確立し、顧客からの信用も大きく改善されます。社内でも、成功プロジェクトとして表彰されるかもしれません。成功したプロジェクトマネジャーの次のキャリアとしては、何が期待できるでしょうか。ハイレベルなビジネスアナリストかもしれません。それともCIOでしょうか。良いことずくめですね。

最後に、上記BABOKのタスクをプロジェクトにおいてどのように実現すればよいのでしょうか。それは、プロジェクトマネジャーが上記タスクをプロジェクトのアクティビティとして定義し、タスクのアウトプットをプロジェクトのWBSとして作成することです。そしてアクティビティの実行順序を設定し、アクティビティ資源と所要期間を見積もり、スケジュールを作成します。タスクの実行はプロジェクトマネジャーが自ら行っても構いませんし、他のチームメンバーに依頼しても構いません。ただし、ビジネスアナリシスのスキルを有しているメンバーであることが必要です。

相変わらず、赤字プロジェクトが続いています。某大手システムインテグレータが不採算案件のため大幅な減益を余儀なくされました。新たな開発方法論を採用したものの、隠れていた問題が最後のテスト段階で噴出し、上流工程への大きな手戻りが発生してしまった、というものです。超上流工程の不備が大きな原因のようです。

このシステムインテグレーターの決算報告で発表されている資料を見てみましょう。
不採算案件は6件あります。問題が発覚された工程はすべてテスト工程です。

パブリック&ファイナンシャル（2件の不採算案件）では現行機能調査不足等、品質面の問題が発覚。エンタープライズITサービス（4件の不採算案件）では、外部仕様の詳細化の不足等、品質面の問題が発覚となっています。それらの要因は、開発要素、技術的な課題・制約の見極めが不十分な開発計画・原価計画で開始。そして、過大な生産性を見込むとともに、業務有識者が不十分な体制・原価計画で開始、となっています。

問題発覚がテスト工程とありますが、「ソリューション検証」のことか「ソリューション妥当正確認（受け入れ検査）」なのか、よくわかりませんが、現行機能調査不足とあるのは「ステークホルダー要求」を意味しているようです。残りの外部仕様の詳細化の不足とあるのは「ソリューション要求」に近いものです。

すなわち、これらのプロジェクトの不採算化の要因は「ステークホルダー要求」や「ソリューション要求」を正しく把握することができなかった、といえます。BABOKの観点で考えてみると、それらの本当の原因は要求の「引き出し」能力（スキル）が不足していることになります。

では、このシステムインテグレーターの不採算案件の抑止の取り組み（対策）を見てみましょう。

対策案としてすでに実施しているものとして、社長直轄の「プロジェクト審査委員会」を設置し、重要案件のプロジェクト遂行計画の妥当性を判断する。そして妥当でないものは受注できなくする、というものです。はたしてこれは真の問題の解決策になっているのでしょうか。

「引き出し」能力またはスキルに大きな見落としがあるのではないでしょうか。

左図でわかるように、ソリューション検証でチェックするのはソリューション要求です。また、ソリューションの妥当性確認（受け入れ検査）でチェックするのはステークホルダー要求です。

パブリック&ファイナンシャル（2件の不採算案件）では現行機能調査不足の問題点が発覚したのですから、それはステークホルダー要求が把握されなかったことを意味します。明らかに要求の引き出し能力に問題があります。特に新規業務における引き出し能力が不足しています。プロジェクト遂行能力以前の問題です。

エンタープライズITサービス（4件の不採算案件）では、外部仕様の詳細化が不足していたようですからソリューション要求の問題です。こちらも要求の引き出し能力の不足といえます。特に新規業務においての引き出し能力はやさしくはないですけれど、ビジネスアナリシスにとっては腕の見せ所の一つです。

6件の不採算案件すべてが、要求の引き出し能力が問題の根本原因ではないでしょうか。真の要求が把握されなかったと解釈できます。

では、真の要求の引き出し能力の不備を社長直轄のプロジェクト審査委員会で解決することはできるでしょうか。プロジェクト審査でできることは、問題を見つけることだけです。そして問題のあるプロジェクトを受注しないようにするのですから、赤字プロジェクトは減るでしょう。しかし受注できないのですから、その分収入そのものも減少してしまいます。これが本当の解決策でしょうか。明らかに違いますね。真の解決策は、引き出し能力を高めて、真のステークホルダー要求、真のソリューション要求を完璧なものにすることではないでしょうか。

モノづくりでいえば、不良品を出さないために、製造後の検査を厳重にして不良品を廃棄すればよいのではありません。そうすると検査コストや廃棄した部品コストが増えて利益を圧迫してしまいます。検査を厳重にするのではなく、設計の品質を高め（超上流工程）、製造工程を管理し不良品を作りこまないようなプロセスを確立することです。品質を高めながら、利益率も向上する。かつての日本製造業のお家芸です。

ITプロジェクトでも同じことです。超上流工程の品質を高めれば、現行機能調査や外部仕様不足は防げます。そうすれば、プロジェクト審査も問題なくパスし、赤字にならずに収入も増加します。それはプロジェクトマネジメント能力ではなく、ビジネスアナリシス能力を付けることにほかありません。不採算プロジェクトを解決するためにはプロジェクトマネジメントにビジネスアナリシス能力を追加することです。いま、システムインテグレーターにこそビジネスアナリシスが強く求められているのです。