この記事の説明

アジャイル開発においてはユーザーストーリーが設計書代わりになる。

この記事ではユーザーストーリーとはどのようなものなのかの説明と、どうすればユーザーストーリーを作り上げることができるのかの解説を行う。

この記事の説明
- 参考書籍:アジャイルサムライ
ユーザーストーリーとは
なぜユーザーストーリーなのか？:無駄な工程である文書化を防ぐため
良いユーザーストーリーの書き方
まとめ
- 備考

参考書籍:アジャイルサムライ

この記事は次の書籍を参考にしています。

アジャイルサムライ(オーム社出版)

https://www.amazon.co.jp/アジャイルサムライ−達人開発者への道−-Jonathan-Rasmusson/dp/4274068560

ユーザーストーリーとは

ユーザーストーリーとは顧客がソフトウェアで実現したいと思っているフィーチャーを簡潔に記述したものだ。

記述する媒体は小さい付箋やカードなどで、それの集合がユーザーストーリーの原型となる。(この付箋やカードのことをフィーチャーと呼ぶ）

以下はユーザーストーリーの一例である。

ここで大事なのは、フィーチャーを書く際に製品の本質を捉えるキーワードになりそうなものを書き溜めておくことである。したがって、フィーチャーは思いついたばかりのものでもよく、本当に必要になるかはまだわからない。要求を事細かに聞き出す必要はない。だから、ストーリーを書いてすぐの時点では、検討する時間とエネルギーを節約しておこう。

このカードのことをインデックスカード(またはフィーチャー)と呼ぶ

なぜユーザーストーリーなのか？:無駄な工程である文書化を防ぐため

実際のソフトウェアプロジェクトで、重厚な文章が要求を捉える手段として本当にうまく機能したことなんて一度もないと言っていい。

しかも、ソフトウェアへの要求を表現する手段として文書に頼りすぎることの弊害はそれだけではない。

変化に対応できない

例）顧客「確かにそう言ったわ！でもそれって半年前のことよ！」

顧客の欲しいものに合わせるのではなく、仕様に合わせて作ることになる

例）顧客「こっちがいいわ！」PM「でもそれ仕様と矛盾しますよね」

多くの時間を無駄にする

例）上司「この3ヶ月の要件定義書な、変更になったから変えてくれ」

言葉で全ては表せない

例）私は彼女がお金を盗んだとは言っていない

この文章は別の文脈になりかねない

私は、彼女がお金を盗んだとは言っていない

私は彼女が、お金を盗んだとは言っていない

結論：文章に頼りすぎてはいけない

文章ではなく、もっと別の何かが必要となる。それこそがユーザーストーリーなのだ。

良いユーザーストーリーの書き方

ユーザーストーリーがプロジェクトにどんな省エネをもたらすかを把握できたと思う。次は、どうユーザーストーリを書けば良いのかについて解説する。

良いユーザーストーリーの条件は次の6つだ

顧客にとって何かしらの価値がある
独立している
交渉の余地がある
テストできる
小さく見積もれる
顧客が作成する

良いユーザーストーリの条件:顧客にとって何かしらの価値がある

良いユーザーストーリーの例

よくできたユーザーストーリーの書き方は以下の通り

ユーザーがアカウントを作成する
新規物件が投稿されたらメーリングリストに通知される
メーリングリストの購読を停止できる

このレベルで良い。

悪いユーザーストーリーの例

逆に以下のようなユーザーストーリーは好まれない

C++
コネクションプーリング：データベースの接続はなるべく高速化
MVCパターン

ユーザーストーリーを書く際には、顧客にとって何かしらの価値があるかどうか まずは大事なポイントである。 お客さんがワクワクするようなストーリーを書こう

ユーザーストーリーの条件2:独立している

必ずしもストーリーがお互いに独立させれるわけじゃないが、ストーリーを抽出する時にはできるだけエンドツーエンドの切り口の単位にした方が良い。なぜならプロジェクトには変化がつきものであるため、大事だった要件がどうでもよくなることがよくある。独立性を高めることで、必要に応じてスコープを自在に調節できるのもアジャイルのコツだ。

良いサンプルを見てみよう

これらの要件は全て独立している。

ユーザーストーリーの条件3:交渉の余地がある

ストーリーに交渉の余地があった方がいいのは、予算の範囲内に治るかどうかをある程度融通が聞くようにできるからだ。

ユーザーストーリーの条件4:テストできる

テストできるようになっているユーザーストーリーは素晴らしい。

というのも、どのようになっていればきちんと動いているかがわかるからだ。

ユーザーストーリの条件5:小さく見積もれる

完了の状態を「リリース可能な状態」と定義した時、そのユーザーストーリーはどれくらいのイテレーションに収まりそうだろうか？判断は難しいだろうが、ストーリーを小さくしておけば、1~2週間といったイテレーションの範囲に収まりそうかどうかはわかるはずである。それぐらいのサイズであれば、見積もりも可能になるはずだ。