フクロウの図表ラボ

”INVEST”とは

2003年にBill Wakeという人物によって提唱された、ユーザーストーリーの品質を評価する基準としてグローバルに広く採用されているものです。（こちらがその当時の記事です。）その後、2004年にそのテクニックがMike Cohnの“User Stories applied“の中で紹介・推奨され広まりました。

INVESTの項目は以下の通りです。

• Independent（独立している）
• Negotiable（交渉可能）
• Valuable（価値がある）
• Estimatable（見積もり可能）
• Small（小さい）
• Testable（テスト可能）

ユーザーストーリーを作るときには、これらの項目をクリアしているかどうかを意識しながら作ると良い。逆にこれらの要素を満たしているかどうかで、それが良いユーザーストーリーかどうかが判断できる、という基準になります。

”INVEST”の詳細

さらに個々の要素を細かく整理すると以下のようになります。

I	”独立している” そのユーザーストーリーが他のユーザーストーリーとは別に単独で存在していても意味があることを指します。この性質によって、そのユーザーストーリーを必要に応じて自由に再配置することができます。
N	”交渉可能” ユーザーストーリーは開発チームとクライアントが必要に応じて最善策でなく次善策も選択できるように、十分に一般的であるべきです。特定の技術的な詳細に踏み込むのではなく、要求の最も重要な点は何かを明らかにしましょう。
V	”価値がある” ユーザーストーリーはクライアントに価値を提供する必要があります。
E	”見積もり可能” ユーザーストーリーの要件を設計し、実装するのにかかる時間を見積もることが可能（な程度に要件が明確）でなければならない。
S	”小さい” ユーザーストーリーは短期間で開発することを想定しているため、小さくなければなりません。また、要件を設計し実装する時間が不透明な場合もユーザーストーリーは大きすぎる可能性があります。
T	”テスト可能” ユーザーストーリーは、それが「完了」したかどうかを判断するために、一連の基準に照らして検証可能である必要があります。（いわゆる”Doneの定義”ができる必要があります。）

”小さい”とはどういうことか

おそらく最も判断に困るのは、Small（小さい）の要素だと思います。一般的には「迷ったときは小さくしておくといいよ」というアドバイスもありますが、具体例で感覚を掴むのが一番だと思いますので、以下に「大きすぎるユーザーストーリーを小さくした」例を挙げてみます。

分解の具体例

以下は「オンライン購入の手続き」を例にしています。

<ユーザーストーリー#1>
顧客として、請求に対する支払いを行いたい。それはなるだけ早く商品を手に取りたいからだ。

ユーザーの要求は伝わりますが、どんなプロセスで支払うのか？どんな支払手段が必要なのか？が不明瞭な状態です。他のユーザーストーリーと被る部分が出てきそうな気もしますし、この状態では見積もるのは難しく、テスト可能だとは言いづらいです。

以下のように分解するのはどうでしょうか。

<ユーザーストーリー#1‐a>
顧客として、注文した内容とともに請求内容を確認したい。それは合計金額が正しいか確認したいからだ。
<ユーザーストーリー#1‐b>
顧客として、請求内容確認後に支払い手続きに進みたい。それはすぐに支払いを完了させたいからだ。
<ユーザーストーリー#1‐c>
顧客として、VISAもしくはMASTERカードによる決済を行いたい。それは便利な決済手段を利用したいからだ。

このように分解すると、それぞれがある程度短い期間で開発できそうです。

実は、ユーザーストーリーを小さくすることによって、その他の”INVEST”の充足度も高まるという効果もあります。ですので、Small（小さい）の要素を満たすために「このユーザーストーリーは短期間で開発できそうか？」という観点でチェックするよりはむしろ、「このユーザーストーリーは”INVEST”を満たしているか？」の観点でチェックして、十分に満たせるまでブレイクダウンしてみる。というのが賢いやり方かもしれません。