要件定義で迷わない！ユースケース図とユーザーストーリーの使い分け・連携トラブルシューティング

問題: 「商品を検索する」「キーワードで検索する」「カテゴリで絞り込む」など、ユースケースの分割単位がバラバラで、図が見にくくなったり、記述の詳細度が異なったりする。

原因:

• ユースケースを定義する目的（概要把握か、詳細設計か）が不明確。
• 定義担当者の経験や解釈の違い。
• システムの階層構造を意識していない。

解決策:

• 目的の明確化: まず、ユースケース図で何を明らかにしたいのか（例: システム全体のスコープ定義、主要機能の洗い出し、特定の機能領域の詳細化）をチームで合意します。
• 階層化の導入 (レベル分け):
  • 概要レベル (Summary Level): ビジネスの主要な目標やプロセスに対応する大きなユースケース（例: 「商品を注文する」）。
  • ユーザー目標レベル (User Goal Level): アクターが一回のセッションで達成したい具体的な目標に対応するユースケース（例: 「商品をカートに入れる」「配送先を指定する」）。通常はこのレベルを中心に記述します。
  • サブ機能レベル (Sub-function Level): ユーザー目標レベルのユースケースを実現するための補助的な機能や、共通処理（例: 「住所を検索する」「ログイン認証する」）。`<>` や `<>` で表現されることが多いです。
  どのレベルのユースケースを主に記述するかを決め、必要に応じてレベル間を関連付けます。
• ガイドラインの作成: どのような単位を1ユースケースとするかの簡単なルール（例: 「ユーザーが一つの目標を達成する単位」「完了までに数分〜数十分かかる操作」など）を設けます。
• レビューと調整: 定期的にチームでレビューを行い、粒度のばらつきがあれば認識を合わせて修正します。

問題: 「ユーザー」というアクターしか定義されておらず、権限や役割による違いが考慮されていない。または、システム内部のコンポーネントをアクターとして定義してしまう。

原因:

• システムを利用する人物像の解像度が低い。
• アクターは「システムの外側」にあるという原則を理解していない。

解決策:

• ペルソナの活用: 具体的なユーザー像（ペルソナ）を設定し、そのペルソナがシステムに対してどのような役割や権限を持つかを明確にします。（例: 「一般会員」「プレミアム会員」「管理者」「店舗スタッフ」など）
• 役割ベースでの定義: 人物ではなく、システムに対する「役割」でアクターを定義します。（例: 「コンテンツ閲覧者」「コンテンツ投稿者」「システム管理者」）一人の人物が複数の役割を持つこともあります。
• 「外部」の意識: アクターは常にシステムの「外」にいる存在であることを確認します。システム内部のデータベースやモジュールはアクターではありません。外部の連携システム（API提供元など）はアクターになり得ます。
• アクターの汎化/特化: 共通の操作を持つアクターは汎化（例: 「会員」を基底とし、「一般会員」「プレミアム会員」を特化）で表現することも有効です。

問題: ユースケース図は描けたが、それを補完するユースケース記述（シナリオ）がうまく書けない。特に、正常系（基本フロー）だけでなく、エラー処理（例外フロー）や代替フローの考慮が漏れてしまう。

原因:

• 記述フォーマットが決まっていない、または使いこなせていない。
• シナリオを網羅的に洗い出すための観点が不足している。
• 正常系のハッピーパスしか想定していない。

解決策:

• テンプレートの活用: 標準的なユースケース記述のテンプレート（例: Cockburnスタイル、RUPスタイルなど）を導入し、項目（ユースケース名、アクター、事前条件、事後条件、基本フロー、代替フロー、例外フローなど）を埋める形で記述を進めます。これにより、記述の標準化と考慮点の明確化が図れます。

  
  ユースケース名: UC-001 商品を注文する
  アクター: 会員
  事前条件:
  - 会員がログインしている。
  - カートに商品が1つ以上入っている。
  事後条件(成功時):
  - 注文情報が記録される。
  - 在庫数が更新される。
  - 会員に注文確認メールが送信される。
  事後条件(失敗時):
  - 注文情報は記録されない。
  基本フロー:
  1. アクターは「注文手続きへ進む」ボタンをクリックする。
  2. システムは注文内容確認画面を表示する（配送先、支払方法、商品リスト、合計金額）。
  3. アクターは配送先、支払方法を選択・確認し、「注文を確定する」ボタンをクリックする。
  4. システムは在庫を確認し、引き当てを行う。
  5. システムは決済処理を行う（外部決済システム連携）。
  6. システムは注文情報をデータベースに保存する。
  7. システムは注文完了画面を表示し、注文番号を通知する。
  8. システムはアクターに注文確認メールを送信する。
  代替フロー:
  A1: 配送先を変更する場合 (ステップ3)
    1. アクターは「配送先を変更」ボタンをクリックする。
    2. システムは配送先一覧・新規登録画面を表示する。
    3. アクターは配送先を選択または新規登録する。
    4. システムは注文内容確認画面に戻り、選択された配送先を表示する。
  例外フロー:
  E1: 在庫不足の場合 (ステップ4)
    1. システムはエラーメッセージ（「申し訳ありません。商品Xの在庫が不足しています。」）を表示する。
    2. ユースケースは終了する（注文は確定されない）。
  E2: 決済エラーの場合 (ステップ5)
    1. システムは決済エラーメッセージ（例: 「クレジットカードが無効です。」）を表示する。
    2. アクターに支払方法の再選択または修正を促す。ユースケースはステップ3に戻る。
                  

• シナリオベースでの記述: まず基本フロー（最も一般的で正常な流れ）を記述し、その後、各ステップで起こりうる分岐（代替フロー）やエラー（例外フロー）を洗い出していきます。「もし〜だったら？」「〜が失敗したら？」と自問自答するのが有効です。
• CRUDLの観点: データに対する操作（Create, Read, Update, Delete, List）の観点から、各操作で必要なフローやエラー処理がないかを確認します。
• 非機能要件の考慮: 性能要件（レスポンス時間）、セキュリティ要件（不正アクセス防止）、可用性要件（エラー時の復旧）などを念頭に置き、それらに関連する例外フローがないか検討します。（例: タイムアウト処理、アクセス権限チェック）
• レビュー: 開発者、テスター、ビジネス担当者など、複数の視点からレビューを行い、考慮漏れがないかを確認します。特にテスターは例外ケースを見つけるのが得意です。

問題: ユースケースやアクターの数が多くなりすぎたり、`<>` や `<>` を多用しすぎたりして、図がスパゲッティ状態になり、かえって分かりにくくなる。

原因:

• 一つの図に全ての情報を詰め込もうとしている。
• ユースケースの粒度が細かすぎる。
• `<>` / `<>` の使い方が適切でない、または乱用している。

解決策:

• パッケージ化: 関連性の高いユースケース群を「パッケージ」としてグループ化し、図を分割します。全体像を示す図と、各パッケージの詳細図を作成します。
• 図の目的を絞る: 全てのユースケースを一枚の図に描くのではなく、特定の機能領域や主要なアクターに焦点を当てた図を作成します。
• 粒度の見直し: 細かすぎるユースケースは統合するか、より上位のレベルで表現することを検討します。（トラブル1参照）
• `<>` / `<>` の使用制限: これらの関係は図を複雑にする要因になりやすいため、本当に必要な場合に限定して使用します。特に `<>` は条件分岐が多くなりがちなので注意が必要です。共通処理は `<>` で括り出すのが基本ですが、多用すると依存関係が複雑になります。無理に使わず、ユースケース記述側で補完することも検討します。
• 主要ユースケースに絞る: プロジェクト初期段階や概要説明では、システムのコアとなる重要なユースケースに絞って図を作成し、詳細は別途記述や議論で補います。

問題:

• ストーリーが大きすぎて（Epicと呼ばれることも）、1回のイテレーション（スプリント）で完了できない、見積もりが困難。例: 「ECサイトを作る」
• ストーリーが小さすぎて（タスクに近い）、ユーザー価値が見えにくい、管理が煩雑になる。例: 「ボタンの色を青にする」

原因:

• 適切な粒度の感覚が掴めていない。
• 機能をどのように分割すれば価値を提供できるかの判断が難しい。

解決策:

• INVEST原則の活用: 良いユーザーストーリーの特性とされるINVEST原則に照らして、ストーリーを見直します。
  • Independent (独立している): 他のストーリーになるべく依存しない。
  • Negotiable (交渉可能である): 詳細が固定されておらず、対話によって具体化できる。
  • Valuable (価値がある): ユーザーまたはビジネスにとって明確な価値を提供する。
  • Estimable (見積もり可能である): 開発工数を見積もることができる程度の大きさ。
  • Small (小さい): 1イテレーション（通常1〜4週間）で完了できる程度の大きさ。
  • Testable (テスト可能である): 受け入れ基準を定義し、完了を確認できる。
  特に「Small」と「Estimable」が粒度の判断に役立ちます。1イテレーションで終わらない大きなストーリー（Epic）は、より小さなストーリーに分割します。
• 分割パターンの利用: 大きなストーリーを分割する際の一般的なパターンを活用します。
  • ワークフローのステップで分割: 例：「商品を検索する」「商品詳細を見る」「カートに入れる」「注文を確定する」
  • 操作（CRUD）で分割: 例：「商品マスタを登録する」「商品マスタを編集する」「商品マスタを削除する」
  • 役割（アクター）で分割: 例：「一般会員として注文する」「管理者として注文を管理する」
  • ハッピーパスと例外パスで分割: 例：「正常に注文を完了する」「在庫切れ時の処理」
  • 非機能要件で分割（ただし価値が見えにくい場合も）: 例：「検索結果を1秒以内に表示する」
• ストーリーマッピングの活用: ユーザーストーリーを時間軸や優先度でマッピングする手法（ユーザーストーリーマッピング）を用いることで、全体像を把握しつつ、適切な粒度でのリリース計画（分割）を検討しやすくなります。
• チームでの対話と調整: 開発チームとプロダクトオーナーが協力し、ストーリーの大きさについて認識を合わせ、分割や統合を繰り返します。

問題: ユーザーストーリーは書かれているが、具体的に何ができれば「完了」とみなせるのかが不明確。これにより、開発者の実装内容が要求とずれたり、テストができなかったりする。

原因:

• 「完了」の定義がチーム内で合意されていない。
• 受け入れ基準を具体的に記述するスキルや習慣がない。

解決策:

• 具体的な基準の記述: 各ユーザーストーリーに対して、そのストーリーが完了したと判断するための具体的な条件（受け入れ基準）を複数記述します。箇条書き形式や、振る舞い駆動開発（BDD）のGiven-When-Then形式などがよく用いられます。

  例（箇条書き）: ユーザーストーリー「会員として、過去の注文履歴を一覧で見たい」

  • 注文履歴ページにアクセスできる。
  • 注文日、注文番号、合計金額、ステータスが表示される。
  • 注文日の降順で表示される。
  • 一覧から各注文の詳細画面に遷移できる。
  • 自分の注文のみが表示される。

  例（Given-When-Then）:

  
  Feature: 注文履歴の表示
  
    Scenario: 会員が自分の注文履歴を確認する
      Given 私はログイン済みの会員である
      And 私には過去の注文が3件存在する
      When 私が注文履歴ページを開く
      Then 3件の注文が一覧で表示される
      And 各注文には注文日、注文番号、合計金額、ステータスが表示されている
      And 注文は注文日の降順で並んでいる
                  

• テスト可能な基準: 受け入れ基準は、客観的に「Yes/No」で判断できる、テスト可能な形で記述します。「使いやすいこと」「きれいなこと」といった主観的な表現は避けます。
• プロダクトオーナーと開発チームの協力: 受け入れ基準は、プロダクトオーナー（要求を出す側）と開発チーム（実装・テストする側）が協力して作成・レビューし、認識を合わせることが重要です。
• 「完了の定義 (Definition of Done)」の共有: チーム全体で、どのような状態になればストーリー（あるいはタスク、イテレーション全体）が「完了」したとみなすかの共通認識（例: コードレビュー済み、テスト済み、デプロイ済みなど）を持っておくことも有効です。

問題: ユーザーストーリーの「so that [理由・価値]」の部分が書かれていない、または「〜ができるように」といった機能説明の繰り返しになっており、その機能がなぜユーザーやビジネスにとって重要なのかが分からない。

原因:

• ユーザーストーリーの形式だけを真似て、本質的な価値の探求ができていない。
• ユーザーへのヒアリングやビジネスゴールの理解が不足している。

解決策:

• 「なぜ？」の問いかけ: その機能（I want）を実装することで、ユーザー（As a）は最終的に何を得られるのか、どのような問題が解決するのか、ビジネス上の目標にどう貢献するのかを深く問いかけます。「なぜそれが必要なのか？」を5回繰り返す（なぜなぜ分析）なども有効です。
• ユーザーへのヒアリング・観察: 実際のユーザーにインタビューしたり、利用状況を観察したりすることで、彼らが本当に求めている価値や抱えている課題を理解します。
• ビジネスゴールとの整合性確認: プロダクト全体のビジネス目標やKPIと、個々のユーザーストーリーがどのように関連しているかを意識します。価値が見えないストーリーは、優先度を下げるか、実施を見送る判断も必要です。
• プロダクトオーナーの役割の明確化: ユーザーやビジネスの視点から価値を定義し、開発チームに伝えるのはプロダクトオーナーの重要な役割です。プロダクトオーナーがこの点をしっかり意識し、言語化する努力が求められます。

問題: ユーザーの要望だけを記述した結果、現在の技術やアーキテクチャでは実現が非常に困難、あるいは不可能なユーザーストーリーが作られてしまう。

原因:

• ユーザーストーリー作成時に、開発チームのインプットが不足している。
• プロダクトオーナーが技術的な制約を理解していない。

解決策:

• 早期からの開発チームの関与: ユーザーストーリーを作成する初期段階から、開発チーム（エンジニア、デザイナーなど）を巻き込みます。アイデア出しや実現可能性の検討、技術的な代替案の提示などを協力して行います。
• リファインメント（バックロググルーミング）の実施: 定期的にプロダクトオーナーと開発チームが集まり、ユーザーストーリーの内容、価値、受け入れ基準、そして実現可能性や見積もりについて議論し、ストーリーを洗練させていく活動（リファインメント）を行います。
• スパイク (Spike) の導入: 技術的な実現可能性や最適なアプローチが不明確な場合、調査や試作のためだけの短い時間枠（スパイク）を設けて、ユーザーストーリーの実装前にリスクを低減します。スパイクの結果、ストーリーが分割されたり、内容が変更されたりすることもあります。
• 技術的負債の考慮: 無理な要求を通そうとすると、場当たり的な実装（技術的負債）を生み、将来の開発速度を低下させる可能性があります。長期的な視点で、技術的な健全性も考慮した上でストーリーの実現方法を検討します。