新規事業のシステム開発が失敗する原因と、開発前に置くべき判断基準

2026年9月18日

この記事でわかること

新規事業のシステム開発は、どこで失敗しているのか
開発に進む前にそろえるべき4段階の証拠
実例：新しい顧客層を2週間で検証したら、判定は層ごとに割れた
【判定表】開発に進む・絞る・止めるを決める基準
検証手段の比較：内製・調査会社・広告代理店・開発会社・何もしない

新規事業のシステム開発の失敗は、開発の工程よりも前の段階で決まることが多くあります。調査でも、失敗の原因の上位には社内調整や見積もりの甘さ、市場ニーズの読み違えが並びました。数百万円から数千万円を発注する前に、需要の証拠を段階ごとに確かめ、着手と撤退の基準を先に決めておけば、失敗の規模は抑えられます。

この記事では、次の3つの問いに答えます。

問い	結論
なぜ失敗するのか	開発の進め方より前、企画と計画の段階の要因が上位を占める
開発前に何を確かめるか	課題→需要→商談→成約の4段階のうち、どこまで証拠があるか
どう判断し、どう止めるか	「GO／条件付きGO／NO／判断不能」の4択で、基準を検証の前に決める

公開されている調査と、実際に広告を配信して需要を検証した案件のデータをもとに整理しました。判定表と社内報告用のテンプレートは、あなたの案件にそのまま当てはめて使える形にしています。

新規事業のシステム開発は、どこで失敗しているのか

新規事業のシステム開発の失敗には、プロジェクトの中止に至るものから、予算やスケジュールがずれるものまで幅があります。ここでは公開されている2つの調査をもとに、失敗の中身と原因、そして途中で止まらない理由を整理します。

失敗の中身は「中止」だけではない

Engineerforceは2025年11月、新規事業で失敗を経験した担当者111名に調査を行いました。対象は従業員500名以上の企業で、過去3年以内に失敗を経験した人です。最も当てはまる失敗の種類を聞いた結果は、次のとおりです。

予算が大幅に超過した：33.3%
スケジュールが大幅に遅延した：30.6%
プロジェクトが中止・凍結になった：22.5%
ローンチ後に早期撤退した：9.0%
想定していたKPIを大幅に下回った：4.5%

出典：株式会社Engineerforce「新規事業担当者の失敗本音調査」（PR TIMES、2025年12月8日）https://prtimes.jp/main/html/rd/p/000000081.000068877.html ／ Engineerforce https://engineerforce.io/

中止や撤退よりも、予算とスケジュールのずれを失敗として挙げた人のほうが多い結果です。また、当初予算が1,000万円以上だった案件が76.5%を占めており、1件あたりの損失は小さくありません。ただし対象は大企業の担当者に限られるため、中小企業やスタートアップにそのまま当てはめることはできません。

なお、「システム開発の7割が失敗する」という数字を目にすることがありますが、割合は失敗の定義によって大きく変わります。JUASの「企業IT動向調査2025」では、100人月未満のプロジェクトで工期が「予定どおり完了」したのは31.0%でした。一方で「ある程度は予定どおり完了」を加えると、83.4%になります。社内資料で数字を使う場合は、定義も一緒に示しておくと誤解を避けられます。

出典：一般社団法人日本情報システム・ユーザー協会（JUAS）「企業IT動向調査2025（2024年度調査）」報告発表資料 https://juas.or.jp/cms/media/2025/04/JUAS_IT2025summary.pdf

原因の上位は、開発工程より前にある

先ほどの調査で、失敗の主な原因を3つまで選んでもらった結果、上位は次の4つでした。

社内の関係部門との調整がうまくいかなかった：36.9%
競合分析が甘く、差別化できなかった：35.1%
予算や工数の見積もりが甘かった：35.1%
市場ニーズを読み違えた：31.5%

一方で、要件定義が曖昧で仕様変更が頻発したという回答は18.9%、開発パートナーの選定を誤ったという回答は18.0%でした。プロジェクトマネジメントの失敗は4.5%にとどまっています。開発会社の選び方や進行管理に目が向きがちですが、担当者の実感としては、企画や計画の段階の問題のほうが上位に来ていることになります。

社内調整は企画から開発中まで続く問題ですが、競合分析、見積もり、市場ニーズの3つは、開発を発注する前に手を打てる領域です。発注後の管理を整えても、この前提が崩れていれば、完成したシステムが使われないか、予算内で作りきれない結果になりやすいと考えています。

違和感に気づいても、プロジェクトは止まらない

同じ調査で注目したいのは、失敗に気づいたタイミングです。「企画・構想段階で違和感があった」が9.0%、「要件定義・設計段階で問題が見えてきた」が24.3%でした。合わせて約3人に1人が、開発に入る前に問題を感じていたことになります。それでもプロジェクトは開発へ進み、失敗として確定しています。

止まらなかった理由を調査は直接聞いていませんが、周辺の回答から2つの事情がうかがえます。1つは、止める基準が事前に置かれていなかった可能性です。やり直すなら最初に撤退基準を設定すると答えた人が20.7%おり、一部の案件では当初その基準がなかったと考えられます。もう1つは、止めることが担当者の不利益になりやすい環境です。失敗後に「メンバーの責任が問われた」は28.8%、「経営層からの叱責があった」は22.5%でした。

違和感を持つ担当者がいても、それを止める判断に変える基準がなければ、プロジェクトは計画どおりに進み続けます。次のセクションでは、開発に進む前に何を確かめておくべきかを、証拠の段階に分けて見ていきます。

開発に進む前にそろえるべき4段階の証拠

開発に進んでよいかを判断するには、「需要がありそう」という感触ではなく、段階ごとの証拠がどこまでそろっているかを確認する必要があります。ここでは証拠を4つの段階に分け、それぞれで何が分かるのかを整理します。

証拠は「課題→需要→商談→成約」の順に強くなる

新規事業の需要を示す証拠は、相手が負うコストが大きい行動ほど強くなります。話を聞いてもらうより問い合わせをしてもらうほうが、問い合わせより商談に時間を割いてもらうほうが、相手の本気度を示すためです。4つの段階を整理すると、次のようになります。

段階	確認できること	主な確認手段	この段階だけでは分からないこと
1. 課題	想定した困りごとが実在するか	見込み客へのヒアリング、既存顧客の声	お金を払ってでも解決したいか
2. 需要	解決策を自ら探している人がいるか	検索広告とLPへの反応、問い合わせ・資料請求	検討の本気度、発注の権限があるか
3. 商談	具体的な条件で検討する相手がいるか	商談の実施、見積もりや提案の依頼	価格や条件が折り合うか
4. 成約	実際に対価を払う相手がいるか	受注、有償での試験導入、先行予約	継続して使われるか、採算が合うか

ヒアリングで「あれば使いたい」と言われることは、段階1の証拠にはなりますが、段階4の証拠にはなりません。開発費が大きい案件ほど、段階3から4に近い証拠を持ってから着手するのが安全です。反対に、段階1の証拠だけで数千万円の開発を発注している場合は、次の検討に進む前に証拠の不足を埋める余地があります。

問い合わせの件数だけでGOにしない

BtoBの新規事業では、成約から判断するのが原則です。検証期間内に成約まで観測できない場合に、商談、問い合わせ、クリックの順に指標を下りて判断します。問い合わせの件数は集めやすく目立つ数字ですが、その多くが商談に進まないことは珍しくありません。

たとえば、ある法人向けサービスで需要を検証した案件では、問い合わせ・資料請求が15件、そこから商談に進んだのが5件、成約は2件でした。問い合わせの件数だけを見ればGOと判断しやすい結果でしたが、商談に進んだのはそのうち3分の1です。件数が少ないためこの比率を目安にはできませんが、問い合わせの段階と成約の段階では、見えている需要の大きさが大きく異なることを示す例です。この案件の詳細は次のセクションで紹介します。

需要の検証が不要なケースもある

すべての開発案件で、需要の検証から始める必要はありません。次のような案件では、作ること自体はすでに決まっているため、需要の証拠を集めるより要件定義や開発会社の選定に時間を使うほうが合理的です。

法令や制度の改正に対応するためのシステム
利用者が社内に確定している業務システムの刷新
特定の顧客から契約を前提とした発注の意向を得ているシステム

ただし、社内向けに作ったシステムを後から外販する場合は、その時点で需要の検証が必要になります。特定の顧客向けに作った仕組みを、他社にも広げる場合も同様です。自社の案件がどちらに当たるかは、「作ったシステムを使う相手が、開発前に確定しているか」で判断するとよいでしょう。

実例：新しい顧客層を2週間で検証したら、判定は層ごとに割れた

ここで紹介するのは、システム開発の案件ではありません。既存サービスを新しい顧客層に広げられるかどうかを、2週間で検証した案件です。開発の前に、どこまでのことが分かるのかを示す例として取り上げます。

検証の条件：何が分かり、何が分からない設計だったか

対象は法人向けレンタル・サプライ業の事業者で、新しい顧客層に需要があるかを確かめる目的でした。検索広告とLPを用意し、2週間で10万円弱の広告費を使っています。キーワードは30語（完全一致15語、フレーズ一致15語）で、事業者側の仮説に沿って5つの層に分けました。

成果として数えたのは、フォームからの問い合わせと資料請求です。この設計で分かるのは、それぞれの層に需要があるかどうかと、どの訴求に反応があったかまでです。受注率や取引の継続率は、この時点では分かりません。

結果：反応した層、反応がなかった層、判断できない層

2週間の配信結果は、表示1,850回、クリック129回、問い合わせ・資料請求15件でした。クリック率は7.0%、クリックからの反応率は11.6%で、1件あたりの獲得単価は約6,600円です。層ごとに分けると、次のようになりました。

層	クリック	クリック率	反応	反応率
A（小規模・個人運営が多い事業者）	25	17.0%	5件	20.0%
B（同業のレンタル業者を探している層）	16	15.5%	2件	12.5%
C（大型の事業者）	8	6.5%	1件	12.5%
D（業種名での一般的な検索）	75	5.7%	7件	9.3%
E（隣接サービス名での検索）	5	3.2%	0件	—

明確に言えるのは、層Aのクリック率が他の層より高いことです。表示回数が十分にあるため、この差は偶然では説明できません。一方、層Aの反応率が高く見える点については、件数が少なく他の層との差を判定できません。層Eは0件でしたが、クリックが5回しかないため、需要がないと結論づけることもできない状態です。

この検証で得られた結論は、「層Aに絞って進める」「層Eは判断できないまま残る」という条件付きのものでした。層ごとに結果が割れることは珍しくないため、判定は事業全体でひとつに決めず、層単位で出すほうが実務では使えます。

自社の強みは、検索では一度も表示されなかった

この検証で事業者にとって想定外だったのは、強みとして掲げていた訴求の結果です。設備による品質チェック、管理技術、小ロット対応という3つの訴求で出稿した語句は、いずれも表示回数がゼロか、表示されてもクリックがゼロでした。

表示がゼロだったという事実は、件数の多さに関係なく断定できます。その言葉で検索している人が、期間中にいなかったということです。ここから言えるのは、強みを捨てるということではなく、置き場所を変えるということでした。強みは検索で出会うための言葉ではなく、出会ったあとに他社と比べてもらうための言葉として、LPの中で使うほうが機能します。

これは筆者の解釈ですが、開発でも同じことが起こると考えています。差別化のために作り込もうとしている機能が、顧客が最初に探す条件とは限りません。作る前にその順序を確かめておくと、優先して実装すべき機能の判断が変わります。

この案件で追えなかったこと

この検証は、需要の有無を判定する目的で設計しました。そのため、次の点は追える設計になっていません。

成約2件が、どの層から出たものか
取引額と、獲得にかけた費用が見合っているか
問い合わせから成約までにかかった日数

広告の配信と、その後の商談の管理は別の作業です。検証の段階から商談の記録まで設計しておくと、判断できる範囲はさらに広がります。自社で検証する場合は、この点を先に決めておくことをおすすめします。

【判定表】開発に進む・絞る・止めるを決める基準

検証の結果をどう読むかは、担当者の主観に委ねられがちです。ここでは、観測された状態から機械的に判定するための表と、自社の数字で基準値を逆算する手順を示します。そのまま社内資料に転記して使える形にしています。

観測された状態ごとの判定表

判定は、証拠の強い段階から順に見ます。成約が出ていればそこで判断し、出ていなければ商談、問い合わせ、クリック、表示の順に下ります。下の段の指標だけで判断すると、需要を過大に見積もることになります。

観測された状態	意味	次の行動	実案件の該当
成約が出た	最も強い需要の証拠。採算の判定に進める	取引額と粗利から、獲得にかけた費用が見合うかを確認する	全体で2件
商談にはなるが成約しない	需要はある。価格や条件、決裁の構造がずれている	失注理由を聞き取り、条件を組み直す	商談5件のうち3件
問い合わせはあるが商談にならない	関心はある。相手の層や検討段階がずれている	問い合わせ内容を分類し、対象の層を絞る	15件のうち10件
クリックはあるが問い合わせがない	LPや提案内容のずれ、または件数不足	クリックが数十件に満たなければ判断不能として扱う	層E（クリック5回）
表示はあるがクリックがない	探されてはいるが、訴求が刺さっていない	見出しと訴求の言葉を変えて再配信する	強み訴求の一部
表示がゼロ	その言葉で検索している人がいない	入口の言葉から外し、LPの中の訴求に回す	強み訴求の一部

この表で押さえておきたいのは、上の行ほど判定の材料として強いという順序です。問い合わせが多くても商談に進んでいなければ、判定は3行目にとどまります。右端の列は、前のセクションで紹介した1案件の結果を当てはめたものです。1件の事例なので、基準値ではなく読み方の例として見てください。

自社の数字で、許容できる獲得単価を逆算する

「問い合わせ1件あたりいくらまで許容できるか」は、他社の平均値からは決まりません。自社の取引額と成約率から逆算します。

問い合わせ1件あたりの許容単価＝ 1成約あたりに使ってよい獲得費 × （成約件数 ÷ 問い合わせ件数）

たとえば、1成約あたりに使ってよい獲得費を30万円、問い合わせからの成約率を10%と仮置きします。この場合、問い合わせ1件あたりの許容単価は3万円です（ここでの数字は計算例です）。1成約あたりに使ってよい獲得費は、初年度の粗利、または継続取引を見込むならその期間分の粗利から決めます。

成約率が分からない場合は、既存事業の数字を仮に置いて構いません。検証が終わった時点で実測値に置き換え、基準そのものを更新します。参考として、先ほどの実案件では問い合わせ15件から成約2件でしたが、1案件の結果なので目安の値としては使えません。

「判断不能」を正式な結論に入れる

判定の選択肢をGOとNOの二択にすると、結果が曖昧なときに社内の力学でGOに寄りやすくなります。判断できるだけの件数が集まらなかった場合は、判断不能という結論をそのまま出してください。

判断不能が出たときの選択肢は3つあります。対象を広げて追加で配信する、複数の層をまとめて件数を確保する、その層は今回の対象から外す、のいずれかです。あわせて、追加配信にかけてよい上限額も先に決めておくと、判断がつかないまま費用だけが伸びる事態を避けられます。

基準は検証の前に決め、あとから作らない

基準を検証の後に決めると、出た結果に合わせて基準のほうが動きます。判定表と許容単価は、配信を始める前に書き出しておいてください。決めておくのは、判定する指標、その基準値、判定する日、判定する人の4つです。判定する日は、暦の日付だけでなく「クリックが一定数に達した時点」という形でも構いません。短期間で件数が集まらなかった場合に、判断不能のまま期限だけが来る事態を防げます。

このうち見落とされやすいのが、判定する人です。事業の責任者だけが判定する形にすると、撤退の判断が自分の評価に直結するため、判断が遅れます。経営層や別部門を含めた場で判定すると決めておくと、担当者が違和感を持った時点で、それを議題として出しやすくなります。

自社の案件で基準値をどこに置くか迷う場合は、無料相談で一緒に整理します。判定の設計だけの相談でも構いません。

検証手段の比較：内製・調査会社・広告代理店・開発会社・何もしない

需要を確かめる手段は、外部に依頼するものだけではありません。ここでは主な選択肢を、費用の考え方と得られる証拠の段階で並べます。なお本記事は、検証を請け負う立場から書いています。その前提を踏まえてお読みください。

検証手段の比較表

金額は依頼先や条件で大きく変わるため、下の表では費用のかかり方を示しています。期間は一般的な目安で、実際には見積もりで確認してください。

手段	費用の考え方	期間の目安	得られる証拠の段階	向かないケース
自社でヒアリング	謝礼と自社の工数のみ	2〜6週間	段階1（課題）	相手の本音や購買行動まで知りたいとき
セルフ型のネットリサーチ	1問1回答で10円前後から。設問数と回収数で決まる	即日〜数日	段階1（課題の広がり）	BtoBで対象者を細かく絞りたいとき
調査会社に依頼	設計・実査・分析の工数。個別見積もり	2〜6週間	段階1〜2（意向まで）	実際の行動を確かめたいとき
広告代理店に広告テストを依頼	広告費＋制作費・運用手数料	2週間〜1か月	段階2（需要）	判定の設計まで任せたいとき
開発会社のPoC・MVP	開発費。ノーコードなら抑えられる	1〜3か月	段階2〜4（使われ方、実現性）	作る前に需要だけ知りたいとき
検証を専門にするサービス	広告費＋検証の費用（数十万円台が中心）	2週間前後	段階2〜3（需要と一部の商談）	継続率や採算まで判断したいとき
何もせず本開発へ	開発費のみ	—	なし	需要が確定していないとき

セルフ型のネットリサーチは、数千円から数万円で実施できます。ただし、BtoBで特定の職種や決裁者に絞ると回収が難しくなります。対象者の条件は先に確認が必要です。

段階と予算による選び方

手段は、いま不足している証拠の段階から選びます。課題の実在が確認できていなければヒアリングから始め、課題は分かっているが解決策を探している人がいるか不明なら広告での検証に進みます。使われ方や技術的な実現性を確かめたい段階になって、初めてPoCやMVPの出番になります。

依頼先を選ぶときは、契約に含まれる範囲を確認してください。広告代理店は配信の設計と改善を担いますが、事業を続けるかどうかの判定まで含むかは契約次第です。調査会社は設問の設計と分析に強みがありますが、実際の購買行動のデータは手元にありません。同じ「検証」という言葉でも、納品されるものは依頼先で変わります。

一度にすべてを確かめようとする必要はありません。ヒアリングで課題を確かめ、広告で需要を確かめ、そのうえでMVPを作るという順序にすると、各段階で引き返せます。順序を飛ばすほど、判断を誤ったときの損失が大きくなります。

かけてよい検証費用を決める基準は、開発費の規模です。数千万円の開発を前提とするなら、その数%を検証に充てても割に合います。反対に、開発費と検証費用が近づくなら、検証せずに作って確かめるほうが速いという判断もあり得ます。

何もせず開発へ進んでよい条件

検証をせずに開発へ進む判断が合理的な場合もあります。数十万円から百万円台で作れる規模であれば、検証に2週間と数十万円をかけるより、作って市場に出したほうが早く答えが出ます。すでに発注の意向を得た顧客がいる場合も同じです。

判断の分かれ目になるのは、失敗したときに失う金額と時間です。その損失を受け入れられるなら、検証を省く選択は合理的です。受け入れられない規模であれば、着手前に証拠を足す余地があります。自社の案件がどちらに当たるかは、金額で確認できます。

撤退基準と社内説明の組み立て方

判定の基準を決めても、社内で共有されていなければ機能しません。ここでは、撤退ラインを文書に落とす書き方と、検証結果を報告する形を示します。

撤退ラインを企画書にどう書くか

撤退ラインは、4つの要素をそろえて一文で書きます。「いつまでに」「どの指標が」「どの値に届かなければ」「何をするか」の4つです。このうち最後の行動は、「中止」だけにしないほうが運用できます。「対象を絞って再検証」「予算を半分に縮小」といった段階を用意しておくと、現場が基準を書くことへの抵抗も小さくなります。

書き方の例を挙げます。「配信開始から4週間で、問い合わせからの商談化が1件も発生しない場合は、対象の層を絞って再検証する」。指標を問い合わせ件数ではなく商談の発生に置いているのは、前に述べたとおり、証拠の強い段階で判断するためです。

避けたいのは、「反応が芳しくない場合は見直す」という書き方です。判断する人によって解釈が変わり、結局は継続の判断に落ち着きます。

社内説明用の判定テンプレート

検証の結果は、事前に決めた基準と並べて報告します。次の形式にすると、判定の根拠が読み手に伝わります。右端は、前のセクションで紹介した案件を当てはめた場合の記入例です。

判定項目	事前に決めた基準	判定	記入例（実案件）
成約が出たか	期間内に◯件	GO／条件付き／NO／判断不能	2件
獲得単価は許容内か	◯円以下		約6,600円（取引額が未確認のため判定保留）
仮説の層に反応があったか	層ごとに◯クリック以上で評価		1層が反応、1層は判断不能
想定した訴求は探されていたか	表示が発生するか		3つの訴求で表示ゼロ

報告の場では、GOかNOかの結論よりも、判断できなかった項目を先に共有してください。判断できない項目が残ったまま進めるのか、追加で確かめるのかを決めることが、次の意思決定になります。

「止めるための費用」をどう説明するか

検証には、成果が出ない部分にも費用がかかります。紹介した案件では、問い合わせが1件も発生しなかったキーワードに、広告費全体の約28%が使われました。金額にすると3万円弱です。

この支出は、無駄ではなく「その層に需要が見えなかったと確認するための費用」です。社内で説明する際は、この位置づけを先に伝えてください。検証の費用を成果の出た部分だけで評価すると、判定に必要な範囲まで削られ、結論の精度が下がります。本開発に数千万円をかける案件であれば、その数%で判断材料を用意できたかどうかが比較の基準になります。