ユーザーストーリーを作成する

学習の目的

この単元を完了すると、次のことができるようになります。

• 受け入れ条件を設定する重要性を説明する。
  
• ユーザーストーリーを作成するための INVEST の概念を要約する。
  
• ユーザーストーリーを作成するときに避けるべき一般的な間違いを特定する。
  

プロジェクトチームを集める

ユーザーストーリーの作成ワークショップはプロジェクトの初期に行うことをお勧めします。ストーリー作成ワークショップには、プロジェクトチームであるプロジェクトマネージャー、開発者、システム管理者、UX デザイナー、ユーザーなどが参加するようにします。参加者はブレインストーミングを行ってストーリーのアイデアを出します。ユーザーストーリーの作成では、チーム全体の創造性を発揮する必要があります。最初のユーザーストーリーは変更不可の決定事項ではありません。ユーザーストーリーの良いところは、反復開発が促進され、何度でも調整できることです。 

プロジェクトチームでユーザーストーリーを作成しているときには、そのユーザーストーリーがどのように実装されるか (どのコンポーネントやサービスが影響を受けるかなど) について決めつけないようにします。そのような決定は、開発/実装チームが計画ミーティングで行います。

条件の必要性を受け入れる

プロジェクトグループが集まると、同じ問題がさまざまな角度から捉えられるのは当然のことです。このような異なる視点はどうしても必要ですし有用でもありますが、成功の評価基準について合意できなければストレスにもなります。この基準は受け入れ条件と呼ばれます。受け入れ条件とは、ユーザーストーリーに加えられる一連のステートメントで、各ステートメントでは明確な合格/不合格の結果を指定します。簡単に言うと、受け入れ条件とはユーザーストーリーが達成される条件を指定するものです。シンプルな言葉で明確に表現し、期待される結果があいまいにならないようにします。受け入れ条件が適切に作成されると、プロジェクトのさまざまなフェーズやステークホルダーに次のような利点があります。

• プロジェクトチームの範囲が明確になる。
  
• 開発/実装チームに役立つ。
  
• テスト担当者が何をテストすべきかを知っている。
  

受け入れ条件は意図を記述するものであって、ソリューションを記述するものではありません。「どのように」ではなく「何を」について考えます。 

• ソリューションに重点を置いているため適切でない受け入れ条件の例: 地域マネージャーが [承認/却下] ボタンをクリックして商品の割引価格を承認できる。
  
• 意図に重点を置いているため適切な受け入れ条件の例: 地域マネージャーが商品の割引価格を承認または却下できる。
  

ユーザーストーリーステートメントのワークショップが完了したら、受け入れ条件を追加します。前の単元のユーザーストーリーに戻りましょう。 

ユーザーストーリーの例: カスタマーケア担当者として、私はハイタッチカスタマーエクスペリエンスを提供するために、新しいケースの所有権を取得してお客様とコミュニケーションを行うことが必要です。

このユーザーストーリーの受け入れ条件は、たとえば次のようになります。

• キューからケースの所有権を取得する。
  
• ケースページからお客様にメールを送信する。
  
• ケースの詳細 (状況、件名、説明) を更新する。
  

受け入れ条件は if/then ステートメントの形式にすることもできます。上記の受け入れ条件を if/then ステートメントとして記述すると「(if) ケースページを表示していれば、(then) お客様にメールを送信する機能にアクセスできる」となります。形式がどのようなものであっても、すべてのユーザーストーリーには少なくとも 1 つの受け入れ条件が必要です。各条件は、単独でテストすることが可能で、true または false で答えられる必要があります。

ユーザーストーリーと受け入れ条件を作成するときに、この詳細すべてをどのようにして思い出せるだろうかと考えている方もいるかもしれません。ヒント: 頭文字で覚えましょう。

ユーザーストーリーの INVEST

個人的な ToDo リストに「新しいチェックリストについて学習する」という項目がある方に朗報です。その項目をリストから消すことができます。Salesforce ビジネスアナリストは INVEST チェックリスト (2003 年に Bill Wake が作成) を使用してユーザーストーリーの品質を評価できます。ユーザーストーリーがいずれかのチェック項目を満たさない場合には、おそらく作成し直す必要があります。 

成功するユーザーストーリーは次の条件を満たしています。

• 独立している (Independent): ユーザーストーリーは独立していて、別のユーザーストーリーと概念が重複しないようにする必要があります。
  
• 交渉可能である (Negotiable): ユーザーストーリーは契約ではありません。ストーリーは会話のきっかけです。要点を捉えたものであり、詳細が記述されたものではありません。
  
• 価値がある (Valuable): ユーザーストーリーはエンドユーザーにとって役に立つものである必要があります。ストーリーに価値がなければ、作成されるべきではありません。
  
• 推定可能である (Estimable): 成功するユーザーストーリーのタイムラインは推定できます。正確な推定は必要ありませんが、ストーリーの開発/実装の優先順位とスケジュールを決定するのに役立つ程度に推定できる必要があります。
  
• 小規模である (Small): ほとんどの効果的なユーザーストーリーは小規模です。小規模なユーザーストーリーの方が、正確にタイムラインを推定できる傾向にあります。詳細は会話によって決定できることを覚えておいてください。
  
• テスト可能である (Testable): 良いユーザーストーリーはテストできます。成功するユーザーストーリーの場合、プロジェクトチームの誰もがそのユーザーストーリーを見て「はい、私はこのユーザーストーリーをよく理解していて、受け入れ条件を記述できます」と言えます。
  

避けるべき間違い

複数のステップを含む他のプロセスと同様、間違いは起こります。ユーザーストーリーもそのような間違いの例外ではありません。幸い、ユーザーストーリーは調整可能であるため、常に反復の余地があります。ただしもちろん、最初から間違いを避けるのに越したことはありません。一般的なユーザーストーリーの間違いと Salesforce ユーザーがそれを避けるためのヒントを紹介します。

プロジェクトチームがストーリーの作成に関与しなかった。

• 結果: ユーザーストーリーはプロジェクトチームの複数の視点を表していません。ユーザーストーリーの大幅な書き換えは避けられません。
  
• 回避方法: プロジェクトの開始時にストーリー作成セッションをスケジュールします。継続的にプロジェクトメンバーとユーザーストーリーを見直し、議論します。
  

ユーザーストーリーの「誰」が未定義のユーザーである。

• 結果: このユーザーが未定義であるために開発チームはユーザーのモチベーションやニーズの役割を理解するのが困難です。ユーザーストーリーによって意図した結果が得られません。
  
• 回避方法: ユーザーストーリーを作成する前に、定義されたユーザーの人格のリストを作成します。この明確に定義された人格は、ユーザーストーリーを作成するとき、ソリューションを開発/実装するとき、テストを行うときに参照できます。
  

ユーザーストーリーの「なぜ」で機能が限定されている。

• 結果: ユーザーストーリーが過度に技術的であり詳細に重点が置かれているため、ストーリーというよりもツールの説明のようになってしまいます。ユーザーニーズに対応していません。
  
• 回避方法: ユーザーのニーズを最優先します。作成後にユーザーストーリーを読み直し、詳細に重点を置きすぎていないかを確認します。プロジェクトチームからのフィードバックをいつでも歓迎します。
  

受け入れ条件があいまいすぎる。

• 結果: 具体的でテスト可能な受け入れ条件がなければ、ユーザーストーリーが成功したかどうかを信頼できる方法で測定できません。
  
• 回避方法: すべての受け入れ条件が独立していて、true または false で答えられることを確認します。プロジェクトチームと協力して、ユーザーの目標に沿った受け入れ条件を作成します。
  

チームの議論を行わないままユーザーストーリーが実装チームに割り当てられた。

• 結果: 開発中にユーザーストーリーが誤って解釈される可能性が高くなります。最終成果物が意図したものと大きく異なる可能性があります。
  
• 回避方法: ユーザーストーリーを割り当てるときには、チームと一緒にストーリーを確認します。詳細を見直し、意図を強調し、チームの認識が統一されていることを確認します。
  

このように、ユーザーストーリーのプロセスに適切に従えば、上記の間違いはすべて避けることができます。手順を省いてはいけません。プロセスを信頼すれば、最終的にお客様/エンドユーザーの成功に重点を置いたソリューションを実現できます。

ユーザーストーリーがユーザーについてのストーリーだという当たり前な定義がそれほど的外れではないように思えますよね? ここでは、ユーザーストーリーについて、その目的、各部分、関与する参加者、テスト方法、避けるべき間違い、そしてユーザーストーリーを評価するための頭文字まで、多くのことを学習しました。この新しい最大の味方について新しく身に付けた知識を活かして、ユーザーについてのストーリーを作成してみてください。