ユーザーストーリー

ユーザーストーリーとは、その機能から恩恵を受ける人の視点から要件を簡潔に記述したもので、一般的には役割、必要な機能、そしてそれが求められる理由という形式で記述されます。エクストリームプログラミングの手法から生まれ、反復開発における作業内容を表現する主要な形式となりました。

その目的はしばしば誤解されている。ストーリーは仕様書ではなく、対話を促すためのものだ。本来の構想では、ストーリーは機能を必要とする人々とそれを構築する人々との間の議論のためのプレースホルダーとして位置づけられており、文書化されたテキストは議論を代替するのではなく、議論が行われることを確実にするために存在する。カードを完全な要件として扱うチームは、この形式を採用してその仕組みを放棄してしまった。

理由条項は、最も重要な要素でありながら、最もいい加減に書かれがちな部分でもあります。なぜその機能が必要なのかを明確にすることで、チームは同じニーズに対して、より優れた別の解決策を提案できるようになり、根本的な理由が弱いことが判明した場合には、正直に作業の優先順位を下げることも可能になります。単に「ボタンを押すためにボタンが必要」といったように、理由条項が機能の説明に終始しているストーリーは、何も伝わらず、そうした対話の可能性を奪ってしまいます。

ストーリーのサイズは重要です。なぜなら、ストーリーはイテレーション内で完了でき、ユーザーが実際に体験できるものを提供する必要があるからです。大きすぎるストーリーは完了も評価もできませんし、データベーステーブルやインターフェースコンポーネントを個別に構築するなど、技術的なレイヤーに分解されたストーリーは、個別に観察できるものを提供しません。各ストーリーがすべてのレイヤーを横断して薄くても完全な機能を生み出す垂直スライスこそが、デモンストレーションと学習を可能にするのです。

このフォーマットは必須要件ではなく慣習であり、厳密に遵守しようとすると不合理な事態が生じる。依存関係のアップグレードや可観測性の向上など、直接的なユーザーを持たない技術的な作業はテンプレートに適合しないため、無理やり当てはめようとすると、ライブラリの更新を求める不自然なユーザー像が作り出されてしまう。こうした作業は、フォーマットに合わせるために歪めるよりも、その根拠を明記した上で、率直に記録する方が誠実で有益である。

受け入れ基準は、ストーリーをテスト可能にするものであり、独立した成果物ではなく、ストーリーの一部として適切に位置づけられるべきものです。受け入れ基準は、ストーリーが完了とみなされる条件を規定し、物語形式では省略される例外的なケースやエラー経路も含みます。受け入れ基準がなければ、完了は主観的な判断に委ねられ、意見の相違は通常、解決に最もコストがかかるレビュー段階で表面化します。

ストーリーは整理せずに放置しておくと、手に負えないほど溜まってしまいます。何ヶ月も前に書かれた項目は、その後変化した製品や市場について記述しており、数百ものストーリーが溜まったバックログは、計画というより誰も読まない文書になってしまいます。現実的に開発される見込みのないストーリーを定期的に削除するのは、気が進まないかもしれませんが、いつまでも放置しておくよりはるかに効果的です。

価値は成果物ではなく会話に依存するため、有効性は適切な人が参加するかどうかによって決まります。実際には、この形式は次のような状況で使用されます。 製品開発 根本的なニーズは、 ユーザー調査 想定されるのではなく、組織が内部でこの能力を構築する場合、通常は執筆と洗練の実践を内部で確立します。 製品部門 つまり、物語は検証済みの問題から生まれるということだ。