スタートアップが痛みを伴いながらアジャイル開発をスケールした物語〜自律的なチームへの変化〜
こんにちは、atama plusというAI×教育のスタートアップでスクラムマスターをしている河口です。
atama plusでは創業以来アジャイル開発を行っています。1チームから始まり、3チーム、5チームと組織の拡大に伴い「どのようにアジャイル開発をスケールするか」という壁にぶち当たりました。
例えば、チームを細かく分けすぎたことによってチーム間の調整コストが上がったり、局所最適が加速しプロダクトの一体感が失われていったり・・・。
みなさんの組織の中でも、思い当たる節はあるのではないでしょうか？
急激・急速に拡大するスタートアップが、どのように痛みを伴いながらアジャイル開発をスケールしていったのか？
第三回目の今回は、Large Scale-Scrum (以下LeSS) 導入後に起きた課題と、それに対する取り組みや、チームの変化について書きたいと思います。
LeSS導入前後の組織の変遷
第一回目のnoteでもお伝えしましたが、2020年5月まではスクラムチームが3つに分かれていました。
その後、2020年5月からは3つのフィーチャーチームでのLeSSがスタートしました。
さらに、2020年9月に4つ目のチームが、2021年1月に5つ目のチームが発足し、2021年9月時点で5つのフィーチャーチームでLeSSを行っています。
今回は、LeSS導入後に直面した課題と、それに対する取り組み後のチームの変化をご紹介したいと思います。
【課題①】各フィーチャーチームに求められるレベルが上った
LeSS導入以前のスクラムチームが3つのときは、各チームに1人ずつプロダクトオーナーがいて、チームはプロダクトオーナーと二人三脚でプロダクトディスカバリーを行っていました。
※プロダクトディスカバリーとはデュアルトラックアジャイルという開発手法の中で説明されている考え方です。
しかし、LeSS導入後は1人のプロダクトオーナーと複数のフィーチャーチームへ体制が変化したことで、プロダクトオーナーは全体の戦略立案によりフォーカスし、具体的なディスカバリーの計画・実行は今まで以上にチームに委ねるようになりました。
それに伴い、各フィーチャーチームがより自律してプロダクトディスカバリーを行っていく必要が出てきたのです。
また、LeSS導入以前は３種類のペルソナごとにスクラムチームがわかれていたため、チームは担当ペルソナの課題に注力して取り組んでいました。しかし、LeSS導入後はプロダクトバックログを1つに統一することで、各フィーチャーチームの対応領域が広くなり、ペルソナ全体に対しての課題をチームとして取り組むようになりました。
以前に比べ課題領域が広くなったことで、より本質的な課題に取り組むことができる一方、扱う課題の抽象度・複雑度・難易度もぐっと上がりました。
【取り組み①】BX（Business UX）・課題整理トラックの新設
上記の課題に対応するため、アプリチーム内に「BX（Business UX）」という、抽象的な事業課題を整理する役割と、「課題整理トラック」というプロセスを新設し、開発プロセスの整理を行いました。
BX、課題整理トラックの新設については、弊社のプロダクトオーナーが他のnoteでも記載しているので、そちらを御覧ください。
もちろん上記の取り組みだけでなく、各フィーチャーチームも、自律的にプロダクトディスカバリーやデリバリーを進めていく中でチームとして学習し、成長していきました。
以下noteでは、弊社のUXデザイナーがチームでLean UXに取り組んだ話を記事にしています。
【課題②】組織アジリティ向上のための学習コストが果てしない
LeSSに移行して数ヶ月が経った頃、「複数チームプロダクトバックログリファインメント（以下複数チームPBR）が非効率なのでは？」という意見が多数でました。
分析してみると、背景知識の異なる（例：所属チーム、職種、入社時期）メンバーが一同に介してPBIの議論をしようとしても、前提が違いすぎて議論がかみ合わなかったり、正しく見積もれなかったり、といった状況が多発していました。
LeSS導入当初は、複数チームPBRを行えば組織のアジリティは向上すると信じていましたが、見立てが甘かったのです。
LeSSによって特に高められる組織アジリティとは「特定のチームに依存したPBIを減らすことで、スプリントプランニング1において優先したいことを柔軟に変更できる状態」だと思います。
一方で、すべてのPBIをすべてのチームが選択できる状態が良いのか？といった疑問も生まれます。もちろんそれは理想の状態ですが、実現には相応のコストがかかります。
PBIに着手するためには、ビジネス上のドメイン知識、ユーザーについての知識、プロダクトのドメイン知識など、様々なスキル・知識が必要です。すべてのPBIに対してそのスキル・知識を取得するためには、相応の学習コストがかかります。
また、過剰なほど組織アジリティを高く保とうとすると、コストだけが膨らむリスクがあり、ROIを意識した組織アジリティの上げ方（＝アジリティ戦略）が必要になりました。
【取り組み②】リファインメントしやすいところから、徐々に広げていった
LeSS導入当初は、プロダクトディスカバリーのPBI、プロダクトデリバリーのPBIともにとにかく複数チームでリファインメントをしていましたが、まずはプロダクトデリバリーのPBIに限定して複数チームPBRを行うようにしました。
また、背景知識を揃えるためにアプリチーム内のオンボーディングを充実させたり、社歴の長いエンジニアによるシステム仕様のレクチャー会を定期開催したり、学習のためのペアプロをやってみたりと、いろいろな手を使って学習コストを効率的にかけながら組織アジリティを向上するチャレンジをしました。
型を外していくことでみんなが自律的に判断するようになった
LeSS導入当初は、LeSSのガイドに沿って、開発プロセスを型化していたため、複数チームPBRにはメンバー全員が参加必須という意識が強かったのですが、LeSSのプロセスに慣れていくにつれ、複数チームPBRやスプリントプランニング1などイベントへの参加判断をチームに委ねるようにしました。
結果として、各人がそれぞれの場の目的を理解した上で、イベントへの参加判断をするようになり、「複数チームPBRが非効率」といった意見は出なくなりました。
現在では、新しいテーマはプロダクトオーナーが蹴り出してリファインメントを行いますが、継続的なテーマに関しては各チームが必要に応じて関係者を集めて自律的にリファインメントを行うようになっています。
LeSSを導入して14ヶ月経ち、複数チームが連携し始めた
最近では、大きめの機能開発を主導するチームが情報発信をし、他のチームを巻き込み4チームで一気に並列開発を進める良い事例も出始めました。
まだまだ課題は山積みですが、アプリチームメンバーからも「LeSSの良さを活用した動きができてきた」という声も上がっており、LeSSの良さを享受し始めているようです。
まとめ
今回は、LeSSを導入して直面した課題とそれに対する取り組み、自律的なチームへの変化について説明しました。LeSSは導入したらすぐ効果が出るものではなく、LeSSを導入（組織構造を変更する）して初めてスタートラインに立つのだと思います。これからももっとたくさんの課題に直面すると思いますが、実験思考を忘れずにいろいろなチャレンジをしていきたいと思います。
「組織のアジリティは1日にして成らず、だが着実に高めていこう」
atama plusはミッション実現のためにメンバーが集まっている会社で、アジャイル開発はミッション実現の大事な手段です。もしよろしければミッション実現のために一緒にトライしませんか？
▼募集職種一覧
▼採用ホームページでもLeSSについての記事を載せていただいています。
よろしければサポートお願いします！活動費に使わせていただきます！