ジェイソン・ガードナー（編）
ユーザーストーリーは、アジャイルソフトウェア開発の重要な要素です。 その核となるものは、「ソフトウェアシステムのユーザーのニーズと要件を説明する方法である」という単純なものです。 しかし、開発チームは、辻褄の合わない言い回しでユーザーストーリーを書くことがよくあります。 具体的には、「システムとして…」や「開発者として…」で始まるストーリーは、ユーザーストーリーの意味をなしていません。 この記事では、なぜこのようなユーザーストーリーが意味をなさないのか、そしてプロジェクトに付加価値を与える、より効果的なストーリーを書くために何をすべきかを見ていきます。
開発チームが「システムとして…」 で始まるユーザー ストーリーを書くということは、エンド ユーザーを無視しているということです。 システム自体にニーズや要件はありません。それがあるのはユーザーです。 最初にシステムに焦点を当てると、チームはユーザーストーリーの達成すべきこと、つまりユーザーのニーズを理解するという意義を見失います。 同様に、「開発者として…」で始まるユーザーストーリーも問題があります。 開発者はソフトウェア開発プロセスにおいて重要な存在ですが、システムを使うのは開発者ではありません。
「システムとして…」「開発者として…」で始まるユーザーストーリーのもう一つの問題は、プロジェクトに真の価値を提供しないということです。 ユーザーストーリーがシステムや開発者に焦点を絞っている場合、エンドユーザーに利益をもたらす実際の結果にはつながりません。 ユーザーストーリーは、新機能の提供、既存の機能の改善、プロセスの合理化など、常にユーザーにとっての価値の創造に焦点を当てる必要があります。 直接的であれ間接的であれ、ユーザーストーリーが顧客にどのような利益をもたらすかを理解できない場合、そもそもユーザーストーリーの必要性を問うべきです。
では、より効果的なユーザーストーリーを書くにはどうすればよいでしょうか？ 何よりもまず、常にユーザーに焦点を当てることが重要です。 ユーザーストーリーは「ユーザーとして…」あるいは「顧客として…」で始める必要があります。そして、ユーザーが何を必要としているか、ソフトウェアがそれをどのように助けるのかが分かるように記述する必要があります。 もう １つの有用な手法は、たとえ間接的な利益に見えたとしても、ストーリーのビジネス価値に焦点を当てることです。 たとえば、「開発者としてデータベース スキーマを更新する必要がある」というストーリーを書く代わりに、「ビジネス オーナーとして、需要に合わせて製品をスケーリングできる必要がある」というストーリーを書きます。 このリフレーミングは、そのストーリーが、ビジネスとエンドユーザー両方の価値創造に焦点を当てていることを確認するのに役立ちます。 結局のところ、セキュリティの向上、ツールの刷新、保守性のさらなる容易化はすべて、最終的に顧客に利益をもたらします。
最後に、ユーザーストーリーをより小さく、より管理しやすい塊に分割することで、価値に焦点を当て、予定どおりの完成が可能になります。 ストーリーが大きすぎたり複雑すぎたりすると、焦点が合わなくなったり、技術的な詳細が分からなくなったりする可能性が高くなります。 ストーリーを小さな塊に分割することで、各ストーリーがユーザーにとっての価値創造に集中し、チームがプロジェクトの完了に向けて測定可能な進歩を遂げることができるようにすることが容易になります。
まとめ
ユーザーストーリーはアジャイルソフトウェア開発の重要な要素ですが 正しく記述されていないと、不満や混乱の原因にもなり得ます。 「システムとして」あるいは「開発者として」から始まるユーザーストーリーは、間違ったものに焦点を当て、プロジェクトに本来の価値を提供しないので、問題です。 より効果的なユーザーストーリーを書くには、常にエンドユーザーに焦点を当て、明確なビジネス価値を提供するストーリーを作成することが重要です。 ストーリーをより小さく、より管理しやすい塊に分割することで、ストーリーが価値に焦点を合わせ、予定どおりの完成が可能になります。 上記のガイドラインに従うことで、開発チームはより効果的なユーザーストーリーを作成し、エンドユーザーとビジネス全体にとってより良い結果をもたらすことができます。
