人気ブログランキング |

<   2020年 02月 ( 4 )   > この月の画像一覧

書評:「理解とは何か」 佐伯胖・編

理解とは何か」 佐伯胖・編(認知科学選書 4 東京大学出版会) (Amazon)


「『理解』という事について研究ができる。なんというすばらしいことだろうか。」

本書の中心にあたる、編者・佐伯胖の書く第5章「『理解』はどう研究されてきたか」は、このような一見ふしぎな言葉から始まる。そして、次のように続く。

「心理学の長い歴史を振り返ってみると、それは『理解』を研究したいという人々の熱い思いが、何度も何度もくりかえし裏切られ、『理解』とは似ていて非なるものばかりを押し付けられ、枠をはめられ、偽物であることを承知の上で無理やりに背負い込まされてきたものであることがわかる。」(P.127)

心理学の素人からすると、「理解する」というのは、人間にとって当たり前の心の働きに思える。だが、それを論じ研究することは、長らく心理学分野のタブーであったらしい。ちょっと驚きである。

だが、なぜ、そのような状態が、日本でも米国でも続いていたのか?(なみに本書は1985年の発刊だ)

佐伯胖は、自分が66〜67年に米国ワシントン大学に留学した際の、当時の米国心理学会の雰囲気をいきいきと描写しながら、その理由を説明する。それは、米国の心理学を1930年代以来ずっと支配してきた行動主義の影響らしい。行動主義とは、「科学としての心理学は、対象を客観的に観察可能な行動に限定すべき」という立場で、意識とか内観といった概念を排除していく。

佐伯胖によると、66年当時の主流派心理学者が認める、科学的研究の方法は次のような4項目であったという(P.136より要約して引用)。

(1) 実験データによる仮説の検証という手続きに基づく
(2) 観測される反応、すなわち行動を説明することが全てである
(3) 理論仮説は、データを説明するための必要かつ十分なものに限ること
(4) 説明は機能主義的説明で足りる。生体の内部構造には立ち入らず、ブラックボックスとしたまあ、その働きを正しく予測できるかどうかを問う

このようなパラダイムの中で研究を行う限り、たしかに「理解」それ自体のメカニズムを論じることは、いたって困難になる。

そうしたアメリカ心理学の強固な枠に対し、揺さぶりをかける動きも、たしかに一部は存在した。たとえば、スイスのピアジェによる発達心理学の業績である。またこれ以外に、フェスティンガーらの社会心理学、サイモンやハントらの情報処理アプローチがあるし、ボールズ、ロカードらの動物習性学・行動進化学の研究もあった。

これらを背景に、アメリカ心理学では67年ごろから「認知革命」と呼ぶべき動きが出てきたらしい。そして、上記の4項目に、さらに2項目を慎重に付け加えていった(P.136)。

(5) 内部機能に関するモデルの想定も許される(ただし実験的に検証が必要)
(6) 生物は外界の刺激に支配され、反応してるに過ぎない、と考える必要はない

わたし達のようなシステム・アナリスト(モデラー)から考えると、まあ当然のような6項目に見える。しかし、こうした変化がごくゆっくりしか起きないのは、それだけ学問研究の「パラダイム」の強さを示している。

佐伯よると、70年代は認知心理学が登場し、「知識」と「スキーマ」が研究の中心になる。72年には、ウィノグラードによる人工知能(自然言語による対話処理システムSHRDLU)が発表される。SHRDLUは積み木ブロックの世界について、人間と自然言語で対話しながら、積み木を運んだり積み上げたり、といった操作を行う。ウィノグラードはこれを心理学研究の一環として進めていた。

また、こうした動きと並行して出てきた、チョムスキー理論の心理学への影響は計り知れない、という(P.146)。チョムスキーはまず、行動主義心理学への批判を行い、さらに生得的な認知能力の仮説を立てる。そして認知過程に関する、生成変形文法という構造主義的アプローチを強める。

かくして心理学は「理解」をめぐって、認知→知識・スキーマ→自然言語、という風に主題を進めてきた。この流れは結局80年代に入り、「認知科学」に合流していく。本書自体が『認知科学選書』(東京大学出版会)の第4巻として発刊されている事が、事情をよく表していると言えるだろう。

ちなみに佐伯胖氏自身は、81〜83年に「LISPで学ぶ認知心理学」全3巻を出しているが、このタイトル自体が、ある種の時代を感じさせる。認知科学は90年代に入って、LISPの得意とする記号的人工知能から、神経回路網モデルをベースにした、コネクショニズム的なAI研究にうつっていく。それが今日のAIブームの基礎となる訳だ。

ただ、この動きはいささか、偏りすぎてきた観もある。記号による手続き的知識と、行列計算によるパターン認識的知識との間に、見えない壁がある現状は、どこかで再度パラダイム変化が必要なのではないか。

ともあれ、本書全体でいうと、マイケル・コール(UCSD教授)による第4章「リテラシー(読み書き能力)の文化的起源」も面白いが、第3章「理解におけるインターラクションとは何か」(三宅なほみ)が興味深い。これは二人以上の人が相手とやりとりしながら、建設的な問題解決をするプロセスを追った研究だ。

インターラクションの例に出すのは、「ミシンはどうして縫えるのか?」という議論だ。ミシンがなぜ布を縫えるのか。これはよく考えてみると、案外難問だ。これを二人で議論していくとき、「課題遂行係」と「モニター係」に作業分担するほうが進みやすい、など面白い知見がたくさん出てくる。

本書の1〜4章は一種のシンポジウムの講演録で、質疑応答も丁寧に収録されているため、とても読みやすい。そして第5章が編者による、まとめと展望だ。ただ時代のせいか、全体をよんでも、「理解」の心理学が、全体としてどのような戦略を持ち、どこを攻めようとしているのか、まだ作戦マップが描けるほどには概観できていないように感じた。

わたしが編者である佐伯胖氏の名前を知ったのは、「『きめ方』の論理 〜社会的決定理論への招待」(1980)をよんだ時だった。これは今でも、画期的な本だと思う。彼自身はその後、「決める」から「分かる」へ、そして「学ぶ」へと、研究分野をうつしていく。それは経営工学から出発して、心理学、さらに教育学へと進んでいく道のりだった。本書はちょうど、その分水嶺に当たる1985年、46歳のときの宣言的な業績である。だから勢いがあって、とても面白いのだ。
`

by Tomoichi_Sato | 2020-02-24 22:12 | 書評 | Comments(0)

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

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)

「プロジェクト&プログラム・アナリシス研究部会」(2月20日)開催のお知らせ

各位、

来る2月20日(木)に、2020年の「プロジェクト&プログラム・アナリシス研究部会」第1回会合を開催します。今回は、PM教育のためのゲームを開発された、日立ドキュメントソリューションズの岡田様にご講演いただきます。

プロジェクト・マネージャーの人材不足にはどこも頭を痛めており、優れたプロマネの育成研修は焦眉の急です。しかし、プロマネに必要とされる知識とスキルの幅はけっこう広く、身に付けるのは簡単ではありません。

当研究部会でも3年ほど前から「PM教育分科会」を組織して、独自の研修カリキュラムを開発してきました。ただし限られた時間内に、PMのソフトスキルとハードスキルの両面を伝えるのは、至難の技です。

日立さんのアプローチのユニークな点は、モノポリー的なカードゲームを元に、主にソフトスキルにフォーカスした問題解決力の教育を組み込まれた点です。教育における「ゲーミフィケーション」の効果は、最近つとに指摘されていますが、短時間に集中して考える取組みとして興味深いものです。またファシリテーターによる丁寧な指導も、実践的な価値を高める工夫のようです。

プロマネの育成について悩んでいる多くの方に、役立つ内容になると期待しております。開催日の直前のご案内になってしまい恐縮ですが、ぜひご来聴ください。


<記>

■日時:2020年2月20日(木) 18:30~20:30

■場所:田町キャンパスイノベーションセンター 
 5F スペース:509AB
 (JR田町駅の芝浦口から右方向の階段をおりて、50mほど先の右手の建物です)

■講演タイトル:
「ゲーミフィケーションを用いたビジネス人間力養成の取り組み」

■概要:
プロジェクトの現場において、プロジェクトマネージャは発生する問題やリスクに対して限られたリソースの中でその都度適切な意思決定を行うスキルが求められる。これらのスキルは実践訓練などを通して習得できるものであるが、習得には多くの体験を経る必要があり時間を要す。そこで、ゲームを通してチームでプロジェクトを模擬体験する実践訓練手法を開発した。ここで得られるスキルは、プロジェクトマネジメント分野に限らず、ビジネス全般に必要なソフトスキルであると考える。講演では、プロジェクトマネジメント分野以外への展開可能性や、ゲーム中の振る舞いによるプロジェクトマネージャの特性評価の取り組み、ゲームの臨場感向上のためのデジタル化/ゲーム空間の開発に関する取り組みを紹介する。
●YouTube:プロジェクトマネージャの”感性”を磨くボードゲーム「プロ・トレZ」プロモーション映像リンク先
* ダイジェスト版 ・・・・2分
* フル版 ・・・・21分

■講師:岡田 久子
 株式会社日立ドキュメントソリューションズ EPCプロジェクト本部 本部長

■講師略歴:
1998年日立製作所に入社。大規模発電所等の建設管理、および建設管理システムの運用・高度化業務を経て、
2014年より日立ドキュメントソリューションズへ移り、プロジェクトマネジメント支援業務の取り纏めに従事。

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 参加を希望される方は、確認のため、できましたら前日までに三好副幹事までご連絡ください。

 以上、よろしくお願いいたします。


佐藤知一@日揮ホールディングス(株)


by Tomoichi_Sato | 2020-02-12 07:24 | プロジェクト・マネジメント | Comments(0)

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

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

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

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

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

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

* 10本のプログラムからなるシステムを完成させるプロジェクトがある。
* 1本のプログラムを完成させるには1人月の工数がかかると見積もられた。
* 各プログラムの開発作業は、設計(20%)→コーディング(50%)→テスト(30%)のプロセスからなると推定された。
* 作業開始から15日たった時点で進捗状況を調べたら下記のとおりだった:

* 現時点での進捗率を求めよ
進捗率を何で測るか? −−情報処理技術者試験の問題より_e0058447_21440942.jpg
・・という問題である。

どうやらこのシステム、ほぼまったく同一規模のサブシステム・プログラム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%が妥当ではないか。この考えを、『実績基準』と呼ぶことにする。

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

3/10=30%? (完成数基準)
5.9/10=59%? (見積基準)
7.0/10=70%? (実績基準)

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

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

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

その観点から、完成数基準の計算:
 3/10=30%
を見ると、どうなるだろうか?

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

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

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

進捗率のグラフは、ずっと0%のまま29日目までx軸にはりついていて、30日目にいきなり100%になる。このグラフを見て、完了日の予測ができるだろうか? 理想的にプロジェクトが進むと、完了時点が予測できなくなるような基準は、役に立つだろうか。
進捗率を何で測るか? −−情報処理技術者試験の問題より_e0058447_21464971.jpg

では逆に、実績基準の計算:
 7.0/10=70%
は、どうか?

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

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

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

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

したがって、見積基準の計算:
 5.9/10=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の進捗率計算は広く使われている(少なくとも欧米では)。
進捗率を何で測るか? −−情報処理技術者試験の問題より_e0058447_21501962.jpg

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

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

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

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


<関連エントリ>
 →(2010-02-17)

 → (2019-05-26)


by Tomoichi_Sato | 2020-02-08 21:56 | プロジェクト・マネジメント | Comments(1)