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

「日本企業は、計画しすぎなんです。」——最近、ある外資系戦略コンサルタントから、こんなセリフを聞いた。いわゆるDXに関する話題の時だ。「計画して、それも細かく緻密な計画を立てて、石橋をたたくようにリスクを全て洗い出してから、はじめようとします。そして動き出したら、すぐ進捗率を問題にする。でも、そんなやり方では、イノベーションは動きません。」

たしかにまあ、日本企業、とくに製造業は、まず計画ありきで動いていると言ってもいい。年度計画（いわゆる「予算」）、月度計画、小日程計画・・。建設業も、似たところがある。全体工程表、月間工程表、週間工程表、等々。現場に行くと、計画表は、必ず目立つ位置にはり出してある。

だが、新しいビジネスモデルを創出するような、イノベーティブな試みは、目指すべき目的地が最初から決まっている訳ではない。登るべき山の頂が明確なら、アプローチの経路を地図の上に引き、どこまで登ったかで進捗率を測ることもできる。しかしイノベーションは、行き先も地図も定かならぬ旅路（ジャーニー）である。大きな方向性はあるだろうが、実際には小刻みに、道を探りながら進むしかない。

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

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

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

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

かくて、数年後には意味の乏しい成果しか得られぬと分かっているのに、延々と無駄金を投じるような研究開発が進んだりする。公的資金が絡まなくても、官僚的体質の大企業では、似たようなことが起こりがちだ。

研究開発以外でも、新事業開発や業務改革といった分野のプロジェクトも、同様の問題を抱えるケースが少なくない。新事業の開発は、（同業ライバルのまるっきり真似をするのでない限り）どんな答えが出てくるか、あらかじめ決められない。業務改革プロジェクトもしかり。在庫削減だの省人化だの、KPI的な目標は先に与えられるかも知れないが、方法は誰もよく分からない。それなのに、詳細な計画を立てろと言われる。

だったら、計画なんて一切、立てなければいいではないか。まず動いてみて、考える。必要なのは、現場力。それで何が悪いのか？　誰か困る人がいるのか？

もちろん、時間が無限にあり、お金も使い放題、人も好きなだけ動員できるなら、それもありだろう。だが組織が抱える経営資源は、お金も人も有限だ。それは、なるべく有効に使いたい。これが、経営者の論理である。急にお金がいると言われたって困る。当期利益や来期予測から大きく外れたら、株主からも叱られる。

経営管理側が、プロジェクトチームに計画を要求する主な理由は、資金調達、つまりお金の出入りを予定したいからだ。でも、それだけではない。上に書いたとおり、実行者側に対する一種の不信感がある場合、どうしても詳細な計画を作らせ、説明させ、なおかつ実行段階に入ったら、進捗確認で尻をたたいて、都度モニタリングしたい、と考えがちだ。

ところが実行者側は、プロジェクトの初期段階ではそんなに詳細な計画なんて立てようがない、と考えている。仮に立てたって、その通りに進むはずがない。ここにギャップがある。

このギャップは結局、プロジェクト計画は誰のためにあるのか、何を目的として作るのか、という認識のズレから来る。

本来、プロジェクト計画は、プロジェクトの実行主体（現場側）が、必要なアクションの特定と、リソース（特に人と予算）のニーズを明らかにする目的で作るものだ。それにより、実行の当事者が、自分たちの進め方をある程度、イメージアップする。別の言い方をすれば、プロジェクト計画とは、モデル作りなのである。プロジェクトがどう進むか、どう進めたいか、に関するモデリングだ。

モデルとは、一種の近似である。全ての細部にわたって正確なモデルを作ることはできない。ただ、重要な部分だけは、ある程度精度良く、おさえたい。それが良いモデルだ。そして良いモデルができると、外部環境の変化などのイベントに、どの程度影響されるのか、どこが弱いのか、などのシミュレーション的検討にも使える。

つまり、プロジェクト計画というのは、実行主体が、頭の中で様々なシミュレーションを行って、いろいろな環境変化にも対応できるようにするために作るのだ。だから、前回の記事で説明したように、最後に「リスク・アセスメント」が来るのである。

ところで、プロジェクト計画は、実行主体（とくにプロマネ）が、外部のステークホルダ（利害関係者）に対する説明にも使う。そのステークホルダとしての最初で最大の説明相手が、じつは経営管理層なのである。そして、管理する側は、「プロジェクト計画とは、自分たちへの説明文書だ」と考える。ここが誤解の始まりだ。

とくに、実務内容を指導できない「管理者」は、計画の中でも、コストとリスクの項目しか、見ようとしない。だが実際にはコストは、プロセスの結果で決まる。プロセスとは、アクション（PM用語ではActivity）の連鎖である。アクションの連鎖が、品質とスケジュールを決め、結果としてコストが定まる。プロセスを支えるのは、人や設備などのリソースからなる「体制」である。

だから本当にコストを「管理」しかかったら、アクションを指導し体制を指示することが必要だ。だが、技術の中身が分からない管理者は、任命したリーダーの「資質」と、結果としてのコストだけしか口を出せる範囲がなくなる。あと、口を出せるのは、「リスク」であろう。

ただ、それは管理者としての、一種の責任逃れの本能から見たリスク評価になるケースが多い。プロジェクトのリスクの評価は、本当は、問題解決能力と表裏一体だ。自分がすぐに解決できる問題は、普通リスクとは言わないからだ。

結局、管理側が現場から遠く、その仕事の内容を良く理解できないまま、口だけだそうとするから、計画過剰になるのだ。それも、自分では計画を立案できない。現場側に計画を立てさせて、足りなそうな点を批評するだけだ。かくて、管理過剰に陥るのである。計画しすぎてダメにするのは、つまり管理しすぎてダメにすることの一部なのだ。

では、どうしたら良いか。

この問題の背景には、経営管理側と実行者側との認識のギャップがある。そこで、簡単ではないが、このギャップを埋めなければならない。そのためには、「プロジェクト・ガバナンス」の原則と、「スコープが固まるタイミング」について、両者がともに理解するべきである。

「ガバナンス」という言葉は一般に、「マネージャーをマネジメントする」意味で使われる。プロジェクト・ガバナンスとは、つまり、プロマネをどう経営層がマネージするか、いいかえると、どんな権限を委譲するか、に関する決め事である。

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

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

この事情はIT開発プロジェクトも似ていて、初期の段階ではスコープは非常に柔らかい。それが、要件定義を完了すると、ようやく作るべきシステムの規模や機能詳細が見えてきて、コストやスケジュールを、精度よく予測できるようになるのである。

この事情を、わたしはよく魚の形にたとえる。初期の検討はまだ、魚の顔の鼻先をみているようなものだ。それが、基本設計や要件定義を進めると、しだいに目や口の位置が見えてくる。そして、エラの形まで分かるようになったら、あとはどれくらいの体が後ろについているかが、推定できるようになる。そうなれば、計数管理ができるようになる。

だから、経営層が詳細な（コスト的）計画を求めるタイミングは、魚の頭がかなり見えてくる時まで、待つべきなのである。

およそ、自発型プロジェクトの多くは、非常に柔らかなスコープからスタートする。その初期は、コストやスケジュールで管理するのではなく、プロジェクトの生み出す成果物の「前向き品質」（魅力品質）と、技術リスクの検討に集中すべきである。だから、初期のプロジェクト計画は、当面のアクションとリソースについてカバーする範囲で十分だ。

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

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

計画は、必ず必要だ。だが、物事は決して計画通りに行かないからこそ、我々の対応能力を高めるために、計画づくりの作業が必要なのである。

＜関連エントリ＞

　→「成功するプロジェクト計画はこうして立てる」 (2021-07-07)

　→「PMBOK Guideに欠けている、３つの重要事項」 (2019-04-16)