こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。
10 月の終わりに、ひとつだったエンジニアリングチームを分割する形で 2 チームが生まれました。社内では骨 🦴 と稲 🌾 という愛称で呼ばれています。
ちなみに、骨 🦴 の由来はこちらです。
今週から新しいチームが始動するのですが、チーム名は「骨」になりました🦴 英語の "hone" は「磨きをかける」という意味があるので、骨太でしっかりしたシステムを作り磨きをかけるという願を懸けました✨ pic.twitter.com/Gvf2VBYk7d
— Manabu Sakai (@manabusakai) 2022年10月25日
前職でチームの立ち上げやスクラムを経験していたこともあり、CTO から骨 🦴 チームのスクラムマスターを任されました（専任ではなくエンジニアと兼任です）。
チームの立ち上げから 1 か月ほど経ったので、チーム分割する前と後でスクラムにどのような改善が見られたのか振り返ってみようと思います。
カミナシのエンジニアリング組織がどういう変遷を辿ってきたのかは『「憧れのマイクロサービスと愛すべきモノリスの話」にて LT してきました』に詳しくまとまっていますので、合わせてご覧いただけるとより理解しやすいと思います。
（チーム分割のタイミングで、それぞれのチームミッションやステークホルダーが変わっているので純粋な before / after の比較ではありません）
以前のスクラムの課題
どうやって改善していったのかを話す前に、まずは数か月前（9 月ごろ）のスクラムの課題を振り返ってみます。大きな課題は次の 2 つです。
- タスクの粒度が粗すぎて見積もりが信用できない
- 達成できないストーリーポイントを積んでしまう
ゴールに向かってまったく下がらないバーンダウンチャートを見れば、いかに難易度の高い状況であったかを伺い知ることができます。
課題をもう少し詳しく掘り下げます。
タスクの粒度が粗すぎて見積もりが信用できない
カミナシではストーリーポイントにフィボナッチ数列を採用しています。
ざっくり 1 日くらいかかるタスクは 5 pt に設定していますが（もっと詳細な定義はありますが本筋ではないので割愛）、以前はそれを大きく上回る 13 pt や 21 pt のタスクがスプリントバックログにいくつもありました。
それだけ大きな数字になると見積もりがブレるのは当たり前ですが、そのタスクを分割することもなく一人のエンジニアがタスクを進めていました。タスクが大きすぎるので周りからは進捗も見えず、チームメンバーがフォローに入ることも難しい状態でした。その結果、いつまで経ってもタスクが終わらないという悪循環に陥っていました。
達成できないストーリーポイントを積んでしまう
大きなストーリーポイントのタスクがスプリント中に完了しなかった場合、チームのベロシティが不明瞭になってしまいます。実際、レトロスペクティブの中で「この未完了のタスクはあと何ポイントで終わりそうですか？」といったやり取りが度々起きていました。
せっかく見積もりを行っているのに、見積もりが信用できず、チームの実力も測れていなかったのです。実力がわからないので、プロダクトオーナーからスケジュールを聞かれても誰も答えられないのです。
チームの実力を考慮せずに前のスプリントの持ち越しや優先度の高そうなタスクが次々に積まれるため、エンジニアリングチームにも「スプリントを完遂させよう」というマインドが希薄でした。その結果、一度もコミットメントを達成できずにいました。
立て直すために取り組んだ 5 つのこと
この記事を書いている時点で 4 回目のスプリントを回していますが、ブレはあるものの着実にスプリントゴールを達成できるようになってきました。
スプリントの期間を短くする
新しいチームで真っ先に変えたのがスプリントの期間です。もともとは 2 週間のスプリントでしたが、これまでの実績を踏まえると 2 週間のスプリントを精緻に計画して完遂できるイメージは持てませんでした。
また、もともと一緒に働いていたメンバーとはいえ、チームの立ち上げ時は一時的に混乱が生じるものです。そんな中でも、失敗から学んで素早くプロセスを修正するためには、2 週間は長すぎると判断して 1 週間に短縮することにしました。
スプリントの期間を短くするのに合わせて、デイリースクラムの進め方も見直しました。以前は個人のタスクも細かく共有していましたが、チームの成果を重視するためにボードを見ながら進めるように変えました。
タスクの粒度を細かく
課題に挙げたとおり、タスクの粒度が粗いものはスプリントバックログに載せてはいけません。スプリントを短縮したこともあり、これまでのような見積もりをしていては完遂できないことは火を見るよりも明らかでした。
そこでチームのルールとして、見積もり時点で 5 pt より大きいタスクは必ず細分化することにしました。タスクの粒度を細かくすることで解像度が上がり、スプリントの進捗が可視化できるようになります。
たとえば、「新機能開発の Design Doc を書く」というタスクを例に挙げてみましょう。以前であれば 13 pt や 21 pt を付けていましたが、人によって何をすれば良いのかブレていました。これでは成果物のクオリティも一定になりません。
今では次のような小さなタスクに分割し、やることの解像度を上げています。
- ○○について事前調査する
- 参考になる実装を調べる
- Design Doc を書く（だけ）
- チームでレビューして合意を取る
タスクの粒度を細かくすることで In Progress のレーンにいる時間が短くなり、ボード上で進捗が追いやすくなります。また、バーンダウンチャートも着実に下がっていくので、チームのモチベーションを維持するのにも一役買いました。
スプリントゴールを明確にする
以前はスプリントゴールがありませんでした。コミットメントを達成できないことに慣れすぎていたので、そのスプリントで達成したいことやチームがどこに向かって進んでいるのか明確ではなかったのです。
このような状況が続けば、誰しもが近視眼的になってしまいます。イソップ寓話の「3 人のレンガ職人」に例えると、レンガを積むのが目的になってしまって、歴史に残る偉大な大聖堂を造っているということを忘れてしまうのも無理はありません。
チームの目線を合わせ、チームで成果を出すためにも、スプリントプランニングで必ずスプリントゴールを明確に決めるようにしました。
チームでの助け合いを促す
カミナシのエンジニアリングチームは客観的に見ても心理的安全性が高く、困ったときは誰かに助けを求められるという安心感があります。一方で、これまではタスクの粒度が粗いためにフォローに入りづらく、個々人で成果を出すことに重きが置かれていたように感じます。
プロダクトが成長するに合わせて出てくる困難な課題を解くには、個人のスキルに依存し続けるのではなく、チームで助け合いながら成果を出す必要があります。
そこで助け合いを促すような声かけや行動を意識的に増やしました。具体的には、壁打ちして一緒に悩んだり、ペアプロ（ペアオペ）してチーム内でナレッジを共有する機会を作りました（スクラムマスターとして何かしたというよりは、最近入社した @szk3 さんがファーストペンギンになってくれました。感謝！）。
その甲斐あってか、直近のレトロスペクティブでは次のような声が挙がってきました。
- 調査系の時間の使い方が変わってきたかもしれない
- 一人で解消できない不具合は 2 〜 3 人で取り組むと解決できる場合もある、ということが分かった
- Slack の Huddle で脱線も含めて話すといろいろ学びがあった
協力していくためのオーバーヘッドは短期的には生産性を落としますが、中長期で見たときはとてつもない差となって現れます。斧を研ぐことの価値を軽視してはいけないのです。
小さな成功体験を積み重ねる
課題に挙げた悪循環を断ち切るために最も効果的だと感じたのは、チームとして小さな成功体験を積み重ねることでした。
- スプリントゴールを達成できた
- 前回よりもベロシティが上がった
- チームで分担して取り組んだ新しい機能が動いた
コミットメントを達成できない状態に慣れてしまっていたので、チームにとっては大きな一歩です。スクラムでよく言われる自己組織化されたチームを作るには、「チームで取り組めば達成できる」という自己効力感がなくては話が始まりません。
いかがでしたでしょうか？
スクラムを立て直すのにも銀の弾丸は存在せず、セオリーを忠実に実行するのが遠回りなようで近道でした。スクラムはあくまで手法なので、これまで以上にお客様へ価値を提供できるように改善していこうと思います。
最後に宣伝です 📣 カミナシでは絶賛採用中です！ 一緒に強いチームを作っていく仲間を募集しています！
