こんにちは、オープンワークのアプリプロジェクトでスクラムマスターをやっている頼です。舌下療法で花粉症を克服しマスクフリーになったのですが、今度はコロナと戦うためのマスクを探しています。

スクラムはじめました

オープンワークでは2019年7月にアプリプロジェクトで初めてスクラムを導入しました。スクラムをはじめて約9ヶ月。今回はその取り組みについて紹介します。スクラムについて勉強だけしてみた、すでに実践してるけど他のチームのスクラムがどんな感じか気になる、といった方に複数チームスクラムのケーススタディとして参考にしていただければと思います。スクラム自体や用語についての説明は割愛しますので悪しからず。

導入の経緯

スクラム導入までの開発は１機能を一人の担当者が開発していました。統合やプロダクトオーナーのレビューの頻度が少なくビッグバンリリースのような進め方になってしまっていました。またオープンワークではじめてのアプリ開発ということで、探り探り工夫しながら進めていましたが、走りながら考え失敗を通して学んでいたため、改善のペースは遅く、メンバーにも負担をかけてしまっていたと思います。見積もりや進捗管理にスクラムのプラクティスを一部取り入れていたものの、アプリの初回リリースが終わりこれからグロースフェーズへ向けて開発体制改善の必要性をより感じ始めたこのタイミングで根本的に開発プロセスを見直そうと思いました。
簡単にまとめると

個人の経験と勘によるプロジェクト管理をやめる
開発プロセスの継続的な改善を実施する
要求の変更に対応できる柔軟な開発チームになる

このようなことをスクラムに期待して本格導入を決めました。

チーム構成

アプリプロジェクトは以下の開発チームとプロダクトオーナー、アナリストで構成されています。

API：2名
Android：3名
iOS：3名

このチームでスクラムを始めるにあたりどの単位でスクラムチームととらえるか、各スクラムイベントをどのように進めるかべきか非常に悩みました。というのもAndroidとiOSは基本的に同じ機能開発をしAPIに依存しており全体として１つのプロダクトを作っています。またアジャイルの文脈ではでは多能工を良しとし、人に技術や知識が依存することを避けたがります。組織によってはAndroid/iOSやAPIを誰でも開発できるようスキルセットを揃えたり、ReactNativeやFlutterのようなクロスプラットフォーム開発を行っているところもあります。しかし、オープンワークではそれぞれの専門性を十分に発揮できるよう各プラットフォームのスキルセットを分けて考えています。アプリはAPIに依存しますが、それぞれのプラットフォームチームは独立して機能を開発・リリースすることができます。ということで弊プロジェクトではそれぞれのプラットフォームチームを１つのスクラムチーム、3スクラムチームで１プロジェクトと捉えることにしました。はじめてのスクラムにしては複雑に感じましたが、とにかくこのやり方がしっくりくるという感覚を頼りにはじめました。

LeSS

一方でこの3チームは様々なところで連携が必要になります。

Android/iOSで細かい動作や仕様の変更についての共有
APIのリリース時期や下位互換性についての共有
一人のプロダクトオーナーとともにプロダクトを開発している

そこで複数チームのスクラムフレームワークのLarge-Scale Scrum（LeSS：大規模スクラム）として捉えています。
それでは、実際行なっているスクラムイベントやプラクティスについて紹介していきます。

スプリント

スプリントのタイムボックスは2週間に設定しています。１週目の月曜にスプリントプランニング、２週目の金曜にスプリントレビューを実施します。月曜や金曜が休みの場合は火曜または木曜にイベントをずらします。こうすることでスプリントごとに営業日数が異なることになり、場合によってはベロシティのばらつきに影響を与えますが、週単位のリズムとして理解しやすいのでこの方法にしています。またレビューからプランニングまでの間に振り返りを行います。

スプリントプランニング１と２

プランニングは２部制になっていて、複数チーム混合で前半を、各チームで後半を実施します。LeSSではこれをスプリントプランニング１（SP1）、スプリントプランニング２（SP2）と呼んでいます（そのまんますぎ）。
プランニング１では30分〜1時間程度でチーム間で依存関係のあるタスクやリリース状況について共有します。また前のスプリントで追加したプロダクトバックログアイテムや改善タスク、発生したバグなどを見返して、プロダクトオーナーが優先度をチームに共有します。このプロセスでスプリントに投入するタスクの選択し優先度を見直すことでROIの最適化を行っています。
プランニング２では各チームに分かれてスプリントバックログを作成します。2時間〜4時間程度で完了します。

プランニング１で決めた優先度でアイテムを選択
担当者を割り振る
プロダクトバックログアイテムをスプリントバックログアイテムに分割
スプリントバックログアイテムを時間単位で見積もる
スプリントの理想時間に収まるよう調整

このようにしてプラットフォームチーム内でのブロッキングなどを確認しながら無理のない計画を立てていきます。

デイリースクラム

朝会は週2回全チーム合同で15分ほどで実施しています。複数チームのこのような集まりはスクラムオブスクラムと呼ばれることがありますが、まだ1チームあたりの人数が少ないこともありここでは特別な調整のためではなく通常の朝会と同様お互いの進捗や問題の共有を行っています。これとは別に単一チームの朝会を毎日実施したり必要に応じて夕会を行うチームもあります。チームごとに必要に応じてコミュニケーション量をコントロールしています。

スプリントレビュー

スプリントレビューは1時間かけて行います。開発チームとプロダクトオーナーだけでなくアナリストやステークホルダーに参加してもらっています。成果についてデモを行うことで各チームの開発状況や今後の開発内容についての共有が行われます。今後の実装予定機能の共有も行います。

レトロスペクティブとオーバーオールレトロスペクティブ

次のプランニングまでに1時間程度かけて振り返りを行います。プラットフォームチーム単位でKPTを使っています。Tryで実施を決めたものは次のスプリントで実施できるようプロダクトバックログアイテムに登録します。また振り返りは各チームで行っています。導入当初は振り返りを3チーム合同で行っていたこともありますが関心事や進捗など状況が大きく異なるため議論が深まらず人数が多いと発言もしずらくなりうまくいきませんでした。しかし一方で仕様の管理方法やテストの進め方などチーム共通またはチームをまたいだ問題を抱えることもありました。そこで

四半期に2回程度の頻度でプロダクトオーナー含め全体を振り返る
単一チームの振り返りのあとに議題をもちよりチーム代表が集まり定期的に振り返る

を実施しています。
後者の複数チームでの定期的な振り返りをLeSSではオーバーオールレトロスペクティブと呼んでいます（長い）。これも1時間以内を目処に実施しています。

感想

当初の目的を再掲

個人の経験と勘によるプロジェクト管理をやめる
開発プロセスの継続的な改善を実施する
要求の変更に対応できる柔軟な開発チームになる

はじめの数スプリントはカオスでしたが徐々に改善されていく様子がスプリントイベントやバーンアップチャートに反映されていきました。まだまだ改善の余地は多く、スプリントゴールがなかなか達成できなかったり、Tryが後回しになりがちだったりしますが、完璧でないにせよ期待していた効果は得られたように思います。
今回LeSSの考えに触れ少し実践したことでこれまでよりも大きく複雑なチーム開発の方法論を学ぶことができました。現状はまだ大規模チームとは言えないですがメンバーは徐々に増えさらに大きなプロジェクトになりつつあります。組織が大きくなっても合理的な開発チームでサービスを支えていきたいと思います。

参考文献

スクラム導入にあたりいくつか文献にあたりました。開始当初はSCRUM BOOT CAMPとスクラムガイドを読んだだけでしたが、複数スクラムや具体的なスプリントイベントの実践方法が分からず苦労しました。その後LeSSを読み始めたのですが自分のスクラムに対しての理解度が低いことに気づきエッセンシャルスクラムを読みました。具体的なプラクティスがたくさん紹介されていてとても参考になりました。紆余曲折してしまいましたが、おすすめの読破順は以下のとおりなので実践される方は是非この順番で読んでみてください。