プロジェクトの失敗はなぜ起きるか｜よくある原因と、計画の段階で気づくしるし
プロジェクトの失敗はなぜ起きるのか。よくある原因は計画の段階で仕込まれます。憲章・見積書・WBS・体制図のどの欄を見れば失敗のしるしに気づけるか、見つけたときの伝え方と、着手前に決める見直しの条件を解説します。
この記事でわかること
- プロジェクトの失敗は、予定から外れる、成果が出ない、止められないの3種類。後の2つは計画の段階でしか防げない
- 失敗の原因の多くは計画の段階で仕込まれ、憲章・見積書・WBS・体制図の空いた欄や根拠のない数字に先に出る
- しるしを見つけたら、直してほしい欄と選択肢を文面で出し、見直しの条件と決める人を着手前に書いておく
どろん先輩
PM・企画職専門の転職エージェント「ネコノテキャリア」の中の人。オブラートに包まない物言いが持ち味で、相場も裏事情も聞かれれば正直に話す。少し口が悪い。
はじめ
事業会社の情報システム部門でPM2年目。上から降りてきた基幹システム更新の計画書を、来月の承認会議までに書く
目次
上から降りてきた案件の計画書を書いている。納期はもう決まっていて、体制図には兼務の名前が並ぶ。どこかおかしいと感じるのに、何がおかしいのかを言葉にできないまま、承認会議の日が近づいてくる。
この記事では、プロジェクトの失敗がなぜ起きるのかを、よくある原因と、計画の段階で気づけるしるしに分けて整理します。しるしを見つけたときに上の人へ何を持っていけばいいかは、PM専門の転職エージェントのどろん先輩に聞きました。
はじめ（基幹システム更新の計画書を書いている情報システム部門のPM2年目）
来月の承認会議までに、基幹システム更新の計画書を出すことになりました。前に同じ部署でやった更新は、半年遅れたうえに、結局ほとんど使われなかったと聞いていて。同じ失敗をしない計画にしたいんです。
どろん先輩（PM専門エージェント）
計画書を書いているいまが、いちばん手を打ちやすい時期です。プロジェクトの失敗は、途中で突然起きるように見えて、計画の書類にたいてい先に出ています。空いている欄や、根拠の書いていない数字としてね。
プロジェクトの失敗とは、着手前に決めた「終わった」と言える条件を満たせないこと
プロジェクトの失敗とは、着手前に決めた「終わった」と言える条件（納期・費用・品質と、何のためにやるかという目的）を満たせないことです。失敗は、予定から外れる、終わったのに成果が出ない、見込みがないのに止められない、の3種類に分けると、どこで防げるかが見えます。
予定から外れる納期に間に合わない、費用が膨らむ、品質が足りない
成果が出ない予定どおり終わったが、使われない、目的の数字が動かない
止められない見込みがなくなっても、誰も止めずに続く
はじめ
前の更新は、半年遅れたうえに使われなかったので、1つ目と2つ目の両方ですね。
どろん先輩
そうです。そして2つ目と3つ目は、進めている途中ではほとんど防げません。何のためにやるか、いつ何で測るか、誰が止めるかを決めずに始めると、途中で気づいても、比べる物差しがないんです。3種類のうち2つは、計画の段階でしか防げないと考えてください。
プロジェクトが失敗する原因の多くは、計画の段階で仕込まれる
プロジェクトが失敗する原因として多く挙げられるのは、見積もりの甘さ、成功の定義のあいまいさ、範囲の広がり、決める人のあいまいさで、どれも計画の段階で仕込まれます。進めている途中の報告や連絡の問題は、仕込まれた原因が表に出る経路と考えると、手を打つ場所を間違えません。
「プロジェクトの失敗」の検索上位10件を2026年11月に読むと、見積もりや計画の甘さは10件すべてが、目標や成功の定義のあいまいさは7件が原因に挙げていました。フラッグス社がITプロジェクトの経験者235名に聞いた調査（2026年1〜2月、インターネット調査）でも、炎上した・しかけた経験のある104名が挙げた原因の上位は、見積もりの甘さ（49.0%）、要件の追加・変更の頻発（45.2%）、成功の定義のあいまいさ（36.5%）でした。1社の調査で、回答者の偏りは確かめられていません。
| 原因 | 仕込まれる時期 | 計画の書類での現れ方 |
|---|---|---|
| 見積もりの甘さ | 計画（受注・予算取り） | 納期と金額が先に決まり、作業の量から出した日付がない |
| 成功の定義のあいまいさ | 立ち上げ | 目的が「効率化する」のような言葉だけで、何をいつ測るかがない |
| 範囲の広がり | 計画 | やらないことが書かれていない |
| 決める人のあいまいさ | 立ち上げ | 決める人の欄が部署名や会議体の名前になっている |
| 人の当て方の無理 | 計画 | 主要な人が兼務で、割ける時間が書かれていない |
ネコノテキャリアの転職の面談では、前の職場で失敗したプロジェクトの話になると、「計画の時点で無理だと思っていた」と話すPMが少なくありません（統計ではなく、面談で繰り返し聞く話です）。気づいていても、計画の承認の場で言い出せなかった、言っても通らなかった、という話が続きます。
はじめ
気づいていたのに言えなかった、は分かる気がします。納期は部長が経営会議で約束済みなので、僕が何か言っても変わらない気がして。
どろん先輩
納期そのものは変わらないかもしれません。でも、納期を守るために何を前提にするかは、計画書に書けます。前提を書かずに承認された計画は、遅れたときに、比べる記録が無いので「PMの頑張りが足りなかった」で片づけられかねない。前提を書いて承認された計画なら、遅れは「前提が崩れた」として、上の人が判断する話になります。
はじめ
前提というのは、たとえばどんなことを書くんですか。
どろん先輩
基幹システムの更新なら、移す過去のデータは何年分か、業務部門の担当者が週に何日テストに出られるか、連携先の仕様がいつまでに出るか、あたりです。どれも1つ崩れるだけで納期が動くのに、計画書に書かれないまま承認されることがあります。書いてあれば、崩れた日に「前提が変わったので、計画を見直します」と言えます。
計画の段階で気づく失敗のしるしは、書類の欄ごとに見る
計画の段階で気づく失敗のしるしは、プロジェクト憲章（企画書）・計画書・見積書・WBS・体制図の、決まった欄を見れば見つかります。どの欄も、空いているか、根拠が書かれていないかを確かめるだけで足ります。
プロジェクト憲章（企画書）
しるし「業務を効率化する」のような言葉だけで、何をいつ測るかがない
すること測る数字と測る日の案を2つ書き、決める人に選んでもらう
しるし部署名や「推進会議」のような会議体の名前しかない
すること範囲・納期・費用を変えるときに決める1人の名前を入れてもらう
計画書
しるし空欄
することやらないことの案を3つ書き、関係者に確かめる
しるし納期だけが先にあり、作業の量から出した日付がない
すること作業の量から出した日付を並べ、納期との差を書く
見積書
しるし前提がない、または「仕様の確定後に再見積もり」とだけある
すること前提を並べ、崩れたら見積もりを見直すと書く
WBS
しるし「要件定義」「設計」のような工程の名前のまま、2週間を超える行が並ぶ（編集部の目安）
すること1〜2週間で終わる単位まで分ける。分けられない行は、まだ中身が決まっていないしるし
体制図
しるし兼務の人が並び、何割の時間を割けるかが書いていない
すること割ける時間を本人と上長に確かめて書く
はじめ
うちの計画書だと、やらないことの欄は空いていますし、体制図も兼務ばかりです。WBSは、まだ「要件定義」「基本設計」の行しかありません。
どろん先輩
それなら、しるしは3つ出ています。ただ、慌てなくていい。どれも、いま書き足せば消せるしるしです。WBSは、WBSテンプレートの10列に合わせて、タスクごとに担当と期限を1行で書いてみてください。1〜2週間の単位に分けられない行が、まだ誰も中身を決めていない場所です。そこが、計画のいちばん弱いところです。
はじめ
分けられない行が残ったら、計画書に書けないということですか。
どろん先輩
逆です。分けられない行は、「ここは〇月〇日までに方式を決める。決まるまでは見積もりに幅がある」と書いて残す。分からないことを分からないと書いた計画なら、どこが崩れやすいかを全員が知ったまま進められます。決まっていないことがある程度たまってきたら、課題管理表に移して、誰がいつ決めるかを追いかけます。
検索上位10件のうち、計画の書類のどの欄を見ればいいかまで書いた記事はありませんでした。近いのは、ポンチ絵（概要の図）だけで承認された計画を「机上の空論」とする記事と、WBSに分けられない作業を「まだ分かっていない証拠」とする記事でした。
しるしを見つけたら、直してほしい欄と選択肢を文面で持っていく
しるしを見つけたら、「この計画は危ない」と口で伝えるのではなく、直してほしい欄と、直さない場合に起きることと、選べる手を文面にして、決める人に渡します。不安ではなく判断の材料として出すと、上の人は聞く理由ができます。
| 伝え方 | 起きやすいこと |
|---|---|
| 「この納期は厳しいと思います」 | 「何とかしてほしい」で終わり、計画は変わらない |
| 「作業の量から出すと完了は8月です。6月に間に合わせるには、範囲を減らす、人を足す、前提を変える、のどれかが要ります。承認会議でどれにするかを決めてください」 | 選ぶ話になり、選ばなかった場合も、その判断が記録に残る |
- 直してほしい欄（例: 見積書の前提条件、体制図の兼務の割合）
- 直さない場合に起きること（例: 作業の量から出した日付と納期の差）
- 選べる手を2〜3個（範囲を減らす、人を足す、納期を延ばす、前提を変える）
- いつまでに、誰に決めてほしいか
はじめ
部長に「範囲を減らすか、納期を延ばすか選んでください」と言うのは、正直こわいです。
どろん先輩
こわいのは、口で言うからです。1枚の紙にして、承認会議の資料に入れてしまえば、それは「計画書の一部」になります。選んでもらえなくてもかまいません。選択肢を出して決まらなかったことが記録に残れば、遅れたときに個人の責任にされにくくなります。はじめさんを守るのは、頑張りではなく、承認された紙です。
はじめ
全部の欄を直してもらうのは無理そうです。どれから出せばいいですか。
どろん先輩
目的と成功の基準、決める人、やらないこと、の順です。この3つは、あとから決め直すほど関係者が増えて決まりにくくなります。見積もりの前提やWBSの細かさは、進めながら直せる。最初の承認で押さえるのは、あとから直せないほうです。
失敗の判定と止め方は、着手前に決めておく
失敗を小さく済ませるには、「何が起きたら計画を見直すか、止めるか」の条件と、それを決める人と日を、着手前にプロジェクト憲章か計画書に書いておきます。条件が先にあれば、途中で状況が悪くなったときに、続けるかどうかを感情ではなく条件で話せます。憲章のどの欄に何を書くかは、プロジェクト憲章の書き方で記入例つきのテンプレートと一緒にまとめています。
| 見直しの条件の例（編集部の例） | 決める人 | 決める場 |
|---|---|---|
| 費用の見込みが、承認した予算を一定の割合で超えた | 決める人の欄に書いた1人 | 月の定例のあと、臨時の見直し会議 |
| 節目（要件の確定、受け入れテストの開始など）の日付が、承認した日から2週間以上ずれる見込みになった | 同上 | 同上 |
| 前提とした決定（方式、連携先の仕様）が、期限までにされなかった | 同上 | 同上 |
割合や週の数は、案件の大きさで変わります。予算の超過で見直す例としては、20%を超えたら打ち切りを検討するという置き方を挙げる記事もあります（クラウドログ）。数字の大きさより、条件と決める人を承認の前に書いておくことのほうが、効き目は大きいと編集部は見ています。
はじめ
着手前に「止める条件」を書くのは、縁起でもないと言われそうです。
どろん先輩
言われます。だから「止める条件」ではなく「見直す条件」と書いてください。見直した結果、範囲を減らして続けることもあるし、止めることもある。条件を決めずに始めた案件は、見込みがなくなってからも、やめる理由が見つからずに続きやすくなります。失敗の3種類の3つ目、止められない失敗は、こうして起きるんです。
どろん先輩
もし、もう進めている案件で遅れが取り戻せなくなっているなら、計画の書き直しではなく立て直しの段階です。その場合は、プロジェクト炎上の立て直し方に、最初の2週間でやることをまとめています。
参考データと出典
| データ | 内容 | 時点・条件 |
|---|---|---|
| フラッグス株式会社「プロジェクトマネジメントの実態調査」 | 炎上した・しかけた経験のある104名が挙げた原因: 見積もりの甘さ49.0%、要件の追加・変更の頻発45.2%、成功の定義のあいまいさ36.5%（複数回答） | 2026年1月21日〜2月3日、全国のITプロジェクト経験者235名、インターネット調査。2026年4月30日発表。1社の調査で、回答者の偏りは確かめられていない |
| 「プロジェクトの失敗」の検索上位の記事 | 上位10件（本文を一部しか読めなかった記事を含む）が挙げていた原因・兆し・対策 | 2026年11月に編集部が確認 |
| クラウドログ「プロジェクトが失敗する原因とは？失敗例や成功のコツを解説」 | 予算の20%超過を打ち切りの検討の条件にする例 | 2026年11月に編集部が確認 |
| ネコノテキャリアの面談 | 失敗したプロジェクトについて「計画の時点で無理だと思っていた」と話すPMが少なくない | 面談で繰り返し聞く話。統計ではない |
| 書類の欄ごとのしるし、見直しの条件の例 | WBSの行の細かさ（2週間）、節目のずれ（2週間）など | 編集部の目安。統計ではない |
よくある質問
プロジェクト失敗の原因で多いものは何ですか？
見積もりの甘さ、成功の定義のあいまいさ、範囲の広がり、決める人のあいまいさがよく挙げられます。どれも計画の段階で仕込まれる原因で、進めている途中の報告や連絡の問題は、それが表に出る経路にあたります。
プロジェクトの失敗とは、どんな状態を指しますか？
着手前に決めた「終わった」と言える条件（納期・費用・品質と目的）を満たせない状態です。予定から外れる、終わったのに成果が出ない、見込みがないのに止められない、の3種類に分けられ、後の2つは計画の段階でしか防げません。
計画の段階で失敗に気づくには、何を見ればいいですか？
プロジェクト憲章の目的と成功の基準・決める人、計画書のやらないこと、見積書の前提条件、WBSのタスクの細かさ、体制図の兼務、スケジュールの納期の根拠を見ます。空いているか、根拠が書かれていない欄が、失敗のしるしです。
失敗しそうだと気づいたら、上司にどう伝えればいいですか？
直してほしい欄、直さない場合に起きること、選べる手を2〜3個、いつまでに誰に決めてほしいかを1枚の文面にして、承認会議の資料に入れます。選ばれなくても、選択肢を出したことが記録に残ります。
この記事は、PM・PdM・企画職専門の転職支援「ネコノテキャリア」と業務委託の案件紹介「ネコノテエキスパート」を運営する株式会社スナネコが、実務知見に基づいて制作しています。