『Scaling Software Agility』(参考記事・英語)の著者であり、RallyでChief Product MethodologistをつとめるDean Leffingwell氏は、ユースケースが大規模のリーン/アジャイルなプロジェクトにおける要求をモデル化する価値のあるツールになりえると結論を下した。リーン/アジャイル（特にXPやスクラム）の文脈では、ストーリーが要求獲得ツールとして使用されていることもあり、ユースケースは一般に出てこない。しかし、Leffingwell氏はこう述べている。
ある程度の規模のシステムを構築する場合、ユーザの相互作用、システムやサブシステムのソリューションを探究するためにユースケースほどの強力なツールはありません。さらに、ユースケース技術は、システムレベルの品質を高めようとする際に我々を悩ませる、代替のシナリオをすべて識別するのを支援することにおいては、最良の方法です。
Leffingwell氏は本とブログの両方で、大規模プロジェクトへのリーン/アジャイルなプラクティスのアプリケーション開発者のためのモデルおよびメタ・モデルを開発したことを記述した。『Agile Enterprise Requirements Information Model』においてユースケースに言及していないことによって、彼は読者と元同僚によって非難された。Leffingwell氏は、ユースケースに言及しなかったことは、２つの根本的な要因によると考えた:ユースケースはRUPと密接な関連を持つと思われているし、RUPはアジャイルでないという先入観があったこと;そして、「ユースケースは詳細過ぎて、顧客に理解しやすいものでない」ということを示すいくつかの例を示した。
結局、Leffingwell氏は最終的には「ユースケースがアジャイルな開発でのユーザー・ストーリーのための置換ではなく、複雑なシステムの意図された振る舞いの獲得、分析、理解に大きな利益を与える」という結論に達した(リンク)。そうして、ユースケースはバックログ・アイテムを獲得するためのオプションの手段としてLeffingwell氏のモデルに加えられた。
- ユースケースはオプションだが、システムが複雑な場合、振る舞いの理解に大きな価値を加えることができる。
- ユースケースは、最終的にシステム品質に大きな影響を与えることになる代替シナリオをすべて理解するのを支援する。
- ユースケースは新しいストーリーがどこで見つかるか推測するために使用することができる。
- また、ユースケースは、大きなシステムでのストーリーごとの優先順位を決める論理的な方法を提供することができる。
アジャイルな開発モデルにユースケースを含むことの根拠はあくまで規模の問題を扱うためであって、ユースケースが要求獲得ツールとしてはオプションのままであることに注目することが重要である。
この記事の時点で、Leffingwell氏のこの書き込みにレスはついていない。この件が読者の関心を集めるか、またこのモデルを使用している他の人が、このユースケースを追加したことが有用であると感じるかどうかの反応は興味深い。
原文はこちらです：http://www.infoq.com/news/2009/02/Use-Cases-Valuable-But-Optional