プログラムの評価とレビューの手法

プログラム評価およびレビュー手法( PERT ) は、プロジェクト管理で使用される統計ツールであり、特定のプロジェクトの完了に必要なタスクを分析 して表現するために設計されました。

PERTはもともと1958年にチャールズ・E・クラークによってアメリカ海軍向けに開発され、 1958年に導入されたクリティカルパス法（CPM）と組み合わせて使用​​されることが多い。^[1]

PERT は、プロジェクトの完了に関わるタスク、特に各タスクの完了に必要な時間を分析し、プロジェクト全体の完了に必要な最小時間を特定する方法です。すべてのアクティビティの詳細と期間を正確に把握せずにプロジェクトをスケジュールできるようにすることで、不確実性を組み込んでいます。開始と完了を重視するよりもイベントを重視する傾向があり、コストよりも時間が主な制約となるプロジェクトでよく使用されます。非常に大規模で、1 回限りの複雑な非定型的なインフラストラクチャ プロジェクトや、R&Dプロジェクトに適用されます。

^{PERTは[2] : 497という}管理ツールを提供しており、これは「活動とイベントの矢印とノードの図に基づいています。矢印は、プロジェクト全体の完了した各フェーズを示すイベントまたはノードに到達するために必要な活動または作業を表します。」^[3]

PERT と CPM は補完的なツールです。「CPM は各アクティビティに対して 1 つの時間見積と 1 つのコスト見積を使用しますが、PERT は各アクティビティに対して 3 つの時間見積 (楽観的、期待的、悲観的) を使用し、コストは使用しません。これらは明確な違いですが、PERT という用語は、すべてのクリティカル パス スケジューリングにますます適用されています。」^[3]

PERTは主に、大規模で複雑なプロジェクトの計画とスケジュール作成を簡素化するために開発されました。これは、米国海軍のポラリス原子力潜水艦プロジェクトを支援するために、米国海軍特別プロジェクトオフィス向けに開発されました。 ^[4]これは産業界全体で応用されました。初期の例としては、1965年から1968年のオリンピック開幕までPERTが使用された1968年グルノーブル冬季オリンピックがあります。[ 5 ^{]このプロジェクトモデルは、フレデリック・テイラーの}科学的管理法を復活させたもので、後にヘンリー・フォード（フォーディズム）によって改良されました。デュポンのCPMは、PERTとほぼ同時期に発明されました。

PERTは当初、プログラム評価研究タスクの略称であったが、1959年までに改名された。^[4]これは1958年に米国海軍省の2つの出版物、「プログラム評価研究タスク、概要報告書、フェーズ1 ^」[6]および「フェーズ2」^[7]で公表された。どちらもチャールズ・F・クラークが中心となって執筆した。^{[1] 1959年の}アメリカ統計学者の記事で、米国海軍特別プロジェクト事務所プログラム評価部門長のウィラード・ファザールは、PERTの主要な概念について詳細に説明した。彼は次のように説明した。

PERT 技法は、電子コンピュータを使用して、最終目的の達成に不可欠な主要な有限の成果 (イベント)、それらのイベントの相互依存性、および2 つの連続するイベント間の各アクティビティを完了するために必要な時間と時間範囲の見積もりを表すデータを処理します。このような時間予測には、各アクティビティの「最も可能性の高い時間」、「楽観的な時間」、「悲観的な時間」の見積もりが含まれます。この技法は、目標を時間どおりに達成する見通しを評価し、管理上の決定を必要とする危険信号を強調し、フロー プランまたは目標を達成するために実行する必要がある一連のアクティビティのネットワークにおける方法論と余裕の両方を明らかにして定義し、現在の予測を予定完了日と比較し、予定日に間に合う可能性を計算し、決定前にオプションの効果をシミュレートする管理制御ツールです。^[8]

PERTの導入から10年後、アメリカの図書館員マリベス・ブレナンは、1958年から1968年の間に出版されたPERTとCPMに関する約150の出版物を収録した選書目録を編纂しました^。[3]

^{PERT [9]}における作業単位の細分化のために、別のツールが開発された。それは、作業内訳構造である。作業内訳構造は、「完全なネットワーク化のためのフレームワークを提供し、基本的なPERT/CPMを実行する際の最初の分析項目として正式に導入された。」^[10]

PERT 図では、主要な構成要素はイベントであり、既知の先行イベントおよび後続イベントに接続されます。

• PERT イベント: 1 つ以上のアクティビティの開始または完了を示すポイント。時間もリソースも消費しません。1 つ以上のアクティビティの完了を示す場合、そのイベントにつながるすべてのアクティビティが完了するまで、そのイベントには「到達」しません (発生しません)。
• 先行イベント: 他のイベントを介さずに、他のイベントの直前に発生するイベント。イベントには複数の先行イベントが存在する場合があり、複数のイベントの先行イベントになる場合もあります。
• 後続イベント: 他のイベントの直後に発生し、その間に他のイベントが介在しないイベント。イベントには複数の後続イベントが発生する場合があり、複数のイベントの後続イベントになる場合もあります。

PERT は、イベントの他に、アクティビティとサブアクティビティも追跡します。

• PERT アクティビティ: 時間を消費し、リソース (労働力、材料、スペース、機械など) を必要とするタスクの実際の実行。これは、あるイベントから別のイベントに移動するために必要な時間、労力、およびリソースを表すものとして理解できます。PERT アクティビティは、先行イベントが発生するまで実行できません。
• PERT サブアクティビティ: PERT アクティビティは、さらにサブアクティビティのセットに分解できます。たとえば、アクティビティ A1 は、A1.1、A1.2、A1.3 に分解できます。サブアクティビティには、アクティビティのすべてのプロパティがあります。特に、サブアクティビティには、アクティビティと同様に、先行イベントまたは後続イベントがあります。サブアクティビティは、さらに細かいサブアクティビティに分解できます。

PERT では、アクティビティを完了するために必要な時間を 4 種類定義しています。

• 楽観的時間：すべてが通常予想されるよりもうまく進むと仮定して、活動（o）または経路（O）を達成するのに必要な最小の時間^{[2] ：512}
• 悲観的時間：すべてがうまくいかないと仮定した場合（ただし大惨事は除く）、活動（p）または経路（P）を完了するために必要な最大可能時間。^{[2] ：512}
• 最も可能性の高い時間：すべてが通常通りに進むと仮定して、活動（m）または経路（M）を達成するのに必要な時間の最良の推定値。^{[2] ：512}
• 予想時間：物事が常に通常通りに進行するわけではないという事実を考慮した、活動（TE）または経路（TE）を達成するのに必要な時間の最良の推定値（つまり、予想時間は、タスクが長期間にわたって何度も繰り返された場合にタスクに必要な平均時間であることを意味します）。^{[2] ：512–513}

${\displaystyle te={\frac {o+4m+p}{6}}}$

${\displaystyle TE=\sum _{i=1}^{n}te_{i}}$

• 時間の標準偏差 : 活動 (σ _te ) または経路 (σ _TE )を達成するための時間の変動

${\displaystyle {\begin{aligned}&\sigma _{te}={\frac {po}{6}}\\[8pt]&\sigma _{TE}={\sqrt {\sum _{i=1}^{n}{\sigma _{te_{i}}}^{2}}}\end{aligned}}}$

PERT は、次のような概念の決定を伴う管理のためのさまざまなツールを提供します。

• フロートまたはスラックは、タスクを完了するために使用できる余剰時間とリソースの尺度です。これは、後続のタスク (フリー フロート) またはプロジェクト全体 (合計フロート) に遅延を引き起こすことなく、プロジェクト タスクを遅らせることができる時間の量です。プラスのスラックはスケジュールより進んでいることを示し、マイナスのスラックはスケジュールより遅れていることを示し、スラックがゼロの場合はスケジュールどおりであることを示します。
• クリティカル パス: 最初のイベントから終了イベントまでの、可能な限り最長の連続経路。これにより、プロジェクトに必要な合計カレンダー時間が決定されます。したがって、クリティカル パスに沿った時間の遅延は、終了イベントへの到達を少なくとも同じ時間だけ遅らせます。
• クリティカル アクティビティ: 合計フリー フロートがゼロのアクティビティ。フリー フロートがゼロのアクティビティは、パスが最長ではない可能性があるため、必ずしもクリティカル パス上にあるとは限りません。
• リードタイム:特定の PERT イベントが完了するまでに経過する必要があるアクティビティに十分な時間を確保するために、先行イベントを完了する必要がある時間。
• 遅延時間:特定の PERT イベントの後に後続イベントが続くことができる最も早い時間。
• ファストトラッキング：より重要な活動を並行して実行する
• クリティカルパスのクラッシュ：重要な活動の期間の短縮

プロジェクトのスケジュールを立てる最初のステップは、プロジェクトに必要なタスクと、そのタスクを完了する順序を決定することです。タスクによっては順序の記録が簡単なもの (たとえば、家を建てる場合、基礎を築く前に土地を整地する必要がある) もあれば、難しいものもあります (整地が必要なエリアが 2 つあるが、ブルドーザーは 1 つしか用意できない)。また、時間の見積もりは通常、急いでいない場合の通常の時間を反映しています。多くの場合、タスクの実行に必要な時間は、追加コストや品質の低下と引き換えに短縮できます。

次の例では、 AからGまでラベルの付いた 7 つのタスクがあります。タスクの中には同時に実行できるもの ( AとB ) もあれば、先行タスクが完了するまで実行できないものもあります ( C はAが完了するまで開始できません)。さらに、各タスクには 3 つの時間見積もりがあります。楽観的な時間見積もり ( o )、最も可能性の高いまたは通常の時間見積もり ( m )、悲観的な時間見積もり ( p ) です。予想時間 ( te ) は、式 ( o + 4 m + p ) ÷ 6を使用して計算されます。^{[2] : 512–513}

このステップが完了すると、ガントチャートまたはネットワーク図を描くことができます。

ネットワーク図は、手作業またはダイアグラム ソフトウェアを使用して作成できます。ネットワーク図には、アクティビティ オン アロー ( AOA ) とアクティビティ オン ノード ( AON ) の 2 種類があります。アクティビティ オン ノード図の方が、一般的に作成と解釈が簡単です。AON 図を作成するには、startという名前のノードから開始することをお勧めします (必須ではありません) 。この「アクティビティ」の所要時間はゼロ (0) です。次に、先行アクティビティのない各アクティビティ (この例ではaとb ) を描画し、 start から各ノードへの矢印で接続します。次に、cとd の両方でa が先行アクティビティとしてリストされているため、それらのノードはaからの矢印で描画されます。アクティビティeは、 bとc が先行アクティビティとしてリストされているため、ノードe はbとc の両方からの矢印で描画され、 bとcの両方が完了するまでe を開始できないことを示します。アクティビティf はd が先行アクティビティであるため、アクティビティを接続する矢印が描画されます。同様に、 eからgへの矢印が描画されます。fまたはg の後にアクティビティがないため、それらを「finish」というラベルの付いたノードに接続することをお勧めします (ただし、必須ではありません) 。

上に示したネットワーク図だけでは、ガント チャートよりも多くの情報を提供することはできませんが、拡張してより多くの情報を表示できます。表示される最も一般的な情報は次のとおりです。

1. アクティビティ名
2. 予想される継続時間
3. 早い開始時間（ES）
4. 早い終了時間（EF）
5. 開始時刻が遅れる（LS）
6. 遅い終了時間 (LF)
7. たるみ​

この情報を決定するには、アクティビティと通常の所要時間が与えられていることが前提となります。最初のステップは、ES と EF を決定することです。ES は、すべての先行アクティビティの最大 EF として定義されます。ただし、問題のアクティビティが最初のアクティビティである場合は、ES はゼロ (0) になります。EF は、ES とタスク所要時間の合計です (EF = ES + 所要時間)。

• startは最初のアクティビティなので、 ES はゼロです。duration はゼロなので、 EF もゼロです。この EF はaとbの ES として使用されます。
• aの ES はゼロです。期間 (4 営業日) を ES に追加すると、EF は 4 になります。この EF はcとdの ES として使用されます。
• bの ES はゼロです。期間 (5.33 労働日) を ES に追加すると、EF は 5.33 になります。
• cの ES は4 です。期間 (5.17 労働日) を ES に追加すると、EF は 9.17 になります。
• dの ES は4 です。期間 (6.33 労働日) を ES に追加すると、EF は 10.33 になります。この EF はfの ES として使用されます。
• eの ES は、先行するアクティビティ ( bとc ) の最大の EF です。bの EF は 5.33、cの EF は 9.17 なので、 eの ES は9.17 です。期間 (5.17 労働日) を ES に追加すると、 EF は 14.34 になります。この EF がgの ES として使用されます。
• fの ES は10.33 です。期間 (4.5 営業日) を ES に追加すると、EF は 14.83 になります。
• gの ES は14.34 です。期間 (5.17 労働日) を ES に追加すると、EF は 19.51 になります。
• 終了の ES は、先行アクティビティ ( fとg )の最大の EF です。 fの EF は 14.83、gの EF は 19.51 なので、終了の ES は19.51 です。 終了はマイルストーン (したがって期間はゼロ) なので、EF も 19.51 です。

不測の事態が発生しない限り、プロジェクトは 19.51 実働日で完了するはずです。次のステップは、各アクティビティの遅延開始 (LS) と遅延終了 (LF) を決定することです。これにより、余裕のあるアクティビティがあるかどうかが最終的にわかります。LF は、アクティビティが最後のアクティビティでない限り、すべての後続アクティビティの最小 LS として定義されます。最後のアクティビティの場合、LF は EF と等しくなります。LS は、LF からタスク期間を引いたものです (LS = LF − 期間)。

• 終了の LF は、プロジェクトの最後のアクティビティであるため、 EF (19.51 作業日) と等しくなります。期間がゼロであるため、 LS も 19.51 作業日です。これは、 fとgの LF として使用されます。
• gの LF は19.51 労働日です。期間 (5.17 労働日) を LF から差し引くと、LS は 14.34 労働日になります。これがeの LF として使用されます。
• fの LF は19.51 労働日です。期間 (4.5 労働日) を LF から差し引くと、 LS は 15.01 労働日になります。これがdの LF として使用されます。
• eの LF は14.34 労働日です。期間 (5.17 労働日) を LF から差し引くと、 LS は 9.17 労働日になります。これがbとcの LF として使用されます。
• dの LFは 15.01 労働日です。期間 (6.33 労働日) を LF から差し引くと、LS は 8.68 労働日になります。
• cの LF は9.17 労働日です。期間 (5.17 労働日) を LF から差し引くと、LS は 4 労働日になります。
• bの LFは 9.17 労働日です。期間 (5.33 労働日) を LF から差し引くと、LS は 3.84 労働日になります。
• aの LF は、その後続のアクティビティの最小 LS です。c の LS は 4 労働日、d の LS は 8.68 労働日なので、 aのLF は4労働日です。期間 (4 労働日) を LF から差し引くと、LS は 0 労働日になります。
• 開始の LF は、後続アクティビティの最小 LS です。aのLSは 0 作業日で、b のLS は 3.84 作業日なので、LS は 0 作業日です。

次のステップは、クリティカル パスを決定し、アクティビティにスラックがあるかどうかを確認します。クリティカル パスとは、完了までに最も長い時間がかかるパスです。パス時間を決定するには、使用可能なすべてのパスのタスク期間を追加します。スラックがあるアクティビティは、プロジェクト全体の時間を変えずに遅らせることができます。スラックは、スラック = LF − EFまたはスラック = LS − ES のいずれかの方法で計算されます。クリティカル パス上のアクティビティのスラックはゼロ (0) です。

• パスADFの期間は14.83 営業日です。
• パスacegの期間は19.51 営業日です。
• パス開始の期間は15.67 営業日です。

クリティカル パスはacegで、クリティカル タイムは 19.51 作業日です。クリティカル パスは複数存在する場合があり (この例よりも複雑なプロジェクトの場合)、クリティカル パスが変わることもあるので注意が必要です。たとえば、アクティビティdとf が、予想時間 (T _E )ではなく悲観時間 (b) で完了するとします。クリティカル パスはadf になり、クリティカル タイムは 22 作業日になります。一方、アクティビティcを 1 作業日に短縮できる場合、acegのパス時間は 15.34 作業日に短縮され、新しいクリティカル パスbeg (15.67 作業日) よりわずかに短くなります。

これらのシナリオが発生しないと仮定すると、各アクティビティの余裕を判断できるようになります。

• 開始と終了はマイルストーンであり、定義上は期間がないため、余裕期間 (0 作業日) はありません。
• クリティカル パス上のアクティビティは定義上、スラックがゼロになりますが、手書きで描画する場合には必ず計算をチェックすることをお勧めします。
  • LF _a – EF _a = 4 − 4 = 0
  • LF _c – EF _c = 9.17 − 9.17 = 0
  • LF _e – EF _e = 14.34 − 14.34 = 0
  • LF _g – EF _g = 19.51 − 19.51 = 0
• アクティビティbの LF は 9.17、EF は 5.33 なので、余裕期間は 3.84 作業日となります。
• アクティビティdの LF は 15.01、EF は 10.33 なので、余裕は 4.68 作業日になります。
• アクティビティfの LF は 19.51、EF は 14.83 なので、余裕は 4.68 作業日になります。

したがって、アクティビティb は、プロジェクトを遅らせることなく、ほぼ 4 営業日遅らせることができます。同様に、アクティビティd またはアクティビティf は、プロジェクトを遅らせることなく、4.68 営業日遅らせることができます (または、dとf をそれぞれ 2.34 営業日遅らせることができます)。

クリティカル パス アルゴリズムのデータ入力フェーズの機能によっては、A -> B -> C -> A などのループを作成できる場合があります。これにより、単純なアルゴリズムが無限にループする可能性があります。アクセスしたノードを「マーク」し、プロセスが完了したら「マーク」をクリアすることもできますが、はるかに単純なメカニズムでは、すべてのアクティビティ期間の合計を計算します。合計を超える EF が見つかった場合は、計算を終了する必要があります。問題のリンクを識別するために、最近アクセスした 12 個程度のノードの ID を保存しておくと便利です。

• PERT チャートは、作業分解構造 (通常はWBS ) 要素間の依存関係(先行関係) を明示的に定義し、可視化します。
• PERT はクリティカル パスの識別を容易にし、可視化します。
• PERT を使用すると、各アクティビティの早期開始、遅延開始、余裕時間の特定が容易になります。
• PERT では、依存関係をより深く理解することで、可能な場合にはアクティビティとタスクの重複が改善され、プロジェクト期間が短縮される可能性があります。
• 大量のプロジェクト データを整理して図に表示し、意思決定に役立てることができます。
• PERT は、指定された時間内に完了する確率を提供できます。

• 潜在的に数百または数千のアクティビティと個々の依存関係が存在する可能性があります。
• PERT は、小規模なプロジェクト向けにスケールダウンするのは簡単ではありません。
• ネットワーク チャートは大きくて扱いにくい傾向があり、印刷するには複数のページが必要で、特別なサイズの用紙が必要になります。
• ほとんどの PERT/CPM チャートには時間枠がないため、ステータスを示すのが難しくなりますが、完了したノードに特定の色を付けるなど、色を使用するとわかりやすくなります。

プロジェクトの実行中、実際のプロジェクトは不確実性のため、計画どおりに実行されることはありません。これは、人為的ミスを起こしやすい主観的な見積もりから生じる曖昧さや、予期しないイベントやリスクから生じる変動性の結果である可能性があります。PERT がプロジェクト完了時間について不正確な情報を提供する主な理由は、このスケジュールの不確実性によるものです。この不正確さは、そのような見積もりが役に立たないほど大きい場合があります。

ソリューションの堅牢性を最大限に高める 1 つの方法は、混乱を吸収するためにベースライン スケジュールに安全性を組み込むことです。これはプロアクティブ スケジューリングと呼ばれますが、起こり得る混乱をすべて考慮すると非常に時間がかかり、ベースライン スケジュールでは対応できません。リアクティブ スケジューリングと呼ばれる 2 番目のアプローチは、ベースライン スケジュールで吸収できない混乱に対処する手順を定義します。

• ウィキメディア・コモンズの PERT 図に関連するメディア