失敗の原因を、個人ではなく進め方の構造から捉える
新規事業がうまくいかなかった理由を振り返ると、「アイデアが悪かった」「担当者の力が足りなかった」という説明になることがあります。しかし実務の構造から見ると、原因は次の四つに整理できます。
- 顧客が不在のまま検討が進む
- 確かめる前に作り込む
- 判断の基準がないまま始める
- 兼務の体制で止まる
この記事では、新規事業の失敗率のような統計値は扱いません。出典や定義が確認できない数字は、自社の判断の助けにならないためです。代わりに、自社の案件がどのパターンに近いかを点検できるよう、それぞれの起こり方と備え方を具体的に書きます。
前提として、新規事業では仮説が外れること自体は避けられません。問題になるのは、外れたことに気づくのが遅れ、費用と時間を使い切ってから判明することです。以下のパターンは、いずれも「気づくのが遅れる構造」です。
パターン1：顧客が不在のまま進む
社内の会議と資料だけで検討が進み、顧客候補と一度も話さないまま事業計画ができあがる形です。市場の資料や社内の意見は集まっているため、検討が進んでいるように見えます。
点検の問いは三つです。
- 具体的な顧客候補の名前（個人名や部署名）を挙げられるか
- その人が直近で、この課題にどう対処したかを知っているか
- その情報は、本人から直接聞いたものか
答えられない場合は、計画を精緻にする前に、顧客候補と話す予定を入れます。想定を確かめられる形に直す方法は、「困っているはず」を課題仮説に変えるで扱っています。
パターン2：確かめる前に作り込む
課題や支払いの意思が確認できていない段階で、本格的なシステムやサービスを開発してしまう形です。作ること自体は進捗が見えやすく、社内にも説明しやすいため、起こりやすい構造です。
完成してから顧客に見せ、使われないと分かった時点では、すでに開発の費用を使い終えています。さらに、作ったものへの愛着や社内への説明責任から、方向を変える判断もしにくくなります。
備えは、作る前に「これは何を確かめるためのものか」を一文で書き、より安い手段で同じ問いに答えられないかを検討することです。インタビュー、紙の試作、検証用のLP、手作業での代行などで答えが出るなら、開発は後に回せます。どの手段を選ぶかは、答えたい問いの種類と、顧客候補に接触できる方法で決めます。
パターン3：判断基準がないまま始める
PoCや試験販売を始めたものの、どんな結果なら進めるのか、どんな結果なら止めるのかを決めていない形です。結果が出てから基準を考えると、都合のよい解釈が可能になり、「もう少し様子を見る」が繰り返されます。
始める前に決めることは次のとおりです。
- 確かめたい問い
- 見る指標や事実
- 進める・方向を変える・止めるの目安
- 判断する日と、判断する人
基準は厳密でなくてかまいません。事前に書いてあること自体に意味があります。置き方はKPIと撤退基準を実験を始める前に置くが参考になります。
パターン4：兼務の体制で止まる
担当者全員が既存業務との兼務で、新規事業に割く時間が確保されていない形です。既存業務には期限と相手があるため、期限のない新規事業の作業は常に後回しになります。会議だけが定期的に開かれ、前回からの進捗がないまま数か月が過ぎます。
備えは、人数を増やすことよりも、次の三点です。
- 担当者のうち少なくとも一人について、使える時間を上長と合意する
- 会議で決めたことを短い決定記録として残し、次の行動と期限を書く
- 時間が確保できない期間は、外部に作業を任せるか、案件を一時停止すると明示する
「止まっている」と明言できないまま続いている状態は、費用と時間が見えないまま出ていく状態です。
失敗の責任と「その後」は、始める前に設計する
失敗の責任や、その後の扱いについて調べている方の関心は、うまくいかなかった場合に担当者がどう扱われるのか、という点にあるかもしれません。これは個別の会社の人事制度によるため一般論は言えませんが、設計の考え方は示せます。
まず、責任を「結果」と「進め方」に分けます。仮説が外れたという結果は、担当者の責任にしても防げません。一方、顧客に確かめたか、基準を決めてから始めたか、記録を残したかという進め方は、担当者が責任を持てる範囲です。評価をこの進め方の側に置くと、早い段階で「この仮説は外れた」と報告することが不利になりません。詳しくは担当者の評価を段階に合う行動と学びで設計するをご覧ください。
次に、撤退の条件と手順を事前に決めます。止める条件、決める人、顧客や取引先への対応、得られた知見の保管、担当者の次の配置です。撤退を後始末ではなく一つの計画として扱う方法は、撤退を顧客と資産を守るプロジェクトにするで述べています。雇用や契約に関わる判断は個別の事情によるため、必要に応じて専門家に確認してください。
よくある質問
Q. すでに開発を進めてしまっています。いまからできることはありますか。
あります。開発を止める必要はなく、並行して顧客候補に途中の状態を見せ、直近の行動と反応を確認します。そのうえで、未着手の機能のうち検証に必要のないものを後回しにします。残りの予算で何を確かめるかを決め直すことが先です。
Q. 失敗のパターンに当てはまっているか、社内でどう点検すればよいですか。
各パターンの点検の問いを、担当者と決裁者が別々に答え、結果を見比べる方法が有効です。答えが食い違う箇所が、認識のずれている箇所です。責める場にしないために、点検の目的は次の行動を決めることだと先に伝えます。
Q. 経営陣が撤退基準を決めたがらない場合はどうすればよいですか。
「撤退」という言葉を避け、「次の投資を判断する条件」として提案すると合意しやすくなります。期限と、その時点で確認する事実を決めるだけでも、判断の先送りは防げます。
Otsumuに相談できること
Otsumuは、新規事業開発コンサルティング、AIを活用したMVPシステム開発、自社サービス運用の自動化コンサルティングを、戦略と開発を分断せず、ひとつのチームで支援しています。
進行中の案件を点検したい場合は、新規事業レビュー Sprintが対応します。48万円（税別・参考価格）、1〜2週間で、市場・競合の論点整理、顧客と課題の仮説シート、収益モデルの整理、優先する検証項目と判断基準、PoCの計画案、経営会議・社内稟議用の説明資料をまとめます。大規模な市場調査、顧客インタビューの実施、システム開発は別途見積もりで、正式な見積もりは相談後にお出しします。
この記事の点検の問いに社内で答えられ、次の行動が決まるなら、外部への相談は不要です。第三者の目で整理したい場合は、5つの質問で現在地をチェックできる診断（回答は送信・保存されません）や、30分の無料診断をご利用ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。記載の価格はOtsumuの税別・参考価格で、正式なお見積もりはご相談後にご案内します。法務・税務・会計・補助金などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.09.21