成功するプロジェクト計画はこうして立てる

「あなたは、同期30人の集まるパーティの幹事になりました。

　あなたが最初にすべきことは何ですか？」

－－これはプロジェクト・マネジメントを人に教えるとき、わたしが必ず出すクイズの一つだ。実はその答えについて、以前このサイトで書いたことがあるのだが、もう9年も前の記事（笑）なので、覚えておられる読者も少ないだろう。そこで、あらためて考えてみていいただきたい。最初にすべきことは何か？

相手が学生の場合、「日程を決める」「店を探す」「参加者のリストを決める」等々、いろいろな答えが思いつく限り出てくる。もちろん、どれもそれなりに正しいように見える。でも、求めている答えはそれじゃないです、どんな種類のパーティやイベントの場合にもあてはまる、唯一の普遍的な正解があるのです、とわたしは続けて説明する。しかし、その『正解』が出てくることは、まずない。

一方、相手が企業人の場合は、ほしい答えを言い当ててくれる人が、ときどき、いる。わたしの求める答えとは、『計画を立てる』である。同期3人の飲み会なら、その場の勢いで決めて動ける場合もある。だが30人の参加するイベントとなったら、計画を立てずに進めることは、まず、できない。

イベント（という種類のプロジェクト）では、

　(1)計画を立てる、

　(2)準備をする、

　(3)当日のイベントを実行する、

　(4)終結する、

という大きな4つの段取りを、必ず経ることになる。その第一歩が「計画を立てる」ことなのは、ある意味、企業人から見たら当然だろう。だが、学生にとっては（たとえ東大の大学院生であっても）、「当然の常識」ではないのだ。

そしてここに、わたし達の文化の持つ、弱みが透けて見える。計画という仕事の位置づけが、社会の中で薄いのだ。わたし達の社会が、大規模な兵站（ロジスティクス）に弱いことは、今回のワクチン供給騒動でもあらわになった。その根本原因は、計画能力の弱さにある。だからこそ、わたしは拙著『世界を動かすプロジェクトマネジメントの教科書』で、大事な「チャレンジのOS」の3要素の一つとして、「かならず計画を立てる」を入れたのである。

それでは、計画とは、どうやって立てるのか？　成功する計画立案の技術があるとしたら、それはどのようなものか？

計画の技術について、大学で教わったという読者は、何人おられるだろうか。あるいは、小中高校で聞いた記憶がある、という方は？　まあ、たぶんどちらも、ほぼゼロであろう。じゃあ会社に入って、計画の技術について、教わったことはあるだろうか？

ある、という方は、それでもきっと少数派だ。だからこそ、当サイトのの存在意義があるのである。

計画を立てるとは、次のようなステップからなるプロセスである。

０ 何をなすべきかを明確にする。ゴールは何か。目的・目標は何か。そして制約条件は何か

　→Project Charterに、それを書く

１ それを実現するために必要なActivityをすべて洗い出し、構造化・リスト化する。重複も、洩れもないように

　→Activityリスト・WBSに、それをまとめる

2. それぞれのActivityを誰がやるべきかを考える

　→組織図・分担表で、それを定める

3. Activityの順序と必要な期間から、全体工期と着手・期限を決める

　→Logic network図とマスタスケジュールに、それを表す

4. 必要な期間・作業量から費用を見積り、収支を計画する

　→実行予算で、それを規定する

5. リスク・アセスメントを行い、計画全体を修正する

　→リスク登録簿に、それをまとめ、必要に応じて1〜4に戻って、計画を修正、完成する

個別のステップの説明よりも、なぜ、このような流れなのかを、ぜひ理解しよう。まず、最初はプロジェクトという活動の目的（Why）と、目標・制約を明らかにするところから、出発する。これを定めずに、お金や人の話をしても仕方がない。

では、なぜ次に、ビジネス界で一番重要な、お金の計画に進まないのか？　答えは簡単だ。具体的に何をやるかが決まっていなければ、コストを見積もりようがないからである。だからWhyの次は、何をやるべきか（What）、つまりアクションの洗い出しになる。それが見えてきたら、誰にやってもらうのがふさわしいか（Who）を考える。ここには、外注とか調達などの要素も入ってくる。

そして、誰が何をやるか、が見えてはじめて、スケジュール（When）について議論することができる。スケジュールが分かってはじめて、プロジェクトを構成する各種の活動Activityについて、費用を見積ることができるのだ。とくに人件費や場所・ツールといったリソースの費用は、期間に応じてコストがかかるのが通例だから、スケジュールが決まってはじめて、コスト計画が可能になるのである。

そして、誰が何をいつ、どうやって、どれだけの費用をかけてやるのかが明らかになって、はじめてリスク・アセスメントが意味を持つのである。その結果、何らかのリスク対策が必要になるかも知れない。つまり、計画の見直しとアップデートだ。ここで、計画立案作業に、多少のリワークが生じる可能性がある。だが、この作業を、もっと前の方のステップでやることは、できない（やっても意味がない）。それは失敗への道である。

PMBOK Guide(R)などで勉強した方は、ともすると、スコープ・コスト・スケジュール・品質・調達・コミュニケーション、などの領域を、お互いに対等で平等な関係だと誤解しがちである。だが、そんな事はないのだ。スコープ→人的リソース→スケジュール→コスト→リスク、という5大要素は、お互いの間に、明らかな順序的な依存関係がある。計画段階では、それを意識しなくてはならない。

ちなみに、最初のStep-0とStep-1の二つをあわせて、『スコープ定義』Scope definitionと呼ぶこともある。Charterができあがり、Activity ListとWBS辞書が作成された段階で、プロジェクト・スコープはかなり明確になる。つまり、やるべきことは明確になるのだ。仕事の地図が見えたと言ってもいいだろう。

その段階ではまだ、誰が、いつやるか、金はいくらかかるのか等、未定事項も多い。でもここが、プロジェクト計画策定プロセスの、前半の山場だとも言えるだろう。ようやく地図の全体像は見えた。目指すべき地点もはっきりしてきた。だがルートはまだ、ぼんやりしている。

ルートを明確にするのが、後半の作業だ。それは最終的には、お金とリスクの話に収束する。そして会社の経営者が一番気にするのも、この２つだ。だが、それを最初から考えることは、できない。地図もなく、ルートもわからないのに、切符代や旅行保険を議論できないのと同じだ。この順序で立てるから、実行可能な、つまり成功するプロジェクトの工程表と予算が出てくるのだ。

このアプローチのもう一つの特徴は、やるべき仕事（Activity）から、それを遂行する人や組織を考える点にある（上記のStep-2）。仕事を起点に、それに向いた組織を計画する。今すでに存在する組織と人を前提にして、仕事の仕方を考えるのではない。なぜなら、プロジェクトとはかならず初めての試みを含むものであり、それはしばしば、既存組織の境目やスキマに落ちるからである。

あるいは、計画づくりとは、建物のようなものだと考えることもできる。地盤の上に基礎（土台）があり、柱を立て、1階・2階と順に積み上げていく。コストとリスクは最上階だ。最上階から、先に作ることはできない。地盤に相当するのはProject Charterであり、基礎に相当するのがWBSだ。ここが不整形でヤワだと、その上にちゃんとした建物が建つはずがない。WBSはプロジェクト計画に共通する基礎なのである。

計画立案とは、ある意味、プロジェクトのモデリングを行う仕事である。モデルだから、一種の近似である。あまり細部までつっこむよりも、主要な点をうまく模倣できるかどうかが肝心だ。そしてモデルだから、あれをしたらどうなるか、ここを変えたらどうなるか、という検討のたたき台になる。

「ものごとは、計画通りには決して進まない。だが、計画は絶対に必要だ」との名言を残したのは、第2次世界大戦の連合国側の将校だった、アイゼンハワー元大統領である。彼は兵站（ロジスティックス）の重要性を、よくよく認識していた。大勢の人を動かす作戦は、出たとこ勝負では回せない。事前に頭の中で、シミュレーションが必要なのである。たとえ現実が予想から外れたとしても、頭を使ったことは無駄にならない。

わたし達の社会では、しばしばこの逆のパターンを見かける。最初に、ゴール地点の幸せなイメージがありるが、どういうルートをたどるとベストかの思考実験はない。かわりに、既存の人や組織に号令を下せば、あとはなんとか現場の頑張りで実現できるはずだ、という奇妙な楽観論があるだけだ。

そういうやり方も、今から半世紀以上前、前回の東京オリンピックのころまでは有効だったかも知れぬ。あの頃は、「突貫工事」という言葉が流行語になった。それはある意味、昭和的な単純思考の産物だが、社会もそれだけシンプルだった。21世紀の複雑系社会に生きるわたし達は、いきなり走り出す前に、もう少しだけ考える時間が必要なのである。

＜関連エントリ＞

　→「Structured Approachができる人、できない人」 (2012-07-08)