タイム・コンサルタントの日誌から

スケジュールという英単語は、もともと『一覧表』とか『箇条』という意味に近い。箇条書き、の箇条である。そこから転じて、主に米国で時間割や予定表の意味に使われるようになったときく。これをtime scheduleという。だから、PMBOK Guideの初版を作った人たちが、９つの知識領域の中で時間軸上のマネジメントのことを、スケジュール・マネジメントなどと呼ばずに、タイム・マネジメントと呼んだのは、本来の英語感覚からすると元に戻ったわけである。

その、プロジェクトにおけるタイム・マネジメントの基本は何だろうか。大きく７点ほどあげることができる。

(1) プロジェクト全体のタイム・スケジュールの目標、すなわち納期を達成するために、スケジューリングの仕組みを確立し、その水準を維持すること。

(2) プロジェクト組織を構成する各機能単位（グループ）に対して、成果物単位での「完了目標日」を含んだ詳細スケジュールを示し、またそれを保守すること

(3) すべてのスケジュールを、そのアクティビティのＷＢＳレベルの如何にかかわらず、ＣＰＭ（Critical Path Method＝クリティカル・パス法）による詳細なネットワーク・スケジュールの中での位置関係を明らかにし、また影響範囲を追跡可能とすること

ここまでの３点は、Plan-Do-Seeのマネジメント・サイクルの中で、Planすなわちプロジェクト計画段階の作業に属する。いわゆるスケジューリングと呼ばれる領域である。教科書的には、(2)のＷＢＳの列挙や(3)のクリティカル・パス法にもとづいたネットワーク・スケジュールを作成が、よくハイライトされる。しかし、一番大事なのは(1)、すなわち、タイムキープするための体制と仕組みの確立である。

そして、たいていの実務では、マスタ・スケジュールを立案してガント・チャートを書き終えると、その時点で安心してしまいがちである。そのあと、そのガント・チャートは一度も見なおされなかったりする。しかし、本当のタイム・マネジメントはこの後からはじまる。

(4) 進捗とパフォーマンスの記録をとり、それをレポーティングすること

これが、Plan-Do-SeeのDoの部分の中核である。記録し、報告する。これをみな、面倒くさがって怠る。そして、ひとたび問題が発生すると（しかもプロジェクトでは必ず、つねに問題は発生する）、それはプロマネに気づかれぬまま、担当者の胸の内に隠微に広がりはじめる。それを防ぐためには、

(5) プロジェクトの状況をモニタリングし分析して、各アクティビティがプロジェクト全体の要求するスケジュールに合致するよう保証すること

(6) プロジェクトのスムーズな遂行を可能にするような、健全なマネジメントの決定がよってたつべき基準を提示すること

(7) プロジェクトの主要やマイルストーンや完了日に影響する潜在的問題を早期に予見すること。そうした問題はマネジメントや最終顧客が先手を打って防げるように、きちんと報告されること

というSeeにかかわる部分の作業が必要になる。こうしたこと全体が、プロジェクト・タイム・マネジメントである。その中心は、(4)進捗とパフォーマンスの計測、にある。この計測が正確かつ迅速に行なわれるプロジェクトは、ちょうど正確なGPSを積んで運航する船のようなものだ。今どこにいて、どれだけの速力で、どこに向かっているかがつねに把握できている。非常に安心である。

むろん、たとえGPSを積んでいても、海に嵐が発生するのは防げない。すなわちリスクの顕在化である。しかし、待避路をとるのは早く確実になる。これが、タイム・マネジメントのベーシックなのである。