スクラムの成熟と壁 〜スケーリングの議論から見えたもの〜 / Maturity and barriers in Scrum

「脱！なんちゃってスクラム」実践事例から学ぶ Lunch LT
#スクラム_findy
https://findy.connpass.com/event/324444/

Transcript

1. © 2024 Loglass Inc. スクラムの成熟と壁 〜スケーリングの議論から見えたもの〜 2024.07.29 「脱！なんちゃってスクラム」実践事例から学ぶ Lunch LT
2. © 2024 Loglass Inc. 飯田 意己 株式会社ログラス 開発本部 プロダクト開発部 部長 シニアエンジニアリングマネージャー Profile 2015年に株式会社クラウドワークスに入社。エンジニア、スクラムマス ター、プロダクトオーナーを経て、2019年から執行役員として開発部門 の統括を行う。現在は株式会社ログラスにてソフトウェアエンジニアとし てプロダクト開発に携わったのち、1人目のエンジニアリングマネージャー として事業と組織の成長にコミットしている。 X: @ysk_118 Yoshiki Iida
3. © 2024 Loglass Inc. Loglassについて
4. © 2024 Loglass Inc. Contents 1. なんちゃってスクラムになっているかもしれない事象とその対処 2. ログラスのスクラムの歴史
5. © 2024 Loglass Inc. Contents 1. なんちゃってスクラムになっているかもしれない事象とその対処 2. ログラスのスクラムの歴史 前半は飯田が過去実際に失敗した経験について、 後半は現在のログラスでの取り組みについてお話しします。
6. © 2024 Loglass Inc. 01 なんちゃってスクラムになっているかもしれない 事象とその対処
7. © 2024 Loglass Inc. 事象1: スクラムガイドを読んでいない • 状況 ◦ ネットの記事や書籍ばかりをインプットしており、スクラムガイドを読んでいない ◦ スクラムイベントの目的をチームで考えていない • 対処 ◦ スクラムをやるのであればもっとも簡潔なドキュメントがスクラムガイドとなるため、まずこ れを読む ▪ その他の情報はスクラムガイドを実践するHowと捉えた方が良い ◦ Howをやる前に、スクラムの”考え方”をチームで共有化しよう 01｜なんちゃってスクラムになっているかもしれない事象とその対処
8. © 2024 Loglass Inc. 事象2: 時間効率ばかり意識したファシリテーション • 状況 ◦ 固定のアジェンダで時間内に議論を終わらせる進め方をしている ◦ 進め方をアップデートする余裕がない・視点を持てていない • 対処 ◦ （少なくともファシリテーターが）議論を時間内に終わらせなければいけないという 思考を一度捨てる ◦ 俯瞰してチームの会話をみてスクラムイベントの目的に沿った会話がなされているか？を観 察する ◦ 進め方を試行錯誤し、目的が達成されるようなアジェンダにアップデートする 01｜なんちゃってスクラムになっているかもしれない事象とその対処
9. © 2024 Loglass Inc. 事象2: 時間効率ばかり意識したファシリテーション 01｜なんちゃってスクラムになっているかもしれない事象とその対処
10. © 2024 Loglass Inc. 事象2: 時間効率ばかり意識したファシリテーション 自動車教習所で、「もっとミラーみて！」「もっと周囲みて！」と注意された ことはありますか？私はあります。 目の前だけを見て運転するのではなく、もっと車の周囲を俯瞰して情報処 理しないといけないということですね。 ファシリテーションも時間内に終わらすだけでなく、チームの雰囲気、発言、 会話の中身など、さまざまな情報を俯瞰的にみて最適なやり方を選択す ると言う点では運転と似ているかもしれません。 目の前で起きていることに集中してしまうかもしれませんが、俯瞰する 気持ちの余裕が重要です。 01｜なんちゃってスクラムになっているかもしれない事象とその対処
11. © 2024 Loglass Inc. 事象3: チーム内だけで自分たちはいいチームだと言っている • 状況 ◦ スクラムの考え方も理解して、自分たちなりの進め方もできるようになって、 成果が出てきたぞ！いいチームになってきた！と自分たちだけで言っている • 対処 ◦ 第三者からチームのパフォーマンスについてどう思うかヒアリングしてみる ▪ 社内:マネージャー、ステークホルダーとなる部署の人 ▪ 社外:コミュニティにいる人 ◦ コミュニティに行ったことがないなら、チームがなんちゃってを脱するチャンスかも 01｜なんちゃってスクラムになっているかもしれない事象とその対処
12. © 2024 Loglass Inc. 02 ログラスのスクラムの歴史
13. © 2024 Loglass Inc. チームの変遷 02｜ログラスのスクラムの歴史 • ワンチーム(2020-2021) ◦ スクラム経験者が多く、過去やっていたことを持ち寄って足固めをした • チーム分割(2022-2023) ◦ 人が増えてきてチームを機能領域で分割 ◦ 領域ごとの複雑さの認知負荷をチーム分割することで扱えるようにした • スケーリング(2024-) ◦ 専任スクラムマスターの配置 ◦ 領域横断の開発項目の増加、流動的な人の動きへの対応
14. © 2024 Loglass Inc. ワンチーム(2020-2021) • 認定スクラムマスターを持っているメンバーが複数名いた • ここでの成功体験がその後のチーム分割の下地になるという意識 • お互いの知識・経験を持ち寄り高速に基盤を整えた 02｜ログラスのスクラムの歴史
15. © 2024 Loglass Inc. チーム分割(2022-2023) • プロダクトが大きくなり、人も増え、ワンチームで動きづらくなってきた • 機能領域ごと、新規・既存、などいろいろ観点はあったが、機能領域の複雑性 に対する認知負荷の高まりから、扱う複雑性のスコープを小さくするという観点で機 能領域ごとのチームを編成した • 専任スクラムマスターは置かずにエンジニアが主体となってチーム運営を行った 02｜ログラスのスクラムの歴史
16. © 2024 Loglass Inc. スケーリング(2024-) • 機能領域ごとのチーム分割の課題 ◦ チームを増やしにくい ▪ 機能を細かい単位で分割するか、新しい機能領域を作るしかない ◦ 領域横断の開発を実施する際のチーム間連携のコミュニケーションコスト ▪ 結局全体の複雑性に向き合わなければいけなかった • 高い自律性と組織の流動性を考慮したスケーリングの検討へ ◦ 専任スクラムマスター(@bonotake)の参画 ◦ FASTの検討 ▪ https://www.fast-agile.com/ 02｜ログラスのスクラムの歴史
17. © 2024 Loglass Inc. FASTとは？やログラスがFASTに至った背景は以下をご覧ください https://speakerdeck.com/itohiro73/huitiyakai-fa-kara-horupurodakutokai-fa-he-gu-ke-jia-zhi-hexiang-kihe-isok-kerutiao-zhan-at-itohiro73-number-kai-fa-sheng -chan-xing-con-findy?slide=67 02｜ログラスのスクラムの歴史
18. © 2024 Loglass Inc. 4年の取り組みを振り返って • 初期にスクラムを選択し、知見・経験を持ち寄れたのはよかった ◦ 高速に開発の基盤が構築できた • 認知負荷への対処としてのチーム分割を行ったが、当時は、プロダクトの価値を 考えた時に結局認知負荷と向き合わざるを得ないことが見えていなかった ◦ チームのスコープを小さくコントロールし続けられるならスケーリングを 検討せずとも、複数スクラムチームを育てていくだけでも耐えうる • 自律性の高いスケーリングが実現できるか？がこれからのチャレンジ ◦ 専任スクラムマスターから組織視点のインプットをもらい、 一緒に変革を推進している（めちゃくちゃありがたい） 02｜ログラスのスクラムの歴史
19. © 2024 Loglass Inc.