PDCAサイクルに潜むプロジェクト管理の問題点：TOC流の開発型プロジェクト管理術「CCPM」（2）（2/3 ページ）

確認段階（Check）に潜む問題

　説明するまでもなく、開発に携わる人間は本能的に、プロジェクトは初めから遅れる宿命を持っていることに気付いています。そして、遅れから身を守るためにチェックとフォローをしっかり実施しようとします。しかし、この確認段階（C）にも多くの問題が潜んでいるのです。

1. ガントチャート（バーチャート）

　作業ごとの予定と実績が書かれた計画表（ガントチャート）で、予定と実績を対比することで、各作業の予定からの乖離（かいり）が分かります（図1）。しかし、現実のプロジェクトで、数百にも上るタスクをガントチャートだけで管理するのは極めて難しいのです。ガントチャートと日々格闘しているプロジェクトリーダーならともかく、進ちょく会議で報告される管理者側は、このような資料だけで状況を把握することは不可能に近いのです。

図1　プロジェクトの進ちょく確認方法（ガントチャート）

2. イナズマ線

　ガントチャートの欠点を修正し、分かりやすくする方法としてイナズマ線という方法があります。これはガントチャートに確認日を基準としたタスクごとの進ちょく率線を引いて表す方法です。計画どおりであれば確認日から直線が引かれ、左に突き出していれば遅れ、右に突き出していれば進んでいることを表します（図2）。

図2　プロジェクトの進ちょく確認方法（イナズマ線）

　この補助線（イナズマ線）によって、各作業単位の状況は格段に把握しやすくなりますが、これでもまだ全体の進ちょくがどうかという重要なポイントを把握するのは困難です。なぜならば、プロジェクトのタスクは順序依存性に縛られたネットワークでつながっており、個々の作業の重要度や余裕などさまざまです。これらの関係性の影響が分からないイナズマ線では、関係者全員がまず知りたい「このプロジェクトは納期に間に合うのか？」という肝心な質問に正確には答えられないのです。

3. クリティカル・パス法

　ならば、ネットワークの中でも一番長い経路だけを管理すればよいと考えて構築されたのがクリティカル・パス法です。クリティカル・パスとはプロジェクトの開始から終了をつなぐ経路のうち、最も時間のかかるものと定義されます。つまりプロジェクト全体の完了期間はクリティカル・パスで決まるということです。この最も長い経路上のタスクの進み具合が納期に大きな影響を与えるため、この進ちょく状況を確認することが非常に重要になるのです。

　しかしクリティカル・パス法も、プロジェクト間のリソース競合という問題にうまく対処できないため、クリティカル・パスが頻繁に変わり、その結果遅れの発生を食い止めることは容易ではありません。

結局のところ意思決定は直感

　見てきたように、どのような管理方法を採用してもプロジェクトは遅れ、状況はあいまいにしかつかめません。状況があいまいにしかつかめなければ、対策も結局はあいまいになります。

　例えばトータルで1年と計画したプロジェクトが予定より2カ月遅れていたら、誰でも対策を打たなければならないと感じます。ところが遅れが1日ではどうでしょう。きっと1日程度なら、後続作業の「余裕」でなんとかリカバリーできると考えるのではないでしょうか。では1カ月では？ 15日では？ 10日ではどうでしょう。

　2カ月では危険と思い、1日では大丈夫だと思う。一体どこに危険と安全の境目があるのでしょうか。さまざまなツールを活用し、線を引いたり表やグラフを作ったりしていますが、とどのつまり対策は経験や感覚で判断しているのが実態なのです。

　それでもプロジェクトは遅れてはならないので管理を強化します。それでも遅れるので、さらに管理を強化することになります。管理を強化するたびに進ちょく会議の資料は増え、プロジェクトリーダーの負担は年々増し、会議での報告時間はどんどん長くなるのです。知りたいのは、「定められた品質を確保し納期に間に合うのか？」というシンプルな質問であるにもかかわらず、膨大な資料からこれを読み解くことは不可能に近いのです。