WBSからガントチャートを作成する

プロジェクトの進捗管理は一般的に「スケジュール表」もしくは「ガントチャート」と呼ばれる表を使って行ないます。

次の図はガントチャートの一例です。

よく見てもらうとWBS要素がチャートの左側に列記されているのが確認できます。

この表を作るために必要なのが「PERT図」とか「アローダイヤグラム」と呼ばれるものです。これはWBSとガントチャートを結び付けるもので、WBSのワーク・パッケージの前後関係と並行関係を1つの表で示すことができます。

下の図を見てください。

作業1.1が終了するまで作業1.2を始めることはできません。

そのため作業1.1と作業1.2は前後関係（依存関係）にあると言えます。作業1.1と作業2.1はお互いに独立して仕事を進めることができるので、並行関係にあるといえるでしょう。タスク同士の前後関係、並行関係が明らかになればガントチャートを書くことができます。

PERT図はどのように書けば良いのでしょう。

まずはWBSの最下層である、ワーク・パッケージを取り出します。

それぞれのタスク(アクティビティ)の所要時間を見積もった後、最初に行うべき仕事から順番に時間の流れに沿ってワーク・パッケージ同士をつないでいきます。

最後にPERT図の中で最大の時間がかかる経路（上の図では赤線の経路）を計算し、プロジェクト全体の所要期間を算出します。この経路上のタスクは、タスクの遅れがプロジェクト全体の遅れに直結するため、重点管理が必要な部分です。この経路（作業1.1、1.2、1.3、1.4）は、特に重要な経路だということで「クリティカルパス」と呼びます。
　
計画時点でプロジェクトマネジメントが破綻する大きな要因の１つに、マネージャーやメンバーがこの"クリティカルパスを軽視している"という点が挙げられます。

クリティカルパスはその名の通り、ミッションクリティカルな経路（手順）を指しています。

PERT図ではさらにその経路に所要時間を算出しているため、重要期日(納期等)のスケジュール管理を達成するために必要不可欠な最重要ルートと言うことになります。

にも拘らず、

　「後で調整すればいいや」
　「どーせ仕様とか変わるし、その際にスケジュール見直しすれば大丈夫」

とタカをくくっていたりします。これはお客さま側でスケジュールをコロコロ変更してくる場合も、基本的には同じ問題を抱えていると言っていいでしょう。

スケジュールの調整と言えば聞こえはいいですが、実際には"納期"が調整されることはほぼ１００％ありません。大抵の場合は工程完了のタイミング調整でしかありません。

その場合、今現在の工程スケジュールの帳尻が合うだけで、そのぶん後工程に問題を先送りしているだけでしかなく、しかもそれがテスト工程だったりすると品質劣化まで招くことになってしまいます。

結果、最も割を食らうのは現場の開発メンバーです。プロジェクトメンバーが疲弊するシナリオはこうして出来ていると言い切っても過言ではありません。

PERT図が完成すればガントチャートは簡単に作成できますが、ガントチャートだけでは進捗管理はできません。

進捗管理は「進捗率の算出」を行なって初めて可能となります。

しかし、普通に百分率での進捗報告をさせていたのでは数週間経っても、進捗率が90％のままで変わらない進捗あるあるによって、管理そのものが破綻します。

みなさんの周りにもそんな人はいませんでしたか？

「60%」「75%」「85%」「90%」「93%」「94%」「94.5%」…

と徐々に刻み方が細かくなっていったり、なぜか数字が減ったりする現象。これは進捗"率"の測定基準を決めていないことが根本的な原因です。

そこでガントチャートが完成した後に「進捗率の計測基準」のルールを定めます。

たとえば、図のように

　タスクに着手して10％
　作成完了して50％
　レビュー開始で60％
　レビュー終了で90％
　承認が下りて次工程に進めるようになって100％

など、客観的基準によって進捗を報告するルールを定めておけば人によって進捗率の基準がばらばらになるということが防げます。また、虚偽報告を防ぐことが可能です。そのほか、WBSのタスクが終わっている／終わっていないという２通りだけで報告させる方法などもあります。

進捗率の計測ルールを定めたら、プロジェクトを実施し、その都度報告された進捗率を基に適切な手を打つことが必要になります。

ここで1つ注意すべきは「どのようになったらスケジュールを変更する必要があるか」という判断基準です。わずかに遅れが発生しているだけでスケジュールを変更すれば膨大な手間が掛かります。

一方、大きな遅れを放置すればプロジェクトの納期を守ることはできません。その１つの解としてよく用いられるのが「リカバリー限界の法則」です。この法則は「20％より遅れが大きくなった場合、スケジュールを変更せよ」というもので、このままのスケジュールでいいのか、思い切って実態を反映したスケジュールを引き直すかの判断を与えてくれます。

しかし頻繁に20%以上の差異が出ているようでは、そもそも最初に策定したスケジュールやメンバーの割り振り、タスクの分解の仕方などがあまりにもお粗末であることを露呈しているようなもので、マネジメントとしてはやはり破綻していると言わざるを得ないでしょう。プロジェクトが致命傷を負う前に、思い切ってマネージャを交代した方がよいかもしれません。

また、厳密には『20%』という数字は絶対的なものではありません。

リカバリーの計画を立てるマネージャーの力量によって限界値は変動します。たとえば、２週間（10人日）のタスクがあったとします。この作業が最初の１週間で２日遅れると、この２日を残りの１週間以内にリカバリーしようとすると土日を休日出勤して対応するか、毎日４～５時間残業して対応するしかありません。ですがそんなことをすればメンバーは極度に疲弊してしまう危険性を伴います。

かといって要員を追加すればその危険性を排除できるかもしれませんが、前後の事情も知らないメンバーを増やしても即日パフォーマンスが出るとは限りません。期日を後ろに倒せばオンスケのように見えるかも知れませんが、根本的な解決をしていない以上、問題を先送りしているにすぎません。

そうならないように調整するためには、マネージャーが己の力量でリカバリー可能な単位で監視・測定することです。

そもそも１週間経って２日遅れてる…という状況を知る以前から、２日経って半日遅れたことを知っていれば、簡単にリカバリーできたかもしれません。毎日確認していれば、さらにもっと簡単にリカバリーできたことでしょう。１週間もモニタリングやリカバリーを行わず、己の力量もわからずに２日遅れになるまで状況を放置していること自体が根本的原因と言えるでしょう。

私は

　・進捗は毎日確認する
　・メンバーもマネージャーも負担を限りなくゼロに近づける

ことを両立させるモニタリングを行います。実際、ほんのちょっとの労力で簡単にできてしまいます。

実は難しいノウハウなんて一切不要で、ただただマネージャーのエゴと先入観を取り除いてしまえば超簡単に実現してしまえるのですが、案外誰もやっていないところを見ると、まだまだ現場では苦労させられているメンバーも多いんだろうな…と少し残念に思ったりもします。