PERT

PERT (ぱーと, 英: Program Evaluation and Review Technique）とは、プロジェクトマネジメントの際に用いられる手法の一つ。特定のプロジェクトの完遂までに必要なタスクを洗い出し、相互関係を明確にすることによってプロジェクトを素早く達成することを目的とする。Project Evaluation and Review Techniqueとも。
概要.
PERTは、対象とするプロジェクトの完遂に必要なタスクを分析する手法であり、特に各タスク完了に必要な時間を分析し、プロジェクト全体を完了させるのに必要な最小時間を特定する。
このモデルは、ブーズ・アレン・ハミルトンが1958年、アメリカ国防総省 US Navy Special Projects Office からの委託の一環で、ポラリス潜水艦発射弾道ミサイルプロジェクトの一部として発明したものである。このプロジェクトはスプートニク・ショックへの直接的な反応の1つであった。アメリカ政府の一部の契約では、PERTを管理手法の1つとすることが義務付けられた。
PERTは主に大規模で複雑なプロジェクトの計画立案とスケジューリングを単純化するために開発された。全作業の正確な詳細と期間が不明であっても、不確実性を含んだままプロジェクトのスケジューリングが可能になっている。開始・終了指向というよりもイベント指向の技法というべきであり、コストよりも時間が主要な要因となる研究開発プロジェクトに向いている。
このプロジェクトモデルはフォーディズムと科学的管理法で確立された科学的管理の延長線上にある。PERTとほぼ同じ頃、デュポンでクリティカルパス法を考案している。
PERTの最も特徴的な図として「PERT図」がある。これは、線表を矢印で相互接続した図（アローダイアグラム）である。PERTは、非常に大規模で1度限りの紋切り型でない複雑なプロジェクトに向いている。
実施手順.
プロジェクトのスケジューリングの第一歩は、プロジェクトに必要なタスクを洗い出し、それらの完了順序を決定することである。順序が容易に決められるタスクもあれば（例えば、家を建てる場合、基礎工事の前に土地を整地する必要がある）、難しいタスクもある（整地が必要な部分が 2 か所あるが、ブルドーザーが 1 台しかない場合など）。さらに、所要時間には通常時の見積もりをする。あるタスクを実行するための時間は、実際には必要に迫られて短縮されることが多い。
以下の例では、a から g までの 7 つのタスクを考える。一部のタスク（a と b）は同時に実施できるが、他は先行タスクが完了するまで実施できない（c は a が完了するまで開始できない）。さらに、それぞれのタスクには 3 種類の見積もり時間がある。楽観的見積もり時間 (q)、最確見積もり時間または正常見積もり時間 (m)、悲観的見積もり時間 (p) である。期待時間 (TE) は (q + 4m + p) / 6 という式で計算する。
次に、ガントチャートかネットワーク図を描く。
ネットワーク図は人間が描くこともできるし、作図ソフトウェアで描くこともできる。ネットワーク図には、矢印を作業とする図 (Activity on Arrow) と、ノードを作業とする図 (Activity on Node) との2種類がある。日本では、説明にはよく前者を用いていて、その図をアローダイアグラム（矢線図）と呼んでいる。このほうが（前後のノードでの）時刻の重複がないので、手間が少なくなる。
しかし、ノード（ここでは四角形で表す）を作業とする図のほうが作成と理解が容易なので、ここではそういう図を作成する。まず、Start と名づけたノードから作図を開始する。この「作業」にかかる時間はゼロ (0) である。次に先行作業のない作業（例では a と b）を描き、ノード Start からそれらに矢印を描く。c と d の先行作業は a なので、これらのノードを描き a から矢印を引く。e の先行作業は b と c となっているので、ノード e を描いて b と c から矢印を引く。作業 f の先行作業は d なので、そのように節と矢印を描く。同様に、e から g へ矢印を描く。f と g の後には作業がないので、ノード Finish を描いて、f および g から矢印を引けばよい。
このようにして描いたネットワーク図は、ガントチャートに比較して情報が多いわけではない。しかし、この図に表示する情報を追加することができる。一般に以下のような情報が書き込まれる。
これらの値を決定するため、作業とその標準見積もり時間は判っているものとする。まず、ES と EF を決定する。ES は全先行作業の EF の最大値で定義される。その作業が最初の作業の場合、ES は 0 となる。EF は ES にその作業の見積もり時間を足した値となる。
予期しないイベントがない限り、このプロジェクトは 19.51 実働日で完了すると期待できる。次に LS と LF を決定する。これによって、各作業にスラックがあるかどうかを示すことになる。LF は全後続作業の LS の最小値と定義される。最後の作業の場合、LF と EF は等しい。LS は LF からそのタスクの見積もり時間を引いた値になる。
続いて、クリティカルパスを決定し、もしあればスラックのある作業を特定する。クリティカルパスは完了までの最長の経路である。このため、全経路についてタスクの見積もり時間の累計を計算する。スラックのある作業はプロジェクト全体には影響を与えずに遅延させることができる。スラックの計算方法は 2 種類あり、LF - EF または LS - ES で求められる。クリティカルパス上の作業のスラックは常に 0 である。
以上からクリティカルパスは a-c-e-g であり、クリティカル時間は 19.51 実働日となる。もっと複雑なプロジェクトでは、複数のクリティカルパスのある場合も考えられるし、クリティカルパスが変化することもある。例えば、d と f が期待時間 (TE) ではなく悲観的見積もり時間 (p) だけかかるとする。するとクリティカルパスは a-d-f になり、クリティカル時間は 22 実働日となる。一方、c を 1 実働日に短縮できた場合、a-c-e-g は 15.34 実働日に短縮され、新たに b-e-g（15.67 実働日）がクリティカルパスになる。
以上のような変動はないものとすれば、スラックは次のように決定される。
したがって、作業 b は約 4 実働日だけ遅延してもプロジェクト全体には影響しない。同様に 作業 d または f も全体への影響なしに 4.68 実働日だけ遅延可能である（ただし、両方がそれだけ遅延すると全体に影響が出る）。