この記事は Retty Part1 Advent Calendar 2021 の14日目の記事です。
RettyでtoB（飲食店さん）向け開発のエンジニアをしている今井です！ まだギリギリRetty一年生です。
今回は最近の考え事トレンドであるスプリントレビューとデリバリーについて放出していきたいと思います。
ちなみに「考え事トレンド」という表現は最近個人的に気に入っていて、「モヤモヤ」とか「気になっていること」に近いです。
「モヤモヤ」っていうほど課題感は感じていなくて、「気になっていること」よりかは深めに考える事を楽しんでるので「考え事トレンド」です。
スプリントレビューで感じていたモヤモヤ
「いやモヤモヤかいっ」て思ったかもしれないですけど、元々はモヤモヤでした。
RettyではLeSSを導入していて、私のいるチームもその中に入っています。 ほとんどのチームがtoC向け開発をメインに行っていますが、私たちはtoBの開発がメインということもあり、ドメイン知識が違っていたり、手がける機能がほとんど干渉し合わないものだったりします。
そのため、スプリントレビューに開発物を持ち込んでも、開発物に関する前提知識が揃っていないために濃いフィードバックが思うように得られないことが多くなっていました。
その課題を解決するため、関係深いステークホルダをスプリントレビューに招く動きが生まれましたが、スプリントでやったことの共有がメインになっていて、以降のスプリントへ反映していくような動きにはなりませんでした。
デリバリーが少なくなってしまうモヤモヤ
こちらも元々モヤモヤしていたことです。
私がいるチームの開発では、飲食店さんのためのフォロー体制を維持できるよう、機能によってはリリース前に関係者への周知を行ったり、ある程度まとまった単位でのリリースを計画したりします。
作ったものがすぐに使われていくわけではないので、「リリース予定日に向けて計画していた全ての実装を終わらせる」という意識で動いていました。
開発の残作業だけ見れば進捗はしているし、スプリントの形をとっているものの、目に見えて動くものとしては何も変化がないスプリントが続くこともしばしば。例えば、「バックエンドの実装は終わりました！」みたいな感じですね。
結果としてデリバリーの頻度は下がっていましたが、ある程度完成度を高めてからでないと出せない制約があるのも事実で、解決策を見出すことができず。そんな状態なので、作ったものをどんどん出して次の開発に反映させるというサイクルがうまく回せないことにモヤモヤが募っていました。
モヤモヤの正体
スクラムで開発をする以上、どうしてもフィードバックと反映のサイクルを回していきたかったので、1on1でマネージャーに相談してみました。
そこでもらったコメントがこちら。
エンドユーザーに出さないとしても、スプリントレビューで毎回「見せられるものはありません！でも順調です！」って言ってたらあのチームは何をやってるの？ってなるよね。
そしてそのコメントと共に見せられたツイートがこちら。
あとはあれだな、管理がどうとかベロシティがどうとか言ってないで、スプリントレビュー行けっていうのと、スクラムチームは本筋に関係ない茶々入れを受けないためにも、インクリメントを全力で作ろうな。
— Ryutaro YOSHIBA (@ryuzee) 2021年10月28日
「今回はインクリメントありませーん」
「今回もインクリメントありませーん」
では信用されん
ナルホド。
確かにこれまで個人的に思っていたのは「フィードバックで回していけないならスプリントレビューに持っていっても意味ないじゃん」ということばかりで、もう一つ大切なことを忘れていました。
それは、自分たちがやっていることの透明性！
モヤモヤの原因はてっきり「フィードバックを得られないこと」と思い込んでたけど、実は自分たちがインクリメントを作れていないことで透明性を低下させていたせいかも！
確かに、動く状態を作っていくのって自分たち的にも着実に出来上がってる感があるんですよね。
結局それでもフィードバック得られない問題が解決したわけではないですが、
「デリバリー」にフォーカスしてばかりではなくスプリントの中で「インクリメントを作れているか」を考える
スクラムで開発する意味を「フィードバックを受けてプロダクトを良くしていく」だけでなく「自分たちがやっていることの透明性を上げる」と分けて考える
この気づきは自分にとってかなり大きくて、視界が少しクリアになった気がしました。
その後の考え事
モヤモヤって、何やったらいいかわからない感があるんですよね。なので「考え事」であることには変わりないんですけど、ただ悩んでるだけの時間が長い気がします。
私のモヤモヤは、視界がクリアになってきたことで「考え事トレンド」に昇華しました。これから何をしていくのがいいかなーという前向きな感じで楽しいです。
いろんな制約ですぐにユーザにデリバリーができないことって、そりゃできた方が良いんでしょうけど、まぁ仕方なくあるんだろうと思います。それはそれとして、デリバリーができないからといってせっかくのスプリントというイベントを蔑ろにはしたくないです。
なのでこれから意識していきたいのは、
デリバリーの単位に関わらず毎スプリントでインクリメントを出していくこと
です！
スプリント内でリリース（もしくは完成系）まで持っていけないボリュームの開発だと、スプリントゴールが疎かになってしまうように思います。3スプリントかかる開発なら、3スプリント終わった時点で全部終わってればいいよね、となってしまっているような感じです。
でもせっかくリズムを作って自分たち（とプロダクト）の現在位置を確認しながら進められるなら、スプリントごとにちゃんと動くものを出して行って、目に見えてわかる状態で進んでることを示していきたいですよね。
実現しようとしていたことが100%できていなければ0%のままスプリントを終えて良い、わけではないよな、と思います。
動くソフトウェアこそが進捗の最も重要な尺度です。
胸に刻んで生きていきます。
P.S.
そんなことを文字に起こしているうちに、スクラムマスター研修で学んだことを思い出してきました。
Definition of Done（Doneの定義）≒技術品質
Doneの定義を満たしたものがPotentially Shippable Increment（出荷可能な製品単位）
Acceptance Criteria（受け入れ基準）≒製品品質
受け入れ基準が満たせなかったとしても、Doneの定義を満たすことでインクリメントを作ることはできるはずなんですよね。
当時もなんとなくわかった気になってナルホド〜とか言ってましたけど、ここにきてまた一つ理解が深まった気がします。
