define-problem-statement

問題ステートメント

問題ステートメントは、解決する問題を明確にし、ユーザーとビジネスへの影響を説明し、明確な成功基準を定める簡潔なドキュメントです。解決方法に飛びつく前に、解決すべき問題を共有認識することで、その後のすべてのプロダクト開発の基盤となります。

使用する場面

• 新しい取り組みやプロジェクトを始める際に、共通認識を確立する
• 当初の意図から逸れてしまったプロジェクトを、本来の方向に戻す
• 優先事項について、経営層や関係者に伝える
• 提案された解決策が、根本的な問題に実際に対処しているかを評価する
• 新しいチームメンバーに背景を伝える

使用しない場面

• 問題についてすでに合意済みで、エンジニアリングチームが仕様を必要としている場合 → deliver-prd を使用します
• 解決策を提案して比較したい場合 → develop-solution-brief を使用します
• ビジネス上の問題ではなく、顧客の動機を整理したい場合 → define-jtbd-canvas を使用します
• 「問題」が実際には未検証の仮説である場合 → define-hypothesis で仮説を設定し、チームが取り組むと決める前に検証します

手順

問題ステートメントの作成を依頼されたら、次の手順に従います。

1. ユーザーセグメントを特定する 誰がこの問題を経験しているのかを尋ねます。ユーザーペルソナ、役割、セグメントを具体化します。「ユーザー」のような曖昧な説明は避け、「モバイルで購入手続きを完了する買い物客」や「50 人以上のユーザーを管理するエンタープライズ管理者」のように対象を絞ります。

2. 課題を把握する ユーザーが経験している摩擦、不満、満たされていないニーズを掘り下げます。問題の深刻度や発生頻度を理解するために、詳細な質問をします。ユーザー調査、サポートチケット、行動データから証拠を探します。

3. ビジネス上の背景を明確にする ユーザーの問題をビジネスへの影響と結び付けます。この問題は収益、顧客維持、成長、戦略目標にどのような影響を与えますか？組織が後回しにせず、今解決に投資すべき理由は何ですか？

4. 成功指標を定める 成功をどのように測定するかを特定します。この問題が解決された場合、どの指標が変化しますか？現状の基準値と目標とする改善幅を設定します。具体的な数値と期限を示します。

5. 制約と考慮事項を明らかにする 解決策の範囲に影響する技術的な制限、リソースの制約、規制要件、依存関係を記載します。

6. 未解決の疑問を記録する まだ分かっていないことを記録します。検証が必要な前提は何ですか？どのような追加調査が必要ですか？

出力形式

references/TEMPLATE.md のテンプレートを使用して、出力を構成します。完全な問題ステートメントには、テンプレートのすべてのセクション（問題の概要、ユーザーへの影響、ビジネス上の背景、成功基準、制約と考慮事項、未解決の疑問）を記入します。

品質チェックリスト

最終版を作成する前に、次の点を確認します。

• 問題が、定義されたユーザーセグメント（「すべてのユーザー」ではない）に固有のものになっている
• データまたは妥当な推定値によって、影響が定量化されている
• 成功指標に基準値と目標値が設定されている
• 問題の「内容」を説明し、「解決方法」を指示していない
• なぜ今これが重要なのか、ビジネス上の背景で説明されている
• フォローアップが必要な未解決の疑問が記録されている

例

完成例は references/EXAMPLE.md を参照してください。