ゆーざーすとーりー

ユーザーストーリー

アジャイル開発において、顧客や利用者の視点で機能を表現する記述手法です。「誰が、何を、何のために」という形式で要求を記述します。

詳しい説明

ユーザーストーリーとは、アジャイル開発において、顧客や利用者の視点からシステムが提供する機能を表現する記述手法です。「誰が」「何を」「何のために」という形式で要求を書き出します。

詳細な要求仕様書を作成する前段階として、開発チームと顧客の間で「何を実現したいか」という価値観を共有するために用います。文章の書き方はシンプルですが、機能の目的と価値を明確にするための非常に強力なツールです。

標準的な形式は、「～という役割のユーザーとして、～という目的のために、～という機能がほしい」という構成をとります。これにより、開発者は単に作るべき機能を理解するだけでなく、その背景にあるユーザーの目的を深く理解できます。

また、ユーザーストーリーを束ねた「エピック」や、さらに細分化した「タスク」という階層構造を持ちます。プロジェクト全体で実現したい大きな目標から、今すぐ着手すべき具体的な作業まで、優先順位をつけて管理していくのが基本の仕組みです。

ITパスポート試験では、アジャイル開発手法の一つとして登場します。要求定義の段階で、顧客と開発者が対話を通じて要件を固めていくプロセスの重要性が問われます。ガチガチの仕様書とは異なり、変化に対応しやすい手法である点がポイントです。

基本情報技術者試験では、ストーリーポイントを用いた工数見積もりや、プロダクトバックログとの関連が問われます。ユーザーストーリーは未完了の作業リストであるプロダクトバックログの最小単位として扱われ、開発の優先順位付けや進捗管理の材料として機能します。

機能要件定義書とは、記載の粒度や目的が異なります。要件定義書はシステムに必要な機能を網羅的かつ詳細に定めた契約的な文書ですが、ユーザーストーリーはユーザーの目的達成に焦点を当てた、対話のための短い記述です。

ユースケースとも混同されがちですが、ユースケースはシステムとユーザーの相互作用の「手順」を詳細に記述するのに対し、ユーザーストーリーは「誰が何の価値を得るか」という目的にフォーカスします。ユースケースの方が構造的な仕様記述に近いです。

例えば「ログイン機能」を作るとします。要件定義書では「IDとパスワードの照合を行う」と書きますが、ユーザーストーリーでは「会員として、サイトの特典を利用するために、マイページにログインしたい」と書きます。

このように書くことで、開発チームは単にID照合プログラムを書くのではなく、会員がストレスなく特典を利用できるようなログイン体験を意識して設計できます。利用者の視点が開発の指針になる分かりやすい例です。