feature-launch-playbook

機能ローンチの実践ガイド

機能をただ出荷するだけでなく、うまくローンチするための、経験豊富なプロダクトマネジメントリーダーによる実践ガイドです。

多くのチームは、出荷、リリース、ローンチを混同しています。出荷とは、エンジニアリング作業が完了することです。リリースとは、たとえフラグによって1％のユーザーに限定されていても、ユーザーがアクセスできる状態になることです。ローンチとは、ポジショニング、社内の認識合わせ、顧客とのコミュニケーション、営業支援、サポート体制の準備、段階的な展開戦略、モニタリング、リリース後の効果測定を通じて、「機能が存在する」状態を「機能がユーザーに届く」状態へ変える取り組みです。

ローンチせずに出荷した機能は、同じだけのエンジニアリング投資が必要でありながら、その価値のほんの一部しか得られません。営業はどう売ればいいかわかりません。サポートはどう支援すればいいかわかりません。顧客はその存在に気づきません。誰も機能の存在を知らないため、動かすはずだった指標も動きません。

このスキルは、実務で使えるプレイブックです。すでに仕様書を作成し（pm-spec-writing）、ロードマップに優先順位を付けて組み込み（roadmap-planning）、計測のための計装を済ませ（product-analytics-setup）、必要に応じてテストも済ませている（experiment-design）ことを前提とします。次の取り組みがローンチです。適切なコンテキストとともに、適切なユーザーに実際に機能を届け、効果があったかどうかを測定できるようにする方法を扱います。

このスキルを使う場面：規模や対象セグメントを問わずローンチを計画するとき、既存のローンチプロセスを監査するとき、「出荷したのに指標が動かなかった」という問題を解決するとき、チーム向けのローンチチェックリストを作成するときです。

---

このスキルの目的

このスキルでは、ローンチ実務を幅広く扱います。プロダクト関連スキルの一連の内容と連携します。

• pm-spec-writingでローンチの仮説を定義し、このスキルでその仮説を検証します。
• roadmap-planningから、ローンチの背景（それまでに何があり、この先に何があるのか）を把握できます。
• product-analytics-setupは計装の前提条件です。これがなければローンチの効果を測定できません。
• experiment-designとdata-warehouse-experimentationで、ローンチがうまくいったかをテストする方法を得られます。
• feature-flaggingから、このスキルが依存する段階的な展開の基盤を得られます。

このスキルでは、価格設定の決定、ブランドキャンペーン、GTM戦略全体は扱いません。これらにはマーケティングチームとの連携が必要です。このガイドは、エンジニアリングとプロダクトの側に向けた、PMの実務用プレイブックです。

対象者は幅広く、すべてのPMが機能を出荷し、少なくとも一度はローンチに失敗した経験があり、最悪の失敗を繰り返さないためのチェックリストから恩恵を得られます。このガイドは、経験豊富なPMリーダーからPMに向けた、具体的で明確な意見を持ち、各段階で重要な取り組みについて率直に語る内容です。

---

出荷、リリース、ローンチの違い

最も重要な違いです。3つの定義を紹介します。

出荷とは、エンジニアリングが作業を完了することです。コードが本番環境にデプロイされています。ユーザーはまだアクセスできないか、フラグを通じて内部ユーザーのみがアクセスできる状態です。PRがマージされ、デプロイされています。

リリースとは、ユーザーがアクセスできる状態にすることです。1％へのロールアウトの場合も、100％の場合もあります。技術的な意味で、機能が「稼働中」になっています。少なくとも1人のユーザーに対してフラグがオンになっています。

ローンチとは、ポジショニング、社内調整、顧客向けコミュニケーション、営業支援、サポート体制の準備、ロールアウト戦略、モニタリング、ローンチ後の効果測定がすべて進行中であることです。この機能から恩恵を受ける人々に、活用に必要な背景情報とともに紹介されています。

よくある問題。PMは、エンジニアリングが作業を完了しただけなのに、「機能Xを出荷しました」と報告します。機能はユーザーの1％にリリースされているかもしれませんが、告知も、ドキュメントも、営業支援も、測定計画もありません。価値獲得の観点では、これはローンチされていない機能です。

規律。正確な用語を使いましょう。「火曜日にエンジニアリングが出荷しました。木曜日に25％へリリースします。来月、一般公開でローンチします。」用語を正確に使うことで、何が起きていて、何がまだ起きていないのかを正直に把握できます。

「機能が失敗した」という診断の多くは、実際には「機能がローンチされていなかった」ということがわかります。このスキルはローンチの側面を中心に構成されています。多くのチームが最も投資を怠っている領域だからです。

---

ローンチのティア

すべての機能に完全なプレイブックが必要なわけではありません。機能に応じて取り組みを調整しましょう。

ティア1（全面的なローンチ）。 新規プロダクト、プロダクトの訴求内容を大きく変える主要機能、価格変更、互換性を破る変更。完全なプレイブックを適用します。ポジショニング、すべてのコミュニケーションチャネル、営業支援、カスタマーサクセス向け説明、専用のローンチ後測定、経営陣による発表を含みます。

ティア2（重点的なローンチ）。 ユーザー価値や競争上のポジショニングに実質的な影響を与える、有意義な改善。プレイブックの一部を適用します。アプリ内コミュニケーション、ブログ記事またはリリースノート、サポート体制の準備、ロールアウト戦略、ローンチ後の測定を含みます。

ティア3（リリースノート）。 段階的な改善、価値を高めるバグ修正、品質向上。最小限の対応とします。変更履歴への記載、リリースノート、軽いモニタリングを行います。

どちら側にも落とし穴があります。

• すべてのリリースをティア1として扱うと、コミュニケーション疲れが生じます。顧客は大量の告知に反応しなくなり、本当のティア1ローンチも雑音に埋もれてしまいます。
• すべてのリリースをティア3として扱うと、ローンチされない機能が生まれます。機能を出荷しても指標は動かず、チームは「ユーザーはこれを求めていない」と結論づけますが、実際の原因は「ユーザーに知らされていなかった」ことです。

機能に応じてティアを選びましょう。このスキルは主にティア1とティア2を扱います。ティア3で中心となるのは変更履歴の運用規律です。ローンチプレイブックを適用しますが、変更履歴への記載と軽いモニタリングに簡略化します。

詳細はreferences/launch-tier-decision.mdをご覧ください。

---

公開前：ポジショニング

ポジショニングでは、誰を対象としているのか、どのような問題を解決するのか、なぜ今なのか、ユーザーにどのような価値を約束するのかを明確にします。

ポジショニングキャンバス。コミュニケーションの原稿を作成する前に、1ページにまとめて記入します。

• 対象ユーザー。 セグメント、役割、達成すべき業務。営業担当者が顧客像を一文で説明できるほど具体的にします。
• 解決する問題。 ユーザーの言葉で具体的に記述します。「生産性を向上させる」ではなく、「1日に200件のチケットを振り分ける必要があるカスタマーサポートマネージャーは、1件ずつ開かないと緊急のチケットを見分けられない」のように記述します。
• 現在の代替手段。 これがない場合に、ユーザーが今どうしているかを記述します。現状こそが実際の競合です。
• ユーザーに伝わる約束。 一文で記述します。ユーザーが実際にこの機能に触れたときに耳にする約束です。
• 裏付けとなるポイント。 具体的な機能や成果を3～5個記述します。形容詞ではなく、具体的に示します。
• ポジショニングの対象外。 これは何ではないのか、何を目指していないのかを示します。過剰な約束を防ぎます。

ポジショニングで最もよくある失敗は、対象ユーザーが曖昧なことです。「PM向け」は対象ユーザーではありません。「エンジニアリング部門とカスタマーサクセス部門をまたぐロードマップの議論を調整する必要がある、顧客数50～500社のB2B SaaS企業のPM向け」は対象ユーザーを明確にしています。ここまで具体的にすることで、営業、マーケティング、サポートが、誰を対象としているのかを共通の言葉で話せるようになります。

詳細は references/positioning-canvas.md を参照してください。

---

公開前：社内での認識合わせ

公開前に把握しておく必要のあるステークホルダーです。

• エンジニアリング部門のリーダー。 追加対応、サポートへのエスカレーション、公開後の修正に対応できる体制。
• 営業部門のリーダー。 売上予測の更新、商談のコーチング、パイプラインへの影響。
• カスタマーサクセス部門のリーダー。 顧客への事前通知、リスクのある商談の維持、拡大に向けた対話。
• マーケティング部門のリーダー。 有料広告の調整、ブログの投稿カレンダー、ソーシャルメディアでの発信時期。
• サポート部門のリーダー。 トレーニング、FAQ、エスカレーション経路。
• エグゼクティブスポンサー。 状況の把握、対外向けメッセージ、投資家や取締役会への報告。

守るべき手順は、公開の2～4週間前（Tier 1）または1週間前（Tier 2）に、社内向けのローンチブリーフを1つ作成して配布することです。ブリーフには、1ページの概要、FAQ、すでに決定した事項の意思決定ログ、ローンチカレンダーを含めます。「このローンチによって、自分は何を変える必要があるのか」という問いに答えられる内容にします。

社内での認識合わせで最もよくある失敗は、営業部門に知らせずに公開することです。営業部門が顧客からの問い合わせで初めて知ることになります。これでは次回のローンチに向けた信頼が損なわれます。対策はローンチブリーフに加えて、顧客向け公開の1～2週間前に営業部門向けの説明会を行うことです。

詳細は references/internal-alignment-checklist.md を参照してください。

リリース前：顧客コミュニケーション計画

チャネルと判断基準。

• アプリ内。 アクティブユーザーへのリーチが最も高く、プロダクト内の機能に適しています。ツールチップ、バナー、モーダル。
• メール（トランザクションメールまたはキャンペーンメール）。 アクティブユーザーと非アクティブユーザーの両方に幅広くリーチでき、既存のワークフローに影響する重要な変更に適しています。
• ブログ記事。 SEO、リード獲得、ストーリーの発信に役立ち、外部向けのストーリーがある Tier 1 のローンチに適しています。
• リリースノート。 見つけやすく、保存され、検索可能です。Tier 2 以上のすべてに適しています。多くの場合、後から顧客が見つける正式なリファレンスになります。
• ソーシャル（LinkedIn、X、Bluesky）。 既存顧客以外にもリーチでき、ローンチに外部向けのストーリーや競争上の切り口がある場合に適しています。
• ウェビナーまたは顧客との通話。 エンタープライズ顧客に詳しい情報を届けられ、顧客に重大な影響を与える Tier 1 に適しています。
• 営業主導の説明会。 主要アカウントに個別対応でき、ローンチが価格設定、契約、または戦略的なポジショニングに影響する場合に適しています。

各チャネルについて、誰が草案を作成するか、誰が承認するか、いつ実施するか、行動喚起の内容を決めます。

コミュニケーションカレンダーのパターン。すべてのチャネルと日付をまとめた単一のドキュメントを作成し、社内向けローンチブリーフで共有します。「営業への説明前にブログ記事が公開されてしまった」という事態を防げます。通常は、営業への説明、サポート担当者のトレーニング、カスタマーサクセスによる主要アカウントへの連絡、一般向けの告知の順に進めます。

詳細は references/customer-comms-playbook.md をご覧ください。

---

リリース前：営業支援（B2B）

B2B プロダクトでは、Tier 1 と大半の Tier 2 のローンチに営業支援が不可欠です。成果物は以下のとおりです。

• 1 ページのバトルカード。 ポジショニング、ターゲット顧客、主な反論、裏付けとなる実績をまとめます。営業担当者が 2 分で読み、5 分で機能を提案できる内容にします。
• デモスクリプトと録画デモ。 営業担当者が顧客に対して実施できる、再現性のあるデモを用意します。録画版は、ローンチ後に加わった営業担当者向けの代替手段になります。
• 価格変更のドキュメント（該当する場合）。明確なガイダンスがなければ、営業担当者は価格に関する質問に正確に答えられません。
• 商談支援ガイド。 どの商談を前進させ、どの商談を複雑にするのかを記載します。必要に応じて、具体的な主要アカウントも明記します。
• 社内トレーニングセッション（ライブまたは録画）と、アーカイブされた Q&A。営業担当者が機能を顧客に紹介する前に、質問できる機会が必要です。

「シャドーローンチ」の失敗例。機能がリリースされ、営業担当者はプロダクトチームの Slack でそのことを知ります。バトルカードはなく、営業担当者は機能を無視するか、顧客に誤った説明をします。実態と異なる形で機能を約束したため、顧客が解約します。

B2C および PLG のプロダクトでは、このセクションはほとんど適用されません。ユーザー自身が購入者であり、営業活動がないためです。こうした状況の PM が必要な取り組みを見落としていると感じないよう、その旨を明記してください。

詳細は references/sales-enablement-template.md をご覧ください。

---

リリース前：サポート体制の準備

新機能の障害や問題に最初に直面するのは、サポートであることがよくあります。必要な準備は以下のとおりです。

• トレーニング（ライブまたは録画）と Q&A。営業トレーニングと同じ内容を、サポートのワークフローに合わせて調整します。
• FAQ ドキュメント。リリース時点で判明している質問、制限事項、バグをまとめます。最初の 1 週間は、新たな質問が出るたびに毎日更新します。
• エスカレーション経路。エンジニアリングまたは PM の対応が必要な問題について、担当者と対応時間の目安を明記します。
• 監視へのアクセス権、またはアクセスを依頼する手段。サポート担当者が顧客の問題が機能固有のものかを確認できるようにします。

この取り組みの原則は、サポートチームの戸惑いはテスト顧客の戸惑いと同じだということです。サポートが機能を理解していなければ、顧客も理解できません。顧客向けのローンチ告知を出す前に、サポート担当者をトレーニングしてください。

詳細は references/support-readiness-checklist.md をご覧ください。

---

ローンチ当日：展開戦略

機能の種類に応じて選べる、よくある4つのパターンです。

一斉展開（ビッグバン方式）。 1回のデプロイで、展開率を0％から100％にします。告知と展開を同時に行うマーケティング主導のローンチに適しています。バグが多くの顧客に影響する可能性がある場合は、リスクが高くなります。使用は控えめにします。

段階的な割合での展開。 数時間から数日かけて、展開率を1％、10％、25％、50％、100％と上げ、各段階で監視します。ほとんどの機能ローンチに適しており、変更する理由がない限り、これをデフォルトとします。

フラグで制御するコホート別展開。 特定のユーザーセグメントを対象にします。まず無料プラン、次に有料プラン。まず小規模アカウント、次にエンタープライズアカウントという順です。コホートごとにリスク特性が異なる機能に適しています。

段階的なローンチ（複数週間）。 一部のユーザー、地域、または顧客を対象にローンチし、フィードバックを集めて改善した後、対象を拡大します。ユーザーの反応に関する不確実性が高いTier 1ローンチに適しています。

判断の枠組みは、機能の影響範囲の大きさ、正しく動作する確信度、外部への約束を組み合わせて考えます。

• 影響範囲が大きく、確信度が低く、外部への約束がない場合：段階的なローンチ。
• 影響範囲が小さく、確信度が高く、外部向けのローンチ日が決まっている場合：一斉展開。
• その中間（ほとんどのローンチ）：段階的な割合での展開。

詳細はreferences/rollout-strategy-patterns.mdをご覧ください。

---

ローンチ当日：モニタリング

ローンチ前に、監視する項目とアラートの条件を定義します。一般的な指標は次のとおりです。

• エラー率。 全体および機能固有のエラー率。
• レイテンシ。 全体および機能固有のレイテンシ。
• 機能の利用率。 使うべき人が実際に使っているか。
• ファネルの完了率。 ユーザーが新しいフローを完了するか。
• サポートチケットの件数。 特に、機能固有のタグが付いたチケット。
• 顧客満足度を示すシグナル。 NPSのコメントやフィードバックウィジェットへの投稿。

ロールバックのトリガーを、ローンチ前に明確に定義します。例：

• 「エラー率が1％を超えた状態が5分間続いた場合、ロールバックを開始する。」
• 「最初の1時間に機能についてのサポートチケットが50件を超えた場合、エスカレーションを開始する。」
• 「いずれかのコホートでファネル完了率がローンチ前のベースラインの50％を下回った場合、展開を一時停止する。」

「ロールバックのトリガーがない」ことで起きる問題です。ローンチに問題が発生しても、チームがロールバックすべきか1時間議論するうちに、問題が悪化します。トリガーを事前に定義しておけば、議論をなくせます。ルールが自動的に作動し、チームはロールバックを実行します。

詳細はreferences/monitoring-readiness-checklist.mdをご覧ください。

---

ローンチ当日：コミュニケーションの実行

顧客向けコミュニケーションのセクションで作成したカレンダーに従い、ローンチ当日に各施策を実行します。各チャネルの担当者、時刻、順序を明確にします。

• 展開率がX％に達したら、アプリ内バナーを表示します。
• 4時間の安定性確認を終えてから、メールを送信します。
• 社内で告知した時刻にブログ記事を公開します。
• 公開向けのコミュニケーションの1日前に、営業チーム向けの説明を行います。
• ローンチの1週間前に、サポートチームのトレーニングを行います。

「コミュニケーションの連携ミス」で起きる問題です。予定時刻にブログ記事が自動公開されますが、その2時間前に問題が起きて展開が一時停止されていました。顧客は記事のリンクをクリックしても、フラグで利用を制限された機能にアクセスできません。顧客の信頼を損ない、ローンチのストーリーが崩れます。

解決策です。外部向けのコミュニケーションは手動で実行し、展開の健全性チェックを通過した場合にのみ実施します。カレンダーの時刻はあくまで予定時刻です。実際の実施は、展開が健全性チェックに合格することを条件とします。

---

リリース後：仕様の仮説に照らした測定

仕様書（pm-spec-writing に従って作成）には、その機能によって何が変わるのかについて、明示的な仮説を記載しておく必要があります。リリース時の測定計画では、それぞれの仮説が検証されたか、否定されたかを確認します。

測定する4つの側面。

1. 採用。 適切なユーザーが実際に利用したでしょうか。リーチに関する問いです。対象セグメントに機能が認知され、試されているでしょうか。
2. エンゲージメント。 試したユーザーは再び利用したでしょうか。定着度に関する問いです。初回利用は必要ですが、それだけでは十分ではありません。
3. 成果。 仕様書で変化すると想定した指標は、実際に変化したでしょうか。効果に関する問いです。仕様書で立てた仮説を検証します。
4. 副作用。 変化する想定ではなかったほかの指標が変化したでしょうか。安全性に関する問いです。機能がうまく動作していても、ほかの何かに悪影響を及ぼすことがあります。

測定期間。ほとんどのリリースでは、エンゲージメントの兆候を把握するためにリリース後2〜4週間、成果の兆候を把握するために4〜8週間分のデータが必要です。成功か失敗かを早まって判断しないでください。

「測定計画がない」ことによる失敗。機能をリリースすると、チームは次の仕事に移ります。6か月後には、うまくいったのか誰も分かりません。その機能は保守負債となり、チームはさらなる投資を判断できなくなります。

詳しくは、references/post-launch-measurement-framework.md を参照してください。

---

リリース後：改善とフォローアップ

リリース後の最初の4週間は、次のようなことが起こると想定してください。

• QA や限定的な展開では見つからなかったバグが見つかります。
• ユーザーリサーチでは把握できなかったユーザビリティの問題が明らかになります。
• 想定していなかったコホートで、採用が目標を下回ります。
• 関連する機能のリクエストが寄せられます。

取り組み方。すべての問題を記録し、毎週トリアージを行い、当初の測定計画に照らして修正の優先順位を付けます。

採用が目標を下回っている場合、問うべきはその原因です。マーケティングの問題でしょうか（ユーザーが機能を知らない）？ユーザビリティの問題でしょうか（ユーザーが機能を試すものの、すぐに離れてしまう）？価値の問題でしょうか（ユーザーが機能を試しても、価値を感じない）？対象セグメントの誤りでしょうか（想定していたユーザーが実際の対象ではなかった）？

原因ごとに、必要な修正は異なります。

• マーケティングの問題：告知を増やす、繰り返し告知する、営業を通じて再び働きかける。
• ユーザビリティの問題：デザインまたはオンボーディングを修正する。
• 価値の問題：機能を再設計する、または位置付けを見直す。
• 対象セグメントの誤り：告知の対象を別のオーディエンスに変更する。

「勝利宣言をした」ことによる失敗。リリース1週目に指標が目標に達します（多くの場合、リリース告知による急増が原因です）。チームは次の仕事に移り、4週目には指標が基準値まで戻ります。リリースは成功と報告されましたが、機能は実際には定着していません。

対策。リリース週の急増ではなく、リリース後の安定した推移に基づいて成功か失敗かを判断します。成功か失敗かを確実に判断するには、ほとんどのリリースで少なくとも4週間の安定した推移が必要です。

---

よくある失敗パターン

機能のローンチでは、12 のパターンが繰り返し発生します。詳細は references/common-launch-failures.md をご覧ください。

• 「リリースしたのに何も起きなかった。」ローンチされていない状態です。コミュニケーション計画も、社内の連携も、効果測定もありません。
• 「営業が混乱して、間違った売り方をしている。」営業支援がありません。バトルカード、デモ、トレーニングが省略されたか、準備不足でした。
• 「サポートが対応しきれない。」トレーニングも FAQ もありません。顧客から問い合わせがあったとき、サポート担当者は初めてその機能に触れています。
• 「ロールアウトした直後に、すぐロールバックすることになった。」ロールアウト戦略もヘルスチェックもありません。一斉に本番環境へデプロイした結果、障害が発生しました。
• 「ブログ記事を公開したのに、機能が壊れている。」コミュニケーションの失敗です。コミュニケーションの実施が、ロールアウトの正常性を条件としていませんでした。
• 「1 週目の利用は好調だったのに、今は横ばいです。」ローンチ直後の急増だけを見て成功と判断しました。指標はベースラインに戻りました。
• 「うまくいったのかどうかわからない。」仕様の仮説に結び付いた効果測定計画がありません。
• 「顧客から、何も知らされていなかったと言われた。」コミュニケーションが適切なセグメントに届きませんでした。メールはアクティブユーザーだけに送られ、非アクティブユーザーには通知されませんでした。
• 「エンタープライズ顧客が知ったのは、アカウントマネージャー経由で 3 日も遅れてからだった。」コミュニケーションにハイタッチ層向けの対応がありません。主要アカウントには、一般向けの告知より前に、営業主導の説明を行うべきです。
• 「指標が動いたけれど、実際には同じ週の別のローンチが原因だった。」影響を切り分けていません。このローンチと、同時期に行われた別の変更のどちらが指標の変動をもたらしたのか、特定できません。
• 「間違った機能をローンチしてしまった。」ポジショニングが不明確です。顧客が期待していたものとリリースしたものが異なり、機能自体は動作していても、期待と現実のギャップによってローンチが失敗したように見えます。
• 「機能は動作したのに、社内では誰も知らなかった。」社内の連携がありません。営業は商談でこの機能を活用できず、カスタマーサクセスは、この機能で解消できるようになった課題が原因で解約しようとしていたアカウントを引き留められませんでした。

---

フレームワーク：実際のローンチに必要な 12 の検討事項

ローンチを計画する際は、次の 12 項目を確認してください。いずれかを省くと、上記の失敗パターンのどれかにつながります。

1. ローンチのティアを決めます。 ティア 1、ティア 2、またはティア 3。機能に応じた労力をかけます。
2. ポジショニングを定めます。 対象ユーザー、課題、約束、裏付けとなる根拠、アンチポジショニング。
3. 社内で連携します。 ローンチの概要を 1 つにまとめ、ローンチの 2〜4 週間前に関係者へ共有します。
4. 顧客向けのコミュニケーションを計画します。 チャネルの組み合わせ、スケジュール、担当者、実施条件。
5. 営業を支援します。 バトルカード、デモ、トレーニング、商談コーチング（B2B のみ）。
6. サポートの準備を整えます。 トレーニング、FAQ、エスカレーション経路、モニタリングへのアクセス。
7. ロールアウト戦略を選びます。 一斉展開、段階的展開、フラグによる制御、またはフェーズ分け。
8. モニタリングを定義します。 指標、アラート、ロールバックのトリガー。事前に定義し、その場で決めないようにします。
9. コミュニケーションの実施順序を決めます。 ヘルスチェックを実施条件とします。ロールアウトが一時停止されている場合に、自動で配信してはいけません。
10. 効果測定を仕様の仮説に結び付けます。 採用、エンゲージメント、成果、副作用。
11. ローンチ後に改善を続けます。 毎週トリアージを行います。マーケティング、ユーザビリティ、価値、セグメントに関する問題を区別します。
12. 安定した傾向に基づいて成功または失敗を判断します。 ローンチ週の急増だけで判断しません。

このフレームワークの成果物は、ローンチ計画書です。ポジショニングキャンバス、社内向けローンチ概要、コミュニケーションカレンダー、ヘルスチェックの実施条件を含むロールアウト戦略、ロールバックのトリガーを含むモニタリング仕様、仕様の仮説に結び付いたローンチ後の効果測定計画をまとめます。計画はローンチの 2 週間前にレビューし、ローンチ日までに不足を補います。

---

必要なデータを入手できない場合

このスキルの出力は、このスキルだけでは生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースを利用できない、あるいは検証できない場合、認められる出力は、何が必要だったのか、実際に何を取得または検証できたのか、出力のどの部分に影響するのかを明記した成果物です。成果物を完成させるために、必要な数値を捏造、推定、または補間することは、決して認められません。不足を明記すれば、それで完全な回答です。

---

参考ファイル

• references/launch-tier-decision.md - 実例付きの Tier 1、2、3 の判断フレームワーク。
• references/positioning-canvas.md - B2B SaaS、B2C、開発者向け機能の例を含む、1 ページのポジショニングテンプレート。
• references/internal-alignment-checklist.md - ステークホルダー、ブリーフの構成、Tier ごとの配布タイミング。
• references/customer-comms-playbook.md - チャネル、カレンダー、担当者、ゲート。
• references/sales-enablement-template.md - バトルカード、デモ、案件コーチング、トレーニング（B2B）。B2C および PLG ではスキップする旨の注記。
• references/support-readiness-checklist.md - トレーニング、FAQ、エスカレーション、監視へのアクセス。
• references/rollout-strategy-patterns.md - 機能の種類に応じた 4 つのパターン。判断フレームワーク：影響範囲 × 確信度 × 対外的な約束。
• references/monitoring-readiness-checklist.md - 指標の切り口、アラートのしきい値、事前定義されたロールバックのトリガー。
• references/post-launch-measurement-framework.md - 導入、エンゲージメント、成果、副作用。測定期間。仕様の仮説との関連付け。
• references/common-launch-failures.md - 12 の失敗パターンと、その診断および対策。

---

まとめ：失敗したローンチのほとんどは、ローンチされていません

機能が「失敗」したとき、最もよくある診断は、その機能が間違っていたということではありません。ローンチが不完全だったということです。営業チームは知りませんでした。顧客には伝えられていませんでした。サポートは対応できませんでした。ローンチが、指標を動かすはずの人々に届かなかったため、指標は動きませんでした。

機能の失敗を宣言する前に、このプレイブックに照らしてローンチを監査してください。半分のケースでは機能に問題はなく、ローンチが行われていなかっただけです。

出荷、リリース、ローンチを区別する習慣を身につけることは、PM の語彙を磨くうえで最も役立つことです。明確に使い分けてください。朝会、ロードマップレビュー、ローンチの振り返りで使いましょう。何が起きたかを正確な言葉で表現するチームは、ローンチされていない機能を失敗と決めつける前に見つけ、エンジニアリング投資を、実際に価値を生み出せる機能へと再配分できます。

ローンチの準備が整っているか判断に迷ったら、次の点を確認してください。ローンチブリーフは作成され、配布されていますか？営業チームはバトルカードを確認しましたか？サポートチームは FAQ を用意していますか？ロールアウト戦略は選定され、ロールバックのトリガーも定義されていますか？コミュニケーションはヘルスチェックを条件にしていますか？測定計画は仕様の仮説と結び付いていますか？

どれか一つでも「いいえ」なら、ローンチの準備は整っていません。足りない部分を埋めるためにローンチを 1 週間遅らせるほうが、不完全な状態でローンチし、機能が生み出せたはずの価値の一部しか得られないよりも、コストがかかりません。