ユーザーストーリーを使って、ユーザー価値を素早く実現しよう!

使い方編:ソフトウェアエンジニアの視点

Yuka Kobayashi
Product Run
Apr 12, 2023

--

VMware Tanzu LabsでソフトウェアエンジニアをしているYukaです。

今回はユーザーストーリー3部作の使い方編として、プロダクトマネージャー(PM)やデザイナーから受けとったユーザーストーリーをTanzu Labsのソフトウェアエンジニアがどういう風に開発に活用しているかを紹介したいと思います。

エンジニア視点でのメリットについての話が多くはなりますが、他のロールから見てもユーザーストーリーが具体的にどう役立っているかを知り、そこからストーリーを書くモチベーションに繋げてもらえると嬉しいです。

Photo by Desola Lanre-Ologun on Unsplash

ユーザーストーリーとはなんなのか

いざユーザーストーリーを元に実装しよう!となったとき、みなさんはどんなことを考えながら着手しますか?

ここで重要なのは、ユーザーストーリーは「仕様書」や「決定済みで変更ができないもの」ではないということです。

もしストーリーが「仕様書」でありそのまま実装すべきものであれば、Acceptance Criteria(受け入れ条件)だけ書いてあればよいかもしれません。しかし我々の作るユーザーストーリーには、必ずWhyが一緒に書かれています。

その理由はユーザーストーリーが表現しているものは「ユーザーに提供したい価値」であり、その実現方法は交渉が可能だからです。

それでは、なぜユーザーストーリーは「ユーザーに提供したい価値」を定義し、エンジニアがそれを理解・意識する必要があるのでしょうか。

エンジニアが「ユーザー価値」を理解すると何が起こるのか

具体的な例で考えてみましょう!

タスク管理ができるWebアプリケーションで、以下のようなユーザーストーリーがあったとします。

Why
高橋さんは
(I want to) タスクの期限の日付を入力したい
(So that I can) いつまでにタスクを終わらせるべきか管理したいからだ

Acceptance Criteria
Given タスク新規登録画面にいるとき
When 「期限」ラベルのついたテキストフィールドをクリックすると
Then 「YYYY/mm/dd」のフォーマットで日付をテキスト入力できる

このストーリーは開発初期に作られたストーリーを想定しています。

LeanXPでの開発の場合、まずはユーザーが一番ハッピーになれる一連の流れを実装し、その後に細かいユースケースやユーザビリティの改善に着手していくことが多いです。そのためこの時点ではWhyにもあるようにタスクの管理をするために日付入力できることが最優先であり、一番素早く実装できる実現方法を選ぶのが望ましいと考えます。

このストーリーを書いた人は「将来的にはもっとリッチで使いやすいUIにしたいけど、現時点では一番シンプルな方法でいいのでテキスト入力にしよう」と考えてAcceptance Criteriaを書きました。

しかしこのストーリーを見たエンジニアは「実はHTMLで使える標準の日付選択UIがあって、そっちの方がシンプルな実装でWhyが達成できる(更にユーザーも使いやすいだろう)」ということに気付きました。

そういったアイディアが浮かんだら、交渉してストーリーを改善するチャンスです!

すぐにPMと相談して、Acceptance Criteriaを修正すべきかどうかディスカッションをしてみましょう。それによってチームはより早くより良い価値をユーザーに提供できるようになるはずです。

意図を理解することで、素早く改善ができる

先ほどの例のように、エンジニアがストーリーの価値や意図を理解していると、重要な部分・融通が効く部分がわかっているので、具体的かつ受け入れやすいアイディアを思いつきやすい状態になります。

これによりチームは開発の速度やプロダクトの価値を素早く改善していくことができるのです。実際、こういった提案はテストや実装を始めてからわかることも多いので、常にチーム全員がこういった提案やコミュニケーションにオープンな気持ちでいることも大切にしています。

機能やUIを率先して考えるのはエンジニア以外のロールがやることが多いかもしれません。でもエンジニアには技術や実現可能性についての専門知識があります。その知識や視点を活かすことで、コードを書くこと以外でチームに貢献するチャンスはたくさんあります!

我々のプロセスではそういったチームのコラボレーションを大事にしているため、ユーザーストーリーを使った開発は文化や雰囲気作りにも役立っていると思います。

ちなみに、Acceptance Criteriaに直接的に現れない部分であればもっとカジュアルにエンジニアの判断に委ねられることもあります。

成功ケースを実装するストーリーのIPMで「この処理でエラーが起きたときはどうする?」という質問が出た場合、「現時点ではエンジニアにお任せします」という結論になることも多いです。そういうときはエラーケースのことはあまり考えず成功ケースのための最低限の実装をしていき、今はエラーが起きるとこういう挙動になっているよ!という共有をするようにしています。(そしてエラーケースは後々必要となったタイミングで改めて別ストーリーにします)

ユーザーストーリーがチームにもたらす変化

ユーザーストーリーはチームのコミュニケーションツールであり、エンジニアにとってはユーザー(とチーム)のために最適な実現方法を提案・実装するための手掛かりでもあります。

それによりエンジニアを含めたチームメンバー全員が、「言われた通りに作る人」ではなく、より自律的に行動できる状態、つまりアジャイルなチームに近づくことができるんじゃないかなと思います。

今回の記事が、自律性を持ってチーム全員でどんどんプロダクトを改善していきたい!というチームの参考になれば嬉しいです。

さいごに

ユーザーストーリーの使い方編、いかがだったでしょうか。

今回はコミュニケーションをテーマに書いてみましたが、更にエンジニア特有の使い方で言うとAcceptance Criteriaがテストを書く手助けになったり、小さいストーリーが開発のモチベーションにもたらす効果などまだまだたくさんのメリットがあるので、それらも今後記事にしていけたらと思います。

また、各ロールが協力して記事を書くのも初めての試みでした。書きながら普段の自分たちの考えやプロセスについて話す機会がたくさんでき、とても楽しかったです!みなさんもこの3部作を読んで、チームでの会話やディスカッションのきっかけにしてもらえれば嬉しいです。

まだ他の記事を読んでない方も是非読んでみてください。

以上、使い方編でした。

--

--