スタートアップが痛みを伴いながらアジャイル開発をスケールした物語〜LeSSの検討・導入編〜
こんにちは、atama plusというAI×教育のスタートアップでスクラムマスターをしている河口です。
会社の紹介については、下記のスライドを参照ください。
atama plusでは創業以来アジャイル開発を行っています。1チームから始まり、3チーム、5チームと組織の拡大に伴い「どのようにアジャイル開発をスケールするか」という壁にぶち当たりました。
例えば、チームを細かく分けすぎたことによってチーム間の調整コストが上がったり、局所最適が加速しプロダクトの一体感が失われていったり・・・。
みなさんの組織の中でも思い当たる節はあるのではないでしょうか？
急激に拡大するスタートアップがどのように痛みを伴いながらアジャイル開発をスケールしていったのか？
第1回目の前回はatama plusがどのように大規模アジャイルへ取り組んでいったのか、その背景にはどんな課題があったのかをお伝えしました。
第2回の今回は「具体的にどうやってLeSSを導入したのか」について書きます。もし、これからLeSSの導入を検討されている方がいらっしゃれば何かのヒントになれば幸いです。時系列順に導入経緯をご紹介していきます。
2020年2月LeSSというのがあるらしい・・・
遡ること2020年2月・・・。スクラムマスターを初めて1ヶ月、代表の稲田から「組織の次のスケーリングを考えてほしい」というお題をもらいました。
そこで、まず大規模アジャイルについて知るために、SAFeのセミナーに顔をだしたり、Scrum@Scaleについて調べたり、LeSSの本を読んだりと情報収集を開始しました。
そんな中、2020年2月にLeSSの考案者であるBas VoddeさんのLeSS実践者トレーニングがOdd-eで行われると聞き、3日間のトレーニングを受講しました。
余談ですが、そこでアジャイルコーチののりぴーさんと出会いその後atama plusにも遊びに来ていただき記事にしていただいたので、こちらもぜひご覧ください！
また、LeSSを実際にやられているRettyの常松さんを始めとする皆様にお話を伺ったり、ヤフーの荒瀬さんにもお話を伺いました。
2020年3月スケーリング検討タスクフォースの立ち上げ
具体的にアプリチームのスケーリングを検討するためにタスクフォースの立ち上げをしました。ぼくがタスクフォースオーナーをし、PO、UX、Dev、QAから代表者を募り、8人で議論を開始しました。
まずはじめに、「そもそもなぜアジャイル開発なのか」、「このままスケールするとどんなことが起きるか」について考えるワークショップを実施しました。
ワークショップの中では下記のような意見がでていました。
『Why Agile?（なぜアジャイル開発なのか）』
・早く価値を届ける必要がある＆早く学習するため
・わからないことが多いので検証しながら少しずつ学ぶため
・わかったつもり、なんとなくで進めると間違っていることが多いため
・外部環境の変化に対応するため
・不透明・不明確なことが多く、計画より変化への適応が求められるため
・アウトプットよりアウトカムを最大化するのに最も適していると信じているから
・やっていて楽しいから
『このままスケールするとどんなことが起きるか』
調整コスト増への懸念
・依存関係増、チームの独立性が損なわれる
・技術的コンフリクトによりDeliver依存関係が複雑化
・プロダクトの統一感、一体感を保つコスト増
Deliverのコスト増によるスピードダウン
・実装コスト、テストコスト増大
・MTG時間長くなる
（アウトカムの）局所最適
・全体感が失われる→何を目指しているかわからなくなる
・自チームのスコープについて非常に詳しくなる＆他チームへの興味低下
チーム間のコミュニケーションが減る
・喧嘩、チーム間が疎遠になる
各チームのフォーカスが絞られる
・知識の属チーム化
・フォーカスが絞られすぎてつまらない
・一方でフォーカスが絞られてミッションが明確になることでスピードがあがる
2020年3月 社内でLeSSの勉強会を実施
LeSSを検討するにあたりLeSSへの理解が必要なため、勉強会を有志で行いました（当時約15名が参加してくれました！）。勉強会は僕が実際に受講したLeSSの実践者トレーニングの内容を参考に設計しました。
当時の開発チームはスクラム自体への理解が浅かったため、LeSSの勉強会の中で、スクラム自体への質問がたくさん出ていたのが印象的でした。
2020年4月 スケーリング検討タスクフォースで議論開始
LeSSをアプリチームに当てはめるとどうなるかをタスクフォースメンバーとシミュレーションし、ありとあらゆる懸念を出し、1つずつ議論しながら潰していきました。まだ体験したことのない課題を議論するに当たり解決策が見つからないときは、LeSSの本の『ガイド』が非常に役に立ちました。
組織体制における懸念を洗い出し
出てきた懸念をグルーピング化して1つずつ議論
出てきた課題の一例は下記です。
・複数チームでリファインメントって実際どういうプロセスになる？
・プロダクトオーナーとチームとのバックログ完了の確認ミーティングって時間的に成立するの？
・デュアルトラックアジャイルのプロセスとどう成立させるの？
当時のカレンダーを確認すると合計約20時間に及ぶ議論を行っていました。最終的にはLeSSを導入するプロセスも含めて1つのドキュメントにまとめて、方針含め代表の稲田に共有して具体的にLeSSへ移行する意思決定を行いました。
また、緊急事態宣言が発令された関係で、議論がオフラインからオンラインに切り替わりました。当時はオンラインにまだなれておらず、オンライン上での長時間の議論はかなりハードでした。笑
2020年5月 いよいよLeSSを導入
初の緊急事態宣言下でまだリモートワークに試行錯誤している中でしたが、LeSSへ移行することを決断しました。ゴールデンウィークを挟むスプリントでアプリチームの開発を中断し、下記を行いました。
・LeSSについて理解するワークショップ（計2日間）
・新しく統合したプロダクトバックログの複数チームでのリファインメント（計2日間）
・各チームでのチームビルディング
上記の、ワークショップやリファインメントはすべてオンラインで行い、初めてづくしでした。こうして、2020年5月13日からLeSS体制としての新しいスプリントをスタートさせました。
LeSSの導入検討で特に苦労した点
ここでは2点あげます。
1点目は僕たちが大切にしているデュアルトラックアジャイルの考え方、プロセスとの兼ね合いをどうしていくかという点です。議論が白熱しました。
デュアルトラックアジャイルについて知りたい方はこちらを御覧ください。
特にLeSS導入前まで各スクラムチームでPOとチームメンバーが二人三脚で行っていたディスカバリーが、LeSS導入後のPO1人体制で成立するのか、ディスカバリーから得た学びをどうやって複数チームでシェアするかなどです。
当時の結論としてはディスカバリーについて僕たちとして大事にしたいことは言語化した上で、プロセス設計はいったんLeSSをやってみてからチューニングしようとなりました。
当時まとめたドキュメントのディスカバリー部分だけ抜粋して公開します。
実際にLeSSを導入してみると、複数の観点でディスカバリーの難易度は上がりました。このあたりは次回以降のnoteで書く予定です。
苦労した点の2点目は大規模なセレモニーのファシリテーションが成立するかという点です。当時、誰もLeSSをやったことがなかったので、複数チームでのリファインメントや大人数でのスプリントプランニング1などをどのように行うのか想像がつきませんでした。
特に、新しいプロダクトバックログのリファインメントでは3チーム混合でどうやって効率的にリファインメントをするのか悩みました。
ワークショップ設計の本や、LeSSのトレーニングでも学んだ、分散と統合のファシリテーションテクニックをうまく活用しながらリファインメントの場を設計しました。具体的には、3つの混合グループに分けてリファインメントをした後、各チームでまた集まってリファインメント内容をシェアするという形をとりました。
LeSSをやるためには大規模セレモニーのワークショップ設計やファシリテーションテクニックが結構大事になってきます。ファシリテーションを失敗すると、30人の時間が溶けてしまうので、始めは慎重に設計しました。
まとめ
2020年の5月にLeSSを導入してから今日までで59スプリントをこなしています。導入当時は様々な課題も発生していましたが、今ではセレモニーなども随分そつなくこなせるようになりました。
今回はLeSSを導入した経緯について書きました。次回はLeSSを導入して生じた課題について書きたいと思います。ぜひ次回もお楽しみに。
We are hiring!
atama plusはミッション実現のためにメンバーが集まっている会社で、アジャイル開発はミッション実現の有力な手段です。もしよろしければミッション実現のために一緒にトライしませんか？
▼募集職種一覧
▼採用ホームページでもLeSSについての記事を載せていただいています。
いいなと思ったら応援しよう！
