BASEプロダクトチームブログ

ネットショップ作成サービス「BASE ( https://thebase.in )」、ショッピングアプリ「BASE ( https://thebase.in/sp )」のプロダクトチームによるブログです。

スクラム開発で数スプリント先の未来の落とし穴を回避する

はじめに

はじめまして。エンジニアの近藤(@kon_engineer)と申します。本記事は BASE アドベントカレンダー 2022 の6日目の記事です。

本記事では、私が苦い経験から学んだ、スクラム開発で未来の落とし穴を回避する考え方について書きたいと思います。具体的には、ユーザーストーリーの優先度を決めるとき、ユーザーにとってどれだけ価値を提供するかという視点だけでなく、プロジェクトとして何がリスクで、それを回避するために何からやっていくのか、しっかりバランスを考えるべきだった、という経験談を記載します。また、本記事で事例として記載するスクラム開発は、1スプリントごとにリリースする形ではなく、スプリントをある程度回して、大きな機能が出来上がったら都度リリースしていたスクラム開発の形式になります。

ユーザーストーリーについて

ユーザーストーリーは、システムがユーザーに届ける価値を表現するものです。例えば、ショップオーナーは、管理画面で任意の配送可能日時を指定して、ショップに反映することができる、といった形で、登場人物が何をできるのか明確にするものであり、スクラムチームがスプリントで達成するべき重要なものと思います。

ユーザーストーリーの優先度について

ユーザーストーリーの優先度を決めるためには、いくつもの考え方があると思います。私たちのチームでは、ユーザーにとって最も重要で、このストーリーがなければ後のストーリーは成り立たないものの優先度を高くしていました。この判断基準自体は間違っていなかったと思います。ただ、優先度としては後半に取り組むストーリーで、一度もチームメンバーが触ったことのない領域の開発がありました。その時は、優先度も高くないし、それほど難しい機能でもないから何とかなるだろうと思い、あまり注視していませんでした。これは良くなかったです。

リリース手前のスプリントで初めて大変さに気づく

リリースも近くなったスプリントで、今まで経験がないBASEの領域の開発を行いました。その結果、修正量は少なかったとしても、その領域を深くまで理解していなければ影響範囲が読めず、開発が自分達にとって難しいことがこのタイミングで分かりました。結局、当初の見積りより倍以上の時間がかかってしまい、チームメンバーに助けられてなんとかリリースに間に合った、というギリギリの開発になってしまいました。開発を進めていくと実は大変だったというのはあるあるですが、元々知見がないのは分かっていたので、もう少しやりようがあったと思います。

どうすればよかったのか

懸念があるユーザーストーリーの優先度は上げる

今回の事例では、機能としての優先度が高くないストーリーであったため、詳しくない領域の開発を後ろに回してしまいました。しかし、プロジェクトとして事前に不確かな部分、不安な部分を早めに潰して安定した開発をすることは、ユーザーにとって優先度の高い機能を開発することよりも、時として重要であると考えます。なぜなら、懸念を後回しにすることで、プロジェクトの失敗確率が上がったり、全体の工数が伸びてしまうのであれば、長い目で見るとユーザーにとっても不利益であるためです。もちろん、ただ分からないからという理由で、闇雲に優先度を上げることはよくありませんが、プロジェクトの懸念が払拭されて成功率が高まるのであれば、今やった方が良いと思ったものは、優先度を上げる検討をした方が良いと思います。

懸念があるユーザーストーリーとはどういうものかについて、もう少し補足したいと思います。私が考えるものは、以下の図でユーザーストーリーBにあたるものです。

ユーザーストーリーのマトリックス図
ユーザーストーリーの重要度はCの方が上であるが、ユーザーストーリーBは例えば使ったことがない技術を使用する必要があるとか、外部サービスと連携しなければならなくて、その調査が必要であるといったことで、考えなければいけない課題が多く存在するような状態です。この場合は、ユーザーストーリーCよりも先んじてBをやった方が良い場合があると考えます。

調査タスクを切る

ユーザーにとって重要なストーリーから届けたい、しかし技術的に懸念があるストーリーなどは事前に備えておきたい場合に、当該ストーリーの調査タスクだけ切って、先に問題がないか確認することも有効だと思います。一度もチームメンバーが開発したことのない領域や技術であったり、技術的に実現できるのか分からない課題がある場合、後々何かしら問題が起きる場合があります。特に手戻りが発生して、すでに開発もしくはリリースしたストーリーに影響する事態は避けたいので、今取り組んでいる優先度の高いストーリーを安心して進めるために、事前調査して懸念を払拭しておきます。

ユーザーストーリーの優先度は常に見直す

ユーザーストーリーの優先度は、最初に決めたら動かさないものではなく、状況によって柔軟に変更すべきものだと思います。今回の事例では、一度決めた優先度でそのまま開発を進めてしまっていました。ユーザーストーリーの優先度を見直す機会を設けていれば、そういえばこのユーザーストーリーは懸念はないかなど、改めて議論する場が用意されるので、もう少し早めに開発する上で懸念があることに気づけたかもしれません。

おわりに

本記事では、自分の経験を通じて、スクラム開発におけるユーザーストーリーの優先度決めについて記載いたしました。読んでいただいた方の助けに少しでもなれば幸いです。

明日はsatoshi_takemotoさんとtoshさんの記事が公開予定です、ぜひご覧ください。