PMF(プロダクトマーケットフィット)に到達する前のスタートアップにとって、開発体制の選び方は事業の生死を分けます。まだ「誰のどの課題を解くか」が固まっていない段階で、立派な開発チームを組んで腰を据えて作り込むと、仮説がハズれたときに身動きが取れなくなります。

この記事では、AI 駆動開発のクリエイティブスタジオである FIXIT が、PMF 前のスタートアップが取るべき開発体制を「スピード」と「捨てる前提(撤退のしやすさ)」の両立という観点で整理します。内製・外注・AI 駆動開発の使い分け、検証を止めずにピボットできるプロダクトの作り方、週次デモで意思決定を速める進め方、そして実際の探索フェーズでの進め方までを扱います。

PMF 前は「正しく作る」より「速く確かめる」が正義

PMF 前のスタートアップが最初に握っておくべき前提は、この段階のプロダクトは検証の道具であって、完成品ではない ということです。

成熟したプロダクトであれば、可用性・拡張性・保守性を作り込む「正しく作る」ことに価値があります。しかし PMF 前は、そもそも作っているものが当たっているかどうかが分かっていません。ここで品質を作り込むのは、行き先が決まっていないのに高速道路を全力で走るようなものです。速く走るほど、間違った方向に遠くまで進んでしまいます。

この段階で測るべき指標は、コードの綺麗さでも機能の網羅性でもなく、仮説検証のサイクルを何回・どれだけ速く回せたか です。1 つの仮説を 1 週間で検証できるチームと、1 か月かかるチームでは、同じ半年でも検証回数が 4 倍違います。検証回数の差が、そのまま PMF にたどり着く確率の差になります。

だからこそ、PMF 前の開発体制を選ぶときの評価軸は「いいものを安く作れるか」ではありません。学習サイクルを速く回せるか、そして仮説がハズれたときに低コストで捨てられるか の 2 点です。この 2 点を軸に、内製・外注・AI 駆動開発を使い分けていきます。

内製・外注・AI 駆動開発の使い分け判断

PMF 前の開発手段は、大きく内製(エンジニアを採用して自社で作る)・外注(受託開発に委託する)・AI 駆動開発(AI エージェントを実装の中心に据えて少人数で作る)の 3 つに整理できます。それぞれ向き不向きがはっきりしています。

flowchart TD
  Q1{"作るものが<br/>確定している?"}
  Q1 -->|まだ揺れている| Q2{"検証を<br/>止めたくない?"}
  Q1 -->|ほぼ確定| INHOUSE["内製化を検討<br/>(コア機能の継続改善)"]
  Q2 -->|止めたくない| AID["AI 駆動開発<br/>少人数 + 委託で薄く速く"]
  Q2 -->|まとめて任せたい| OUT["外注<br/>要件を切り出して委託"]

内製は、作るべきものが固まり、継続的に改善し続けるフェーズで強みを発揮します。事業ドメインの知識がチームに蓄積し、改善の意思決定が速くなるからです。一方で、採用には時間がかかり、固定費として人件費が乗り続けます。PMF 前にフルタイムのエンジニアを何人も抱えると、ピボットのたびにその人たちの手が空いたり、逆に特定スタックへのこだわりが足かせになったりします。

従来型の外注(受託開発)は、要件がある程度固まった塊をまとめて任せたいときに有効です。ただし PMF 前は要件そのものが頻繁に変わるため、仕様変更のたびに見積もりと契約を取り直す進め方だと、検証スピードが契約手続きの速度に律速されてしまいます。

AI 駆動開発は、この 2 つの中間にある第三の選択肢です。少人数(あるいは外部パートナーとの混成)で、AI エージェントを実装の中心に据えて作るため、固定費を抱えずに内製に近いスピードで動けます。仕様が揺れても作り直しのコストが低いので、PMF 前の「速く確かめて、ハズれたら捨てる」という要求と相性が良い手段です。AI 駆動開発が従来開発と何が違うのかは AI 駆動開発とは？従来開発との違い・進め方 で整理しています。

人を採る前に検証を回すべき理由

PMF 前のスタートアップでよくある失敗が、「プロダクトを作るぞ」と意気込んで、最初にエンジニアを採用してしまうことです。気持ちは分かりますが、これは順番が逆になりがちです。

正社員のエンジニアを 1 人採ると、採用に数か月、オンボーディングに数週間、そして辞めてもらうにも相応のコストがかかります。仮説が 1 つハズれてピボットするたびに、この固定費が重くのしかかります。検証フェーズで人を増やすことは、学習する前に撤退コストを積み上げる行為 になりかねません。

PMF 前は、人を増やすより検証サイクルを速くする方を先に考えます。外部の委託や AI 駆動開発であれば、検証したい仮説の単位で薄く広く作って試し、ハズれたら止める、当たったら投資を厚くする、という調整がしやすくなります。実際、最初の数か月は委託や AI 駆動開発で検証を回し、コア機能と提供価値が安定してから内製エンジニアを採る、という順番にした方が、無駄な固定費を抱えずに済みます。

最初の 1 人を採るなら、特定の技術スタックの専門家よりも、技術選定ごと任せられて事業の議論にも入れる人を選ぶと、ピボットに耐えられます。

捨てる前提のプロダクトを作る技術的な工夫

PMF 前のプロダクトは捨てることを前提に作る、と聞くと「雑に作ればいい」と誤解されがちですが、そうではありません。捨てやすく作る には、それなりの設計上の工夫が要ります。

一番大事なのは、捨てる単位を機能ごとに切り分けておくことです。共通の土台(認証、データの入れ物、課金などのインフラ的な部分)と、検証対象の機能(まだ当たるか分からない部分)を疎結合にしておきます。こうしておけば、ある仮説がハズれても、その機能だけを外して土台は次の検証に再利用できます。土台と検証機能がベッタリ結合していると、1 つの機能を捨てるためにシステム全体を作り直す羽目になります。

次に、検証に不要な部分は意図的に薄く保ちます。具体的には次のような割り切りです。

  • 検証したい仮説に直結する一画面・一機能だけを作り込み、それ以外は仮実装で済ませる
  • 管理画面やバッチ処理は、最初は手動運用(スプレッドシートや手作業)で代替する
  • データ基盤は本格的なものを組まず、まずは検証データが取れる最小構成にする

AI 駆動開発を使うと実装そのものが速くなる分、つい周辺機能まで作りたくなる誘惑が生まれます。しかし PMF 前に避けたいのは「丁寧に作り込みすぎて捨てられなくなる」状態です。AI でコードを速く量産できるからこそ、「速く作って速く捨てる」前提の設計を意識的に守ることが、かえって無駄を抑える鍵になります。

加えて、捨てる前提だからこそ、最低限のテストとドキュメントは残しておきます。これは矛盾しているようですが、ピボット後に「前の検証で何が分かったか」を引き継ぐためです。コードは捨てても、学習は捨てない。この線引きが PMF 探索の質を決めます。捨てやすさを基準にした技術スタックの選び方は SaaS スタートアップの技術選定｜AI 駆動開発前提のスタック設計 で掘り下げています。

週次デモと意思決定スピードを担保する進め方

検証サイクルを速く回すには、作る速さだけでなく「決める速さ」も必要です。せっかく 1 週間でプロトタイプができても、それを見て次にどうするかを決めるのに 2 週間かかれば、サイクル全体は遅くなります。

ここで効くのが 週次デモ です。週に 1 回、必ず動くものを触りながら、創業者・事業責任者・開発側が同じ画面を見て次の意思決定をする場を固定で設けます。ポイントは、資料やスクリーンショットではなく、実際に触れる動くものを見ることです。動くものを前にすると、議論が「こうあるべき」という抽象論から「この操作が分かりにくい」という具体に降りてきます。

週次デモを機能させるコツは 3 つあります。

1 つ目は、デモのアジェンダを「先週検証したかった仮説に対して、結果はどうだったか」に固定することです。新機能のお披露目会にしてしまうと、検証が目的だったことを見失います。

2 つ目は、その場で次の 1 週間で検証する仮説を 1 つに絞って決めることです。あれもこれもと欲張ると、結局どれも中途半端になります。意思決定者がその場にいることが前提なので、持ち帰りを最小にします。

3 つ目は、捨てる判断もその場で下せるようにしておくことです。「この方向はハズれた」と分かったら、未練を残さず次の仮説に移ります。捨てる判断を先送りすると、ハズれた方向に開発リソースを使い続けることになります。

AI 駆動開発のクリエイティブスタジオとして案件を進めるときも、この週次デモを進行の軸に据えています。動くものを毎週出せるのは AI で実装が速いからこそで、スピードと意思決定の速さが噛み合うと、検証サイクルが目に見えて短くなります。

ピボット時に開発を止めないための設計

PMF 前のスタートアップにとって、ピボットは事故ではなく前提です。問題は、ピボットのたびに開発が数週間止まってしまうことです。検証を止めないためには、ピボットしても無駄になりにくい部分と、捨てる部分を最初から分けておきます。

ピボットしても再利用しやすいのは、ドメインに依存しない土台の部分です。認証、課金、通知、データの保存といった機能は、事業の方向が変わっても作り直す必要が薄いので、最初からある程度しっかり作っても無駄になりません。逆に、特定の仮説に紐づく画面やロジックは、ピボットで丸ごと捨てる前提で薄く作ります。

この切り分けを成立させるのが、リポジトリにコンテキスト(設計方針やドメイン知識)を Markdown で常駐させる進め方です。何をなぜそう作ったかがドキュメントとして残っていれば、ピボット後に「どこまで再利用できて、どこを捨てるべきか」の判断が速くなります。AI 駆動開発では、この常駐ドキュメントを AI も人も同じように参照して開発するため、ピボット後も同じ前提で作業を続けられます。

契約面でも、ピボットを止めない工夫があります。仕様変更のたびに見積もりと契約を取り直す進め方だと、検証が契約手続きの速度に縛られます。準委任で工数ベースの柔軟な進め方にしておけば、仕様が揺れても契約のやり直しで足止めを食わずに済みます。委託先の選び方については AI 受託開発の会社を選ぶときのチェックポイント も参考になります。

実例｜PMF 探索フェーズで AI 駆動開発を使った進め方

ここまでの考え方を、実際の進め方に落とし込んでみます。以下は、SaaS の新規事業を立ち上げた業種匿名のスタートアップ(創業数名規模)の探索フェーズで実践した進め方です。

このスタートアップは、ある業務の非効率を解く SaaS の仮説を持っていましたが、ターゲットとなる顧客像も提供価値もまだ揺れている段階でした。そこで、内製エンジニアを採るのではなく、AI 駆動開発のクリエイティブスタジオと組んで、3 週間で最初の検証用 MVP を作る進め方を取りました。短期で動く MVP を立ち上げる進め方は SaaS MVP 開発サービス でも提供しており、最短リリースの 7 手順は SaaS の MVP の作り方、実際の進行は 3 週間で SaaS MVP を立ち上げた事例 にまとめています。

進め方のポイントは次の通りです。最初の MVP では、検証したいコアの 1 機能だけを作り込み、管理画面やデータ集計は手動運用で代替しました。これにより、本来 2 か月かかる範囲を 3 週間に圧縮しています。週次デモで実際の見込み顧客に触ってもらい、毎週「次に検証する仮説」を 1 つに絞って決めました。

探索の途中で、当初想定していたターゲットよりも、隣接する別の業種の方が課題が深いことが分かり、ピボットしました。このとき、認証やデータの土台は再利用し、検証対象だった画面とロジックだけを差し替えたため、ピボットに伴う作り直しは数日で済みました。捨てる単位を機能ごとに切り分けておいた設計が効いた場面です。

結果として、固定費としてのエンジニア人件費を抱えることなく、半年で複数回の検証とピボットを回し、提供価値が安定した時点で内製エンジニアの採用に踏み切る、という順番を実現しました。「速く確かめて、ハズれたら低コストで捨てる」という PMF 前の要求に、AI 駆動開発が素直に応えた形です。

まとめ｜評価軸はスピードと撤退のしやすさ

PMF 前のスタートアップが開発体制を選ぶとき、評価軸は「いいものを安く作れるか」ではなく、学習サイクルを速く回せるか、ハズれたときに低コストで捨てられるか の 2 点です。

人を採る前に検証を回し、捨てる単位を機能ごとに切り分け、週次デモで意思決定を速め、ピボットしても土台が再利用できるように設計する。これらを満たす手段として、固定費を抱えずに内製に近いスピードで動ける AI 駆動開発は、PMF 探索フェーズと相性の良い選択肢です。作るべきものが固まってから内製化に踏み切る、という順番を守れば、無駄な固定費もベンダーロックインも避けられます。

PMF 前のどのフェーズで、内製・外注・AI 駆動開発のどれを選ぶべきか迷っているなら、開発体制の無料相談 で現状の仮説と検証状況をお聞かせください。検証を止めずに進める体制づくりを、SaaS MVP 開発サービス を含めてご提案します。