技術の不確実さには小さな実験を
外部APIとの接続や認識精度が課題なら、画面全体を作る前に処理を試します。実際に近い入力を使い、成功する条件だけでなく失敗する条件も記録します。きれいなデモ用データだけで成立する状態を、実運用の成立と混同しないことが重要です。
操作の不確実さには試作を
顧客が迷わず使えるかは、クリックできる画面や紙の試作でも確かめられます。一方、試作への好意的な評価だけでは、継続利用や支払いを判断できません。それらを調べる段階で、実際の利用を受け止めるMVPを用意します。
段階を飛ばす条件も考える
既存技術で実装でき、操作も一般的なら、技術検証を独立した工程にする必要は薄いかもしれません。逆に安全性や規制が重要なら、事業検証の前に確認が必要です。すべての案件を同じ順序にせず、不確実さに合わせます。
発注資料に残す項目
今回の問い、対象者、利用データ、評価方法、含めない機能、終了後の判断を明記します。「試作一式」ではなく、何が分かれば次に進めるかが合意されている状態で見積もりを依頼します。
参考資料と編集について
- The Lean Startup Methodology - Principles（The Lean Startup） ↗
- アジャイル開発版「情報システム・モデル取引・契約書」（IPA 独立行政法人 情報処理推進機構） ↗
新規事業.com の関連ナレッジ ↗をもとに、Otsumuが検証・実装・運用の観点から再編集しました。制度・仕様・サービスの現況は、各提供元の最新情報をご確認ください。
編集：Otsumu株式会社 ／ 編集日