本記事の読みどころ
プロジェクトを始める際には、まずプロジェクト計画書を作成することが一般的ですが、この計画書が軽視される事例が散見されます。しっかり作ったもののメンバーにその内容が浸透しない、作ることで満足してしまっている、あるいは計画書自体が存在しない......など、問題点はさまざま。今回はプロジェクトマネジメントのプロ3人に、計画書の必要性、計画書作成でよくあるミスや事例、そしてメンバーに浸透させる方法などについて語ってもらいました。
プロジェクト計画書はなぜ必要なのか？
- プロジェクト計画書はプロジェクト内で共通認識を持たせるために必要
- プロジェクトに関わる人が多ければ多いほど、立ち返る場所（プロジェクト計画書）が必要
- プロジェクト計画書ではQCDを決めることが重要
―プロジェクトが始まるときに、単に「作らないといけないから」という理由でプロジェクト計画書を作るケースが結構多いように見受けられますが、そもそもプロジェクト計画書は必要なのでしょうか？
杉本：必要ですね。計画書は、経営層含めてそのプロジェクトに関わっている人たちの間で「認識違い」を起こさないために必要なんです。プロジェクトが進んでいくと、どうしても迷ったり、目的からズレてしまったりすることが必ずあるんですが、そのときに立ち止まって「ここに書いてあるじゃん」って、計画書があれば確認できるんですよ。
早川：教科書的に言うと、プロジェクト計画書は「このプロジェクトがなんのためにあるのか」というプロジェクトの目的をきちんと言語化して、関わるメンバーの間で共通認識を持たせるためのものですよね。
小宮：ただ、そもそもプロジェクト計画書がないケースが多いんですよ（笑）。例えば我々が途中からプロジェクトに参画して、このプロジェクトの概要を把握するために計画書を見たいと思っても、計画書自体が存在しなかったり、仮にあってもざっくりした目的や期間、予算くらいのざっくりした情報しか書かれていなかったりして、「なんじゃこれ」ってなる。
こうなると、杉本さんが言ったように、プロジェクトの途中で何か問題が起きて解決できずに困ったとしても、それが「計画書が存在しないからだ」ということに気づくことができないので、計画書の必要性が正しく認識されないまま放置されていることがほとんどだと思います。
―なるほど。そもそも計画書自体がなかったり、たとえあったとしても計画書の体を成していなかったりすると。
小宮：はい。でもどうしても問題は起きるわけです。単純に自分1人とか数名単位で全部できるようなプロジェクトであれば、計画書がなくてもなんとかなると思います。でも10人、20人、さらに100人とかが関わる大規模なプロジェクトでは、計画書がないと何か問題が起きたときに適切に対処できないんです。
想像してみてください。例えば、何か会議をやるにしても大人数であればあるほど、「とりあえずみんな集まって話しましょう！」とはならないですよね。参加者の役割をちゃんと決めて、テーマを掲げたうえで議論を始めて、もし話が脱線すれば「何を議論する場なのか」って立ち止まって考えるじゃないですか。プロジェクトの場合、その立ち返る場所が計画書です。計画書がないと大人数のプロジェクトでズレが生じた場合、そのズレを修正できないままずるずる最後までいってしまうんです。
一番致命的なのが、QCDのどれを優先するかの部分をきちんと定めておかないことで起きる問題です。プロジェクトは、常にトレードオフの連続です。Q＝クオリティ（品質）を優先するのか、C＝コスト（費用）を優先するのか、それともD＝デリバリー（納期）を優先するのか、都度都度この選択を迫られますが、どれを優先するのかの判断基準になるのが計画書なんです。計画書がないと、そのときそのときの思いつきの判断になってしまって、意思決定がどうしてもブレる。例えばQ＝クオリティ（品質）が優先なのに、納期が近づくとみんなD＝デリバリー（納期）を優先し始めて、品質を落としたりするんですよ。でも「このプロジェクトはとにかくQ＝クオリティ（品質）が優先」と決まっていればそうはならないんです。
一同：はい。
小宮：Q＝クオリティ（品質）が優先ということがちゃんと決まっていれば、納期を優先すると品質に問題が生じそうだという場面で、自然と「納期を延ばす交渉をする」という選択になるじゃないですか。最初にちゃんと決め事を言語化しておけばいいだけのことなんです。その重要性をみんながわかっていないというのが、計画書が放置されたり、ただのお飾りになってしまう原因だと思います。
プロジェクト計画書ではQCDの優先順位をどう決める？
- QCDのすべてが大事は、すべてが大事ではないのと同じ
- QCDの優先にはトレードオフがあることを理解する
- QCDの優先によってリスクが伴うことを共有する
―とは言っても、QCD（品質、コスト、納期）の優先順位を決められないプロジェクトが多いと感じます。
早川：QCDの話でいうと、どうしても「全部大事」ってなりがちですよね。私も事業会社にいたときはそう思っていた節があります。小宮さんが以前「みんな好きは誰も好きじゃないと言っているのと同じで、QCD全部大事は全部大事じゃないと言っているようなもの」というようなことをおっしゃっていて、すごく理解した記憶があります。
小宮：トレードオフがあることを理解していないというのが大きいと思います。あとは忖度です。
仮にQCD全部優先というのを受け入れたときに、当然そこには応える現場側のリスクがあるじゃないですか。ではなぜそのリスクを伝えないのか。「言えない」ということもあるかもしれませんが、忖度による部分も大きいと思います。それに、全部実現できるんだったら言った者勝ちです。それで失敗という結果に終わって、いざ振り返ったとしても、計画書もないので何がだめだったのかがわからない、と。
でもこういう失敗って日本でずっと繰り返されているんです。100年前の日本軍とまったく変わっていないんですよ。出口戦略がないとか、目的が二重化しているとか、いろいろありますけど、失敗の本質は昔も今も変わっていないんです。下は上に気を遣って言えない、上は上でリスクを聞こうとしない。そして失敗して、原因が不明なまま次のプロジェクトに進み、また失敗する......。このループがもう延々と繰り返されている。だから我々のようなあまりしがらみのない第三者が「計画書は必要だよね」「リスク管理しなきゃ駄目だよね」という当たり前だけど大切なことを、ある意味リズムを壊していくような感覚で、繰り返し伝えていくことが重要ですし、それこそが求められていることだと思います。
プロジェクト計画を経営と現場で認識をどうすり合わせるか？
- プロジェクトにおいて何を優先するのかを経営戦略と合わせる
- プロジェクトの価値や市場への貢献をしっかりと議論する
- 経営層と現場でリスクを共有する
―話は経営層の判断基準のほうにまで入っていると思うんですが、例えばQCDの重要さを経営層にちゃんと伝えるときのポイントなどはありますか？
早川：そもそもの話ですが、プロジェクト云々以前に経営戦略があるのが本来の姿ですよね。経営があり、その中に事業があり、そこから生まれるのがプロジェクトなわけですから、下からどう伝えるかの前に経営側がそれをきちんと把握しておく必要があると思います。
もちろんプロジェクトの発足にはさまざまなパターンがあると思いますが、結局そのプロジェクトにおいて「何を優先するのか」の部分が経営戦略とずれていれば、うまくいくものもいかなくなってしまいます。まずは経営が上位にあって、そこの戦略とプロジェクトが紐づいていないとうまくいかないんです。
―「とりあえず予算をとったからやれ」とかにありがちな問題ですね。
小宮：それがまさに今話題のDXですよね。とりあえずよくわかんないけど「DX構想」みたいな文脈に沿って予算があるからやれと上が音頭をとって、みんなが上から降りてきたものを一生懸命やるみたいな。
早川：それこそ手段が目的化していますよね。プロジェクトがどう生まれるかの問題はありますけど、そのプロジェクトに価値はあるのか、市場にどのように貢献するのか、といった議論がされていないケースが散見されますよね。さっきの日本軍の話もそうだと思うんですけど、往々にして現場と経営層が違う考えで動いてしまがちというか、そこのギャップを埋めていかないといけないですよね。
小宮：すごい平たく言えば、プロジェクトって誰もやったことがない仕事のことを言うんですよ。ある程度ルーティンが決まっていて、その繰り返しという仕事がある一方で、プロジェクトって誰しもが初めてやる仕事なんです。誰もやったことがないんだから、普通に考えたらリスクしかないんです。
だから「リスクはない」っていう考え自体がまずおかしくて、むしろプロジェクトはリスクだらけです。なのでまずは「どこにどんなリスクがあるか？」っていうのを考えなければいけないんです。そこの認識を変えないと、まさに100年前の日本軍じゃないですけど、「必勝の精神でやれ！リスクなんて考えるな！」みたいな話になってしまいます。
早川：過去に似たようなプロジェクトが成功しちゃってたりなんかした日には、何も考えずに突き進む、なんてこともざらにありますからね。
―経営と現場との考えのギャップとか、その辺を埋めるよいアプローチはありますか？
杉本：まず、現場は「リスクを言いたがらない」、上は「リスクを聞きたがらない」という構造がありますよね。現場は上への忖度が働いて、本当はリスクがあるんだけど「うまくいっています」って調子のいいことを言ってしまうと。でもこれは、経営層が「そんなことないでしょ」と気づくべきなんですよ。「うまくいっているのか。引き続き頑張ってくれたまえ」で終わっちゃうことが往々にしてある。もちろん下は下で、空気を読まずに本当のことを伝えていくということが必要なんですけど。
小宮：経営側のそのリスクを聞かない姿勢っていうのは、ほんとその感覚は何なんだって逆に聞きたいぐらいですけどね（笑）。そういう感覚をお持ちの方々の話を聞くと、「システムのことはわからないから」とか「現場のことは現場に任せているから」みたいなこと言うんですけど、そもそもわかろうとしていないんですよ。なんなんだろうなと思いますけどね。
早川：責任は重いはずですよね。
プロジェクト計画書にまつわるトラブル事例
- 事例1 経営層への交渉がうまくいかない
- 事例2 意思決定者があいまいで誰に判断を仰べきか不明
- 事例3 体制図にいる浮いた役割の人が問題になる
―みなさんがプロジェクト計画書の作成やその支援を事業会社にしたときに、実際にあったトラブルや障壁にはどのようなものがあるでしょうか？
事例1 経営層への交渉がうまくいかない
杉本：最初にも話がありましたが、プロジェクトの途中から参加したときに計画書がないという事例ですよね。そもそもプロジェクトって全然予定どおりにいかないんですよ。なので、そのたびに経営層と話す必要が出てきます。先ほどの「QCDの何を優先しますか」とかの相談だけでなく、「このままだと期間が足りなくなってしまうので、もっと増員できませんか？」とか「ちょっとこのままだとクオリティに懸念があるので、予算を増やせませんか？」とか、さまざまな交渉をしていく必要があります。そのときに手ぶらで臨んでもほぼうまくいかないんですよ。そのときに、プロジェクト計画書などの第三者がパッと見られるドキュメントがあると、それがこちらの要求の根拠としてはっきり伝わるので、交渉は格段としやすくなります。
事例2 意思決定者があいまいで誰に判断を仰べきか不明
早川：私が何回か経験したのは、プロジェクトにおける意思決定者があいまいなケースや、意思決定するポジションが2系統あるようなケースです。最終的に「誰が決めるんですか？」みたいなことが、計画書からは判断できない。こうなると、プロジェクトの途中で何か問題が起きたときに、誰の判断を仰げばいいかわからないですよね。とくに会社をまたぐプロジェクトの場合は、この辺があいまいになりがちです。そういうときは、まずは意思決定者から整理して、計画書の体制図のところで責任の所在を明らかにしつつ、問題が起きたときにはちゃんとそこに立ち返るようにする、ということは結構経験しました。
事例3 体制図にいる浮いた役割の人が問題になる
小宮：最後にちょっとだけ（笑）
体制図の話もまさにあるあるです。体制図はツリー構造やピラミッド構造になっていて、てっぺんの部分を見れば意思決定者がはっきりわかるようになっているのが基本です。早川さんが言うように、それが2系統あるケースもそうなんですが、不思議なのがその体制図の周りに浮いている箱とかが書いてあることがあるんですよ。「これは誰ですか？」と聞くと、「ご意見番です」と。ツリー構造の中には入らないけど、この人の名前を入れておかないとバツが悪いからとりあえず入れておかないとみたいな、よくわからない理由で浮いた箱が誕生します。でもこれを見た人は「どうすりゃいいんだ？」ってなりますよね。「自分のレポートラインはここだけど、ここに書いてあるということは何かえらい人だろうから、一応こっちにも根回ししておくか......」みたいな変な忖度が作動してしまうんです。
あと「責任」という言葉はみなさんよく口にするんですけど、「責任って何ですか」って聞いてもほとんどの人が答えられないんですよね。責任には必ず権限が伴います。権限があるからこそ、責任が生じるんです。この浮いている箱の人たちって役職者が多いんですが、そのプロジェクトにおいて何の権限があるのかというと、本人たちもわかっていないことがほとんどです。上長という理由だけで呼ばれて、みんなが変に空気を読む。これは本当に大問題なんですが、それは100歩譲って仕方ないとしても、組織を作ってヒエラルキーを設定するんだったら、権限と責任をちゃんと定義しないといけないんですよ。それを本人たちにちゃんと理解してもらい、重要な局面で判断してもらうということをはっきり決めておかないと、何も進まない。それをうやむやにしながら、「大丈夫です、こっちでやっときますから」「ここにハンコを押すだけですから」みたいに周りの人間が忖度してやっちゃうから、大問題が起きて大失敗するんです。
何か問題が起きたときに上長の人たちにいろいろ話を聞くと「いや私にそこまでの権限があるとは思っていませんでした」とか、よくある話ですけど、こういうことにならないようにしなきゃいけない。これ以上言うと多分止まらない（笑）
プロジェクト計画書の内容をメンバーに浸透させるにはどうすればいい？
- プロジェクトでの役割と個人のキャリアパスを紐付ける
- プロジェクト内で心理的安全性を確保する
- 繰り返し繰り返しプロジェクト計画書を伝える機会をつくる
―プロジェクト計画書を頑張って作ったけど、誰も覚えいてないとか、全然読んでいないとか、よくあると思うのですが、そうならないためにはどうすればいいでしょうか。？
杉本：まずは、役割と定義をちゃんと決めておくことが重要だと思います。君の役割はこれ、君のキャリアパスにはこんな影響がある、このプロジェクトを通してこういう経験をしてこういう貢献をしてほしい......といった、プロジェクトの目的と個人のキャリアパスを紐付けてちゃんと伝えることが大切ですね。それがあると、掲げた目標に一緒に進んでいきましょうという雰囲気が醸成されていきます。
あとは心理的安全性を確保することも重要で、「ちょっとこれはやりたくないです」といった言いづらいことを言える関係をちゃんと作っておくと、メンバーに計画書の中身の部分が浸透しやすいかなと思います。
早川：私もまずは心理的安全性がポイントかなと思いました。最近まで支援していた事例では、若手のメンバーの方に対して、役割やキャリアパスとの紐付けの部分が全然語られないまま、「これだけやっといて」と雑に投げられる場合が多くて、そうなるとみんな「もうやりたくない」という気持ちになってしまうんですよね。あとは長期のプロジェクトだと、どうしても計画書に書かれた内容を忘れてしまいますし、メンバーの入れ替わりもあるので、定期的に認識をすり合わせる意味でも計画書に立ち戻って確認する作業をしていくことが重要かなと思います。
小宮：すごい簡単な話をすれば、計画書が浸透しないのは誰も説明しないからです。
最初に計画書を作ってキックオフしても、ほとんどは儀式で終わってしまう。「計画書はあとで読んどいてね」のようにさらっと触れても、あとでちゃんと読む人なんていないですよ。いざプロジェクトが始まって人が増えて、そのときに計画書の内容をちゃんと説明しますと言ってもしていないでしょと。ちゃんと説明しようよって話なんです。
繰り返し繰り返し、ことあるごとに話す。プロジェクトのフェーズの変わり目に「このプロジェクトはこういう計画・内容です」という計画書の中身を話すイベントをもうけて、ちゃんと話せばいいんです。
慣れてくると、いやそんなもん読めばわかるだろうとか、暗黙の了解のようなことが増えていくんですが、そうなると後から入ってきた人たちは聞きづらい。これはさっきの心的安全性の話ですよね。そういう空気ができてしまうと、計画書はちゃんと読まれないし浸透しない。まとめると、ちゃんと作ってちゃんと伝える。そして、ちゃんと言いやすい環境を作る。それをするだけでいいんです。
プロジェクト計画書のポイント：まとめ
設計図なしに作られた大規模な建築物......考えただけでも恐ろしいですが、プロジェクトに置き換えてみると、この設計図に当たるプロジェクト計画書が軽視されがちです。計画書に書かれた内容に沿ってプロジェクトは動き出しますが、ゴールに向かう過程で必ず問題は起きる。そのたびに適切な判断を迫られますが、その際に判断の基準となるのは、常にプロジェクト計画書なのです。
また、計画書はプロジェクトに関わるメンバー全員が内容を理解し、困ったときに立ち返れる場所として認識することで初めて大きな意味を持ちます。その共有作業は地味で簡単なことではないかもしれません。しかし、問題が起きたときや新しいメンバーが加わったときなど、その都度計画書の内容を共有し、浸透させることは、プロジェクトの成功確率を高めるうえで必要不可欠と言えるでしょう。
（撮影／音孝典 取材・文・編集／福井寿和、白戸翔）
前職にて基幹業務システムのコンサルタントとして従事、2008年にMSOL入社。その後約15年間、大手製造業や情報サービス企業にて、大規模プロジェクトにおけるPMOおよび、組織横断的なプロジェクト監査/支援組織の立ち上げなどに従事。直近ではPMOサービスのアウトソーシング事業(PMO Center)の立ち上げと推進に携わる
2007年に教育・介護事業会社の機能子会社に入社し、ユーザーサイドよりITプロジェクトや運用業務に従事。その中でシステム開発プロジェクトにおけるPMOを経験し、より体系的にマネジメントを習得したいと考えMSOLへ入社。その後大手小売業、製造業等で大規模プロジェクトにおけるPMOおよび、部門PMOに従事。
デジタルマーケティングのアウトソーサーとして主に金融系、通信キャリアを中心にWebサイト制作のプロジェクトマネジメントや業務設計、事業計画、営業企画、生産担当責任者として品質管理、約100名のメンバー管理やベンダーコントロールに従事。その後、2022年にMSOL入社。DX推進プロジェクトなどのPMOに従事。