MVP を定義してリリースする

この章で学ぶこと：MVP を定義する際の判断基準、リリース直前のチェックリスト、公開後の改善サイクルの回し方を身につける。
なぜ学ぶのか：機能を盛り込みすぎるといつまでも公開できない。MVP で割り切って出し、ユーザーの反応を見て育てる方が結果的に早く良いものになる。
Web 開発のどの領域か：プロダクト設計・リリース戦略。b17〜b20 の総仕上げに位置する。

前提: 応用編（b17〜b23）を読み終え、c01〜c04 でドキュメント・設計・開発フローが整っていること。

所要時間: 大きい（リリース作業そのものに 5〜20 時間）。本章の読解は 45 分。

到達目標: n10u-tech.<自分のドメイン> で sns_clone の MVP が公開され、自分以外の最低 1 名がアクセスできる状態。

MVP とは

Minimum Viable Product（必要最小限の価値を届ける製品）。目指すのは「完成品」ではなく「検証可能な仮説を伴った最小プロダクト」。

sns_clone の例：

フル機能	MVP	MVP 後の追加
投稿・いいね・フォロー・コメント・DM・画像・通知	投稿・いいね・タイムライン表示	コメント → フォロー → 画像 → 通知 → DM
OAuth・2FA・ソーシャルログイン	メール＋パスワードのみ	後から追加
多言語対応	日本語のみ	需要があれば
モバイルネイティブアプリ	Web のみ	PWA → ネイティブ

「これがないと仮説検証できない」機能だけ入れる。「あると便利」は全部削る。

MVP を絞るための 3 つの質問

この機能がないと、核心の体験が成立しないか？
- タイムライン表示：YES（SNS の核）
- コメント：NO（MVP では読むだけでよい）
ユーザーは 5 分以内に「価値」に到達できるか？
- ログイン→タイムライン→投稿の 3 ステップで完結させる
- オンボーディング画面は後回し
クラッシュしたら致命傷か？
- YES のものだけテスト・監視を厚くする
- 他は「壊れたら直す」で割り切る

リリース前チェックリスト

[ ] 本番 URL で HTTPS が有効
[ ] ログイン・ログアウトが動く
[ ] 投稿・いいね・タイムライン取得が動く
[ ] エラーページ（404・500）が用意されている
[ ] DB にバックアップ設定がある（AWS RDS の自動バックアップ）
[ ] エラー監視（Sentry など）が入っている
[ ] 最低限のテストが CI で通っている
[ ] README にセットアップ手順がある
[ ] LICENSE ファイルがある
[ ] .env.example がある（実 .env はコミットしない）
[ ] 秘密情報のリーク確認（git-secrets などで走査）

デプロイまでの手順（AWS 構成）

インフラ構築: b17 で作成した EC2・RDS・CloudFront をセットアップ
ドメイン設定: Route53（または他の DNS）で A レコードを ALB に向ける
HTTPS 証明書: ACM で証明書を発行し、CloudFront に設定
初回デプロイ: CI/CD パイプライン（b19）を走らせて main → EC2 への自動デプロイが通ることを確認
疎通確認: 本番 URL で全画面を開く

公開後の改善サイクル

MVP を出した直後が一番大事。仮説が合っているかを測る。

ユーザー行動の計測: Plausible や Cloudflare Web Analytics（無料・軽量）でページビュー・滞在時間を計測
エラー監視: Sentry で本番エラーをリアルタイム検知
フィードバック経路: 簡単なお問い合わせフォームか、GitHub の issue を公開
次の機能の優先順位: 「よく使われる機能」と「要望が多い機能」は別。データで判断する

よくある詰まりポイント

完璧主義で永遠に公開しない: 6 か月かけても 100 点にはならない。60 点で出して、使いながら 80 点にする。
最初から大規模対応: ユーザー 0 人の段階で「10 万ユーザー捌けるか」を気にしない。無料枠で十分。
モニタリングゼロで放置: 公開したら Sentry とアクセスログは最低限入れる。何が起きたか分からない状態は危ない。
秘密情報のコミット: .env をうっかり push してしまうと、Git 履歴から消すのは極めて面倒。git-secrets や gitleaks を pre-commit に入れる。

おめでとうございます

ここまで来たら、Web エンジニアとして「動くものを自力で公開する」という到達点に立てている。次は公開後の運用・改善を通じて、さらに深い学びに進む。

sns_clone 参考実装

checklist.yml — MVP 完成条件（M1〜M8 機能要求・非機能要求）
README.md — デプロイ手順・AWS 構成の実例

確認クイズ

Q1. MVP に入れるべき機能と、後回しにする機能を判断する最初の問いは何か。

正解: 「この機能がないと、核心の体験が成立しないか？」

解説: 答えが YES のものだけ MVP に入れる。NO は後回し。SNS なら「投稿とタイムライン」がなければ SNS として成立しないので必須、「通知」はなくても成立するので後回しになる。

Q2. 公開直前のチェックリストに「.env.example がある」が含まれる理由は何か。

正解: 別環境（他のマシンや共同開発者の環境）でセットアップする際、必要な環境変数が何かを自明にするため。実際の .env は秘密情報を含むためコミットしない。

解説: README にセットアップ手順があっても、環境変数の key が漏れていると誰もセットアップを再現できない。.env.example は空の値または説明コメント付きで全 key を列挙する。

Q3. MVP を公開した直後に入れるべき監視・計測ツールを 2 つ挙げよ。

正解: エラー監視（Sentry など）とアクセス計測（Plausible・Cloudflare Web Analytics・Google Analytics など）。

解説: エラー監視は「壊れていること」を知るため、アクセス計測は「使われているか・どこで離脱するか」を知るため。どちらも無料枠で始められる。公開後に入れるのではなく、公開前に組み込んでおく。

生きているコード

本ドキュメントで扱ったパターンの完全な動作コードは、メンター側リポジトリの参照ブランチで確認できます。

対応 Week: W20
参照ブランチ:
W20: reference/week-20
対応 checklist 項目: M12

ブランチの作り方・見方は b00-curriculum-map を参照してください。