よいユーザーストーリーとユーザストーリーの分割

　
6/25 に開催された「アジャイルサムライ読書会 at 大阪道場」にて

・よいユーザーストーリーとはなにか？
・ユーザーストーリーをうまく分割するには？

というテーマでディスカッションがあった。

ふたつのテーマではあったが、結果的にユーザーストーリーの分割に議論が集中した。
巨大なユーザーストーリーをどうすれば、分割することができるか？
分割しづらい一連の処理をいかにして分割していけばよいか？　喧々諤々…

難しい問題で、うちに帰ってからも色々と考えてみた。

そもそも、ユーザーストーリーとは

私の解釈は、ユーザーに価値をとどける単位。リリースできる、リリースする単位。

『アジャイルな見積りと計画づくり』には、ユーザーストーリーの定義として以下のようにある（P50）。非常にわかりやすい表現だと思う。

ユーザーストーリーは、システムについてユーザーまたは顧客の視点からフィーチャーの概要を記述したものだ。

また、続けてユーザーストーリーをまとめる指針として

ユーザーストーリーには形式が定められておらず、標準的な記法もない。とはいえ、次のような形式でストーリーを考えてみると便利である。「＜ユーザの種類＞として、＜機能や性能＞がほしい。それは＜ビジネス価値＞のためだ」という形のテンプレートに従うと、たとえば次のようなストーリーが書ける。「本の購入者として、ISBNで本を検索したい。それは探している本を素早く見つけるためだ」

とある。

「ユーザーまたは顧客の視点」というのが重要な要素だと思う。

ユーザーストーリーとタスクの違い

ユーザーストーリーを分割していくと、最終的にはタスクに落とし込まれる。
ユーザーストーリーは複数のタスクから構成されて、すべてのタスクが完了すればユーザーストーリーも完了となる。

一方で、ユーザーストーリーは分割して、小さなユーザーストーリーの集合とすることも可能だ。
では、小さなユーザーストーリーとタスクの違いはなにか。

一番の違いは、完了することでユーザーにとっての価値が生まれるかどうかだと思う。
タスクはどんなに大きいものであっても、内部作業である。開発者の自己満足みたいなもの。
タスクをいくらこなしても、それが結びついているユーザーストーリーとして完了していない場合はユーザーにとって価値が生まれない。

だからこそ、MVP（Minimum Viable Product：最低限実行可能なプロダクト）をまず作り出して、そこからインクリメントに開発していくことが重要視される。
多くのタスクを一気にこなすことが素晴らしいのではなく、早く継続的にユーザーストーリーを完了させていくことの方が大切。

可能であれば、「ユーザーストーリー＝タスク」となるように分割できるといい。
目の前のタスクをひとつ完了すれば、価値が生まれるわけだから。

ユーザーストーリーを分割するということ

『アジャイルな見積りと計画づくり』の12章には「ユーザーストーリーの分割」という題で詳しく述べられている。
（読書会の次の日にたまたま開いたのがこの章でビックリした。ドンピシャの内容だった…）

ストーリー分割に適用できるガイドラインが紹介されているのだが、各節のタイトルを書きだしてみる。

１．ユーザーストーリーをいつ分割するか
２．データの境界に沿って分割する
３．操作の境界で分割する
４．横断的な関心事を分割する
５．パフォーマンス制約をストーリーにする
６．優先度に沿ってストーリーを分割する
７．ストーリーをタスクに分解してはならない
８．関連する変更への誘惑を断つ
９．ストーリーをまとめる

タイトルだけ見ても、なにかつかめるところはある。「７．ストーリーをタスクに分解してはならない」なんて、ここまでで書いてきたことと重複している…

ユーザーの要求を一度に丸々と解決する必要はないということだ。
逆にいえば、自分で一度にやらないといけないと勝手に思い込んでいることが多々あるかもしれない。
そうではなく、ユーザー視点を思い出して、インクリメントに作り上げていけばいいことがよくわかる。