ユーザーストーリー
 | この記事は英語版の対応するページを翻訳することにより充実させることができます。（2021年12月） 翻訳前に重要な指示を読むには右にある[表示]をクリックしてください。
|
ユーザーストーリー（英: User Story）はユーザーの観点から日常用語を用いて説明されたソフトウェアへの要望である[1]。ソフトウェア工学・プロダクトマネジメント・マーケティングの分野で用いられる。
概要
[編集]ソフトウェアはユーザーへ価値を届ける道具である。そのためユーザーの要望を知ることはソフトウェア開発の第一歩である。これを可能にするのがユーザーストーリーである[2]。
前提として、ユーザーは技術の専門家でもソフトウェアの専門家でもない。ゆえにユーザーは希望する要件を技術的に定義できないし、ソフトウェア実装の選択肢を思い浮かべることもできない[3]。ユーザーはUIと機能の分離という発想がないかもしれないし、メニューが欲しくてもハンバーガーボタンとタブを選択肢として思い浮かべることができないかもしれない。
一方、ユーザーは何が欲しいか（what）、それはなぜなのか（why）を日常用語を用いて説明することはできる[4]。例えば「私は友達を招待したい、それでこのサービスを私と一緒に受けられるようにしたい」や「僕は仕事を整理したい、なぜならその全体像を把握したいからだ」と説明できる[5]。言い換えれば、自分が望むユーザーエクスペリエンス（UX）を語ることはできる。これがユーザーストーリーである。
ユーザーストーリーがあれば開発者はユーザーと対話が可能になり、そこからソフトウェアの要件を導くことができる。何が欲しいかの詳細を聞き、今使っている道具・アプリを把握し、モックアップを見せていくことで、どのような機能を実装すれば要望を満たせるか・価値を届けられるかを把握できる。例えば「友達を招待したい」を起点にして「同じアプリを使っている友人と利用したいのか」「Twitterの友人を招待したいのか」「不特定多数の友人に声をかけたいのか」と深めていくことで、必要な機能がフレンド機能なのか、SNS連携なのか、招待リンクなのか理解できる。このようにユーザーストーリーは対話の土台となる役割を果たす。ユーザーストーリーはユーザー視点でみた要望であり、（ユーザーの専門外である）技術要件やソフトウェア実装（how）の情報は一切含まれない。ゆえにユーザーストーリーをもって要件定義とすることは無く、対話を介して得た情報を整理して要件定義とする[6]。
良いユーザーストーリーが満たす特性を示す標語にはINVESTがある。INVESTのVは価値/Valueを意味しており、ストーリーを分割する際には価値を分割するべきである[7]。機能/技術レイヤーに基づいた分割はストーリーをストーリー（UX）で無くしてしまう。価値・featureに基づいた分割はバーティカルスライス、E2Eなどと呼ばれる。
ユーザーストーリーはアジャイルソフトウェア開発、特にXPやスクラムで用いられる開発手法である。ソフトウェア開発に限らず、プロダクトマネジメント全般に適用が可能である。
脚注
[編集]- ^ "ユーザーストーリーは、ソフトウェアの機能をエンドユーザーの観点から、堅苦しくない一般的な言葉で説明するものであり" MAX REHKOPF. 例とテンプレートで作るユーザーストーリー. ATLASSIAN Agile Coach. 2021-09-06閲覧.
- ^ "ユーザーストーリーは ... ソフトウェアの機能が顧客にどのように価値を提供するかを示すことを目的としています。" MAX REHKOPF. 例とテンプレートで作るユーザーストーリー. ATLASSIAN Agile Coach. 2021-09-06閲覧.
- ^ "We don’t expect customers or users to view the system the same way that programmers do" Bill Wake. (2003). INVEST in Good Stories, and SMART Tasks. XP123.
- ^ "It’s an end goal, not a feature, expressed from the software user’s perspective." MAX REHKOPF. 例とテンプレートで作るユーザーストーリー. ATLASSIAN Agile Coach. 2021-09-06閲覧.
- ^ "たとえば、ユーザーストーリーは次のようになります: ..." MAX REHKOPF. 例とテンプレートで作るユーザーストーリー. ATLASSIAN Agile Coach. 2021-09-06閲覧.
- ^ "They don't go into detail. Requirements are added later, once agreed upon by the team." MAX REHKOPF. 例とテンプレートで作るユーザーストーリー. ATLASSIAN Agile Coach. 2021-09-06閲覧.
- ^ "This is especially an issue when splitting stories. ... We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. ... Making each slice valuable to the customer" Bill Wake. (2003). INVEST in Good Stories, and SMART Tasks. XP123.
参考文献
[編集]- 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