大規模スクラムのプロジェクト実践事例 〜 不確実性を乗り切った工夫の紹介

こんにちは！　スクラムマスターの似内、田原、小林、荒瀬です。今年私たちは、巨大なスポーツイベントにおける各国の代表選手、試合スケジュールや結果が見れる、総合メディアサイトを開発しました。約40人が直接的に関わる大きなプロジェクトでしたが、大規模スクラムで進めました。
実践した私たちの軌跡を通して、大規模ならではのスクラムの工夫や進め方をご紹介します。同じような状況下の方のお役に立てれば幸いです。

なぜスクラムを選択したか

新型コロナウイルスの世界的感染拡大発生後初めての、多くの国・地域が集結した世界規模のスポーツの祭典でした。この影響は私たちの開発プロジェクトにもあり、要求や仕様が開催直前に決まるなど、情報が二転三転しました。過去に類を見ない困難なプロジェクトですが、スポーツが大好きな私たちはスポーツ好きな人々に楽しんでもらいたく、閉幕まで走り続けました。これを進めるにあたり、以下のような制約条件がありました。

1. 外部との取り決めはプロジェクト初期に決める
   このプロジェクトはステークホルダーが多く、またそれが社内外にいます。彼らとの契約や要望はプロジェクト初期段階で決まります。例えば全競技、全試合の速報情報や広告、ページレイアウト、実装する機能など多岐に渡ります。
2. 公式スケジュールを厳守する
   イベントの公式サイドで決まったスケジュールは、私たちの都合で変えられないファーストプライオリティです。もちろん提供するプロダクトの品質もユーザー価値も満たした上です。
3. 開催可否に始まり観客有無、代表選手、新競技に関する情報は判明次第順次対応する
   先ほどのプロジェクト初期段階で決まるものとは反対に、プロジェクトが走りながら決まるものもあります。例えば開催決定後も観客有無は決まっていませんでした。観客有りの場合は熱中症情報や電車の期間中のダイヤ変更、交通規制情報が重要になってきますし、反対に観客なしの場合はテレビ放映情報が重要になってきます。それらが決定後、Yahoo!検索、Yahoo!天気、Yahoo!地図などの他サービスと連携しながら仕様を固めます。

つまり私たちが作るプロダクトは、プロジェクト初期に決まることとプロジェクトを走らせながら決めていくことが併存し、かつ開催日に確実にローンチする必要があるものでした。 また以前のプロジェクトをウォーターフォールで進めた際に、プロジェクト終盤におこなったテストや仕様変更によりコードやデザインの修正が増えメンバーの作業量が増えた経験がありました。 そこで、プロジェクトの早い段階から品質を満たしたプロダクトをイテレーティブに作れるスクラムを選択しました。

大規模スクラムまでにやったこと

今回の開発プロジェクトは、ヤフー社員、協力会社社員含めて約40人が直接的に関わりました。ステークホルダーを含めるとさらに人数は増えます。 大規模スクラムが未経験だったこともあり、アジャイルコーチに相談しました。

その結果、大規模スクラムを始める前に、以下の理由で1チームスクラムからお試しで始めることにしました。

• スクラムマスターとして、チームをサポートできるよう事前にスクラムを体験する
• 大規模スクラム開始までに準備が必要なものやステークホルダーへの協力を明らかにする
• スクラムを経験したのち、スクラム以外の方法も選択肢にあるか検討する

役割について

1チームスクラムの役割はこのようにしました。

スクラムマスターとしての振る舞いを見て学ぶのと、他の役割を体験することで相手の立場を理解したサポートをできるようになるのが狙いです。

進め方について

事前準備は以下の流れで進めました。

1. アジャイルコーチによるスクラムの概要説明
   スクラム経験、未経験、知識格差がありましたので、まずは改めてスクラムについて知識をそろえ共通言語を増やします。
2. プロダクトバックログ、スプリントバックログ、完成の定義を作成
   プロダクトバックログ、スプリントバックログ、完成の定義はMiroで管理しました。
3. 1sprint（1週間）実践
   動くプロダクトを1sprintで実際に作りました。
4. フリカエリ
   1sprint経験してツールやスクラムイベントについて見直したり新たに生まれた疑問や懸念について話したりしました。そして大規模スクラム参加メンバーに伝えたいことを決めました。

Miroは無限に広がるキャンパスのように使えて、こういった選択理由がありました。

• チームの成長に合わせてレイアウトを変えられる。
• 情報が階層化されないので視認性が高い。
• 他のツールと違い文字を書きすぎないので会話が誘発できる。
• 共有したいことを伝言板みたいに伝えることができる。

（2022年8月10日追記）
2022年にMiroの日本語版がリリースされ、スクラム向けテンプレートの提供も始まったようです。
アジャイルチームのためのスクラムボード（外部サイト）

大規模スクラム実践終盤のスプリントバックログと完成の定義、プロダクトバックログのレイアウトはこんな感じでした。

大規模スクラムのセットアップ

大規模スクラムはLeSS（LargeScaleScrum）を採用しました。チーム編成と役割は以下です。どの役割も専任です。

チームの編成条件は以下になります。

1. 動くプロダクトを作れるスキルセットがそろっていること
2. 偽装請負にならないこと
3. 上記条件を満たした最小の人数であること

ウォーターフォールの時は職種単位（コンポーネント）でチーム編成し、中間生成物が各チームのゴールやプロジェクト全体のマイルストーンになりますが、スクラムの場合、プロダクトの機能や要件が各チームのゴールやプロジェクト全体のマイルストーンになります。チーム内外の情報共有・引き継ぎ方法やプロダクト管理方法も見直しました。

大規模スクラム実践と工夫

ここからはスクラム実践する中で継続したことや背景にあるチームのコアバリューにしたことをお話しします。

シンプルなプロセスにする

チーム運営の決め事はリードタイムへの影響を考慮しました。
例えばメンバーが課題を抱えた後、他メンバーと共に解決した場合、次回からは課題から解決まで個人で完結できるための手順や、関連情報をドキュメントにまとめたり、他メンバーのサポートを得るまでの手順が追加されることがありました。個人が課題解決できることはとても素晴らしいことです。一方でドキュメントの更新管理や他メンバーのサポートを受けるまでの手順が増えた結果、課題解決のリードタイムやプロダクトインクリメントに直結しない作業が増えないようでできるだけシンプルなプロセスを維持できるよう心掛けました。

私たちのチーム運営の一例をご紹介します。

• Slackのチャンネル数は必要最低限にし、複雑な情報管理をしない
  1番活発だったチャンネルは全チーム合同のチャンネルで、常に情報が最短で共有されます。
• 共有したいことやチームで話し合った履歴などはMiroで一元管理する
  お休みの方も翌日Miroを見れば現状をすぐに把握できます。
• 悩んだらすぐにZoomで相談する
  SlackでチャットラリーするよりZoom立ち上げ話した方が解決が早いです。クラスタ構成に関するリファクタから競技のルール確認レベルでもすぐに話して解決できました。

ワンピースフロープロダクションにする

困ってるメンバーを他メンバーが早期に気づきやすくなりました。タスクが停滞しているとき担当者は想定より作業が大変だったり、もしかしたら悩んでいるかもしれません。そういった状況はデイリースクラムで把握できますが、もっと早く他メンバーが気づけてサポートすることでより進展します。他メンバーがすぐに気づけるよう、タスクをできるだけ小さく分割し、かつ仕掛かり(作業中)タスクは1つまでにしました。これによって１つのタスクが長時間、スプリントバックログの”In Progress”レーンにあると声をかけ、一緒に解決する活動が自然と定着しました。

責任と裁量の明確化をする

プロダクトに対する提案や議論が職種、会社関係なくできました。
プロジェクトメンバーは職種別のスキルセットやヤフー社員、協力会社社員ととさまざまなバックグランドやマインドセットで構成されたフィーチャーチームです。スプリントゴールやプロダクトゴール、役割や責任範囲は同じで、そのための権限や裁量は可能な限り平等にしましたが、当初、意思決定範囲に戸惑いがありました。そこで私たちは以下を実施し役割ごとの責任や意思決定範囲の明確化しました。

• スクラムチーム外やステークホルダーとのミーティングも職種、会社関係なく必要なメンバーは参加しました
• スクラムマスターからチームに向けてチームが意思決定しやすいバウンダリーの提案をしました
• 調査、設計がその後のタスク（開発やレビューなど）に影響がある場合は、ペアプロ、モブプロによる協働作業しました
• プロダクトオーナーと一緒にスプリントレビュー時のステークホルダーに向けた説明や質疑に対する応答はメンバーにお願いしました

自己管理で返答待ちをコントローラブルにする

プロダクトの進捗をできるだけ自分たちで管理できました。
冒頭で語った通り、不確実性が高いプロジェクトでした。将来リソースやスケジュールに影響しそうなことは、プロダクトバックログで可視化しました。不確実性の大半はチームのものづくりにおける未経験タスク、ステークホルダーからの要望やフィードバックによる作業規模、社外折衝時に発生する“返答待ち”でした。

そこでわれわれは不確実性を減らし、手戻りや将来の予測を高めるために以下を実施しました。

• 未経験タスクに関するプロダクトバックログアイテムの優先順位を高くしたり、完成の定義を更新し何度も反復し学習しました
• プロジェクトに影響を及ぼすステークホルダーは可能な限りスプリントレビューに参加していただき、プロダクトの動作、デザインやUXに関するフィードバックを受けました
• 社外のステークホルダーと定期的に話し合う場を設けました

未経験タスクを徐々に経験済みタスクに変えることで、計画もしやすく、また何度もフィードバックをいただくことで、ステークホルダーの思考を理解できたと思います。

経験をもとに意思決定する

憶測による議論や意思決定が減りました。
スクラムは、スプリントゴールとプロダクトゴールの2つのゴールがあります。スプリント毎にスプリントゴールに向けた計画をしますが、将来のプロダクトゴールを気にした計画をすると、設計やコードの量やそれらに関連した議論が増える傾向がありました。そして、遠い将来を気にするあまり、憶測で計画してしまい、手戻りや作りすぎなどのムダが発生する懸念もありました。憶測ではなく、経験に基づいた計画や意思決定をするために以下を取り組みました。

• プロダクトゴールは気にしつつも、スプリントプランニングはスプリントゴールに必要な分だけ計画（設計、調査の範囲）する
• 日々小さいチャレンジ（実験）を行い、デイリースクラムでチャレンジから学んだことを共有し、学んだことをチーム運営に反映する

大規模スクラム実施の結果

苦しい時もありましたが当初決めたスケジュール通りにローンチしました。そして、ユーザー満足度も、非常に高いことが、定量での結果と定性での調査から明らかになっています。

私たちが、ユーザーに届けられたコンテンツの一部を、ご紹介いたします。

• 開会式、閉会式の速報（入場全曲含む）
• リアルタイムでの試合結果速報（全競技全種目）
• 競技ハイライト動画・ニュース
• テレビ放映スケジュール

大規模スクラムを経験して

困難の連続でした。にもかかわらずメンバーのモチベーションやリレーションは、終始良かったと感じています。私たちがすごいなと思ったのはスクラムメンバーが、今までの経験や職種ごとのそれまでの進め方やこだわりを横に置いてスクラムを受け入れ、頻繁に対話しお互いの立場や大事にしていることに配慮しながら意思決定するマインドセットでした。
スクラムチームメンバー同士、さらにはステークホルダーとの関係性が良くなるほどプロセスや結果がどんどん良くなりました。どんなに忙しくてもチームメンバーを気遣い、また他チームを助けるコメントがたくさんSlackに流れていました。

類を見ない困難なプロジェクトを走り切れたのは職種、会社、チームの垣根を越えてお互いを助け合えるカルチャーをみんなでつくれたからだと確信しています。

最後に、スクラムチームとステークホルダーのコメントをご紹介いたします。

ステークホルダー

• スプリントレビューに参加したのでチームの方と心理的安全性が一緒に作れたと思う
• 困っていることや相談したいことをすぐに聞いてくれた
• また進捗も把握しやすかった

プロダクトオーナー

• プロダクトに関する全てのことを決定するのではなくチームからも提案いただけた
• チームがプロダクトオーナーシップを持ってくれたので自分たちがボトルネックにならずに済んだ
• 普段当たり前に使っているビジネス用語をチームも理解してくれた

チーム

• 全員がスプリントレビューに参加することでステークホルダーの考え、フィードバックが把握できプロダクトに対するナレッジが浸透しやすかった
• プロダクトのことを理解できたからこそ意思決定がスムーズだった
• 企画視点、デザイナー視点、開発視点、さまざまな視点から提案できるようになった

スクラムマスター

• このプロジェクトは終始、チームとステークホルダーの関係は良好でした
• スプリントゴールやプロダクトゴールと共通のゴールがあることで職種によるこだわりよりも共通の目標に向かって互いを気遣いサポートできたと思います
• プロジェクトが進むにつれて一体感とプロダクトオーナーシップの高まりを感じました

今回経験したことやカルチャーを継承し、次の同規模プロジェクトでもスクラムで進めています。