wwas

Why-What-Acceptance バックログエキスパート

概要

Why-What-Acceptance（WWAS）形式を使用して、バックログ項目を作成します。この形式では、すべての作業を戦略的な背景につなげ、詳細な仕様ではなく「議論の内容を思い出すため」の簡潔な説明を含め、観察可能な成果に焦点を当てた高水準の受け入れ基準を定義します。

使用する場面

• バックログの作成 -- 戦略との整合性が重要なプロダクトバックログを作成するとき。
• スプリント計画 -- 次のスプリントに向けて項目を整理し、各項目がなぜ重要なのかをチームが理解する必要があるとき。
• ステークホルダーとのコミュニケーション -- 経営幹部や部門横断的なパートナーに、個々の作業項目が事業目標とどのようにつながっているかを示す必要があるとき。
• ロードマップの分解 -- ロードマップのテーマを実行可能なバックログ項目に分解するとき。

使用しない場面

• 状況に基づいた要件が必要な場合は、代わりにjob-stories/を使用してください。
• 戦略的な背景がない純粋な技術タスクの場合（シンプルなタスク説明を使用してください）。
• チームが従来のユーザーストーリー形式を好み、戦略的な背景も十分に理解されている場合。

WWAS 形式

各バックログ項目は、次の3つの部分で構成されます。

1. Why（戦略的な背景）

この作業項目をチームの目標や事業戦略につなげる1～2文です。Why では、次のことに答えます。

• どの事業目標を支援するのか？（例：「第2四半期に解約率を10％削減する」）
• なぜ今なのか？ 他の作業と比べて、この項目が今重要である理由は何ですか？

Why が最も重要です。 チームが戦略から切り離された機能を作るのを防ぎます。Why を説明できない場合、その項目をバックログに含めるべきではありません。

良い Why の例：

• 「第2四半期の目標は、新規ユーザーが価値を実感するまでの期間を14日から3日に短縮することです。オンボーディングが最も大きな効果をもたらします。解約したユーザーの60％はセットアップを完了していませんでした。」
• 「エンタープライズ顧客から、SSO がないことがアップグレードしない最大の理由として挙げられています。これは、上半期に ARR を200万ドル増やすという収益拡大目標を直接支援します。」
• 「請求に関するサポートチケット数が前四半期に40％増加しました。この問題を解決すれば、サポート担当者2人分の稼働時間をオンボーディング支援に充てられ、アクティベーション目標の達成につながります。」

悪い Why の例（避けてください）：

• 「顧客に頼まれたからです。」（戦略的な背景がありません）
• 「ベストプラクティスだからです。」（チームの目標とのつながりがありません）
• 「リリースに必要だからです。」（循環論法です）

2. What（説明）

何を作成または変更する必要があるかを簡潔に説明します。このセクションは、詳細な仕様ではなく、議論の内容を思い出すためのものです。

ガイドライン：

• 最大1～2段落にします。
• リファインメントで話し合った内容をチームが思い出せるレベルで、変更内容を説明します。
• デザインファイルがある場合は、そのリンクを含めます。
• 実装の詳細、技術仕様、手順を段階的に記述した説明は書きません。
• チームが What を読んで、「はい、何を作ると合意したか覚えています」と言えるようにします。

良い What の例：

• 「新規ユーザーがデータソースの接続、チームメイトの招待、最初のダッシュボードの作成を行えるように案内する、ガイド付きセットアップウィザードを追加します。ウィザードはスキップ可能で、後から再開できるようにします。[デザイン：Figma リンク]」
• 「現在の請求 FAQ ページを、よくある請求の問題（支払いの失敗、プランの変更、請求書のリクエスト）を案内し、サポートチケットを作成せずにケースの80％を解決する、インタラクティブなトラブルシューティングツールに置き換えます。」

悪い What の例（避けてください）：

• ワイヤーフレーム、API コントラクト、データベーススキーマを含む複数ページの仕様（詳細すぎます。これは設計ドキュメントに記載する内容です）。
• 「SSO を構築する。」（曖昧すぎるため、チームが話し合った内容を思い出せません。）

3. 受け入れ基準

項目が完了したと判断するための、具体的に確認できる高レベルの成果です。詳細なテストケースではなく、その項目を受け入れるために満たすべき最低限の条件です。

ガイドライン：

• 項目ごとに受け入れ基準を4つ以上設けます。
• 各基準では、実装手順ではなく確認可能な成果を説明します。
• どのように構築するかではなく、ユーザーまたはシステムが何をすべきかに焦点を当てます。
• 特に重要なエッジケースを含めますが、網羅的なテストケースはQA用に残しておきます。

受け入れ基準の良い例：

1. セットアップウィザードを完了した新規ユーザーは、3日以内にアクティベートします（最初のダッシュボードの作成によって測定）。
2. ウィザードはモバイルブラウザーとデスクトップブラウザーで利用できます。
3. ユーザーはウィザードのどのステップでもスキップでき、後から中断したところから再開できます。
4. ウィザードをスキップしたユーザーは、ヘルプメニューから再度アクセスできます。

受け入れ基準の悪い例（避けてください）：

• APIが、次の内容を含むJSONペイロードとともに200ステータスコードを返す（実装の詳細）
• Reactコンポーネントがすべての単体テストに合格する（内部品質であり、ユーザーにとっての成果ではない）
• Chromeで動作する（曖昧すぎます。「動作する」の内容を具体的に指定してください）

INVEST 品質ゲート

WWAS 項目をスプリントに入れる前に、INVEST の基準を満たす必要があります。

基準	質問	満たさない場合の対応
独立性	別の項目を待たずに、この項目を提供できますか？	バックログの順序を変更するか、依存する項目をまとめます。
交渉可能性	What の実装方法について、議論の余地がありますか？	What から実装方法の指定を取り除きます。
価値	Why が実際のビジネス目標と結び付いていますか？	Why を書き直すか、項目の優先度を下げます。
見積もり可能性	チームは妥当な確度で作業量を見積もれますか？	What により詳しい背景を追加するか、スパイクを実施します。
小ささ	1スプリント以内に完了できますか？	成果、スコープ、またはユーザーセグメントごとに項目を分割します。
テスト可能性	受け入れ基準を検証できますか？	基準を、確認可能で具体的な内容に書き直します。

項目テンプレート

### [Title]

**Why:**
[1-2 sentences connecting to strategic objective and explaining why this matters now.]

**What:**
[1-2 paragraphs describing the change. Reminder of the discussion, not a specification.]

[Design: link or "TBD"]

**Acceptance Criteria:**

1. [ ] [Observable outcome]
2. [ ] [Observable outcome]
3. [ ] [Observable outcome]
4. [ ] [Observable outcome]

記入例

ガイド付きオンボーディングウィザード

Why： 当社のQ2のノーススターメトリックは、価値実現までの時間を14日から3日に短縮することです。ユーザー調査によると、解約したユーザーの60％は初期設定を完了しておらず、最も多く挙げられた理由は「次に何をすればよいかわからなかった」ことです。ガイド付きのオンボーディングフローで重要な最初の手順を案内することで、この問題に直接対処します。

What： 初回ログイン時に表示される、ステップごとのセットアップウィザードを追加します。新規ユーザーを、データソースの接続、チームメイトの招待、最初のダッシュボードの作成という3つのマイルストーンに沿って案内します。ユーザーによっては自分で操作したい場合もあるため、ウィザードはどの段階でもスキップできるようにし、完了前に離れた場合は再開できるようにします。各ステップには、その操作が重要な理由を簡潔に説明する文と、直接操作できるボタンを含めます。

[デザイン：figma.com/file/abc123]

受け入れ基準：

1. 新規ユーザーの初回ログイン時に、ウィザードが自動的に表示される。
2. ユーザーはウィザードのどのステップでもスキップでき、後からヘルプメニューから再開できる。
3. 各マイルストーン（データソース、チームメイト、ダッシュボード）は、個別に、任意の順序で完了できる。
4. 3つすべてのマイルストーンを完了したユーザーには、完了確認と次のステップの提案が表示される。
5. セットアップをすでに完了している既存ユーザーには、ウィザードが表示されない。
6. ウィザードはデスクトップブラウザーとモバイルブラウザーの両方で機能する。

Why とビジネス目標の結び付け

WWAS の強みは、戦略との明確な結び付きにあります。この対応表を使って、説得力のある Why を記述してください。

目標レベル	目標の例	Why の表現
会社の OKR	ARR を 1,000 万ドルに増やす	「これは、1,000 万ドルの ARR 目標を達成するために……」
チームの OKR	月次解約率を 5% 未満に抑える	「チームの第 2 四半期の解約率目標を達成するには……」
プロダクトのテーマ	セルフサービス型のオンボーディング	「セルフサービス型オンボーディングのテーマの一環として……」
顧客からのフィードバック	要望の多い機能トップ 3	「これはエンタープライズ顧客から最も多く要望されている機能であり、50 万ドルのパイプラインを妨げています……」
業務運用	サポート負荷の軽減	「この問題に関するサポートチケットは月に X 件発生し、Y 時間のコストがかかっています……」

他のスキルとの連携

• 戦略との整合性よりもユーザーの状況に焦点を当てた、状況主導のストーリーが必要な場合は、job-stories/ を使用してください。
• WWAS の項目が結び付く目標を定義するには、brainstorm-okrs/ を使用してください。
• What に反映するリファインメントセッションの議論を記録するには、summarize-meeting/ を使用してください。
• WWAS の項目を ../jira-expert/ に渡して、構造化フィールドを含むチケットを作成してください。

参考資料

• 形式の比較、INVEST の詳細、リファインメントのベストプラクティスについては、references/backlog-management-guide.md を参照してください。
• すぐに使えるテンプレートについては、assets/wwas_template.md を参照してください。

トラブルシューティング

問題	考えられる原因	解決策
「Why」の記述が抽象的（「顧客に頼まれたから」）	PM が要望をビジネス目標に結び付けていない。戦略的な背景が不明確	すべての Why に具体的な OKR、指標、またはビジネスケースを記載するよう求めてください。このスキルの目標レベル対応表を使用してください
「What」の説明が曖昧すぎる、または詳細すぎる	「議論の備忘録」という原則をチームが理解していない。リファインメントセッションが実施されていない	What を記述する前にリファインメントセッションを実施してください。1～2 段落の上限を徹底し、詳細については設計ドキュメントへのリンクを付けてください
受け入れ基準に実装手順が記載されている	エンジニアリングチームがユーザー視点の表現を使わずに基準を記述した	「ユーザーにとって重要か？」という観点で確認してください。すべての基準を観察可能な成果として書き直し、API やデータベースへの言及を取り除いてください
項目が一貫して INVEST-S（小ささ）の基準を満たさない	リファインメント中にスコープが拡大している。チームが項目の分割に消極的	垂直スライスを実践してください。ユーザー層、シナリオ、または成果ごとに分割し、3～5 日で完了できる項目を目指してください
バックログ項目が時間とともに戦略との結び付きを失う	Why が一度記述されただけで見直されていない。OKR が変わってもバックログが更新されていない	四半期ごとにバックログとの整合性を確認してください。Why が現在の目標に結び付かなくなった項目は更新するか、廃止してください
シンプルなユーザーストーリーに比べて WWAS 形式の負担が大きいとチームが感じる	形式によって摩擦が生じる一方、その価値が認識されていない。チームがすでに十分な戦略的背景を共有している	優先度の高い項目や機能には WWAS を使用し、バグや技術的な作業にはよりシンプルな形式を認めてください。Why によって無駄な作業を防げることを示し、価値を実証してください
受け入れ基準が少なすぎる、または浅すぎる	チームがリファインメントを急いでいる。基準がチェックリストとして扱われている	項目ごとに受け入れ基準を最低 4 つ設定してください。少なくとも 1 つのエッジケースと 1 つのエラー状態に関する基準を含めてください

成功基準

• すべての機能バックログ項目に、具体的なビジネス目標または OKR を参照する Why の記述が含まれている
• What の説明は 1～2 段落で、該当する場合は設計ドキュメントへのリンクが記載されている
• すべての項目に、観察可能なユーザー成果に焦点を当てた受け入れ基準が 4 つ以上ある
• スプリントの準備が整ったすべての項目が、スプリントに入る前に INVEST 品質ゲートをすべて通過している
• ステークホルダーは、バックログ項目の Why を読めば、追加の背景情報がなくても戦略との整合性を確認できる
• WWAS 形式で作成された項目は、戦略的な背景を含まない項目と比べて、スプリントレビューでの却下率が 30％以上低い
• バックログの整合性レビューを少なくとも四半期ごとに実施し、古くなった項目は廃止または更新する

範囲と制限事項

対象範囲： Why-What-Acceptance 形式でのバックログ項目の作成、INVEST 品質ゲートの適用、作業項目と戦略目標の関連付け、WWAS 項目を作成するためのリファインメントセッションの進行、既存のバックログ項目の WWAS 形式への変換、チケット作成のための Jira との連携。

対象外： 状況に基づく要件（job-stories/ に引き継ぎ）、製品のアイデア創出や機会の発見（discovery/brainstorm-ideas/ に引き継ぎ）、OKR の定義（execution/brainstorm-okrs/ に引き継ぎ）、詳細な技術仕様、スプリント計画とキャパシティ管理（../scrum-master/ に引き継ぎ）。

制限事項： WWAS 形式が最も効果を発揮するのは、組織の目標（OKR、ノーススターメトリクス）が明確に定義されている場合です。戦略的な背景がないと、Why は形だけの作業になり、得られるメリットは限られます。この形式は製品や機能の作業を想定しており、純粋な技術的負債やインフラストラクチャの項目には、必ずしも自然に当てはまりません。ユーザーストーリーから移行するチームが、この形式に習熟するには 2～3 スプリントかかる場合があります。

連携ポイント

連携	方向	データの流れ
job-stories/	相互補完	ジョブストーリーは状況的な背景（When）を加え、WWAS は戦略的な背景（Why）を加えます。要件を完全に記述するには、両方を使用します
summarize-meeting/	会議 -> WWAS	リファインメントセッションでの議論から What が生まれ、決定事項から受け入れ基準が生まれます
../jira-expert/	WWAS -> Jira	WWAS 項目は、構造化された説明フィールドを持つ Jira チケットになります
execution/brainstorm-okrs/	OKR -> WWAS	チームの OKR が、Why の記述で参照する戦略目標になります
execution/prioritization-frameworks/	WWAS -> 優先順位付け	WWAS 項目を RICE などのフレームワークで評価し、バックログの順序を決めます
discovery/brainstorm-ideas/	アイデア -> WWAS	検証済みのアイデアを、戦略との追跡可能性を備えた WWAS バックログ項目に分解します