mvp-architect

MVP アーキテクト - 最小限の実用的な製品のスコープ設定

概要

Hexa の方法論を用いて、核となる仮説を検証するために必要な最小限の製品を、インディー創業者がスコープ設定できるよう支援します。3 か月以内に市場投入を目指します。

Hexa の基本原則：「価値の高い主要機能を備えた MVP を 3 か月以内にリリースしましょう。まだ十分な機能を備えていなくても、明確で分かりやすい機能をそろえてリリースするほうがよいでしょう。」

どんなときに使うか

• 「MVP に何を含めるべきですか」
• 「MVP のスコープ設定を手伝ってください」
• 「どの機能が必要ですか」
• 「まず何を作ればよいですか」
• 「何か月も開発しているのに、まだリリースできていません」

Hexa の 7 つの原則

1. ユーザーの要望の奥を掘り下げる — 表面的な希望ではなく、根本的なニーズを探る
2. 確証バイアスに対処する — 前提に疑問を投げかける
3. 早い段階からデザインパートナーと連携する — 実際のユーザーとともに作る
4. 柔軟に変更できるマイルストーンを優先する — 6 か月の目標と 2 週間のスプリント
5. デザインの前にスケッチする — 検証が済むまでは粗削りなままにする
6. 安定した要素を中心に構築する — 安定した機能だけを含める
7. アーキテクチャを徹底的に検証する — データベース設計はすべてに影響する

簡易ワークフロー

ステップ 1：課題が明確か確認する

• 顧客インタビューを 10 件以上行いましたか？
• 課題を 1 文で説明できますか？
• デザインパートナーが 3〜5 人いますか？

ステップ 2：核となる仮説

We believe that [customer] has a problem with [pain point].
We believe that [solution] will solve this.
We will know we're right when [success metric].

ステップ 3：機能の優先順位付け

各機能について、次の質問をします。

• 核となる仮説を検証するか？ → 残す
• ユーザーから明確に要望されたか？ → 場合による
• クリティカルパスに含まれるか？ → 残す
• 手作業で対応できるか？ → 開発しない

目標：機能は最大 3〜5 個です。

ステップ 4：安定要素のテスト

すべてのデザインパートナーからのフィードバックを経ても安定していた機能だけを開発します。

ステップ 5：ユーザージャーニー（画面 3〜4 枚）

• ユーザーはどのように登録しますか？
• 最初に行う操作は何ですか？
• 核となる価値はどのように提供されますか？
• 成功をどのように確認しますか？

スコープクリープ防止チェックリスト

機能を追加する前に、必ず確認します。

1. 核となる仮説を検証できますか？ → いいえなら、削除します
2. 3 人以上のデザインパートナーから要望されましたか？ → いいえなら、先送りします
3. これがなくてもリリースできますか？ → はいなら、先送りします
4. まず手作業で対応できますか？ → はいなら、開発しません
5. これによってリリースが 3 日を超えて遅れますか？ → はいなら、削除します

「2 週間でリリース」テスト

もし 2 週間以内にリリースしなければならないとしたら、何を削りますか？ 削るものは、今すぐ削りましょう。 それが本当の MVP です。

連携

• idea-validator - スコープ設定の前に検証する
• startup-icp-definer - 対象ユーザーを定義する
• fullstack-workspace-init - コードベースをセットアップする
• brand-architect - 製品の名前とポジショニングを決める

---

仮説フレームワーク、機能の優先順位付けマトリックス、安定要素の特定、画面マッピング、技術アーキテクチャのチェックリスト、タイムラインのテンプレート、出力形式の完全版については、こちらを参照してください： references/full-guide.md