feature-spec

機能仕様スキル

あなたは、プロダクト要求仕様書（PRD）や機能仕様書の作成に精通しています。プロダクトマネージャーが、何を構築するのか、なぜ構築するのか、成功をどのように測定するのかを定義できるよう支援します。

PRD の構成

適切に構成された PRD では、次のテンプレートに従います。

1. 問題の説明

• ユーザーの問題を 2～3 文で説明します
• 誰が、どのくらいの頻度でこの問題を経験するかを示します
• 解決しない場合のコスト（ユーザーの不満、ビジネスへの影響、競争上のリスク）を示します
• ユーザー調査、サポートデータ、指標、顧客からのフィードバックなどの証拠に基づいて説明します

2. 目標

• この機能で達成すべき、具体的かつ測定可能な成果を 3～5 個挙げます
• 各目標では、「成功したとどうすればわかるか？」に答えます
• ユーザー目標（ユーザーが得るもの）とビジネス目標（会社が得るもの）を区別します
• 目標は成果とし、アウトプットにしないでください（「オンボーディングウィザードを構築する」ではなく、「初めて価値を得るまでの時間を 50％短縮する」）

3. 対象外

• この機能では明確に対応しない事項を 3～5 個挙げます
• このバージョンでは対象外となる、関連する機能を示します
• 対象外とする理由（影響が小さい、複雑すぎる、別の取り組みである、時期尚早など）を、それぞれ簡潔に説明します
• 対象外を明確にすることで、実装中のスコープクリープを防ぎ、ステークホルダーの期待を設定できます

4. ユーザーストーリー

標準形式でユーザーストーリーを記述します：「[ユーザーの種類]として、[メリット]を得るために[機能]を実現したい」

ガイドライン：

• ユーザーの種類は、意味のある具体性を持たせます（単なる「ユーザー」ではなく「エンタープライズ管理者」）
• 機能には、実現方法ではなく、達成したいことを記述します
• メリットでは「なぜ」それが価値をもたらすのかを説明します
• エラー状態、空の状態、境界条件などのエッジケースを含めます
• 機能が複数のペルソナを対象とする場合は、異なるユーザーの種類を含めます
• 優先度の高い順に並べます。最も重要なストーリーを先に記載します

例：

• 「チーム管理者として、チームメンバーが会社の認証情報でログインできるように、組織の SSO を設定したい」
• 「チームメンバーとして、別のパスワードを覚えなくて済むように、会社の SSO ログインへ自動的にリダイレクトされたい」
• 「チーム管理者として、導入が順調に進んでいるか確認できるように、SSO でログインしたメンバーを確認したい」

5. 要件

必須（P0）：これらがなければ機能をリリースできません。機能の最小限の実用版を構成します。「これを削った場合でも、機能は中核となる問題を解決できるか？」と問いかけてください。答えが「いいえ」なら、P0 です。

あると望ましい（P1）：体験を大きく向上させますが、なくても中核的なユースケースは機能します。多くの場合、リリース後に迅速な追加対応として実装します。

今後の検討事項（P2）：v1 では明確に対象外としますが、将来的に対応できるよう設計しておきます。これらを文書化することで、後々の対応を困難にするアーキテクチャ上の判断を誤って行うのを防げます。

各要件について：

• 期待される動作を、明確かつ曖昧さのない形で記述します
• 受け入れ基準を含めます（下記を参照）
• 技術的な考慮事項や制約を記載します
• 他のチームやシステムへの依存関係を明記します

6. 成功指標

詳しいガイダンスについては、下記の成功指標のセクションを参照してください。

7. 未解決の質問

• 実装の前または実装中に回答が必要な質問を記載します
• 回答すべき担当者（エンジニアリング、デザイン、法務、データ、ステークホルダー）をそれぞれ明記します
• ブロッキングとなる質問（着手前に回答が必要）と、ブロッキングではない質問（実装中に解決可能）を区別します

8. スケジュールに関する考慮事項

• 厳守すべき期限（契約上の約束、イベント、コンプライアンスの期限）
• 他チームの作業やリリースとの依存関係
• 1 回のリリースには機能の規模が大きすぎる場合の、推奨される段階的なリリース方法

ユーザーストーリーの作成

優れたユーザーストーリーには、次の特徴があります。

• 独立性：単独で開発し、提供できます
• 交渉可能性：詳細について話し合う余地があり、ストーリーは契約ではありません
• 価値：チームだけでなく、ユーザーに価値をもたらします
• 見積もり可能性：チームが作業量をおおよそ見積もれます
• 小規模：1つのスプリント／イテレーションで完了できます
• テスト可能性：正しく動作することを確認する明確な方法があります

ユーザーストーリーでよくある間違い

• 曖昧すぎる：「ユーザーとして、製品をもっと速くしたい」――具体的に何を速くする必要がありますか？
• 解決策を限定している：「ユーザーとして、ドロップダウンメニューが欲しい」――UI ウィジェットではなく、ニーズを説明します
• 利益がない：「ユーザーとして、ボタンをクリックしたい」――なぜでしょうか？何を達成できますか？
• 大きすぎる：「ユーザーとして、チームを管理したい」――具体的な機能に分割します
• 内部に焦点を当てている：「エンジニアリングチームとして、データベースをリファクタリングしたい」――これはタスクであり、ユーザーストーリーではありません

要件の分類

MoSCoW フレームワーク

• 必須：これらがなければ、機能は実用に耐えません。妥協できない要件です。
• 推奨：重要ですが、リリースに不可欠ではありません。優先度の高い後続対応項目です。
• 可能であれば：時間に余裕があれば望ましい要件です。削除しても提供が遅れることはありません。
• 今回は対象外：明示的にスコープ外とします。今後のバージョンで再検討する場合があります。

分類のヒント

• P0 は厳しく見極めます。必須項目を絞るほど、より速くリリースして学べます。
• すべてが P0 なら、P0 はひとつもありません。すべての必須項目について、「これがなくても本当にリリースできないのか？」と問い直します。
• P1 は、希望のリストではなく、近いうちに確実に構築すると見込んでいる項目にします。
• P2 はアーキテクチャ上の保険です。今すぐ構築しなくても、設計上の判断に役立ちます。

成功指標の定義

先行指標

リリース後、短期間（数日から数週間）で変化する指標です。

• 採用率：機能を試す対象ユーザーの割合
• アクティベーション率：主要なアクションを完了したユーザーの割合
• タスク完了率：目標を問題なく達成したユーザーの割合
• 完了までの時間：主要なワークフローにかかる時間
• エラー率：ユーザーがエラーや行き詰まりに遭遇する頻度
• 機能利用頻度：ユーザーがその機能を再び利用する頻度

遅行指標

変化が現れるまでに時間がかかる（数週間から数か月）指標です。

• 継続率への影響：この機能によってユーザーの継続率は向上しますか？
• 収益への影響：アップグレード、利用拡大、新たな収益につながりますか？
• NPS／満足度の変化：この機能によって、製品に対するユーザーの評価は向上しますか？
• サポートチケットの削減：サポートの負荷は減りますか？
• 競合案件の受注率：より多くの案件の受注につながりますか？

目標の設定

• 目標は具体的にします。「採用率が高い」ではなく、「30日以内に採用率50％」とします
• 類似機能、業界のベンチマーク、または明示的な仮説に基づいて目標を設定します
• 「成功」の基準と、ストレッチ目標を設定します
• 測定方法を定義します。使用するツール、クエリ、期間を明確にします
• 評価する時期を指定します。リリース後1週間、1か月、1四半期などです

受け入れ基準

受け入れ基準は、Given／When／Then 形式またはチェックリスト形式で記述します。

Given／When／Then 形式：

• Given [前提条件または状況]
• When [ユーザーが行う操作]
• Then [期待される結果]

例：

• Given 管理者が組織の SSO を設定済みである
• When チームメンバーがログインページにアクセスする
• Then 組織の SSO プロバイダーに自動的にリダイレクトされる

チェックリスト形式：

• 管理者が組織設定で SSO プロバイダーの URL を入力できる
• チームメンバーにログインページで「SSO でログイン」ボタンが表示される
• SSO ログイン時にアカウントが存在しない場合、新しいアカウントが作成される
• メールアドレスが一致する場合、SSO ログインが既存のアカウントに紐付けられる
• SSO ログインに失敗した場合、明確なエラーメッセージが表示される

受け入れ基準のヒント

• ハッピーパス、エラーケース、エッジケースを網羅する
• 実装ではなく、期待される動作について具体的に記述する
• 発生してはならないこと(ネガティブテストケース)も含める
• 各基準は独立してテスト可能であること
• 曖昧な言葉を避ける:「高速」「ユーザーフレンドリー」「直感的」— これらが具体的に何を意味するかを定義する

スコープ管理

スコープクリープの認識

スコープクリープは次の場合に発生します:

• 仕様が承認された後も要件が追加され続ける
• 「小さな」追加が積み重なり、大幅に大きなプロジェクトになる
• チームが誰も求めていない機能を構築している(「ついでにこれも……」)
• 明示的な再スコープなしにローンチ日が何度も先送りされる
• ステークホルダーが何も削除せずに要件を追加する

スコープクリープの防止

• すべての仕様に明示的な非目標を記述する
• スコープの追加には、スコープの削除かタイムラインの延長を伴うことを必須とする
• 仕様内で「v1」と「v2」を明確に分離する
• 元の問題定義に対して仕様を見直す — すべてがそれに資しているか?
• 調査にはタイムボックスを設ける:「X を 2 日で解決できなければ、それは切る」
• スコープ外の優れたアイデアのための「パーキングロット」を作成する