はじめに
こんにちは。LITALICOにQAエンジニアとして所属しています@take_takehiroです。「障害福祉サービスを展開する事業所様向けの請求業務支援システム」に関わらせてもらっております。本記事は、LITALICO Advent Calendar 2024の18日目の記事となります。
アジャイル開発を進めていらっしゃる方を中心に、「ユーザーストーリー」という言葉を耳にしたことはございますでしょうか。ユーザーストーリーとは何なのか、なぜ必要なのかといった観点で記載させていただきます。
ユーザーストーリーの定義
ユーザーストーリーについて、QbookのHPには下記の記載があります。（QbookのHP「ユーザーストーリーとは？書き方やアジャイル開発での進め方・ポイント」より引用）
- 定義：ユーザーが思い描く「理想のユーザー体験」を端的に言語化したもの
- 目的：ユーザーの要求とプロダクトの価値を正しく結びつけること
ポイントとして、「ユーザーの理想や要求に近づけるための具体的方法は書かない」ということが挙げられます。例えば、「スポーツの観戦グッズを購入したい」という場面があった時、「お店に行って購入する」「ネットで購入する」といった方法があると思いますが、「スポーツの観戦グッズを購入したい」という目的だけであれば、お店で購入しようがネットで購入しようが実現されることは変わらない、といった具合です。
上記内容を基に、ユーザーストーリーは、下図のような文章でまとめられます。
アジャイル開発におけるユーザーストーリーの重要性
アジャイル開発をテーマにする本を拝見すると、ユーザーストーリーの重要性をコラム形式で紹介されているのが多いように感じております。中にはコラムではなく、数ページにわたって紹介されている本もありますが、個人的な感想としては「気にした方が良い手法かもね」くらいの記載量かなという印象です。一方で、インターネットでアジャイル開発の調査をすると、ユーザーストーリーの重要性を力説している記事を目にすることもあり、本とインターネットでも温度差が違うのかなと思うと楽しかったりします。
アジャイル開発でユーザストーリーの重要性が言われるようになったのは、「短い開発サイクルを何度も繰り返して行うアジャイル開発において、各開発工程で十分に議論する時間を確保することが難しい」といったことがあると思います。ウォーターフォール型の開発に比べると、各工程での議論時間が短くなってしまう傾向にあります。そのためにユーザーストーリーを用いることで、「ユーザーにとって、何を実現出来ていると良いのか」「複雑な作業であってもシステムを使いたいと思っているような満足感を提供するために必要なこと」といったものを見える化し、アジャイル開発において何を達成方針にするかを明確することで、要件定義や実装といった開発工程を短距離で進めやすくなるメリットが出てきます。
上記までの説明で感じた方もいらっしゃると思いますが、ユーザーストーリーは要求整理や要件定義といった開発工程の始めから導入することが望まれます。一方で、ユーザーストーリーの温度差に所見を述べさせてもらった通り、ユーザーストーリーの重要性の感じ方や知る/知らないという点も千差万別の状態なのかなと思ってます。
私は、開発されたものに対してテストを行うことを主な業務としております。要件が固まり、開発がほぼ終わる時にテスト作成を行い、その後テストを行うことになります。以下では、そのテスト活動において、どのようにユーザーストーリーを用いているかを説明します。
なぜテストでユーザーストーリーを用いるか
弊社の開発活動においても開発者がテストを行うことが必須であるため、ある程度の品質は担保出来ていると言って良い状態です。それでもユーザーストーリーを用いたテストを行う理由は下記のようなものがあります。
- そもそもユーザーが達成したいことを達成出来る状態なのかを検証
- 開発したものをユーザーに使ってもらった時に満足してもらえるかの検証
例えば集計機能への開発があった場合、「集計で得られた情報を基にユーザーは判断作業をスムーズに行うことが出来るか」「関連する集計情報を近くに表示されていればユーザーが情報を確認するストレスを減らせることが出来るのでは」などといったユーザー目線での検証に重きを置きます。極端な例ではありますが、集計に関してユーザーの達成度や満足度の違いをまとめたのが下図となります。
上図は極端な例として示したため、左側のような表を目にすることはほぼないと思います。目にする機会がなぜないかとなると「月ごとに出力項目が違うから月別の評価が出来ない」「売上を円単位と個数単位を混在して出すと何を持って良いとするかの判断が出来ない」などといったことがあげられるでしょう。極端な例であればユーザー目線での検証は割とスムーズにいくかとおもいますが、テスト実施するなかで（テスト以外の開発工程でも構いません）、「何となく違和感」「これ使いやすい？」「開発したけどユーザーに使ってもらえるか、なんとなく自信がない」といったことに直面されたことは、どなたでも少なからず経験されたと思います。
このような事例へ対処するために「ユーザーストーリーを用いて検証をしよう」となります。ユーザー目線での作業内容や満足度をテキスト化して見える形で検証するために、先に定義した「【Who】が、【What】する。【Why】だからだ。」の構文に当てはめて検証を行います。
ユーザーストーリーには、心理やリスクが後ろに隠れている～隠れていることへの確認がテスト活動につながる～
再三ではありますが、ユーザーストーリーは「【Who】が、【What】する。【Why】だからだ。」という構文で構成されるものとなります。言い換えると、「主語・やりたいこと・理由」を明白にしましょう、ということになります。
ここで、「【Why】＝理由」について考えてみましょう。Whyが出てくるということは、それが達成されないと何かしら困ることが発生すると考えられます。例として先の集計機能について考えてみましょう。ユーザーストーリーを下記のようにしてみます。
- スーパーの店長は、売上状況を把握したい。繁忙期や閑散期の把握をしたいからだ。
【Why】に該当する「繁忙期や閑散期の把握をしたいからだ」に着目したいと思います。店長はなぜ把握したいのでしょうか。「繁忙期がある程度長期に渡るならアルバイトを雇った方が良いかもしれない」「閑散期を短くするための施策を考えるためにまずは時期を把握したい」などと【Why】が出てくる背景は無数に出てくると思います。見方を変えると、【Why】が達成されないと背景はリスクとなり、焦りや困惑といった心理に働きます。
そのため、ユーザーストーリーを作る際は、心理（どんな気持ちでいるか）やリスク（ユーザーストーリーが達成されないことによる課題）を合わせてまとめるようにします。合わせて行うことで、ユーザストーリーに対応したテストを行う際、「何を達成していればテストをOKとすることが出来るか」の判断軸に用いることが出来るようになります。
ユーザーストーリーを用いたテスト設計を行う場合、見える化したユーザーストーリー・心理・リスクなどを、ユーザーストーリーマップという形で1つのシートにまとめております。下図に、過去に作成したユーザーストーリーマップの一部を紹介させていただきます（※一部加工してます）。
テスト作成では、ユーザーストーリーマップに記載した内容を、そのままテスト観点として流用しております。テスト観点へ流用する際に文言を修正することが発生する場合は「ユーザーストーリーマップの作成において粒度が誤っていたか」「文章の書き方が変だったのではないか」など、自身で振り返ることも可能です。ここまで来れば、テスト設計の題材としては十分な情報が集まったことになるので、後は機械作業でテストシートを作成していく、といった段取りになります。
最近意識し取り組み始めたこと
テストに取り組む際、基本的にはissue単位で行うため、issueに記載されている内容を基にユーザーストーリーマップの作成などのテスト設計を行ってます。issueには「不具合内容や課題」「解決内容の概要」が明記されているので、テスト設計の回数を踏めば、ある程度こんな感じに進めれば良いのかなという検討は立てやすいです。その中で、個人的に気になっているのが、
- 解決されないとユーザーはどう困るのか（回避策はあるのか、ストレスのかかり方）
- 解決されることでユーザーはどう嬉しくなるのか
という点があまり明確になっていないのかなと感じてます。もちろん要求分析の時点で議論はされているはずなので、私が把握出来てない可能性は往々にしてある状態ですが・・・。そこで、上記の困ることや嬉しくなることに対してもユーザーストーリーを立ててみる活動を始めてます。例えば、先の集計機能であれば下記のようなユーザーストーリーを作ることが出来ます。
- 解決されないことによる困りごと
- スーパーの店長は、売上状況を把握したい。繁忙期や閑散期の把握出来ないと人材募集に影響が出るからだ。
- 解決されて嬉しくなること
- スーパーの店長は、売上状況を把握したい。繁忙期や閑散期の把握出来ることで適切に人材募集を行うことが出来るからだ。
上記「解決されないことによる困りごと」「解決されて嬉しくなること」のユーザーストーリーについて、ほぼ同じ内容で記載しました。ただし2つのユーザーストーリーを見て感じ方は違うのかなと思います。「解決されないことによる困りごと」を読むと「人材確保出来ないと店を開けることが出来なくなるかもしれない」といった雰囲気があるかもしれないため、リスクは大きくみても良いかもしれません。一方で「解決されて嬉しくなること」を読むと「人材募集円滑に行える手助けになってくれそう」と、ユーザーへシステムを使って頂く価値提供の明白化につなげることが出来ます。
ただし、上記のみのユーザーストーリーではリスクや価値提供につながる根拠や情報が少ない状態です。そのため、根拠や情報を明白にするため、紐づける形で別途ユーザーストーリーを用意するようにしてみました。ユーザーストーリーの二段構えといった感じです。二段構えで用意することで、「最も大事にすべき指針はブラさない」「リスクや価値提供につながる根拠や情報を整理して明確にする」「対応すべきユーザーストーリーの優先度の整理する」ことが出来ると思います。
ユーザーストーリーという言葉自体は、そんなに難しいものではないと思います。一方でいざ取り組むとなかなか奥が深いものとなります。システム開発にとどまらず、使い勝手次第では日常生活でも出来るのかなと思うので、固くならずに「まずはやってみる！！」精神で取り組んでみてはいかがでしょうか。