 |
|
ダブリンの風(49) 「90%シンドローム」 高根 宏士：4月号
30数年前に見たプログラミングプロジェクトの書籍のまえがきに次のようなエピソードが紹介されていた。 多くのプロジェクトでは納期の1ヶ月前辺りまではスケジュールは順調である。そして納期の1ヶ月前になると問題が出始め、納期までに完成するかどうか危ないという情報が挙がってくる。そして1ヶ月のスケジュール延長が決められる。1ヶ月遅れの完成日が近づいてくると事態は益々悪くなり、到底1ヶ月程度の延長では収束しそうもない。改めてプロジェクトの状況を点検してみると、何ができていて何ができていないかもはっきりしない。内容はどうなのか調べると、誰もスペックを正確には理解していない。というよりも関係するステークホルダー間で共通に認識されたものがない。そこで外圧により、あらためて明確化の動きが始まる。 当時はソフトウエア開発のプロセスモデルや方法論もはっきりしていない時代だったからスケジュールの進捗状況もそれぞれのプロジェクトが独自の方法で判断していた。平均のプロジェクトではプロジェクトマネジャーは担当者から「大体の」状況を聞き、「感じ」で進捗を判断していた。例えば担当者から半分程度はできましたといわれ、進捗率50%とする。そしてこれまでと同じ時間を書ければ掛ければ終わると予想する。ところが実際はそうはならない。納期が近づくにつれ、問題が残り時間に反比例して発生する。そして予想の3〜4倍程度の時間がかかってしまう。この期間はプロジェクトとしては死の苦しみである。 問題は「感じ」で把握した進捗率が当てにならないことである。実際の作業においては、大体終わったと思った時から、本当に終わったと判断するまでには相当の時間がかかる。「感じ」で90%と思った時から99%と思うまでに同程度の時間がかかる。99%終わったと判断した時から99．9%終わったと判断するまでにまた同じぐらいの時間がかかる。したがって90%終わったと思った時から本当に終わるまでには、それまでにかかった時間の倍はかかる。90%終わってから99．9%までにはなかなかならない。これが90%シンドロームである。まして50%終わったという「感じ」では実際は10%程度しか終わっていない。 エピソードは30数年前の話である。現在はどうであろうか。プロセスモデルも研究され、多くの方法論も提案され、実施されている。プロジェクトマネジメントについても、PMPやPMS資格なども多くの人が取っており、知識は広がっている。それでも90%シンドロームのプロジェクトは多い。本質は現実のプロジェクトにおいて進捗を具体的に測定していないからである。筆者は「50%終わりました」という報告を受けたら、「50%とした分母と分子は何か」と聞くことにしている。進捗を具体的な内容で判断しているならば、50%を算出した分母と分子のデータがあるはずである。それは難しいことではない。プログラムの本数でもよいし、LOC(Line Of Code)でもよいし、FP(Function Point)でもよい。WBSの各ワークパッケージやアクティビティに対する評価ポイントでも良い。それらを具体的に、厳密に評価した結果の%ならば50%の進捗という判断も、それなりに割り切った形で信頼できるものになる。しかし分母と分子の質問に答えられない%表示の進捗率は信頼できない。また形式的には決まっていても具体的に現場で厳密に採取していないならば同じことである。それを基に終了時点を予測すると必ずその予測は誤る。 このようなことを話すとシステム開発は複雑だから、そんなに簡単にはできないと言われる。しかしこれは進捗管理ができないということではなく、問題は開発するシステムのイメージを、管理する人が持っていないことである。このことをプロジェクトマネジャーやリーダの立場にある人が自覚することが進捗管理、広くはプロジェクトマネジメントにおける基礎である。 余談であるが、プロジェクトの進捗報告を受けるとき、報告者から「大体終わりました」と言われたら「大体終わっていないんですね」ということにしている。 「大体終わりました」、「後ほんの少しです」、「90%程度進んでいます」という言葉の存在を許容することは現状認識を誤るトリガーになる。コミュニケーションの齟齬をきたす最大の要因でもある。 |
 |