ニュース

2024年8月15日

ソフトウェア開発における「要件」と「ストーリー」はどう違うのか：適切なユーザーストーリーを作る「3つの質問」とは

TechTargetは「ソフトウェア開発における要件とユーザーストーリーの違い」に関する記事を公開した。どちらも設計、機能、使い勝手について「利害関係者がアプリケーションに想定すること」を記述するものだが、その違いは何か。

LINE

Hatena

　TechTargetは2024年7月2日（米国時間）、「ソフトウェア開発における要件とユーザーストーリーの違い」に関する記事を公開した。ユーザーストーリーとソフトウェア要件は目的は同じだが手段が異なる。本稿では、ユーザーストーリーの書き方と、ユーザーストーリーとソフトウェア要件の関係について説明する。

ソフトウェア開発における要件とユーザーストーリーの違い（提供：TechTarget）

　ソフトウェア開発において、ソフトウェア要件は最も重要な要素だ。明確な要件がなければ、開発チームは利害関係者の想定に完全に応えることはできない。そういった意味でソフトウェア要件は「ソフトウェア開発のあらゆる側面の基礎」と言える。ソフトウェア要件にはさまざまな種類とアプローチがあるため、開発チームとその利害関係者は各種の違いを理解した上で、期待に応え、そして期待を上回るソフトウェアを開発することが重要だ。

ソフトウェア要件とは

　ソフトウェア要件は、要件文書の形式でビジネスアナリストから開発チームに提示されることが多い。要件ドキュメントは包括的であるため、実際の開発だけでなく、トレーサビリティーやテスト範囲を文書化するのにも役立つ。

　生産性の高い開発チームは、開発の効果を高めるためにさまざまな種類のソフトウェア要件を使い分ける。そういった開発チームではソフトウェア要件をウォータフォール手法で使用し、大規模で厳しく規制されるプロジェクトに関連付けることが多い。

　ウォータフォール手法の文脈（コンテキスト）では、ソフトウェア要件のドキュメントは設計要件から始まり、技術要件、非機能要件、機能要件、ユーザビリティ要件という順で作成される。ソフトウェア要件ドキュメントは、開発を始める前に完成させる。ドキュメントを承認した後に変更を加える場合は、変更管理プロセスに従って変更する必要がある。

機能要件と非機能要件の違いを比較したチャート

ユーザーストーリーとは

　ユーザーストーリーとは、主にアジャイル手法で使われる要件の確定方法だ。アジャイル手法では、段階的開発に重点を置き、各スプリントでリリース可能なソフトウェアを作成するため、要件は焦点を絞った詳細なものにしなければならない。従って、ユーザーストーリーは機能要件の増分と考えることができる。

　ユーザーストーリーはアジャイル開発における「エピック」（大まかな作業やタスクを示す概念）を構成する要素で、アプリケーションの機能を俯瞰（ふかん）的に説明する。開発チームはエンドユーザーの視点からユーザーストーリーを描き、ユーザーが何をしたいのか、それはなぜかといったことを明らかにする。開発したユーザーストーリーはバックログに配置され、その後、スクラムチームのスプリントに割り当てられる。

ソフトウェア要件とユーザーストーリーの違い

　テストチームが要件とユーザーストーリーを実装する方法には大きな違いがある。ソフトウェア要件は、機能要件と非機能要件の両方が含まれ、開発の大まかな方向性を知ることができる。一方、ユーザーストーリーはある段階における詳細な情報（要件）が記載されている。つまり、テストにユーザーストーリーを使えば、機能の詳細を深く掘り下げることができ、変更に対してソフトウェア要件を使う場合よりも柔軟に対応できると言える。

　テストでソフトウェア要件を使う場合のメリットは以下の2点だ。

トレーサビリティー

　テストケースを各ソフトウェア要件までトレースすることで、コンプライアンス要件を満たす効果的なアプローチが提供される

テスト範囲

　ソフトウェア要件にテストケースを結び付けることで、網羅的なテストができる

　ユーザーストーリーを使用するテストのメリットは以下の3点だ。

コラボレーション

　ユーザーストーリーベースのテストでは、開発者とプロダクトオーナーが「ユーザーストーリー」と「必要な変更」について話し合う必要があるため、コラボレーションが促進される

ユーザー中心

　ユーザーストーリーを使用するテストでは、ユーザーに明確に焦点を当てる。そのため、ユーザーのニーズを確実に満たすことができる

問題点の早期検出

　ユーザーストーリーを使用するテストの反復的なアプローチによって、テストプロセスの早い段階で問題点を検出できる

ユーザーストーリーの作成方法

　ユーザーストーリーを適切に作成するには、次の要素を盛り込む必要がある。

特徴（Feature）：ユーザーストーリーが関係するエピック
シナリオ：フィーチャーの簡単な説明（ストーリー名のこと）
ユーザーロール：視点を提供する仮想の人間（ペルソナ）のこと
達成可能なアクション：ペルソナが得る価値のことで、これによって視点が絞り込まれる
求めるビジネス価値：達成可能なアクションから得られるビジネス上の価値
受け入れ基準：完全性を判断するために作業が満たさなければならない基準

　ユーザーストーリーは、ユーザーの視点から作成すると最も効果が高まる。ユーザーストーリーは、次の3つの疑問に答えるように設計する。

「誰が求めているのか」：ユーザーのペルソナとその役割を答える
「何を求めているのか」：ユーザーが実行したいアクションを答える
「なぜ必要なのか」：ユーザーが実現する必要があるメリットを答える

　ユーザーストーリーは「ユーザー」として「何らかのアクションを実行」することで「何らかのメリットを得る」という形式で作成する。

　ユーザーストーリーを構成する要素の中でも「受け入れ基準」は特に重要だ。受け入れ基準は、求められた機能がユーザーのニーズを満たしているかどうか判断する方法を詳しく説明するものだからだ。ユーザーストーリーの種類によって、チームは受け入れ基準をルールとして書くことも、シナリオとして書くこともできる。

　ルールとして受け入れ基準を作成する場合は、アクションの基準を定義する「番号付きリスト」で作成するのが一般的だ。シナリオとして受け入れ基準を作成する場合は「given、when、then」の形式で表現する。つまり「前提条件のリスト（given）」「実行するアクション（when）」「想定する結果（then）」を説明する。チームは、受け入れ基準を使用して、ユーザーストーリー内のテストケースを記述し、関連付けをする。

　ユーザーストーリーによる開発の準備が整っているかどうかを判断する場合、「INVEST」基準がよく使われる。INVESTは、それぞれ「独立性（Independent）」「交渉可能性（Negotiable）」「価値（Valuable）」「見積もり可能性（Estimable）」「小ささ（Small）」「テスト可能性（Testable）」を表している。

　また、ユーザーストーリーの記述には「Gherkin」構文が適している。この形式であれば、シナリオと想定する結果を構造化して理解しやすい方法で定義できるからだ。Gherkin構文は平易な言語テキストで、ソフトウェアテストツール「Cucumber」で要件から直接コードを作成するのに利用できる。このアプローチは、ビヘイビア駆動型開発で最もよく使用されている。

　ソフトウェア要件とユーザーストーリーはいずれも、ソフトウェアプロジェクトのニーズを定義する効果的なアプローチだ。ソフトウェア要件はウォータフォール手法に関連付けられることが多く、ユーザーストーリーはアジャイルの段階的開発の基礎となる。どちらを使っても効果的なテスト、トレーサビリティーの確保、テスト範囲の定義は可能だ。