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

◆目標をどう設定するか

たとえば、市場に対する影響力の強化を図るという戦略目標があり、新しいコンセプトの製品を投入するとしよう。そのためにいくつかの製品を開発する。通常はこの開発の一つ一つがプロジェクトになる。

そこである開発プロジェクトではブランドイメージの刷新を目的とし、従来にはないデザインの製品を投入することにした。具体的な目標としては３０歳以下の顧客の比率を従来製品の平均２５％に対して、５０％を目指すことにした。

この時に悩むのは、この目標の設定方法は正しいのかという点だ。つまり、この目標が達成できたかどうかの評価は、せいぜい開発が終了し、生産・販売が始まり３カ月後、できれば製品の立ち上がりが終わる頃まで見て初めてできる。ところが、一般的にいえば開発が終了すればプロジェクトチームは解散して、メンバーは別の仕事を担当しているので、評価・分析をすることすら難しい。

本来であれば、もし、５０％を目指し、４５％だったとすれば改良版の商品を出したり、プロモーションを強化するといった活動をしてもおかしくない。ところが、実際にはこのような活動は行われないことが多い。

◆ライフサイクルはＰＩとして決める

この問題の本質はライフサイクルの認識にある。

プロジェクト・イニシアチブの重要な概念の中に「プロジェクト・インフラストラクチャー（ＰＩ）」という概念がある。詳しくはまた機会を見て解説するが、ＰＩはプロジェクトの開始前に行うべき意思決定を指している。プロジェクト方針を細かく規定するものだといってよい。この概念は日本ではプロジェクトマネジメントに標準化から入ったのであまり関心を持たれていないが、極めて重要な概念である。

その意思決定項目の一つにプロジェクトライフサイクルをどう考えるかがある。この議論はケースバイケースなので標準として定めることは難しい。ある製品は開発作業だけでいいかもしれないし、製品は開発後の展開や改良までをライフサイクルと考えるべきかもしれない。ちなみにPMBOK(R)ではそのようなライフサイクルの組み立てが可能なように「フェーズ」という概念がある。

上の議論、つまり、目的に対して目標をどのように設定するかは、プロジェクトインフラストラクチャーとしてのライフサイクル次第なのだ。ここがおざなりになっているプロジェクトが多い。

◆ライフサイクルは重要なＰＩ

ライフサイクルというＰＩはプロジェクトの組成上、非常に重要な意味がある。たとえば、開発作業だけをプロジェクトライフサイクルにすればいいのであれば、いわゆる専業のプロジェクトチームを作って行えばよい。ところが、プロジェクトライフサイクルに企画やフォロー、改善のようなフェーズまで入れようとすると専業チームを作って行うことは現実的ではない。製造や営業なども含めたプロジェクト体制を作る必要がある。いわゆるマトリクス型の組織だ。

ライフサイクルをきちんと決定して始めたとして、もう一つの問題としてあるのが、４５％しか実現できないなかった場合にどうするかという議論である。プロジェクトの推進として考える限り、ここに反復的なプロセスを入れるのは難しい。一旦、リリースしたメンバーを再び集めることが難しいからだ。

◆プロジェクトからプログラムへ

そこで出てくるのがプログラムという考え方である。ここでいうプログラムとは

共通の目的に向けて、複数の活動（プロジェクト）を行い、成果を統合していく活動

である。

ここで、共通の目的は事業の戦略ゴールであったり、場合によってはビジョンであったりする。

プログラムとして考えるなら、プロジェクトを複数のプロジェクトに分割し、最初のプロジェクトで３０％、次にプロジェクトでプラス２０％、最初のプロジェクトの結果によっては次のプロジェクトでプラス３０％といった目標変更をすることもできる。

ここに「市場に対する影響力の強化を図る」という戦略目標に対する別の活動（プロジェクト）を入れて考えることができるわけだ。

この場合、最初に述べたようなプロジェクトのライフサイクル自体は大きな問題にはならない。プロジェクトごとには目的を絞り込み、目標を絞り込み、それをいくつか組み合わせてプログラムとそのライフサイクルを作ればよいからだ。その場合、プロモーションや改良などもプログラムを構成するプロジェクトになる。