Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スクラムの成熟と壁 〜スケーリングの議論から見えたもの〜 / Maturity and bar...
Search
Yoshiki Iida
July 28, 2024
Technology
4
2k
スクラムの成熟と壁 〜スケーリングの議論から見えたもの〜 / Maturity and barriers in Scrum
「脱!なんちゃってスクラム」実践事例から学ぶ Lunch LT
#スクラム_findy
https://findy.connpass.com/event/324444/
Yoshiki Iida
July 28, 2024
Tweet
Share
More Decks by Yoshiki Iida
See All by Yoshiki Iida
自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ / dev-productivity-con-2025
yoshikiiida
2
23k
エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢 / RSGT2025
yoshikiiida
5
9.4k
ログラスが面白いと思う理由をマネージャーがエモく語ってみる / 20240829 vs LT
yoshikiiida
1
930
質とスピードを両立するログラスのホールチームQA / 20240827 QASaaS_findy
yoshikiiida
2
810
エンジニア組織30人の壁を超えるための 評価システムとマネジメントのスケール / Scaling evaluation system and management
yoshikiiida
12
3.8k
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
yoshikiiida
17
6.5k
ログラスの選考プロセスにおけるアトラクト戦略 / Attraction strategy in Loglass interview process
yoshikiiida
7
3.8k
QA経験のないエンジニアリング マネージャーがQAのカジュアル面談に出て 苦労していること・気づいたこと / scrum fest niigata 2024
yoshikiiida
2
5.7k
ログラスにおけるコード品質でビジネスに貢献する仕組み・カルチャー / A system and culture that contributes to business through code quality in Loglass
yoshikiiida
12
2.5k
Other Decks in Technology
See All in Technology
AIのグローバルトレンド 2025 / ai global trend 2025
kyonmm
PRO
1
140
ロールが細分化された組織でSREと協働するインフラエンジニアは何をするか? / SRE Lounge #18
kossykinto
0
210
LTに影響を受けてテンプレリポジトリを作った話
hol1kgmg
0
360
Claude Codeから我々が学ぶべきこと
oikon48
10
2.8k
金融サービスにおける高速な価値提供とAIの役割 #BetAIDay
layerx
PRO
1
820
形式手法特論:位相空間としての並行プログラミング #kernelvm / Kernel VM Study Tokyo 18th
ytaka23
3
1.3k
LLMでAI-OCR、実際どうなの? / llm_ai_ocr_layerx_bet_ai_day_lt
sbrf248
0
460
Oracle Cloud Infrastructure:2025年7月度サービス・アップデート
oracle4engineer
PRO
1
190
마라톤 끝의 단거리 스퍼트: 2025년의 AI
inureyes
PRO
1
740
Claude Codeは仕様駆動の夢を見ない
gotalab555
23
6.4k
Intro to Software Startups: Spring 2025
arnabdotorg
0
240
AWS re:Inforce 2025 re:Cap Update Pickup & AWS Control Tower の運用における考慮ポイント
htan
1
240
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
183
54k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Adopting Sorbet at Scale
ufuk
77
9.5k
The Pragmatic Product Professional
lauravandoore
36
6.8k
The Invisible Side of Design
smashingmag
301
51k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
6k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
The Cost Of JavaScript in 2023
addyosmani
51
8.8k
Art, The Web, and Tiny UX
lynnandtonic
301
21k
How GitHub (no longer) Works
holman
314
140k
BBQ
matthewcrist
89
9.8k
Writing Fast Ruby
sferik
628
62k
Transcript
© 2024 Loglass Inc. スクラムの成熟と壁 〜スケーリングの議論から見えたもの〜 2024.07.29 「脱!なんちゃってスクラム」実践事例から学ぶ Lunch LT
© 2024 Loglass Inc. 飯田 意己 株式会社ログラス 開発本部 プロダクト開発部 部長
シニアエンジニアリングマネージャー Profile 2015年に株式会社クラウドワークスに入社。エンジニア、スクラムマス ター、プロダクトオーナーを経て、2019年から執行役員として開発部門 の統括を行う。現在は株式会社ログラスにてソフトウェアエンジニアとし てプロダクト開発に携わったのち、1人目のエンジニアリングマネージャー として事業と組織の成長にコミットしている。 X: @ysk_118 Yoshiki Iida
© 2024 Loglass Inc. Loglassについて
© 2024 Loglass Inc. Contents 1. なんちゃってスクラムになっているかもしれない事象とその対処 2. ログラスのスクラムの歴史
© 2024 Loglass Inc. Contents 1. なんちゃってスクラムになっているかもしれない事象とその対処 2. ログラスのスクラムの歴史 前半は飯田が過去実際に失敗した経験について、
後半は現在のログラスでの取り組みについてお話しします。
© 2024 Loglass Inc. 01 なんちゃってスクラムになっているかもしれない 事象とその対処
© 2024 Loglass Inc. 事象1: スクラムガイドを読んでいない • 状況 ◦ ネットの記事や書籍ばかりをインプットしており、スクラムガイドを読んでいない
◦ スクラムイベントの目的をチームで考えていない • 対処 ◦ スクラムをやるのであればもっとも簡潔なドキュメントがスクラムガイドとなるため、まずこ れを読む ▪ その他の情報はスクラムガイドを実践するHowと捉えた方が良い ◦ Howをやる前に、スクラムの”考え方”をチームで共有化しよう 01|なんちゃってスクラムになっているかもしれない事象とその対処
© 2024 Loglass Inc. 事象2: 時間効率ばかり意識したファシリテーション • 状況 ◦ 固定のアジェンダで時間内に議論を終わらせる進め方をしている
◦ 進め方をアップデートする余裕がない・視点を持てていない • 対処 ◦ (少なくともファシリテーターが)議論を時間内に終わらせなければいけないという 思考を一度捨てる ◦ 俯瞰してチームの会話をみてスクラムイベントの目的に沿った会話がなされているか?を観 察する ◦ 進め方を試行錯誤し、目的が達成されるようなアジェンダにアップデートする 01|なんちゃってスクラムになっているかもしれない事象とその対処
© 2024 Loglass Inc. 事象2: 時間効率ばかり意識したファシリテーション 01|なんちゃってスクラムになっているかもしれない事象とその対処
© 2024 Loglass Inc. 事象2: 時間効率ばかり意識したファシリテーション 自動車教習所で、「もっとミラーみて!」「もっと周囲みて!」と注意された ことはありますか?私はあります。 目の前だけを見て運転するのではなく、もっと車の周囲を俯瞰して情報処 理しないといけないということですね。
ファシリテーションも時間内に終わらすだけでなく、チームの雰囲気、発言、 会話の中身など、さまざまな情報を俯瞰的にみて最適なやり方を選択す ると言う点では運転と似ているかもしれません。 目の前で起きていることに集中してしまうかもしれませんが、俯瞰する 気持ちの余裕が重要です。 01|なんちゃってスクラムになっているかもしれない事象とその対処
© 2024 Loglass Inc. 事象3: チーム内だけで自分たちはいいチームだと言っている • 状況 ◦ スクラムの考え方も理解して、自分たちなりの進め方もできるようになって、
成果が出てきたぞ!いいチームになってきた!と自分たちだけで言っている • 対処 ◦ 第三者からチームのパフォーマンスについてどう思うかヒアリングしてみる ▪ 社内:マネージャー、ステークホルダーとなる部署の人 ▪ 社外:コミュニティにいる人 ◦ コミュニティに行ったことがないなら、チームがなんちゃってを脱するチャンスかも 01|なんちゃってスクラムになっているかもしれない事象とその対処
© 2024 Loglass Inc. 02 ログラスのスクラムの歴史
© 2024 Loglass Inc. チームの変遷 02|ログラスのスクラムの歴史 • ワンチーム(2020-2021) ◦ スクラム経験者が多く、過去やっていたことを持ち寄って足固めをした
• チーム分割(2022-2023) ◦ 人が増えてきてチームを機能領域で分割 ◦ 領域ごとの複雑さの認知負荷をチーム分割することで扱えるようにした • スケーリング(2024-) ◦ 専任スクラムマスターの配置 ◦ 領域横断の開発項目の増加、流動的な人の動きへの対応
© 2024 Loglass Inc. ワンチーム(2020-2021) • 認定スクラムマスターを持っているメンバーが複数名いた • ここでの成功体験がその後のチーム分割の下地になるという意識 •
お互いの知識・経験を持ち寄り高速に基盤を整えた 02|ログラスのスクラムの歴史
© 2024 Loglass Inc. チーム分割(2022-2023) • プロダクトが大きくなり、人も増え、ワンチームで動きづらくなってきた • 機能領域ごと、新規・既存、などいろいろ観点はあったが、機能領域の複雑性 に対する認知負荷の高まりから、扱う複雑性のスコープを小さくするという観点で機
能領域ごとのチームを編成した • 専任スクラムマスターは置かずにエンジニアが主体となってチーム運営を行った 02|ログラスのスクラムの歴史
© 2024 Loglass Inc. スケーリング(2024-) • 機能領域ごとのチーム分割の課題 ◦ チームを増やしにくい ▪
機能を細かい単位で分割するか、新しい機能領域を作るしかない ◦ 領域横断の開発を実施する際のチーム間連携のコミュニケーションコスト ▪ 結局全体の複雑性に向き合わなければいけなかった • 高い自律性と組織の流動性を考慮したスケーリングの検討へ ◦ 専任スクラムマスター(@bonotake)の参画 ◦ FASTの検討 ▪ https://www.fast-agile.com/ 02|ログラスのスクラムの歴史
© 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|ログラスのスクラムの歴史
© 2024 Loglass Inc. 4年の取り組みを振り返って • 初期にスクラムを選択し、知見・経験を持ち寄れたのはよかった ◦ 高速に開発の基盤が構築できた •
認知負荷への対処としてのチーム分割を行ったが、当時は、プロダクトの価値を 考えた時に結局認知負荷と向き合わざるを得ないことが見えていなかった ◦ チームのスコープを小さくコントロールし続けられるならスケーリングを 検討せずとも、複数スクラムチームを育てていくだけでも耐えうる • 自律性の高いスケーリングが実現できるか?がこれからのチャレンジ ◦ 専任スクラムマスターから組織視点のインプットをもらい、 一緒に変革を推進している(めちゃくちゃありがたい) 02|ログラスのスクラムの歴史
© 2024 Loglass Inc.