システム開発を伴う新規事業の投資判断で最も大切なのは、開発費の全額を一度に投じるかどうかを決めることではなく、「どの段階で、いくらまで投じ、何が分かったら次に進むのか」を先に設計することです。新規事業は、作ってみるまで顧客が本当に使うか分からない、という不確実性を抱えています。その不確実性を前提にすると、最初に大きな金額を決め打ちするよりも、検証の段階ごとに小さく投資し、結果を見て追加するほうが合理的です。
もう一つの結論は、開発費の見積もりと回収見込みを「一つの数字」で評価しないことです。開発費は範囲によって大きく変わり、回収見込みは仮定によって大きく揺れます。だからこそ、数字を一つに絞るのではなく、前提条件と幅を持たせたシナリオで比較し、どの前提が崩れると事業が成り立たなくなるのかを把握しておくことが、判断の質を左右します。
この記事は、新規事業の責任者や担当者、経営企画、経営者で、システム開発を伴う事業への投資をどう判断すべきか悩んでいる方に向けて書いています。開発費の見積もりの読み方、回収見込みの立て方、段階的な投資の設計、継続と撤退の判断基準、よくある失敗とその避け方までを、手順と表で整理します。
なぜ新規事業の開発投資は判断が難しいのか
既存事業のシステム投資、たとえば業務システムの入れ替えであれば、効果の見積もりはある程度できます。今かかっている作業時間やコストが分かっており、システムによって何がどれだけ減るのかを推定できるからです。
新規事業ではこの前提が成り立ちません。判断を難しくしている要因は大きく三つあります。
収益の根拠がまだない
顧客が何人集まり、いくら払い、どれだけ続けてくれるのかは、事業を始めてみるまで分かりません。事業計画の売上は、多くの場合、仮定の積み重ねです。仮定の一つが外れれば、回収の見込みは大きく変わります。
開発範囲が固まっていない
何を作れば顧客の課題を解けるのかも、最初は仮説にすぎません。検証を進めるうちに必要な機能が変わるため、最初の見積もりの範囲と、最終的に必要な範囲は一致しないのが普通です。
撤退の判断が先送りされやすい
一度大きな金額を投じると、それを無駄にしたくないという心理が働き、うまくいっていない事業でも追加投資を続けてしまうことがあります。投じた費用は取り戻せない「埋没費用」なので、本来は今後の見込みだけで判断すべきですが、組織の中ではそう簡単に割り切れません。
この三つの要因があるからこそ、新規事業の開発投資は「一度に大きく決める」のではなく「小さく決めて、学びながら追加する」設計が求められます。
開発費の見積もりを読むときの視点
投資判断の前提として、開発費の見積もりが何で決まっているのかを理解しておく必要があります。システム開発の費用は、基本的に「どれだけの作業が必要か(工数)」と「その作業を誰がどの単価で行うか」の掛け算で決まります。工数は、作る機能の数と複雑さ、品質の水準、関わる人数とコミュニケーションの量によって変わります。費用の内訳の考え方はシステム開発の費用相場はどう決まるかで詳しく解説しています。
投資判断の観点で見積もりを読むときは、次の点を確認します。
- 見積もりの範囲が、どの検証段階に対応しているか。 全機能をまとめた見積もりなのか、最初の検証に必要な範囲だけなのかで、意味が大きく違います。
- 見積もりの精度がどの程度か。 要件が固まる前の概算は幅が大きく、詳細な見積もりとは性格が異なります。概算の段階で投資額を確定させないことが重要です。
- 開発費以外の費用が含まれているか。 サーバー費、外部サービスの利用料、保守費、運用の人件費、集客の費用などは、開発費とは別に継続して発生します。
- 変更が起きたときの扱い。 新規事業では仕様の変更が前提です。変更をどう見積もり直すのか、契約形態とあわせて確認します。
見積もりの精度については、概算見積もり・詳細見積もりの違いを理解しておくと、社内で数字を扱う際の誤解を減らせます。概算の数字が「確定した予算」として一人歩きすると、後から必要な変更が「予算超過」と見なされ、柔軟な判断ができなくなります。
回収見込みの立て方:一つの数字ではなくシナリオで考える
回収の見込みは、売上から変動費を引いた利益で、投じた開発費や固定費をいつまでに取り戻せるかで考えます。ここで大切なのは、売上の見込みを一つに決めず、前提の違う複数のシナリオで計算することです。
売上を分解して前提を明らかにする
売上を「顧客数 × 単価 × 継続期間」のように分解すると、どの前提に依存しているかが見えます。顧客数はさらに、接触できる見込み客の数と、そのうち申し込む割合に分けられます。それぞれの前提について、根拠のあるものと、まだ仮定にすぎないものを区別しておきます。継続課金の事業なら、解約を組み込んだ計算が欠かせません。SaaS事業計画の収益モデルの作り方で、その組み立て方を解説しています。
三つのシナリオを並べる
慎重・標準・好調の三つのシナリオを作り、それぞれで回収にかかる期間と、資金が最も少なくなる時点の額を計算します。比較の観点を表にすると次のようになります。
| 観点 | 慎重シナリオ | 標準シナリオ | 好調シナリオ |
|---|---|---|---|
| 前提の置き方 | 根拠のある前提だけで計算 | 現実的に見込める前提 | 仮説がすべて当たった場合 |
| 使い道 | 最悪の場合でも会社が耐えられるかの確認 | 事業計画の基準 | 追加投資や体制強化の上限の目安 |
| 見るべき数字 | 資金が最も減る時点の額 | 回収までの期間 | 拡大時に必要な追加投資 |
| 判断への影響 | 投資の上限を決める | 段階ごとの目標を決める | 成功時の準備を決める |
慎重シナリオで会社が耐えられないのであれば、その投資は規模を小さくするか、別の進め方を探すべきです。逆に、慎重シナリオでも耐えられるのであれば、残る問いは「どの前提を最初に確かめるか」に移ります。
感度の高い前提を見つける
前提を一つずつ動かしてみて、回収期間が最も大きく変わる前提を探します。たとえば、単価が少し下がるだけで事業が成り立たなくなるのか、それとも顧客数の前提のほうが影響が大きいのか。最も影響の大きい前提こそが、最初の検証で確かめるべきものです。投資判断と検証計画は、ここでつながります。
段階的に投資する設計:全額を一度に投じない
不確実性の高い新規事業では、検証の段階ごとに投資額と判断の条件を決め、段階を通過するたびに次の投資を判断する進め方が有効です。いわゆるステージゲートの考え方です。段階の区切り方の一例を示します。
| 段階 | 主な目的 | 開発の範囲 | 次に進む条件の例 |
|---|---|---|---|
| 課題検証 | 顧客が本当にその課題を抱えているか確かめる | 原則として開発しない。資料や簡単な試作で検証 | 想定顧客の多くが課題を認め、解決策に関心を示す |
| 解決策検証 | 提案する解決策で課題が解けるか確かめる | 手作業やノーコードを組み合わせた最小限の仕組み | 試験利用者が繰り返し使い、対価を払う意思を示す |
| MVP | 実際の利用と支払いが成り立つか確かめる | 中心となる機能だけのシステム | 有料利用が成立し、継続や紹介の兆しがある |
| 本格開発 | 事業として拡大できる仕組みを作る | 運用・拡張に耐える設計への作り込み | 獲得と継続の数字が計画の前提に近づいている |
この表のポイントは、段階が進むほど投資額は大きくなるが、判断の根拠も強くなるという関係です。最初の段階で大きな投資をしなくて済むよう、検証の手段は安く速いものから選びます。MVPの範囲の決め方はMVPの機能の絞り方も参考にしてください。
投資判断を進める手順
段階的な投資を実際の判断に落とし込む手順をまとめます。
- 事業の仮説を書き出す。 誰の、どんな課題を、どう解決し、どう収益を得るのかを一枚にまとめます。仮説の一つひとつが、後で検証する対象になります。
- 収益の前提を分解し、感度を確かめる。 売上と費用を要素に分け、どの前提が回収に最も影響するかを確認します。
- 慎重シナリオで投資の上限を決める。 最悪の場合でも会社が耐えられる損失の上限を、経営層と合意します。これが事業全体への投資の天井になります。
- 段階を区切り、各段階の投資額と期間を決める。 段階ごとに、使ってよい金額と期間、作る範囲を決めます。
- 各段階の「次に進む条件」と「やめる条件」を決める。 数字や事実で判断できる形で書きます。曖昧な条件は、後で都合よく解釈されがちです。
- 段階ごとに見積もりを取り、発注を分ける。 開発会社との契約も段階に合わせて区切ります。全体を一括で発注すると、途中でやめる選択肢が実質的に失われます。
- 段階の終わりに判断会議を開く。 結果を条件に照らし、継続・方向転換・中止のいずれかを決めます。判断の記録を残します。
- 判断の結果を次の段階の計画に反映する。 学んだことに基づき、前提とシナリオを更新してから次の投資を決めます。
継続・方向転換・撤退を判断する基準
段階の終わりに迷わないために、判断の基準をあらかじめ型として持っておきます。
継続する
次に進む条件を満たしており、慎重シナリオでも会社が耐えられる見込みがある場合です。ここで注意したいのは、条件を「おおむね満たした」状態で進むことの是非です。満たしていない部分が、感度の高い前提に関わるものであれば、次の段階に進む前に追加の検証を優先します。
方向転換する
顧客の課題は確かにあるが、提案した解決策や対象顧客、価格の前提が合っていなかった場合です。この場合、これまでの投資で得た学びを活かし、変える部分を絞って次の検証を設計します。開発済みのシステムは、残せる部分と作り直す部分を分けて扱います。最初から作り直す前提にせず、顧客管理や決済、認証といった方向転換後も使える土台がないかを確認すると、次の段階の投資を抑えられます。
撤退する
やめる条件に当てはまった、または慎重シナリオで耐えられないことが分かった場合です。撤退はこれまでの投資を無駄にする判断ではなく、これ以上の損失を防ぐ判断です。判断では、これまでにいくら使ったかではなく、これからいくら使えば何が得られるかだけを見ます。
撤退を決めた場合も、やるべきことは残ります。利用中の顧客への告知と移行の支援、データの扱い、契約中の外部サービスや開発会社との契約の終了、そして何が分かり何が分からなかったのかの記録です。とくに学びの記録は、次の新規事業の投資判断で前提を置くときの貴重な材料になります。撤退の手続きまで含めて段階の計画に入れておくと、撤退の判断そのものも下しやすくなります。
判断会議を形骸化させない工夫
段階の終わりの判断会議は、放っておくと「報告を聞いて継続を追認する場」になりがちです。形骸化を防ぐには、会議の前に結果を条件と照らした資料を配り、会議では判断だけに時間を使うこと、継続を提案する側とは別に、やめる理由を検討する役割の人を置くこと、判断の結果と理由を必ず記録して次の会議で振り返ることが有効です。判断を下す人が誰なのかを事前に決めておくことも欠かせません。
これらの判断を経営層に報告するときの伝え方は、経営層への新規事業の進捗報告にまとめています。
具体的な場面の例:業務支援サービスの段階投資
架空の一般例で考えます。ある専門サービス会社が、自社の業務ノウハウを活かして、同業他社向けの業務支援Webサービスを立ち上げようとしています。最初に開発会社から取った見積もりは、構想したすべての機能を作る前提のもので、経営層は「この金額を一度に投じてよいのか」と判断に迷っていました。
新規事業チームは、まず売上の前提を分解し、感度を確かめました。その結果、回収に最も影響するのは「同業他社が月額でいくらまでなら払うか」という単価の前提であることが分かりました。顧客数の前提も重要ですが、単価が想定を下回ると、どれだけ顧客を集めても回収できない構造だったのです。
そこでチームは計画を段階に分けました。最初の段階では開発をせず、同業他社に提案資料を見せて価格への反応を確かめます。次の段階では、表計算ソフトと手作業を組み合わせた仕組みで数社に試験提供し、実際に対価を受け取れるかを確かめます。そのうえで、中心となる機能だけのMVPを作り、有料の利用が継続するかを見ます。全機能の開発は、その結果を見てから判断することにしました。
経営層には、事業全体の投資の上限と、各段階の投資額、次に進む条件・やめる条件をまとめて説明しました。最初に承認を求めたのは、最初の二つの段階の小さな金額だけです。結果として、経営層は一度に大きな金額を決める必要がなくなり、チームは検証の結果をもって次の承認を求められるようになりました。
よくある失敗とその避け方
- 概算の見積もりが確定予算として扱われる。 概算は幅のある数字であることを、社内の資料に明記します。投資額は段階ごとに、詳細な見積もりを取ってから確定させます。
- 最初に全機能を一括で発注してしまう。 途中でやめる選択肢がなくなります。発注は段階ごとに分け、各段階の契約で区切ります。
- 好調シナリオだけで事業計画を作る。 承認を得やすくするために楽観的な数字だけを示すと、後で苦しくなります。慎重シナリオを必ず並べます。
- 開発費だけを見て、運用費や集客費を見落とす。 システムは作った後も費用がかかります。サーバー費、保守、運用の人件費、顧客獲得の費用を計画に含めます。
- やめる条件を決めずに始める。 条件がないと、撤退の判断が先送りされます。始める前に、数字や事実で判断できる条件を書きます。
- これまでの投資額を理由に追加投資を続ける。 判断はこれからの見込みだけで行うことを、事業開始時に関係者と合意しておきます。
投資判断の前に確認したいチェックリスト
- 事業の仮説が一枚にまとまっている
- 売上と費用が要素に分解され、感度の高い前提が分かっている
- 慎重・標準・好調のシナリオで回収期間と資金の底が計算されている
- 事業全体の投資の上限を経営層と合意している
- 段階ごとの投資額・期間・開発範囲が決まっている
- 各段階の「次に進む条件」と「やめる条件」が数字や事実で書かれている
- 開発費以外の継続費用が計画に含まれている
- 発注が段階ごとに分けられる契約になっている
- 判断会議の日程と参加者が決まっている
よくある質問
Q. 段階的に投資すると、かえって総額が高くなりませんか?
段階ごとに区切ると、打ち合わせや見積もりの手間が増える分、まとめて発注するより割高になる場合はあります。ただし、途中で方向転換や撤退をした場合に無駄にならずに済む金額を考えると、不確実性の高い段階では段階投資のほうが期待される損失は小さくなります。確実性が高まった段階では、まとめて発注する判断も合理的です。
Q. 投資回収の期間はどれくらいを目安にすべきですか?
一律の目安はありません。会社の資金の余力、既存事業の収益、事業の性質によって許容できる期間は変わります。大切なのは、慎重シナリオで資金が最も減る時点の額が、会社として許容できる範囲に収まっているかを確認することです。
Q. 社内の承認ルールが一括承認を前提にしている場合はどうすればよいですか?
事業全体の上限額を一度承認してもらい、その範囲内で段階ごとの執行を新規事業の責任者に任せる形を提案する方法があります。段階ごとの結果を報告する仕組みとセットにすると、経営層も受け入れやすくなります。
Q. 外部の投資家やファンドから資金を受ける場合も考え方は同じですか?
段階ごとに不確実性を減らしながら資金を投じるという考え方は共通です。ただし、外部資金の場合は投資家との契約条件や報告義務が加わるため、資金調達の制度や契約については専門家に確認してください。
Otsumuに相談できること
投資判断の枠組み自体は、ここまで紹介した手順で自社でも組み立てられます。事業の仮説が明確で、売上の前提を分解できており、経営層と段階ごとの判断条件を合意できる関係があるなら、外部に頼らず進めるのが最も速い方法です。
一方で、開発会社の見積もりが妥当か判断できない、どこまでをMVPとして作るべきか決められない、検証の手段を開発以外に思いつかない、といった状況では、事業と開発の両方を理解している外部の視点が役に立ちます。投資判断の難しさの多くは、事業計画と開発計画が別々に作られ、つながっていないことから生まれます。
Otsumuは、自らも事業を手がける実践者として、新規事業開発コンサルティングで事業の仮説整理と段階ごとの検証計画づくりを支援しています。構想から開発・運用・改善まで一気通貫で関わるため、検証に必要な開発があれば新規事業の爆速MVPシステム開発で、目的から逆算して必要な機能に絞り、AIを活用して少人数・短期間で形にできます。今の計画と見積もりを短期間で点検したい場合は、新規事業レビュー Sprint(48万円・税別、1〜2週間)、MVPで検証まで進めたい場合はPoC / MVP Sprint(300万円〜・税別、6週間を目安に設計)といった進め方があります。
投資の判断に迷っている段階でも構いません。30分の無料相談で、現在の計画と見積もりを一緒に確認します。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆:Otsumu株式会社 / 編集日 2026.10.01