概要 PERTは、プロジェクトの完了に関わるタスク、特に各タスクの完了に必要な時間を分析し、プロジェクト全体の完了に必要な最小時間を特定する手法です。すべての活動の詳細や期間が正確に分からなくてもプロジェクトのスケジュールを立てられるため、不確実性にも対応できます。開始と完了を重視するよりもイベント重視の手法であり、コストよりも時間が主要な制約となるプロジェクトでより多く用いられます。大規模で単発的、複雑で非定型的なインフラプロジェクトや、研究開発 プロジェクトなどに適用されます。
活動 とイベントの矢印と の図に依存する管理ツールを提供します。 矢印は、プロジェクト の各完了フェーズを示すイベントまたはノードに到達するために必要な 活動 または作業を表します。 [ 3 ]
PERTとCPMは補完的なツールです。なぜなら、「CPMは各アクティビティに対して1つの時間見積もりと1つのコスト見積もりを使用するのに対し、PERTは各アクティビティに対して3つの時間見積もり(楽観的、期待、悲観的)とコストを使用しない場合があるからです。これらは明確な違いですが、PERTという用語はすべてのクリティカルパススケジューリングにますます適用されるようになっています。」[ 3 ]
歴史 PERT は、主に大規模で複雑なプロジェクトの計画とスケジュールを簡素化するために開発されました。米国海軍特別プロジェクト局 、ロッキード・エアクラフト 、ブーズ・アレン・ハミルトン によって、海軍のポラリスミサイル 計画を支援するために開発されました。[ 4 ] [ 5 ] PERT は、産業界全体で応用されています。初期の例としては、1965 年以降、1968 年の大会の開会まで PERT を使用した1968 年のグルノーブル 冬季オリンピックがあります。 [ 6 ] このプロジェクトモデルは、この種のものとしては最初のものであり、フレデリック・テイラーの科学的管理 の復活であり、後にヘンリー・フォードによって改良されました (フォーディズム )。デュポン の CPM は、PERT とほぼ同時期に発明されました。
PERTサマリーレポート フェーズ2 、1958年当初PERTはProgram Evaluation Research Task の略でしたが、1959年までに改名されました。[ 4 ] 1958年に米国海軍省の2つの出版物、Program Evaluation Research Task, Summary Report, Phase 1 [ 7 ] とPhase 2 [ 8 ] で公表されました。どちらも主にチャールズ・F・クラークによって執筆されました。[ 1 ] 1959年のThe American Statistician誌 の記事で、米国海軍特別プロジェクト局プログラム評価支部長のウィラード・ファザーは 、PERTの主要概念を詳細に説明しました。彼は次のように説明しました。
PERT 手法は、電子計算機を用いて、最終目標達成に不可欠な主要な有限の成果 (イベント)、それらのイベント間の相互依存性、および連続する 2 つのイベント間で各アクティビティを完了するために必要な時間と時間範囲の推定値を表すデータを処理します 。このような時間の予測には、各アクティビティの「最も可能性の高い時間」、「楽観的な時間」、「悲観的な時間」の推定値が含まれます。この手法は、目標を期限内に達成できる見込みを評価し、経営判断を必要とする危険信号を強調し、目標達成のために実行しなければならない一連のアクティビティのフロー計画またはネットワークにおける体系性と余裕の両方を明らかにして定義し、現在の予測を予定された 完了日と比較し、予定された日付に間に合う確率を計算し、意思決定の前に意思決定の選択肢の影響をシミュレートする管理制御ツールです。[ 9 ]
PERT(経営管理向け)ガイド 、1963年6月PERTの導入から10年後、アメリカの司書 マリベス・ブレナンは、PERTとCPMに関する約150の出版物をまとめた選集を作成した。これらの出版物 はすべて1958年から1968年の間に出版されたものである。[ 3 ]
PERT [ 10 ] における作業単位の細分化のために、別のツールである作業分解構造 が開発されました。作業分解構造は「完全なネットワーク化のためのフレームワークを提供し、作業分解構造は、基本的な PERT/CPM を実行する際の最初の分析項目として正式に導入されました。」[ 11 ]
用語
イベントとアクティビティ PERT図では、主要な構成要素はイベント であり、既知の先行イベントおよび後続イベントとの接続があります。
PERTイベント :1つまたは複数のアクティビティの開始または完了を示すポイント。時間もリソースも消費しません。1つまたは複数のアクティビティの完了を示す場合、そのイベントに至るまでのすべて のアクティビティが完了するまで、「到達」(発生)とはみなされません。先行イベント :他のイベントを介さずに、他のイベントの直前に発生するイベント。1つのイベントは複数の先行イベントを持つことができ、また複数のイベントの先行イベントとなることもできる。後続イベント :他のイベントを介さずに、あるイベントの直後に発生するイベント。1つのイベントは複数の後続イベントを持つことができ、また複数のイベントの後続イベントとなることもできる。PERTはイベントだけでなく、活動やサブ活動も追跡します。
PERTアクティビティ :時間とリソース(労働力、材料、スペース、機械など)を必要とするタスクの実際の実行。これは、あるイベントから別のイベントへ移行するために必要な時間、労力、リソースを表すものと理解できます。PERTアクティビティは、先行イベントが発生するまで実行できません。PERTサブアクティビティ :PERTアクティビティは、さらに一連のサブアクティビティに分解できます。例えば、アクティビティA1は、A1.1、A1.2、A1.3に分解できます。サブアクティビティは、アクティビティのすべての特性を備えています。特に、サブアクティビティは、アクティビティと同様に、先行イベントまたは後続イベントを持ちます。サブアクティビティは、さらに細かいサブアクティビティに分解できます。
時間 PERTは、活動を完了するために必要な時間を4種類定義しています。
楽観的時間 :すべてが通常予想よりも順調に進むと仮定した場合に、活動(o)または経路(O)を達成するために必要な最小時間: 512悲観的時間 :あらゆる事態がうまくいかないと仮定した場合(ただし、重大な災害は除く)、活動(p)または経路(P)を完了するために必要な最大時間。: 512最も可能性の高い時間 :すべてが通常通り進行すると仮定した場合の、活動(m)または経路(M)を完了するのに必要な時間の最良推定値。: 512予想時間 :活動(te)または経路(TE)を完了するために必要な時間の最良の推定値であり、物事が常に通常通りに進むとは限らないという事実を考慮に入れたものである(つまり、予想時間は、タスクが長期間にわたって複数回繰り返された場合にタスクに必要な平均時間である)。: 512-513t e = o + 4 m + p 6 {\displaystyle te={\frac {o+4m+p}{6}}} T E = ∑ 私 = 1 n t e 私 TE=\sum _{i=1}^{n}te_{i}} 時間の標準偏差 :活動(σ te )または経路(σ TE )を完了するのにかかる時間のばらつきσ t e = p − o 6 σ T E = ∑ 私 = 1 n σ t e 私 2 {\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 + 4m + p )÷6の式で計算されます。: 512-513
この手順が完了したら、ガントチャート またはネットワーク図を描くことができます。
Microsoft Project (MSP)を使用して作成されたガントチャート。注: (1)クリティカルパス は赤色で表示されています。(2) スラックは 、クリティカルでないアクティビティに接続された黒線です。(3) 土曜日と日曜日は営業日ではないためスケジュールから除外されるため、ガントチャートの一部のバーは、週末をまたぐ場合は長くなります。OmniPlan を使用して作成されたガントチャート。注: (1)クリティカルパス が強調表示されています。(2)タスク 5 (d) ではスラックは 特に示されていませんが、タスク 3 と 7 (b と f) では確認できます。(3) 週末は細い垂直線で示され、作業カレンダーに追加のスペースを占有しないため、ガントチャートのバーは、週末をまたぐかどうかにかかわらず、長くなったり短くなったりしません。
次のステップは、ネットワーク図を手書きまたは図作成ソフトウェアを使用して作成することです。ネットワーク図は、 手書きまたは図作成ソフトウェアを使用して作成できます。ネットワーク図には、アクティビティ・オン・アロー ( 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 というラベルのノードに接続することをお勧めします (ただし、必須ではありません) 。
Microsoft Project (MSP)を使用して作成されたネットワーク図。クリティカルパス は赤色で示されています。
このようなノードを使用すると、アクティビティ名、期間、ES、EF、LS、LF、およびスラックを表示できます。
上記のネットワーク図単体では、ガントチャートと比べてそれほど多くの情報を提供するわけではありませんが、拡張することでより多くの情報を表示できます。最も一般的に表示される情報は次のとおりです。
アクティビティ名 予想される所要時間 早朝開始時間(ES) 早期終了時刻(EF) 遅延開始時刻(LS) 最終終了時刻(LF) スラック この情報を決定するために、アクティビティと通常の所要時間が与えられていると仮定します。最初のステップは、ESとEFを決定することです。ESは、対象となるアクティビティが最初のアクティビティでない限り、すべての先行アクティビティの最大EFとして定義されます。最初のアクティビティの場合、ESはゼロ(0)です。EFは、ESにタスクの所要時間を加えたものです(EF = ES + 所要時間)。
最初の活動であるため、開始時 のESはゼロです。期間がゼロなので、EFもゼロです。このEFは、a とb のESとして使用されます。a の ES はゼロです。ES に期間 (4 営業日) を加算して EF を 4 とします。この EF をc とd の ES として使用します。b のESはゼロです。ESに期間(5.33営業日)を加算して、EFは5.33となります。c のESは4です。ESに期間(5.17営業日)を加えると、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 です。ES に期間 (5.17 営業日) を加えると、EF は 14.34 になります。この EF をg の ES として使用します。f のESは10.33です。ESに期間(4.5営業日)を加えると、EFは14.83になります。g のESは14.34です。ESに期間(5.17営業日)を加えると、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作業日となります。
次のステップは、クリティカルパスと可能な余裕時間の決定です。次のステップは、クリティカルパス を特定し、アクティビティに余裕時間 があるかどうかを判断することです。クリティカルパスとは、完了までに最も時間 がかかるパスのことです。パス時間を決定するには、利用可能なすべてのパスのタスク期間を合計します。余裕時間のあるアクティビティは、プロジェクト全体の時間を変更せずに遅延させることができます。余裕時間は、slack = LF − EFまたは slack = 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営業日遅らせることができます)。
Microsoft Visio を使用して作成された完成版ネットワーク図。クリティカルパス は赤色で示されています。
ループを回避する クリティカルパスアルゴリズムのデータ入力フェーズの機能によっては、A → B → C → A のようなループを作成できる場合があります。これにより、単純なアルゴリズムが無限ループに陥る可能性があります。訪問済みのノードを「マーク」し、処理完了時に「マーク」を解除することも可能ですが、はるかに簡単なメカニズムとして、すべてのアクティビティ期間の合計を計算する方法があります。合計を超えるEFが見つかった場合は、計算を終了する必要があります。問題のあるリンクを特定するために、最近訪問した十数個のノードのIDを保存しておくと便利です。
利点 PERT図は、作業分解構造(一般的にWBSと呼ばれる)の要素間の 依存関係 (先行関係)を明確に定義し、可視化する。 PERTはクリティカルパスの特定を容易にし、それを可視化する。 PERTは、各アクティビティの早期開始、遅延開始、および余裕時間の特定を容易にします。 PERTは、依存関係をより深く理解することで、可能な限り活動やタスクの重複を改善し、プロジェクト期間を短縮できる可能性を秘めている。 膨大な量のプロジェクトデータは、意思決定に役立てるために、整理して図表にまとめることができる。 PERTは、指定された時間内に完了する確率を示すことができる。
デメリット 潜在的には、数百、あるいは数千もの活動と個々の依存関係が存在する可能性がある。 PERTを小規模プロジェクト向けに縮小するのは容易ではない。 ネットワーク図は一般的に大きくて扱いにくく、印刷には複数ページを要し、専用サイズの用紙が必要となる。 ほとんどのPERT/CPMチャートには時間枠がないため、ステータスを示すのが難しいが、色分けは役立つ場合がある。例えば 、完了したノードには特定の色を付けるなど。
プロジェクトスケジュールの不確実性 プロジェクト実行中、実際のプロジェクトは不確実性のため、計画通りに完全に実行されることは決してありません。これは、人為的ミスが生じやすい主観的な見積もりによる曖昧さ、あるいは予期せぬ出来事やリスクによる変動が原因である可能性があります。PERTがプロジェクト完了時間に関して不正確な情報を提供する主な理由は、このようなスケジュールの不確実性にあります。この不正確さは、PERTの見積もりを役に立たないものにするほど大きい場合があります。
ソリューションの堅牢性を最大限に高める方法の一つとして、ベースラインスケジュールに安全対策を組み込み、混乱を吸収できるようにする方法があります。これはプロアクティブスケジューリング と呼ばれますが、あらゆる混乱を想定すると非常に時間がかかり、ベースラインスケジュールでは対応できません。そこで、リアクティブスケジューリング と呼ばれる別のアプローチでは、ベースラインスケジュールでは吸収できない混乱に対応するための手順を定義します。
参考文献 1 2 Kelley, James E.; Walker, Morgan R.; Sayer, John S. (1989 年 2 月)。「CPM の起源: 個人的な歴史」。プロジェクト マネジメント 。3 (2)。プロジェクト マネジメント協会: 18。2024年 3 月 20 日 に取得 。 1 2 3 ブレナン、マリベス; PERTとCPM:厳選された参考文献 、計画図書館員協議会、モンティチェロ(イリノイ州)、1968年、p. 1 1 2 Malcolm, Donald G.; Roseboom, John H.; Clark, Charles E.; Fazar, Willard ; 「研究開発プログラム評価のための手法の適用」、 Operations Research 、第7巻、第5号、1959年9月~10月、646~669ページ ↑ Zimmerman, Steve; Conrad, Leo M. (1982 年 5 月). "Programming PERT in BASIC" . BYTE . pp. 465–478 . 2024 年 12 月 29 日 取得 . ↑ 1968年冬季オリンピック公式報告書、49ページ。2010年11月1日アクセス。(英語とフランス語) ↑ 米国海軍省、 プログラム評価調査タスク、概要報告書、フェーズ1 、政府印刷局、ワシントンDC、1958年 ↑ 米国海軍省、プログラム評価調査タスク、概要報告書、フェーズ2 、政府印刷局、ワシントンDC、1958年 ↑ ウィラード・ファザールの 引用元: Stauber, B. Ralph; Douty, Harry M.; Fazar, Willard; Jordan, Richard H.; Weinfeld, William; and Manvel, Allen D.; "Federal Statistical Activities" , The American Statistician , 13(2): 9–12 (1959年4月), pp. 9–12↑ クック、デズモンド・L.『プログラム評価とレビュー技法 』1966年、12ページ ↑ メイナード、ハロルド・ブライト 、『経営管理ハンドブック』、 1967年、17ページ
さらに読む プロジェクトマネジメント協会(2013)。プロジェクトマネジメント知識体系ガイド (第5 版)。プロジェクトマネジメント協会。ISBN 978-1-935589-67-9 。 クラストリン、テッド(2003)。プロジェクトマネジメント:ツールとトレードオフ (第3 版)。ワイリー。ISBN 978-0-471-41384-4 。 カーズナー、ハロルド (2009)。プロジェクトマネジメント:計画、スケジューリング、および管理へのシステムアプローチ (第10 版)。ワイリー。ISBN 978-0-470-27870-3 。ミロシェヴィッチ、ドラガン・Z. (2003).プロジェクトマネジメントツールボックス:実践的なプロジェクトマネージャーのためのツールとテクニック . ワイリー. ISBN 978-0-471-20822-8 。 ミラー、ロバート・W. (1963). PERTによるスケジュール、コスト、利益管理 ― プログラム管理のための包括的なガイド . マグロウヒル. ISBN 9780070419940 。 サポルスキー、ハーヴェイ・M. (1971). 『ポラリス・システム開発:政府における官僚的および計画的成功 』 ハーバード大学出版局。ISBN 0674682254 。
外部リンク PERT図に関連するメディアは、 Wikimedia Commonsで閲覧できます。