ユーザーストーリー

ソフトウェアはユーザーへ価値を届ける道具である。そのためユーザーの要望を知ることはソフトウェア開発の第一歩である。これを可能にするのがユーザーストーリーである^[2]。

前提として、ユーザーは技術の専門家でもソフトウェアの専門家でもない。ゆえにユーザーは希望する要件を技術的に定義できないし、ソフトウェア実装の選択肢を思い浮かべることもできない^[3]。ユーザーはUIと機能の分離という発想がないかもしれないし、メニューが欲しくてもハンバーガーボタンとタブを選択肢として思い浮かべることができないかもしれない。

一方、ユーザーは何が欲しいか（what）、それはなぜなのか（why）を日常用語を用いて説明することはできる^[4]。例えば「私は友達を招待したい、それでこのサービスを私と一緒に受けられるようにしたい」や「僕は仕事を整理したい、なぜならその全体像を把握したいからだ」と説明できる^[5]。言い換えれば、自分が望むユーザーエクスペリエンス（UX）を語ることはできる。これがユーザーストーリーである。

ユーザーストーリーがあれば開発者はユーザーと対話が可能になり、そこからソフトウェアの要件を導くことができる。何が欲しいかの詳細を聞き、今使っている道具・アプリを把握し、モックアップを見せていくことで、どのような機能を実装すれば要望を満たせるか・価値を届けられるかを把握できる。例えば「友達を招待したい」を起点にして「同じアプリを使っている友人と利用したいのか」「Twitterの友人を招待したいのか」「不特定多数の友人に声をかけたいのか」と深めていくことで、必要な機能がフレンド機能なのか、SNS連携なのか、招待リンクなのか理解できる。このようにユーザーストーリーは対話の土台となる役割を果たす。ユーザーストーリーはユーザー視点でみた要望であり、（ユーザーの専門外である）技術要件やソフトウェア実装（how）の情報は一切含まれない。ゆえにユーザーストーリーをもって要件定義とすることは無く、対話を介して得た情報を整理して要件定義とする^[6]。

良いユーザーストーリーが満たす特性を示す標語にはINVESTがある。INVESTのVは価値/Valueを意味しており、ストーリーを分割する際には価値を分割するべきである^[7]。機能/技術レイヤーに基づいた分割はストーリーをストーリー（UX）で無くしてしまう。価値・featureに基づいた分割はバーティカルスライス、E2Eなどと呼ばれる。

ユーザーストーリーはアジャイルソフトウェア開発、特にXPやスクラムで用いられる開発手法である。ソフトウェア開発に限らず、プロダクトマネジメント全般に適用が可能である。

• Daniel H. Steinberg, Daniel W. Palmer, Extreme Software Engineering, Pearson Education, Inc., ISBN 0-13-047381-2.
• Mike Cohn, User Stories Applied, 2004, Addison Wesley, ISBN 0-321-20568-5.
• Mike Cohn, Agile Estimating and Planning, 2006, Prentice Hall, ISBN 0-13-147941-5.
• Business Analyst Time
• Payton Consulting 'How user stories are different from IEEE requirements