進捗率を何で測るか？ −−情報処理技術者試験の問題より

仕事の進捗（しんちょく＝進み具合）を何で測り、どう数値化するか。これはいつも悩ましい問題である。

「プラント・エンジニアリング会社のように、物理的に目に見えるモノを作っている分野は、数量が測りやすいからいい。ソフトのように目に見えない成果物を作る仕事は、進捗管理がとても難しい。」

・・こういう意味のことを、IT業界の方から何度か言われたこともある。いえいえ、どういたしまして。プラント・エンジニアリングのプロジェクトでは、設計業務だけで18ヶ月〜24ヶ月もかかる。この間、膨大な図面や仕様書が生成されるが、プラント予定地では１年後にやっと、基礎工事のための穴掘りが始まる程度だ。設計作業の進捗をどう捉えるかは、同じように悩ましい。

もちろん、具体的なものづくりに携わっている企業だって、進捗をタイムリーに正確につかむのは難しい。同時並行に進む作業が多いし、その負荷の大小だって、様々だからだ。

ところで、情報処理技術者試験に「プロジェクトマネージャ」という種目がある。IPAの試験制度の中でも、いわゆる「高度」に分類される資格の一つだ（一応、わたしも持っている）。さて、今を去る2004年秋のことだが、この試験に、進捗率に関して、次のような問題が出たことがある（一部佐藤が改編して引用）：

* １０本のプログラムからなるシステムを完成させるプロジェクトがある。

* １本のプログラムを完成させるには１人月の工数がかかると見積もられた。

* 各プログラムの開発作業は、設計（20%）→コーディング（50%）→テスト（30%）のプロセスからなると推定された。

* 作業開始から15日たった時点で進捗状況を調べたら下記のとおりだった：

* 現時点での進捗率を求めよ

・・という問題である。

どうやらこのシステム、ほぼまったく同一規模のサブシステム・プログラム10本からなっていて、なおかつ、その間のインタフェースも結合テストもいらないらしい。随分とありそうにない、不自然なシステムだが、まあ試験問題だから文句を言っても仕方がない。

とにかく10個のタスク（アクティビティ）があり、それぞれが設計・コーディング・テストの3段階からなるから、全部で30個のサブタスク（サブ・アクティビティ）から構成されたプロジェクトだ、ということになる。

進捗率を問われている訳だから、なにか基準となるモノサシが必要だ。では、一番単純に考えて、「完成したプログラムの本数」を基準にしてはどうか？　全部で10本のプログラムを作らねばならない。15日たった現時点で、できあがったのは3本だけだ。だったら、3 / 10 = 30%ではないか。

これはこれで、シンプルで分かりやすい尺度である。これをかりに『完成数基準』と呼ぶことにしよう。

ところで、別の考え方もありうる。プログラムが完成まで至っていなくても、設計やコーディングがそれぞれ終わっているのなら、一定の進捗があったと言えるはずだ。で、その進捗率は、どう測るのか。それは、工数によるウェイトがいいと思う。

15日たった現時点で、設計は10本とも完了している。設計の工数はそれぞれ0.2人月と見積もられている。またコーディングは6本完了だ。1本あたり0.5人月だから、3人月分の仕事が終わっている。そしてテスト。これは3本×0.3人月で、0.9人月分。だから合計、5.9人月分の仕事までは進んだ訳だ。だから、全体工数の10人月で割ると、5.9 / 10 = 59%となる。この考え方を、『見積基準』と呼ぼう。

いやいや、よく考えてみよう。工数の見積なんて、いつでも大した精度がなく、あてにならないものだ。ウェイトをつけるなら、実際に掛かった工数を重みにすべきではないか。表によれば、設計には合計2.5人月、コーディングには4.0人月かかり、テストにも1.5人月使っている。合計7.0人月だ。だとするならば、進捗率＝70%が妥当ではないか。この考えを、『実績基準』と呼ぶことにする。

結局、この問題は、次の三つのどれかを選べ、という問いになる：

３／１０＝３０％？　（完成数基準）

５．９／１０＝５９％？　（見積基準）

７．０／１０＝７０％？　（実績基準）

さて、あなたなら、どれを選ぶだろうか？

上の３つの計算例でも分かる通り、進捗には、さまざまな定義が可能である。いわば決め事の問題であって、その点で原価管理にも似ている。原価にも、様々な計算手法がありえる。その中から、どれを選ぶかは、企業のマネジメント方針次第なのである。

しかし、『進捗率』を数字で計算する以上、合理的かつ整合的な算定方法として、皆が合意できることが条件になる。

その観点から、完成数基準の計算：

　３／１０＝３０％

を見ると、どうなるだろうか？

15日目の現時点で進捗率30％ならば、100%完成まで、15 / 30 * 100 = 50だから、あと50日かかる計算になる。じゃあ、このプロジェクトは、あと35日必要だと言えるだろうか？

進捗管理の目的は、きれいな進捗レポートを作ることではない。進捗率を測る最大の目的は、完了日を予測するためにある。完成数基準は分かりやすく単純だが、この目的のために有用だろうか？

考えてみてほしい。横軸にプロジェクト開始からの日数を取り、縦軸に進捗率をとって、グラフにプロットするとする。もしこのプロジェクトが理想的に進めば（＝つまり、各プログラムが予定通り並列に開発されると）、29日目までは完成数＝ゼロである。30日目に、10本のプログラムが全部、同時に完成する。

進捗率のグラフは、ずっと0%のまま29日目までx軸にはりついていて、30日目にいきなり100%になる。このグラフを見て、完了日の予測ができるだろうか？　理想的にプロジェクトが進むと、完了時点が予測できなくなるような基準は、役に立つだろうか。

では逆に、実績基準の計算：

　７．０／１０＝７０％

は、どうか？

いま仮に、現在までにトータルで9人月かかったとすると、90%進捗、ということになる。もし12人月かかっていたら、120%進捗、という計算にならないだろうか？　これは明らかに不合理である。

予算消化率で進捗率は測れない。これまで、どれだけ頑張ったか、どれだけ工数や予算を使ったか、で進捗を測ってはいけないのだ。この点はよく覚えておいてほしい。世間の人は、ここを誤解しているケースが非常に多いからだ。

進捗率は、今までどれだけ頑張ったか、ではなく、あとどれくらい仕事が残っているかで測るべきなのだ。

では、あとどれくらい仕事が残っているのか。それは、未完了の仕事（コーディング4本とテスト7本分）を見る必要がある。その仕事量は、4 * 0.5 + 7 * 0.3 = 4.1人月だと見積もられている。全体が10人月分の仕事量だったのだから、41%残っている。となると、進捗した分は、差し引き100 - 41 = 59%となる。

したがって、見積基準の計算：

　５．９／１０＝５９％

が正解らしい、とわかる。

実を言うと、この当時、経産省主導の資格試験は、正解を公表していなかった（もっと後には公表するようになったが）。だから、上に述べたのは、あくまでも佐藤の推測した回答である。しかし、これが正解だろうと思う。なぜなら、この見積基準の進捗率とは、EVMS (Earned Value Management System)の標準的な手法だからだ。

EVMSは、モダンPMの技法の三本柱の一つだ。EVMSでは、進捗率を次のような方法で定義する。

1. 各Activityに見積った工数を、ProjectにおけるそのActivityの価値とする

2. 全Activityの価値の合計は、Project全体の価値に等しい

3. 完了したActivityの価値の合計を、「出来高」（アーンドバリュー）と呼ぶ

4. 出来高をProject全体の価値で割ったものを進捗率と定義する

この問題では、完了したサブ・アクティビティの価値（見積もられた工数）の合計は5.9人月だった。だから、5.9 / 10 = 59%になるのである。いいかえると、EVMSの進捗率計算は、見積基準なのだ。

さきほど、完成数基準で進捗率のグラフをプロットすると、値がずっとゼロのままで、使い物にならなと書いた。逆に言うと、進捗率計算の主目的が完成日予測にあるのならば、理想的な進捗の指標とは、グラフがちょうど直線で進んでいくような形だろう。これならば予測は、かなりやりやすい。

これに対してEVMSの進捗カーブの形は、通常、もう少しS字カーブ型になる。プロジェクトの最初はゆっくりと立ち上がり、やがては活況に入ってぐんぐんと進捗があるが、最後の方になるとまたカーブが寝て、ゆっくりとした収束になる。だからプロジェクトの一番初期と、一番最後の頃は、EVMSの進捗率から完了日予測を正確にするのは難しい。しかし両端の時期を除けば、まあまあ予測には使える。こういうこともあって、EVMSの進捗率計算は広く使われている（少なくとも欧米では）。

ただし、EVMSの進捗率によるコントロールは、万能ではない。この点についてはすでに何度か記事も書いたので、ここでは繰り返さない。だが、舶来の手法で、試験問題にも繰り返し出されると、なんだかそれが『正解』だと思い込み、暗記してそのまま従うような風潮が、わたし達の社会には無い訳でもない。

繰り返すが、進捗率計算というのは、いろいろな定義が可能なのである。少なくともそれが合理的で整合的である限りは、各社がいろいろと工夫して使っていい。ただ一つ言えることは、「過去こんなに頑張りました」という事をベースにして計算してはいけない、という点だけだ。

これまでの努力を言いたい気持ちは、もちろんわかる。それをきちんと、ステークホルダー達に説明する必要もある。だが、それは過去に属することだ。言ってみれば、タクシーメーターの料金なのである。ここまで、これだけ走り、料金換算でこれだけかかりました。だが、タクシーメーターをいくら懸命に見つめても、この先いつになったら目的地に到着できるかは、分からない。つまり、進捗の指標にはならないということだ。

進捗コントロールというのは、もっと未来志向の行為なのである。

＜関連エントリ＞

　→(2010-02-17)

　→ (2019-05-26)