Delay Analysisの手法⑥　as planned impact/ Time Impact/ Windowsの比較～これからプロジェクトマネージャーになる人のためのDelay Analysisの基礎知識⑳～

ここまで、3つのDelay Analysisの手法を見てきました。

As planned impact

Time Impact

Windows

です。

これらは、それぞれに特徴を有しており、その特徴から導き出される長所と、そして短所・欠陥・問題点といったものを持っていました。

ここでは、それらを比較しながら見ていきたいと思います。こうすることで、それぞれの手法をより理解できるようになるはずです。

As planned impact

まず、As planned impactは、3つの中で一番簡単にできる手法です。

なぜなら、契約締結時、または契約締結後速やかに作成されたオリジナルの工程表であるAs planned programがあればできる手法だからです。

どんなEPC案件でも、どんな建設案件でも、as planned programがないなどということはまずないでしょう。

というのも、それがなければ、コントラクターは納期に間に合うのかどうか、自分でもわからないうちに仕事を受注して作業を始めるということになりますが、そんなコントラクターは、世の中にあるわけがないからです。

間に合うかどうか、プラント完成までにどんな仕事が必要になり、それらをどの順番で行うのかまだわかっていないけど、とにかく工事に手を付けよう！なんてコントラクターがいたら驚きです。また、そのようなコントラクターに仕事を依頼するオーナーも絶対にいないはずです。オーナーも納期に間に合うことを期待しているので、コントラクターがしようとしている全行程を把握しておきたいと思うはずだからです。完成が遅れると、オーナーは操業開始が遅れるという損失を被ることになります。その損失を全てコントラクターに負わせること等、通常は不可能です。納期遅延LDには上限があるのが通常であり、また、逸失利益は免責とされていることがほとんどだからです。このような契約条件の中で、as planned programがないのに仕事が開始されるなどということは、やはりあり得ないといえます。

もっとも、その中身の正確性はピンからキリまであるでしょう。

As planned programは、あくまで計画として作成されたものです。「Delay Analysisの手法④」で解説したように、コントラクターはプログラム中の納期に間に合わせる義務こそ負っているものの、そこに至る過程には法的な拘束力はないというのが通常です。最後に間に合いさえすれば、コントラクターは途中で遅れたとしても、計画とは異なる順番で仕事を遂行したとしても、オーナーに対して責任を負いません。

また、長期に渡る案件では、契約締結時にどこまで緻密に計画を立てられるか、という問題もあります。

こうしたことから、as planned program通りに仕事が遂行されるとは限らない、つまり、as planned programが、工事完了時に振り返ってみたときに、正しく実際の工事の進捗を反映しているわけではなかった、ということはいくらでも起こり得ます。

そのような性格をもつas planned programを基に、現実の工事の進捗状況を一切反映させずに、その結果、一度決められた工程はその後もずっと常に変わらないと仮定してDelay Analysisを行うのが、as planned impact methodなのです（※もっとも、納期延長となる事象の影響を入れ込んでいくので、当然、その範囲では変更されます。それ以外は全て不変だと捉えている、という意味です）。

工程に遅れを生じさせる事象が生じたときには、既にas planned programは実態を正しく反映しない状態になっているかもしれないのに、それでもなお、その点には目をつぶり、ひたすら遅れを生じさせる事象の影響をas planned programに入れ込んでいき、それによって納期に生じる影響を見ていくのです。

考えてみると、これはある意味すごい手法です。

「本当は違うんだけど・・・」と認識しながら行われる点がすごいと感じられないでしょうか。

このような手法が手法として曲がりなりにも存在するのは、やはり、それなりの理由があるのでしょう。

それは、「工事の進捗状況を初めから終わりまでずっと見続け、それをas planned programに反映していくことはとても難しい」という実務上の問題です。そしてこの問題が、業界内で、「確かにそうだ」と、ある程度認識されているのです。そうでなければ、as planned impactは、Delay Analysisの手法として到底認められない代物でしょう。もしも認められるとすれば、それは、契約締結後、かなり早い段階で生じた遅れに対してだけ、となるはずです。というのも、早い段階での遅れなら、as planned programは、実際の工事の進捗からそうかけ離れたものにはなっていないはずだからです（もっとも、as planned programがいい加減に作成されていたのなら、最初からズレているということも起こり得ますが・・・）。

上記の様な問題点をはらんではいるため、Delay Analysisの専門書の中には、「この手法では、コントラクターは、納期の遅れについての立証責任を果たしたとはいえない」とするものもあります。

しかし、とにかく、これはこれで１つの手法と認められてはいます。

そして、この手法の長所は、なんといっても、「簡単だ」ということです。

加えて、このas planned impactは、「Delay Analysisとは、概ねこのようなもの」という基本を示してくれます。つまり、「as planned programに遅れを入れ込む」という点です。この基本を理解していないと、Time ImpactもWindowsも極めて理解困難に陥ると思われますが、最初にこれを学んでおくことで、Delay Analysis全般に対する理解が促進・助長される、という役割もあるといえます。

Time Impact

次に、Time Impactです。

これは、as planned impactを発展させたものです。

遅れを生じさせる事象が起こるたびに、それまでの進捗状況をas planned programに反映させ、実態を表すものに更新していきます。

こうすることで、as planned impactと比べて、検討結果の精度が格段に高まるでしょう。

これをコントラクターが本当に実施してオーナーに提示したなら、オーナーはおそらく、何の反論の余地もないでしょう。「立証責任をはたしていない」などとはいえなくなるはずです。

しかし、その分、手間がかかります。工事の進捗状況に関する記録を緻密に取り、そして保存し、さらに、それを利用して工程表を更新させていく必要があります。

遅れを生じさせる事象が生じるごとにこの作業を行うので、そのような事象がたくさん生じれば生じるだけ、手間と労力がかかるはずです。

英国プロトコルはこの手法を推奨していますが、果たして、どれだけの企業がこの手法を忠実に遂行できているのか、私にはわかりません。

ただ、理論としては、確かに、正しい手法であるといえるでしょう。

Windows

次に、Windowsです。

これは、as planned programをいくつかの期間＝Windowに分け、そのWindowの期間が終了する毎に、as planned programを実態に合わせて更新させていくことで、完了予定日にどれだけ遅れが生じるかを見ていきます。

その上で、その遅れの原因はWindow内で起きたいかなる事象であったのか？を後から遡ってみていくのです。そして、納期延長が認められる事象が遅れの原因であった分だけ、コントラクターに納期延長が認められることになります。

ここで、このWindows methodは、as planned impactやTime Impactと比べて際立った特徴を示しているといえます。

それは何でしょうか？

答えは、Windowsは、「結果から原因を遡って検討する手法である」という点です。

Windowsは、Windowが終了する毎に検討するので、そのWindow内の事象は、既に現実に起こったことなのです。

一方、As planned impactやTime Impactは、まず、遅れを生じさせる事象を特定します。つまり、原因から出発します。その後、それがどれだけ工程に影響を与えることになるのか？という「未だ生じていない結果」を予想していきます。つまり、「原因から結果を予測する手法である」といえます。

このような違いがあるため、as planned impactとTime Impactは、「prospective（予測する）な手法」であり、Windowsは「retrospective（遡る）な手法」である、とよくいわれます。

このWindowsも、Time Impactと同様に、Window終了毎ではありますが、ともかく、工事の進捗状況のデータを取り、保管し、それに基づいて工程表を更新していくという手間のかかる作業が不可欠となります。

そのため、Time Impactほどではないかもしれませんが、as planned impactよりは、はるかに多くの手間と労力が必要となる手法といえます。

以下に3つの手法の特徴・長所・短所をまとめましたのでご参考ください。

【Delay Analysisの解説の目次】