pm-product-spec

製品仕様書 / PRD 作成スキル

このスキルの動作 (最初にお読みください)

Claude のデフォルトは、依頼されればすでにそれらしく見える PRD を生成します。そして、まさにそれが問題です。デフォルトは次のような傾向があります。問題が確定する前に要件をでっち上げる、「高速」「ユーザーフレンドリー」といった曖昧な目標を書く、依存関係や前提を省く、ユーザーストーリーをエンジニアリングタスクとして表現する。一見完成しているように見えても、検証されていない問題とテスト不能な要件の上に成り立っている文書は、文書がないよりも有害です。なぜなら、チームはそれを基に開発を進めてしまうからです。

そこで、このスキルは生成的でありながらゲートを設けたものとし、単にテンプレートを埋めるのではなく品質を強制します。

1. まず問題でゲートする。 明確で事実に基づく問題定義が存在するまで、要件を起草しないでください。ユーザーがそれを提供していない場合は、ユーザーとともに構築するか、その仕様が未検証の前提に依拠していることを明示してください。
2. 適切な文書を書く。 PRD と仕様書は、対象読者とタイミングが異なる別々の成果物です。意図的に選び分けてください (以下を参照)。
3. 測定可能性を強制する。 すべての要件はテスト可能でなければならず、すべてのユーザーストーリーは価値を表現しなければならず、すべての前提はリスクとして明示されなければなりません。
4. 提供前に自己監査する (組み込みのレビューパス — 最後のセクションを参照)。

---

ステップ 0 — PRD か仕様書か? 適切な方を書きましょう。

これらは別々の文書です。誤った方を書く (あるいは両者を混同する) ことはよくある失敗です。

	PRD (製品要件定義書)	製品仕様書
答える問い	製品は何をすべきか、そしてなぜか	どのように設計・構築されるか
対象読者	広範 — PM、経営層、マーケティング、ステークホルダー	技術者 — エンジニア、デザイナー、QA
タイミング	早期、ディスカバリー/計画の段階	要件が合意された後
柔軟性	洞察が得られるにつれて適応可能	開発開始後は安定。変更は手戻りを引き起こす
含む内容	ビジョン、目標、ペルソナ、ユーザーストーリー、成功指標	コンポーネント、動作、パフォーマンス目標、依存関係

経験則: 要件は優先順位を定め (何を/なぜ)、仕様は依存関係と動作を定義します (どのように)。ユーザーがまだ何を作るかを決めている段階なら PRD が必要です。何を作るかが固まり、構築の設計図が必要なら仕様書が必要です。書く前にどちらかを確認してください。

---

問題ゲート (要件の前にこれを行ってください)

不十分に定義された問題の上に構築された仕様は、どれほど上手く書かれていても失敗します。完全な問題定義には3つの部分があります。

• 問題 — 現状と望ましい状態とのギャップ (前提ではなく事実)。
• 結果 — ユーザーやビジネスにとっての悪い結果。
• 目標 — 達成すべき改善であり、解決策ではありません。

先に進む前に、以下のチェックを強制してください。

• 症状ではなく原因。 「リテンションが低い」は症状であり、「オンボーディングが中核的価値を伝えていない」は原因です。症状を突き抜けてください。
• 広範ではなく具体的。 「ユーザー体験を改善する」は問題ではありません。終わりのないタスクリストを生み出します。絞り込んでください。
• 前提ではなく事実。 「プロセスが非効率だ」「ユーザーが不満だ」は真の原因と測定可能な影響を隠します。可能な限り証拠 (フィードバック、データ) に結びつけてください。
• 明確さのテスト。 デザイン、エンジニアリング、経営層の誰かが、追加の説明なしに何が問題で、誰に影響し、なぜ重要かを理解できるでしょうか? できないなら、洗練させてください。

ユーザーが証拠を提供できない場合は、進めてかまいませんが、問題を検証すべき未検証の前提として明示的にマークしてください — ごまかしてはいけません。

---

仕様書 / PRD の構造

この構造に沿って作成します（ステップ0で判定したドキュメント種別に合わせて調整してください）。すべてのセクションは課題定義にさかのぼってつながります。

1. 概要 — それが何か、なぜ今存在するのか、誰に役立つのか。
2. 課題定義 — 上記のゲートで判定したもの。
3. スコープ — 対象と対象外。 何を含めるかだけでなく、何を除外するかを明示します。明示されていないスコープこそ、認識のずれが潜む場所です。
4. ペルソナとユーザーストーリー — 誰が、何を必要としているか（下記の形式）。
5. 要件 — 製品が何をしなければならないか、それぞれがテスト可能であること（下記のルール）。
6. 受け入れ基準 — 各要件について「完了」とはどのような状態か。
7. 依存関係、制約、前提条件（DCA） — 何が納品を妨げる可能性があるか（下記）。
8. 成功指標 — 成果をどのように測定するか、具体的な表現で。

---

要件の品質 — すべての要件をテスト可能にする

主観的な記述を測定可能な目標に置き換えます。これはこのスキルが行う中で最も効果の高いことです。

• ❌「アプリは素早く読み込まれるべきです。」→ ✅「ダッシュボードは標準的なモバイル回線で2秒以内に読み込まれます。」
• ❌「チェックアウトをユーザーフレンドリーにします。」→ ✅「リピートユーザーは、保存済みの情報を再入力することなく、3ステップ以内にチェックアウトを完了できます。」
• 孤立した機能ではなく、ワークフロー全体を記述します。
• 要件は、QA（または誰であれ）が意図を尋ねることなく合否チェックを書けるとき、テスト可能であると言えます。

---

ユーザーストーリー — タスクではなく価値を表現する

次の公式を使います: 「[ペルソナ]として、[行動]したい。なぜなら[利点]だからだ。」 各ストーリーを実在のペルソナ（調査から得た目標と不満）に結びつけることで、バックログが本物のニーズに根ざした状態を保てます。

INVEST を適用します — Independent（独立している）、Negotiable（交渉可能）、Valuable（価値がある）、Estimable（見積もり可能）、Small（小さい）、Testable（テスト可能）。

弱いストーリーに印をつける — これらはユーザー価値ではなくタスクを記述しているため、書き直すべきです:

• ❌「ログイン機能を追加する」/「ダッシュボードのパフォーマンスを改善する」（タスクであり、誰が・なぜがない）
• ✅「リピートユーザーとして、保存したデータにアクセスできるように素早くログインしたい。」

---

依存関係、制約、前提条件（DCA）

デフォルトでは最も省略されがちなセクションであり、実際に納品が破綻する場所です。

• 依存関係 — 次のステップを可能にする一つのステップ。内部（チーム内 — 計画によって管理可能）と外部（法務承認、サードパーティベンダー、他チーム — より高リスク）を区別します。連鎖をマッピングして、一つの遅延が下流に与える影響を見えるようにします。
• 制約 — 境界線: 予算、締め切り、レガシー技術、法務・コンプライアンス。早い段階で明示し、非現実的な計画を避けます。
• 前提条件 — チームが信じているが確認していないこと。各前提条件を、担当者を定めた測定可能なチェックに変換します。 検証されないまま放置された前提条件は隠れたリスクです。それをリスクとして表面化させます。

既存の仕様書をレビューする際に指摘すべき早期警告シグナル: 重要な依存関係の担当が曖昧、チーム間でタイムラインが不整合、数スプリント経っても検証されていない前提条件。

---

納品前のセルフ監査（組み込みレビューパス）

ドキュメントを提示する前に、自分の出力に対してこの品質チェックを実行してください。これがスキルとテンプレートの穴埋めを分けるものです。

• すべての要件が測定可能／テスト可能である（「高速」「直感的」「ユーザーフレンドリー」を未定義のまま残していない）。
• すべてのユーザーストーリーが価値を表現している（誰が＋なぜがある）、INVEST を満たしている、そして偽装されたタスクになっていない。
• スコープが含まれるものだけでなく、含まれないものを明示的に列挙している。
• 各要件が問題定義にさかのぼってトレースできる。
• 前提がリスクとしてフラグ付けされ、それを検証する方法がある。依存関係は内部と外部を区別して記載している。
• 成功が具体的かつ測定可能な形で定義されている。

次に、ドキュメントを監査レンズに渡します。これらは候補レンズです。姿勢は docs/orchestration-policy.md に従うか、成果物全体を pm-product-review にルーティングしてください。ここでは**assumption-rigor が常に関連するレンズ（自動実行）です。その他は提示される**もので、成果物が実際に含む内容に紐づきます。ユーザーがこのスキルを特定の一つの目的で呼び出した場合は、そのスコープを尊重してください。

完全なアイデアから計画への構築において、この仕様は pm-idea-to-plan の最終段です。すでに枠組み化された問題、発見の証拠、テスト済みの最もリスクの高い前提の上に位置し、それらと釣り合ったものになっているべきです。これらの段より前に作成された仕様は、検証されていない賭けに対する磨かれた PRD であり、まさにその入口が防ぐために存在する失敗です。

ハンドオフは各レンズをそのインストール可能なスキル name で指定します。そのスキルがインストールされている場合にのみ呼び出してください。インストールされていない場合、このスキル自体の上記のセルフ監査チェックリストがすでにこれらのルールを担っています。ブロックするのではなく、それなしで進めてください。

• pm-assumption-rigor-audit (自動実行) — 仕様が重要な未検証の前提に依拠している場合：最もリスクの高い前提が、信念を事実に見せかけたままにされるのではなく、適切な忠実度の手法とあらかじめ設定された成功基準をもってテストされているかどうか。
• pm-spec-quality-audit (提示 — 仕様を作成する場合) — ドキュメント全体のレビュー：すべての要件のテスト可能性、完全なフロー対ハッピーパス、スコープの除外、DCA の網羅性、検証の証拠、レイヤーの混在、対象読者への適合。
• pm-okr-metric-validity-audit (提示 — 成功指標を挙げる場合) — 特に成功指標：虚栄の指標、反証不可能なターゲット、アウトカムに偽装されたアウトプット、ガードレールを欠いたゲーム可能な指標。

満たせないものは（例：「要件 3 の成功指標が未定義 — ターゲットが必要」）、もっともらしく聞こえるテキストで黙って埋めるのではなく、報告してください。仕様は生きたドキュメントであることに注意してください。要件はスプリントレビューとリリースの後に再検証すべきです。

---

よくある do/don't パターン

❌ しない	✅ する
問題が明確になる前に要件を起草する	まず問題定義（問題＋結果＋目標）でゲートする
症状を述べる（「リテンションが低い」）	根本原因を枠組み化する
「ユーザーエクスペリエンスを改善する」	具体的で証拠に基づく問題に絞り込む
「ページは高速であるべき」	「標準的なモバイルネットワークで 2 秒以内に読み込む」
「ログイン機能を追加する」	「リピーターユーザーとして、保存したデータにアクセスするためにすばやくログインしたい」
スコープに含まれるものだけを列挙する	明示的にスコープ外のものも述べる
依存関係と前提を省略する	DCA セクションを含める。前提を担当者付きのテスト可能なチェックに変える
PRD と仕様を曖昧にする	その瞬間／対象読者が必要とするドキュメントを決める
磨かれているが曖昧なドキュメントを提示する	セルフ監査する。未定義のターゲットをでっち上げずにフラグ付けする
仕様を最終版として扱う	生きたものとして扱う — レビューとリリースの後に再検証する

---

参考レッスン (Uxcel)

• プロダクト仕様を理解する
• プロダクト仕様とプロダクト要求定義書の比較
• 効果的な仕様のための問題定義
• 依存関係、制約、前提条件
• 仕様のレビューと検証
• ユーザーの理解とユーザーストーリーの組み立て