MVPを出した後に何を観察すべきかから、二周目で直面する共通課題まで、全五編にわたって点検してきました。それぞれの記事は個別のテーマとして読んでも成り立ちますが、実際には一つの連続した意思決定のプロセスを扱っています。
この過程を実際に経験したチームは、次の意思決定の場面でまったく違う位置に立ちます。初めて決定を控えるチームは何から把握すべきか迷いますが、一度枠組みを作ったチームはどのシグナルが弱かったか、どの問いで判断が分かれたか、何を優先して検証すべきかをすでに把握しています。決定そのものの結果よりも、決定に至る構造化された進め方自体がチームの資産として残るためです。同じ課題が起きたとき、毎回一から根拠を探すチームと、すでに定めた基準に照らすチームとでは、意思決定にかかる時間から大きな差が出ます。
決定地図
MVP出荷以降の判断は、段階ごとに確認すべき中核の対象が異なります。今、組織がいる段階に合わせて、下の表の項目を確認すれば足ります。
| 段階 | 何を判断するか | 該当編 |
|---|---|---|
| シグナルを読む | 到達・反復・支払い・要望の4つのシグナルで現在のサービス状態を客観的に把握する | 第1部 |
| 分かれ道の判断 | 仮説が妥当で構造も安定していれば拡張、仮説は正しいが構造が限界なら再設計を検討する | 第1部、第2部 |
| 作り直しの要否 | 中核データ、ユーザー種別、中核フローのうち変化した項目数を基準に分ける。0〜1個なら拡張、2個以上なら作り直し | 第2部 |
| 育てる経路 | 弱いシグナルから先に補強し、毎サイクルの30%を技術整備に割り当て、停止シグナルを観察する | 第3部 |
| 作り直す経路 | ユーザー、データ、検証済みの流れは保存し、コードと画面の構造は作り直し、並行運用を図る | 第4部 |
| 共通課題 | ライブ変更の統制、フィードバックのスクリーニング、二周目の工数見積もり、改善を裏づける比較基準、障害対応の最低基準を確立する | 第5部 |
シグナルを読む段階から始めて方向性を定め、その経路の中で優先順位や移行の基準を決めた後、経路にかかわらない共通課題を押さえるという順序です。この段階を飛ばすと、その後に下す意思決定の根拠が揺らぎます。シグナルの分析なしに方向から決めると主観的な感覚に頼ることになり、中核となる基準なしに作り直しに着手すると、何を残し何を捨てるかの明確な指針が失われます。逆に順序を丁寧に踏んだチームは、今の状況に当たる表の欄を確認するだけで次の行動指針をすぐに得られます。
なお、第1部で触れた仮説そのものが妥当でない状況は、この地図の範囲外です。これは開発の方法論ではなく、製品が本来解決しようとする課題そのものを見直すべき、プロダクトマーケットフィットの領域です。
MVP段階を卒業する時点
MVP段階をいつ抜け出すかは、単純なユーザー数や売上規模では決まりません。中核となる基準は、サービスの運用と保守にかかる時間が新機能の開発速度を追い越す瞬間です。障害対応、フィードバック処理、運用に関する問い合わせへの対応にかかる時間が開発リソース全体の半分を超え始めたら、既存のチーム構造だけでは次のサイクルを支えるのが難しいというシグナルです。
この時点は会議の議題の性質に最初に表れます。次のサイクルで出す新機能より、先週起きた障害の原因究明や未処理の要望が会議の優先順位を占め始めたら、すでにMVP段階を越えた状態です。
この時点では、無理な新機能の追加よりチーム内の役割の組み替えが最優先の課題です。これまで個別の担当者や単一のチームが開発と運用を兼ねてきたなら、社内で継続して担当する領域と外部パートナーに委ねる領域を明確に分ける必要があります。役割の構造を整え直さないまま従来の方式を続けると、次のバージョンの製品改善に取り組む時間的な余裕そのものを確保できなくなります。この判断基準は、外注・採用・フリーランス：スタートアップのための開発体制 意思決定ガイド で具体化できます。
判断の枠組みが資産になる理由
MVP以降の意思決定は一度きりのイベントでは終わりません。バージョン2.0を軌道に乗せると3.0を考える時期が訪れ、3.0を越えると4.0の方向性を決める瞬間が続けて訪れます。サービスが存続し成長する限り、この意思決定の枠組みはバージョンごとに繰り返されます。
バージョン2.0を準備する過程で確立した次の要素は、製品の資産として蓄積されます。
- データシグナルを解釈する客観的な基準
- 作り直しの要否を判断する3つの中核となる問い
- デプロイ前にベンチマークの基準値を記録するプロセス
- ユーザーからのフィードバックを一つの窓口で集める仕組み
バージョン3.0を企画するときはこの資産の上から出発するため、同じ意思決定の速度が大きく短縮されます。何を観察すべきか改めて探る時間が減り、集まったデータを即座に照らし合わせる作業に集中できます。指標の抽出方法とフィードバックの分類の仕組みが定まっていれば、一度の会議だけでも明確な戦略の方向を導けます。
一方、毎回その場しのぎの感覚で決めてきた組織は、バージョンが上がっても判断の速度が改善しません。2.0の段階で経験した混乱を3.0でも同じように繰り返し、4.0に至っても初期と同じ試行錯誤を重ねます。判断の枠組みを構造化しないと、バージョンを重ねても常に同じ出発点に戻ることになります。
インテグラビットが1.0の先を共に見る理由
インテグラビットは、バージョン1.0を構築して関係を終える単発のプロジェクト方式を志向していません。リリース後の最初の振り返りでシグナルを一緒に分析し、構造診断を経て作り直しの要否を客観的に判断し、次のバージョンを企画する際もこの決定地図をもとに戦略を練り直します。1.0を一緒に作ったパートナーがその先の段階まで伴走すれば、データ抽出の文脈や過去の判断基準について不要な再説明を繰り返す必要がありません。
この地図が示す方向が拡張であれ再設計であれ、あるいはその先の3.0や4.0であれ、最終的な実行範囲と着手の時期を確定する判断は、依頼する組織自身の主体的な決定によって完成します。
前の記事: どちらを選んでも直面すること：二周目の共通課題
このシリーズで扱ったシグナルと問いを今のサービスに当てはめてみたい場合は、30分の無料相談で一緒に確認できます。