ヤフーにはたくさんの社内プラットフォームがあります。
私もそのうちの1つを担当していましたが、そのプロダクトはある別のプロダクトの後継となることが決まっていました。
後継であるということは、旧プロダクトで求められていたことを新プロダクトでも求められますし、逆に旧プロダクトでの課題が新プロダクトで解決されていることも望まれています。この期待に応えられるプロダクト開発をおこなうため、新旧プロダクトを担当していた2つのチームは、戦略として1つのLeSSチームで2つのプロダクトを担当することを選択しました。
新プロダクトを作りはじめたチームと、旧プロダクトを運用しているチームは、それぞれにスクラムをおこなっていましたが、その雰囲気は対照的でした。
- 一方は、かろうじてスクラムの枠組みには沿っているが、完成の定義なども決める前段階の緩くインクリメンタルな開発を行おうとするチーム
- もう一方は、3チームによる LeSS をおこない、プロダクトを安定運用するための様々なルールに沿って開発運用を行うチーム
2つの異なるスクラムチームが一つになることは、簡単ではありませんでした。
特にそれぞれが対照的な雰囲気のチームだったことや、それぞれが今までと変わらずなプロダクト運用も求められる中でのチームの合体だったため、課題も多かったからです。
いざ一緒になることが決まり、プロダクトオーナーになることが決まった私は、旧プロダクトの LeSS を見て複数の違和感を持ちました。
- ルールに縛られた軍隊チックなチーム体制
- プロダクトについての議論がされ、ルールばかりが追加される振り返り
- 誰に何を届けたいのかがわからないスプリントレビュー
- プロダクトオーナー以外、誰も優先順を認識していないバックログ
- 判断がプロダクトオーナーに一任されるコミュニケーション
一方で新プロダクトのチームには別の課題がありました。
- 全員がスクラム経験者ではあるものの、人数が増えて LeSS をおこなうことへの漠然とした抵抗感
- 完成の定義などの決めごとがほとんどなく、チームの変化に弱いプロダクト品質
- チームの人数が少ないことで担保されていた共通認識や前提知識が成り立たなくなる課題
私自身にとっても LeSS ははじめてだったため、旧プロダクトの現状を見て単純に LeSS についての知識が足りていないから違和感を持つのではないか?と思ったり、新プロダクトのメンバー同様に漠然とした不安をもったりしていましたが、その違和感や課題、不安を整理していくと、そこに見えてきたのは「スクラム」でした。
LeSS も スクラム である。
「スクラム」であるならばと、スクラムマスターとの会話を重ね、それぞれのチームが元々抱えていた課題や目指したいスクラム像のすり合わせをおこないながら、1年半かけてチームに対してアプローチをおこなってきました。
まだまだ荒削りで道半ばではありますが、双方のチームが壁を感じながら合体しただけの状態から、1つのスクラムチームとして融合し次のステップに進めるようになるまでの LeSS の歩みを、実際におこなったアプローチや私自身が感じたこととともに紹介します。
「うちも LeSS やっているけれど、なかなかうまくいかなくて・・・」
「LeSS って人数も多いし、なんだか難しくて大変><」
「同じ LeSS チームなのに、チーム内で対立構造ができてしまって困っている」
などの悩みを抱える方にとって、それぞれのチームが抱える課題は違っていても、よくしていくための一歩を踏み出せるきっかけになれば、と思っています。