このチュートリアルでは、ソフトウェア開発におけるアジャイルアプローチの重要な部分であるユーザーストーリーについて学びます。

ユーザーストーリーとは何か、ユーザーストーリー作成時に見られる一般的な落とし穴、そしてあなたのユーザーストーリーが「良い」ものであるかを検証するためのフレームワークについて説明します。

以下の内容をカバーします：

アジャイルの始まり

アジャイル開発とユーザーストーリーについて聞いたことがあるでしょう。しかし、もし聞いたことがなければ、簡単な歴史の授業をしましょう：

ユーザーストーリーは、アジャイル手法と呼ばれるより大きな概念の一部です。

アジャイル手法は2001年に、17人の著名なソフトウェアエンジニアがユタ州のスキーリゾートで集まり、今では悪名高いアジャイルマニフェストを作成した時から存在しています。

ロバート・マーチン、マーチン・ファウラー、ケント・ベックといった名前があなたにとって意味を持たないのであれば、この記事を読み終えたら彼らを探してみてください。彼らは豊富な知識を持っており、ソフトウェアの世界に流動的なプロジェクト提供の方法、アジャイルをもたらしました。

アジャイルとは何か？

アジャイルは、規定された方法というよりも思考の方法と言えます。スクラムやカンバンのような規定された方法は存在しますが、アジャイルは概念です。

アジャイルは、コラボレーション、迅速なフィードバック、そしてユーザーに価値を頻繁に提供することを促進します。

アジャイルの思考方法は、プロジェクト計画における柔軟性を奨励し、当時の競合であったウォーターフォールプロジェクト計画の非常に厳格な納品物と納期に対してはっきりと対照的です。

アジャイル手法は、プロジェクトを開始するために「必要最低限」の調査を行い、その後、学習し、反復し、プロジェクトの進行に応じて設計や成果物を変更することを促進します。最終的なコードが納品されるまでのこの「進行しながら学ぶ」というアプローチは「適応型計画」と呼ばれます。

アジャイルは、価値のある何かを迅速かつ頻繁に提供することを促進しており、通常は2週間ごとの「スプリント」の終わりにコードを本番環境にデリバリーする形を取ります。これは、ユーザーに見える変更が本番環境に提供されるまでに数ヶ月の開発を要することが多い従来のウォーターフォール計画とは大きく異なります。

アジャイルのもう一つの重要な部分は、利害関係者が密接に、そして頻繁に協力することに焦点を当てている点です。プロダクト、QA、エンジニアリング、営業は、プロジェクトライフサイクルを通じてプロジェクトに対して大きな影響と常にフィードバックを持っています。

アジャイルの仕組みについて少し理解したところで、ユーザーに対する価値をどのように検証するかをさらに深く掘り下げていきましょう。

ユーザーストーリーの登場です。

ユーザーストーリーとは何ですか？

ユーザーストーリーは、エンジニアをソフトウェアの最終目標に結びつけるための平易な英語の表現です。

技術に詳しくない人が読んでも理解できるように設計されており、エンジニアが見て価値を確認し、その価値を提供したことを検証する方法を理解できるようになっています。

ユーザーストーリーの構造

私は[ユーザータイプ]として、[アクションを実行する]とき、[期待される結果]が得られる。

これは最も基本的な形です。

エンドユーザーと提供する「価値」に重点を置いています。

入力内容を詳しく見てみましょう：

  • ユーザーの種類：「ユーザー」には一括りにできるものはありません。「管理者ユーザー」や「ログインユーザー」、「権限Xを持つユーザー」や「役割Yのユーザー」などがいます。これは、どのユーザーがアクションを実行しているかを具体的に示しています。

  • アクションを実行：ユーザーが何をしていますか？「ログイン」ボタンをクリックしていますか？レコードを削除していますか？フォームを送信していますか？

  • 期待される結果：ユーザーがアクションを実行した後、何が起こるべきですか？正しいメールアドレスとパスワードで「ログイン」をクリックした場合、どこにリダイレクトされるべきですか？間違ったメールアドレスとパスワードで「ログイン」をクリックした場合、何が起こるべきですか？

ユーザーストーリーの例：

ログインページのユーザーストーリーの例を見てみましょう。

例があるのは何よりも良いことです。

シーンを設定しましょう。メールアドレス用の入力テキストボックスとパスワード用の入力テキストボックスがあるログインページがあります。送信ボタンもあります。それだけです。

このページで、ユーザーの視点からどのような異なるパーミュテーションが起こり得るでしょうか？

ログイン済みのユーザーとして、ページが読み込まれると、ログイン済みのホームページにリダイレクトされます。

すでにログインしている場合は、再度詳細を入力したくありません。ログイン済みのホームページにリダイレクトしてください。

ログインしていないユーザーとして、正しいメールアドレスを入力したが、パスワードが間違っている場合、ログインをクリックするとエラーメッセージが表示されます。

私はすでにログインしていないユーザーで、間違った詳細を入力しました。ログインするべきではありません。

ログインしていないユーザーとして、間違ったメールアドレスとパスワードを入力し、ログインをクリックするとエラーメッセージが表示されます。

再度。私はログイン済みのユーザーではありません。間違った詳細を入力したので、ログインするべきではありません。

ログインしていないユーザーとして、正しいメールアドレスとパスワードを入力し、ログインをクリックすると、ログイン済みのホームページにリダイレクトされます。

今回は、私はまだログインしておらず、正しい詳細を入力してログインをクリックします。システムにログインしました。

これらすべてがユーザーに焦点を当てていることがわかりますか？

上記の「期待される動作」のいくつかが完全に定義されていないことに気付くかもしれません。それについては、後で受け入れ基準で対処します。

良いユーザーストーリーの作り方

ユーザーストーリーが良いかどうかを簡単に示す良いモデルが「INVESTモデル」です。

INVESTモデル:

  • I独立: 個別に開発可能です。
  • N交渉可能: 討論や変更にオープンです。
  • V価値ある: ユーザーに価値を提供します。
  • E見積もり可能: 努力を見積もることができます。
  • S小さい: スプリント内に収まります。
  • Tテスト可能: 明確な受け入れ基準があります。

このINVESTモデルを上記のユーザーストーリーの例の1つに適用してみましょう:

ログインしていないユーザーとして、正しいメールアドレスとパスワードを入力してログインをクリックすると、ログインしたホームページにリダイレクトされます。

(これは理論的なコードベースと理論的なプロジェクトなので、いくつかの仮定を立てます)

このストーリーは 独立していますか？はい、そうだと思います。これは、恐らく既に存在するいくつかの要素だけを含む小さなストーリーです。ただし、プロジェクトのためのデータベースがまだ作成されていない場合、それは依存関係を生むことになります。そうなると、もはや独立ではありません。

これは 交渉可能ですか？再度、はい。ユーザープロフィールページにリダイレクトするように簡単に変更できるストーリーです。

このストーリーは確実に 価値があります。実装されれば、ユーザーはログインできます。もしこのストーリーが:

ログインしていないユーザーとして、正しいメールアドレスとパスワードを入力してログインをクリックすると、何も起こらない。

これは価値がないでしょう。ユーザーはこれから何も得られません。

このストーリーは 見積もり可能ですか？再度、架空のシナリオでいくつかの仮定をする必要がありますが、これは簡単に見積もれることを願っています。簡潔なストーリーで、少ない要素を含み、誰もが馴染みのあるドメインで明確な受け入れ基準があります。

このストーリーは確実に 小さいです。何をする必要があるのかあまりあいまいさはなく、ユーザーパスは一つだけで、結果も明確です。では、あまりにも大きすぎるストーリーを見てみましょう:

ログインしていないユーザーとして、ログインページは期待通りに機能するべきです。

この記事の前半で議論したように、ログインページが機能する方法は多くあり、それらをカバーする「期待通りに機能するべき」というのは、すべての変種を網羅しているようです。これはストーリーとして効果的にサイズを測るには大きすぎ、恐らく一回のスプリントで完了するには大きすぎるでしょう。

その話は確かに テスト可能 です。明確なユーザーアクションがあり、それには明確な結果があります。このユーザーストーリーは、単体テスト、統合テスト、および手動テストでカバーできます。

良いユーザーストーリーを作成できたようです！

私が上で定義した構造を使用し、ストーリーがINVESTモデルの基準を満たしていれば、それはおそらく良いストーリーです。

ユーザーストーリー作成の一般的な落とし穴

過去に、ユーザーストーリーが間違った方向に進んだ事例を見てきました。人々がユーザーストーリーのいくつかの重要な側面を見逃してしまったのです：

技術的な側面に焦点を当てること

私の上の例が示すように、ユーザーストーリーは非技術的です。

サービス名、データベース名、またはユーザーが見えないものでの検証について言及してはいけません。

ストーリーがエンドユーザーによって理解できなくなった瞬間、あなたは間違っています。

ユーザーが何をするのか、ユーザーが何を見るのかに焦点を当てましょう。

技術的に焦点を当てたストーリーの例を見てみましょう：

ログインしていないユーザーとして、正しいメールアドレスでパスワードを忘れたリンクをクリックすると、パスワードリセットリンクが送信されたことを示すレコードがデータベーステーブルに記録されます。

このストーリーはユーザーによって検証できず、非技術的なユーザーには意味が分からないかもしれません。

修正してみましょう：

ログインしていないユーザーとして、正しいメールアドレスでパスワードを忘れたリンクをクリックすると、提供されたメールアドレスにパスワードリセットリンクが含まれたメールが送信されます。

非技術者でも理解でき、ユーザーに焦点を当てています。

ステークホルダーの協力

アジャイルは協力的です。

ユーザーストーリーには、プロダクト、BA、QA、エンジニア、そして最も重要なのはユーザーからの入力が必要です。

これが、ユーザーが望むものを提供していることを確認する方法です。多くの手で作業を軽くします。

たとえば、エンジニアリングチームだけがユーザーストーリーを考えた場合、以下のようになるかもしれません：

ログインユーザーとして、ページが読み込まれると、ログインホームページにリダイレクトされます

非ログインユーザーとして、正しいメールアドレスを入力し、間違ったパスワードを入力してログインをクリックすると、エラーメッセージが表示されます

非ログインユーザーとして、間違ったメールアドレスとパスワードを入力し、ログインをクリックすると、エラーメッセージが表示されます。

素晴らしいですね。しかし、今度は異なる視点から来るQAを参加させましょう：

非ログインユーザーとして、ヘブライ語で正しいメールアドレスと正しいパスワードを入力すると、ホームページにリダイレクトされます

非ログインユーザーとして、正しいメールアドレスとパスワードを入力し、繰り返しログインをクリックすると、ホームページにリダイレクトされます

素晴らしいです。これで、さらに多くの状況をカバーするユーザーストーリーのセットを得ることができます。しかし、プロダクトを巻き込んだ場合はどうなるでしょうか？

非ログインユーザーとして、ページが読み込まれると、パスワードマネージャーがユーザー名とパスワードを事前に読み込んでくれ、ログインをクリックすると、ホームページにリダイレクトされます

プロダクトチームはユーザーを理解しています。彼らは人々が実際にパスワードマネージャーを使用していることを知っています。ユーザーが実際に何も入力しない場合（テキストがパスワードマネージャーによって読み込まれるため）、ログインが正しく機能することを確認する必要があります。

曖昧なユーザーストーリー

良いユーザーストーリーの背後にあるアイデアは、専門知識に関係なく誰もが理解できることです。

10人の異なる人によって10通りの解釈が可能なユーザーストーリーを書いた場合、少し間違っています。

受け入れ基準について触れると前述しましたが、今そのことについて触れます。

次のユーザーストーリーを再検討しましょう：

ログインしていないユーザーとして、無効なメールアドレスとパスワードを入力してログインをクリックすると、エラーメッセージが表示されます。

そこには曖昧さがあります。

どのメッセージが表示されるべきですか？無効なログイン試行の後、ページが再読み込みされる際、ユーザー名のテキストボックスは空に戻されるべきか、それとも以前に入力した値で事前入力されるべきか？「無効なメールアドレス」とは何を意味しますか？今まで見たことのないメールアドレス、または現在無効なメールアドレス（サブスクリプションが未払い、サブスクリプションがキャンセルされた等）でしょうか？

ですので、詳細が重要です。

このユーザーストーリーはかなり不自然なシンプルな例であり、たくさんの疑問を見つけることができました。

問題を修正しましょう：

ログインしていないユーザーとして、システムに登録されていないメールアドレスを入力し、ログインをクリックすると、エラーメッセージが表示されます。

それはユーザーアクションに関する質問を取り除きましたが、期待されるエラーメッセージに関する問題は解決されていませんでした。

受け入れ基準を入力してください。

ユーザーストーリーの中には、ユーザーストーリーの実装が期待通りであるかどうかを定義する受け入れ基準のセットを持つ必要があります。

具体的には：

  • エラーメッセージ：「無効なメールアドレスまたはパスワード」

  • メールアドレスとパスワードのテキストボックスはリロード時に空にリセットされる

  • ユーザーはログインが必要なページにアクセスできない

  • ユーザーには「パスワードを忘れた」提案が表示される。

受け入れ基準は、実装から期待されることを示しています。

ユーザーストーリーを始める方法

小さく始めてください。

最初はユーザーストーリーを洗練させたり作成したりすることは完璧ではありません。

ユーザーストーリーの作成は、科学と同じくらいアートでもあります。練習すれば完璧になります。

ユーザーストーリーの作成はグループで行うべきです。多くの場合、「3人のアミーゴ」アプローチを使って、エンジニア、プロダクト担当者、QAが一緒に座り、サポートが必要なさまざまな組み合わせをブレインストーミングします。

プロジェクトを納品したら、振り返りを行いましょう。ユーザーストーリーにどのようなギャップがあるのかを見直してください。ユーザーやQA、UATが見つけるバグは、ユーザーストーリーのギャップやテストのギャップが原因です。いずれにせよ、次回に向けて学びましょう。

結論

アジャイルは協力的です。スクラムも協力的です。ユーザーストーリーの作成は協力的です。それを忘れないでください。

異なる専門分野の人々がユーザーストーリーの作成についてブレインストーミングを行うほど、ワークフローの全セットをカバーする可能性が高まります。

ユーザーが焦点です。ユーザーが理解できない用語を含めている場合は、ユーザーストーリーを再考してください。

最初から完璧である必要はありませんが、回数を重ねるごとに、より迅速で効果的になります。これを10年以上この仕事をしている私からのアドバイスとして受け取ってください。今日の私のユーザーストーリー作成の速度と品質は、10年前とはまったく異なります。

私のウェブサイトのブログ投稿をチェックするか、Just Another Tech Leadで週刊メールニュースレターに登録してください。こちらから。