テンプレート — PR-FAQ

いつ使うか

ステージ1 — 意図定義で完成した姿を先に描いてみるときに使う。アマゾンが新製品の企画に使う方式で、まだ作っていないもののリリース発表文(Press Release)と想定質疑応答(FAQ)を先に作成する。機能や要求を列挙する代わりに「これが成功したらユーザーに何が変わるのか」をユーザー視点の文で強制するため、目的なく表面だけを実装する誤りを文書作成のステージで漉し取る。意図文書(6-pager)とともに作成し、通常はPR-FAQを先に書いて目標像を描いたうえで6-pagerで背景・制約を埋める。

使い方

下のテンプレートをコピーして実際のリリース時点を想像し、過去形/現在形で叙述する。「まだ検討中」のような条件文は使わない — 確定した事実のように書いてこそ、何を目標にするかが明確になる。引用文は実際にありそうな発言を想像して埋める。FAQは実際に出るであろう質問を予想して答えを前もって用意するのが目的なので、難しい質問(価格、制約、失敗シナリオ)を避けない。

テンプレート

# [製品/機能名] リリース発表文

## 見出し

<!-- 記入ガイド: 製品/機能と中核価値を一文で。プレスリリースの見出しのように書く。 -->

例: [サービス名]、オンボーディング時間を30分から5分へ短縮する簡単設定ウィザードをリリース

## 顧客の問題

<!-- 記入ガイド: いま顧客が抱える具体的な困難を1〜2段落で。数値や事例を含める。 -->

例: 新規ユーザーの42%が初回セッションで設定を終えられず離脱する。大半は12ステップに及ぶ初期設定の過程で、何を入力すべきか混乱する。

## 解決

<!-- 記入ガイド: 何を作り、それが顧客の問題をどう解決するかを1〜2段落で。 -->

例: 新しいオンボーディングウィザードは必須入力を5ステップへ減らし、残りの設定は使用中に必要な時点で自然に案内する。ユーザーは初回セッションで中核機能へ直ちに到達する。

## 引用 — 会社/チーム

<!-- 記入ガイド: この機能を作った理由をチーム視点で一文の引用で。 -->

例: 「ユーザーがサービスの価値を感じる前に設定画面で諦めることが、最大の損失でした。」 — [担当者名]、[チーム名]

## 引用 — 顧客

<!-- 記入ガイド: この機能を使った顧客がありそうな言葉を想像して一文で。 -->

例: 「登録して5分で最初の結果が見られました。前は設定だけで諦めていたのに。」 — [仮想の顧客ペルソナ]

## 始め方

<!-- 記入ガイド: 顧客がいま何をすればよいのか、行動指針を一段落で。 -->

例: 既存ユーザーは特別な対応は不要だ。新規登録者は次回のデプロイから自動で新しいオンボーディングフローを体験する。

---

# FAQ

## 顧客FAQ

<!-- 記入ガイド: 実際のユーザーが尋ねそうな質問3〜5個と答え。 -->

1. **例: すでに保存した設定はどうなりますか?** 答: 既存の設定はそのまま維持され、新しいオンボーディングは新規登録者だけに適用されます。
2. **例: スキップした高度な設定は後でどこで見つけますか?** 答: 設定メニューの上部に案内バナーとして表示され、いつでもアクセスできます。
3. **例: 追加費用は発生しますか?** 答: いいえ、既存の料金プランのユーザーに無料で提供されます。

## 内部FAQ

<!-- 記入ガイド: チーム内部・ステークホルダーが尋ねそうな質問3〜5個と答え。リスク、トレードオフ、測定計画を含める。 -->

1. **例: 成功の可否は何で判断しますか?** 答: 7日リテンションとオンボーディング完了時間をデプロイ4週間後に比較する。意図文書の成功基準を参照。
2. **例: 失敗したらロールバック計画は?** 答: 機能フラグで包み、直ちに以前のフローへ戻せる。
3. **例: 今回の範囲で外したものは何で、なぜか?** 答: ソーシャルログイン連携は今回の離脱率問題と直接関係がないため次サイクルへ送った。
4. **例: どのチームがレビューに参加すべきですか?** 答: プロダクト、認証ドメイン担当者、QA。認証フローが絡むためHighリスクに分類。