第5章 プロジェクト中のビジネスアナリシス（後半）
プロジェクトマネジメントの知識体系PMBOK®︎には「要求事項収集」というプロセスがありますが、実は以前はありませんでした。最近と言ってもかなり前のことになりますが、途中から追加されたことをご存じでしょうか。PMBOK®︎第3版まではなかったのですが、第4版から追加されたのです。ですから第3版までにPMPを取得されたプロジェクト・マネジャーにとってはあずかり知れないことかもしれません。ではなぜ、途中の第4版から追加されたのでしょうか。疑問を感じる人はあまり多くなさそうですが、すこし考えてみましょう。
PMBOK®︎によると、プロジェクトには大きく2種類のプロセスがあります。それらはプロジェクトのマネジメント・プロセスとプロダクト指向プロセスです。そしてPMBOK®︎はプロジェクトのマネジメント・プロセスのみを扱いプロダクト指向プロセスは対象外とされています。では、要求事項収集はどちらのプロセスでしょうか。プロダクトに関する要求事項を扱いますから、実はプロダクト指向のプロセスと言えます。マネジメント・プロセスとしてはWBSとして要求事項文書、アクティビティとして要求事項収集を定義し、メンバーの誰かをアサインし、進捗を管理するというプロセスを実施すればよいのです。すでにマネジメント・プロセスとしては十分にカバーされていると言って差し支えないものです。ですから本来のPMBOK®︎には「要求事項収集」というプロセスは必要ありませんでした。なくてかまわないものなのです。ITを扱うプロジェクトにおいて必要ならば、そのWBSとアクティビティを定義し管理すればよいのです。ですからこの「要求事項収集」というプロセスは、プロダクト指向プロセスは対象外というPMBOK®︎の原則を逸脱していることになりそうです。
では、一体なぜPMBOK®︎の原則を踏み外してまでも新しい「要求事項収集」プロセスを追加したのでしょうか。不思議だと思いませんか。それは冒頭に紹介した日経コンピュータ誌の結果と同様に、PMIでの調査による失敗プロジェクトの原因の最大要因が「要件定義」だったからではないでしょうか。
[画像クリックで拡大表示]
PMIでは毎年Pulse of Profession Studyという調査をおこない、プロジェクトの失敗要因を調べています。上図は2014年の結果ですが、なんと失敗プロジェクトの47%が「要求管理の不備（Poor Requirement Management）」と結論付けています。この年はかつてなく悪い数字でしたが、ここ数年40%前後で推移しています。 PMI Pulse of Profession Survey 2014
PMBOK®︎の原則としてプロダクト指向プロセスは対象外のはずでしたが、このようにはっきりと失敗要因が明確になれば、究極の目的であるプロジェクトを成功させる知識体系としては原則を踏み外してもプロダクト指向の「要求事項収集」プロセスを追加せざるを得なかったのではないでしょうか。
少し脱線したようです。ビジネスアナリシスの話に戻しましょう。ではその「要求事項収集」プロセスを見ていきます。
[画像クリックで拡大表示]
上図はPMBOK®︎第5版の「要求事項収集」です。このプロセスのアウトプットは要求事項文書ですが、その内容は次の通りです。
- ビジネス要求事項
- ステークホルダー要求事項
- ソリューション要求事項
- 移行要求事項
- その他
この中のビジネス要求事項、ステークホルダー要求事項、ソリューション要求事項などは次の通りです。
[画像クリックで拡大表示]
では、この「要求事項収集」プロセスのインプットとツールと技法からビジネス要求事項、ステークホルダー要求事項、ソリューション要求事項などが作成できるでしょうか。
技法としてインタビュー、フォーカスグループ、ファシリテーション型ワークショップなどがありますが、これらは要求の引き出しで使われるものばかりで、ステークホルダー要求事項やソリューション要求事項を作成するのに必須のモデリング技法（データフロー図、UML、データモデルなど）がありませんね。ですからこのプロセスではこれらの要求事項（とくにステークホルダー要求事項とソリューション要求事項）をアウトプットとして作成することは無理があると言わざるを得ません。一体どうやってステークホルダー要求事項（モデル化された）やソリューション要求事項（モデル化された）は作られるのでしょうか。その疑問を解消するためには次の図を理解する必要があります。
[画像クリックで拡大表示]
プロジェクトマネジメントのPMBOK®︎はプロジェクトマネジメント・プロセスだけを扱っていて、プロダクト指向プロセスには何も触れていません。そのため、このような形になります。4種類の要求はまさにプロダクト指向のプロセス（のアウトプット）です。それを扱っているのが、ビジネスアナリシス（知識体系としてBABOK）で、PMBOK®︎とBABOKで明確に2つを分担していることになります。
ビジネス要求事項はBABOKの「戦略アナリシス」の活動で作成され、ステークホルダー要求事項とソリューション要求事項はBABOKの「要求アナリシスとデザイン定義」の活動で作成されま、移行要求事項もBABOKで作成されます。それら4種類の要求事項はすべてビジネスアナリストが作成します。ですから、PMBOK®︎ではプロジェクトマネジメントのプロセスとして、ビジネスアナリストが作成した4種類の要求事項を収集する（Collect）プロセスを定義しています。決して要求を引き出し（elicit）て要求事項をまとめるのではなく、ビジネスアナリストが作成した要求事項文書を収集（collect）するだけなのです。
言い変えると、PMBOKの「要求事項収集」というプロセスは、ビジネスアナリシスのBABOKおよびその活動を実施するビジネスアナリストの存在を前提にしたプロセスである、といえます。ですからプロセス名は「引き出す（elicit）」ではなく、「収集（collect）」になります。ビジネスアナリストが要求を引き出し、要求に優先順位をつけ、要求を分析（モデル化）し、要求を検証し、要求の妥当性確認し、要求を文書化した「ステークホルダー要求事項」、「ソリューション要求事項」」などを、プロジェクトマネジメントとして単に「収集（collect）」するプロセスです。要求事項文書はビジネスアナリシス/BABOKでは「要求パッケージ」と称する場合があります。具体的には、RFP（お馴染みですね）、BRD（ビジネス要求文書）、SW要求仕様書、プロダクトロードマップなどが該当します。
ところがビジネスアナリスト不在のプロジェクトの場合はどうなるでしょうか。次の図解をご覧ください。
[画像クリックで拡大表示]
誰も要求事項をまとめる人材がいませんね。ステークホルダー要求やソリューション要求を責任もってまとめる人材がいません。そして多くのプロジェクト・マネジャー（PMBOK第5版までにPMPを取得者された方）はビジネスアナリストがプロジェクトに不可欠なことをご存じありません。それが受注者側のみならず、発注者側にも不在だとしたら、そのプロジェクトの先行きは大変暗いものにならざるを得ない、ということです。日本のITプロジェクトの半数が失敗するのもうなずけるというものではないでしょうか。
重要なので繰り返します。PMBOKはプロジェクトのマネジメント・プロセスのみを対象にしています。プロダクト指向、特に要求に関する部分はビジネスアナリシス/BABOKが担っています。プロジェクトを成功に導くためにビジネスアナリシスが不可欠な主要な理由です。 今まではPMBOKの第5版を参照していましたが、最新の第6版を見てください。
[画像クリックで拡大表示]
注目していただきたいのは「ツールと技法」の最初の「専門家の判断」です。この第6版で追加されました。これこそビジネスアナリストを指しています。やっと第6版でビジネスアナリストの存在が明文化されるようになりました。以下はPMBOK第6版からの引用です。よくお読みください。
- 「ステークホルダーの要求事項を引き出し、文書化し、マネジメントすることは、プロジェクト・スコープ・マネジメントのプロセス内で行われる。プロジェクト・スコープ・マネジメントの傾向と新たな実務慣行は、ビジネスアナリシス専門家との次のような協業に焦点があてられる．．．」
- 「ビジネスアナリシスを実行する責任を負う役割は、十分なビジネスアナリシスのスキルと専門知識のある人的資源に割り当てられる必要がある．．．」
- 「プロジェクト・マネジャーとビジネスアナリストとの関係は、協力的なパートナーシップがなければならない。プロジェクト目標を成功のうちに達成するためにプロジェクト・マネジャーとビジネスアナリストが互いの役割と責任を十分に理解しあうことによって、プロジェクトが成功する可能性はより高まる。」
そして、プロジェクトマネジメントとビジネスアナリシスの主な違いは次の通りです。
- プロジェクトマネジメントの主な焦点はプロジェクト
- ビジネスアナリシスの主な焦点はプロダクト
遅きに逸した感じがしますけれど、 やっとPMBOKにビジネスアナリストとの協働作業がプロジェクトを成功に導く旨の記述がされるようになりました。これで晴れて日本でもプロジェクトにおけるビジネスアナリシスの重要性が認識されるようになることを期待します。
読者でPMP取得の方はぜひご自分が取得した時のPMBOKガイドのバージョンを確認してください。第5版までにPMP取得された方（ほとんどかもしれません）は最近のビジネスアナリストとの協働の必要性をご存じない可能性があります。ぜひ第6版をご覧いただきたいと思います。
ファシリテーション
要求定義においても基礎的なコンピテンシーは重要です。特にファシリテーションで顕著です。テクニックのワークショップをスムーズに行うために不可欠なコンピテンシーです。出席者全員に参加を促し、ステークホルダー同士で意思決定し、問題を解決し、アイデアや情報を交換し、要求の優先順位や要求の性質について合意できるようにします。ある要求を主張するグループAとそれとは異なる要求を主張するグループB。Aの要求を採用するとBが困る（反対する）、Bの要求を採るとAが嫌がる。このような衝突はITプロジェクトでは珍しくありません。グループA、グループBを含む全グループの要求を引き出し、そして中立的な要求案Cを見いだすようにファシリテーションを行います。そこで役に立つのは「交渉と衝突解消」というスキルです。交渉のスキルを使うとうまく衝突を解消することができます。
交渉と衝突解消
以下はある「交渉術」の研修で用いられている寸話を引用します。
「ある姉妹が冷蔵庫にある一つのオレンジを取り合って喧嘩しています。二人ともオレンジ丸一個ほしいと言い合っています。それを見かねた母親が仲裁を試みますが、二人とも引き下がりません。二人とも、どうしても「オレンジ丸一個必要」と主張しています。そこで、母親はひとりひとりにどうしてオレンジ丸一個ほしいのか聞いてみました。姉は「昨日、家庭科の授業でオレンジマーマレードの作り方を教わったから、これからオレンジ丸一個使ってマーマレードを作る。レシピにオレンジ丸一個必要と書いてあるから半分ではできない。」と言い張ります。次に母親は妹を呼んで聞くと「ジョギングしてのどが渇いたから丸一個のオレンジをジュースにして飲む。半分では足りない」と。母親が、妹にオレンジの皮はどうするのか聞くと、「皮なんかいらないから捨てるわよ」と。姉は「マーマレードに必要なのは皮だけ、実の部分は要らない」と言いました」。見事に二人の姉妹は自分の欲しいものを100%ずつ手にすることができました。」
似たような状況はいくらでもあるはずです。相手にとって重要なものでも自分とって取るに足らないものならあげればよい。代わりに相手にとって些細かもしれないが自分にとって価値のあるものならもらえばよい。そのためにはお互いが何を重要と感じているのか（価値観）を知ることが大切です。そうすればWin/Winの関係が実現できるのではないでしょうか。主張している立場（姉も妹もオレンジ丸一個を主張）が重要ではありません、二人の背後にある利害（本当に必要なもの：価値）を理解することです。それを可能にするにはお互いの信頼感が不可欠なことも忘れてはいけません。
リーダーシップとチームワークはビジネスアナリストにとって極めて重要です。
リーダーシップ
ビジネスアナリストはステークホルダーに対して何の権限もありませんがリーダーシップを発揮する必要があります。ここはプロジェクト・マネジャーと決定的に違う点です。プロジェクト・マネジャーの場合は「人、モノ、金」の権限を持ちますが、ビジネスアナリストは何も権限を持ちません。にもかかわらずリーダーシップを発揮する必要があります。ポイントはビジョンです。望ましい未来の状態について明確で意欲的なビジョンを提示し、人を動かしビジョンを行動にうまく移行させるのです。お互いの利益を理解できるように、ステークホルダーを感化し、ステークホルダーに影響を与えるための協働のテクニックを効果的に活用することにより、個人の動機を超えてより広い目標を考慮するように、ステークホルダーに影響を与えます。これは上下関係に関係ないリーダーシップで、いわば「責任を共有するリーダーシップ」と言えます。アジャイルのリーダーシップ（サーバント・リーダーシップ）にも通じます。
チームワーク
チームワークも不可欠です。
ビジネスアナリストは、チームはどのように形成され、どのように機能するかを知っておかなければなりません。チーム力学を意識し、プロジェクトのさまざまな段階を踏んでチームが成長していく中で、力学がどのように作用するかを知ることも極めて重要です。チームメートとの信頼を築き、良好に保つことは、チーム全体の一体感を高め、チームのパフォーマンスを最大限に引き出すのに有効です。チームにおいて衝突はよくあることです。適切に対処すれば、衝突の解消がチームにとってむしろメリットをもたらすこともあります。
そして、協働作業の環境が育まれ、適切に衝突が解消され、チーム・メンバー間の信頼が醸成されるようにします。共有されている高い達成基準に向けて、チーム内で支え合う雰囲気を作るのです。チームゴールに対する当事者意識が共有されることが重要です。
「リーダーシップ」と「チームワーク」は表裏一体です。リーダーが全責任を持つという専制型のリーダーシップ（PMBOKでのリーダーシップ）ではありません。リーダーもチームメンバーも同等に責任を共有する、という新しいリーダーシップです。協働型のリーダーシップとでも言うのでしょうか。前述の信頼感が前提ですね。
ビジネスアナリストはステークホルダー（要求を引き出す相手）の上司ではありませんから専制型リーダーシップで「引き出し」がうまくできるわけありません。ステークホルダーが責任を共有してもらうようになってくれることが重要です。これもエンゲージメントにもつながります。