プロダクト開発と要件定義

目次

• 概要
• プロダクト開発とは何か
• 問題、解決策、仕様を分ける
• ステークホルダーと利用者
• 成果指標と出力指標
• 要件の種類
• ユーザーストーリーとユースケース
• 受け入れ条件
• 優先順位づけ
• 非機能要件
• スコープ管理
• 仮説検証とMVP
• PRDを育てる
• 設計への渡し方
• よくある失敗
• Atlassian ツール群でのアジャイル要件管理
• Scrum.org でのプロダクトゴール実装
• プロダクト開発の失敗パターンと対策
• 受け入れ条件設計パターン
• 要件定義の実装パターン
• 要件管理ツールと連携パターン
• 要件の優先度づけの実装
• よくある失敗とその対策
• プロダクトゴールとScrumにおける役割
• アジャイル要件管理とウォーターフォール要件管理
• 要件定義ドキュメントの構成例
• 要件検証の実装チェックリスト
• まとめ
• 参考文献

概要

何を作るべきかを、実装前に整える

プロダクト開発は、単に機能を増やす活動ではありません。利用者の問題を見つけ、解く価値があるかを確かめ、実装可能な要件へ落とし込む活動です。要件定義はその入口にあり、後続のアーキテクチャ、API設計、UI/UX、テスト、運用設計に強く影響します。

この章で重視すること

• 問題、解決策、仕様を混同しない
• ユーザー価値と実装単位を分けて考える
• 機能要件だけでなく非機能要件も早めに扱う
• 要件を設計、テスト、運用へ渡せる形にする

プロダクト開発とは何か

プロダクト開発は、価値の仮説をソフトウェアとして検証し続ける活動です。

ここで重要なのは、実装がゴールではないことです。リリース後に使われ、学習が得られ、次の判断ができて初めてプロダクト開発のループが回ります。

問題、解決策、仕様を分ける

要件定義でよく起きる混乱は、問題、解決策、仕様が混ざることです。

「ボタンが欲しい」は仕様に近く、「なぜ必要か」は問題に近いです。仕様から始めると、よりよい解決策を見落とすことがあります。

この3つを分けると、議論の戻り先も分かりやすくなります。仕様の細部で意見が割れているように見えて、実際には解決したい問題の認識が違うことがあります。逆に、問題は一致しているのに、最初に出た解決策だけを前提にしてしまい、より小さい実装や運用変更で済む可能性を見落とすこともあります。

要件レビューでは、仕様の前に「これは何の問題を解くのか」「成功したとき何が変わるのか」を確認します。ここが言えない場合、その要件はまだ実装待ちではなく、探索待ちです。

ステークホルダーと利用者

利用者と意思決定者は同じとは限りません。

• 利用者: 実際に画面やAPIを使う人
• 購入者: 予算を持つ人
• 運用者: 障害時に対応する人
• 管理者: 権限、監査、設定を扱う人
• 開発者: APIやSDKを使う人

要件は、誰の成功条件なのかを明示すると衝突を整理しやすくなります。

ステークホルダーマップ

同じ機能でも、関係者ごとに関心は違います。たとえば請求書機能では、経理担当者は作業時間、管理者は承認統制、監査担当者は証跡、顧客は請求内容の分かりやすさを見ます。

要件定義では、すべての要望を同じ重さで扱うのではなく、誰のどの制約を満たす必要があるかを分けます。

成果指標と出力指標

プロダクト開発では、作った量ではなく、利用者や事業に起きた変化を見ます。

Product Goalは、バックログを単なる作業リストにしないための焦点です。Scrum.orgの説明では、Product GoalはProduct Backlogに文脈を与え、進捗を測れる将来状態を表します。したがって「検索画面を作る」より「目的の資料に3クリック以内で到達できる利用者を増やす」の方が、判断に使いやすい目標になります。

弱い目標:
  検索機能を作る

強い目標:
  初回利用者が3分以内に目的の章へ到達できる状態にする

ガードレール:
  検索結果からの離脱率が増えていない
  問い合わせ数が増えていない

成果指標は1つだけにすると危険です。たとえば「問い合わせ数を減らす」だけを追うと、問い合わせ導線を見つけにくくするだけでも達成できてしまいます。そのため、主要指標とガードレール指標を組み合わせます。

指標はリリース後に見るものですが、要件定義の時点で決めておきます。何を測るかが決まっていない要件は、リリース後に学習できません。

要件の種類

要件は大きく分けて、機能要件、非機能要件、制約条件があります。

非機能要件を後回しにすると、アーキテクチャの前提が崩れることがあります。

ユーザーストーリーとユースケース

ユーザーストーリーは価値を短く表す形式です。

誰として
何をしたい
なぜなら

例:

経理担当者として
月末の請求書を一括生成したい
なぜなら手作業の転記ミスを減らしたいから

ユースケースは、開始条件、通常フロー、例外フローまで扱います。画面中心の機能ではユーザーストーリー、業務フローや例外が多い機能ではユースケースが向きます。

ストーリー分割

大きすぎるストーリーは、実装もレビューも検証も重くなります。分割するときは、画面部品ではなく、利用者に届く価値の薄いスライスを探します。

「UIだけ先に作る」「DBだけ先に作る」という分け方は、学習が少なくなりがちです。小さくても利用者の流れが通る単位を優先します。

受け入れ条件

受け入れ条件は、要件が満たされたかを判断する基準です。

Given: 請求対象の注文が3件ある
When: 経理担当者が一括生成を実行する
Then: 3件分の請求書PDFが生成される
And: 生成履歴が監査ログに残る

受け入れ条件はテスト設計への橋になります。曖昧な要件はテストできず、テストできない要件は完了判定ができません。

優先順位づけ

優先順位は「重要そう」で決めるとぶれます。判断軸を分けると扱いやすくなります。

MoSCoW、RICE、Kanoモデルなどの手法は便利ですが、最終的にはチームが同じ判断軸を共有できることが重要です。

プロダクトゴールでバックログを束ねる

バックログは機能リストになりがちです。Product BacklogにはProduct Goalを置き、チームが何に向かっているかを明確にします。Product Goalは将来の状態を表し、Product Backlogの文脈を与えるものとして扱います。

Product Goal:
  請求業務の月末処理時間を50%削減する

Backlog Items:
  - 請求書の一括生成
  - 生成履歴の保存
  - 承認フロー
  - エラー一覧と再実行

この形にすると、個々の機能が「なぜ必要か」を見失いにくくなります。

非機能要件

非機能要件は、後続章と強くつながります。

「速く」「安全に」「使いやすく」では不十分です。測定できる形にします。

非機能要件は、文章の形を少し変えるだけで設計に渡しやすくなります。

非機能要件は、後から追加できるものと、最初の設計に入れないと高くつくものに分かれます。監査ログ、データ保持、権限、マルチテナント、可用性の目標は、あとから継ぎ足すとデータモデルや境界設計に大きく影響します。

仮定と未決事項を要件から分ける

AtlassianのPRD解説では、assumptionsやquestionsを明示し、学習に合わせて更新することが重視されています。要件、仮定、未決事項、スコープ外を同じ箇条書きに混ぜると、何を実装すべきか、何を検証すべきかが曖昧になります。

仮定を要件のように扱うと、間違った前提のまま設計が固定されます。未決事項を放置すると、実装中に仕様の穴として表面化します。

スコープ管理

スコープ管理では、作るものだけでなく作らないものを明示します。

今回やる:
  - 請求書PDFの一括生成
  - 生成履歴の保存

今回やらない:
  - 郵送代行
  - 会計ソフト連携
  - 多言語テンプレート

「やらないこと」は冷たい宣言ではなく、集中するための合意です。

仮説検証とMVP

MVPは「雑に作った最小版」ではありません。最小の学習単位です。

最初から完成形を作るより、最も不確実な仮説を早く検証する方が失敗コストを下げられます。

MVPの種類

MVPは必ずしも実装済みプロダクトである必要はありません。知りたいことによって、検証方法を変えます。

MVPを小さくする目的は、手を抜くためではなく、間違った前提に長く投資しないためです。

PRDは固定仕様書ではなく、合意の置き場

AtlassianのPRD解説では、AgileなPRDは詳細な固定仕様よりも、目的、ユーザー、仮説、設計、未決事項、スコープ外を共有するための軽量な文書として扱われています。要件文書は「一度承認したら終わり」ではなく、学習に合わせて更新されるべきです。

PRDに最低限入れたい項目:

• 背景と目的
• 成功指標
• 対象ユーザー
• ユーザーストーリー
• 受け入れ条件
• 非機能要件
• スコープ外
• 未決事項
• リリース後に見る指標

PRDを育てる

PRDは最初から完全な仕様書にするより、発見、合意、実装、リリース後の学習に合わせて育てます。アジャイル開発で重視される「変化への対応」は、要件を雑に扱うことではなく、変化が起きたときに判断できる材料を保つことです。

チームで作る

Atlassianの文献では、プロダクトオーナーだけが要件を書き、開発者やデザイナーが後から読む形をアンチパターンとして扱っています。顧客インタビュー、ペルソナ、バックログ整理に開発・デザイン・運用が関わると、要件の読み違いが減ります。

プロダクト:
  何を達成したいか

デザイン:
  利用者がどう理解し、操作するか

開発:
  どこに複雑さや制約があるか

運用:
  障害時にどう扱うか

セキュリティ:
  どの権限・監査・データ保護が必要か

PRDが更新されないままチケットだけ増えると、全体の目的が見えにくくなります。逆にPRDにすべてを書き込みすぎると読まれなくなります。役割は「判断に必要な文脈を保つこと」です。

設計への渡し方

要件はそのまま設計にはなりません。設計へ渡すときは、次の情報があるとよいです。

• 利用者と目的
• 成功条件
• 主要フローと例外フロー
• データの作成、更新、削除
• 権限と監査
• 性能、可用性、セキュリティ要件
• 計測したい指標

この形にすると、API設計、UI/UX、テスト、SREの観点に接続しやすくなります。

要件から設計へ渡すときは、1つの文書にすべてを書き込むより、後続の作業で使われる粒度に分けると扱いやすくなります。

この受け渡しが弱いと、要件定義は終わったように見えても、設計や実装の段階で同じ質問が何度も出ます。要件の完成度は、文書量ではなく、後続の判断がどれだけ迷わず進むかで確認します。

よくある失敗

• 解決策を最初から固定する
• 非機能要件を「あとで考える」にする
• ステークホルダー間の成功条件を揃えない
• 例外フローを扱わない
• 完了条件をテスト可能にしない
• リリース後に何を測るかを決めない

Atlassian ツール群でのアジャイル要件管理

Jira Product Discovery での仮説検証

Atlassian の生態系では、要件定義と学習ループの統合が重視されます。

仮説駆動開発のプロセス

Atlassian が提唱する仮説フレームワーク:

We believe [ユーザーグループ]
Will achieve [望ましい成果]
By/Through [実装手段]
We will measure this by [測定方法]

例:

We believe [経理担当者]
Will achieve [月末処理時間を50%削減できる]
By [請求書の一括生成機能]
We will measure this by [月末処理の実績時間を時系列で記録]

この形式を Jira の Epic や Story に組み込むと、実装チームが「なぜこの機能を作るのか」を失わないまま進められます。

Jira での受け入れ条件の記述

Atlassian の Best Practice では、受け入れ条件を構造化することが勧められます:

Given (前提)
When (操作)
Then (期待動作)
And (追加条件)

Jira への具体的な記述例:

Story: 請求書の一括生成
Acceptance Criteria:
  [ ] Given: 月末対象期間内の請求可能な注文が10件存在する
  [ ] When: 経理担当者が「一括生成」ボタンをクリックする
  [ ] Then: 10件分のPDFが順序に生成される
  [ ] And: 生成完了メッセージが表示される
  [ ] And: 生成履歴(ユーザー、日時、ファイル数)が監査ログに記録される
  [ ] And: 生成されたPDFは請求金額を正しく反映している

これを使うと、テストケースの設計が自動的に定まり、完了条件の曖昧さが減ります。

Confluence での要件文書の構造化

Atlassian の Confluence は、PRD や仕様書を動的に保つためのツールです。静的なWordドキュメントと違い、リアルタイム協編集と成長を前提にしています。

推奨される構成:

# プロダクト要件書 (PRD)

## 目的
 - 背景と問題定義
 - ビジネスゴール
 - 成功指標

## 対象ユーザーと成功条件
 - ペルソナ
 - ユースケース
 - ガードレール指標

## 機能要件と受け入れ条件
 - ユーザーストーリー
 - ユースケース図
 - 受け入れ条件 (BDD形式)

## 非機能要件
 - 性能: p95レスポンス、スループット
 - 可用性: SLO目標
 - セキュリティ: 認証、認可、監査
 - 保守性: デプロイ頻度、MTTRターゲット

## API/データモデル仕様
 - エンドポイント一覧
 - 入出力スキーマ
 - エラーハンドリング

## スコープとタイムライン
 - 今回実装する機能
 - 今回実装しない機能 (明示的)
 - マイルストーン

## リスク・未決事項
 - 技術リスク
 - 未決事項と決定予定日

## 後追い確認 (リリース後)
 - 計測する指標
 - A/Bテスト計画
 - ロールバック条件

スコープ管理の実践例

Atlassian の案例では、スコープ外を明示することが紛争を減らすとされています。

今回の実装スコープ:
  [x] 単一テナント環境での請求書生成
  [x] PDF形式での出力
  [x] 管理者による承認ワークフロー
  [x] 生成履歴の保存と検索

スコープ外 (今後の検討):
  [ ] メール自動送信
  [ ] 会計ソフト連携
  [ ] 多言語テンプレート
  [ ] カスタムロゴ埋め込み
  [ ] 月次スケジュール実行

「スコープ外」リストは、ユーザーからのリクエストが来たときの判断軸になります。同じリクエストが複数回来たら、優先度を上げて検討する合図になります。

Scrum.org でのプロダクトゴール実装

プロダクトゴール とバックログの関係性

Product Goal はバックログ全体のコミットメントであり、各Sprint Goal はそこへ近づくための短いステップとして扱います。

Product Goal:
  請求業務の月末処理時間を50%削減し、
  経理担当者の稼働を月5日削減する

Sprint Goal #1:
  請求書の一括生成機能を実装し、
  手動PDF作成業務を廃止できる状態にする

Sprint Goal #2:
  承認ワークフローを実装し、
  複数経理担当者での確認が同時にできる状態にする

Sprint Goal #3:
  監査ログ表示を実装し、
  監査対応時間を30分以内で完了できる状態にする

各 Sprint が Product Goal に向かっていることが見える形になります。

フォーマティブ・サマティブ評価の使い分け

Scrum.org では、プロダクト開発の成功測定を2段階に分けることが推奨されます:

フォーマティブ評価(テスト、レビュー)がなければ品質は保証できません。一方、サマティブ評価(ユーザーメトリクス)がなければ、要件定義が正しかったかを確認できません。

リリース後のメトリクス追跡

Scrum Guide では、Product Goal の達成を確認するために、リリース後のメトリクス測定が重要とされています。Atlassian と Scrum.org の両方で推奨されている観測項目:

リリース直後 (1-2週間):
  - 機能の使用率 (DAU, WAU)
  - エラー率・スタック率
  - サポート問い合わせ数
  - 性能メトリクス (レスポンスタイム)

中期観測 (4-12週間):
  - 目標指標の変化 (処理時間削減など)
  - ガードレール指標の悪化有無
  - ユーザーセグメント別の効果差
  - 利用パターンの想定外の使い方

長期監視:
  - Product Goal 達成度の確認
  - 次のプロダクト課題の発見
  - ユーザーフィードバック収集

プロダクト開発の失敗パターンと対策

パターン1: 要件定義の形式化

失敗: ドキュメントが完成したら要件定義が終わりと考える

対策:

• 要件は「現時点の理解」であり、実装中に質問が出ることは正常
• Sprint中に「未決事項」が解決されることを前提に計画する
• 週1回の要件確認会を設定し、曖昧さをリアルタイムで解決

パターン2: 非機能要件の後付け

失敗: 性能やセキュリティ要件を実装後に追加する

対策:

• 非機能要件は初期段階で粗くても確定させる
• アーキテクチャ決定に直接影響する項目 (スケーラビリティ、キャッシュ戦略など) は特に重要
• 非機能要件ごとに「確認方法」(ロードテスト、監査チェックリストなど) を先に決める

パターン3: 優先順位の不安定性

失敗: リクエストが来るたびに優先順位を変える

対策:

• Product Goal を固定し、それに対する貢献度を判断軸にする
• 「学習価値」を数値化し、小さくても学習が大きい機能を重視
• 優先順位変更の記録と理由を残す

パターン4: ステークホルダー間の成功条件の不一致

失敗: 営業、開発、運用が異なるゴールを持ったまま進める

対策:

• リリース前に成功条件を全員で確認 (Product Review 的な会)
• ガードレール指標で「失敗基準」も一緒に決める
• リリース後の指標確認も全員参加で実施

受け入れ条件設計パターン

正常系と例外フローの両方を書く

Story: 請求書生成機能

正常系:
  [ ] Given: 請求対象データが5件ある
  [ ] When: ユーザーが生成ボタンをクリック
  [ ] Then: 5件の請求書PDFが生成される

例外フロー1 (データ不完全):
  [ ] Given: 顧客情報が不完全な注文が混在
  [ ] When: 生成ボタンをクリック
  [ ] Then: エラーリストが表示され、正常なもののみ生成

例外フロー2 (権限不足):
  [ ] Given: 一般ユーザーがこの機能にアクセス
  [ ] When: 生成ボタンをクリック
  [ ] Then: 「権限がありません」メッセージが表示される

パフォーマンス条件の記述

性能受け入れ条件:
  [ ] 通常時(データ5-100件): p95 < 500ms
  [ ] ピーク時(データ1000件): p95 < 2s
  [ ] 生成中にUIがブロックされない (非同期処理)
  [ ] 1000件以上の場合、バックグラウンドジョブへ自動転送

セキュリティ受け入れ条件

セキュリティ受け入れ条件:
  [ ] 管理者のみが生成履歴を閲覧できる
  [ ] PDFには生成時刻、実行者、対象データ件数が含まれる
  [ ] 生成時に個人情報出力が監査ログに記録される
  [ ] 権限なしユーザーが直URLアクセスを試みたら403が返る

要件定義の実装パターン

パターン1: ユーザーストーリーマッピング

User Story Mappingは、ユーザーの行動フローから要件を抽出する手法です。

ユーザーゴール: 初めての購入を完了する

行動フロー:
  1. ホームから商品検索ページへ移動
  2. 検索キーワードで商品を絞る
  3. 商品詳細を確認する
  4. カートに追加する
  5. 配送情報を入力する
  6. 支払い方法を選ぶ
  7. 注文を確認して完了

各ステップに対応する要件:
  ステップ1-2: 検索インデックス、フィルター機能
  ステップ3: 詳細ページのレイアウト、レビュー表示
  ステップ4-5: カート管理、バリデーション
  ステップ6: 支払いゲートウェイ統合
  ステップ7: 確認メール、在庫確保

パターン2: バリューストリームマッピング

現状フロー (マニュアル請求書処理):
  販売確定 → 営業が手作業で集計 (1-2時間)
           → 経理担当が確認 (30分)
           → PDF生成・メール送付 (30分)
           → 顧客への請求書到着 (翌日)

改善後フロー (自動化):
  販売確定 → システム自動集計 (即座)
           → 承認者向けプレビュー (数秒)
           → 自動PDF生成・メール送付 (数秒)
           → 顧客への請求書到着 (数分)

削減効果: 営業 2時間/件、経理 30分/件、リードタイム 90%削減

パターン3: 非機能要件テンプレート

実装前に非機能要件を明確にすることで、設計・テストの品質が大幅に向上します。

パフォーマンス:
  - ページロード時間: p95 < 1.5秒
  - API応答時間: p99 < 500ms
  - バッチ処理(1000件): 完了時間 < 5分

スケーラビリティ:
  - 同時接続ユーザー数: 10,000
  - データベース記録数: 10,000,000
  - ストレージ: 1TB

信頼性:
  - 可用性: 99.9%
  - MTTR (Mean Time To Recovery): < 15分
  - RPO (Recovery Point Objective): < 1時間

セキュリティ:
  - データ転送: TLS 1.3
  - 認証: OAuth 2.0 or SAML
  - 監査ログ: すべての重要操作を記録

保守性:
  - コード品質: SonarQube A以上
  - テストカバレッジ: > 80%
  - ドキュメント: すべてのAPI に Swagger/OpenAPI

要件管理ツールと連携パターン

Jira での要件管理フロー

Atlassianの Jira では、以下の構造で要件を管理します：

Epic (大目標)
  ├─ Story (機能単位)
  │   ├─ Task (実装作業)
  │   ├─ Task (テスト)
  │   └─ Task (ドキュメント)
  ├─ Story
  └─ Story

例: 請求書自動化プロジェクト

Epic: 請求処理の完全自動化
  Story: 請求書テンプレート管理
    Task: DBスキーマ設計
    Task: テンプレート編集UI実装
    Task: unit test + integration test
    Task: ユーザードキュメント作成

  Story: 自動PDF生成機能
    Task: PDF生成ライブラリ統合
    Task: 品質保証テスト
    Task: パフォーマンステスト
    Task: 運用ドキュメント作成

  Story: 監査ログ機能
    Task: ログスキーマ設計
    Task: ロギング実装
    Task: ログビューア UI
    Task: セキュリティテスト

Confluence での仕様書作成

Confluence は要件の詳細ドキュメント化に使われます：

プロジェクト名: 請求書自動化

├─ Product Vision (全体像)
│  ├─ ビジネス背景と目標
│  ├─ 成功指標
│  └─ リスク・制約

├─ Requirements Specification
│  ├─ User Stories
│  ├─ 画面仕様書 (Mock + 説明)
│  ├─ API仕様 (Swagger)
│  └─ データモデル (ER図)

├─ Design & Architecture
│  ├─ システム設計図
│  ├─ シーケンス図
│  └─ 技術選定の根拠

├─ Testing
│  ├─ テストプラン
│  ├─ テストケース
│  └─ テスト結果

└─ Release Notes
   ├─ 何が変わったか
   ├─ 既知問題
   └─ マイグレーション手順

要件の優先度づけの実装

優先度マトリクス

High Impact / Low Effort (優先実装)
  ├─ ボタン1クリック請求書生成
  ├─ メール自動送付
  └─ 簡易監査ログ

High Impact / High Effort (戦略実装)
  ├─ 複数フォーマット対応
  └─ 海外対応 (多言語・通貨)

Low Impact / Low Effort (検討実装)
  ├─ UI細部のスタイル調整
  └─ オプション機能

Low Impact / High Effort (スキップ)
  ├─ 複雑な承認フロー
  └─ カスタマイズ無限対応

RICEスコアリング

より定量的な優先度付けでは、RICE (Reach, Impact, Confidence, Effort) を使います：

RICE Score = (Reach × Impact × Confidence) / Effort

機能A: 請求書生成自動化
  Reach: 毎月 1000人が使用 = 1000
  Impact: 請求処理時間 90%削減 = 3 (大)
  Confidence: 90% = 0.9
  Effort: 40人日 = 40
  Score = (1000 × 3 × 0.9) / 40 = 67.5

機能B: レポート機能拡張
  Reach: 毎月 100人 = 100
  Impact: 分析効率 50%向上 = 2 (中)
  Confidence: 70% = 0.7
  Effort: 80人日 = 80
  Score = (100 × 2 × 0.7) / 80 = 1.75

優先度: 機能A >> 機能B

よくある失敗とその対策

プロダクトゴールとScrumにおける役割

Scrum.org の定義によれば、Product Goal は Product Backlog に記載される単一の目標であり、Product Owner が明文化し、全 Scrum Team で共有される必要があります。

プロダクトゴールの構成要素

Product Goal の書き方:

弱い例:
  - アプリを改善する
  - ユーザー体験を向上させる

強い例:
  - 初回ユーザーが3分以内に最初のタスクを作成できる状態にする
  - 既存ユーザーの月間利用時間を 50%増加させる
  - API レスポンス時間を p99 で 100ms 以下に削減する

特徴:
  - 測定可能である (定量的)
  - チーム全員で理解可能である
  - 1-3 Sprint で達成可能な規模である
  - ビジネス価値が明確である

プロダクトゴールとスプリントゴールの関係

Product Goal (大目標): 初回ユーザーの成功率を 80% にする

Sprint 1 Goal: オンボーディング画面を実装し、タスク作成フローをシンプル化する
Sprint 2 Goal: 初回チュートリアルを動画化し、理解度テストを追加する
Sprint 3 Goal: エラーハンドリング UI を改善し、ヘルプページを充実させる
Sprint 4 Goal: 初回ユーザーの成功率を計測し、フィードバックを集約する

各 Sprint は Product Goal への段階的な貢献を行う

アジャイル要件管理とウォーターフォール要件管理

Agile アプローチ

Agile では、要件は継続的に発見・更新されるものとして扱われます。

特徴:
  - 要件は段階的に詳細化される
  - ユーザーフィードバックに基づき要件が変わる
  - Sprint ごとに実装・検証を繰り返す
  - 優先度付けは動的である

Agile での要件フロー:
  Product Backlog (粗い)
    ↓
  Sprint Planning (詳細化)
    ↓
  Implementation + Daily Review
    ↓
  Sprint Review (ユーザーフィードバック)
    ↓
  Refinement (要件調整)
    ↓
  次の Sprint へ

ウォーターフォールアプローチ

Waterfall では、要件定義フェーズですべてを決定し、以降は変更を最小限にします。

フェーズ:
  1. 要件定義 (3-6ヶ月)
  2. 設計 (2-4ヶ月)
  3. 実装 (4-8ヶ月)
  4. テスト (2-3ヶ月)
  5. 本番運用

各フェーズで戻らない (あるいは戻ると大きなコスト)

ハイブリッドアプローチ

実務では、両者の利点を組み合わせることが多いです：

全体計画は Waterfall (長期的なロードマップ)
  ├─ Phase 1: 要件定義 (2ヶ月) → 高レベル仕様を固定
  ├─ Phase 2: Agile 実装 (3 Sprint)
  ├─ Phase 3: Agile 実装 (3 Sprint)
  └─ Phase 4: 本番運用

各 Phase 内では Agile (日次のスタンドアップ、2週間 Sprint)

要件定義ドキュメントの構成例

実際のプロジェクトで使われるドキュメント構成です：

1. エグゼクティブサマリー

- プロジェクト名
- ビジネス背景（なぜやるのか）
- 成功指標（何で成功と判断するか）
- スコープと制約
- 概算リソース・期間

2. ユーザー調査とペルソナ

- ターゲットユーザー分析
- ペルソナ定義
- ユースケース図
- ユーザーの痛点と期待

3. 要件仕様

- 機能要件 (User Stories + Acceptance Criteria)
- 非機能要件 (Performance, Security, Scalability)
- システム要件 (OS, Browser, Dependencies)
- 外部システムとの統合仕様

4. 設計とアーキテクチャ

- システムアーキテクチャ図
- データフロー図
- 画面遷移図
- API 設計 (OpenAPI spec)
- データモデル (ER図)

5. テスト戦略

- テストタイプ (Unit, Integration, E2E, Load)
- テストシナリオ
- 成功基準
- テスト環境構成

6. 移行と展開

- 段階的ロールアウト計画
- ロールバック手順
- 移行教育計画
- 運用引き継ぎ

要件検証の実装チェックリスト

プロジェクト開始前に、以下を確認します：

□ Business Case
  □ ビジネスゴールが明文化されている
  □ ROI が計算されている
  □ ステークホルダー間で合意している

□ User Understanding
  □ ターゲットユーザーが特定されている
  □ ペルソナ / シナリオが作成されている
  □ ユーザーリサーチが実施されている

□ Requirements Clarity
  □ 機能要件が User Story で記述されている
  □ Acceptance Criteria が SMART である
  □ 非機能要件が定量的に定義されている

□ Scope Management
  □ Out of Scope が明記されている
  □ スコープの変更プロセスが決まっている
  □ リソース・期間の見積もりがある

□ Design & Feasibility
  □ 技術的な実現可能性が検証されている
  □ リスク分析が完了している
  □ Proof of Concept (PoC) が実施されている

□ Testing & Acceptance
  □ テスト計画が策定されている
  □ 受け入れ基準が関係者で署名されている
  □ UAT スケジュールが決まっている

まとめ

プロダクト開発と要件定義は、実装前の事務作業ではありません。何を解くべきかを明確にし、設計・実装・テスト・運用が同じ方向を向くための土台です。要件がよく整理されているほど、後続の技術判断はぶれにくくなります。

参考文献

公式ガイド・標準

• Scrum.org: Scrum Guide 2020 - Product Goal
• Scrum.org: Introducing the Product Goal
• Scrum.org: Formulating a Product Goal
• Scrum.org: Product Goal

実装ガイド

• Atlassian: Acceptance Criteria
• Atlassian: Product Requirements Document
• Atlassian: What is Agile?
• Atlassian: Agile vs Waterfall

関連トピック

• User Story Mapping
• Impact Mapping
• RICE Scoring
• Lean Canvas