ランウェイから開発範囲を逆算する

「開発にいくらかけられますか」と聞かれて、即答できる会社は多くありません。相場を調べても幅が大きく、判断の助けになりにくいためです。この問いは、金額から考えると答えが出ませんが、残り月数から逆算すると、かなり機械的に決められます。

本記事では、ランウェイ（現在の資金で事業を継続できる期間）を起点に、開発に回せる額と作る範囲を決める手順を整理します。金額そのものは事業によって大きく異なるため、ここでは考え方と手順だけを扱います。費用の内訳や見積の読み方はMVP開発の費用相場をあわせてご覧ください。

手順1: 現在のランウェイを月数で出す

出発点は、残りの現預金と、月あたりの純減額（バーンレート）です。

ランウェイ（月）＝ 現在の現預金 ÷ 月あたりの純減額

ここで注意したいのは、純減額を過去の平均で置かないことです。採用や広告投下の予定があれば、これからの純減額は今より大きくなります。直近の実績ではなく、これからの数か月に実際に出ていく見込みで計算してください。

売上がある場合は、入金のタイミングも考慮します。売上が立っていても入金が翌々月なら、手元の資金はその分だけ薄く動きます。

手順2: 次の目標時期を決める

ランウェイが出たら、次に「いつまでに何を達成するか」を決めます。選択肢は大きく二つです。

• 次の資金調達を目指す：調達活動には準備と交渉で数か月かかります。資金が尽きる直前に動き出すと、条件の交渉余地がなくなります。ランウェイから調達活動に要する期間を差し引いた時点が、実質的な締切です。
• 黒字化を目指す：単月の収支が均衡する時期を目標に置きます。この場合、開発投資は収益に直結するものへ強く絞られます。

この目標時期から逆算した期間が、開発に使える時間です。ランウェイそのものではない点に注意してください。ランウェイ12か月で、調達活動に3か月かかるなら、開発で成果を出す期間は9か月です。

手順3: 固定費と余白を先に引く

開発に回せる額は、残額から順に引いていくと確定します。引く順序は次のとおりです。

1. 人件費：既存メンバーの給与と社会保険料。目標時期までの合計。
2. 継続的な固定費：オフィス、SaaS、既存システムの運用費、専門家への顧問料。
3. 事業に必須の変動費：原価、決済手数料、最低限の広告費。
4. 余白：想定外の支出に備える分。ここを確保しないと、小さな不測の事態で計画全体が崩れます。

この四つを引いた残りが、新しい開発に回せる上限です。多くの場合、想像していたより小さい数字になります。それが実態です。

余白をどれだけ取るかに決まった答えはありませんが、余白をゼロにしないことだけは守ってください。開発には見積を超える事態が起こります。想定していなかった外部サービスの制約、データ移行の手間、法務確認による手戻り。余白がないと、これらが起きた瞬間に事業判断ではなく資金繰りが主導権を握ります。

手順4: 月あたりに割り戻す

上限額が出たら、目標時期までの月数で割ります。この「月あたりに使える開発費」が、実務でもっとも使いやすい数字です。

なぜ月あたりで見るかというと、外部への委託は多くの場合、月ごとの稼働で契約するためです。月あたりの額が決まれば、どの程度の体制を組めるかがおおよそ見えます。一人月あたりの単価は依頼先によって差がありますが、月あたりの上限を先に決めておけば、見積を受けたときに「何人月分なら収まるか」を即座に判断できます。

また、月あたりで管理すると、途中での軌道修正がしやすくなります。総額で契約すると、途中で方向転換したくなったときに範囲と費用の再交渉が必要になります。月ごとの稼働で契約していれば、優先順位を入れ替えるだけで済みます。要件が動く時期には、この形が向いています。

手順5: 収まらないときは仮説から削る

ここまで来ると、たいていの場合、作りたい範囲が上限に収まりません。そこで機能を一つずつ削る作業に入りがちですが、順序が逆です。

先に見るのは、検証したい仮説がいくつ含まれているかです。要望の一覧を眺めると、実は三つも四つも別々の仮説を同時に確かめようとしていることがあります。仮説を一つに絞ると、必要な機能は驚くほど減ります。機能を一つずつ削る作業は、仮説を絞った後にやると効率がよくなります。

削る順序は次のようになります。

1. 検証したい仮説を一つに絞る
2. その仮説の検証に効かない機能を外す
3. 実装せずに検証できる部分（手作業の運用、既存ツールの組み合わせ）を探す
4. 残った範囲を、上限の金額と突き合わせる

最初の二手順がどう効くかを、想定の例で見てみます。業務向けサービスの新機能に、半年分の開発予算を充てようとしている場面だとしましょう。要望を整理すると、「現場が使い続けるか」と「管理者が導入を承認するか」という二つの仮説が混ざっていました。前者に絞ったところ、管理者向けの権限設定や集計画面が検証対象から外れ、範囲がほぼ半分になりました。後者は、現場での利用が定着してから確かめる順序に変えています。

仮説の絞り方はMVP開発とはで詳しく整理しています。

ランウェイが短いときに使わないほうがよい費目

残り月数が短くなるほど、支出は「効果の大きさ」ではなく「結果が出るまでの速さ」で選ぶことになります。次の費目は、残り6か月を切った局面では見送ることをお勧めします。

作り直しと基盤整備。 効果は本物ですが、効果が出るのは数か月先です。その時点まで会社が資金を保てるかが不確かなら、投資として成立しません。判断の順番は調達後に返す技術的負債の順番で扱っています。

長期契約による単価の引き下げ。 クラウドの予約割引などは、一定期間の利用を確約する代わりに単価が下がる仕組みです。月々の支出は減りますが、資金が尽きる可能性がある局面で期間を確約するのは、選択肢を狭める方向に働きます。

採用にかかる費用。 採用が決まって立ち上がるまでの期間を、残り月数が吸収できるかを確認してください。入社の一か月後に資金が尽きる計画は、本人にも会社にも不誠実です。

検証されていない機能の追加開発。 残りが短い局面では、新しい仮説を増やす余裕はありません。すでに手応えのある部分を確実にするほうに寄せます。

弊社にご相談いただく場合も、ランウェイを先に伺います。残りが短い状況で、効果が出るまでに数か月かかる開発をご提案するのは、受注としては成立しても発注側の利益になりません。この局面では、開発を請けずに「いま作らずに済ませる方法」をお伝えすることもあります。逆に、残り月数に見合う範囲であれば、月ごとの稼働で小さく区切る形をご提案します。

手順6: リリース後の運用費を計画に入れる

見落とされやすいのが、作り終えた後に毎月出ていく費用です。ここを見込まずに開発費を使い切ると、リリースした翌月から資金の減り方が想定と変わります。

含めるべきものは次のとおりです。

• サーバー、データベース、外部サービスの利用料
• 障害対応と、小さな改修に要する稼働
• 監視や記録の仕組みにかかる費用
• 決済や認証など、利用量に比例して増える費用

AI機能を含む場合は、外部APIの利用料が利用量に比例する点に注意が必要です。利用者が増えるほど支出が増えるため、想定する利用量での月額を概算し、上限の設定を設計に含めてください。運用費の見直し方はクラウドインフラコストの圧縮にまとめています。

手順7: 月ごとに実績と突き合わせる

計画を立てた後は、月ごとに実際の支出と突き合わせます。確認するのは次の二点です。

• 想定した純減額から乖離していないか
• 開発の進捗が、使った額に見合っているか

二つ目が重要です。予算どおりに使っていても、検証すべき仮説に近づいていなければ、資金を時間に変換できていません。月に一度、「今月の支出で、何が分かったか」を一文で書けるかを確かめてください。書けない月が続くなら、範囲か進め方に問題があります。

金額ではなく、残り時間から考える

開発範囲の判断が難しいのは、金額から入るからです。残り月数を起点に、固定費と余白を引き、月あたりに割り戻す。その額に収まらなければ、機能ではなく仮説を絞る。この順序で考えると、判断はかなり機械的になります。

実際の金額は、事業の性質、必要な機能の複雑さ、体制の作り方によって大きく異なります。相場の数字を当てはめるより、自社の残り時間から逆算した上限を先に持っておくほうが、見積を受け取ったときの判断が速くなります。

残りの期間で何をどこまで作るべきか、範囲の整理を一緒に行いたい場合は、Webシステム開発や市場リサーチの観点から状況を伺います。お問い合わせからご相談ください。ご相談・お見積りは無料です。