プロジェクトのネットワーク表現
数多くの作業（タスク）が相互に関連しながら，ある決まった期間の中で一つの目的を達成するための仕事を，一般に「プロジェクト」とよぶことはご存じだと思います。たとえば，製品開発における一つの開発案件の遂行，受注生産における一つの製番の設計から製造出荷までの作業，あるいは展示会によるセールスプロモーション活動などは，いずれもプロジェクトです。複数の人間が協力しながら進める仕事のスケジューリングとは，プロジェクトのスケジュールを計画することにほかならないのです。
このプロジェクト･スケジューリングにおいて重要な考え方が「クリティカル・パス」です。日本語では「隘路（あいろ）」とよびます。クリティカル・パスはプロジェクトの納期を左右する要素であり，これを見つける手法がCritical Path Method＝ＣＰＭです。ＣＰＭは1950年代に米国のデュポン社で開発され，以降半世紀にわたりプロジェクト管理の主要な道具となってきました。
ＣＰＭでは，プロジェクトをネットワークの形に図で表現することからはじめます。プロジェクトを構成するWBSの全タスクをリストアップし，その順序関係を定め，さらに所要時間を推定して，スケジュールのネットワーク表現を作成するのです。これによって，スケジュール全体を見通しよく把握できるようになります。
図的表現はいくつかの流儀があるのですが，ここではプロジェクト・ネットワーク・ダイアグラムをご紹介します。この方法では，タスクを四角で表し，タスク間の依存関係を矢印で表現します（なお，ネットワーク図ではタスクのことを「アクティビティ」とよぶ慣習もあります）。このとき，タスクの四角の中を，さらに７つの小さな区画に分けておきます。真ん中の区画に，タスクの内容を表すわかりやすい名称を書きます。その上の区画には，WBS番号を，またその下の区画には，推定所要時間を書いておきます（図1）。
図1 タスクの図的表現
![図1 タスクの図的表現]( "図1 タスクの図的表現")
図2は，前回（第7回「仕事の工程表をつくる」）で例として出した新製品開発プロジェクトを図示したものです。
図2 プロジェクト・ネットワーク・ダイアグラム
![図2 プロジェクト・ネットワーク・ダイアグラム]( "図2 プロジェクト・ネットワーク・ダイアグラム")
クリティカル・パス
さて，プロジェクトの最初のタスクから，最後の終了タスクまでをつなぐ経路は，ネットワークの中でいくつもあります。たとえば，図2では
- 1 → 2.1 → 3.1 → 5.1 → 5.2
- 1 → 2.2 → 3.2 → 3.3 → 5.1 → 5.2
- 1 → 2.3 → 4 → 5.1 → 5.2
- 1 → 2.1 → 3.2 → 3.3 → 5.1 → 5.2
など，いろいろ考えられます。
これらの中で，所要時間合計が最も長い経路をクリティカル・パスといいます。そして，プロジェクト全体の所要時間は，クリティカル・パスの長さに等しいのです。逆に言うと，クリティカル・パスの長さがプロジェクトの納期を決めることになります。プロジェクトの納期を，クリティカル・パスよりも短く約束してしまったら，最初から実行不可能な計画になるわけです。
クリティカル・パスを求める手順は以下の通りです：
- あるタスクに先行するタスクが一つだけ存在するときは，先行タスクの終了日を，そのタスクの最早開始日（Earliest Start = ES）とする。
- 先行タスクが複数存在するときには，先行タスクの終了日の中で最も遅い日を，そのタスクの最早着手日とする。
- タスクの最早開始日に作業時間を加えて，最早終了日を求める（Earliest Finish = EF）。
- この計算を，プロジェクトの開始点から順番に終了点まで行なう。最後のタスクの最早終了日が，プロジェクト全体の完了日である。
- プロジェクトの終了点に達する複数のタスクのうち，所要時間の最もかかるタスクを選ぶ。この操作を順次さかのぼると，クリティカル・パスが得られる。
図3 クリティカル・パスの求め方
![図3 クリティカル・パスの求め方]( "図3 クリティカル・パスの求め方")
（1）最初のタスクの最早開始日と最早終了日を計算する
（2）タスク間の依存関係にしたがって，後続のタスクの最早開始日と最早終了日を順に求める
（3）最後のタスクまで到達したら，そこから逆に，最遅終了日・最遅開始日を順に求める
（4）最早開始日＝最遅開始日の経路をたどって，クリティカル・パスを特定する
図3の赤線で示した経路がクリティカル・パスであり，オレンジ色のタスクが，そのパスを構成するタスクです。
「フロート日数」を知る
さて，クリティカル・パスがプロジェクトの納期を決めるわけですから，納期短縮を図りたいときは，まずクリティカル・パス上にのっているタスクの短縮をはかる必要があります。言いかえると，クリティカルでないタスクを，いくら短縮しても全体の納期は縮まらないのです。
クリティカルでないタスクには，すなわち作業上の余裕日数があるわけです。これを「フロート日数」といいます。ここではその計算方法を示しましょう。
各タスクの最早開始日・最早終了日とクリティカル・パスが決まったら，以下の手順で最遅開始日・最遅終了日を計算します。
- タスクの最遅終了日（Latest Finish = LF）とは，それに後続するタスク群の中で最も早い最遅開始日に等しい。
- タスクの最遅終了日から作業時間を引いて，最遅開始日（Latest Start = LS）を求める。
- プロジェクトの最終タスクからさかのぼって，すべての先行タスクの最遅開始日を順次計算する。
各タスクの「最遅開始日－最早開始日」の日数が，そのタスクの「フロート日数」です。たとえば，2.2「市場調査」のフロート日数は８－５＝３日ですし，2.3「要素技術の検討」のフロート日数は１５－５＝１０日となります。もし，「要素技術の検討」の完了が数日遅れても，それがフロート日数の１０日よりも小さければ，プロジェクトの全体スケジュールには影響を与えません。ただし，これが１０日以上遅れると，今度はクリティカル・パスがこちらを通る経路に移ってしまうことに注意してください。
クリティカル・パス上のタスクは原理上，フロート＝０日であり，とうぜん遅れは許されません。大規模プロジェクトでは一般に，クリティカル・パスにあるタスクは全タスクの20%以内であると言われています。つまり，プロジェクトの納期を守りたければ，全体の2割程度の重要なタスクをしっかりと着目していればいいということになります。これが，プロジェクトにおけるタイム・マネジメントの要点なのです。
