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
26k
エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢 / RSGT2025
yoshikiiida
5
10k
ログラスが面白いと思う理由をマネージャーがエモく語ってみる / 20240829 vs LT
yoshikiiida
1
950
質とスピードを両立するログラスのホールチームQA / 20240827 QASaaS_findy
yoshikiiida
2
890
エンジニア組織30人の壁を超えるための 評価システムとマネジメントのスケール / Scaling evaluation system and management
yoshikiiida
12
3.9k
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
yoshikiiida
17
6.6k
ログラスの選考プロセスにおけるアトラクト戦略 / Attraction strategy in Loglass interview process
yoshikiiida
7
3.9k
QA経験のないエンジニアリング マネージャーがQAのカジュアル面談に出て 苦労していること・気づいたこと / scrum fest niigata 2024
yoshikiiida
2
5.9k
ログラスにおけるコード品質でビジネスに貢献する仕組み・カルチャー / 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
空間を設計する力を考える / 20251004 Naoki Takahashi
shift_evolve
PRO
4
440
AI時代こそ求められる設計力- AWSクラウドデザインパターン3選で信頼性と拡張性を高める-
kenichirokimura
3
160
「AI駆動PO」を考えてみる - 作る速さから価値のスループットへ:検査・適応で未来を開発 / AI-driven product owner. scrummat2025
yosuke_nagai
3
760
Access-what? why and how, A11Y for All - Nordic.js 2025
gdomiciano
1
120
スタートアップにおけるこれからの「データ整備」
shomaekawa
2
320
20201008_ファインディ_品質意識を育てる役目は人かAIか___2_.pdf
findy_eventslides
2
560
AI ReadyなData PlatformとしてのAutonomous Databaseアップデート
oracle4engineer
PRO
0
230
AWSにおけるTrend Vision Oneの効果について
shimak
0
140
Modern_Data_Stack最新動向クイズ_買収_AI_激動の2025年_.pdf
sagara
0
230
E2Eテスト設計_自動化のリアル___Playwrightでの実践とMCPの試み__AIによるテスト観点作成_.pdf
findy_eventslides
1
540
SoccerNet GSRの紹介と技術応用:選手視点映像を提供するサッカー作戦盤ツール
mixi_engineers
PRO
1
190
Shirankedo NOCで見えてきたeduroam/OpenRoaming運用ノウハウと課題 - BAKUCHIKU BANBAN #2
marokiki
0
170
Featured
See All Featured
Practical Orchestrator
shlominoach
190
11k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
9
580
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
970
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Automating Front-end Workflow
addyosmani
1371
200k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
189
55k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
It's Worth the Effort
3n
187
28k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
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.