トレーニング予約 お問い合わせ

User Story Index Card
プロダクトオーナー初心者が
プロダクトバックログを簡単に作成できる
ユーザーストーリー インデックスカード

ユーザーストーリーとは

アジャイル開発において「ユーザーの目線で要件を考える」「必要なプロセスを明確にする」といった目的で利用されるユーザーストーリー。ユーザーストーリーは、顧客やユーザーができるようになりたいことをまとめたもので、システムを開発する際に必要なプロジェクトの要求事項です。名前の通りユーザーの要望や役割、ふるまい、そしてゴールなどの内容が含まれています。
ユーザーストーリーは、アジャイルソフトウェア開発の世界で広く使われており、大量の機能を細かく分解して計画作りに生かせるようにしています。

ユーザーストーリーは、エクストリーム・プログラミング(Extreaming Programming:XP)の考案者のひとりケント・ベック(Kent Beck)が、ソフトウェア開発においての大きな問題が要件定義のプロセスに起因するものであると考えたことにはじまります。
文字量が多く、ときには読み手によってイメージが異なったり、合意して開発プロセスに踏み込んだのに途中で違う理解だったことに気づくなど、さまざまな問題が発生する要件定義書。ケント・ベック氏は、そんな要件定義書の使用をやめ、形式にとらわれないようステークホルダーが集まって対話型で要件(ストーリー)を語るやり方で要件を引き出しまとめることにしました。

このケント・ベック氏の考えから生まれた「ストーリー」が「ユーザーストーリー」と発展していき、今ではスクラムやカンバンなどの開発方式でも、開発時の要件定義を関連づけるために広く使われています。

ユーザーストーリー インデックスカードとは

ユーザーストーリーを作成するためには「Card(カード)」「Conversation(会話)」「Confirmation(確認)」の3Cが必要とされています。
考案者のうちの別の1人である ロン・ジェフリーズ(Ron Jeffries)氏により「3C」という「ユーザーストーリー」を3段階で発展させる方法が考案されました。

Card(カード)

ユーザーストーリーはカードに書き出します。カードにはカードに書ききれる量にすることを推奨してます。カードに書ききれない場合、複数のストーリーが入っている可能性が多いため、分割することをおすすめしています。例えば検索の条件がいっぱいある場合、その検索条件を使いたい「なぜなら」の理由は違う可能性が高いわけで、なぜそんなにたくさんの検索条件が必要なのかを認識合わせするためだったり、優先順位をつける際に、低い検索条件はスコープアウトすることができます。

Conversation(会話)

詳しい要件は、会話を通じて考え、意見、感情の交換を行います。

Confirmation(確認)

カードに書かれたストーリーについて詳細な会話を行っても、認識の違いが生じることがあります。わたしたちが切に求めていることが正しく実装されているかの受入基準を確認します。仮に作り方(HOW)に認識の違いがあったとしても、最終的に実現される(WHAT)が同じであれば、ユーザーは困らないので、受け入れ条件(ゴール)が正しいことは明確ににします。

ストーリーを書くときによく使われる、お決まりの書式があります。
「___として、___をしたい。なぜなら___だからだ」というものです。
「___として」には、誰がそのストーリーを欲しているのかを書き、 「___をしたい」には、どんな機能であるかを書きます。そして「なぜなら___だからだ」の項目には、なぜその機能が欲しいのかを書きます。その「なぜなら」を省く人が多いですが、エンジニアが求めているのは実は「なぜなら」だったりします。
開発者が何のためにその機能を必要なのかを知ってもらうことで、成果物の認識のズレが起きることを防ぎます。また開発者目線で、もっとよいアイデアを出してくれるかもしれません。

ビル・ウェイク(Bill Wake)氏は、良いストーリーの特徴としてINVESTという用語を提唱しています。INVESTでユーザーストーリーが書かれていれば、誰もがゴールを理解でき、また最小の単位で受け入れテストをしていくことができます。

  • Independent(独立している) どのストーリーも、順番を気にせずに出荷できること
  • Negotiable(交渉可能である) ストーリーの内部の詳細は、開発中にプログラマーと顧客の共同作業で作り上げること
  • Valuable(価値がある) そのストーリーの機能が、顧客あるいはそのソフトウェアのユーザーにとって価値があるものであること
  • Estimable(見積もり可能である) プログラマーがストーリーを実装するにあたって、妥当な見積もりができること
  • Small(粒が小さい) ストーリーの実装にかかる時間は少なくすること。通常は数人日程度になる。 少なくとも、1回のイテレーションで複数のストーリーを完成させるくらいでなければいけない
  • Testable(テスト可能である) ストーリーが正しく機能することを確認するためのテストを書けること

ユーザーストーリーを理解するためには、マイク・コーン(Mike Cohn)氏著書の 「 User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series (Beck)) 」を参考にされるとよいでしょう。

ユーザーストーリー インデックスカードのテンプレート

Odd-e Japanのトレーニング

Odd-e Japanの認定スクラムプロダクトオーナー(Certified Scrum Product Owner®:CSPO® )トレーニング、では、プロダクトオーナーとしての基本的な知識や考え方について学びます。必要に応じて、スクラムの概念、背景、概要、各役割やセレモニー(ミーティング)、スクラムと他の新製品開発手法との違いについても取り上げます。
ユーザーストーリーの作成、事業計画やスタートアップについても体系的に学んでいただくことができます。
研修によってはプログラムに組み込まれないこともありますが、講師に直接ご質問ください。

また、「アジャイル新規事業」は、経験豊富なプロフェッショナル人材を提供することで貴社の新規事業を早期実現するサービスですが、お客様のご要望に応じて、ユーザーストーリー作りはもちろん、貴社の新規事業を成功に導くサポートをいたします。

関連URL