進捗率にはいろいろな定義が可能である

進捗率にはいろいろな定義が可能である （2012/03/04）

ＩＴ業界の人からときどき聞く発言の一つに、「ＩＴプロジェクトではクリティカル・パス法なんか使えない」という主張がある。わたしはスケジューリングとかタイム・マネジメントの分野で長く仕事をしてきたが、こういう主張をＩＴ分野以外できいた覚えがない。ＩＴ業界人は知的な人が多いと思うが、自分達の仕事を“特殊な仕事”だと考える傾向も強いように思われる。無論ある意味では特殊な分野かもしれないが、だとしても1日の作業のあとに2日の作業をした場合、合計3日かかるのは、どんな仕事でも共通ではないか。なぜＩＴ業界の人だけ、“ウチの分野は1+2=3の算数が成立しない”といった意味のことを言いたがるのか？　当初はとても不思議に感じた。

しかし、話しあっていく内に、次第にＩＴ系の人たちの抱える不満、ないし問題がすこしずつ分かるようになってきた。クリティカル・パス法はいうまでもなく、プロジェクト全体を複数のアクティビティにブレークダウン（ＷＢＳ化）し、各アクティビティの期間と順序依存関係をもとに、全体の工期を推定する手法である。これ自体は非常に論理的な、いわば算法の世界だから、不服を申し立てる人はいない。問題は、そのアクティビティ所要期間の見積にあるのである。10日間のアクティビティＡ（たとえば設計）の後に20日間のアクティビティＢ（たとえば実装）をやった場合、全体で30日かかる、と、そこまではいい。難しいのは、設計が本当に10日で終わるのかどうか計画時点で誰も自信を持って見積もれないし、スタートして5日後に設計進捗率＝50%になってもちゃんと10日で終わるか不明だし、9日目になって前提条件がひっくり返り「さらに10日かかる」状態になるかもしれない、という点だ。こうした不確実性があるから、「ＰＥＲＴ／ＣＰＭなんか使えない」という不満が出てくるという事らしい。

ここでの問題を解きほぐすと、実は三種類の別の悩みが混じっていることが分かる。第一は、そもそも計画時点で期間見積をすることが難しいという点。第二に、途中の進捗状況から完了の『見込み日』を推定することが困難である、という点。そして第三が、途中でリワーク（手戻り）によるリスクがある点である。このサイトでは、第一の期間見積の精度向上については「マイルストーンは中点で測れ」ですでに論じたし、第三のスケジュール・リスクについては「時間のムダとり－－スケジュールのサバを切り捨てる」でも書いている。そこで、今回は二番目の『進捗率』の信頼性問題について考えてみよう。

情報処理技術者試験に「プロジェクトマネージャ」がある事は、ＩＴ業界のかたならご存じだろう。経済産業省の認定資格である。その2004年度の秋季に、進捗率に関するこんな問題があった（以下、筆者が一部改変して引用）：

• 10本のプログラムからなるシステムを完成させるプロジェクトがある。１本のプログラムを完成させるには１人月の工数がかかると見積もられた。
  
• 各プログラムの開発作業は、設計（20%）→コーディング（50%）→テスト（30%）のプロセスからなると推定された。
  
• 作業開始から15日たった時点で進捗状況を調べたら下記のとおりだった。現時点での進捗率を求めよ
  
  　　　　　　完了数（本）　予定工数（人月）　実績工数（人月）
  
  　設計　　　　　１０　　　　２．０　　　　　　２．５
  
  　コーディング　　６　　　　３．０　　　　　　４．０
  
  　テスト　　　　　３　　　　０．９　　　　　　１．５
  

なかなか面白い問題である。読者諸兄だったら、どう考えられるだろうか？

問題文には書いていないが、この10本のプログラムは、互いにまったく独立で、相互に連関はなく、作業は完全に平行に進める事ができるらしい（そんなプロジェクトばっかりだったら誰も苦労しないさ、というような批判は置いておく）。

進捗率の計算としては、ぱっと考えて三種類の方法がありそうだ。

（１）完成数基準。最後まで完成した本数の比率を、進捗率とする。つまり

　　３／１０＝３０％

（２）予定工数基準。問題文に工数見積の情報があるのだから、きっとこれを使うのだろう。すでに完了した作業の予定工数から計算する。

　（２．０＋３．０＋０．９）／１０＝５９％

（３）実績工数基準。いや、すでに消費した実績工数のデータで計算すべきだろう。

　（２．５＋４．０＋１．５）／１０＝７０％

あいにく当時の経産省系の試験はすべて、正解が公開されなかった。だから出題者がどれを念頭においたのかは分からないが、ここで推理してみよう。

念のためにいうが、進捗には、さまざまな定義が可能である。これは決め事の問題であって、その点では原価管理に似ている。同じ会社の同じ製品といえど、いろいろな原価の計算が可能である。原価にただ一つの正解は無い。進捗率も同じだ。しかし少なくとも、合理的な算定方法として合意できることが条件であろう。

完成数基準の計算：３／１０＝３０％、はどうだろうか。これはこれで単純至極な定義であり、問題はないように思える。しかし進捗管理の目的は、「この仕事はいつ終わるのか」を知る事であった。１５日目に進捗率３０％ならば、完成まで５０日かかる計算だから、あと３５日必要と言えるだろうか？　そうではなさそうである。そもそも、もしこの仕事が理想的な並列で進んだとしたら、ずっと完成本数＝０で、最終日にいきなり１０本完了、ということになる。横軸に時間、縦軸に進捗率をとってグラフを描いたら、ずっとゼロ％のままで、最終日に100％になる。このようなグラフを用いて、進捗管理（すなわち完了の予測）ができるだろうか？　完成数基準の進捗率はシンプルで分かりやすいが、こうしたケースでは進捗管理には向かないのである。

では、実績工数基準はどうか。この手法の問題点は、すでにお気づきのかたも多いだろう。もし仮に、現在までに9人月かかったとすると、進捗率は90％ということになる。12人月かかったら、120％進捗（？）になってしまう。これは明らかに不合理である。「予算消化率で進捗率は測れない」のであった。

だとしたら、消去法で、『予定工数基準』がこの問題の正解らしいと分かる。でも、なぜこれが正解なのか？　それは、“進捗はあとどれくらい仕事が残っているか”で測るのが原則だからである。現時点で、残っている作業の工数は、コーディングが４本、テストが７本であった。ということは、２＋２．１＝４．１（人月）、すなわち全体の４１％の仕事が残っている訳だ。だから進捗率５９％が正解なのである。ちなみに、この計算方法は、全部で３０個のサブ・アクティビティ単位における完成数基準で、重みづけに計画工数をつかったものだと説明することができる。そして、これこそ、アーンドバリュー・マネジメント・システム（ＥＶＭＳ）の考え方そのものであった。この問題は、だからＥＶＭＳの理解を問うのが目的だったらしい（ＥＶＭＳで完了までの期間をどう推計するかについては、長くなるので別の機会に述べよう）。

進捗率とか原価という概念は、案外危険な概念である。それは数字で示されて、分かったような気になりやすい。しかし、これらは人為的な尺度であって、いろいろな測り方ができ、目的に応じて使い分けなければいけない。間違った使い方をすれば、かえってミスリードなだけである。精度を議論するなら、その定義に立ち返って議論しなければならない。よく「製造業や建設業はモノが出来ていくから、進捗が目に見える」などと言う人がいるが、ことはそれほど単純ではない事を知るべきである。

そして、もう一点。アクティビティの期間にばらつきがあり、推定にリスクがともなう現象は別にＩＴ業界だけに限ったことではない。リスクの無いプロジェクトなどというものはない。これは共通の問題であり、共通の知恵が使えるのである。もちろんＩＴプロジェクトだけはリスクが極端に大きいのだ、と言えば言えよう。でも、だとしたら、ＰＥＲＴ／ＣＰＭを批判するだけでなく、それに代わる定量的な理論と手法を、なんとかして考案すべきであろう。そして、ＩＴ業界の人たちには、それをできるだけの知性と能力があると期待したいのである。