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
800
エンジニア組織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
AWS re:Inforce 2025 re:Cap Update Pickup & AWS Control Tower の運用における考慮ポイント
htan
1
210
Tableau API連携の罠!?脱スプシを夢見たはずが、逆に依存を深めた話
cuebic9bic
3
210
20250807_Kiroと私の反省会
riz3f7
0
140
Perlアプリケーションで トレースを実装するまでの 工夫と苦労話
masayoshi
1
410
ホリスティックテスティングの右側も大切にする 〜2つの[はか]る〜 / Holistic Testing: Right Side Matters
nihonbuson
PRO
0
580
Google Agentspaceを実際に導入した効果と今後の展望
mixi_engineers
PRO
2
330
AWS DDoS攻撃防御の最前線
ryutakondo
0
110
Claude Codeが働くAI中心の業務システム構築の挑戦―AIエージェント中心の働き方を目指して
os1ma
9
1.5k
データエンジニアがクラシルでやりたいことの現在地
gappy50
3
850
製造業の課題解決に向けた機械学習の活用と、製造業特化LLM開発への挑戦
knt44kw
0
150
LLM開発を支えるエヌビディアの生成AIエコシステム
acceleratedmu3n
0
370
Mambaで物体検出 完全に理解した
shirarei24
2
210
Featured
See All Featured
How to Ace a Technical Interview
jacobian
278
23k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Testing 201, or: Great Expectations
jmmastey
45
7.6k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.8k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
The Cost Of JavaScript in 2023
addyosmani
51
8.7k
Typedesign – Prime Four
hannesfritz
42
2.7k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
19k
4 Signs Your Business is Dying
shpigford
184
22k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
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.