requirements-specification

要件・仕様策定スキル

顧客のインサイトを、エンジニアリングチームが実装できる明確で詳細な仕様に変換します。ユーザーストーリーの作成、受け入れ基準の定義、スコープの徹底的な管理を習得しましょう。

ユーザーストーリーの作成（INVEST 形式）

INVEST の原則

I - Independent（独立している：依存関係が最小限） N - Negotiable（交渉可能：詳細を話し合える） V - Valuable（価値がある：顧客価値をもたらす） E - Estimable（見積もり可能：チームが作業量を見積もれる） S - Small（小さい：1〜2 スプリントで完了できる） T - Testable（テスト可能：成功基準が明確）

ユーザーストーリーのテンプレート

As a [user role]
I want [action/capability]
So that [benefit/outcome]

Acceptance Criteria:
Given [context]
When [user action]
Then [expected result]

良い例と悪い例

悪いストーリー：

As a user
I want a better dashboard
So that I can see my data

問題点：曖昧すぎる、テストできない、範囲が大きすぎる

良いストーリー：

As a project manager
I want to see all tasks assigned to me in the last 24 hours
So that I can track what happened while I was offline

Acceptance Criteria:
Given I'm logged in
When I view the Home dashboard
Then I see a "Recent Tasks" section
And it shows tasks assigned to me from last 24 hours
And tasks are sorted by assignment time (newest first)
And clicking a task opens the task detail page

受け入れ基準（BDD 形式）

シナリオのテンプレート

Scenario: [Specific user action]
Given [initial context/state]
When [user performs action]
Then [expected result]
And [additional verification]

例：パスワードリセット機能

Scenario: User resets password with valid email
Given I'm on the login page
And I'm not logged in
When I click "Forgot Password?"
And enter my email address
And click "Send Reset Email"
Then I see message "Check your email for reset link"
And a password reset email is sent to that address
And the email contains a valid reset link

Scenario: User uses expired reset link
Given I received a password reset email
And the reset link is more than 24 hours old
When I click the reset link
Then I see "Link has expired"
And I'm offered to request a new reset link

Scenario: Password doesn't meet requirements
Given I'm on password reset page
When I enter password "123"
Then I see error "Password must be 8+ characters"
And the form doesn't submit

要件ドキュメントの構成

エグゼクティブサマリー（1 ページ）

• 機能／製品の概要
• ビジネス目標／背景
• 主なメリット
• スケジュール
• 成功指標

要件概要（5〜10 ページ）

機能要件

• システムが実行する必要のあること
• 機能と能力
• ユーザーとのやり取り
• データ処理

非機能要件

• パフォーマンス（応答時間 < 2s）
• スケーラビリティ（同時ユーザー数 10K に対応）
• セキュリティ（PII を暗号化）
• 可用性（稼働率 99.9%）
• アクセシビリティ（WCAG AA 準拠）

ビジネス要件

• 開発する理由
• ビジネス指標
• 顧客のニーズ
• 競争優位性

制約

• 技術的制約
• 予算上の制約
• スケジュール上の制約
• リソース上の制約

ユーザーストーリーとエピック（20〜50 ページ）

構成：

• エピック： 関連するストーリーをまとめた大規模な取り組み
• ユーザーストーリー： 個々の機能（エピックごとに 10〜20 件）
• タスク： エンジニアリング作業の内訳（必要な場合）

各ストーリーに含める項目：

• ストーリー ID とタイトル
• 「〜として、〜したい。なぜなら〜だから」
• 受け入れ基準（3〜8 シナリオ）
• ストーリーポイントの見積もり
• 依存関係
• デザインの参照資料（ワイヤーフレーム／モックアップ）
• 注記／補足説明

ユースケースとフロー（10〜20 ページ）

ユースケースのテンプレート：

Use Case: [Use Case Name]
Primary Actor: [User role]
Precondition: [State before action]

Main Flow:
1. User does X
2. System responds with Y
3. User does Z
4. System returns result

Alternative Flows:
3a. If data invalid
    - System shows error
    - User corrects and resubmits

データモデル（10 ページ）

ER 図

• エンティティ（User、Post、Comment）
• リレーションシップ（User が Post を作成する）
• 属性（Post のタイトル、コンテンツ、creation_date）
• 主キー、外部キー

UI／ワイヤーフレーム（添付）

• ユーザーインターフェースのモックアップ
• ユーザーフローとナビゲーション
• 主な操作

スコープ管理

MVP と「あれば望ましい」機能

MoSCoW メソッド：

MUST Have（必須）

• 中核となる機能
• これらがないと製品が動作しない
• これらを備えてリリースする必要がある
• 例：ユーザーログイン、基本的なコンテンツ表示

SHOULD Have（重要だが必須ではない）

• ユーザー体験を向上させる
• 付加価値をもたらす
• 時間があれば実施する
• 例：高度な検索、保存済みの設定

COULD Have（あれば望ましい）

• 磨き上げのための機能
• 優先度は低い
• 追加の時間／予算があれば実施する
• 例：ダークモード、アニメーション

WON'T Have（明示的にスコープ外）

• 将来対応することを明確にする
• ステークホルダーに「今は対応しない」と伝えやすくする
• 後続バージョンでの対応を計画する
• 例：モバイルアプリ（まずは Web 版をリリース）

スコープクリープの防止

要注意の兆候：

• 「これも追加できますか？」
• 「こうすればもっと良くなるのでは……」
• 「これも含めるのはどうでしょう……」
• 「もう 1 つだけ……」

返答例：

• 「いいアイデアですね。Q2 のロードマップに追加しましょう。」
• 「それには 3 週間かかります。代わりに何の優先度を下げますか？」
• 「それは現在のスコープ外です。次のフェーズに向けて記録しておきましょう。」

変更管理

変更リクエストのプロセス：

1. 変更内容を記録する
2. 影響を評価する（時間、複雑さ）
3. トレードオフを提示する
4. ステークホルダーの判断を得る
5. 要件ドキュメントを更新する
6. チームに共有する

よくある落とし穴

曖昧すぎる

❌ 「パフォーマンスを改善する」 ✅ 「ページの読み込み時間を 4s から 2s 未満に短縮する」

成功基準がない

❌ 「ダッシュボードを作る」 ✅ 「過去 24h のアクティブユーザー数を 95% の精度で表示するダッシュボードを作る」

背景情報が不足している

❌ 「バグを修正する」 ✅ 「特殊文字を使って検索すると結果にエラーが表示される。特殊文字を処理できるように修正する。」

過剰な仕様指定

❌ 「状態管理に Redux と saga ミドルウェアを使用します」 ✅ 「状態の変更を追跡およびデバッグできる必要があります」

受け入れ基準が曖昧

❌ 「システムは高速である必要があります」 ✅ 「API の応答時間は 95 パーセンタイルで 200ms 未満」

要件レビューのチェックリスト

• ✓ 各要件がテスト可能である
• ✓ 実装方法を指定する要件がない
• ✓ 依存関係が特定され、文書化されている
• ✓ 受け入れ基準が明確で、漏れがない
• ✓ エンジニアリングチームが作業量を見積もっている
• ✓ デザインのモックアップが用意されている
• ✓ データモデルが文書化されている
• ✓ エッジケースが考慮されている
• ✓ スコープが明確に定義されている（MVP と今後の対応）
• ✓ 成功指標が特定されている
• ✓ 現実的なスケジュールである
• ✓ エンジニアリングリードによるレビュー済み
• ✓ デザインリードによるレビュー済み
• ✓ ステークホルダー間で合意されている

トラブルシューティング

よくあるエラーと解決策

エラー	考えられる原因	解決策
ストーリーが大きすぎる	エピックとして記述されている	ストーリーを分割する
AC が曖昧	基準が漠然としている	Given/When/Then 形式を使用する
スコープクリープ	変更管理がない	変更リクエストのプロセスを設ける
エッジケースの不足	ハッピーパスに注目している	エッジケースのワークショップを実施する

デバッグチェックリスト

[ ] Her story INVEST criteria geçiyor mu?
[ ] Acceptance criteria testable mı?
[ ] Non-functional requirements tanımlı mı?
[ ] Dependencies documented mı?
[ ] Engineering review yapıldı mı?

復旧手順

1. 要件が曖昧 → 明確化のためのミーティング
2. スコープクリープ → トレードオフマトリックス
3. 実現可能性の検討不足 → エンジニアリングスパイク

---

明確な要件を作成し、プロジェクトの問題の 90% を回避しましょう！