Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Daily Scrum Anti-Patterns
Search
itosho
October 26, 2018
Technology
5
760
Daily Scrum Anti-Patterns
アジャイルひよこクラブ「みんな教えて!!スクラムアンチパターン」でのLT資料です。
itosho
October 26, 2018
Tweet
Share
More Decks by itosho
See All by itosho
【2025年版】インターネットサービスの育て方 / How to Grow and Scale Internet Services 2025
itosho
0
67
Windsurf Rulesでどう自分のクローンをつくるか / How can I make a clone of myself in Windsurf Rules
itosho
0
100
Text EditorとしてのWindsurf / Windsurf as a Text Editor
itosho
0
97
【2024年版】インターネットサービスの育て方 / How to Grow and Scale Internet Services
itosho
0
98
打線組という個人サービスを Goで開発している話 / Indie Service Development by Go
itosho
1
180
Components Reconsidered
itosho
1
2.3k
打線組を支える技術 / The Technology Behind Dasengumi
itosho
0
55
組織をスケールさせるためのTech Vision / Connehito Tech Vision for Growing Our Team
itosho
2
670
生きのびるためのインディー開発 / Indie Development to Survive
itosho
0
51
Other Decks in Technology
See All in Technology
OCI Oracle Database Services新機能アップデート(2025/09-2025/11)
oracle4engineer
PRO
1
210
コンテキスト情報を活用し個社最適化されたAI Agentを実現する4つのポイント
kworkdev
PRO
1
1.5k
CARTAのAI CoE が挑む「事業を進化させる AI エンジニアリング」 / carta ai coe evolution business ai engineering
carta_engineering
0
1.9k
マイクロサービスへの5年間 ぶっちゃけ何をしてどうなったか
joker1007
8
5.1k
re:Invent2025 コンテナ系アップデート振り返り(+CloudWatchログのアップデート紹介)
masukawa
0
380
打 造 A I 驅 動 的 G i t H u b ⾃ 動 化 ⼯ 作 流 程
appleboy
0
350
Database イノベーショントークを振り返る/reinvent-2025-database-innovation-talk-recap
emiki
0
220
大企業でもできる!ボトムアップで拡大させるプラットフォームの作り方
findy_eventslides
1
800
1人1サービス開発しているチームでのClaudeCodeの使い方
noayaoshiro
1
270
生成AI活用の型ハンズオン〜顧客課題起点で設計する7つのステップ
yushin_n
0
230
SSO方式とJumpアカウント方式の比較と設計方針
yuobayashi
7
690
初めてのDatabricks AI/BI Genie
taka_aki
0
200
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Six Lessons from altMBA
skipperchong
29
4.1k
Designing for humans not robots
tammielis
254
26k
The Pragmatic Product Professional
lauravandoore
37
7.1k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.6k
Git: the NoSQL Database
bkeepers
PRO
432
66k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
7.9k
Building an army of robots
kneath
306
46k
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
1
100
YesSQL, Process and Tooling at Scale
rocio
174
15k
Speed Design
sergeychernyshev
33
1.4k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.5k
Transcript
Daily Scrum Anti-Patterns アジャイルひよこクラブ @itosho 1
▪ 自己紹介 ・伊藤 翔 @itosho ・コネヒト株式会社 / Supership株式会社 ・ひよっこスクラムマスター ・兼バックエンドエンジニア
・野球とアイドルが好きです ・最近推しが卒業を発表して哀しい
皆さんはデイリースクラムやってますか? 3
▪ 今日話すこと ・デイリースクラムをやっている人が0人だった場合 ⇒昨日のプロ野球のドラフト会議の話 ・デイリースクラムをやっている人が1人以上いた場合 ⇒デイリースクラムのアンチパターン3選をご紹介
アンチパターン#1 Rush Hour 5
▪ Rush Hourとは? ・デイリースクラムの時間が「柔軟」にずらされること ・ラッシュアワーの電車のように時間通り始まらない ・時間がずれる原因 is… ・(不可抗力により)遅刻するメンバーがいる ・別のMTGがあるメンバーがいる ・よくあるフレーズ「全員揃ったらやりましょ〜」
▪ Rush Hourの問題点 ・柔軟でよさそうにみえてしまうが… ・デイリースクラムは柔軟さよりも「固定」されていることが重要 ・時間が変わるとリズムがつくられない ・ルーティンにすることが大切 ・作業時間が分断される ・生産性が下がるリスクがある 朝会
開発 朝会 10:00 12:00 開発 開発 どちらが効率的か?
▪ Rush Hourのカイゼン策 ・朝にこだわらない ・確実に全員集まれるなら昼会や夕会も検討する ・そもそもなぜ別のMTGが入るのかを確認する ・メンバー/周囲からデイリースクラムの重要性が認知されていない ・デイリースクラムが形骸化している可能性も
▪ Rush Hourを用いてもよい場合 ・プロジェクト序盤や短期プロジェクトの場合 ・リズム/ルーティンよりもチームビルディングを優先したい場合 ・朝にやる必要性はないが、基本的に朝のほうが向いている ・たまになら許容してもよい ・事前にチームメンバーと合意しておくことが大切
アンチパターン#2 Face To Fake 10
▪ Face To Fakeとは? ・対面で集まっているがメンバーの顔をみていないこと ・他のメンバーの話に集中していない ・メンバーの顔をみていない原因 is… ・昨日やったことや今日やることをスマホで確認している ・順番が固定化されている
▪ Face To Fakeの問題点 ・個人作業に陥りやすい ・チームでスプリントバックログを終わらせるという意識がなくなる ・非言語によるサインを見逃してしまう ・体調が悪そうだったり、言いたいことを我慢していそうだったり
▪ Face To Fakeのカイゼン策 ・カンバンにすべてのタスクがあるかを確認する ・スマホをみてしまうのはカンバンにないタスクがある ・カンバンの前に出て、みんなに向かって話す ・発表する順番をランダムにする ・ぬいぐるみやクッションを投げて、次に話す人を決める
▪ Face To Fakeを用いてもよい場合 ・基本的にはない ・まずはデイリースクラムの意義をきちんと全員で理解する ・それでも解決しない場合は… ・オフラインでの開催を検討 ・メンバーが多すぎるかもしれないのでチームを分割する
アンチパターン#3 Share For Share 15
▪ Share For Shareとは? ・共有のための共有 ・ふーん…ってなるだけの行動に結びつかない共有 ・例えば、KPIの数値を毎日共有する ・一朝一夕には数値が変化しない場合 ・チームでコントロールしづらい数値の場合
▪ Share For Shareの問題点 ・やってる感は出るが、実際は何も生まれてない ・組織で「共有が足りない」という声はよく上がる ・その共有が何のアクションに繋がるかはよく考えたほうがよい ・結果的にモチベーションが下がることがある ・共有しているKPIの数値が日々の仕事から遠い場合は要注意 ・更にモチベーションは良くも悪くも伝播しやすい
▪ Share For Shareのカイゼン策 ・アクショナブルではない共有はやめる ・例: 何故それを共有するのかを全員が答えられるようにする ・共有の粒度を変える ・例: KPIであれば、KPIツリーなどでKPIを更に分解する
▪ Share For Shareを用いてもよい場合 ・何らかのアクションや意思決定を促進する共有 ・情報の流通性が低い現場 ・情報がオープンに共有されていること自体は重要 fyi: Netflix社も「share information
openly, broadly, and deliberately」と言っている ・癖を付けたい場合 ・数字を意識させるために、KPIの数値を毎日共有するのはあり ・しかし、それをデイリースクラムで共有するかは考えたほうがよい
まとめ 20
▪ Failure Teaches Success ・デイリースクラムは目的ではなく手段 ・全員がデイリースクラムの目的を理解していることが重要 ・デイリースクラムをやることで何を得たいのか?に答えられるか ・教科書通りにやりすぎない ・組織/現場毎に考慮すべき変数は異なる(アンチパターンも違う) ・教科書通りにやるにしても目的を正しく理解してから
・失敗から学ぶ ・とは言え、やってみなければ分からないことは多い ・失敗を恐れず、日々改善していくことが大切
▪ 参考サイト / 文献 ・デイリースクラムのTIPS (2016年版) ・https://www.ryuzee.com/contents/blog/7083 ・朝会のパターン:立ってるだけじゃないよ ・http://bliki-ja.github.io/ItsNotJustStandingUp/ ・Culture
At Netflix ・https://jobs.netflix.com/culture ・『カンバン仕事術――チームではじめる見える化と改善』 ・https://www.oreilly.co.jp/books/9784873117645/ ・『SCRUM BOOT CAMP THE BOOK』 ・https://www.shoeisha.co.jp/book/detail/9784798129716
23