プロジェクト計画を美しく作りすぎると進行が窮屈になる

社内のプロジェクトに参加したことはあるが、PM（プロジェクトマネジャー）をしたことはない、というビジネスパーソンにお聞きします。

「ハイレベルのプロジェクト計画」というと、どんな計画をイメージしますか？

「非常に良くできた上等な計画」という意味ではありません。

今後具体化していく（下位のレベルに落とし込んでいく）アバウトな計画のことです。

プロジェクトは「やってみるまで分からない」部分が必ずあるチャレンジングな仕事です。

プロジェクト計画を経営層やクライアントに提示するために、できるだけ詳細な計画書を作ろうというPMの気持ちは分かりますが、やってみるまで分からないことを分かっているかのように書くと、その「美しい計画書」がプロジェクトの進捗の邪魔をすることになります。

この記事では、プロジェクト計画書を作るとき注意点や勘どころを、分りやすく解説しています。

これからプロジェクトマネジャーの大役を任される可能性があるビジネスパーソンの方はぜひ参考にしてください。

プロジェクト計画はあくまで暫定計画

受験勉強で200頁の参考書を1ヶ月で終えるには1日7頁やればいいーという計画を立てても、200頁の中にはマスターするのが難しい箇所もあれば、簡単な箇所もあります。

どこが難しくてどこが簡単かは、やってみるまで分かりません。「1日7頁」というきっちりした計画を作っても無意味なのです。

プロジェクト計画にも同じような問題があります。

• プロジェクト計画の前提になるプロジェクト憲章とは
• プロジェクト計画の内容
• スコープとスケジュール

プロジェクト計画の前提になるプロジェクト憲章とは

プロジェクトマネジメントを学ぶための「世界標準」とされるPMBOKガイドには、プロジェクトを立ち上げるには「プロジェクト憲章」を作らなければならないと記されています。

「そういうものは見たことがない」という方も多いと思います。日本ではプロジェクト憲章をパスして、いきなりプロジェクト計画に入る例が多いからです。

しかし、「憲章」なしに「計画」に入ることが計画づくりを難しくし、ときにはプロジェクトの行く末を危うくすることがあります。

プロジェクト憲章は経営層またはクライアントが、正式にプロジェクトの立ち上げを許可する文書で、PMに会社のリソース（ヒト・モノ・金）を使う権限を与えるものです。

プロジェクト憲章に書かれるのは次のようなことです。

・プロジェクトの目的
・ゴール（どこまでできれば成功と言えるか）
・前提条件と制約条件 （もう決まっていて変更できないこと）
・スケジュール
・予算
・リスク
・PMの名前とその責任範囲

これを見て「プロジェクト計画とどこが違うの？」と思いませんか？

それもそのはずで、項目はほぼ同じです。

違うのはプロジェクト計画がよりハイレベル（アバウト）だということです。文書の量もA4用紙2枚くらいがふつうです。

とくに、スケジュール、予算、リスクはハイレベルで、「やってみなければ分らない」を許容しています。

このようなプロジェクト憲章がある場合とない場合では、プロジェクト計画のスタート地点が違うのは容易に想像がつくと思います。

ない場合はある意味で憲章づくりから始めなければなりません。

つまり、「許可」の責任や「権限」の範囲にあいまいさを抱えたまま計画づくりをしなければならないのです。

プロジェクト計画の内容

PMBOKガイドにはプロジェクト計画書の内容（構成）を次のように記しています。

・目的
・ゴール
・スコープ（範囲）
・スケジュール
・コスト
・体制
・品質マネジメント
・コミュニケーションマネジメント
・リスクと対策

プロジェクト憲章がある場合は、目的やゴールなどはすでに「合意」ができているのでそれを書き写せばよいのですが、ない場合はPMがたたき台を作って経営層やクライアントの認可を得るのも計画づくりの一部になります。

つまり実質的な憲章づくりが、計画づくりのスタートになるわけです。

それを経て、プロジェクトメンバーが参加するのキックオフ会議までに、上記の構成を備えたプロジェクト計画を作成することになります。

スコープとスケジュール

上記のプロジェクト計画の項目の中で、毎日のタスクに直接関わるのがスコープとスケジュールです。

スコープとは、目的・ゴールを達成するために必要な作業範囲のことです。ここでも当然、どの範囲までやればゴールに到達できるかという、不確定要素をはらんでいます。

計画書でハイレベルなスコープが示されたら、実作業にかかる前にWBSを作成します。

WBSは、Work（作業） Breakdown（分解） Structure（構成）で、よく例に出されるのが「ベーコンレタスサンド」を作るにはどのような作業をどの順番でやらなくてはならないかを分析して図示することです。

しかし、ベーコンレタスサンドなら最終工程まで見通して分解し、構成することができますが、システム開発などのプロジェクトではそうはいきません。最初からタスクを洗い出しつくすことはできないのです。

WBSはプロジェクトが進捗するにしたがって細分化されて具体的なタスク（ワーク・パッケージ）が決まっていきます。

スケジュール（タスクに要する時間）をグラフにしたガントチャートも最初はアバウトなものにならざるを得ません。

したがって、プロジェクト計画書でのスコープとスケジュールは、PMが過去の経験と知識からゴール（クライアントが要求する成果物）までにどれくらいの工数や時間が必要かを推察したハイレベルなものなのです。

プロジェクト計画を綿密に立てようとすると生じやすいマイナスとは

プロジェクト計画を詳細に立てようとすると、やたらに時間がかかるということを抜きにしても、プロジェクトの成否に関わる次のような問題点が生じます。

• アバウトな計画に詳細な上着を着せるとプロジェクトの本体が見えにくくなる
• メンバーが見ても理解できない計画になる
• 計画の手直し・メンテナンスを避けようとする

アバウトな計画に詳細な上着を着せるとプロジェクトの本体が見えにくくなる

本当は不明確なところを、分かっているかのように計画に書くと、実行段階でどんどん計画が狂ってきます。

プロジェクト計画はハイレベルで良いと心得、実行段階で変えていくのが当然と認識して、プロジェクトのラフスケッチ、絵コンテのつもりで書くべきです。

本当はラフなもの、粒度のあらいものに美しい上着を着せてしまうと、計画の本体が見えにくくなり、プロジェクトのあちこちにブラックボックスを生じさせることになります。

メンバーが見ても理解できない計画になる

見かけだけが整った「張りぼて」の計画書は、プロジェクトメンバーが読んだときに、「分かるようでよく分からない」ものになります。

プロジェクト計画書は、実行段階に入ったらメンバーのコミュニケーションツールになります。

文書で持っているにしろツールに落とし込むにしろ、メンバーは計画書を道しるべにして仕事を進めます。

PMはどの辺がアバウトかを自覚して、見る人にもアバウトさが分るように書くことが大切です。

また、計画書はクライアントや社外の協力者も見る文書です。誤解や認識のずれを防ぐように、社内だけで通用する専門用語は使わずに、平易に分りやすく書くことが大切です。

計画の手直し・メンテナンスを避けようとする

プロジェクト計画はスコープやスケジュールが変更されることが織り込まれた文書です。

あまり立派な計画書を作ってしまうと、計画の変更を避けようする気持ちが無意識に働いて、それが後々プロジェクトを炎上させる原因になることがあります。

プロジェクト計画　まとめ

プロジェクト計画は、目的やゴールは明確に定める必要がありますが、スコープやスケジュールはアバウトにならざるを得ません。

スコープとスケジュールを見透すのはPMの腕の見せ所ですが、無理をして見かけだけの計画書を作ってはいけません。

プロジェクトのリスク管理に最初からハンディキャップを持ち込むような「美しい計画書」を作ろうとせずに、実質本位の正直な計画を立てることが肝心です。

また、作られた計画書はプロジェクトの根幹になるコミュニケーションツールです。管理ツールなどを通じてメンバーと共有して、タスクのベクトルを合わせるために活用しましょう。