人気ブログランキング | 話題のタグを見る

EVMSとアーンド・スケジュール法の弱点 ~ プロジェクト予測のミクロとマクロ

前回の記事から2週間ほど間が空いてしまった。先週から欧州で、製造業系と石油ガス業界系の二つのカンファレンスに立て続けに参加していて、サイトの記事を書く時間がなかなか取れなかったのだ。最初の会議では、わたしの勤務先で最近つくった、2030年の未来を見据えた長期的な「IT Grand Plan 2030」(https://www.jgc.com/jp/news/assets/pdf/20181218_1.pdf)の講演発表もした。それなりに一応、好評だったと思う。

ところで、こういう国際カンファレンスに来るといつも思うのだが、欧米人はハイ・レベルな概念論が大の得意だ(ここでいうHigh levelとは、もちろん「高級品の話」ではなく、視点が高い=抽象的という意味である)。たとえばDigital transformationだとか、Ecosystemだとか、Sustainabilityとか、彼らの好きな言葉がある。一種の流行言葉でバズ・ワードであるが、彼らは自分のプレゼンで、必ずと言っていいほど、自分なりにその内容を言葉で定義する。その定義が皆と共通であれば、もっと良いと彼らは考えている。だから標準化だとかBOK(知識体系)とかが好きなのだろう。

ところが、そういう講演を聞いていると、どうしてもわたし達のような日本のエンジニアは、「だけど具体的にはどうなの?」という風につっこんで聞きたくなる。ある程度の具体性、現実味がないと、なんだか綿飴を噛んでいるような、歯ごたえのなさを感じてしまう。逆にいえば日本の技術者の発表は、えてしていきなりディテールに入りすぎるきらいがある。

ハイ・レベルで抽象度の高い議論と、ディテールにこだわる議論。その両方が必要なのは言うまでもない。その優先度がどちらにあるべきかで、洋の東西は意見が微妙に分かれている。もっとも、一口に「欧米」といったってアメリカと欧州は違うし、ヨーロッパだって南北でずいぶん違うのは事実だ。でも、日本との隔たりは非常に大きい。西洋人はとにかく、マクロに物事をとらえたがる。

さて、最近注目の「アーンド・スケジュール」という手法は、EVMS(Earned value management system)から派生した新しい手法である。EVMSがもつ、これまでのスケジュール把握における問題点、とくに完了日予測に関する困難を解決しようと工夫した点に、特徴がある。これが前回まで2回続きの記事で書いたことだった。ところが、アーンド・スケジュール法にも弱点がある。それが、スケジュール把握におけるマクロとミクロに関係しているのである。

例を挙げよう(つまり、数式で抽象的に説明するより、具体的なディテールを提示したほうが、読者にもわたし自身にも分かりやすいからだ)。

下の図は、あるプロジェクトの構造を図示したものだ。システム開発系のプロジェクトだが、WBSはかなり簡潔化してあり、わずか6個のActivityから構成している。図はそのActivity間の順序関係を示した「ロジック・ネットワーク」で、いわゆるprecedence diagram形式になっている。この図の見方については、ずいぶん以前に書いた記事「納期が延びる要因を指標化する - スケジュールのDRAGとはどんな尺度か」 https://brevis.exblog.jp/20000432/ (2013-03-25)を参照してほしい(ただし、以前の記事の図とは、意図的にいくつか数字を変えているので注意されたい)。

EVMSとアーンド・スケジュール法の弱点 ~ プロジェクト予測のミクロとマクロ_e0058447_05395335.jpg
このプロジェクトは基本設計で始まるが、その後、二つの並行する経路に分かれる。それがハードの調達系と、ソフトの開発系である。両者は総合テストで合流する。クリティカル・パスは、下側のソフト開発系にある。上側のハード調達系は、図中の四角の左上に示されるES(Earliest start=最早開始日)と、左下のLS(Latest start=最遅開始日)の数値に、10日分の差がある。これは、このアクティビティ系列に10日のFloat日数(余裕日数)があることを示している。

Float日数を持つアクティビティは、いつ開始するべきかについて、自由度がある。たとえば「ハード選定」は、最早開始日ES=20日だが、最遅開始日LS=30日だ。これを見て、プロマネのあなただったらどうするだろうか? 基本設計が終わったら、間髪を入れず、すぐにハード発注作業をする? だが、この作業は実稼働日で10日(つまりカレンダーでは半月ほど)余裕があるのだ。だったら、基本設計に続く詳細設計をまずちゃんとまとめて、それからハード発注に頭を切り替えても遅くはあるまい。

そういう前提で作業のシーケンスを考えると、それぞれの計画上の予定完了日と、その時点までの出費PVは、下の表1のようになるだろう。全体期間は75日。ちょうど中ごろの35日目に、累積のPVは250万円になる。

[表1 予定の出費(PV)]
EVMSとアーンド・スケジュール法の弱点 ~ プロジェクト予測のミクロとマクロ_e0058447_06033096.jpg

さて。実際にプロジェクトを進めていくと、(いつものことだが)設計上の問題が生じてしまった。10日で終わるはずの詳細設計の冒頭に手戻りが発生し、15日くらいかかりそうな状況だ。あなたの上司は(あるいは顧客でもいいが)、プロジェクトの週次レポートで、累積の出来高(EV値)が予定通り上がっていくかを、チェックしている。このままでは遅れが出て、あなたは叱責されかねない。

そこであなたは考えをかえ、詳細設計が終わってからやるつもりだった「ハード発注」を、基本設計後に前倒しして並列に行うことにした。おかげで25日目にハード発注は完了。「詳細設計」は遅れて35日目に完了した(実績を示す表2では、アクティビティの完了日の順序が、上の表と一部逆転しているので注意してほしい)。35日目の時点で、出来高EV値=250万円だ。PV=EVだから、つまり「アーンド・スケジュール」ES(t)=35日、ということになる。万歳、プロジェクトは遅れていないのだ!

[表2 実際の出来高(EV)]
EVMSとアーンド・スケジュール法の弱点 ~ プロジェクト予測のミクロとマクロ_e0058447_06083510.jpg
本当だろうか?

もちろん、間違っている。「詳細設計」はクリティカル・パス上のアクティビティなのだ。だから、この完了が5日遅れたら、プロジェクト全体の納期が確実に5日遅れてしまう。まあ、あなたがプログラマを余計動員して、ソフト開発の所用期間を5日以上短縮できれば別だが、そのためには余計にコストがかかるはずだ。(詳細設計の工数が増えたのだから、プロジェクトはすでに予定より赤字になっているが、それがさらに増えかねない訳だ)

いかがだろうか。アーンド・スケジュール法による進捗コントロールの、どこがおかしいのだろうか? アーンド・スケジュール法の論理も計算自体も、間違ってはいない。だが、明らかに、プロジェクトの遅れの検出に失敗しているのだ。

それはもちろん、アーンド・スケジュール法が、マクロなEVやES(t)の値しか見ていないことに原因がある。ロジック・ネットワークが示すように、プロジェクトの完成予定日は、クリティカル・パスの長さで決まる。それは、ネットワークの構造をミクロに見なければ、分からないのだ。この例は簡略化してあるので、6つしかアクティビティが無いから、よく見れば誰でもおかしい点が理解できる。

だがアクティビティが100個も200個もあったら、ネットワークをたどっていくのは大変だ。だからEVやES(t)などのマクロな指標で見よう、という気持ちはわからないでもない。でも、EVやES(t)は、それまでに完了した全てのアクティビティの合計指標だ。この中には、クリティカルな作業もそうでないものも、ともに含まれている。だから、たとえクリティカル・パスの作業が遅れても、フロートのある作業を前倒しで進めることで、見かけ上、進捗率を上げることができるのである。

別の言い方をすると、コスト視点とスケジュール視点では、アクティビティの「重要度」の尺度が異なるから、こういう事が起こる。スケジュールでは、クリティカル・パス上のアクティビティは、たとえ予算が小さくても重要だ。だが、EVMSでは予算(コスト)でしか重みをつけないから、スケジュール差異を正しく検知できないのだ。

ミクロを積み上げても、マクロにならない。マクロに良さそうに見えても、ミクロにはおかしい場合がある。これが『システム』というものの基本的性質だ。

プロジェクトは、アクティビティのネットワークで構成される、典型的なシステムである。そして、人が重要な役割を担い、また外乱的な変動にもさらされる、ひどく複雑なシステムでもある。この複雑さを、まだ適正なレベルで、うまく予測しハンドリングできる理論はできていない、というのが現時点でのわたしの感覚だ。

最初に述べた、わたしの勤務先の「IT Grand Plan 2030」では、プロジェクトという目に見えない対象のデジタル・ツィン=『Project Digital Twin』という概念の実現を目標にしている。デジタル・ツィンであるから、その上でシミュレーションができる必要がある。

しかし、現状のEVMSも、クリティカル・パス法も、その意味ではまだ、単純にすぎる。何より、決定論的すぎるという限界がある。シミュレーションを行って、プロジェクトの完了日や完成コストの予測をしようにも、一点しか答えが出てこない。台風の進路を予測して、一本しか線が描かれないようなものだ。現実のプロジェクトとは、もっとブレがあって、そのリスクとどう戦うかが一番大事なのに。

そして本物のプロジェクトは時々、崩壊現象を起こす。だからプロジェクトのシミュレーションも、ちゃんと崩壊現象を再現できなければならない。今のPERT/CPMやEVMSの、どこをどうひねくっても、崩壊現象など出てこない。

その意味で、わたしは今のプロジェクト・マネジメント理論にはまだ、『第一原理』が欠けていると思っている。材料物性を研究している人達は、量子力学の波動方程式という第一原理から出発して、マクロな多体問題を解き、物性を推算している。だが、不確実性をはらむプロジェクトの予測をするための基礎方程式は、どんな形をしているのだろうか? 

わたし達の旅路は、まだ始まったばかりである。

<関連エントリ>
 →「プロジェクトの進捗を計る『アーンド・スケジュール法』とは何か 〜 その内容と課題」 https://brevis.exblog.jp/28339485/ (2019-05-26)
 →「納期が延びる要因を指標化する - スケジュールのDRAGとはどんな尺度か」https://brevis.exblog.jp/20000432/ (2013-03-25)




by Tomoichi_Sato | 2019-06-10 06:17 | プロジェクト・マネジメント | Comments(0)
<< 「プロジェクト&プログラム・ア... プロジェクトの進捗を計る「アー... >>