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

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

[高橋睦美，＠IT]

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

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

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

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

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

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

原因はどこに？　サポーターの力を借りながら再始動

　その後もこのチームでは、計画通りにプロジェクトが進まない状況が発生し、メンバーが残業して遅れを取り戻す状況が繰り返されていた。当初スクラム開発の旗振りをしていたAさんはチームを去り、若手のBさんがプロジェクトマネジャーになり挑戦していたが、状況はなかなか好転しない。その状況を立て直すため、経験豊富なCさんが「サポーター」という立場でチームに加わり、変革に取り組んだ。

チームの登場人物

　Cさんの見立てでは、このチームには下記のような課題があったという。

• プロジェクトマネジャーがエンジニアのアサインとタスクを細かく管理しようとしている
• 要件が曖昧なまま始まっているプロジェクトがある
• エンジニアごとに担当する機能がほぼ固定されている
• タスク一つ一つの見積もりが個人に依存している

　この結果、リスケジュールが繰り返され、依頼元からクレームが発生する状況となっていた。こうした現状を踏まえ、Cさんとマネジャーが目指したのは次のようなチームだ。

• プロジェクトマネジャーは要件の決定に集中する
• 個人への依存を減らし、チームで仕事を進められるようになる
• プロジェクトマネジャーがエンジニアを管理するのではなく、チームが自主的に仕事を進められるようになる

　しかもちょうどこの頃、たまたまチームの1人がスクラムマスター研修に参加し、過去の失敗を知らずに「スクラム開発、やってみませんか」と再提案してきた。過去に一度挑戦しながら、うまくいかなかった経験を持つメンバーからは戸惑いや疑念の声もあったが、Cさんは「チームを変革し、課題を解決するチャンス」と捉え、チームとしてスクラム開発に再挑戦した。

不安から生まれた反発を乗り越え、少しずつ成長

　チームはまず、2週間のスプリントに取り組んだ。すでにタスク一覧はあったため、最初のスプリントで取り組むタスクを決めようとしたところ「全体のスケジュールはどうやって管理するのか」といった反発があったという。

　だが実は、WBSを用いて全体を管理していたときでも、スケジュール通りに進むことはまれだった。というのも、プロジェクトの進行に伴い、新たなタスクや疑問が発生することは珍しくない上に、そもそも「要件は何か」が曖昧なまま「取りあえず設計を終わらせてフェーズを進めよう」というやり方で進んでいたためだ。

　これに対しCさんはまず、2週間のスプリントの中で「何をもってタスク完了とするのか」を定義し、さらに優先すべきタスクを決め、チケット化することから始めるようBさんに求めた。そしてこれらのチケットを元にエンジニアが工数を見積もり、そのチケットを誰が担当するかもプロジェクトマネジャーが割り振るのではなく、チームで相談しながら決めていく形にした。こうして優先すべきタスクを明確にし、工数を見積もることで計画を立てていった。

　次の取り組みはレトロスペクティブだった。レトロスペクティブは、1つのスプリントを回した後に振り返りを行い、どのような問題が起こったかを話し合っていく作業だが、ここでも進捗を優先するあまり、「振り返りよりも、すぐ次のタスクに着手すべきではないか」という反発があったという。

　だが考えてみれば、これまでのやり方では、チームメンバーはそれぞれアサインされたタスクをこなすのに精いっぱいで、せいぜいスケジュールにバッファーを持たせるくらいしか改善の余地がなかった。つまり、チームの中で仕事の仕方を改善する機会が存在しなかったのだ。それを改善する場がレトロスペクティブというわけだ。

　実際に振り返ってみると「やることがクリアになった」「他のメンバーがやっていることが把握できた」のようにうまくいった事柄と同時に、「差し込みがあって遅れてしまった」「チケットの書き方がまちまちで分かりづらかった」と、うまくいかなかった事柄も出てきた。こうした意見をベースに、「次に、もう少しうまくやるためにできること」をチームとして検討し、「チケットの書き方をそろえよう」といったすぐできる改善案を次のスプリントで試していくことにした。

　3つ目の挑戦は、作業の大きさを測るストーリーポイントの見積もりだ。これまたチームからは「この作業をいちいちやっていて案件は回るのか。スケジュールに間に合うのか」という反発を受けたという。

　しかし実際のところ、プロジェクトを回し始めた後に分からない点が生まれてくるのはよくあることだ。このため、スケジュールもなかなか見積もり通りには進まない。そこをなんとかするために、さらに見積もりに時間を費やすような状況になっていた。

　こうした状況を改善するために提案したのが、ストーリーポイントの見積もりだ。すると、「自分と全く違うポイントを出す人がいる」「ポイントを決められない」といった声が上がってきた。そこで、互いに「なぜそのポイントを出したのか」を話し合い、どこに時間がかかるのか、何の確認が必要なのかを納得するまで話し合ったことで、次のスプリントで実行するチケットは、以前より自信を持って終わらせることができるようになったという。

　一度スクラム開発を試し、失敗したからこそ生じたスクラム開発への反発。その背景には「不安」があったのではないかと國本氏は述べた。

楽天グループ ECインキュベーション開発部 General Manager 國本隆志氏

　「誰もがプロダクトを良くしたい、依頼元の期待に応えたいと思っています。ですが過去の失敗の経験もあり、やり方を変えるとうまくいかず期待に応えられないのではないか、従来の進め方が確実なんじゃないか、という不安が反発となって現れていたのではないかと考えます」（國本氏）。さらに根本原因をたどれば、プロジェクトマネジャーは依頼元の担当者からの、担当者はその上司からの期待やプレッシャーにさらされていたといえる。

　そこで登場したのが、チームマネジャーだ。マネジャー自ら依頼元の上司に「今はチームの成長が必要なフェーズです。最初は案件の進みが遅くなるかもしれませんが、挑戦させてほしい」と説得することで、チーム全体が心置きなくスクラム開発に挑戦できたという。

　結果として、チームはスクラム開発への挑戦を通じて少しずつ成長し、プロジェクトマネジャーは細かな進捗管理から解放され、本来の役割である要件そのものの検討に時間を割けるようになった。そして、ストーリーポイントの見積もりを通してチーム全体の会話が増え、知識の共有が進んだ。さらに、どうやってスプリントを終わらせていくかという共通のゴールを達成するため、より良い進め方をメンバーが自ら考えるようになっていったという。

　良かれと思いスクラム開発に挑戦したものの、期待に応えようとするあまりに挫折し、結局元のやり方に戻ってしまう――このような話は楽天の開発チームに限らず、あちこちに転がっているだろう。楽天の開発チームがスクラム開発に再挑戦して得た学びから幾つかの示唆が得られるはずだ。