野村（Nick）です。
皆さんの会社では、正式な見積りがないまま、プロジェクトの契約や承認が先へ進んでいないでしょうか。作る機能は書かれているのに、それを実現するために何人が必要で、どのくらいの期間と費用がかかるのか、誰も説明できないということはないでしょうか。
もう一つ、考えてみてください。そのプロダクトを作ることは決まっている。しかし、なぜ顧客がそれを選ぶのか、既存製品と何が違うのか、事業として本当に成立するのかという問いには、誰も答えられない。にもかかわらず、会議ではGoの判断が出てしまう。皆さんの周囲に、そのようなプロジェクトはないでしょうか。
さらに難しいのは、現場の誰かが「これは危ない」と気づいていても、プロジェクトを止める根拠がない場合です。すでに役員が承認し、関係会社との話が進み、社内でも人が動き始めている。直感的に危険だとわかっていても、「私がそう思うから」という理由だけで組織を止めることはできません。
これは、最近始まった問題ではありません。私は23年前、これらがすべて重なったプロジェクトに関わりました。その経験が、私がPMPを取得し、R.E.P.としてPMP試験対策を始めた理由の一つです。同時に、プロジェクトマネジメントだけでは足りないと知り、新規事業開発やプロダクトマネジメントの支援を続けてきた理由でもあります。
これは私の経歴を紹介するためだけの記事ではありません。作るものと、作るための仕事と、事業としての価値が切り離されたとき、何が起きるのか。そして、暴走し始めたプロジェクトを、組織としてどのように止めるのか。古い失敗事例を材料に、現在のプロジェクトを考えてみたいと思います。
2001年、スタートアップを辞めて独立した
2001年、私は取締役を務めていたスタートアップを辞め、独立しました。その会社では、私が最初のいくつかのサービスを立ち上げ、実際に顧客へ提供していました。企画だけではなく、サービスを作り、世の中へ出し、運営しながら改善するところまで担当していました。会社の人数は、最終的に50名ほどまで成長しました。
今でいうなら、私はプロダクトマネジメントに近い仕事をしていたのだと思います。しかし、当時の私は「プロダクトマネジメントをしている」とは考えていませんでした。必要なものを考え、作り、顧客に使ってもらい、その反応を見ながら直していく。目の前のことを一つずつ進めていただけです。
今思えば、早すぎたDXだった
独立後、ある伝統的な日本企業で、新しい製品を次々にリリースするための子会社が立ち上がりました。私は、その会社に支援という形で参加しました。既存の大きな企業の中に新しい仕組みを作り、従来とは異なる発想で製品やサービスを企画し、世の中へ出していく仕事でした。
今思えば、あれは早すぎたDXでした。当時はまだAgileという言葉も一般的ではなく、基本的にはウォーターフォールでプロダクトを作っていました。今と比べれば、開発速度はかなり低速です。それでも顧客訪問を繰り返し、必要な機能を確認しながら、機能を絞った小さなプロダクトをリリースしていました。
MVPという言葉も、少なくとも私たちの周囲では使われていませんでした。しかし、いきなり大きなものを作るのではなく、機能を限定して世の中へ出し、顧客の反応を見るという考え方はありました。後から名前が付いた方法を、当時なりのやり方で実践していたのだと思います。
その仕事の中で、私は小さな失敗と、大きな失敗の両方に関わりました。ここでは、大きな失敗のほうをお話しします。
30億円かかりそうなものを、一桁小さく見積もっていた
あまり詳しくは書けませんが、あるソフトウェアを、今でいうクラウドサービスのような形で提供しようという計画がありました。私の感覚では、まともに作れば30億円ほどかかる話でした。ところが、決裁者たちは一桁小さい金額を想定していました。最初にその数字を見たときは、率直に「えっ？」と思いました。
PMBOKガイドの言葉で説明すると、スコープは一見、正しく設定されていました。何を作るのかは、それなりに書かれていたのです。しかし、そのスコープを実現するために、何人が、どの程度の期間、何をしなければならないのか。人的資源の見積りが極めて雑でした。
雑というより、見積りが書面としてどこにも存在していませんでした。さらに、開発を担う予定だったパートナー企業から、正式な見積りがまったく出てこない状況でした。見積金額がわからないまま、契約だけが先へ進もうとしていたのです。
初めて、PMBOKガイドを実務で使った
文字として残すことが難しい部分は飛ばします。最終的には、複数の会社へ正式な見積作成を依頼することになりました。見積りにも相当な作業が必要だったため、その作成費用は発注者側が負担しました。
そのときのRFPを書いたのが、私です。これが、私がPMBOKガイドを実務で利用した最初の仕事ではないかと思います。何を作るのか、何を見積りに含めるのか、どのような前提条件があり、どこにリスクがあるのか。曖昧な話を、複数の会社が見積可能な形へ変えていきました。
止めるために、アクセルを踏む
実際、この仕事では「アクセルを踏みながら、ブレーキも踏む」ことが求められました。内心、私は「今すぐやめたほうがよい」と思っていました。しかし、個人の感覚だけで経営を納得させることはできません。すでに動き始めていたプロジェクトを止めるには、客観的な材料と、誰もが納得できる手続きが必要でした。
そこで一度アクセルを踏み、複数の会社へ正式な見積作成を依頼しました。見積りを見た後で都合よく条件を変えるのではなく、事前に評価基準を作り、それに沿って比較しました。RFPを作り、有償で見積りを依頼することは、外から見ればプロジェクトを前へ進める行為です。しかし実際には、経営が納得できる形でブレーキをかけるための準備でもありました。
見積作成の依頼だけでも、かなりの金額がかかっていたと思います。それでも、本体の開発へ進めば、数十億円規模の損失が発生する可能性がありました。結果として、数十億円になり得た損失を、極めて小さな段階で止めることができました。
各社から提出された見積りは、スコープをかなり削った場合でも約25億円、想定されるリスクをすべて織り込んだ場合は100億円を超えるものでした。一方、肝心のパートナー企業からは、期日になっても見積りが出てきませんでした。経営は、さすがにプロジェクトを停止する判断をしました。NOGOです。
プロジェクトを止めることは、何もしないことではありません。止めるための根拠を作るところまで、慎重に前へ進めなければならないことがあります。プロジェクトマネジメントは、アクセルを踏むためだけの技術ではなく、適切な場所でブレーキをかけるための技術でもあります。
作ることはできても、勝てないプロダクトだった
この話には、プロジェクトマネジメントだけでは説明できない問題もありました。そのソフトウェアの市場は、すでに大手数社によって完全に支配されていました。しかも、各社のソフトウェアが提供している機能には大きな差がありませんでした。すでにコモディティ化していたのです。
後から市場へ参入する側に残された数少ない可能性は、圧倒的に安く作り、安く提供することでした。ところが、正式に見積りを取ってみると、安くは作れないことがわかりました。既存の大手企業と比べて機能上の差がなく、開発費も安くならない。それでは、このプロダクトを作る理由がありません。
プロジェクトとして実行可能かどうかを調べた結果、プロダクトとしても勝てないことが明確になりました。プロジェクトを計画どおりに進める能力があったとしても、事業として成立しないものを完成させては意味がありません。
一見正しいスコープを、誰も自分事として捉えていなかった
プロジェクトを停止した後、振り返りにもPMBOKガイドを使いました。ガイドの視点で一つずつ確認していくと、スコープは一見、正しく書かれていました。しかし、ここでいう「正しい」とは、作ろうとしているソフトウェアの機能が、それなりに列挙されていたという意味にすぎません。
PMBOKガイドでは、プロダクトスコープとプロジェクトスコープを分けて考えます。プロダクトスコープは、作る製品やサービスが備えるべき機能や特性です。一方、プロジェクトスコープは、その製品やサービスを実現するために必要な作業の全体を指します。
たとえば、「このような機能を持つクラウド型のサービスを提供する」というのは、主にプロダクトスコープの話です。しかし、それを実現するためには、設計、開発、テスト、インフラ構築、セキュリティ対策、データ移行、運用設計、顧客サポートなど、膨大な作業が必要になります。既存システムとの連携、障害発生時の対応、サービス開始後の保守まで考えれば、必要な人員、期間、費用はさらに増えます。
今回のケースでは、作りたいソフトウェアの機能は書かれていました。しかし、それを実現するために必要な作業が十分に分解されておらず、誰が担当するのか、何人必要なのか、どの程度の期間がかかるのかも明確ではありませんでした。プロダクトスコープらしきものは存在していましたが、そこからプロジェクトスコープが導き出されていなかったのです。
さらに問題だったのは、書かれていたプロダクトスコープについても、誰も自分事として引き受けていなかったことです。機能の一覧はあっても、なぜその機能が必要なのか、それによって既存製品とどのような差が生まれるのか、顧客が本当に選ぶ理由になるのかという議論が不足していました。市場ですでにコモディティ化しているソフトウェアを、ほぼ同じ機能で提供しようとしていたのです。
つまり、プロダクトスコープは「何を作るか」という書類にはなっていましたが、「なぜ作るのか」という事業上の判断には結びついていませんでした。プロジェクトスコープも、「それを作るために何をしなければならないか」という実行可能な計画に変換されていませんでした。
役員も、その規模やリスクに実感を持てないままGoを出してしまいました。スコープが書かれていることと、スコープを理解していることは違います。承認されたことと、実行可能であることも違います。そして、実行可能であることと、事業として成功することも違います。
スコープマネジメントは、単に「どこまで作るか」を線引きする作業ではありません。作るものと、それを作るための仕事を結びつけ、必要な人、時間、費用、リスクを、関係者が現実のものとして理解できる状態にすることです。このケースでは、その接続が切れていました。
Agile以前の話だが、過去の話ではない
この出来事は、Agileという言葉がまだ一般的ではなかった時代の話です。私たちも顧客訪問を繰り返し、機能を絞った小さなプロダクトをリリースしていましたが、開発の基本はウォーターフォールでした。現在と比べれば、仮説を確認し、方向を変える速度はかなり低速でした。
ただし、ウォーターフォールそのものが悪いわけではありません。作るものが明確で、変更の必要性が低く、十分な見積りと計画があり、段階ごとに継続の妥当性を判断できるなら、ウォーターフォールが適した仕事もあります。問題は、最初に決めた前提を誰も検証せず、見積りも不十分なまま、後戻りできない規模まで進めてしまうことです。
もし現在、同じことを当時と変わらないウォーターフォールで行えば、さらに大きな悲劇になる可能性があります。市場も技術も顧客の期待も、23年前より速く変化します。数年かけて完成した頃には市場の前提が変わり、競合製品や代替サービスが登場し、生成AIのような技術によってコスト構造そのものが変わっているかもしれません。
要求を最初に固定し、完成するまで顧客に見せず、途中で事業性を再評価する機会もない。その状態で大規模な投資を続ければ、「計画どおり完成したが、誰も必要としていない」という結果になりかねません。プロジェクトとしては完了していても、プロダクトとしては失敗です。
一方で、Agileと呼んでいれば安全になるわけでもありません。誰がプロダクトの価値に責任を持つのかが曖昧で、顧客から得た情報が意思決定に反映されず、止める基準も存在しないのであれば、短い単位で同じ失敗を繰り返すだけです。重要なのは方法論の名前ではなく、仮説を確認し、見積りを更新し、継続する価値があるかを判断する仕組みがあることです。
プロジェクトマネジメントだけでも、プロダクトマネジメントだけでも足りない
この出来事には、現代でも通用する失敗がいくつも含まれています。見積りがないまま契約を進める。書類上のスコープだけを見て、必要な人的資源を考えない。市場ですでに差がつかなくなったプロダクトへ巨額の投資をしようとする。誰も全体像を自分事として引き受けないまま、意思決定だけが進んでいく。
これは、プロジェクトマネジメントの失敗であると同時に、プロダクトマネジメントの失敗でもありました。優れたプロジェクトマネジメントで、作る価値のないプロダクトを予定どおり完成させても意味がありません。反対に、どれほど魅力的なプロダクトの構想があっても、それを実現するプロジェクトが成立しなければ、世の中には出せません。
プロダクトマネジメントは「何を、なぜ作るのか」を扱います。プロジェクトマネジメントは、それを「どのように実現するのか」を扱います。実際の仕事では、この二つを完全に切り離すことはできません。
この経験から、PMPを取得した
この経験を通じて、私はプロジェクトを整理し、関係者の認識を揃え、意思決定に必要な情報を作るための共通言語が必要だと考えるようになりました。そこでPMPを取得しました。そして、取得後すぐにR.E.P.を申請し、PMP試験対策コースを始めました。R.E.P.制度が終了するまで、その活動を続けました。
私がPMBOKガイドを教え始めたのは、ガイドに書かれていることを暗記し、PMP試験に合格してもらうためだけではありません。プロジェクトが、とんでもない方向へ進み始める前に何を確認しなければならないのか。一見もっともらしい計画のどこに穴があるのか。Goを出す前に何がわかっていなければならないのか。そして、ときにはNOGOを判断するために、どのような情報が必要なのか。それを実際の失敗を通じて知ったからです。
一方で、PMBOKガイドを適切に使ったとしても、作るプロダクトそのものに価値がなければ成功しません。だから私は、新規事業開発やサービス開発の伴走支援も続けてきました。顧客のところへ行き、話を聞き、仮説を作り、小さく試し、必要なら方向を変える。プロジェクトを正しく進めることと、正しいプロダクトを見つけることの両方が必要だからです。
皆さんのプロジェクトは、止められるでしょうか
ここまで読んで、現在関わっているプロジェクトを一つ思い浮かべてみてください。何を作るのかだけでなく、なぜ作るのかを説明できるでしょうか。それを実現するために必要な作業、人員、期間、費用が、現実的な数字として示されているでしょうか。
そのプロダクトが市場で選ばれる理由を、誰かが自分の言葉で説明できるでしょうか。最初に置いた前提が変わっていないかを、途中で確認する機会はあるでしょうか。そして、作り続ける価値がなくなったとき、経営がNOGOを判断するための基準は用意されているでしょうか。
Goを出せる組織はたくさんあります。しかし、十分な根拠をもってNOGOを出せる組織は、それほど多くありません。私が23年間、プロジェクトマネジメントとプロダクトマネジメントの両方に関わり続けているのは、作ることだけでなく、作らないこと、そして途中で止めることにも、専門的な支援が必要だと考えているからです。
なぜ23年間も続けているのか
23年間続けてきた理由は、プロジェクトマネジメントにも、プロダクトマネジメントにも、単独では埋められない穴があると知っているからです。どちらか一方だけでは、プロジェクトは予定どおり終わったのに事業として失敗する、あるいは魅力的なアイデアがあるのに実現できない、ということが起こります。
私は、プロジェクトを予定どおり進めることだけを支援したいのではありません。作る価値のあるものを見つけ、それを実現できる形へ変え、必要であれば途中で止める。その一連の意思決定に関わりたいのです。
プロジェクトを始めることだけが成果ではありません。プロジェクトを完成させることだけが成功でもありません。十分な情報を集め、数十億円の損失になる前にNOGOを判断できたのであれば、それも明確な成果です。
私がプロジェクトマネジメントとプロダクトマネジメントを続けているのは、両方を知ることで、初めて守れるものと作れるものがあると考えているからです。
関連ページ
- 講師紹介――野村隆昌（Nick Nomura）
- 会社概要――有限会社システムマネジメントアンドコントロール
- PMP試験対策2026――3つの受講方法とコース案内
- プロジェクトとプロダクトマネジメントの実務家が教える試験対策
- 法人向けのトレーニングと伴走支援
編集注
本記事は筆者自身の経験と記憶をもとにしています。関係する企業、製品、担当者を特定できないよう、一部の情報を省略しています。金額は当時の見積りに関する概数です。
PMP、PMBOKは、Project Management Institute, Inc.（PMI）の登録商標です。