こんにちは。 Product Team の相川です。 現在はProduct TeamでINITIALというプロダクトの開発をしております。
改めてのお話になりますが、Product TeamではXP(extreme programming)を軸にアジャイル開発を実践しています。 アジャイルのプラクティスについて、僕たちのチームではかなり強度を高く持って実践しているのですが、 そもそもなぜ、そのプラクティスをやっているのか？やっていく中で感じたメリットや伸びしろなどを交えて、何度かに渡って発信していきたいと思います。 今回はユーザーストーリーについて、お話していきます。
ユーザーストーリーとは
プロダクトチームでは、開発する内容をユーザーストーリーと呼ばれる、ストーリーで管理をしています。
ユーザーストーリーを端的に言うと、「どのようなユーザーにどのような価値を提供するのか」を明確にしたものです。以下に、例をあげておくと、
「ユーザーは〇〇ページにアクセスできる」
「ユーザーは〇〇ページのXXセクションを見ることができる」
といったものが挙げられます。
実際に、(今はオンラインのツール上でですが)上記の文言で定義した付箋をバックログないしカンバン上に置いて、日々開発を進めています。
XPではユーザーストーリーをなるべくシンプルかつできるだけ小さいものにすることが良いとされています。 なので、ユーザーストーリーは上記のような非常にシンプルな作りになっているのですが、逆に「シンプルすぎて何をやったら良いのか付箋から伝わってきにくい」という指摘がありそうな気がします。(実際、私も初めてユーザーストーリーを見た時にそのような感覚を持ちました)
ですが、アリスター・コーバーン(アジャイルマニフェストの執筆者のひとり)によると、ストーリーは「将来の会話のための約束手形」という位置づけをしているので、会話をするのに十分な情報さえ乗っていれば良く、詳細は着手する際にコミュニケーションをとれば良いとされています。
ユーザーストーリーの切り方については、話すと長くなりそうなので、詳細については今回は割愛します。
ユーザーストーリーのメリット
ここからは実際にユーザーストーリーを使うメリットについて挙げていきたいと思います。
顧客にとって伝わる文言で書かれていること
ユーザーストーリーは上述の通り、「ユーザーは・・・」という文言で始まります。他にも「開発者は・・・」であったり、「ビジネスサイドは・・・」といった文言で始まることもありますが、すべて誰に価値を届けるストーリーなのか明確にしています。なので、ビジネスサイドであったり、プロダクトオーナーであったり、誰が見ても誰のための開発を今しているのかが、ひと目でわかるようになっているので、顧客との共通理解を作りやすいというメリットがあります。
なので、ストーリーを出す時に、顧客にも入ってもらって一緒にストーリーを考えるということが可能になりますし、実際に僕たちのチームではCS(カスタマーサクセス)の人やデザイナーの人にもプロジェクトのキックオフに参加してもらって、一緒にストーリーを出すということをしています。
優先順位の判断とスコープの調整をしやすい
ユーザーストーリーは、開発優先度を決める時やスコープの調整をするとき効果を発揮します。例えば、以下に3つのストーリーがあるとして、
「ユーザーは〇〇ページでXXの説明をみることができる」
「ユーザーは〇〇ページでXXの説明を省略表示でみることができる」
「ユーザーは〇〇ページでXXの省略表示された説明をホバーするとすべてみることができる」
プランニングしているときに、まずは1番上のストーリーだけやってみて、表示した結果を見てからまた判断することができると思います。また、
「ユーザーは〇〇ページでXXをみることができる」
「ユーザーは〇〇ページでXXを押すとページに遷移できる」
みたいな場合、まずは表示だけして、ユーザーに最小限の価値を届けようといった判断も可能になります。
なので、ユーザーストーリーを使い、ユーザーに届ける価値をできるだけ細かくしていくことで、プランニングで柔軟な調整が可能になります。
完了の定義が明確であること
ユーザーストーリーは、何を持ってしてそのストーリーが完了したと判断できるか？ということが明確です。なぜなら、そのストーリーに書かれたことが実現できているかどうかをひと目に判断できるからです。(厳密には、そのストーリーを出したときの前提を満たしていることだとは思います。)
XPには「完全DONE」というプラクティスがあります。「完全DONE」にしていいのか、いけないのか、といった判断をストーリーの文言に基づいて、誰もが判断できるというのも、ユーザーストーリーの強みかなと思います。
自分たちのモチベーションを助ける
これは、賛否両論ある気がするのですが、私は最近特に感じているメリットです。
ユーザーストーリーにすることで、プランニング時点でイテレーションが終わった時にどんな価値が届いてることが想像しやすくなります。逆に言えば、顧客に価値のとどかないユーザーストーリー(開発者ストーリーと呼んでます)しか積んでないイテレーションでは、イテレーションが終わったときにユーザー向けリリースはないかもしれないと心の準備をすることができます。
些細なことではあるのですが、このことがプランニング時点でわかってるのとわかってないのでは自分たちのモチベーションに与えるインパクトは変わります。
例えば、何回かイテレーションを進めていく中で、順調にユーザーストーリーを消化することができていて、確実に価値を届けることができているチームがあったとします。そんな中で、突然何もユーザーに価値が届けられないイテレーションが発生すると、急に不安や消化不良が襲ってきます。ですが、イテレーションの時点でそれに気づいていて、チーム全体で合意をとっておけば、その事実の受け止め方は変わってきます。
1つ1つのストーリーでどのような価値が届くのか、イテレーション全体ではどのような価値が届くのか、俯瞰的に把握することができるのもユーザーストーリーならではのメリットではないかなと個人的には思ってます。
ユーザーストーリーの難しさ
ここまで、ユーザーストーリーの良い側面ばかりお伝えしましたが、ユーザーストーリーにも難しさはあります。
ユーザーストーリーを使うことの難しさは、ユーザーストーリーを使いこなすことだと思います。(ちょっと哲学的ですがw)
ストーリーは、できるだけ小さくすること、ストーリー同士の依存関係ができるだけないことが理想とされています。しかし、この2つについては、頭でわかっていても実践することがめちゃめちゃ難しいというのが実感です。
「できるだけ小さくする」といった文脈では、主観的には小さいつもりでもCTOに見てもらったときに「もっと小さくできるでしょ」と突っ込まれた経験が何度もありますし、「ストーリー同士の依存関係」については、ストーリー出しの時点では依存を排除したつもりでも、着手したらめちゃめちゃ依存していたみたいなこともありました。
これらについては、何度もやってみてアジャイルに精通した人にフィードバックをもらって、改善していくことで、ユーザーストーリーを使いこなせるようになっていくのかなと思います。
大事なことは、ストーリーについて不安を持ったり、気になった時点で、アジャイルに精通している人(アジャイルコーチ的な人)に相談することです。
まとめ
今回はユーザーストーリーについてお話してみました。
このような感じで、私の所属しているProduct Teamでは当たり前のようにユーザーストーリーを使ってタスク管理を行っていて、それぞれがユーザーストーリーを使う意義を感じているはずです(...そう信じてます。笑) なので、今までユーザーストーリーを使ったことのない方に、少しでも興味を持ってもらって、ユーザーストーリーを使ってみようと思うきっかけになったら嬉しいと思ってます。
おわりに
ユーザベースではエンジニアを募集しています。
アジャイル開発をやっていて話をしてみたいと思ってくださった方、アジャイル開発はやってないけど興味を持ってくださった方など、ぜひ一度お話できればと思っております！
