スタートアップが痛みを伴いながらアジャイル開発をスケールした物語〜LeSS序章〜
こんにちは、atama plusというAI×教育のスタートアップでスクラムマスターをしている河口です。
会社の紹介については、下記のスライドを参照ください。
atama plusでは創業以来アジャイル開発を行っています。1チームから始まり、3チーム、5チームと組織の拡大に伴い「どのようにアジャイル開発をスケールするか」という壁にぶち当たりました。
例えば、チームを細かく分けすぎたことによってチーム間の調整コストが上がったり、局所最適が加速しプロダクトの一体感が失われていったり・・・。
みなさんの組織の中でも思い当たる節はあるのではないでしょうか？
急激・急速に拡大するスタートアップがどのように痛みを伴いながらアジャイル開発をスケールしていったのか？
第1回目の今回はatama plusがどのように大規模アジャイルへ取り組んでいったのか、その背景にはどんな課題があったのかをお伝えします。
atama plusのビジネスモデルとプロダクト
まずは、atama plusの組織課題をご理解いただくために、atama plusのビジネスモデルについてご説明します。atama plusはAI先生「atama＋」を全国の塾・予備校にSaaSモデルで提供しています。
atama plusには4種類のペルソナがいます。
・実際に学習する生徒
・生徒の学習をサポートするコーチ（講師）
・教室を運営する教室長
・複数の教室を管理する塾本部
また、それぞれのペルソナに下記のアプリを提供しています。
・atama＋（生徒が使うアプリ）
・atama＋ COACH（コーチが使うアプリ）
・atama＋ PORTAL（教室長、塾本部が使うWebアプリ）
ここでご理解いただきたいのが複数のペルソナと複数のプロダクトが連動してatama＋のサービスが成立しているという点です。例えば、教室長が生徒の目標設定の提案をatama＋ PORTALで行い、生徒がatama＋で提案された目標を受け入れる。このように、それぞれのペルソナ、プロダクトの連動を意識したUX設計が重要になります。
アジャイル開発拡大前の開発チーム
2020年5月までは3つのスクラムチームが存在していました。3つのスクラムチームの役割分担は下記の通りです。
・主に生徒の体験を向上するチーム
・主にコーチ（講師）の体験を向上するチーム
・主に教室長、塾本部の体験を向上するチーム
それぞれのスクラムチームは、プロダクトオーナー1名、UXデザイナー2名、エンジニア3〜4名、QA1名という構成で、各スクラムチームでプロダクトバックログ（≒ゴール、戦略）をもっており、セレモニーもそれぞれ別で実施していました。
スクラムチームが増えていくにつれて課題が出始めた
ありがたいことに、atama plusはビジネス、組織ともに拡大していき、開発メンバーの数も順調に増えていきました。
スクラムチームも創業時には1チームから始まり、メンバーが増えていくにつれ、2チーム、3チームと増えていったのですが、チーム数が増えるにつれて下記の課題が出始めました。
・各スクラムチームのプロダクトオーナー間でのコミュニケーションコストがどんどん増加した
・3人のプロダクトオーナーと代表の稲田の4人で全体の戦略を考えていたが、それぞれのプロダクトオーナーが担当領域で課題を捉えてしまっていたため、捉え方が限定的かつ打ち手の粒感も小さくなってしまい、それにつられて見通しも近視眼的になってしまっていた
上述の通り各チームで分担しているユーザー体験はかなり連動します。例えば、生徒が同じ単元につまずいて繰り返し学習してしまう課題は同時に進捗を管理している教室長の課題でもあり、課題をどう捉えるかで解決するチームが異なります。
そんな中、スクラムチームの担当領域が異なることで、局所最適が加速し、スクラムチーム間のプロダクトバックログアイテムの関係性も見えづらくなっていきました。
開発チームの拡大に伴い想定された課題
2020年3月、開発チームのスケーリングを検討するタスクフォースで、スクラムチームをこのまま増やしていったときにどんなことが起こりそうかを議論しました。
・（局所最適の加速）打ち手の優先順位が各チームにとっての最適になり、開発チーム全体としての提供価値が最大化されなくなる
・（スクラムチームのサイロ化）異なるプロダクトバックログ間の関係性が見えづらくなり、スクラムチーム間で協働しづらくなる
・（プロダクト全体への責任感）スクラムチームごとの局所最適が加速すると、プロダクト全体に対する責任感が薄れていくと同時に、プロダクトの統一感や一体感が失われていく
atama plusはスタートアップであり、外部環境もどんどん変化していきます。そんな中で、戦略の変更に対して柔軟に対応できることこそが僕たちの強みであり、その強みを発揮できる組織体制が必要でした。
これらを改善してくれるフレームワークとして、Large-Scale Scrum（以下：LeSS）の採用が候補に上がりました。
LeSSとは
LeSSは、2〜8チーム向けの大規模アジャイルのフレームワークです。特徴として1つのプロダクトバックログを1人のプロダクトオーナーと複数のフィーチャーチームで管理しながら共通のプロダクトゴールに向かって開発をしていく手法になります。
LeSSには大事な原則と最低限のフレームワーク、たくさんのガイド、実験が提供されています。
LeSSの概要を理解したい方は下記の動画がおすすめです。
今回のnoteではLeSSの詳細については記載しませんので、知りたい方は下記の書籍、サイトを御覧ください。
LeSSへの移行
様々な検討を経て、2020年5月にLeSSを導入し3つのスクラムチームのバックログ、セレモニーを統合しLeSS体制へ移行しました。
LeSSの検討プロセス、導入プロセスについては次回のnoteで書く予定ですので、ここでは詳細を記載しませんが、本noteではLeSSを採用することで、上述の課題に対してどのように取り組んでいったかをご説明します。課題のおさらいです。
・（局所最適の加速）打ち手の優先順位が各チームにとっての最適になり、開発チーム全体としての提供価値が最大化されなくなる
・（スクラムチームのサイロ化）異なるプロダクトバックログ間の関係性が見えづらくなり、スクラムチーム間で協働しづらくなる
・（プロダクト全体への責任感）スクラムチームごとの局所最適が加速すると、プロダクト全体に対する責任感が薄れていくと同時に、プロダクトの統一感や一体感が失われていく
局所最適の加速
スクラムチームが増えるということは、それぞれのプロダクトバックログ（≒ゴール、戦略）が存在することになります。
各スクラムチームはプロダクトバックログの最優先のアイテムに着手していたとしても全体で見ると、優先度の低いアイテムに着手している可能性があります。
また特定の領域を特定のチームが対応し続けると知識の属チーム化が進み、全体として注力したい領域が変わった時に、特定のチームしか対応できないリスクがでてきます。
そこでLeSSのプロダクト全体思考の原則を大切にして、下記のような方針に変えました。
・複数のペルソナに対して最も良いアウトカムを出すために、全体最適な価値提供ができる組織にする
・各スクラムチームごとのプロダクトバックログではなく、優先順位付けがされた唯一のプロダクトバックログを作る
こうすることで、複数のチームが同じプロダクトバックログ（≒ゴール、戦略）を見ながら最優先の課題に着手することができます。
スクラムチームのサイロ化
スクラムチームの増加に合わせてそれぞれに別のプロダクトバックログを作成すると、スクラムチーム間のプロダクトバックログアイテムの関係性が見えづらくなります。
そうなると、各スクラムチーム（プロダクトバックログ）のサイロ化が加速し、スクラムチーム間の協働が起きにくくなります。そこでLeSSのルールに基づいて下記のような方針としました。
・専任の1人のプロダクトオーナーが1つのプロダクトバックログ上で全体の優先順位付けを行う
・プロダクトオーナーは今までよりも優先順位付けに専念し、その他のことはチームに任せていく
一般的には、スクラムチーム間の役割分担をすることで組織を拡大させていくと思いますが、LeSSでは、プロダクトオーナーとチームの役割分担を再整理することで、1人のプロダクトオーナー✕複数チームでもスクラムが成立するようになります。
スクラムチーム内の様々なタスク（ミーティングの設定、バックログアイテムのリファインメント、チーム間の調整など）をできるだけチームが引き取り、プロダクトオーナーは全体の戦略を考えることに集中してもらう方向に変えていきました。
プロダクト全体への責任感
最後に、スクラムチームごとの局所最適が進むと、プロダクト全体に対する責任感が薄れていくと同時に、プロダクトの統一感や一体感が失われていきます。
スクラムチームが3つに分かれていたときは、プロダクトオーナーがスクラムチーム間の連携を担っていましたが、LeSSに移行し、同じ戦略のもと、各人、各チームが自律的に連携する方針にしました。
そうすることでみんなで全体感を理解しながら、プロダクト全体に対して必要な動きを自律的にとっていくようになりました。
改めてatama plusはなぜLeSSを導入したのか
LeSSを導入してから1年が経ち現在は5チームでLeSSをしています。
組織拡大を考えたときに、スクラムチームを増やしていきながら領域を細分化していくのか、もしくは、領域を分けずに1つの大きなスクラムチームとして動くのかはかなり大きな分かれ道だったと思います。
その中で、開発チームがLeSSの方向に進んだのは、背景にあるビジネスモデル、プロダクトのフェーズ、組織の拡大など様々な要因のなかで、LeSSが刻々と変わるプロダクト戦略に対してもっと柔軟に対応できるフレームワークであったからだと思います。
今回のお話はあくまで現時点でのスナップショットに過ぎません。
LeSSを導入するまで、そして導入してからもたくさんの課題は出てきました。決して簡単にはいきませんでした。そしてこれからビジネスの拡大、組織の拡大に伴って、開発プロセスもどんどん変化し続けると思います。
次回以降、具体的にどうやってLeSSを導入したのか（LeSSの検討プロセス、導入プロセス）について書きたいと思います。最後までお読みいただきありがとうございました！
atama plusはミッション実現のためにメンバーが集まっている会社で、アジャイル開発はミッション実現の大事な手段です。もしよろしければミッション実現のために一緒にトライしませんか？
▼採用ホームページでもLeSSについての記事を載せていただいています。
いいなと思ったら応援しよう！
