(2010/07/31)プロジェクトの計画作業は大きく二段階に分かれる。前半はスコープ定義で、プロジェクトを構成するアクティビティを洗い出し、達成すべき仕事の範囲全体を網羅しカバーする。このアクティビティを階層的に構成して整理番号を付番したものがWBSである。後半は、各アクティビティに必要なリソース・時間・コストを見積り、アクティビティの順序(論理的関係)にしたがって、ロジック・ネットワークを作成する。これがプロジェクトのタイム・テーブル(工程表)のベースとなる。これがスケジューリングである。プロジェクトを表すアクティビティ・ロジック・ネットワークの始点から終点までを結ぶさまざまな経路のうち、最長のものをクリティカル・パスと呼ぶことはよく知られている。プロジェクト全体の所要期間(工期)は、クリティカル・パスよりも短くすることはできない。ここまではまあ、ある意味で基本である。プロジェクトの期限ないし納期設定を考える時、そこに自由度がある場合と、外部から制約条件として与えられる場合がある。受注ビジネスの中で生きている人は、「納期とは客先から与えられた制約条件だ」と考えることが多いだろう。契約によっては、納期遅延に対してペナルティ条項がついていることもある。ように、自社が発案した自発型プロジェクトでは、納期はある程度、自ら設定できる。Projectと呼んで区別する。自発型であっても、新製品の納期が展示会やフェアーなどの期日にしばられることはある。対外発表の時期が、上からぽーんと鶴の一声のように下りてくることもあろう。いずれにせよ、自発型の場合、納期に多少の自由度があるケースが多い。自分が納期を設定できるときは、クリティカル・パスの長さで決めるべきだろうか。クリティカル・パスの長さが120日ならば、納期は120日と宣言して良いだろうか。クリティカル・パスの長さとは、プロジェクトが達成可能な『最短の期間』だからだ。計画段階ですべてを見通すことはできない。予期せぬ事やらミスやらが、途中で生じてくるものである。した外乱・内乱(?)によって、スケジュールというのは常に遅れていく可能性がある。そこで、クリティカル・パス長に、最小限の適切な余裕日数を加えて、納期を設定する方が安全である。この、意図して追加した余裕日数のことを、「バッファー」と呼ぶ。余裕日数としての「バッファー」と、PERT/CPM技法でいう「フロート日数」は、ときどき混乱して使われるので、注意が必要である。PERT/CPMのフロートは、そのアクティビティが遅延したときに、プロジェクト全体の工期に影響を与えるまでの日数を言う。Floatの二種類があるが、説明は省く)。クリティカル・パス上のアクティビティはすべてフロート=0日である。フロートとは個々のアクティビティに付随する属性値だと理解してほしい。これに対してバッファーとは、特定のアクティビティにぶら下がる性質のものではない。全体のプロジェクト・マネジメントの観点から、意図して置かれるものである。「時間のムダとり--スケジュールのサバを切り捨てる」でも説明したとおり、適正なスケジューリングにおいては、(1)アクティビティ所要期間の冗長な部分をみつける、(2)それを捨てる(正味分のみにする)、(3)プロジェクト全体に必要最小限の冗長性を付け加える、という、ちょうど情報理論と類似した手続きを行う。このステップ(3)がバッファーなのである。バッファーは生産管理で言う、意図した在庫配置に相当する。それでは、このバッファーを、アクティビティ・ネットワークのどこに配置すべきなのか。全体工程120日のプロジェクトに15日のバッファーを追加するとして、それはどこに置くべきか。細かく分割して、すべてのアクティビティに公平に配分したら、という考え方もあり得よう。いや、クリティカル・パス上のアクティビティだけに個別配分する、という案もある。これらはあまりおすすめできない。前にも書いたが、バッファーには加法性が成り立たず、1日のバッファーを15個持つよりも、15日のバッファーを一箇所にまとめておく方が、ずっと安全なのだ。最初にバッファーを置く、というのは、言いかえると、プロジェクトがスタートしてから15日間は、何の作業にも着手しない、ということになる。これではバッファーとしての意味がない。したがって、プロジェクトの最後にまとめて置く、というのが正解となる。これを、「プロジェクト・バッファー」とも呼ぶ。プロジェクトを遂行していく上で生じるさまざまな遅れにより、このプロジェクト・バッファーは次第に消費されていく運命にある。そこで、プロマネは残りのバッファー日数をウォッチして、あと何日までなら納期に影響がでないか、常に見ていくことをお勧めする。このように、計画段階で上手にバッファーを配置設定し、実行段階でそれをウォッチし続けることを、CCPM技法では「バッファー・マネジメント」と呼んでいる。この目的のために実行段階でしばしば使用されるツールとして、横軸にプロジェクトの経過日数(割合)をとり、縦軸にバッファー日数の消費(比率)をとって定期的にプロットする手法(バッファー・トレンド・グラフ)がある。理想的に言うならば、プロジェクトの進行割合に比例して、バッファー日数が消費されていく、という形になる。開始後40日たったらバッファーは5日消費され、開始後80日では10日消費されている、という具合だから、プロットされた点は斜めの直線になるだろう。現実はなかなかそうはいかず、ジグザグの線になる。グラフ上で点が上の方に来る状態は、プロジェクトの進行に対してフロートの消費が著しく大きいことを意味している。そこで、グラフに原点を通る2本の線を書いて、プロット・エリアを3つに分け、下からグリーン・イエロー・レッドに分けることがよく行われる。プロットされた点が下の方、つまりグリーン・ゾーンなら安全、中間のイエローなら注意、上の方のレッドなら危険、という訳である。要注意から危険領域に入ったら、さまざまな対策を施して安全側に戻るようマネジメントする必要がある。このようにCCPM技法では、プロマネが個別のアクティビティ全てを進捗管理するなど無駄な労力であって、クリティカル・アクティビティとバッファー日数だけをきちんとコントロールしておき、あとの精神的余力は他の重要な事に取っておくべきだと考える。はいっても全体の進捗率計算が必要だが、この「プロマネの注意は重要な事だけに向けるべき」というのは、とても良い提案だと私は思っている。technology.。