問題とスコープ
Working Backwardsは、顧客体験と課題からスタートし、そこからプロダクトのソリューションへと逆算して考える手法です。PR/FAQでは、顧客向けのプレスリリース（PR）を用いてコアバリューを提示し、FAQを通じて顧客や社内ステークホルダーから指摘されるであろう詳細な懸念点を洗い出します。この設問は、機会の検証、スコープ管理、評価指標、そしてチーム間のアライメントを評価するものであり、そのカテゴリーは product です。固定のテンプレートは不要であり、体裁の整ったドキュメントがあること自体は、ニーズが検証された証拠にはなりません。
面接官が確認しているポイント
まずターゲット顧客とペインを定義し、その上で約束（プロミス）を反証可能な形に落とし込みます。導入条件、データとプライバシー、コスト、サポート、障害モード、成功指標、中止条件を網羅します。ドキュメントを単独で作成して満足するのではなく、インタビュー、プロトタイプ、または限定的なパイロット運用を通じて、どのようにFAQの仮説を検証するかを説明します。
明確にすべき質問
- ターゲット顧客は誰で、現在はどのようにデータをエクスポートしていますか？
- コストやリスク要因となっているペインは、待ち時間、フォーマットの互換性、権限設定、それともコンプライアンスですか？
- どのようなデータがエクスポート可能で、誰がそれを開始、承認、取り消しできますか？
- 顧客はどのような成果に対して対価を支払うのか、またどのような代替手段が存在しますか？
- 想定される導入率、SLA、ストレージ、サポートコストはどの程度ですか？
- どの仮説が覆された場合に、プロジェクトを即時中止すべきですか？
30秒回答フレームワーク
「まず顧客と課題を絞り込み、次に顧客が得られる結果のみを記述したPRを作成します。FAQは価値、ワークフロー、境界条件、プライバシー、セキュリティ、価格設定、運用に分割し、すべての主要な仮説に裏付けとなる証拠を紐付けます。インタビューとクリッカブルプロトタイプを用いて最も検証が難しい主張をテストし、導入率、完了率、失敗率、サポートチケット数、コストの上限を定義します。十分な証拠が得られない場合は、プラットフォーム全体の開発にコミットするのではなく、提供価値を絞り込むか中止します。」
ステップごとの回答
ステップ 1：顧客と課題を定義する
契約終了前にテナントの移行を行う管理者など、特定の役割と状況を選択します。「すべての企業がこれを必要としている」という曖昧な表現を課題と見なすのではなく、現在の作業手順、所要時間、エラー、コンプライアンス上の制約を記録します。
ステップ 2：顧客の言葉でPRを執筆する
見出しと導入文では、監査可能な権限設定を備えた復旧可能なエクスポートなど、顧客が得られる成果を約束する必要があります。内部アーキテクチャ、技術用語、「業界初」といった主張は避け、証拠がないまま100%の成功を約束してはなりません。
ステップ 3：FAQで制約を洗い出す
データの対象範囲、フォーマット、保持期間、権限、承認、キャンセル、再試行、通知、価格、SLA、サポート、責任の境界について回答します。リスクの高い質問を優先し、それぞれの回答を「既知の事実」「検証すべき仮説」「明示的にサポート対象外とするケース」のいずれかに分類します。
ステップ 4：検証の証拠とパイロットを設計する
さまざまな規模の顧客にインタビューを実施し、実際の移行作業を観察します。プロトタイプを使用して権限設定、進捗状況、復旧手順をテストします。パイロットは特定のデータタイプとテナントに限定し、エクスポートあたりの完了率、再試行回数、人的介入、サポートチケット数、インフラコストを測定します。
ステップ 5：意思決定ゲート（判定基準）を設定する
継続、絞り込み、中止の基準をドキュメントに明記します。例えば、ターゲット顧客が手動の追加承認なしに完了できない場合や、ユニットコストが予算を超える場合は、まずスコープを変更します。レビュー後、FAQの変更内容をロードマップ、ランブック、および次の実験計画へと反映させます。
回答例
「具体的な移行タスクを抱えるエンタープライズ管理者を想定し、現在の所要時間、エラー、コンプライアンスリスクを定量化した上で、顧客目線のPRを執筆します。FAQでは権限、フォーマット、復旧、データ保持、SLA、価格、サポートについて回答し、不明点をテスト可能な仮説に変換します。インタビュー、プロトタイプ、限定的なパイロットを通じて、完了率、失敗、介入度合い、チケット数、ユニットコストを測定します。事前に定義したゲート基準をクリアした場合のみ拡張し、それ以外の場合は約束の範囲を縮小するか中止します。PR/FAQは一度でプラットフォーム全体を承認するためのものではなく、得られた証拠に応じて進化させていきます。」
よくある間違い
- アーキテクチャから考え始める → 顧客価値と課題が曖昧なままになる → まずは反証可能な成果から記述する。
- FAQをマーケティング資料にしてしまう → リスク、境界、コストが見えなくなる → 最も厳しい反論から優先して回答する。
- すべての顧客が同じだと想定する → パイロット運用のシグナルが解釈不能になる → 役割、コンテキスト、代替手段を限定する。
- 導入率のみに注目する → 人的介入やサポートコストが見落とされる → 完了率、失敗率、チケット数、ユニットコストを追跡する。
- 中止条件を設定しない → パイロットが無計画に拡大する → 継続、絞り込み、中止のゲートをあらかじめ定義する。
- ドキュメントを更新しない → 意思決定が証拠から乖離する → レビューやロードマップのプロセスを通じてFAQをバージョン管理する。
フォローアップ質問
フォローアップ 1：PRは要件定義書とどう違うのですか？
PRは顧客が得られる成果と価値を明記するものであり、FAQは顧客やステークホルダーから指摘される詳細な疑問点を捉えるものです。要件定義書は、その後に実装スコープを定義するために作成されます。PR/FAQは機会を検証しアライメントを取るためのものであり、それ自体で実装を承認するものではありません。
フォローアップ 2：賛同者ばかりにインタビューしてしまうのを防ぐには？
事前に定義した役割、企業規模、現在利用している代替手段に基づいてサンプリングを行い、拒否された事例や失敗した試みも記録します。代替手段、支払い意欲、利用をやめた理由について質問し、反例もFAQに含めるようにします。
フォローアップ 3：どのような場合に中止すべきですか？
課題の深刻度が低い場合、権限やコンプライアンス要件を満たせない場合、パイロットの完了率がゲート基準を下回っている場合、またはユニットコストが予算を超過し続けている場合に、中止またはスコープの縮小を行います。後から基準が動かないよう、パイロット開始前にゲートを文書化しておきます。
フォローアップ 4：ドキュメントはロードマップとどのように連動しますか？
FAQの各仮説を検証タスク、担当者、期日にマッピングします。検証された約束はバージョンスコープに組み込まれ、未検証または検証に失敗した約束は、開発スケジュールに直接組み込まずリスクとして管理し続けます。