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

◆プロジェクトの範囲

プロジェクトはどこからどこまでかというのは、当たり前のようで、はっきりしない話だ。プロジェクトの開始をプロジェクトの目的と目標の設定だと考えると、終結はその確認ができたところだという理屈になる。ところが、実際には商品を発売したり、システムを納品したところでプロジェクトは終わる。

計画体系が曖昧（構想計画と基本計画が明確に区別されていない）という問題があるにせよ、本質的にはライフサイクルの定義があいまいなのではないかと思われる。この原因は、おそらく組織の曖昧さにある。

組織を作る場合、機能組織を作って組織的分担をする。マーケティング、設計、製造、販売といった機能を分担し、調整をしながら商品を開発し、販売をしていた。ところが、ビジネスのスピードが速くなってくると、調整にかかる時間がネックになる。そこで製品を中心に考え、各機能組織から担当者が参加したプロジェクトを編成して開発を一旦機能組織から切り離し、開発が完了したら、機能組織に戻すという方法がとられるようになってきた。

マトリクス組織というのは本来便宜的なもので、明確にできないので、マトリクス組織にしている。それを明確にするのは無理があるし、明確にしすぎるのは合理性を欠く。その中で、業務を確実に行うようにするには、ライフサイクルを明確にすることが重要である。ＰＭ２.０はそのように考えている。


◆ＰＭ２.０のライフサイクル

では上の流れを組織を超えて、ライフサイクルとして定義するどうなるか。考えなくてはならないのは、現行のプロジェクトのライフサイクルではなく、プロダクトのライフサイクルである。簡単にいえば、プロジェクトの後に、製造販売することによって利益を上げ続け、そして、古くなったらフェードアウトするというフェーズを考える必要がある。

一般的に、プロダクトライフサイクルは

（１）構想
製品を構想する
（２）フィージビリティ
製品の可能性を確認する
（３）計画
製品開発を計画する
（４）実行
製品開発を実行する
（５）移行
製品を引き渡す
（６）ベネフィット
製品により便益（ベネフィット）を得る
（７）廃棄
製品を廃棄する

というサイクルになっている。この中で、（２）～（５）がプロジェクトライフサイクルである。ここでは便宜的にそのあとの（６）～（７）をオペレーションライフサイクルと呼ぶことにする。

さらに、（１）はもう少し、上流であり、この部分を戦略ライフサイクルと呼ぶ。

ここで微妙なのが、派生商品の開発や、システム改良などをライフサイクル上、どのように扱うかである。これは、微妙な問題であるが、基本的にはベネフィットを高めるために行っている活動であり、ベネフィットのフェーズでよいと思う。


◆プロジェクトありきで考える

ＰＭ２.０では、ライフサイクルとしてプロダクトライフサイクルを想定している。すると、いわゆるプロジェクトマネジャーはフェーズによって変わってくる。ＰＭＢＯＫのような標準プロセスは、むしろ、ロールにフォーカスしてプロジェクトマネジメントを定義している。つまり、プロジェクトマネジャーがすべきことがプロジェクトマネジメントである。ある意味で、プロジェクトマネジメントありきだ。

しかし、ＰＭ２.０（組織的プロジェクトマネジメント）では、発想を逆転する必要がある。プロジェクトがあり、それをうまく行うにはどのようなマネジメントが必要で、それを誰が行うかである。


◆フェーズとマネジメントプロセス

この議論は、別の機会にし、ここで改めて言葉の定義をしておく。フェーズについてである。

ライフサイクルの構成要素が「フェーズ」である。フェーズの中に、プロジェクトの性格に応じてさらに細かいフェーズが定義されることがある。たとえば、ＩＴプロジェクトで開発フェーズであれば、要件定義、基本設計、製造といったフェーズが設定されることが多い。

また、マネジメントプロセスは、フェーズごとに設定されるのが普通である。たとえば、ＰＭＢＯＫであれば、

・立上げ
・計画
・実行
・監視・コントロール
・終結

が各フェーズで設定される。また、フェーズが異なれば、同じプロセスとして実施するマネジメントの内容は変わってくるのが普通だ。プロジェクトフェーズとプロジェクトマネジメントプロセスを混乱しないようにしてほしい。