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

プロジェクトの生産性と着地点を測るには

2015年7月、東芝は過去7年間に渡って、「不適切会計」で1500億円以上も利益をかさ上げしてきた、という第三者調査委員会の報告を公開した。これに伴い、田中社長を始め、歴代3社長が退任。日本の産業史上最大の不正会計事件となった。

このときの不正に、実はプロジェクトの『進捗率』の計算が、深く関わっていた。というのも、会計操作の手法の一つが、「進行基準」の悪用だったからだ。

「ああ、会計の話なんか興味ないよ。技術屋としての俺の仕事には関係ないから」とお思いの方も、その手口については、少しだけ知っておいたほうがいい。というのも、これは進捗率をどう粉飾するか、という話だからである。しかも、先々のコスト増を無視していると、結果的に売上や進捗率を粉飾したことになってしまう事があるのだ。そして売上や原価は、エンジニアたちの尻を叩くモノサシでもある。妙な叩かれ方をしたくないならば、少しはその仕掛けについて学んでおくべきだ。

一般に受注型プロジェクトの会計には、完成基準進行基準の二種類がある。そして、複数年次に渡る大規模なプロジェクトでは、進行基準が望まれる。進行基準では、プロジェクトの進捗に従って、毎期ごとに、収益(売上)が計上できる。これに対して、完成基準では、プロジェクトが完了しないと売上が立てられないからだ。普通の経営者にとっては、何よりも売上高が命であり、数年もの間「売上ゼロ」では、何も仕事していないのか、と言われてしまう。

進行基準は、「工事進行基準」とも呼ばれる。建設業会計の世界で発達した手法だからである。しかし作るものが無形のソフトウェアであろうと、工事を伴わぬ大型機械の製造だろうと、考え方は同じだ。

さて、当時の東芝は、次の計算式で工事収益を計上していた(「東芝不適切会計と工事進行基準」清和監査法人」による):

当期の工事収益 = 工事収益総額 × 工事進捗度 - 過年度工事収益計上額
 ただし、工事進捗度 = 累計工事原価発生総額 ÷ 工事原価総額

この計算式自体は、ごく普通のものだ。建設業であれ、受託ITシステム開発のSIerであれ、進行基準に従う多くの企業は、こうして計算しているはずだ。

東芝の不正手口は、「工事原価総額」を少なめに見積もることで、「工事進捗度」をかさ上げする、というやり方だった。いや、少なめに見積もる、という表現は正確ではない。じつは、プロジェクトの途中で予想されたコスト増を、無視して繰り入れなかったのだ。これによって約500億円もの根拠なき売上が立った、と言われている。そして東芝の会計監査法人は、この問題点を見過ごしていた、としか思えない。

「進捗率」を水増しすれば、架空の売上が手に入る? どうしてだろうか。

たとえば、今、受注金120億円のプロジェクトがあったとしよう。この案件は、開始から完成まで、たっぷり3年かかる。そして、プロジェクト原価は100億円、利益額は20億円と計算されていた。想定される年度別の計画は、次のようなものであった:

     発生原価  累計原価  進捗率 
1年目  20億円  20億円  20%
2年目  30億円  50億円  50%
3年目  50億円 100億円 100%

上の式で、進捗度 = 累計原価発生総額 ÷ 原価総額、とあるとおりだ。そして、各年度で、それぞれ計上できる売上と、その年度の発生原価から見た利益額を計算すると、次のようになる:

     発生原価  累計原価  進捗率  計上売上  年度利益 
1年目  20億円  20億円  20%  24億円   4億円
2年目  30億円  50億円  50%  36億円   6億円
3年目  50億円 100億円 100%  60億円  10億円

さて、このプロジェクトの1年目の終わり近くになって、問題が起こった。技術的なトラブルと、顧客側の無理難題が重なって、完成までにさらに40億円もの追加費用がかかりそうだ、という状況が判明したのだ(2年目に10億円、3年目に30億円のコスト増)。まあ、「判明」というのは、経営者にとってであって、担当者レベルでは、最初の頃から「このプロジェクトはまずいな」と思っていたのかもしれないが。

ともあれ、このままでは受注総額120億円に対し、原価総額=140億円になってしまい、赤字プロジェクトに転落である。かりにトラブルのスケジュールへの影響が小さく、なんとか3年以内に終わるとしても、正しくは次のような表になるはずだ。

     発生原価  累計原価  進捗率  計上売上  年度利益 
1年目  20億円  20億円  14%  17億円  ー3億円
2年目  40億円  60億円  43%  34億円  ー6億円
3年目  80億円 140億円 100%  69億円 ー11億円

1年目の進捗率が20%→14%に、2年目の進捗率が、50%→43%に、それぞれ下がった点に注意してほしい。これは、累計原価の総額が100億から140億円に増えたためだ。そこで、
1年後の進捗率: 20÷140=14%、
という計算になる。

だから計上できる売上も、
1年目の売上: 120×14% = 17億円
に減ってしまうのである。結局、17億の売上で、20億円のコスト発生だから、マイナス3億円の赤字になる。2・3年目も同様の計算で、売上は34億と69億、原価は40億と80億で、都合、6億円と11億円の赤字だ。

さて。この計算表を見て、不心得な経営者がこう考えたら、どうなるだろうか?
「トータル40億円のコスト増だって? そんなの、まだ確定していないじゃないか。少なくとも今期のコストはまだ増えていない。来期以降の増分は、最後に確定してから膿を出せばいいのだ」

かくて、現実を無視して累計原価の総額を2年目まで変更せず、最後に帳尻を合わようとすると、こうなる:

     発生原価  累計原価  進捗率  計上売上  年度利益 
1年目  20億円  20億円  20%  24億円   4億円
2年目  40億円  50億円  50%  36億円  ー4億円
3年目  80億円 100億円 100%  60億円 ー20億円

バンザイ! かくて当年度の売上は17億ではなく24億に増え、収支も3億円の赤字から、4億円の利益になる。経営者にとって、赤字と黒字では天国と地獄ほど違う。

お分かりだろうか? プロジェクトで今後発生しそうな(合理的に予見できる)コスト増を無視すると、進捗率も売上も、本来よりもカサ上げできるのだ。だが、結果的にそれは粉飾になる。現実の東芝で起きた事件は、米国の原子力子会社と孫会社を巻き込んでもっと複雑だが、本質だけを単純化すると、上の例のようなことになる。そして、赤字か黒字かは、各社員のボーナスの査定や昇進のみならず、事業部の存続までかかってくる問題なのである。

・・ところで、ここまで我慢して(?)読んでこられた真面目な技術者諸賢は、疑問を感じられたことだろう。「トータル40億円のコスト増って、どうやって推算したんだ? そんな事が、全部終わって金勘定を締める前に、わかるのだろうか? そんな事が分かるくらいなら、誰も苦労しないじゃないか!」

もちろん、本当に「合理的に予見可能」な原価というからには、個別のワークパッケージ単位に、追加変更のコストを積上げ、その発生する蓋然性を評価しなければならない。大規模プロジェクトでは、そこまでプロジェクト・マネジメントを徹底することが求められる。でも、読者が知りたいのは、もう少し身近なプロジェクトの場合だろう。とくに、スコープ=役務範囲の柔らかい(例えばIT系などの)、プロジェクトの場合に違いない。そんなの、本当に可能なのか、と。

ところが、将来のコスト増を、ある程度の精度を持って推算する方法があるのだ。そこにEVMSの技法が関わってくるのである。

前回の記事(「進捗率を何で測るか? −−情報処理技術者試験の問題より」)で、わたしは、「進捗率は、今までどれだけ頑張ったかではなく、あとどれくらい仕事が残っているかで測るべき」と主張した。

では、「あとどれくらい仕事が残っているか」をどうやって推算するのか。答えは、CPI (Cost Performance Index)という、プロジェクト遂行の生産性を測る指標によるのだ。プロジェクトのCPIは、次式で定義される量である:

 CPI = EV / AC

つまり、その時点までの出来高(EV)を、その時点までの実績出費累計(AC)で割った数字である。出来高EVとは、完了したアクティビティの予算の合計であった。もしEVとACの両者がぴったり一致したら、計画通りに仕事が進んでいる訳で、CPIは1になる。EVが1よりも大きければ、当初計画したよりも実績コストは小さくすんでいることになる。逆に、思ったよりお金がかかっているなら、CPIは1以下になる。

さて、米国では国防総省を中心に、EVMSに関する膨大なデータの蓄積がある。それによると、プロジェクト全体のCPIの値は、良きにつけ悪しきにつけ、全体工期の2割を超えた時点から、±10%以内の精度で安定することが分かっている。良いなら良いなりに、まずいならまずいなりに、傾向が定まるのだ。

たとえば前回の出題の例では、EV = 5.9、AC = 7.0であった(単位は人月)。だから、

 CPI = EV / AC = 84%

である。簡単に言うと、100円使って、84円分の成果しか上がらないのだ。プロジェクトの生産性が84%と言い直しても良い。

では、このプロジェクトの累計原価発生総額(完成予定額 EAC = Estimate at Completion ともいう)は、どうなるか? 元の見積では、全部で10人月で終わるはずだった(これをBAC: Budget at Completionと呼ぶ)。一方、これまでに、AC=7.0人月使ってしまった。残っている仕事量は、10 - 5.9 = 4.1人月分になる(元の見積ベースでは)。だが、これも84%の生産性で補正しなければならない。つまり

 EAC = AC + (BAC - EV) / CPI = 7.0 + 4.1 / 84% = 11.9

結局、約12人月だろう、ということになる。つまり、2割ほどコスト増が予想されるのだ。

ちなみに、プロジェクト初期の段階では、CPIの値はかなりアバレるから、まだ推算には使えない。この例では、すでに進捗率=59%なのだから、プロジェクトも中盤に入っており、CPIの値は安定すると予想できる。

なお、プロジェクトを構成する各アクティビティは、それぞれ種類も違う固有の業務内容を持っているのに、CPI値が安定するのは奇妙に思えるかもしれない。しかし、独立した変動を持つ分布を足し合わせると、全体としては分散が小さくなる、というのが統計学の教えるところだ。では、そのような推算が成り立つためには、どれくらいの要素数が必要かと統計学者に聞くと、「中心極限定理から、30以上は必要だ」と答えるだろう。

全体の2割を過ぎた時点で、30個以上のアクティビティの実績データが必要だとしたら、EVMSで完成予想額を見るためには、プロジェクト全体では150個以上のアクティビティからなるWBSを持つことが、条件になる。EVMSというのは、それなりの規模のプロジェクト向けの手法なのである。だから例題のような、トータル10人月程度のプロジェクトにEVMSを持ち出すのは、いささか「牛刀をもって鶏を割く」きらいがある。

ここまではまあ、普通のPMの教科書に書いてあることだ。ところで、この話にまだ、少しだけ先がある。12人月で終わりそうだ、という着地点の推測は、本当はまださらに、補正が必要なのである。

実を言うと、EVMSから導出されるプロジェクトの生産性指標は、もう一つある。それがSPI (Schedule Performance Index)で、次式で定義される:

 SPI = EV / PV

ここでPVは、元の計画上での進捗率である。たとえば、本来70%終わっているはずの計画だったのに、実際の出来高基準では59%しか進んでいないなら、CPI = 59/70 = 91% という事になる(ちなみに問題文には計画上の15日時点の進捗率は書かれていないから、上記の91%というのは、単なる例である)。

SPIは、スケジュール面から見た、プロジェクトの効率性を表す。先に紹介したCPIも、このSPIも、分子にEVが来ている点を覚えておいてほしい。SPIもCPIも、値が高いほどよい。1よりも大きければ、計画より効率よく遂行できていることを示す。

そして、米国で蓄積した膨大なEVMSデータによると、プロジェクトの完成予定額EACは、次の式で計算するほうが、より現実のデータに合うというのだ:

 EAC = AC + (BAC - EV) / (CPI・SPI) = 7 + (10 - 5.9) / (0.84 * 0.91) = 12.4

つまり、先ほどの推算よりも約0.5人月分、さらにコスト増になるという計算だ。

この計算式は、Flemming & Koppelman: "Earned Value Project Management, 2nd Edition", PMI, pp.136-137, 2000.(邦訳「アーンド・バリューによるプロジェクトマネジメント」)に解説されてる。ただ、日本のPM関係の教科書参考書の類では、なぜかあまり書かれていない。日本語版Wikipediaにも、現時点ではのっていない。

それにしても、残っている仕事量(BAC - EV)を、なぜCPIとSPIの両方で割るのか? 明確な理論的説明がある訳ではない。ただ、コスト超過しているプロジェクトは、スケジュールも遅れているので、全体工期が延びる分だけ、さらに余計に費用がかかるようだ、という経験知を示している訳である。

以前の記事で、わたしは「進捗率は予算消化率では測れない」と書いた。実を言うと工事進行基準とは、「進捗率=予算消化率」という定義になっている。ただ、そのかわり、「予算には、今後発生する合理的なコスト増を組み入れること」という形になっている。なので、コスト増が起きると、分母が増えて、進捗率がその分下がることになる。結果として、「残っている仕事量」が反映されるのである。

ソフトウェア開発の売上計上に工事進行基準が義務付けられるようになったのは、2009年からのことである(企業会計基準第15号「工事契約に関する会計基準」及び企業会計基準適用指針第18号「工事契約に関する会計基準の適用指針」)。その1〜2年前から、大手SIerの間で、「これからはもっと真面目に(定量的に)進捗管理をしなければならい」という議論がかわされていたのを、覚えている。

そして、さらに2021年4月以降は、ソフトウェア業界も、会計が「収益認識基準」に変更される。こちらは「もっともっと真面目に」役務項目別のコントロールが義務付けられる。これに各社は、準備対応できるのだろうか。

ちなみに上の説明で、「わずか10人月程度のプロジェクトにEVMSを適用するのは、大げさすぎる」という意味のことを書いた。しかし、そのような態度にも、一つ利点がある。社内で、大小様々なプロジェクトに関するデータが蓄積できることだ。

米国では国防総省が中心になって、EVMSの適用を進めてきた。また90年代以降、一定金額以上の公共事業にも、EVMSの適用が求められるようになった。彼らは、データを蓄積することの威力を、知っているのだ。上に述べた「工期の2割以上をすぎるとCPI値が安定する」といった知見も、そこから得られたものだ。

事実とデータに基づいて、マネジメントが予測と決断を下すこと。そうしなければ、強い軍隊や、勝てる組織などというものは、維持できないというのが、米国流の経営思想である。勇敢な兵士や鬼軍曹だけでは、戦えないのだ。正しいデータと分析が、重要だ。気合と根性だけでは、仕事はスケーラブルにならない。

EVMSという手法には限界もあって、万能ではない。しかし、その限界を知りつつ使ってデータを蓄積するのと、その手法を知らないために使いもせず、データも取らないのとでは、長い間には天と地ほどの差ができる。ITという仕事が、データから有用な情報を組み上げるためのものならば、わたし達自身の仕事についても、やはり数値化の努力をすべきだろう。


<関連エントリ>
 →「
」 (2020-02-08)


by Tomoichi_Sato | 2020-02-18 23:36 | プロジェクト・マネジメント | Comments(0)
<< 書評:「理解とは何か」 佐伯胖・編 「プロジェクト&プログラム・ア... >>