/note/tech

プロジェクトを計画しすぎてダメにする方法

にもかかわらず、とくに国などの公的資金が入るような研究開発などでは、「計画しすぎ」の弊害が見受けられるように思える。研究開発には最低でも数年単位の時間がかかる。しかし国の予算は年度単位だ。だから年度ごとに、達成すべき目標をあらかじめ定めてから、始める。そして異様に細かな経費記録や詳細な経過報告が求められる。

このような考え方の底には、「研究開発に携わる研究者という連中は、自分たちの興味のおもむくまま、勝手に好きなことをやりたがるものだ」という信憑だか不信があるのだろう。たしかに、 大企業の中央研究所というお堀の中に住む人の中には、技術を具現化して利益を生み出すより、学会誌に論文を何本出すかに情熱を集中するタイプも、いることは、いる。実用よりも、真理探究の知的好奇心が、行動基準なのだ。

なので、そういう、いわば「ネコ型」の研究者の首に鈴をつけるために、大部な計画書の作成が義務づけられ、詳細な(しかも文章記述中心の)進捗報告の書式が定められる。計画書の提出で研究費が配分され、進捗が遅れると鞭打たれる。こうすれば集団で一つの目標を追いかける「イヌ型」の行動をとるはずだ、と思うのであろう。これが研究開発型プロジェクトを「管理」しがたる側の、ロジックである。

だが、技術開発というのは、未知に挑む仕事だ。途中で、大きなやり直しも生じやすいものだ。なのに、こういう官僚的な管理システムの中では、最初に決めた目標に向かって、計画で決めた通りのペースで進むことが求められる。途中でうまくいかないことが明らかになっても、大きく方針転換したり、中止する決断を、誰もしない(官僚組織でそんな事を決めれば、責任を追求されるからだ)。

たとえば英国のPM標準「PRINCE2」が推奨するように、スケジュール・コスト・スコープ・リスクなどに関して、権限と許容度を設定しておく。たとえばプロジェクト・レベルでは1ヶ月以内まではプロマネの裁量とし、それ以上になる場合は、スポンサーやステアリング・コミッティに上申して裁可を仰ぐ、といった決まりを作る。このように、現場側にある程度の自由度を残し、かつ、野放図にならぬよう制限をつけるのだ。

もう一つの「スコープが固まるタイミング」については、とくに自発型プロジェクトで重要になる。というのも、研究開発・新事業開発・業務改革など、自発型プロジェクトの多くは、最初はかなり「ソフトな」スコープでプロジェクトが開始する。そして、ある程度検討が進んで、何をどうすべきかかなり明確になった段階で、はじめて、残りの仕事が「ハードな」スコープとして見えてくるのである。

もし進捗を見たければ、数量ベースではなくマイルストーンで見ていく。あるいは、アジャイルのようにiterationベースで見ていく。この段階で使うコストは、どうせ知れている。だから遂行の効率性よりも、生み出す有用性を高める努力の方が、ずっと大切になる。

そして、ある程度進んだら、プロジェクトの中に、かなり固まったスコープの部分が見えてくる。そこではじめて、計数管理に基づくベースライン計画を作り直すのである。初期の段階でも、この段階でも、プロジェクト計画で使うステップは、共通している。だが、目的とフォーカスが違うのである。