--- title: 立ち上げ時点で炎上確定！こんなプロジェクト計画は嫌だ date: 2017-05-10 description: プロジェクトの成否は計画にあり。炎上確定の拙い計画を作らないために最低限必要な3つのレビュー観点をご紹介。 categories: [productivity] tags: [planning] source: https://work.naenote.net/planning-basics/ --- ビジネスパーソンのみなさま、日々お仕事お疲れさまです。NAEでございます。 みなさま**プロジェクト計画書**というものを読んだことはありますか？ プロジェクト計画書とは、プロジェクトが体をなすために必要な情報が盛り込まれた、とても重要なドキュメントです。 今まさに目の前でこなしている仕事は実は大きなプロジェクト計画のなかの1つのタスクだ、という方が多いのではないでしょうか。 さてこのプロジェクト計画書、ドキュメントとしての体裁がよく整っているため一見よくできているように見えますが、実は**良し悪し**があります。むしろ**プロジェクト計画の時点で炎上がほぼ確定している場合**すらあります。 そこで今回は、ぼくが過去経験したor見聞きした事例をもとに、こんなプロジェクト計画は嫌だというお話をさせていただきたいと思います。 ## プロジェクト計画とは プロジェクト計画とは、当該プロジェクトの建てつけが書かれたドキュメントです。 プロジェクトは「定められた期間とコストで定められた品質の成果を実現する」という性質を持つ仕事。またほとんどの場合チームプレーになるため、関係者を巻き込んで足並みをそろえて動くことが求められます。 そのため建てつけとして * プロジェクト立ち上げの背景 * プロジェクトの目的やゴール * 成果物の一覧 * マイルストン、作業計画、人員計画 * 参画メンバー、体制図、役割分担 * コミュニケーション計画 * 前提事項 といった、「なぜやるの」「何をやるの」から「いつ誰が何をするの」を導き出して共有することが非常に重要です。ゲームで言うなら「ぼうけんマップ」みたいなものですね。 これらが書かれたドキュメントが、プロジェクト計画書です。 ## 炎上確定！こんなプロジェクト計画は嫌だ プロジェクト計画は関係者に共有される前提で作られるため、多くの場合きちんとした体裁をしていおり、パッと見「いい感じ」に見えます。 しかし中身をよくよく見てみると、見た瞬間にコレ炎上確定だと思うものもちらほら… 以下、ぼくがこれまで出会った**アンチパターン**を4つピックアップして紹介してみます。 ### 前提事項が不明確だ ![海岸での砂遊び](https://media.work.naenote.net/2017/05/sand_castle_1494210099.jpg) 一つ目がプロジェクト開始のための前提事項が書いていない、不明確、もしくは不足しているパターン。 これはいわゆる砂上の楼閣であり、極端に言えば「残機ゼロ」で走り出す行為です。 1つのミスが致命傷につながる状態で、非常によろしくありません。 例をあげてみましょう。 プロジェクト初日に関係者を集めた全体のキックオフ会議を行う予定だった。 しかし関係者のスケジュール調整が十分にされておらず、キックオフは1週間後に延期となってしまった。 もともとキックオフで議論・合意する必要のあった根本的な議題が先送りになったため、その他作業に着手できず、いきなり1週間の遅延が確定した。 いち早くプロジェクトを開始したいという要望に応え、プロジェクト開始時点で分析作業に着手できるよう、それまでに必要な資料が提供されている前提でスケジュールを組んだ。 しかしいつまでたってもクライアントから資料が共有されず、プロジェクト初日を迎えてしまった。 インプットがなければアウトプットが出せないのは必然。結果、初日から遅延が確定した。 プロジェクト計画上、初日からクライアントのオフィスにベンダーさんを招聘し作業に着手していただく前提になっていた。 しかし当日になって作業場所が確保されていないことが判明し、会議室利用申請や入館証の申請などもろもろのアドミ作業を急ぎ行った。 しかし作業開始できたのはプロジェクト開始から1週間後であり、のっけから1週間の遅延を抱えてのスタートとなった。 このようにプロジェクト開始の前提が明確でない、もしくは前提が揃っていない状態で見切り発車すると、前提事項をそろえる「露払い」で最初の何週間かが潰れ、いざという時のために取っておいたバッファ（予備期間）が食いつぶされます。 最悪の場合、開始初日からいきなり進捗遅延、初回の定例会議でいきなり緊急度の高い課題を報告、という憂き目を見ます。 これ、プロジェクトオーナーからすると「なんで？」と言いたくなるものばかり。説明のために食いつぶされた工数がさらに食いつぶされてしまう悪循環に陥る第一歩です。 また前提事項が不明確であるがゆえに追加作業が発生したとしても、それは計画が悪かったのであって、巻きとるのはプロジェクト側の責任です。誰も助けてくれませんし、助ける義理もありません。「プロジェクト側が手持ちの期間や工数でなんとかしろ」となります。 そして炎上へ・・・ 参考: [プロジェクト計画の前提が崩れたまま走り続けると現場が死ぬ](/start-negotiaion-when-assumption-changed/) ### 刺身ばかりだ ![刺身状態のプロジェクト計画](https://media.work.naenote.net/2016/12/Screenshot-2017-05-08-at-11.39.57.png) *タスクが刺身になっている状態* 「刺身」とは、プロジェクトのスケジュールに書いてあるタスク（矢羽）が全体的にヨコに間延びして重なっている状態を指します。 複数のプロジェクトをまとめた「プログラム」くらい大きな取り組みであればスケジュールの全体像が刺し身になっていても許される可能性があります。各プロジェクトの開始日と終了日をビジュアル化するのが目的という場合があるからです。 しかしプロジェクトの単位でスケジュールが「刺し身」になっていたら赤信号。**開始から終了まで間延びした矢羽が複数重ねて置いてあるだけの計画は、計画ではなくただのイメージ画像です。** こんなざっくり荒々しい計画でプロジェクトを見切り発車するとどうなるでしょうか。 例を見てみましょう。 作業レベルに分解されていない矢羽を見た各メンバーが、現場レベルの「ミニ計画書」を作り始める。 最初の1週間くらいはそれで走れるし進捗的には「順調です」と報告される。 しかし全体的な整合性や依存関係は検証されないため、遠からず手戻りの嵐に見舞われる。 長い矢羽を作業レベルに分解できないメンバーが上司に都度作業指示をもらいにくる。 今すぐに作業を振らないと部下の時間が無駄になると考えた上司は、その場その場で矢羽の中身を想像して作業を振る。 このオーバーヘッドが積み重なり本来の作業に割く時間が削れられていき、残業の嵐につながる。 全体の進め方と個別の作業のつながりを腰を据えて考えず、都度判断で作業を振ってしまう。 するとプロジェクト全体の成果とのつながりが不明確な断片（個別作業の成果物）が量産される。 結果、重役への報告を前に「目の前のゴミの山」をいかにそれっぽく統合するかに苦慮する。 最悪の場合、その時点で重要なピースが足りないと判明し、リカバリ残業の嵐に見舞われる。 要するに刺し身ばかりのプロジェクト計画は、**プロジェクトを完遂するために必要な段取りを作る、大まかな依存関係を整理する、メンバーが理解して自走できくらいの粒度の作業に分割するといった重大な責務を放棄している**のと等しいわけです。 鳥の目と虫の目を兼ね備え、全体の整合性を見ながら自ら連携ができるようなスジのいいメンバーが揃っているならそれでも回ります。しかし多くの場合、現場にスーパーマンはいません。 そして炎上へ・・・ 参考: [全ての仕事には意味があるべきだし、意味が無い仕事はしてはいけない](/every_work_should_be_significant/) ### 山と谷が激しい ![上下の激しいグラフ](https://media.work.naenote.net/2017/05/graph_1494211404.jpg) 山と谷とは、プロジェクト計画を人員計画に落としたときに見えてくる、期間ごとに必要な工数や頭数を指します。 全体像で見ると段取りがきちんとしているプロジェクト計画も、具体的な作業に落として必要な工数を積み上げてみると、特定の期間に工数が集中して作業がたて込む場合があります。 するとどうなるでしょうか。例を見てみましょう。 開始当初はとてもスムーズに進んでいたプロジェクト。メンバーの残業もほぼゼロだ。 が、とある期間にさしかかった途端、作業量が倍に増えた。計画上は正しい状態だが、計画通りに進めるにはどう考えても手数が足りない。 急いで他のプロジェクトにヘルプを要請したがみんな手一杯。メンバーの残業時間は増すばかり。しかし計画通りモノができあがる見込みはない。 付き合いの長いベンダーさんに頼み込んで何名かメンバーを補充でき、作業の重い期間をなんとか乗り切った。 しかし待っていたのはヒマな期間。せっかく来ていただいたメンバーが「オレなんでここにいるの」という顔をしているが、契約の関係でもう1ヶ月は一緒に働かなければならない。 人件費増で圧迫されたプロジェクト予算が重く頭にのしかかる。 作業の重い期間に抱えてしまった遅延があとを引いてしまい、その後のスケジュールを全体的に圧縮せざるをえない可能性が出てきた。 リカバリ案を検討したものの、作業の性質上、人を増やせばリカバリできるシロモノではない。今いるメンバーで乗り切るのが最善手だ。 しかし皆すでに疲弊しきっている。さらに残業を頼むことになるのか。 作業計画を人員計画に落としたときに全体が平坦になっているか？という検証をしないとこういうことが起こります。いわゆる**「山積み・山崩し」**というやつすね。 **人材は出せば使えていつでも捨てられる便利な歯車ではありません。**調達や配属には時間がかかります。プロジェクトから外すのもそう。加えて本人の思いやキャリアにも配慮が必要ですし、適切なスキルを持っていないとそもそも配属しても無意味なんてことにもなりかねません。 だからこそ、人材を扱う人員計画には細心の注意が必要です。**仕事を形作るのは人（スキル）です。**どのようなスキルを持っている人が、いつ、どのくらいの数必要なのか？調達可能か？こういった点が検証されていなかったり、そもそも作業計画で満足して人員計画が適当・すざんなプロジェクト計画を見たら、秒速で赤信号を灯さなければ恐ろしい未来がやってきます。 そして炎上へ・・・ 参考: [人材やスキルのミスマッチはデスマーチの火種。資質を見極めて炎上を防げ](/skill-mismatch-causes-death-march/) ### 自プロジェクトしか見ていない ![自分のプロジェクトだけにフォーカス](https://media.work.naenote.net/2017/05/graph_1494213964.png) プロジェクト計画に自プロジェクトのことしか書いていない場合、炎上する可能性がきわめて高いです。 プロジェクトはあくまで企業活動の1つ。他にもたくさんのプロジェクトや定常業務が同時並行で進んでいます。そちらの動きをきちんと視界に入れ、密に連携しないと足元からひっくり返るリスクが高まります。 関係者との連携を軽視したワガママプロジェクトがどういう目を見るか、例を見てみましょう。 プロジェクトを立ち上げた。作業計画も人員計画も完璧だ。 が、実際に走り出してみたところ、初回の役員報告で「あっちのプロジェクトと足並みそろえて」というフィードバックがあった。 よくよく調べてみると、すでに作成済の成果物に対してあちらの検討結果を反映する必要が見えてきた。依存関係があったのだ。 結局成果物は作り直しになり、プロジェクト計画全体も後ろ倒しする羽目になってしまった。オレの完璧な計画が台無しだ。 依存関係があると判明した他プロジェクトに「今版のドラフトでいいからその資料がほしい」と依頼した。 結果すぐさま資料をもらえたため、それをベースにわがプロジェクトの作業が着手できた。傷は軽微だ。 しかしフタを開けてみると、ドラフト版と完成版で書いてあることが全く違う。なんだこれは。 事情を聞いてみると、どうやら部長級報告で方針がひっくり返ったようだ。こっちの作業もイチからやり直しになってしまった。これではどう考えてもカットオーバーに間に合わない。 なんとかカットオーバーまでのめどはつけた。しかし定常業務の担当部署に今後の業務変更ポイントを伝える期間をかなり圧縮しなければならなくなった。 これまでの経験上、全部きちんと伝えるには説明会が2回は必要だ。 さっそく日程調整に乗り出したが、その期間は繁忙期のため2回も説明会に付き合っていられないと突き返されてしまった。 これはきちんとロールアウトできるのか…？ このように、プロジェクト外との連携を無視・軽視したプロジェクトは外的要因でいとも簡単に遅延します。炎上は内部要因だけでなく外部要因によっても引き起こされる、ということです。 しかしプロジェクト計画の中には、外部との連携が矢印一本だけで表現されているようなものもあります。これ赤信号です。 そういうプロジェクトほど、より広い範囲でものごとを見る上役への大事な報告でクルッとひっくり返される傾向にあります。 「なんで今コレを決めようとしている？あっちのプロジェクトの動きはちゃんと把握しているか？」 「あっちのプロジェクトで考えている全体基本方針は確認したか？お前のプロジェクトで検討している方向はその真逆だぞ」 そして炎上へ・・・ 参考: [議事録を会議前に書き終える？元MENSAの敏腕コンサルに学ぶ会議の極意](/meeting-preparation-and-design/) ## 計画時点での炎上確定を防ぐ3つのポイント つまるところ計画や段取りが悪いとプロジェクトは炎上一直線ってことです。 もちろん、先の見えづらい状況下での都度判断でも最適なルートを選んでプロジェクトをゴールに導く嗅覚を持つ稀有なリーダーがいるなら話は別です。 しかしぼくたちは凡人であって天才ではありません。だからこそ正しい手法を学び、スキルを磨くことで「秀才」を目指すべきでしょう。 プロジェクト計画についても、少なくとも立ち上げ時点での炎上確定を防ぐための最低限のレビューポイントが3つあります。 **合理性、実現性、経済性**です。 ### 合理性 合理性とは、プロジェクト計画を作業に分解したとき、**外の関係者を含めた作業間の依存関係が抜け漏れなく定義されているか？**という観点です。 ![全体アプローチ](https://media.work.naenote.net/2017/05/plan_1493690285-150x150.jpg) プロジェクト計画を作るときは、スケジュールを作る前にまず全体の流れ（アプローチ）を決めるものです。たとえば「AのあとにBをやる。並行してCをやり、Dの時点て合流する」といったもの。いわゆる作業の流れですね。 「作業の流れ」を定義する際、考えるべきは**各作業のインプットとアウトプットのつながり**です。作業には必ずインプットとアウトプットがあり、前段作業のアウトプットをもとに後段作業に着手するのが原則だからです。この原則がプロジェクト計画全体で守られている状態を「合理的である」「合理性が担保されている」と呼びます。 逆を言うと、前段作業のアウトプットがきちんと揃わない状態で後段作業を進めるのはとてもリスキー。ドラフト版を先出しでもらっても完成版でひっくり返った事例、ありましたよね。それと同じ憂き目にあう可能性があります。 つまり、 作業の流れがきちんと整理されていない ＝作業間のインプットとアウトプットのつながりに矛盾や抜け漏れがある ＝そもそものアプローチが合理的ではない ということです。 アプローチの時点で合理性を欠いている場合、それをスケジュールに落として実行しても早晩無理が生じて破綻します。全体計画が作業レベルに分解されていない「刺身」の場合はもちろん論外。 したがって、**このプロジェクト計画の全体の流れは合理的なのか？インプットとアウトプットの関係はプロジェクト外部を含めて漏れなく整理されているか？**という観点でレビューすることが、計画時点での炎上確定要素を1つ減らすポイントといえます。 アプローチはプロジェクト計画の要。最終成果までどのようなステップを踏んで進むのか、少なくとも最終成果物レベルのリストとフロー、依存関係は計画時点で整理し切りたいところです。 ### 実現性 実現性とは、**定義した作業の流れ（アプローチ）を具体的な時間軸に落としたとき、本当に実行できるのか？**という観点です。 ![私達ならできるさ！](https://media.work.naenote.net/2017/05/can_do_1494252101.jpg) 実行できないプロジェクトや計画は単なる絵空事でしかありません。「CAN DO（やればできる！）」の精神は大事ですが、本当に実行・完遂できることが検証されてはじめてプロジェクト計画は計画として成り立つんです。 検証の観点は2つあります。**環境**と**人材**です。 **環境**とは、プロジェクトを取り巻くヒト・モノが、プロジェクトが実行できる状態になっているかを検証する観点です。たとえば先ほどの事例に出てきた「プロジェクト開始日なのに作業場所がない」はモノ、「キックオフで関係者の足並みが揃えられなかった」はヒトが揃っていない状態といえます。 アプローチと作業の組み立ては完璧でも、人が動くための環境づくりできていなければチームは開店休業に陥り、プロジェクトの予算と期間が無駄に食われていくことになります。少なくとも向こう2ヶ月くらいまでは各作業を着手・実行するためにどのような環境が揃っている必要があるか、計画時点で明らかにしておくと良いでしょう。 次に**人材**とは、プロジェクトチームのメンバー構成は必要十分かを検証する観点です。ここでいう「必要十分」とは、スキルが揃っていること、頭数が足りていること（工数が捻出できること）、そして作業計画を人員計画に落とした際に期間毎の工数分布が平坦になっていることの3点です。スキルと頭数については言うまでもなし、工数分布については「山と谷が激しい」アンチパターンの通りです。 とはいえ、計画時点で精緻な工数見積を出すのは難しい場合もあると思います。そのときはたとえば2週間単位くらいの区切りで超ざっくり見積った工数を積み上げてみて、「この粒度で考えた時点で無理はなさそうか？」の検算をすると良いでしょう。またプロジェクト外の関係者の参画が必要な場合、週あたり何日・何時間くらいこちらに割いてほしいのか見通しを立てたうえで早めに調整に走ると良いでしょう。 仕事は人が動かすものです。仕事をきちんと終わらせるには、必要な人材が足りており、かつ作業を実行できる環境を最後まで維持し続けなければなりません。いずれかの点で明らかな無理（ノックアウト条件）がある場合、その計画は「無理スジ」ということになります。 つまり、**環境と人材の観点から実現性は担保されているか？もし欠けている場合、必要な露払い（前提事項）は明確か？**という観点でレビューするのは「計画倒れ」や「計画時点の炎上確定」を防ぐ良い手立てになります。 ### 経済性 経済性とは、**プロジェクト完遂に必要なヒトやモノにかかるカネがプロジェクトの予算内に収まるか？**という観点です。 ![時は金なり](https://media.work.naenote.net/2017/05/money_1494341479.jpg) 身も蓋もない話ですが、先立つもの（カネ）がなければなにもできません。計画の中身は合理的、かつ実現性を担保する人員計画（ヒト）や必要な環境（モノ）がわかったとしても、かかるカネが予算をはるかに超えているならそのプロジェクト計画は破綻していると言えます。 たとえば5000万円しかかけられないプロジェクトに必要なカネを見積もったら1億円かかる計算になったとします。どう考えても予算オーバーですよね。 そこで5000万円にどうにかおさめるように計画自体を調整することになります。たとえば 1. 工数削減の余地はないか（無駄な中間成果物を作らないようアプローチを組み替える、連携効率化のためチーム編成を見直す等） 2. 人材の単価削減の余地はないか（オフショア人材を活用する等） 3. 調達する製品・サービスをより安価なもので代替できないか（シェアドサービスやオープンソースソフトウェアを活用する等） 4. そもそものプロジェクトのゴールについて、質的・量的観点で妥協できる余地はないか 5. 予算の増枠は可能か といった順番で検討していくのがオーソドックスな方法です。合理性と実現性を守った状態でコスト圧縮の余地を探り、どうしてもダメならおかわりをお願いする、ということですね。 もちろんアプローチのレベルでひっくり返ったらまた作業計画、人員計画、前提整理その他すべて作り直す必要があるので、この順番での検討は「正しいけど大変」です。とはいえ、プロジェクトがきちんと立ち上がって完遂できるためには必要な産みの痛みとも言えます。 しかし「予算の枠内におさめる」という誘惑はそれはそれは強いものでして、この「痛み」そのものを面倒くさがってズルをしている場合があります。かかるカネを予算枠内におさめることが目的化した「数字遊び」に陥っているプロジェクト計画です。 ありえないレベルの極端な例ですが、たとえば「1人月10万円で国内ベンダーの人材を調達する（相場は1人月100万円）」のような、どう考えても実現不可能な前提を置いて数字を作りに行っている、ですとか。経済性を重視するあまり実現性が失われてしまっています。 こういった前提がきちんと書かれている計画ならまだマシな方で、責任者レベルが「とりあえずトータル5000万円に書き換えたから（人員計画？下がどうにかするだろ）」的な無茶ぶりをやらかしている場合すらあります。 つまりはパッと見て経済性が確保されている＝コストが予算の枠内にきれいにおさまっているプロジェクト計画でも、**実は無理な前提に基づいているのではないか？そもそもカネの算出根拠は？**という観点でレビューするとボロが出てくる可能性があります。 合理性と実現性に裏打ちされない経済性こそブラック系炎上プロジェクトの産みの親だということですね。 ##  もし炎上確定なプロジェクト計画を目の当たりにしたら 合理性、実現性、経済性。3つの観点からプロジェクト計画を眺めたときこれヤバいと感じたらどうすればいいのか？ もし今あなたのいるプロジェクトの計画がそのたぐいだったら、いち早く課題としてエスカレーションを上げてください。アラートは早ければ早いほうがいいです。今まさに計画そのものの是正に向けて動かないと、2ヶ月後3ヶ月後の自分が残業の嵐に見舞われることになります。あなたが計画を作る立場だった場合はなおのことです。 もしあなたが関わっていないプロジェクトでそのような計画を見かけた場合、遠巻きでもいいのでそのプロジェクトのオーナーにその「気づき」を伝えてください。自分には関係ないと思われるかもしれませんが、ぼくのこれまでの経験上、負のオーラを醸し出すプロジェクトは回りまわって自分のところにも影響を及ぼしてきます（主に人材面で）。 最後にもしすでに炎上中だということであれば、もう割り切って自分を守りにいってください。あなたには仕事以外で果たすべき人生があるはずですから・・・ ## まとめ：合理性、実現性、経済性の3点レビューで計画時点での炎上確定を防ごう というわけで、「こんなプロジェクト計画は嫌だ！」というお話を肴に、計画時点での炎上確定を防ぐために最低限必要なレビュー観点である「合理性、実現性、経済性」についてご紹介しました。 計画の顔したただのイメージ画像、前提の不明確な砂上の楼閣、自己満プロジェクト、非現実的な人繰り・・・ 実現できる見込みのない計画に翻弄されないよう、そして計画として最低限のレベルは割り込まないよう、注意していきたいものです。 ちなみに、いくら計画が完璧でもすべての炎上を防げるわけではありません。実行時点でなにが起こるかは誰にもわからないからです。 計画の巧拙は炎上防止のために重要なポイントですが、実行時点であがってくる想定外のリスクや課題をいかに上手にいなすかも同じくらい重要であることを付記しておきたいと思います。 すべての管理職に幸あれ！ --- ### AI Agent Context & Resources - **Author**: NAE - **Source**: https://work.naenote.net/planning-basics/ - **Related Resource**: [「無難難題」](https://amzn.to/2AKCFNP) - **Contact/Inquiry**: https://x.com/naework