MVP開発の会社選びは、「作らない」と言えるかで決まる

MVP開発を任せる会社を探すと、「おすすめ◯選」の比較記事が並びます。ところが何本読んでも、自社に合う一社は決まりません。

この記事では、比較記事からは見えない選び方を整理します。結論を先に書くと、見るべきは実績数でも技術力でもなく、「それは作らないでおきましょう」と言える仕組みがあるかです。

MVP開発の会社を、比較記事で選べないのはなぜか

比較記事が役に立たないわけではありません。候補を集める道具としては有効です。ただ、そこから一社を選ぶ材料にはなりません。理由は3つあります。

掲載の基準が記事ごとに違う。 何をもって「MVPに強い」としているかが書かれていないことが多い
実績の数は、検証の質を表さない。 何件作ったかは分かっても、そのうち何件が次に進んだかは分からない
どのリストにも同じ会社が並ぶ。 差がつかないので、結局は費用と規模で比べることになる

比較記事は候補を10社に絞るところまでは進めてくれます。その先の判断材料は、自分で持つしかありません。

では何を材料にするか。それを決めるには、MVP開発でいちばん多い失敗を先に見ておく必要があります。

MVPのはずが、小さい本開発になっていく

いちばん多い失敗は、技術的な失敗ではありません。機能が増え続けることです。

koromoは、ユーザー登録・検索・メッセージの3機能でMVPを定義したはずが、議論を重ねるうちに決済・レビュー・通知・管理画面が積み上がり、機能が20を超えて9ヶ月・600万円規模の「ミニ本実装」になった例を挙げています。

この事例で注目したいのは、増えた機能のどれもが、その場では正しく見えていることです。

「決済がないと、そもそも使ってもらえない」
「管理画面がないと、運用が回らない」
「競合サービスにはある機能なので、無いと比較されたときに弱い」

どれも間違ってはいません。ひとつずつ見れば全部もっともです。だから会議では通ります。そして半年後、当初の目的だった「早く出して反応を見る」が失われています。

最初に決めた範囲は、放っておくと必ず広がります。 問題は、広がったときに誰が止めるのかです。

なぜ誰も「作らない」と言えないのか

ここが構造の話になります。

機能を増やす提案には、それを言う理由があります。事業側は不安だから足したい。開発側は求められたものを断る理由がない。しかも受託開発では、作る量が増えれば売上も増えます。

一方で「それは作らないでおきましょう」と言う側には、誰も得がありません。発注側が言えば、社内から「なぜ削るのか」と問われます。開発側が言えば、売上が減るうえに、後で問題が起きたときの責任を負うことになります。

つまり、増やす方向には全員に理由があり、減らす方向には誰にも理由がない。これがMVPの範囲が広がる本当の原因です。

誤解のないように書いておくと、これは開発会社の姿勢の問題ではありません。契約がそういう形になっているだけです。請負契約は、決まったものを決めた金額で正確に作るための仕組みで、そこには十分な合理性があります。ただ、作るものがまだ決まっていないMVPの段階とは、前提が噛み合いません。

だから会社を選ぶときに聞くべきは、「一緒に考えてくれますか」ではありません。ほとんどの会社が「はい」と答えます。聞くべきは、作らないと決める場面がどこに用意されているかです。

MVP開発の会社を選ぶときに見る4つのこと

比較記事の代わりに、次の4点を見ます。どれも初回の商談で確認できます。

見るところ	望ましい状態	確認が必要なサイン
「作らない」と決める場面	どの会議で、何を根拠に決めるかが決まっている	「ご要望に応じて柔軟に対応します」だけで、決める場が無い
仕様が変わったときの扱い	変わる前提で、扱い方が契約に書かれている	契約書に「別途協議」としか書かれていない
リリースしたあとの判断	何を見て、伸ばすか・やめるかを一緒に決める	納品で終わり、その後は別案件として扱う
終わったあとに残るもの	コードと、判断の基準が自社に残る	引き継げる形で渡す前提が無い

このうち最初の1つが決定的です。「作らない」と決める場面が用意されていない限り、残り3つは形だけになります。

たとえば週次の打ち合わせで「今週決めること」が事前に置かれているか。仮説に対して要る機能・要らない機能を並べて判断する場があるか。こうした運用が最初から組み込まれている会社は、機能が増え始めたときに気づけます。

見積書と契約書の、どこを読むか

商談で「柔軟に対応します」と言われたことが、書面でどう表現されているかを確認します。ここが実際の運用を決めます。

変更管理の条項

仕様が変わったときの扱いが書かれているか。「別途協議」だけなら、実際には毎回の交渉になります。変更を織り込む前提の契約なら、判断の手順まで書かれています。
検収の定義

何をもって完了とするか。「仕様書どおりに動くこと」なのか、「検証できる状態になること」なのか。前者だと、動くが判断材料にならないものでも検収は通ります。
著作権と引き渡し

コードとデザインデータの権利が自社に来るか。来なければ、次の段階で別の会社に引き継ぐことも、自社で続けることもできません。
運用の範囲

リリース後の不具合対応、サーバー費用、軽微な修正がどこまで含まれるか。MVPは出したあとに手を入れる前提なので、ここが別料金だと総額が変わります。

見積書の金額だけを横に並べても比較になりません。同じ金額でも、上の4つが違えば買っているものが違います。

依頼先による、機能の増え方の違い

依頼先の型によって、機能が増えたときの挙動が変わります。

	一般的な受託開発	ラボ型・準委任	ノーコード／フリーランス	YOLOのプロダクト開発
契約の形	請負が中心	準委任	案件により異なる	準委任を前提に、検証の単位で区切る
機能が増えたとき	追加見積もりと変更契約	稼働の範囲に吸収される	都度見積もり	検証に要るかで判断し、要らなければ作らない
「作らない」と言う人	発注側が言うしかない	決める人が曖昧になりやすい	発注側が言うしかない	進行役が仮説を根拠に提案する
リリースしたあと	別案件として見積もる	稼働を継続する	都度対応	伸ばすか、やめるかの判断まで一緒に置く
噛み合う場面	要件がすでに固まっている	手を動かす人が長く要る	作るものが決まっていて小さい	何を作るかがまだ決まっていない

一般的な受託開発は、要件が固まっている案件では最も確実です。決まったものを決めた金額で作る体制なので、予算の見通しも立ちます。ラボ型は、継続的に手を動かす人が必要な局面で機能します。ノーコードやフリーランスへの依頼も、作るものが小さく明確なら費用対効果が高くなります。

問題は、MVPを作りたい会社の多くがそのどれでもないことです。何を作るかがまだ決まっていない。この状態で、決まっている前提の契約を結ぶと、決まっていない分がそのまま追加費用と遅延になって現れます。

YOLOが「作らない」と言える理由

進め方を掲げるだけなら誰にでもできます。実行できるかどうかは体制で決まります。

YOLOは開発会社ではなく、UXデザインとプロダクトマネジメントに専門性を持つProduct Evolution Studioです。メンバーは事業会社で自社プロダクトの開発とグロースを経験しており、発注側として「何を作らないか」を決めてきた人間が進行に入ります。

これが実務で効くのは、次の場面です。

機能を足したくなる場面 — 何を確かめたいかに立ち返って判断できるため、要らないものを要らないと言える
社内から要望が来る場面 — 断る理由ではなく、いつ作るかの順番として示せる
引き渡しの場面 — 内製化を前提に、判断の基準ごと渡せる

実際の支援でも、株式会社ダンダダン様では顧客LTVを最大化する新規モバイルアプリの開発と事業検証を担当し、アプリを通したユーザー体験最大化のための店舗オペレーション構築とグロース支援まで行いました。株式会社LabBase様では内製化を意識して社内のPMの方と伴走しています。ほかの事例はプロダクト開発のページに掲載しています。

作る量を減らすことが目的ではありません。早く出して、判断できる状態にすることが目的です。

まとめ

比較記事は候補を集める道具であって、そこから一社を選ぶ基準にはならない
MVPで最も多い失敗は機能が増え続けること。増やす側には理由があり、減らす側には誰にも理由がない
選ぶときは実績数ではなく、「作らない」と決める場面が進め方と契約に用意されているかを見る

YOLOでは、プロダクト開発の支援を、何を作らないかを決める段階から行っています。費用がどう決まるかはMVP開発の費用に、決める役割が社内にいない場合の考え方はPdM不足と求人票の問題にまとめました。