ソフトウェア開発手法は、過去数十年の間に急速に進化し、重い初期のウォーターフォール型文書から、軽量で反復的なアジャイル手法へと移行しました。長期間にわたり、伝統的な「ユースケース」——オブジェクト指向ソフトウェア工学の柱の一つ——は、現代のアジャイルフレームワークスクラムやカンバンのようなものと相性が悪いと見なされてきました。文書中心的で遅いとよく批判されていました。
登場するUse-Case 2.0。イヴァル・ヤコブソン、イアン・スペンス、ブライアン・カーによって提唱された、この現代的なフレームワークは、古典的なユースケースを軽量でスケーラブルで多用途なものに再設計しています。ユースケースの構造的利点とアジャイル開発の柔軟性の間のギャップを埋めるように設計されています。
Use-Case 2.0とは何か？
Use-Case 2.0は、伝統的な要件定義の限界を克服するために特に開発された、ユースケースアプローチの現代的な進化です。前例となる手法が開発開始前に膨大な詳細を要求する傾向があったのに対し、Use-Case 2.0は必須事項、反復的提供、垂直スライシングに注力しています。
このフレームワークの核となる革新は、ユースケースをより小さく、管理しやすい単位に分割できるという点にあります。これらはユースケーススライスと呼ばれます。これにより、チームはシステムアーキテクチャの「全体像」を維持しつつ、スクラム、SAFe、ディシプリンド・アジャイルと互換性のある、小さなスプリント単位での価値提供が可能になります。
6つの基本原則
Use-Case 2.0は、プロセスが軽量かつ価値志向のままであることを保証する6つの指針に基づいています：
- 物語を語ることでシンプルさを保つ：要件は物語志向のままに保つべきです。ユースケースは、システムの使い方に関する物語であり、すべてのステークホルダーにとって理解しやすい形で維持されるべきです。
- 全体像を理解する：フラットなバックログとは異なり、ユーザーストーリーUse-Case 2.0は、簡潔な5～20のユースケースからなる図.
- 価値に注目する：記述されたすべての相互作用は、ユーザーまたはステークホルダーに明確な価値を提供しなければならず、機能の過剰化を防ぎます。
- システムをスライス単位で構築する：これは中心的なコンセプトです。一度に全体のユースケースを構築するのではなく、開発者は垂直スライス単位で実装します。
- システムを段階的に提供する：作業は反復的に行われ、早期かつ頻繁に利用可能なソフトウェアをリリースします。
- チームのニーズに合わせて調整する：詳細さや形式の程度は固定されておらず、プロジェクトの複雑さや規制要件に応じて、必要に応じて拡大または縮小されます。
コアコンセプト：スライスがゲームチェンジャーである
Use-Case 2.0がアジャイルにどう適合するかを理解するには、そのアーティファクトを理解する必要がある。このフレームワークは、過去の重い文書化を、三つの主要な構成要素に簡素化している。
1. 軽量なユースケース
ユースケースは依然として、アクター（ユーザー）とシステム間の目的指向の相互作用を記述する。しかし、バージョン2.0では、初期段階で完全に詳細化されるわけではない。名前と簡単な説明、そして主要成功シナリオに、代替フローと例外に関する詳細が開発の優先順位がつけられたタイミングで「ちょうどその時」に追加される。
2. ユースケーススライス
そのユースケーススライスはこのフレームワークにおける最も重要な革新である。スライスとは、価値の完全なフローを構成するユースケースにおける垂直な断面である。これは物語（ストーリー）の一部、関連するテストケース、および実装に必要なコードを含む。
スライシングにより、単一のユースケース（例：「注文処理」）を複数のスプリントに分けて扱うことができる：
- スライス1：基本的な「ハッピーパス」（標準注文）。
- スライス2：代替パス（割引コード付き注文）。
- スライス3：例外パス（クレジットカード拒否）。
各スライスはバックログ項目として機能する。開発見積もりが可能で、テスト可能であり、イテレーション内で納品可能である。
3. ユースケースモデル
スライスは日々の作業で扱われる一方で、ユースケースモデルは地図として残る。これはすべてのユースケースの集約であり、個々のユーザーストーリーがしばしば欠く文脈とアーキテクチャ的概要を提供する。これにより、チームが何百ものストーリーを完了しても、全体のシステム動作を把握できなくなるという一般的なアジャイルの問題を解決する。
比較：Use-Case 2.0 vs. ユーザーストーリー vs. クラシックなユースケース
多くのチームはユーザーストーリーとユースケースのどちらを選ぶかに悩む。Use-Case 2.0は、選ばなければならないわけではないと主張する。ユースケースの構造とストーリーの柔軟性を両立させている。
| 側面 | クラシックなユースケース（2.0以前） | ユーザーストーリー | ユースケース2.0 |
|---|---|---|---|
| 初期の努力 | 高い（詳細仕様） | 非常に低い | 低い → 漸進的 |
| 全体像の把握 | はい | しばしば失われる | はい（ユースケースモデル経由） |
| 反復的機能 | 悪い | 優れた | 優れた（スライス経由） |
| トレーサビリティ | 強い | 弱い | 強い（テストへ流れ込む） |
| テストへの注力 | 手動 / 後期段階 | 受入基準 | スライスごとに組み込み（TDD） |
| 最適な環境 | ウォーターフォール／構造的 | シンプルなアジャイルプロジェクト | 複雑／企業向けアジャイル |
ワークフロー：ユースケース2.0の実装方法
この手法を採用するには、標準的なアジャイルスプリントにすっきりと収まる循環的なワークフローを実施する必要がある。
- アクターとユースケースを特定する：まず、システムの主要な5～20の目標を整理して、範囲を明確にする。
- 優先順位をつけてスライスする： 高価値のユースケースを選定する。垂直にスライスする（例：基本フローと例外を分ける）。これらのスライスがバックログ項目となる。
- 必要に応じて詳細化する： まだ完全な仕様書を書かないでください。次のイテレーションで選定されたスライスのみを詳細化する。この段階でテストケースやUXノートを追加する。
- 実装とテスト： スライスのコードを開発し、そのスライスに定義された特定のテストケース に対して検証する。Use-Case 2.0はテスト駆動開発（TDD）を強く支援する。
- 統合と段階的進展： 完成したスライスをシステムに統合する。アーキテクチャが進化した場合は、全体のユースケースモデルを更新する。
Use-Case 2.0が現代の開発に適している理由
Use-Case 2.0は、単純なユーザーストーリーでは不十分な企業システム、規制産業、または複雑なドメインにおいて特に効果的である。
それはスケーラビリティを提供する。チームが軽量で始められ、必要に応じてのみ形式を追加できる。また、価値中心を確保する。チームが孤立した技術的タスクではなく、エンドツーエンドのユーザー体験を意識するように強制する。最後に、ドキュメントの負債問題を解決する。ユースケースモデルが反復的に更新されるため、ドキュメントはコードとともに進化し、陳腐なアーカイブではなく「生きている」要件セットとして機能する。