こんにちは。 Product Team の相川です。 現在はProduct TeamでINITIALというプロダクトの開発をしております。
前回からアジャイルについてブログを発信していこうと思い、ブログを書き始めました。
前回はユーザーストーリーについて書かせてもらいましたが、今回はそのユーザーストーリーを小さくすることと大きくすることについて説明します。
ユーザーストーリーは小さい方が良い
まず前提から話すと、ユーザーストーリーはできるだけ小さくしておいた方が良いです。
ユーザーストーリーを小さくしておくと以下のようなメリットがあります。
- 小さくリリースするので早くフィードバックをもらえる
- 見積もりがしやすい
- スコープの調整がしやすい
- ストーリーを出す時点での考慮漏れが減る
小さくリリースするので早くフィードバックをもらえる
当たり前ですが、ユーザーストーリーが小さければ小さいほど実装するものは少なくなります。なので、着手からリリースまでの時間は短くなり早くユーザーが確認できる状態に持っていくことが可能になります。その結果、それを見たユーザーからフィードバックをもらいやすく、そのフィードバックをプロダクトに反映しやすくなります。
逆に、大きなストーリーだと、全てを実装し終えるまでユーザーに見てもらえないですし、それまでフィードバックをもらうことが難しいです。その結果、実はユーザーとしては要らない機能だったとか、A機能よりB機能の方が先に欲しかったとか、ユーザーのニーズに応えられずにリリースしてしまうという不幸なことが発生してしまいます。
ちなみにProduct Team(SaaS側)において、ここでいう「リリース」は一般ユーザーに届けることを最初から目指しているのではなく、ベータ機能として社内に向けてリリースすることが多く、PdMをはじめとする関係者とドッグフーディングを経て一般公開になることが多いです。
見積もりがしやすい
ユーザーストーリーが大きくなると、考慮しないといけないことが増え、不確実性が増えます。不確実性が増えるとその分、見積りにかかる時間が増えていきます。見積りに時間がかかると、チームが疲れていき見積もり自体の数字がブレていきます。といった具合に負のサイクルに陥りがちです。
一方で、ユーザーストーリーが小さいと、そのストーリーあたりの関心事は少なくなり、不確実性は減り、早く見積りが終わる印象があります。
一般的に、アジャイルに関する書籍を読むと、1ストーリーあたり見積もりは1-2分くらいで終わらせる方が良いとされています。見積りの時間を短くすることは、ストーリーを小さくするだけでは達成できませんが、一方で、短くするのに必要な条件の1つであることは間違いないです。
スコープの調整がしやすい
フィードバックの話と多少重複する部分もあるのですが、ストーリーを小さくするとスコープが調整しやすくなります。例えば、ストーリーを小さくして、細かくリリースしていると早くフィードバックをもらえるというのは先述の通りですが、その中で想定していなかった追加機能のリクエストが発生したとします。
その場合に、細かくストーリーを切っておけば、プランニングの中で、同規模のものと比較して優先度を考えてスコープイン・スコープアウトをすることが可能になります。 ストーリーが大きいままだと、同規模のものがない・優先度の比較がしにくい、ということが起こり、スコープの調整に時間がかかりそうです。
なので、ストーリーを小さく切っておくことで、変化に対応しやすくなると言えそうです。
ストーリーを出す時点での考慮漏れが減る
前提として、ストーリーを出す時点で考慮漏れは0にはできないと思います。やってみて見えることというのはたくさんあると思いますし、考慮漏れを0にすることは本質ではないかなと個人的には思います。
ただ、考慮漏れを減らすことは可能ですし、その努力は必要なことだと思います。
そのためには、ストーリーを小さくする必要があります。ストーリーを小さくすることで、マクロで捉えていた1つの機能開発も、細分化されることで色々な想定ができるようになり、その結果、必要なコミュニケーションがとられることで、事前に防げる考慮漏れを減らすことが可能になります。
ユーザーストーリーを大きくする
上記の通り、ストーリーは小さい方が良いと一般的にはされていますし、そこに対して異論はないです。一方で、ストーリーを細かくした上で、敢えてストーリーをまとめる・大きくする選択をとるというのは個人的にありだと思います。
前提として、ストーリーをまとめることよりも、ストーリーを分解することの方が圧倒的に難しいです。 なので、最初から大きいものを許容するのではなく、小さくした上でまとめられないか検討するという順序が大事だと思います。
その前提に立った上で、ストーリーを大きくする・まとめるということについてお話ししていきます。
ユーザーストーリーをまとめていいと考えてるものたちは以下の通りです。
- データとしての関連性があり、ストーリーを分けてしまうと単独では価値がなくなってしまうもの
- 明らかにまとめて開発した方が効率が良いものたち
データとしての関連性があり、ストーリーを分けてしまうと単独では価値がなくなってしまうもの
例えば、弊社ではデータを外部のサプライヤーから取り込むなどの実装をすることがあります。そういった場合に、1項目ずつ別のストーリーにし、1つずつ着手していくといったことが多いのですが、データの紐付き的に明らかに関連性のあるもの、(例えば、株価とその時刻、調達前評価額と調達後評価額など)については一緒に取り込むようなことをします。
例にあげてる、前者の「株価とその時刻」については、株価はいつ時点での株価なのかわからないとデータとしての扱いに困るし使いようがないですし、後者の「調達前評価額と調達後評価額」についてはスタートアップの資金調達でよく出てくるデータセットなのですが、片方だけ格納されていても困るといったことはデータの性質上わかります。
なので、ドメインを理解した上で、データの性質上、一緒にやった方が良いと意識的に判断することは良いことだと思います
明らかにまとめて開発した方が効率が良いものたち
ドッグフーディングなどを経て、出てきた軽微なバグ修正などはその代表例です。
ドッグフーディングを経て、リリースクライテリア的にここまでやらないとダメというストーリーが出てくることがあると思います。そういったものについては、軽微なものであればまとめてしまう、というのは良いと思います。
また、APIの実装などで1項目ずつ開発する場合のデプロイや開発のコストを、1つのストーリーでまとめた場合のコストとで天秤にかけた際に、明らかにまとめて開発した方が効率が良い場合(かつ、その開発が着手することが決まってる前提)であれば、まとめて実装してしまうのはありだと思っています。
まとめないという選択肢
基本的にはケースバイケースなので、本当にまとめて良いのか?と考えることが重要だと思います。
ただ、あくまでも まとめても良い なので、まとめることを強制してる訳ではないです。前提としては、やはりストーリーは小さく保つことが理想だと思います。
ユーザーストーリーを小さくするためにできること
最後にストーリーを小さくするために、意識していることをお伝えしておきます。
- ストーリーが大きいと判断する基準を明確にしておく
- まずは、とにかく小さくする
- ユーザーストーリーとして適切に小さくする
ストーリーが大きいと判断する基準を明確にしておく
僕たちのチームでは見積りにフィボナッチ数を使っています。その数字のうち、5のストーリーが出てきたときにチームでは小さくしようという会話をします。明確にチームで合意をとっておくと、小さくしようという会話が生まれやすくなるので、意識しておくと良いと思います。
まずは、とにかく小さくする
小さくするときに、最初はやりすぎかなというくらいに小さくすることをお勧めします。(先ほども言いましたが、小さくしたものを大きくするのは簡単なので。)
例えば、以下のページをつくるときを例にしてみると、
- ユーザーは空のページを見ることができる
- ユーザーはスタートアップヘッドラインの文言をみることができる
- ユーザーはスタートアップヘッドラインの空セクションをみることができる
- ユーザーは記事をX件見ることができる
- ユーザーは記事の画像を見ることができる
といった具合に、コンポーネントの内部の要素ごとにストーリーを切っています。
初めてこの粒度でストーリーを出した時は正直驚きましたが、この粒度でやることで見積りの時に相対判断しやすく、見積りにかかる時間をかなり減らすことができると感じました。
ユーザーストーリーとして適切に小さくする
最後に、ストーリーを小さくする際に注意してることがあります。それはユーザーストーリーという形を守ることです。あくまでも、小さくすることが目的ではなく、できるだけ細かくユーザーに届けることが目的なので、ユーザーストーリーでなくなってしまうと本末転倒です。
なので、データの取り込み系と取得・表示系を分けるときにも、例えば「ユーザーは固定のデータを見ることができる」「ユーザーはリアルタイムに更新のあるデータを見ることができる」といったように、届ける価値がわかるような形で小さくすると良いです。
まとめ
ユーザーストーリーを小さくすることの重要性についてまとめてみましたが、実際にやってみると難しさを実感すると思いますし、すぐには効果を感じられないと思います。ただ、継続していくことでストーリーを小さくしていて良かったなと感じる場面に遭遇できると思うので、興味を持たれた方は実践してみていただければと思います!
おわりに
ユーザベースではエンジニアを募集しています。
アジャイル開発をやっていて話をしてみたいと思ってくださった方、アジャイル開発はやってないけど興味を持ってくださった方など、ぜひ一度お話できればと思っております!