新規サービスを「作って終わり」にせず、価値を届け続けるために押さえるべき原則と実践をフェーズごとにまとめたガイド。
目次
- 0. 全体を貫く原則
- 1. 構想・企画フェーズ
- 2. 要件定義・設計フェーズ
- 3. 開発フェーズ
- 4. ローンチ準備フェーズ
- 5. ローンチ後・グロースフェーズ
- 6. チーム・組織
- 7. よくある失敗パターン
- 8. フェーズ別チェックリスト（要約）
- 参考フレームワーク・キーワード
0. 全体を貫く原則
| 原則 | 意味 |
|---|---|
| 課題から始める | 「何を作るか」より先に「誰のどんな課題を解くか」を明確にする |
| 小さく作って早く学ぶ | 完璧な初版より、検証できる最小の形を早く出す |
| 仮説を明文化する | 前提を言語化し、検証可能な形にしておく |
| 計測できないものは改善できない | 初日から指標とログを仕込む |
| 捨てる判断を恐れない | サンクコストに囚われず、撤退・ピボットの基準を事前に決める |
| 後で変えにくいものだけは慎重に | データモデル・認証・課金・ドメイン名などは初期に丁寧に設計する |
1. 構想・企画フェーズ
1.1 課題とターゲットの定義
- ターゲットユーザーを具体化する：ペルソナより「実在する10人」を思い浮かべられるレベルで
- 課題の深さを確認する：「あったら便利」ではなく「今お金や時間を払って解決している」課題か
- 現在の代替手段を調べる：Excel、手作業、競合サービスなど。代替手段が存在しない課題は、課題自体が存在しない可能性もある
1.2 仮説の整理
以下を1枚にまとめる（リーンキャンバス等が有効）。
- 顧客セグメント
- 課題（上位3つ）
- 提供価値（なぜ既存手段より良いか）
- ソリューションの概要
- 主要指標（何が改善されれば成功か）
- 収益モデル・コスト構造
- 圧倒的優位性（真似されにくい理由）
1.3 顧客検証（作る前に）
- ユーザーインタビュー：最低5〜10人。誘導せず、過去の具体的な行動を聞く（「使いますか？」ではなく「前回それで困ったのはいつ？どうした？」）
- スモークテスト：LP＋事前登録フォームで反応を見る
- コンシェルジュ型MVP：システムを作らず手作業で価値を提供してみる
1.4 成功基準と撤退基準を先に決める
- 例：「ローンチ3ヶ月でWAU 500、4週継続率30%に届かなければ方針転換を検討」
- 基準はローンチ前に関係者で合意しておく（後付けだと甘くなる）
2. 要件定義・設計フェーズ
2.1 MVPのスコープを絞る
- 機能を Must / Should / Could / Won’t（MoSCoW） に分類し、Mustだけで出す
- 「コア体験」を1文で言えるか確認する（例：「3タップで経費申請が終わる」）
- 管理画面・設定画面・多言語対応などは後回しにできることが多い
2.2 ユーザーストーリーと受け入れ条件
- 「〇〇として、△△したい。なぜなら□□だから」の形で書く
- 各ストーリーに受け入れ条件（Done の定義） を付ける
2.3 非機能要件を軽視しない
最低限、以下は初期に決めておく。
- セキュリティ：認証方式、権限モデル、個人情報の扱い
- 可用性：許容できるダウンタイム（SLO）
- 性能：想定ユーザー数・レスポンスタイム目標
- 法令・規約：個人情報保護法、特定商取引法、利用規約・プライバシーポリシー
- バックアップとリカバリ：データ消失時に何時点まで戻せるか
2.4 アーキテクチャの原則
- 最初はモノリスで良い：境界が見えないうちのマイクロサービス化は高コスト
- 退屈な技術を選ぶ：チームが慣れていて、情報が豊富な技術を優先
- マネージドサービスを活用：認証・DB・キュー・メール送信などは自前運用を避ける
- データモデルは丁寧に：後から変えるコストが最も大きい
- ADR（Architecture Decision Record）を残す：なぜその選択をしたかを短く記録
3. 開発フェーズ
3.1 開発基盤（最初の1〜2週間で整える）
- Gitリポジトリとブランチ戦略（トランクベース推奨）
- CI（Lint・テスト・ビルドの自動実行）
- CD（ステージング・本番への自動/ワンクリックデプロイ）
- 環境分離（開発 / ステージング / 本番）
- シークレット管理（環境変数・Secrets Manager。リポジトリに直書きしない）
- Infrastructure as Code（Terraform 等）
- コードフォーマッタ・Linterの統一
- READMEとセットアップ手順（新メンバーが半日で動かせる状態）
3.2 開発プロセス
- 短いイテレーション：1〜2週間スプリント、または継続的フロー
- 小さなPR：レビューしやすく、デプロイリスクも小さい
- コードレビュー：品質と知識共有のため必ず行う
- フィーチャーフラグ：未完成機能を隠したままマージ・デプロイできる
- 定期的なデモ：動くものを関係者に見せてフィードバックを得る
3.3 テスト戦略
- テストピラミッドを意識：ユニット（多）→ 統合（中）→ E2E（少）
- クリティカルパス（登録・ログイン・課金・コア機能）は必ずE2Eで守る
- カバレッジ数値の追求より、壊れると困る箇所を優先
3.4 技術的負債との付き合い方
- 初期の負債はある程度許容してよいが、意図的に借りる（どこを妥協したか記録する）
- スプリントの一定割合（例：15〜20%）を改善に充てる
4. ローンチ準備フェーズ
4.1 計測・分析
- プロダクト分析ツール（主要イベントの設計：登録、コア行動、継続、課金）
- North Star Metric と補助指標の定義
- ファネル（流入 → 登録 → 有効化 → 継続 → 収益 → 紹介）の計測
- ダッシュボード
4.2 運用・監視
- エラー監視（Sentry 等）
- ログ集約・検索
- メトリクス監視とアラート（通知先と対応者を明確に）
- 外形監視（死活監視）
- 障害対応フロー（エスカレーション先、連絡手段、ステータスページ）
- バックアップの復元テストを一度は実施
4.3 セキュリティ・法務
- 脆弱性診断（少なくともOWASP Top 10観点のセルフチェック）
- 依存ライブラリの脆弱性スキャン
- 利用規約・プライバシーポリシー・特商法表記（有料の場合）
- Cookie/トラッキングの同意対応（対象地域による）
- 問い合わせ窓口
4.4 リリース戦略
- 段階的リリース：社内 → クローズドβ → オープンβ → 正式リリース
- カナリアリリース／フィーチャーフラグで影響範囲を限定
- ロールバック手順を事前に確認・リハーサル
- ローンチチェックリストを作り、当日はそれに沿って進める
4.5 Go-to-Market
- ローンチ前からウェイティングリスト・コミュニティを育てる
- オンボーディング（初回体験）を磨き込む：最初の数分で価値を感じられるか
- ヘルプ・FAQ・チュートリアルを用意
- サポート体制（誰がどの窓口で、何時間以内に返答するか）
5. ローンチ後・グロースフェーズ
5.1 学習ループを回す
計測 → 仮説 → 施策 → 検証 → 学び → 次の仮説
- 週次で主要指標をレビュー
- 定性（インタビュー・問い合わせ・レビュー）と定量（データ）を両方見る
- A/Bテストはトラフィックが十分になってから。初期は定性調査の方が効率的
5.2 PMF（プロダクトマーケットフィット）の見極め
- 継続率カーブが横ばいになるか（ゼロに向かって落ち続けないか）
- ショーン・エリス・テスト：「使えなくなったら非常に残念」と答える人が40%以上か
- 自然流入・口コミが増えているか
- PMF前はグロース施策（広告など）に大きく投資しない
5.3 判断のタイミング
事前に決めた基準に照らし、以下のいずれかを選ぶ。
- 継続（Persevere）：指標が改善傾向
- ピボット：課題は正しいが解決策が違う／ターゲットが違う
- 撤退：課題自体が十分に大きくない
5.4 スケールに向けて
- PMF達成後に、パフォーマンス・可用性・組織体制へ投資
- 運用の自動化、オンコール体制の整備
- 先送りした技術的負債の返済計画
6. チーム・組織
- 小さく自律したチーム：意思決定を速くするため、最初は少人数・多能工で
- 役割を明確に：プロダクトの意思決定者（PdM/PO）を一人に定める
- 目的の共有：「なぜ作るのか」を全員が説明できる状態
- ドキュメント文化：決定事項・背景を書き残す（口頭だけで終わらせない）
- ふりかえり：スプリントごとにKPT等で改善
- 心理的安全性：悪いニュースが早く上がってくるチームにする
7. よくある失敗パターン
| 失敗 | 対策 |
|---|---|
| 誰も欲しくないものを作る | 作る前に顧客検証。インタビューとスモークテスト |
| 機能を詰め込みすぎてローンチが遅れる | MVPスコープを厳格に。期日を先に決める |
| 計測を後回しにして何も分からない | ローンチ前にイベント設計とダッシュボード |
| 過剰な設計（最初からマイクロサービス等） | モノリス＋マネージドサービスで始める |
| 障害時に誰も対応できない | 監視・アラート・対応フローを事前整備 |
| 撤退判断が遅れる | 成功・撤退基準を事前に合意 |
| ステークホルダーとの認識ずれ | 定期デモと意思決定の記録 |
| PMF前に広告で集客し、穴の空いたバケツになる | 継続率を先に改善する |
8. フェーズ別チェックリスト（要約）
構想
- ターゲットと課題が具体的に言語化されている
- 5人以上にインタビューした
- 仮説がリーンキャンバス等にまとまっている
- 成功・撤退基準が合意されている
設計
- MVPのスコープがMustのみに絞られている
- 非機能要件（セキュリティ・可用性・法令）が整理されている
- 主要な技術選定がADRに記録されている
開発
- CI/CDが動いている
- 環境が分離されている
- クリティカルパスにテストがある
ローンチ
- 計測・ダッシュボードが準備済み
- 監視・アラート・障害対応フローがある
- 規約類・問い合わせ窓口がある
- ロールバック手順を確認済み
ローンチ後
- 週次で指標レビューをしている
- ユーザーの声を継続的に収集している
- 判断基準に照らして継続/ピボット/撤退を検討している
参考フレームワーク・キーワード
- リーンスタートアップ（Build-Measure-Learn）
- リーンキャンバス
- Jobs to be Done
- AARRR（海賊指標）
- North Star Metric
- MoSCoW 分析
- ADR（Architecture Decision Record）
- SLO / SLI
- DORA メトリクス（デプロイ頻度、変更リードタイム、変更失敗率、復旧時間）