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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2024 Loglass Inc. 飯田意己株式会社ログラス開発本部プロダクト開発部部長シニアエンジニアリングマネージャー Profile 2015年に株式会社クラウドワークスに入社。エンジニア、スクラムマスター、プロダクトオーナーを経て、2019年から執行役員として開発部門の統括を行う。現在は株式会社ログラスにてソフトウェアエンジニアとしてプロダクト開発に携わったのち、1人目のエンジニアリングマネージャーとして事業と組織の成長にコミットしている。 X: @ysk_118 Yoshiki Iida

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© 2024 Loglass Inc. 事象1: スクラムガイドを読んでいない ● 状況 ○ ネットの記事や書籍ばかりをインプットしており、スクラムガイドを読んでいない ○ スクラムイベントの目的をチームで考えていない ● 対処 ○ スクラムをやるのであればもっとも簡潔なドキュメントがスクラムガイドとなるため、まずこれを読む ■ その他の情報はスクラムガイドを実践するHowと捉えた方が良い ○ Howをやる前に、スクラムの”考え方”をチームで共有化しよう 01｜なんちゃってスクラムになっているかもしれない事象とその対処

Slide 8

Slide 8 text

© 2024 Loglass Inc. 事象2: 時間効率ばかり意識したファシリテーション ● 状況 ○ 固定のアジェンダで時間内に議論を終わらせる進め方をしている ○ 進め方をアップデートする余裕がない・視点を持てていない ● 対処 ○ （少なくともファシリテーターが）議論を時間内に終わらせなければいけないという思考を一度捨てる ○ 俯瞰してチームの会話をみてスクラムイベントの目的に沿った会話がなされているか？を観察する ○ 進め方を試行錯誤し、目的が達成されるようなアジェンダにアップデートする 01｜なんちゃってスクラムになっているかもしれない事象とその対処

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2024 Loglass Inc. 事象2: 時間効率ばかり意識したファシリテーション自動車教習所で、「もっとミラーみて！」「もっと周囲みて！」と注意されたことはありますか？私はあります。目の前だけを見て運転するのではなく、もっと車の周囲を俯瞰して情報処理しないといけないということですね。ファシリテーションも時間内に終わらすだけでなく、チームの雰囲気、発言、会話の中身など、さまざまな情報を俯瞰的にみて最適なやり方を選択すると言う点では運転と似ているかもしれません。目の前で起きていることに集中してしまうかもしれませんが、俯瞰する気持ちの余裕が重要です。 01｜なんちゃってスクラムになっているかもしれない事象とその対処

Slide 11

Slide 11 text

© 2024 Loglass Inc. 事象3: チーム内だけで自分たちはいいチームだと言っている ● 状況 ○ スクラムの考え方も理解して、自分たちなりの進め方もできるようになって、成果が出てきたぞ！いいチームになってきた！と自分たちだけで言っている ● 対処 ○ 第三者からチームのパフォーマンスについてどう思うかヒアリングしてみる ■ 社内:マネージャー、ステークホルダーとなる部署の人 ■ 社外:コミュニティにいる人 ○ コミュニティに行ったことがないなら、チームがなんちゃってを脱するチャンスかも 01｜なんちゃってスクラムになっているかもしれない事象とその対処

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 2024 Loglass Inc. チームの変遷 02｜ログラスのスクラムの歴史 ● ワンチーム(2020-2021) ○ スクラム経験者が多く、過去やっていたことを持ち寄って足固めをした ● チーム分割(2022-2023) ○ 人が増えてきてチームを機能領域で分割 ○ 領域ごとの複雑さの認知負荷をチーム分割することで扱えるようにした ● スケーリング(2024-) ○ 専任スクラムマスターの配置 ○ 領域横断の開発項目の増加、流動的な人の動きへの対応

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 2024 Loglass Inc. チーム分割(2022-2023) ● プロダクトが大きくなり、人も増え、ワンチームで動きづらくなってきた ● 機能領域ごと、新規・既存、などいろいろ観点はあったが、機能領域の複雑性に対する認知負荷の高まりから、扱う複雑性のスコープを小さくするという観点で機能領域ごとのチームを編成した ● 専任スクラムマスターは置かずにエンジニアが主体となってチーム運営を行った 02｜ログラスのスクラムの歴史

Slide 16

Slide 16 text

© 2024 Loglass Inc. スケーリング(2024-) ● 機能領域ごとのチーム分割の課題 ○ チームを増やしにくい ■ 機能を細かい単位で分割するか、新しい機能領域を作るしかない ○ 領域横断の開発を実施する際のチーム間連携のコミュニケーションコスト ■ 結局全体の複雑性に向き合わなければいけなかった ● 高い自律性と組織の流動性を考慮したスケーリングの検討へ ○ 専任スクラムマスター(@bonotake)の参画 ○ FASTの検討 ■ https://www.fast-agile.com/ 02｜ログラスのスクラムの歴史

Slide 17

Slide 17 text

© 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｜ログラスのスクラムの歴史

Slide 18

Slide 18 text

© 2024 Loglass Inc. 4年の取り組みを振り返って ● 初期にスクラムを選択し、知見・経験を持ち寄れたのはよかった ○ 高速に開発の基盤が構築できた ● 認知負荷への対処としてのチーム分割を行ったが、当時は、プロダクトの価値を考えた時に結局認知負荷と向き合わざるを得ないことが見えていなかった ○ チームのスコープを小さくコントロールし続けられるならスケーリングを検討せずとも、複数スクラムチームを育てていくだけでも耐えうる ● 自律性の高いスケーリングが実現できるか？がこれからのチャレンジ ○ 専任スクラムマスターから組織視点のインプットをもらい、一緒に変革を推進している（めちゃくちゃありがたい） 02｜ログラスのスクラムの歴史