Murali Krishnaはこう言う(リンク)。
アジャイル開発へ効果的に移行できないという失敗は、ユーザストーリーが何たるかを理解できていないという根本的な失敗に根ざしていることが多い。
ユーザストーリーの最も重要な側面は、ユーザストーリーが要件（機能）の「スケジュール可能な」ユニットであり、スケジュールは他に依存していないということです。ユーザストーリーの「他に依存せずスケジュール可能な」特徴を実現する鍵となるのが、「ユーザ」がどう使うかという目線に立ってユーザストーリーを表現することです。そうすればユーザが実際にインタラクトできるエンドツーエンド（UIからバックエンド）に実装された機能性のユニットが手に入ります。
Krishnaはアジャイルコミュニティで多数の人々が信じている「ユーザストーリーは唯一、最良のよりどころ」を正確に描写し、Mike Cohnによる「Advantages of User Stories for Requirements(リンク)」（ユーザストーリーを要件に使用する利点）というタイトルの記事に目を向けさせてくれる。Cohnはユーザストーリーを次のように定義している。
各ユーザストーリーには3つの側面があります。
- ストーリーの説明を書き記したもので、計画やリマインダとして使用します
- ユーザストーリーの詳細を肉づけする役割を果たす、ユーザストーリーについての会話
- ストーリーの完結時期を決定するために使用可能な詳細を伝達し、記録するテスト
続いてCohnは、ユーザストーリーをもう1つの有名な要件テクニックであるユースケースと明確に対比させている。
ユーザストーリーは、ユースケースや従来の要件ステートメントと同じ特徴を示すことがあるので、ユーザストーリーがこうした初期の要件テクニックと相違している箇所に注目することが大切です。こうした相違が、ユーザストーリーに多数の利点をもたらすことがあるのです。
ユーザストーリーでは話し言葉によるコミュニケーションが重視されます。書き言葉は非常に不明確なことが多く、顧客と開発者がひとつのステートメントを同じように解釈するという保証がありません。たとえば、最近の昼食でメニューに次のような文章を見つけました --「メインディッシュのセットメニューとして、スープあるいはサラダとパンから選べます」
理解に苦しむ文章ではないはずですが、実際はそうでした。次のうちどちらを選べるのでしょう？
- スープもしくは（サラダとパン）
- （スープもしくはサラダ）とパン
私たちは書き言葉が明確であるかのように振る舞いますが、そうでないことが多々あるのです。メニューに書かれた言葉と、ウエートレスが話す「スープとサラダのどちらになさいますか」という言葉を比べてみてください。さらによいことに、ウエートレスは私の注文をとる前にパンの入ったかごをテーブルの上に置き、紛らわしさをすべて取り払ったのです。
そう、ユーザストーリーの方が優れていることはかなりはっきりとしているようである。しかし本当にそうなのか。私たちのコミュニティのAlistair Cockburnという人物も、有名で尊敬されているが、Cockburnはいまだにユースケース(リンク) を利用している。彼はこれまでの経験から、ユーザストーリーの使用にはこんな問題がある、と以下を挙げている。
- デザイナーはユーザストーリーとバックログアイテムから、「ユーザがこれを行うのはいつか」、「そのオペレーションのコンテキストは何か」、「その瞬間のより大きな目標は何か」といった、仕事にとりかかるためのコンテキストを得ることはありません。
- プロジェクトチームはユーザストーリーとバックログアイテムから、「完結」感を得ることはありません。開発チームは（たとえば）270のストーリーポイントでプロジェクトに値をつけ、評価をしているのですが、私がこれまでに何度も気づいたのは、プロジェクトが機能し始めるや否や、ストーリーポイントの数が表面上、限界なしに増加し続けるということです。これには開発者も、スポンサーも憂鬱になります。このプロジェクトは一体どれほど巨大なのでしょう？
- 完結性に関係することですが、ユーザストーリーとバックログアイテムによって、近々担当しなければならない仕事の難しさを見越せるようなメカニズムがもたらされることはありません（原則では可能なはずですが、実際にもたらされることはありせん）。次のような苦情を何度も耳にしています。「顧客（プロダクトの所有者）に質問したところ、回答を得るまでに2週間もかかりました。この役割に適さない人が担当しているに違いありません。」 いいえ、適さない人が担当しているのではなく、プロセスが壊れているのです -- ある種の質問には長期間の調査が必要になります。なぜなら、恐ろしくたくさんの人々にとってバランスのとれた正しい答えを導き出そうと、様々な部門やユーザグループが苦労しているからです。ユースケースで拡張条件一式から始めれば、アナリストはどれが容易で、どれが難しいかを見抜くことができ、それに従って調査を計画できます。ユーザストーリーとバックログアイテムはそうした査定に向けて、十分早い段階にそれほどの精度で設計されていないのです -- 拡張条件が検知されるのはスプリントの中頃で、それでは遅すぎるのです。
Cockburnは次に、「ユーザストーリーではいけない理由」を踏まえて、「ユースケースが好ましい理由」に焦点を当てている。
- システムによりビジネスとユーザにどういった貢献がもたらされるか、を非常に短く要約して重役に教えてくれるのが、ゴール名のリストです。このリストはさらに、初期の優先順位や見積もり、チームの割り当て、時間調整の構築に使用するプロジェクト計画の骨子ともなります。これが完結性に関する問題の最初の部分です。
- 各ユースケースの主な成功シナリオにより、「システムが基本的に行う予定のこと」、時にはそれより重要となる「システムが行わないこと」について、全関係者が同意します。それぞれの特定行項目の要件にコンテキストを提供しますが、このコンテキストは他では非常に入手困難なのです。
- 細かなやっかい事には開発時間と予算の80%をなぜかしら費やしてしまうものですが、要件アナリストは各ユースケースの拡張条件により、こうしたやっかい事のすべてを調査するためのフレームワークを手に入れます。先を見越すメカニズムが手に入るので、顧客/プロダクト所有者/ビジネスアナリストは、回答を得るのに長時間を要しそうな問題を見つけ出すことができます。こうした問題のスケジュールは繰り上げるべきであり、そうすれば開発チームがその問題に対処する時間ができたとき、すでに回答が用意できていることになります。ユースケースの拡張条件は、完結性の問題の第2の部分にあたります。
- ユースケース拡張シナリオのフラグメントにより、プログラマーが尋ねるビジネスに関する細かい、そしてしばしば微妙な質問に対する回答がもたらされます。プログラマーは次のような質問をします -- 「このケースでは何をすることになっているのでしょう。」（通常返ってくる答えは、「わかりません。そのケースについては考えたこともありません」です）。つまり、プログラマーが問題を熟考するのに役立つ「if...then...elseステートメント」に匹敵する、思考/記録フレームワークなのです。この場合はプログラミング時ではなく、調査時に行われるという時間的な相違があるだけです。
- 完全なユースケース一式は、全ユーザのニーズ、システムに関してユーザが持っている全ゴール、関係のあるビジネス上の全バリアントについて、調査者がとことん考えたことを示しています。これが完結性に関する問題の最後の部分です（私はクライアントと一緒に腰を据えて、実際に240個のユースケースをウォークスルーしたことがあります。最後にクライアントに「これで全部ですか？」と尋ねたところ、「全部です」という答えが返ってきました。このユースケースは私たちが構築して引き渡したもので、すでに報酬も受けているのに、10年経ってもまだ使われているのです）。
状況は思っていたほど明快ではない。何をすればいいのか？ 私たちが行っていることは、私たちのためになっているのか？ 正しい方法は1つか？ 2つあるのか？ それとも、コンテキストによって左右されるのか？ 状況によってはユースケースが適切で、別の状況ではユーザストーリーが適当なのか -- どちらなのか？ ひょっとして、この2つには実はそれほど違いはないのではないか -- ユースケース・シナリオの外観や感触、存在がユーザストーリーに似ているので、ユースケースには（おそらく）ユーザストーリーがいくつか内包されているのではないか？
原文はこちらです：http://www.infoq.com/news/2008/07/use-case-or-user-story