システム改善や技術負債返済の進め方 〜ある会計SaaSの場合〜
はじめに
この記事は、Money Forward Kansai Advent Calendar 2024の12月16日の記事です。
こんにちは。マネーフォワードの大阪拠点で、会計Plusの開発チームでエンジニアをしている堺です。
今年も年に1度の、記事を書く日がやってきました。でも、今年はなんと2記事目なのです。成長です！
今回は、会計Plusで取り組んでいる、システム改善や技術負債返済（以降、まとめてジョブストーリーと記載(*1)）の取り組みについて紹介したいと思います。
前提
会計Plusでは、ドメインやミッションに応じた複数のチームがあり、LeSS（複数チーム向けのスクラム拡張フレームワーク）をベースとしたプロセスで開発を進めています。
通常のスクラムでは、1つのプロダクトに対し1つのプロダクトバックログが存在し、それを1つのチームで開発していきます。
これに対して、LeSSでは、同じように1つのプロダクトに対し1つのプロダクトバックログが存在し、各チームが、どのプロダクトバックログアイテムでも対応できるように進めていきます。
会計Plusでも、昔はLeSSの定義に沿って開発を進めていましたが、前述のようにドメインやミッション、さらにチームによっては技術スタックまでもが変わってきた結果、プロダクトバックログは1つであるものの、各チームがそれぞれでエピックを進める（特定のチームが対応するプロダクトバックログアイテムが多くなる）ようになり、リファインメントもプランニングも別々で行う状態になっています。
（以降、スクラムにおける基本的な用語は説明なしで進めますが、意味を知らなくても雰囲気で読めると思います、たぶん。）
課題
元々傾向はあったのですが、チームによってプロダクトバックログが分かれることでより顕在化した問題に「ジョブストーリーの対応がされにくい状態になった」ということがあります。
ヒアリングや問題の深堀りを通して、そこには、大きく分けて、2つの課題があると考えました。
1. ジョブストーリーをどう進めていくか、人によって認識が違う
例えば「同じプロダクト内の問題なので、どのチームが対応してもいい」という方もいれば、「明確にまずいものはやるけど、それ以外は余裕があるとき」「余裕があるなら、自チームのミッションに沿ったものをやりたい」など、考え方が人によって様々でした。
さらに、プロダクトバックログが分かれ、プランニングやリファインメントも別々に実施となれば、ジョブストーリーに関する相談の機会が減り、結果的にスムーズに進まなくなるのは、当然の結果だったのかもしれません。
2. 運用プロセスを決めても、なぁなぁになる
実は、これまでも、ジョブストーリー対応の施策はいくつかやってきました。
しかし、取り組み自体が廃れたり、ジョブストーリーをスプリントに組み込めなかったりと、うまくワークさせることができていませんでした。
また、人数が増えたことにより、（スクラムが標榜する自己組織化とはかけ離れますが）自分ごととして捉える、というのが難しい状況にもなっていたのかな、と、今にして思います。
解決策
以下の3つを解決策として実施しました
1. 全体で扱うもの、チーム毎に扱うものの指針をざっくり定める
一口にシステム改善や技術負債と言っても、多岐に渡ります。そこで全体で扱うもの、そのチームの裁量で扱うものを、ざっくりですが定めました。
全体で扱う:
対応しないとプロダクトの存続に関わるもの
アラートやバグにつながるもの
そのチームの裁量で扱う:
該当チームがメインで扱う領域のリファクタリング、ユーザーや開発体験向上につながるもの
また、あくまで指針なので、リファクタリングや体験向上につながるもので、特別に全体で議論したいものについては、全体で扱うことを制限しません。（全体で共通の技術などもあるので）
2. リファインメントからプランニングを経て、スプリントに組み込まれるまでの運用プロセスを改めて検討し、関係各所の了承を得る
確実に、毎スプリントで、何かしらジョブストーリーが対応されるよう、プロセスを定めました。
週に1度、リファインメントを行う。それには、各チームから1名以上集まる
各チームのプランニングの前に、全チームで、どのチームがどのジョブストーリーを対応するか決める時間を作る
特段の事情がない限り、各チーム1スプリントで1つ以上ジョブストーリーに取り組む
本来のスクラムであれば、プロダクトバックログに組み込み、順番を決めて対応すべきところですが、直接ユーザーに価値を届けるプロダクトバックログアイテムとの比較の難しさから後回しになっていく経験から、こういった形に落ち着きました。
3. プロセスが回るように責任を持つ人を2人置く
これも、自己組織化から外れているのですが、プロセスが廃れないよう責任を持つ人をおきました。
これは、スクラムにおけるスクラムマスターみたいな役割なんだと割り切っています。そういう意味では、そのうち、この人がいなくなっても回るように考えていく必要があるのかもしれません。
ちなみに2人置いたのは、どちらかがいなくても大丈夫なよう、トラックナンバーを意識したものになります。とはいえ、人数が増えると意思決定が難しくなっていくので、必要以上に増やさず、2人という人数にしました。
成果
以上の解決策をチーム内で共有・同意を得て、2024年4月から実際に運用してみました。
指標としては、本来であれば、生産性やユーザー価値というところで測るべきと思いますが、今回は「ジョブストーリーの対応がされにくい状態になった」という問題の対応を第一に考えているので、月毎のジョブストーリーの解決数と、残っているジョブストーリー数でで見てみることにします。
では、その成果を、見てみましょう。
$${\LARGEジョブストーリー数、増加しました！🤣}$$
これは、単純にプロセスの失敗ではなく、以下のような理由があると思っています。
（詳細は伏せますが）夏頃に、とある案件をジョブストーリーより優先する、という決断をした
フロントエンドのリアーキテクチャ(*2)が進み、一旦実装したところでも、もう少しこうしたい、というジョブストーリーが出てきた
（具体的な数は伏せますが）この1年で、会計Plusに関わる人数が増え、単純に問題に気づき、起票されるペースが上がった
そして、状況が安定してきたのか、この2ヶ月くらいは、残数が下降する傾向にあります。（あるはず！）(*3)
まとめ
ということで、もう少し状況を見て、必要に応じてさらなる改善を検討したいと思います。
雑多な文章でしたが、同じようなことに困っている誰かの助けになることを願って…
*1 会計Plusでは、こういった性質のタスクをジョブストーリーと呼んでいます。ジョブストーリーについては、以下の記事が参考になります。が、会計Plusでは、元の意図から多少ズレて、システム目線なタスクを表すものになっています。
*2 フロントエンドのリアーキテクチャについては、今年、弊社大倉が登壇しています。動画・スライドが公開されているので、ぜひ。
*3 蛇足ですが、2024年より2023年の方がよっぽどジョブストーリー対応できているように見えますが、当時のチーム状況が今ほど複雑でなかったことに加え、システム改善Dayという取り組みを四半期に一度やっていたことも大きいです（諸事情により最近は未開催です…）