【保存版】ユーザーストーリーの基本｜アジャイル開発に携わるメンバーが抑えるべきポイント
アジャイル開発を行っている担当者なら、ユーザーストーリーという言葉はよく耳にすると思います。開発する上で、ユーザー目線の・・・・と想起する方は多いと思いますが、実際は、下記のような疑問をお持ちではないでしょうか？
・ユーザーストーリーってそもそもなに？
・どんなときにユーザーストーリーを使えばいいのか？
・どうやってユーザーストーリーを書けばいいのか？
上記のような疑問や不安にお応えしていきます。
今回の記事を読めばこれがわかる！
☑️ ユーザーストーリーの目的が理解できる ☑️ ユーザーストーリーを使ったほうが良い場合 ☑️ ユーザーストーリーの書き方
この記事を書いている私は、、
普段はマーケター＆ディレクターとして、アジャイル開発を行うプロジェクトに関わっています。サイト内の数値分析からUI／UX面を考慮した仕様書・画面設計書を書き、サービスを使うユーザー層をカテゴライズし、どんなUI/UXであれば使いやすい、イケてるとおもわれるのか？という検証を日々行っています。
そんな私がユーザーストーリーについて解説していきます！！
目次
ユーザーストーリーの目的
ユーザーストーリーの全体像を掴むのであれば、まずは下記２つのことを必ず抑えましょう。
- ユーザーストーリーの基本のキ
- なぜユーザーストーリーを使うのか？
概要を理解し、ユーザーストーリーを最適なタイミングで使うことであなたのプロダクトは無駄な開発をなくし、大きく成長すること間違いないでしょう。
ユーザーストーリーの基本のキ
ユーザーストーリーとは
ユーザーストーリーはシステム開発の中でもアジャイルでの開発でよく使われる手法で、「誰が・どういった目的で・何をしたいのか」という開発する上でその機能が叶えるべき経験・体験を表した短い文章のことです。
端的にあらわすと、下記画像のような文章のことを指します。
ポイントは「How」の部分は文章の中に含めないということです。どうやってユーザーストーリーを叶えるのか？はチームで会話をして決めていくため、あえて含めないのが重要なポイントです。
誰がやるのか？
ユーザーストーリーはプロジェクトに関わる人であれば誰でも作れます。
ただ、具体的なペルソナ・獲得したいユーザー層など、サービスのグロースに向けてある程度イメージができている役割の人のほうが適任です。例えば、プロジェクトマネージャーやプロダクトオーナー、UXデザイナーなど、多角的な視点を持っている方が活用できる情報が増えるため、より複数のユーザーストーリーを書き出すことができます。
なぜユーザーストーリーを使うのか？
必要な要件は変化していく
そもそもユーザーの課題解決のアイデアは出てくるが、ユーザーが求めている「システム要件」は開発者でもプロダクトオーナーでもユーザーでさえもわかりません。ユーザーも運用側も、システムに触れれば触れるほど、こうなればいいな、こんな機能あればいいなと思うからです。そのため、実装し、検証して、もともとの要件に変更を加えていくのが当たり前という考えが一般的になっています。
そこで、急な変更や、柔軟性が高いアジャイル開発の手法で、ユーザーストーリーという軸（最低限の要件）があれば、開発の効率も、実装・検証を行うスピードも効率が上がります。細かいことは定義せず、ユーザーが何を求めているのか？をベースとして、認識齟齬がないようにチームで会話をし、メンバーの意見を一致させながら、「どうやって、何を作るのか」を決めることが大事です。
ユーザーストーリーがもたらす６つのメリット
ユーザーストーリーは上記でも述べているよう、無駄な要件はなく、ユーザー目線のシンプルな要望のみ言語化しているため、開発チームは素早く、質も担保してユーザーの求めている機能を届けることができるようになります。というのも、下記のようなことが自然とできるようになるからです。
1.ユーザーが抱えている課題の解決でプロダクトの価値の提供ができる
2.１つのユーザーストーリーでも汎用性がある
3.バックログに溜まったタスクの整理がしやすい
4.システム的観点の機能は一旦無視できる
5.開発側の認識齟齬がない
6.時間の節約になり、スケジュールが立てやすい
こんな場合はユーザーストーリーを使おう
ユーザーストーリーを作成したほうがよい場合はたくさんありますが、少し例を用いて、さらに理解を深めることができればと思います。
ここではよくある代表例を２つ紹介したいと思います。
ケース１：バックログにやることが蓄積していて優先順位がつけれない
ケース２：エンジニアとステークホルダーの認識がなんとなく違うと感じる
開発に携わっている方なら必ず直面する課題ですよね。ユーザーストーリーをつくることによってどう解決できるのかを解説したいと思います。
ケース１：バックログにやることが蓄積していて優先順位がつけれない
開発に携わっていると、バックログ（やりたいこと・やらないといけないことリスト）にたくさん課題が上がってきます。優先順位をつけようにも何から手をつけていいのかわからず、結局、工数が少ないもの、売上インパクトの高そうなもの、人件費が削れそうなものから着手していくチームが多いのではないでしょうか？
そうなってくると、ユーザー目線が置いてけぼりになり、本当にユーザーが欲しているものがわからなくなりがちです。気づけば、デザインが古くなっていたり、システムも古くなっていたりと流れの早いIT業界で取り残されるプロダクトも多く存在しています。一方で、去年は全く名前も知らなかったサービスが、今年は大人気で世の中に広く知られていることも珍しくなくなってきました。
そうするためにも、ユーザーストーリーを使用し、今、ユーザーが何を求めているのか？を追求することで、何から着手すべきかを明確にします。
特に最低限の機能だけで作るMVPを開発する場合では、ユーザーストーリーを規則的に羅列させ、マッピングすることで「最低限の機能」の定義から視覚化することができ、重宝されます。
ユーザーストーリーマッピングについては、また別の機会で記載できればと思います。
私自身がよく行う方法としては、ユーザーストーリーの見直しや、ユーザーストーリーの開発のフェーズごとのスパンか、固定の期間（1ヶ月とか3ヶ月）などを設けて優先順位の見直しを行うことがよいと思います。
売上が企業の業績に直結する場合であれば、年間計画のうちの四半期ごとでも良いとおもいますし、開発のスパンが業績と切り離されているのであれば、開発のフェーズごとに分けるのも一つの手です。
ケース２：エンジニアとステークホルダーの認識がなんとなく違うと感じる
要件定義書などをしっかり書いていても、アジャイル開発でスプリントを何回も回しているエンジニアからすると、プロダクト、サービスのゴールや、機能の目的などが不明瞭になることが多々あります。サービスの全容が見えているプロジェクトマネージャーやプロダクトオーナーはそういう点で、目的やゴールの共有を小さい単位でできるユーザーストーリーは、使うべきです。
いくら優秀なエンジニアがいたとしても、不明瞭なままで機能を実装すると、ユーザーはその機能を使いこなすことができない、エンジニアは納得できず不満が募る、開発した時間と労力が無駄という負の循環に陥ってしまうのはもったいないです。
そのため、「誰が何をなんでしたいのか？」という行動に注目して言語化されていれば、チーム一丸となりその問題点解決のためのベクトルを同じ方向に向けることができます。
さらに、ユーザーストーリーだと、最低限の要望しか書かれていないため、HOWの部分は必ず相談ベースの議論を行う必要があります。そのため、メンバーそれぞれが課題を理解し、助け合い、実装と検証を行うことができます。
１つ１つ会話するのはめんどくさいと思われがちですが、いざ、認識齟齬がある状態とない状態であれば、ない状態にするために会話を密に行う方が良い場合も多々あります。
ユーザーストーリーの書き方がひと目でわかる！！
では、最後に、今まで述べたケースなどを加味して、実際にユーザーストーリーに基づいて開発を整理したいと言う方のために、やり方を説明します。
ここでは実行する下記２つのポイントを解説します。
1) 準備物
2) だれが・何を・なんでやる必要があるのか？（WHO・WHAT・WHY）
準備物
まずは準備物です。
レガシー的方法でステークホルダーが１つの空間に集まれるのであれば、下記のものを準備しましょう。
- 付箋（名刺サイズの小さめのカード）
- ホワイトボード（大きめのテーブル）
- ペン
この３点を用意し、後は、全員が話せるよう、会議室・ラウンジなど、少しにぎやかになってもいい空間も準備できるとなお良いです。
とはいえ、このコロナ禍、リモートワークも当たり前になってきている場合は難しいため、オンラインでも使えるツールのMiroがおすすめです。
Miro自体は英語表記ですが、クラウドのツールのため、Web会議ツールで全員がオンラインのまま、参加メンバー全員で一斉に編集することができます。
付箋の色も多彩に選ぶことができ、後々ユーザーストーリーマッピングを行う際も色別にカテゴリーを分けたりなど、視認性も上がります。
だれが・何を・なんでやるのか
ユーザーストーリーは例に上げているように、下記の３つの問に答える形で、完結に付箋に記載していきます。
- 誰のための機能なのか？
- システム的に期待することは何なのか？
- なぜその機能が大切なのか？
その際、ほぼ８割で使われるテンプレートが、英語表記では「As a role, I want to action, so that benefit」という形です。日本語に訳すと、下記のようになります。
*以下引用
[ ユーザー／顧客 ] として、
クレスコエンジニアブログ
[ 達成したいゴール ] をしたい、
なぜなら[ 理由 ] だから。
個人的にはもう少し、日本語っぽく違和感なくしたいと思い、下記にたどり着きました。
「自分が〇〇の立場なら、□□のために、△△をしたい」
意味はほぼ同じなのですが、、、こっちの方がしっくり来る感じがあったので、これで統一しました。ユーザー目線になりきるという意図も含められているのでわかりやすいと思います。
ここで必ず意識する点としては、最初にも軽く記載した通り、「どのように」「どうやって」の部分はあえて深く記載しないことです。
例えば下記のような感じです。
- 自分が顧客の立場なら、一度購入したものをより簡単に・早く再度購入できるように、購入履歴から再購入したい
- 自分がマーケターの立場なら、週次でコンバージョンを計測するためにレポートをダウンロードしたい
- 自分がユーザーの立場なら、自分にあった時間・場所で受け取れるように荷物が地域の営業所に届いた時点で通知がほしい
普段の開発でも、要件定義を行う際や、仕様を詰める際はエンジニアとのコミュニケーションが発生しますが、ユーザーストーリーをベースに開発を行う場合も同様に、必ず議論や開発についての会話がエンジニアを含めたステークホルダーと発生します。しかし、大きく違う点は、「どのように」や「どうやって」の段階からステークホルダーで話し合って決めていくことです。
そのため、多少ユーザーストーリーが大まかなざっくりしたものでも、話し合いで詳細を詰めていけるため、ユーザーストーリー自体の粒度はバラバラでも問題ありません。
大切なことは、ユーザーが何を求めているのか？を突き詰めるために、いかにユーザー目線で記載できるかです。また、記載後にしっかりチームメンバーで話し合いをするようにしましょう。そうすることで、認識齟齬も少なくなり、仕様の漏れも軽減することができます。
まとめ
ユーザーストーリーはアジャイル開発ではよく使われる方法で、短い文章で記載されます「自分が〇〇の立場なら、□□のために、△△をしたい」というユーザー目線で書くことによって、サービスやプロダクトでユーザーが本当に求めているものは何なのか？を突き詰めていくことができます。
プロダクトバックログにTodoが溜まってきて優先順位がつけられない時など、チームメンバーで一旦整理してみる際などに使用すると良いかもしれません。
ユーザーストーリーを行う場合は、必ずコミュニケーションが発生します。コミュニケーション活性化や、チームの団結力を上げるためにもおすすめです。
アジャイル開発についてもっと知りたい方は、アジャイル開発一覧をチェックしてみてください！
Enlytについて
株式会社Enlytはベトナムに開発拠点SupremeTechを持ち、Enlytではこれまで50以上の開発プロジェクトを行ってきました。（ 株式会社Enlytの実績は開発実績ページから）ベトナムと日本のグローバルなチームで、数多くのプロジェクトを成功に導いてきました。
アジャイル開発をご検討の際は、株式会社Enlytまでご気軽にお問合せください！お客様の納得のいくまで、共に開発させていただき、アイデアを最高のかたちにサービス化いたします。
下記ボタンより気軽にお問合せください！
