残業してもタスク山積み、旗振り役は離任――なぜ楽天の開発チームはスクラムに再挑戦し変革できたのか：スクラム開発への反発と向き合う

開発力を向上させたり、プロダクトを素早く提供したりするために、スクラム開発を学ぼうとする機運は高まっている。楽天のある開発チームでもスクラム開発を取り入れたが、うまくいかずに一度は挫折したという。そのいきさつや再挑戦を経て得られた学びを楽天グループの國本隆志氏が共有した。

[高橋睦美，＠IT]

　開発プロジェクトに携わる人ならば誰しも、より良いプロダクトを予定通りに提供したいと思っているはずだ。だからこそ今、開発手法として「スクラム開発」が注目を集めている。一方で「スケジュールを守るため」「要望に応えて良いプロダクトを提供するため」に、これまでのやり方を踏襲しようとすることもある。一度スクラム開発にチャレンジしてうまくいかなかった失敗体験があればなおさらだ。

　楽天のあるチームでは、そうした2つのベクトルのぶつかり合いを経て、再度スクラム開発に挑戦し、少しずつ成果を出しつつある。2022年7月に開催された「Agile Tech EXPO 2022」で楽天グループの國本隆志氏（ECインキュベーション開発部 General Manager）が「スケジュール遅延が当たり前な状況を少し良くしたいチームがその未来のためにScrumに”再”挑戦した話」と題するセッションの中でそのいきさつと、どのように失敗に伴う反発を乗り越えていったかを紹介した。

いったんはスクラムに挑戦したものの成果が出ない

　楽天社内のあるチームでは、書籍でスクラム開発の良さを知ったプロジェクトマネジャーの旗振りで、「スクラムって良いらしいよ、スクラムやろうよ」と押し切り、とにかく一度やってみようとスクラム開発に挑戦したそうだ。

　しかし、要件が曖昧なままに進み、個人が主観で見積もったチケットでスプリントを回すような状況だった。スプリントプランニングも、すでに割り振られたタスクに従うだけ。さらに、スタンドアップミーティングやレトロスペクティブ（振り返り）を実施しても、「10スプリント中の5スプリントまで終わりました」といった単なる進捗（しんちょく）報告の場に終わってしまい、消化しきれなかったチケットが積み上がっていくだけになっていった。

　結局、スクラム開発への道の途上で「このままではまずい、タスクが終わらない」と判断し、あらためて残りのタスクを調査してスケジュールを引き直した。そしてWBS（Work Breakdown Structure）による従来の管理に戻り、周囲のステークホルダーに遅れをわびながらリリースにこぎ着けたという。