第3章 プロジェクト開始前の活動
プロジェクト開始前の作業のアウトプットとしてビジネス・ケースがありますが、これは日本ではあまり馴染みがないようです。近いものとして「稟議書」があります。書かれている内容はほとんど同じです。大きく異なるのは承認方法です。ビジネス・ケースの場合はスポンサー（エグゼクティブなど）が責任をもってサインしますが、日本の稟議書の場合は多くの役員などの押印による承認で、根回しが必要なことが多く、またかなり時間もかかります。
プロジェクト ビジネス・ケース
- プロジェクト ビジネス・ケースは、十分に定義されていな選択された構成要素のベネフィットの妥当性を確認するために用いられる経済的な実現可能性検討文書であり、以降のプロジェクトマネジメント活動を認可する判断する根拠となる。ビジネス・ケースはプロジェクトの立上げの目標および理由を記載したものである。（PMBOK®︎第6版）
ビジネスアナリストがビジネス・ケースを作成しない限りプロジェクトはスタートできないとも言えるものです。
ここで大切なのはビジネス要求です。英語ではBusiness Requirementsですが、PMBOK（日本語版）ではビジネス要求事項と言い、BABOKではビジネス要求と言います。Requirement(s)を「要求」と訳すか、「要求事項」と訳すかでニュアンスが少し違うかもしれません。さらに日本では「要件」という用語もありますが、こちらも英語ではRequirementsです。「要求（事項）」と「要件」では何が違うのでしょうか。別途コラムで解説したいと思います。
まずPMBOK(R)における「ビジネス要求事項」の定義をご覧ください。
ビジネス要求事項：
- ビジネス上の課題や好機のような組織全体のよりハイレベルのニーズ、およびプロジェクトが採用された理由を表す。（PMBOK®︎第6版）
お分かりのように、ビジネス・ケース作成において最も重要なのはビジネス要求を明確に定義することです。ところが、受注側のプロジェクト・マネジャーは意外と顧客案件のビジネス要求を知らないものです。例えば、弊社のビジネスアナリシス研修で参加者（この研修はPMの方が多く参加される研修です。）によく聞く質問です。
読者の皆様もお考えください。
「現在、あなたの参加しているプロジェクトの本当の目的（理由）を知っていますか？」
例えば、
- ビジネスの売上金額（増）
- ビジネスの利益（増）
- 新製品・サービスの提供とそれによる売り上げ・利益など。
ユーザー企業の読者なら、当然ご存知の方が多いと思います。しかしシステムを構築する立場のシステム開発側のプロジェクト・マネジャーの場合、プロジェクトの品質（Quality）、コスト（Cost）、納期（Delivery）に関して責任があるので、コストは当然管理するためにもしっかり把握しているはずです。しかしプロジェクトの結果、顧客はビジネスでいくらの売り上げを増加しようとしているのか、ビジネスの利益をいくら増加しようとしているのか（それがビジネス要求です）など、までは把握していないことが多いようです。
プロジェクトの現場ではどのようなことが起きているのでしょうか。研修の参加者による問題点とその影響です。
個人的な要求が出てくる → プロジェクト活動に影響が出る
ユーザー部門の要求が人によってずれている → ソリューションがあいまいなものになる。→ 使えないシステム
ユーザーが日頃の仕事の改善案として要求を出してくる。→ その人のみが使う機能。他の人は使わない。
本来の目的と異なる要求が多く出る → コスト増、生産性ダウン、手戻り →失敗PJ
不要なテストをしてしまう。→ コスト増、スケジュール遅延につながる。
ユーザーと会話が通じなくなる
これではまともなシステム開発ができない現状がよくわかるような気がしますね。
では、逆にシステムインテグレーターのプロジェクト・マネジャー（またはビジネスアナリスト）が顧客のビジネス要求を明確にできるようになるとどのようなメリットがあるのでしょうか。これも研修の参加者の意見です。メリットです。
プライオリティの高低が分かる→効率的に仕事ができる →成功PJにつながる
ニーズに合った提案ができる→ ユーザー満足→ 成功PJにつながる
責任感が芽生える → PJメンバーの士気向上 → 成功PJにつながる
ユーザー要求に対して経営目標に合致している議論できる→要件が明確で手戻り減る→予算内、スケジュール通り
より良い提案ができる → 顧客ニーズの満足 → 顧客満足度/SIerの評価向上
ユーザーと会話が通じ、関係が良くなる→ 次の案件につながる
プロジェクトに対して提案できる → 不要なことをやらなくて済む
→ 採用されるとやりがいにつながる
変更要求に対してスムーズに要否を具申できる
PMとして信頼される → お客様から信頼される、感謝される
→ 次のビジネスチャンスの可能性が出てくる
→ 昇格できるかも
まるで雲泥の差が出ることが理解できますね。
ビジネスアナリシスの知識があれば、顧客にビジネスの真のニーズに気づいてもらえるようになります。RFPには書いていないより重要なビジネス機会が得られるかもしれません、また、目の前の小さな課題を解決することが大きなコスト削減につながる可能性が明確になるかもしれません。
RFPが常に正しい要求を書いてあるとは限らないのです。顧客のRFPが正しくないこともありうるという事に気づくことも重要です。ですからRFP通りにシステムを構築しても顧客満足につながらないこともあります。
上図は、有名な狩野モデルです。ビジネスアナリシスを実践することにより、RFPにかかれていない真のビジネス要求を明確にすることができると、その効果は計り知れません。顧客は自分たちの考えていた以上のビジネス成果が出せることがわかったり、自分たちの考えていたのと異なるやり方の方が、より低コストでビジネス・ニーズを満たせることがわかったりします。まさに、図の「喜びのニーズ（魅力的品質）」が実現することになります。その時のシステム開発会社のプロジェクト・マネジャー/ビジネスアナリストの立場はどうなるでしょうか。顧客からの信用が飛躍的に高まることになるでしょう。提案価格はもはや大きな問題ではありません。価格競争から脱却することが可能です。十分なマージンのある見積もりを提示することもができます。競合上の優位性が確立されます。などなど。
日経コンピュータ誌で調査対象のシステム会社の場合はプロジェクトの本当の目的を把握していたのでしょうか。多くのプロジェクト・マネジャーはビジネス要求まで把握していなかったのではないいでしょうか。
プロジェクト開始前のビジネスアナリシスの代表的な活動は以下の通りです。
- ビジネスの現状を分析して取り組むべきビジネス・ニーズ（問題または機会）を決める。
そのビジネス・ニーズを明確にしたものを、ビジネス要求としてまとめる。
そして現状を記述する。 - ビジネス要求を満たした結果の将来状態におけるゴールと目標を定義する。
そのゴールと目標を達成するためのソリューションの概要と潜在価値を定義し、それを含めた複数の将来状態を記述する。 - 現状から将来状態へのチェンジ（トランスフォーメーション）の概要を記述する。
そのチェンジの過程の概略（それがチェンジ戦略）をビジネス・ケースとしてまとめる。 - 2の複数の将来状態の各々のリスクをアセスメントし、リスクを考慮しながら3を行う。
大事なことは１から４をほぼ同時に行うことです。決して順番通りに進むのではありません。行ったり来たりしながら、4つのタスクを実行します。また、一度実行したらそれっきりということでもありません。ビジネスの現状は時々刻々変化しています。特に最近のビジネス事情はVUCAの時代と言われています。VUCAとは次の用語の頭文字を取ったものです。
- Volatile（変りやすい）
- Uncertain（不確かで）
- Complex（複雑な）
- Anbigous（あいまい）
すなわち、変りやすく、不確かで、複雑で、あいまいな状況を表した用語です。VUCAな状況のビジネス環境では、現状が常に変化していることになりますから、現状に変化を感じたら即、戦略を見直す必要すらあるわけです。