2．可視化で浮かび上がる問題
プロジェクト管理の問題を解消するためには「見えないものをコントロールすることは不可能」という点を、認識する必要があります。プロジェクトのマネジメントには「見える化」が必須で、単なるデータは見える化によってメトリクスになるのです。では実際に、幾つかのプロジェクトを見える化する過程を解説します。図2はクルマ関連の製品を開発しているあるメーカーにおける1年間の週ごとの開発工数（単位は時間）を表したものです。
図2.プロジェクト別の工数推移（その1）
図2（a）ではプロジェクト別に工数推移をまとめました。このメーカーでは、ベースプロダクトを開発する2～3の大規模プロジェクトに開発工数のほとんどが投入されていることが分かります。
図3.プロジェクト別の工数推移（その2）
一方で図3は、同じくクルマ関連の製品開発を行っている別のメーカーの開発工数推移です。図3（a）を見ると、先ほどのメーカーとは違い、非常に多くの小規模プロジェクトが並行して存在していることが分かります。ここまでは全体のプロジェクトの様子が分かるものの、プロジェクト管理には使えない単なるデータです。
これを頭に入れた上で、次に図2（b）図3（b）を見て下さい。各メーカーの開発工数推移を、今度は見方を変えて設計や製造など開発工程別にまとめた結果です。同様の傾向が多くの繁忙な開発組織で見られるのですが、これらのグラフを見て、何か新しい発見はないでしょうか。
多くの人は、企画・設計・製造・評価など各工程が逐次的に進み、その流れをコントロールするのがプロジェクト管理や開発プロセスだと考えているでしょうが、図2（b）、図3（b）を見て分かるように、現実は大規模プロジェクト中心だろうと小規模プロジェクト中心だろうと、開発工程は同時並行に実施されています。企画、設計、試作、製造、評価などの作業が常に並行しているわけです。
このような現状にもかかわらず、どちらのメーカーも企画、設計、試作、製造、評価などの各工程が逐次的に進む開発プロセスが規定されているだけで、すべての開発工程が並行に実施される現実を無視しています。大規模プロジェクトでは同時に設計、試作、製造、評価が行われているにもかかわらず、工程移行確認中心の進ちょく会議やデザインレビューが管理の基本となっており、重...
複した開発工程を同時にコントロールするための手順や方法を規定化できていません。
一方、小規模プロジェクトでは、プロジェクトごとに開発プロセスを規定してもほとんど意味はなく、技術者が複数のプロジェクト向けに同時進行している設計、試作、製造、評価作業を兼務している状態をコントロールする仕組みが求められています
次回、その3では、マネジメントできる姿にモデル化する。を解説します。