スタートアップが痛みを伴いながらアジャイル開発をスケールした物語〜LeSS Hugeへの挑戦〜
こんにちは、atama plusというAI×教育のスタートアップでスクラムマスターをしている河口です。
atama plusでは、創業以来アジャイル開発を行っています。1チームから始まり、3チーム、5チームと組織の拡大に伴い「どのようにアジャイル開発をスケールするか」という壁にぶち当たりました。
例えば、チームを細かく分けすぎたことによってチーム間の調整コストが上がったり、局所最適が加速しプロダクトの一体感が失われていったり・・・。
みなさんの組織の中でも思い当たる節はあるのではないでしょうか？
急激・急速に拡大するスタートアップがどのように痛みを伴いながらアジャイル開発をスケールしていったのか？
第4回目の今回は、atama plusの開発チームが取り組む、最近のアジャイル開発のスケールのための「実験」についてお伝えしようと思います。
2020年の5月にLeSSを導入
以前のnoteでも紹介しましたが、atama plusでは2020年5月に3つのスクラムチームのバックログを統合し、3チームでのLeSSをスタートしました。そこから約1年で2チームが増え、2021年7月からは5チームでLeSSを運用しています。1年間でLeSSの運用に関してたくさんの課題もでてきましたが、最近ではだいぶ慣れてきました。
次なるアジャイル開発のスケールを模索
僕たちは、今後3〜4ヶ月毎に1チームのペースで開発チームを増やすことを目指しています。LeSSに慣れてはきたものの、その体制が現在の5チームから6, 7, 8チームと増えていった際、どこかで限界が来ると感じ、早めに次の開発体制の模索を開始しました。
組織が拡大していくには、一定の役割分担をして局所最適を許容しながら、全体のバランスも整えていかないといけないと思います。しかし、過度な役割分担をしすぎると、サイロ化が進み、戦略変更に対する組織の適応能力が下がることも懸念されます。
過去の経験から、チームの分割方法や開発プロセスの策定が、アジャイル開発をスケールする上でポイントになることを痛感していました。そのポイントを踏まえつつ、開発組織のスケールを検討するチームで、議論を開始しました。
事業の不確実性が高い中で、最適なチーム分割の解が見つからなかった
いろいろなチームの分割方法を検討しました。例えば、事業の顧客セグメントで分ける、狭義のプロダクト単位で分ける、ユーザー体験ベースで分ける、一定のコンポーネントで分ける、などです。
現時点で見えている、向こう3〜6ヶ月で取り組みたい開発テーマを棚卸ししながら、僕たちが開発組織として大切にしたいことも踏まえて議論を重ねました。
結論として、まだまだ事業の不確実性が高く、3ヶ月ごとに戦略をアップデートしている現在のatama plusにおいては、特定の分割軸でチームを分けることはリスクが高いと判断しました。
この判断を踏まえ、次なるアジャイル開発のスケールのため、下記の2つの実験を行うことにしました。
【実験①】開発効率・開発基盤系に取り組むDev・QAのみのスクラムチームを切り出す
atama plusでは、ユーザーが使う機能を開発するチームではUXが1〜2名、Devが3〜4名、QA1名という構成でチームを組んでいます。この構成の5チームでLeSSをしていたとき、2つの課題が見えてきました。
1点目は、開発効率・開発基盤に投資するテーマの優先順位がなかなか上がらないことです。事業を進めるためのユーザー価値に繋がるような開発テーマと、ライブラリのアップデートやアーキテクチャに関する課題では、後者の開発効率・開発基盤に関するテーマの優先順位づけの判断が難しい状況がありました。プロダクトオーナーも、頭ではわかっていても、どうしてもユーザー価値に繋がるテーマを優先したくなります。
2点目は、チーム内のリソース配分が難しいことです。UX、Devがいるチームで開発効率・開発基盤系のPBIを取ると、Devのリソースがそこに集中し、UXのリソースが浮く可能性があります。そのため、チームとしても開発効率・開発基盤系のPBIを取るタイミングがないという状況でした。
そこで、実験的に開発効率・開発基盤系に関してはDev2〜3名とQA1名のスクラムチームとして切り出し、プロダクトバックログ、POも分ける実験を開始しました。
【実験②】担当領域を決めずに、1つのLeSSを2つのエリアに分割してみる
LeSSを2つのエリアに分割することに決めてみたものの、どういう軸で分割するかの結論はでていませんでした。
また、2つのLeSSのエリアで、それぞれのスクラムイベントが成立するのか？それぞれのエリアで相互に連携できるのか？など、運用部分でも未知の部分がたくさんありました。
そこで、とりあえず残りの4チームを2チームずつのLeSSのエリアに二分し、それぞれでスクラムイベントを回してみることで、その運用に慣れる、運用課題を出そうという実験を開始しました。
社内ではLeSS Hugeという言葉は使っていませんが、結果的にLeSS Hugeに近い形だったと思います。2エリアのLeSSそれぞれにプロダクトオーナー、バックログをもち、各エリアがそれぞれ独立してスクラムを回している状態になります。
2つのスクラムは独立して回りますが、2人のプロダクトオーナーはかなり密に連携します。常に全体像を把握し、全体としてやるべきテーマを並べ、お互いのエリアのリソース状況、テーマの依存関係などを見ながら、各エリアで取るテーマを調整し動いていきました。
また各職種（UX, Dev, QA）もエリアを横断して、お互いのエリアで扱うテーマを把握し、コンフリクトが発生していないかを連携しながら振り返り、3ヶ月ほど運用しました。
現時点での所感
上記２つの実験を2021年7月から始め、毎月実験のレトロスペクティブを横断で行い、チューニングしながら今日まで運用しています。
現時点での所感としては、概ねうまくいっているのではないかと思います。開発効率・開発基盤系に取り組むチームのモチベーションは高く、PBIに取り組んでいます。また、2エリアのLeSS Hugeの形にした部分については、下記のようなフィードバックがメンバーからでています。
- 5チームLeSSのときに比べて、プロダクトオーナーがよりチームメンバーと密に連携がとれるようになった。
- エリアとしてやるべきテーマがクリアになり、選択と集中が行えるようになった。5チームのLeSSから2チームのLeSSになったため、スクラムイベントが軽量化され、エリア内の連携が密になった。
- 自分が属していないエリアが何をやっているのかわからなくなった。情報のキャッチアップコストは減った一方で、コンフリクトの不安もある。
ぼく個人としては、5チーム1エリアのLeSSからエリアを3つに分けたことで、想像以上に各エリア内の連携密度が向上した一方、各エリアのサイロ化は飛躍的に加速したと感じています。
今回はあえてLeSSのエリアを分けることで一定のサイロ化を許容し、うまく連携する方法を模索する実験なので概ね順調であると感じています。今後も引き続き、何が起こるかは注視しながら、みんなと一緒に実験を繰り返していきたいと思います。
まだまだ伸びしろがたくさん
今週から新しいチームが立ち上がり、3チームのLeSSのエリアと2チームのLeSSのエリアでの新しいLeSS Hugeの形になります。これからまた新しい課題が見えてくると思うので、随時みんなで実験をしながら、atama plusらしい開発体制・開発カルチャーを作っていきたいと思います。
atama plusは生徒の学びを加速するために、これからもどんどん仲間を増やしていきます。開発組織もそれに伴い、どんどん変化していき、課題も山積みです。
Missionの実現はとても困難です。 その道の半ばでは、ときに変化に伴う痛みが発生します。 それでも私たちは、現状に甘んじて快適な状態にとどまるのではなく、 その困難に挑戦し続けます。 その挑戦を支えるのは「なにごとも楽しくなくっちゃ」という遊び心です。 ひと手間かけてみたり、視点を変えてみたり、良い面に目を向けてみたり。 自らが率先して動き、あらゆる状況を楽しみながら、 Missionの実現に向かいます。
これはぼくたちが大事にしているatama plusのカルチャーコードの一文です。引き続き痛みを伴う変化にチャレンジしていきます。
atama plusはミッション実現のためにメンバーが集まっている会社で、アジャイル開発はミッション実現の大事な手段です。もしよろしければミッション実現のために一緒にトライしませんか？
変化の伴う痛みを楽しみたい方、ぜひご連絡お待ちしております！
▼募集職種一覧
▼採用ホームページでもLeSSについての記事を載せていただいています
▼会社紹介
いいなと思ったら応援しよう！
