コンセプチュアル・マネジメント

◆ゴールの多層性とトライアングル

ここで、前回、述べたことを思い出して戴きたい。プロジェクトの目的は、成果物を生み出すことではなく、ゴールを達成することであると述べた。ここで、「ゴール」について少し考えておきたい。

ＰＭＢＯＫ（Ｒ）にはゴールという言葉は出てこないが、達成すべきものだ。この範囲は広い。目的も含まれるし、プロダクトスコープもプロジェクトスコープも含まれる。実際にゴールとはプロジェクトをどういう範囲で考えるかに関わってくる問題である。

つまり、ゴールは

開発チームの視点：達成すべきスコープ
組織としての視点：達成すべき目的

となる。最低限、この２つの視座がある。このような多層性がある。

そのように考えると、プロジェクトマネジメントのトライアングルは

・ゴール
・タイム
・コスト

と考える方が現実的である。つまり、開発チームにおいても、組織においてもコストとタイムという制約は変わらない。しかし、そこで達成しなくてはならないことには違いがある。

このようにマネジャーにとって、プロジェクトマネジメントとは、タイムとコストの制約の中で、プロジェクトチームの生み出した成果物を使って、（戦略・組織上の）
目的を達成するための活動である。

逆にいえば、マネジャーがプロジェクトの目的をきちんと設定していない場合、あるいは、正しくその目的をプロジェクトに伝えていない場合には、スコープ計画は不適切になり、プロジェクトの生み出した成果物には手戻りが生じる。事実、スコープ変更の多くの理由は目的とスコープの不整合で起こっている。


◆ゴールのマネジメントツール　ＧＢＳ
では、ゴールのマネジメントをうまく行うにはどうすればよいか？これはマネジメントの問題なので、いろいろなフレームワークや考え方があると思うが、その一つにブレークダウンストラクチャーを作るという考え方がある。ＧＷＳ（ゴールブレークダウンストラクチャー）である。

ゴールブレークダウンストラクチャーは

（１）ミッション（戦略ゴール）
（２）ビジネス目標（組織上のゴール）
（３）プロジェクトリクエスト（プロジェクトのゴール＝完了基準）
（４）スペック（プロダクト開発のゴール＝ＷＢＳのトップ）

というゴールのブレークダウンを行う。すると、（４）のスペックがＷＢＳのトップになるので、戦略ゴール（ミッション）から、スムーズにＷＢＳ（スコープ定義）まで展開していけるというメリットがある。

また、ゴールの多層性でいえば、一般的には（２）が組織のゴール、プロジェクトで達成すべき問題になるが、このゴールをプロジェクトリクエストに展開して行くことによって、マネジャーとしてのプロジェクトマネジメントとしてすべきことが明確になる。この点でもメリットのある手法だと言えよう。

ＧＢＳによって、プロジェクト側はプロジェクトリクエストを満足するためのプロジェクトマネジメント計画を策定する。ここから先は、いわゆるプロジェクトマネジメントの世界である。

問題はマネジャー側である。トライアングルから分かるように、コストとスケジュールの制約はプロジェクトと同じものであり、管理をしておけばよい。しかし、ビジネス目標の達成については、自らがマネジメントしていく必要がある。ビジネス目標の中には、マーケットシェアのように、プロジェクトの成果物が上がってきたあとのマネジメントが必要なものがある一方で、ＲＯＩや技術開発のようにプロジェクト実施中にマネジメントが必要なものもある。プロジェクトマネジャーにプロジェクトスペックを渡す前に、ＧＢＳだけではなく、スケジュールについても検討しておく必要がある。