初回開発の見積もりを頼む前に
MVP開発の初期範囲を決める方法価値・検証・運用の3条件
「MVPで小さく」と伝えても、開発会社ごとに確かめる価値と運用上限が違えば、見積もりは比べられません。最初の版で誰のどんな判断を良くするか、何が起きれば続けるか、どこまで人手とリスクを引き受けるかを同じ一枚にします。
3条件を先に見る
先に結論
機能を数で削る前に、一つの仕事を最後まで通す
MVPの範囲は、機能を何個まで減らすかから決めません。担当者が仕事を始め、判断や連絡に使える結果を受け取るまでを一本通します。入力画面だけ、一覧画面だけでは、画面が動いても実際の仕事が終わらないことがあります。
説明用の訪問修理受付を、価値仮説・検証信号・運用上限の3条件で区切っています。実際の範囲は、対象業務と安全に使うための条件に合わせて決めます。
名前だけでは範囲は決まらない
MVP・画面試作・PoC・フェーズ1を分ける
同じ「小さく始める」話でも、確かめるものが違います。発注時は名称だけで合意せず、今回使える状態と対象外を言葉にします。
見た目と操作を確かめる
画面の並び、入力のしやすさ、操作の流れを確認します。裏側の処理やデータ保存が完成しているとは限りません。
技術や精度が成立するか確かめる
連携できるか、必要な精度が出るか、難しい処理が実現できるかを限られた条件で確認します。
最小限の製品を使って価値を確かめる
利用者が実際に使える最小限の製品を出し、役立つか、次に何へ投資するかを確かめます。
契約や開発の一区間を示す
初回の開発区間を示す呼び方です。MVPと同じ範囲になる場合も、試作や基盤づくりだけの場合もあります。
見積もり依頼でそろえるのは、呼び方ではなく完成像です。 誰が、どの仕事を、どこまで終えられるか。何を含め、何を含めないか。何をもって完成とするかを書きます。
見積もり依頼に添える
フェーズ1の範囲を決める価値・検証・運用の3条件
機能を並べる前に、何を確かめる投資なのかを固定します。作る量が同じでも、確かめる価値、合否の信号、許容する運用負荷が違えば、必要な範囲は変わります。
知式では、初期範囲を「価値仮説」「検証信号」「運用上限」の順で区切ります。これは画面や機能の分類ではなく、次の投資判断に必要な情報から逆算する並びです。
- 01
価値仮説｜誰のどんな判断を変えるか
利用者が受け取るものから、判断や連絡に使える結果を返すまでを一本にします。機能名ではなく、今より何を早く、正確に、迷わず決められるかを書きます。
書くこと：利用者 / 仕事のきっかけ / 返す結果 / 変えたい判断 - 02
検証信号｜続けるかを決める観測結果
代表例を実機で最後まで通し、利用記録、処理時間、差戻し、相談や申込みなど、次の投資判断に使う信号を決めます。単に画面が完成したことを合格にしません。
書くこと：代表例 / 観測する結果 / 合否を決める人 / 判断日 - 03
運用上限｜初回に引き受ける負荷と境界
手作業で代替する内容、対象外、同時利用者、データ量、初回から必要な品質・安全条件を一緒に決めます。運用できる上限を超える要望は次の判断へ送ります。
書くこと：人手の代替 / 対象外 / 利用環境 / データ量 / 品質・安全条件
一枚にまとめる
空欄を残したまま、次の打ち合わせへ持っていく
決まっていない項目を推測で埋めません。空欄は、見積もり前に発注側と開発会社が一緒に決める質問です。
機能名が同じでも、利用者、データ、例外、完成を確認する環境が違えば、見積もりの前提は変わります。
- 01 価値仮説
- ____________が ____________を受け取り、____________を判断できる
- 02 検証信号
- 代表例____________ / 観測結果____________ / 判断者____________ / 判断日____________
- 03 運用上限
- 人手____________ / 対象外____________ / 利用・データ上限____________ / 品質・安全____________
訪問修理受付の記入例
受付から対応履歴までを、初回で一本通す
ここでは、訪問修理の受付を外部開発する場面で、3条件の書き方を示します。期間、費用、成果を示す顧客事例ではありません。
- 01価値仮説
- 受付担当が、依頼から訪問結果までの次の対応を迷わず決められる
電話・メールを受け取り、受付内容、担当、訪問予定、対応結果を一件の流れとして確認できる。
- 02検証信号
- 3人が実機で代表10件を最後まで通せる
取消・日程変更を含め、次の担当と状態を履歴から説明できるかを確認し、次回の投資判断日に見直す。
- 03運用上限
- 連絡と写真は現行運用に残し、顧客画面と請求連携は対象外
受付担当3人はPC、訪問担当5人はタブレットを使う。写真は共有フォルダ、顧客連絡は電話・メールで続け、安全に使うための権限とバックアップは初回に含める。
総額だけで比べない
同じ範囲表で、見積もりの内訳を比べる
各社へ同じ範囲表を渡し、基本範囲、条件付き、対象外を分けた内訳を依頼します。未確定の項目は、何が決まれば金額や期間が変わるかを確認します。
基本範囲
完成条件まで含めて、フェーズ1で実施するもの。
条件付き
データ、外部サービス、仕様の確認後に金額が決まるもの。
対象外
今回の見積もりに含まず、別の判断日に検討するもの。
見積もりを比べるときの三つの質問
- 1
価値・検証・運用の3条件は、各社で同じ内容になっていますか。
- 2
条件付きの項目は、何が決まれば金額と期間を確定できますか。
- 3
追加・変更になる境界と、再見積もりを承認する人は決まっていますか。
見えにくい条件を落とさない
便利な機能と、安全に使うための品質を同じように削らない
便利な通知や詳細レポートは後回しにできても、利用者を制限する仕組み、データを失わない備え、法令や契約上必要な対応まで、見えにくいという理由だけで後回しにはできません。
扱う情報、利用者、外部公開の有無、止まったときの影響を確認し、初回から必要な品質は範囲表へ残します。必要条件はシステムごとに異なります。
今日、10分で始める
まず、誰が何を受け取り、何を返すまでかを書く
次の一文を埋めます。そのあと、何を観測できれば続けるか、初回に引き受ける人手・品質・対象外の上限はどこかを書いてください。
これだけでも、機能一覧のどこが途中で切れているか、開発会社へ何を質問すべきかが見えます。
初回開発の範囲
よくある質問
MVPなら安く作れますか？
MVPは安さを保証する言葉ではありません。利用者、外部連携、データ移行、安全に使うための品質によって費用は変わります。まず、同じ範囲と完成条件を見積もっているかを確かめます。
仕様が全部決まっていなくても相談できますか？
相談できます。空欄は隠さず、誰がいつ決めるかを残します。ただし、一つの仕事の終点、今回の対象外、完成条件まで空欄のままでは、見積もり前提を比べられません。
セキュリティやバックアップは次回でよいですか？
一律に次回へ回せません。扱う情報、利用者、外部公開の有無、止まったときの影響に合わせ、安全に使うため初回から必要な品質を判断します。
最初から例外も全部書くべきですか？
全部を網羅する必要はありません。日常的に起きる例外と、起きると業務を止める例外を代表として入れ、残りは未確定事項として次の判断日に見直します。