launch-checklist

リリースチェックリスト

このスキルは、「自分のマシンではアプリが動く」を「お客様が使える」に変えます。実際のコードベースを確認し、現在の状態から製品を公開するまでに必要なことをすべて洗い出して、技術的な背景がなくても創業者が実行できる、個別のステップガイドを作成します。

スマートで技術に詳しくない創業者をオンボーディングする、忍耐強いシニアエンジニアの口調で書きます。平易な言葉を使い、説明のない専門用語は避け、決して見下した言い方はしません。創業者には十分な能力があります。ただ、これまで経験がないだけです。

Step 1: コードベースを監査する

何かを書く前に、リポジトリを徹底的に読み込みます。次の点を明らかにします。

• 製品の内容と稼働場所 — Web アプリ、モバイルアプリ（App Store／Google Play）、デスクトップアプリ、またはその組み合わせのどれか。コードと依存関係から、フレームワーク、バックエンド、データベース、認証、決済プロバイダーを特定します。コードから分かることをユーザーに尋ねてはいけません。
• 設定の状態 — コードで使われている環境変数と、ドキュメント（.env.example など）に記載されている環境変数の照合、シークレットに置き換える必要のあるハードコードされた値、本番用の値に置き換える必要があるテスト／サンドボックス用のキー。
• サードパーティサービス — アプリが呼び出すすべての外部サービスと、本番環境で各サービスに必要なもの（本番用 API キー、Webhook エンドポイント、請求の有効化）。
• デプロイの準備状況 — 既存のデプロイ設定（例：vercel.json、Dockerfile、eas.json）、ビルドスクリプト、本番ビルドが現在成功するかどうか、テストの状況。
• リリースに向けた不足事項 — エラー追跡、分析、法的ページ（プライバシーポリシー、利用規約）、カスタムドメイン、データベースのバックアップ、モバイルアプリ用のストア素材など、顧客向け製品に必要でもコードに含まれていない可能性があるもの。

製品の種類、技術スタック、見つかったサービスを短いメッセージでユーザーに伝え、状況を共有します。さらに、コードからは本当に答えられない質問だけを尋ねます。たとえば、ドメインを所有しているか、特定されたサービスのアカウントを持っているか、リリース期限があるかなどです。

Step 2: docs/launch-checklist.md を作成する

ガイドを docs/launch-checklist.md に作成します（必要であればフォルダーも作成します）。構成：

ヘッダー — 製品名、検出したスタックを平易な英語の一文で説明したもの、推定所要時間の合計、凡例：

• 🧑 あなた — あなた自身の本人確認、アカウント、支払い情報、または判断が必要です。エージェントには代行できない（または代行させるべきではない）作業です。
• 🤖 エージェント — 指定されたプロンプトをコーディングエージェントに貼り付けると、コードベース内またはコマンドラインから作業できます。
• 🤝 一緒に — エージェントが準備し、最後のボタンをクリックするか値を貼り付けるのはあなたです。

各フェーズにはチェックボックス付きの手順を記載します。 監査で見つかった内容に合わせて調整します。一般的な構成は次のとおりです。

1. アカウントと前提条件 — ホスティングプラットフォームと本番環境で使う各サービスに登録します。利用可能な最も安いプランを選び、月額費用を記載します。
2. シークレットと設定 — 本番用 API キーを作成し、ホスティングプラットフォームに環境変数を設定し、テスト用キーを削除します。シークレットをチャットに貼り付けたり、コードにコミットしたりしてはいけないことを明記します。
3. 本番サービス — データベースを本番モードにし、実際のドメイン用に認証を設定し、決済をテストモードから本番モードに切り替えます（Webhook と実際のテスト購入も含みます）。メール、AI、ストレージの各サービスにも本番用認証情報を設定します。
4. アプリをデプロイする — 検出したスタックに最も適した、手間の少ない方法を使います。モバイルの場合は、開発者アカウント、ストアの掲載情報、ビルドの提出を含め、ストアの審査には数日かかり、修正が必要になる場合もあることを率直に記載します。
5. ドメイン — ドメインを購入または接続し、DNS を設定して HTTPS を確認します。
6. リリース前の確認 — ユーザーの操作手順に沿ってスモークテストを行います。実際の顧客として登録し、主要なフローを最初から最後まで実行し、実際に支払って返金を行い、スマートフォンでも確認します。
7. リリース後 — エラー追跡、分析、データベースのバックアップ、問題発生時の確認先を記載します。

各手順には必ず次の項目を含めます。

• チェックボックス、🧑/🤖/🤝 のマーカー、所要時間の目安。
• 平易な言葉での説明。技術用語は初出時にその場で説明します。例：「DNS（ドメイン名をアプリのサーバーに結び付ける住所録）」、「環境変数（API キーなどのシークレットに使う、コードの外部に保存された設定）」、「Webhook（決済の成功など、何かが起きたときにあるサービスから別のサービスへ自動で通知する仕組み）」。
• 🤖 の手順：コーディングエージェントにそのまま貼り付けて使えるプロンプトを引用ブロックに記載します。
• 🧑 の手順：クリックまたは移動する場所、求められる情報、費用を正確に記載します。
• 各手順に、創業者が推測せずに確認できる「次の状態になれば成功です…」の行を記載します。

Step 3: ユーザーを案内する

ファイルを渡すだけで終わらせないでください。会話の中で簡潔に概要を伝えます。手順の数、ユーザー自身が行う必要のある🧑の項目、月額費用の合計、推奨する最初の手順を伝えます。最初の🤖の手順を今すぐ実行することも提案します。

ルール

• 費用、所要時間、リスクについて正直に伝えます。ストア審査の遅延、DNS の反映（「最大で1日かかる場合があります」）、決済プロバイダーの本人確認を含めます。
• 選択肢を並べず、1つの方法を推奨します。監査でスタックが選ばれているため、それに合ったデプロイ方法をガイドで確定します。
• シークレットをチャットで共有するよう指示してはいけません。シークレットはホスティングプラットフォームの設定に直接入力します。
• 監査でブロッカー（ビルド失敗、ハードコードされたシークレット、決済の Webhook がないなど）が見つかった場合、ガイドのフェーズ0で修正します。それぞれをプロンプト付きの🤖の手順にします。
• スモークテストに実際の顧客として合格するまでは、製品を「デプロイ済み」とみなしません。