大規模スクラム実践｜ヤフーの開発事例に学ぼう

大規模開発でのスクラム実践複数チーム・ステークホルダー多数のプロジェクト推進に挑んだヤフーの実例

比較的小さなチームで小回りのきくプロジェクトを進める場合には、アジャイル開発やスクラムの利点をすぐに感じられる場面も多いでしょう。しかし、より多くのステークホルダーが関わってくる大規模な開発プロジェクトとなるとどうなるでしょうか。

いくつかのチームで2010年代前半からアジャイル開発に取り組んできたヤフー株式会社の開発組織ですが、現在では新規にスクラムを導入したいプロジェクトを支援する組織があり、たくさんのステークホルダーが関わる世界的なスポーツイベントの特設メディアサイトの構築においても効果を発揮しています。

スクラムマスターとして2021年にスポーツナビの総合メディアサイト開発を推進した田原慎也さんと、その田原さんたちをアジャイルコーチとして支援した荒瀬中人さんに、複数チームをまとめたスクラムでの工夫や課題を聞きました。

後出しの追加要望や市場変化への対応が容易なスクラム
経験者が多くない中で改善を重ねたスクラム導入
重要なことはステークホルダーも含めた共通理解の醸成
誰が質問を受けても同じ回答ができるより強いチームに
事業貢献やサービス目標を見据えたアジャイル開発を

後出しの追加要望や市場変化への対応が容易なスクラム

── ヤフーが会社としてアジャイルやスクラムを取り入れはじめたのは2010年代前半だと聞いていますが、どういった課題があったのでしょう。

荒瀬　当時は、計画駆動型いわゆるウォーターフォールの開発が主流でした。最初に「どういう価値や機能を提供するか」を計画し、半年くらいのスパンで進めるスタイルですが、いったん計画を立てても実行している間にステークホルダーから急な要望追加があったり、市場の変化や技術刷新への対応も難しい状況でした。また、開発者個々の作業内容が可視化できておらず、チームとしてフォローアップしづらかったと記憶しています。

田原　設計や仕様策定を最初に行い、実際に開発に入るのは2カ月後ということも珍しくありません。いざ開発しようという段になって「あれ、この仕様って何だったっけ？」と詳細を思い出せなかったり、その間に考え方が変わって設計のやり直しになることもあって、時間の面でも手間の面でも無駄が発生することがありました。

── アジャイル導入前の典型的な課題ですね。ヤフーという会社ならではの課題もあったのでしょうか？

荒瀬　直接見聞きしたわけではありませんが、いわゆる「縦割り」が問題になりはじめていたと聞いています。育成やマネージメントの観点から職種ごとのチーム編成になりがちで、結果としてチームを横断した連携やプロダクト全体のマネージメントがボトルネックになります。

── それは大きな企業組織らしい課題ですね。そういった背景からスクラムを採用する動きが徐々に広がってきたということですが、現場ではどう感じていたのでしょうか？

田原　先ほど荒瀬の話にもありましたが、ウォーターフォールで開発を進めていると、プロジェクト終盤になって、「いや、実はこうじゃなかった」といった話が持ち上がることがあります。

また、大きな単位で開発を行うため、そもそものコード量が多く、修正量も増えてしまいます。その結果、コードレビューに割く時間が非常に多くなってしまいました。時間が取られるのも問題ですが、「本当にこの量を適正にレビューしきれるのか？」という状態になったこともありました。

── そういった課題感が、荒瀬さんなどの支援でスクラムを経験してどのように変わったのでしょうか？

田原　スクラムでは、機能を細かく区切って小さな単位でリリースしていけばいいよね、というメリットがまずありましたね。すごく細かい単位で開発していくことになるので、開発単位当たりのコードの量が減って、自ずとコードレビューの量も減ります。また数カ月前に設計した場合と違って、記憶が新しいので新鮮な記憶を元にコードレビューができ、結果として時間が圧倒的に短縮されました。スクラムを導入してよかった点だなと思います。

経験者が多くない中で改善を重ねたスクラム導入

── 2021年の総合メディアサイトのプロジェクトでは、どのような体制で開発に取り組んだのでしょう。

田原　このプロジェクトでは、全体を3つのチームに分けました。それぞれのチームは、スクラムマスターが1人、企画が1人、デザイナーが1人、開発者が3名ほどの6〜7名で構成しました。

自分はそのスクラムマスターの1人で、フォローするアジャイルコーチとして荒瀬に入ってもらった形です。実際にスクラムで開発に携わったメンバーは20名ほどですが、周辺に対外的な調整役も含めてさまざまなステークホルダーが加わり、全体で30〜40名が関わっていました。

── その人数でスクラムイベントを行っていたのですか？

田原　開発系のスクラムでは、3チームに分けてそれぞれにイベントをこなしていたので、参加者は6〜7人ですね。人数が絞られているので誰もが自分事として発言できました。それぞれが考えを持って開発しているので、スクラムマスターから問いかけたり荒瀬が自然な形で促してくれたりすると、発言がしっかり出てきます。それを承認・実施することで当人のやる気も出てきて、スクラムイベントの場がどんどん活性化されていきました。

── スクラムの経験者は多かったのでしょうか？

田原　正直に言うと経験者は多くはなかったと思います。そもそも各チームのスクラムマスター自体もスクラムを経験したことがない状態でした。

ウォーターフォール式の開発に慣れすぎていた面もあり、まずスクラム自体を理解し、適用する部分に時間がかかりました。最初の1カ月ほどは「スクラムとは何か」といったことに縛られてしまい、開発のスピードもそれほど上がらなかったのは事実です。

── まずスクラムを経験することが課題だったわけですね。

田原　ただ、スクラムでは振り返りが毎週できて、毎週改善できる強みがあります。「とにかく試せる」ことは大きいですね。試しては改善するプロセスを繰り返すことで、チームとしてどんどん強くなりますし、未経験のメンバーも「こうしていけばいいんだ」と把握できる。最終的には当初の課題であったスピード感も改善され、スプリントのサイクルも順調に回るようになりました。

── 支援する立場としてはどのように後押ししていったのでしょうか？

荒瀬　スクラムガイドに書かれてるフレームをプロセスに適応し、改善を繰り返してプロセスやチームをより良くしますが、本質的に大事なことはフレームだけでなく、もっと深層的なところにあると考えてます。

例えばより良い意思決定は、チームやチームに関わる人たちとの関係性に影響します。関係性が良いチームの意思決定や進め方は、互いに積極的に関わり合う決定事項が多いです。一方、関係性があまり良くないチームは、互いの関わり度合いを低くした進め方になりがちです。関係性を良くし、互いに信頼しあえるチームの土台こそが重要だと感じています。

ですから私は、スクラムを実践しているチーム内に今何が起きているか、個々の変化が全体にどんな変化変容を及ぼしているか、全体の変化変容はチームが望んでいることか、深く注力してこれからさまざまな困難に立ち向かうチームの土台作りにフォーカスしたサポートを行っています。

── 大事なのはルールや書籍などに書かれているやり方ではないということですか？

荒瀬　そうですね。皆さんやっぱり、最初は「計画はどういうアジェンダで進めるのか」「振り返りにはどういうフレームワークを使うのか」といったHowを求めます。Howを知らなければ一歩が踏み出せないと思いますが、大事なのはもう少しコアなところです。

── 皆さんに当事者意識を持ってもらい、関係性を高めていく上で何か秘策はありますか？

荒瀬　時間をかけてチーム文化を醸成していくことが重要です。反対に何かキーフレーズを発したり、資料を提供したり、あるいは一回合宿をやったりするだけではダメです。その時々の状態に合わせたアプローチが必要なので、ツールを用いたり、勉強会、グループワーク、1on1などを実施します。

── 特効薬があるわけではなく、時間をかけて取り組む必要があるのですね。

荒瀬　そうですね。そこはスクラムと相性がいいと私は思っています。定期的にチームや関係者が顔を合わせる機会が用意されているので、そういった場を活用します。

重要なことはステークホルダーも含めた共通理解の醸成

── テレワークが増えてオンライン会議が中心になると、顔を合わせる機会も減るのではないでしょうか？

荒瀬　私は、オンラインでも対話を重視しています。会話の流れでふと出てきた「分かりません」という一言でも、ネガティブに受け取るかポジティブに受け取るかは、相手のことをどれだけ知っているかで変わります。これをテキストチャットだけで会話していると、誤解や望まない対立が生じる懸念もあります。

さらに、質問や相談に早く応えたいときもあるじゃないですか。Slackなどのテキストツールで言語化して伝えるより直接対話した方が早いし、誤解なく伝わりやすいので私は対話をお勧めしています。

── オンラインならではのメリットも何かあるでしょうか？

田原　個人的にはスクラムとリモートワークはけっこう相性がいいなと思っています。今回の大型プロジェクトでは、Zoomの部屋を定常的に1つ用意しておき、「ここは誰々さんと確認したい」ということがあれば入って話したり、必要があれば小部屋に分かれて話ができました。会議室を用意したり移動したりといったコストがかからないのは、オンラインならではの利点だと思います。

荒瀬　オンラインだからこそ、ステークホルダーを一堂に集めやすいという側面はありますね。サービスによってはスプリントレビューに70人、80人と参加する場合もあります。そのための会議室をスプリントのたびに用意する手間がなくなったのは大きなメリットですね。

── ステークホルダーとのコミュニケーションに関してはいかがですか？

田原　開発チーム内ではオンラインコミュニケーションボードのMiroを使って進捗を把握し、改善を加えていくことができましたが、スポーツナビ全体を管理する立場からは見えにくかったようで「スクラムでやってて、本当に大丈夫？」と思われていた部分もあったかもしれません。そうしたステークホルダーの理解をいかに深めるか？という対外的な部分で苦労したところはありますね。

── どのようにステークホルダーとの関係を築いていったのでしょうか？

田原　そういった対外的な理解を得るという目的も含めて、プロジェクト全体でいろいろな関係者をスプリントレビューに集めました。このレビューは開発チームによるスクラムイベントとは別に、ステークホルダーから意見をもらう場という位置づけで、毎週月曜日にスプリントごとの成果物をレビューしていました。

荒瀬　スプリントレビューに呼ぶステークホルダーに対しても「スプリントレビューの目的や、参加に際してスクラムチームが期待していること」を理解していただきました。

田原　同時にスプリントの成果物をレビューする前に、レビュー対象のスプリントでは「どんな価値を作り上げて、どういった目的で進めたのか」をプロダクトオーナーから全体に説明してもらいました。これによって、どんなフィードバックがほしいのかが明確な状態でスプリントレビューを開催できました。

実際にWebアプリやサービスに触って理解を深めてもらうことで、リリース前に関係者全体で「課題を洗い出して磨き上げたら出せるね」という共通理解ができたのは大きかったと思います。

── やっぱり実際に触れると違いますよね。

荒瀬　ただプレゼンを見るだけの目視確認と、実際にプロダクトを動かす動作確認とは、やっぱりフィードバックが違います。ちょっとした使い勝手やデザインに対するフィードバックや、プロダクトを動かしながらふと発する感想がとても大事なことだったりするので、それらを開発チームが洞察し、将来のプロダクトインクリメントに活かすことが重要だと思っています。

── 実際の開発では3つのチームごとにスクラムイベントを実施したとのことですが、チーム間の意思疎通や理解の共有に関して心がけていたことはありましたか？

田原　もちろん3チームとも同じ目標に向けて動いてはいるんですが、プロジェクトを進める中でチーム独自の文化や暗黙知が生まれてしまいます。それは仕方のないことなので、リファインメント（refinement）を工夫し行いました。そこには全員が参加するのではなく、各チームからランダムに2人ずつ入ってプロダクトバックログアイテムを共有し、その場で暗黙知をなくし、共通認識を生む作業をやっていました。

── コーチの立場からはどのようなアドバイスをしたのでしょうか？

荒瀬　先ほど田原が言った暗黙知と形式知の理解と、その活用方法をアドバイスしました。個人の知識や知見、また経験したことがいわゆる暗黙知です。それを伝えたり一緒に体験したりすることで、チーム全体の暗黙知とする。さらに必要であればドキュメントなど、形に残すいわゆる形式知に変えて、概念化していきます。

暗黙知というのは、互いに共有したり議論したりすることで、新たな知が生み出されます。デイリースクラムでは進捗報告より、暗黙知を共有することをお勧めしています。

誰が質問を受けても同じ回答ができるより強いチームに

── 今回のプロジェクトを紹介した開発者ブログの記事「大規模スクラムのプロジェクト実践事例」ではスクラムを通してプロダクト自体の品質向上が実現できたという話がありましたが、皆さんの関係性やチームにも何か変化があったでしょうか？

田原　大規模スクラムでいうフィーチャーチーム（feature team）になるのではないかと思いますが、共通理解や共通認識がすごく進み、職種を問わず誰もが同じことをやっていける状態になりました。

── それは具体的にはどういうことでしょう？

田原　例えば、それまで他の部署から「このAPIを使いたいんだけど」と仕様を尋ねられても、企画担当が窓口として受け取り、その後でエンジニアを経由して回答することが多かったのですが、それが企画担当であっても「こういう使い方をすれば大丈夫です」と返答できるようになっています。逆に開発者もスプリントレビューの場でステークホルダーと関わったりすることで、ビジネス視点を持てるようになったと思います。

── チームとしてすごく強くなった感じですね。

田原　サービスがローンチして運用が始まった後も、チームの誰もが同じ認識を持っているので、障害が発生しても「誰それに聞かないと分からない」といった属人化がなくなりました。誰か特定の人がいないと不安だという状態がなくなり、プロジェクトメンバーの誰がいても大丈夫なので、運用としてすごく安心ですね。

── 支援する立場からはどうでしょう。

荒瀬　一言で言うと、能動的になったと思います。欲しい情報は積極的に得ようとしますし、メンバーの困り事を早期に検知し、助けにいく場面がすごく増えました。情報が一元管理され、常に最新の情報が誰でも容易に知れる高い透明性を担保してくれていたので活動しやすかったのも大きいですが。スクラムマスターが関係性をより良くするファシリテート、必要な権限や裁量の委譲に関するマネージャーのフォローなど、チームが活動しやすい土壌を自ら作り続けたことが要因だと思います。

もう1つ嬉しい変化としては、品質に対する責任感も高まったように思います。それまでは、作ったプロダクトの品質を一部のテックリードやマネージャーに委ねていた部分がありましたが、自分たちで品質責任を果たす行動に変わったと思います。

田原　自分としては、チームが強くなり、職種の隔てなく共通理解が生まれたことで、一体感を強く感じています。現在もいくつかのチームが別の開発をスクラムで進めていますが、そこでも良さを感じています。

── 今後、ヤフーの社内全体がアジャイル開発になる可能性もあるのでしょうか？

荒瀬　いや、全部をアジャイル開発にするわけではなく、スクラムなど選択肢がある状態を目指しています。プロダクトやチーム、組織の状態に適した進め方を選択できるのが理想だと思います。

── 選択肢の使い分けのポイントは何になるでしょうか？

荒瀬　例えば1人で行う作業や、あまり変化がないチーム開発の場合は、アジャイル開発以外でも良いのかなと思います。一方で、アウトプットのスピードが求められたり、アウトカムが不明瞭だったり、市場の変化が激しかったりする場合は、アジャイル開発が適してるように感じます。スクラムは計画と開発、改善が並行で進められる強みがあります。

── そういう意味で、今回のプロジェクトはまさにアジャイルに向いていましたね。

荒瀬　そうですね。そもそも大会自体が開催されるかどうか分からないところから始まっているプロジェクトですし、大会特有のルールもいつ発表されるか分からない状況でした。そしてローンチ期日が決まると変更できないので、計画しながら開発・改善を進めないととても間に合いません。仕様が固まっていないのに、スケジュールだけは決まっている。まさにアジャイル開発向きの案件だったと思います。

── 現場にとって過酷なプロジェクトほどアジャイルが向いているのかもしれませんね。

事業貢献やサービス目標を見据えたアジャイル開発を

── 最後に、アジャイルやスクラムを進める上で陥りがちな課題があれば教えてください。

荒瀬　思い浮かぶとすれば2つあります。1つは、ビジネスKPIを急激に高めるあまり、チームが持続可能なペースで活動できないことです。実は残業が多かったり、特定のメンバーに負担が偏っていたり、技術的負債が溜まったりしています。もう1つは、ステークホルダーと対立構造になってしまうパターンです。チームが目指してる姿とステークホルダーの求めていることがマッチしてないときです。

── そんな場合はどうすれば改善できるでしょう？

荒瀬　ビジネスKPIとチームコンディション両方の把握が必要だと思います。そして、その2つを分析してみると、因果関係が見えてくる場合があります。チームコンディションを改善することでビジネスKPIにどんな影響があるか、仮説検証しながら進めていきます。

ステークホルダーとは、対話の頻度を増やすことが重要だと考えています。対話を通してお互いが大事にしていることを理解し、協調していくことかなと思います。一緒にプロダクトビジョンやチームコンディションアセスメントなど作ったり、スプリントレビューの場で積極的に対話していくことで改善していくと思います。

取材・構成：高橋睦美
編集：はてな編集部