Sreake事業部アプリケーション開発チームの安本です。 現在、スクラムでアプリケーション開発の概念検証（Proof of Concept; PoC）を進めています。
本記事では、スクラム開発を行っているチーム向けに、私たちのチームが遭遇したプロダクトバックログリファインメントの課題について紹介します。
私たちは敏腕スクラムマスター（SM）、開発者との対話に真摯なプロダクトオーナー（PO）、価値あるものを作りあげることに拘りぬく開発者と、メンバーに恵まれているおかげで、なんとかインクリメントの積み上げに成功しています。
一方でプロダクトバックログリファインメントがなかなか進まず、迷いの多い作業の連続でした。 アジャイルコーチで知られる吉羽龍太郎さん*1によると、プロダクトバックログは「スクラムチームが行う作業の唯一の情報源」なので、当然の帰結だったと思います（プロダクトバックログ Deep Dive）。
困難の最たる原因はプロダクトバックログアイテムのタイトルにあったと考えています。 私たちはタイトルを「 <役割>として<機能や性能>がしたい（できる）。それは<ビジネス価値>のためだ。」という構文で記述していました。 いわゆるユーザーストーリーですが、不慣れな我々は構文をなぞることに精一杯でした。 すると、読んでもユーザーが何を求めていて、そのためにどんな機能が欲しいのか分からないタイトルが並びました。 これでは、プロダクトバックログアイテムの詳細化や受け入れ条件の設定、優先順位の整理が進みません。 結果として様々な困難を引き起こしたのです。
そこで今回は、実際にどんな困難が起きたのか、困難の中でどうインクリメントを積んだのか、困難をどう分析し、どう解決しようとしているのかについて、振り返ろうと思います。
プロダクトバックログの未整理に起因する困難との戦い
スクラムを開始してから最初の数スプリントで、私たちは多くの困難に直面しました。
- プロダクトバックログリファインメント
- 議論が紛糾する
- 多くを論じた割りに翌週には何のことか分からなくなり、議論が振り出しに戻る
- 設定した受け入れ条件の根拠が分からなくなってリファインメントがやり直しになる
- スプリントプランニング
- 最上位のユーザーストーリーの解釈から始まりプロダクトバックログリファインメントもどきになる
- タイムボックスにおさまらず、スプリントプランニングが完了しないままスプリントが始まる
- スプリント
- 開発やスプリントレビュー資料の中身がユーザーの求めるものか確証を持てず試行錯誤が重い
プロダクトバックログは「スクラムチームが行う作業の唯一の情報源」という考えが浸透する前から、誰もがプロダクトバックログに問題があると理解し、スプリントレトロスペクティブでも度々問題視しました。 しかし、問題の根が、どこにあるかまで理解が及んでいませんでした。 しばらくして、「ユーザーストーリーを見るたびになんのことか分からなくなるんですよね」とPOが発言して、ようやくユーザーストーリーが注目されたのです。 POのものであるはずのユーザーストーリーがPOの理解の及ばないものになっていることが問題と気付けたのです。
思い起こせば、毎回ユーザーストーリーの議論を重ねていました。 吉羽龍太郎さんが伸べている通り「ユーザーストーリーはチームとステークホルダー間の議論を活性化させるための道具」になっていた点ではよかったのかもしれません（より良いユーザーストーリーを書くための10個のヒント）。 一方で「毎回すごーく細かく議論しないといけないユーザーストーリーっていけてないだろ(それ以前になんか間違ってる) 」という指摘ももっともで、耳の痛いことでした（https://x.com/ryuzee/status/806277846129844224）。
それでもインクリメントを残せた背景には、諦めずに議論し続けたこと、スプリントゴールをできるだけ小さく設定したこと、スプリント中でも随時、POと会話して疑問を解消する・方向性を確認してきたことが挙げられます。 これを成せた背景には、SMがそっと道を示してくれたこと、POがゆっくりとでも小さくとも前進することに価値があると許容してくれたこと、開発者が許容に甘えず全力を注いだことにあると思います。 特にPOからすれば1スプリントあたりのインクリメントを最大化して欲しい、スプリントに入ったのだから開発者でよしなにやって欲しいという考えが湧いてもおかしくないと思います。 そんな中で寛容な精神を持ち続けてくれたことに感謝しています。
感謝と言えば、チーム内ではSM・PO・開発者が互いの行動や態度に感謝していたことも印象的です。 製品開発だけでなく、互いに目を向け合い、チームビルドできていたことも勝因かもしれません。
仲間から戦友という意識になっていく中で、私がスクラムに寄せていた期待を果たせたこともあり、一種の通過儀礼だったのかなとも思います。
- ユーザーにとっての価値が何か理解するために、POとの会話機会を増やす
- 要望が多岐に渡る中、Minimal Viable Product（MVP）を定めて小さくとも価値の高いところから開発を進める
これらは別にスクラムでなくとも達成できることですが、フレームワークは矯正ギプス的な役割を果たしてくれます。
未整理なプロダクトバックログは困難をもたらしたものの、悪ではなく、困難との戦いは我々が前進するきっかけになりました。
なぜプロダクトバックログを整理できていなかったのか
困難が悪ではないとは言え、同じ困難といつまでも戦っているようでは進歩がありません。 なぜプロダクトバックログの整理ができていなかったのか、掘り下げます。
といっても、「ユーザーストーリーを見るたびになんのことか分からなくなるんですよね」というPOの発言にすべてが集約されます。 ユーザーストーリーをプロダクトバックログアイテムのタイトルに使っていたので、ユーザーストーリーこそが議論の起点でした。 ユーザーストーリーがイマイチでは、受け入れ条件の設定も優先順位の判断もあらゆる議論がイマイチになるのです。
ではなぜ、なぜPOのものであるはずのプロダクトバックログの、その顔とも言えるユーザーストーリーがPOにわかりにくいものになったのでしょうか。
我々はスプリント1に向けてPOと共にユーザーストーリーマッピングを描き、プロダクトバックログの整備を進めました。 スプリント開始以降もプロダクトバックログリファインメントを重ねました。 それでも「POの」ユーザーストーリーとしてまとめられなかった最たる理由は、構文の<ビジネス価値>の部分が開発者目線になっていたことにあります。
「 <役割>として<機能や性能>がしたい（できる）。それは<ビジネス価値>のためだ。」
スクラム導入前は、開発者側でユーザーの要求を吸い上げ、まとめ、機能開発を進めていました。 当時の計画では<機能や性能>の1つずつがどんな<ビジネス価値>を目的としているかまで検討されていませんでした。 このためユーザーストーリーの作成にあたっては<ビジネス価値>がPOの考えを推測して書かれたものになっていました。 推測が間違っていないかPOに確認をとり合意を得ていたものの、実際にはPOの考えになんとなく沿いつつ、ぴったりとは当てはまらないユーザーストーリーを生んでしまいました。
開発者主導のユーザーストーリー作成は、視点の偏りも伴い、<機能や性能>と<ビジネス価値>の混同も発生しました。 これはこれで、文章としては間違ってないし、POにとっても必要そうに見えるが、POの意図が反映されていないユーザーストーリーを生んでしまいました。
こうしたユーザーストーリーに、なんとなく違和感を抱いたことは1度や2度ではありません。 しかし、スクラムはタイムボックスが大事という意識から、場当たり的に完了を優先して、違和感を飲み込んでしまった節もあると思います。 形式的なユーザーストーリーを生んでしまいました。
こうして困難は始まりました。
加えて、POも開発者もユーザーストーリーに馴染みがなかったため、ユーザーストーリーって難しいけど慣れの問題かなと思っていた節があります。 このため、慣れの問題ではないと気付くまで、イマイチなユーザーストーリーを作り続け、プロダクトバックログの整理もその先の作業も難しいものにしました。
どうやってユーザーストーリーをまとめるか
吉羽龍太郎さんの資料を読み漁って得た私見ですが、まとまっているユーザーストーリーとは、所有者がPOであると確信でき、さらにチーム全体で共通認識を持てるものだと考えます。 これを達成する上で効果的だったなと感じる施策は以下の3つです。
- ユーザーストーリーの構成要素の中でもビジネス価値から考える
- ユーザーストーリーや議論のメモ、議論のファシリテーションをローテーションする
- プロダクトバックログリファインメントを追加開催する
最初、私はユーザーストーリーが分かりにくいなら、分かりやすいくなるまで細かく書けばいいのではと考えました。 しかし、ユーザーストーリーが簡潔なのは意図的な制約で、本当の課題、規模感、必然性に関する議論を誘発するのが重要とあります（プロダクトバックログDeep Dive p.33, 36）。
- ＊ フォーマット
- ＊ <役割>として
- ＊ <機能や性能>がしたい（できる）。
- ＊ <ビジネス価値>のためだ。
- ＊ 要求を自然言語で簡潔に記したもの
- ＊ 意図的な制約（たくさん書けない）
ユーザーストーリーが発祥したエクストリームプログラミングのルールにも、詳細はユーザーストーリーの合意をしてから書くものだと記されています。
User stories are a few sentences in simple language that outline the desired outcome. They don’t go into detail. Requirements are added later, once agreed upon by the team.
http://www.extremeprogramming.org/rules/userstories.html
なんならユーザーストーリーにこだわることは本質ではないという指摘すらあります。
ユーザーストーリーがだいじなんじゃなくて、POと開発チームが共通理解を作るのがだいじなんじゃないですかね
https://x.com/ryuzee/status/887607421773922305
しかし、ユーザーストーリーをやめたところで、無軌道に書くには経験が足りないし、他のフォーマットが問題解決の一手になるとは考えられませんでした。
問題の原因を振り返ってみましょう。 これまではスクラム開始前の計画にあった機能に合わせてビジネス価値を記述していたのです。 しかし、機能はビジネス価値を生む数ある手段の1つに過ぎません。 ビジネス価値から書き始めるべきだったのです。
我々は、いきなりユーザーストーリーを書き下すことをやめました。 まず、誰にどんなビジネス価値を提供したいのかを考え、ビジネス価値の部分を短かく要約する。 次に機能や性能についていくつも箇条書きしてから選ぶ。 そこまでできてから以下の構文にあてはめることにしました。
「 <役割>として<機能や性能>がしたい（できる）。それは<ビジネス価値>のためだ。」
多くを論じた割りに翌週には何を話したか分からなくなる問題もあったので、ユーザーストーリーを作成するまでの過程も書き残すようにしました。
また、スクラムイベントのファシリテーションや議事録作成をローテーションすることにしました。 これはスクラムのプラクティスとして、自己組織化を目指しての取り組みでした。 しかし、結果として、ユーザーストーリーの品質向上にかなり効果的だったと思います。 SMはある種、客観的で、議論のとりまとめをしやすい立場にあります。 一方で開発者は、自分たちの議論が次のアクションに繋がるため、納得のいく内容でなければファシリも議事録作成も進めにくいものになります。 逆に言えば、納得いくまで議論することを後押しします。 更にローテーションすることで、誰か一人の納得に偏らず、チーム全体の納得を加速しました。 現在は開発者のみでローテーションしていますが、POもローテーションに加わってもらうといいかなと考えています。
そして切り札は、プロダクトバックログリファインメントの追加開催です。 スクラムといえばタイムボックスという意識があったので、追加開催していいものなのかと疑問だったのですが、プロダクトバックログリファインメントの完了条件は、次のスプリントを開始可能と判断できることだと考えれば、必要に応じて追加開催することは理に適っているとSMに教えてもらいました。 開発に使える時間とのトレードオフになるので無制限に使える手札ではありませんが、タイムボックスに縛られて形式的なユーザーストーリーを作成してしまうよりも、ずっと健全だと思います。
これらの取り組みにより、これまでよりもずっと軌道に乗っている感触を得ています。 我々の作業が価値に繋がっていると確信を持てるようになりました。
おわりに
プロダクトバックログをスクラムチームが行う作業の唯一の情報源として成立させるためには、POの追求するビジネス価値に基づいてプロダクトバックログアイテムを作成することが大事です。 その起点として、本記事はユーザーストーリーにこだわりました。
よいユーザーストーリーの作成に効果的だった施策を3つ挙げましたが、これですべてが解決とはなりません。 よくなったなと思ったら、まだまだ価値の議論が甘かったとスプリントプランニングのタイミングで認識するケースも存在しています。 それでも、「スクラムチームが行う作業の唯一の情報源」すら整ってない中で戦ってこれた私たちなら、残る困難もまだ見ぬ困難も糧にしていけると信じています！
軌道に乗るところまで歩みを止めなかった仲間たちと、私たちを支えてくれる沢山の資料を提供していただいた吉羽龍太郎さんに深く感謝申し上げます。
脚注
*1: 吉羽龍太郎さんは株式会社アトラクタ Founder兼CTO/アジャイルコーチ。「エンジニアリングマネージャーのしごと」や「Tidy First? ―チームが必要とするマネージャーになる方法」などの翻訳でも知られる。