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
Scrum導入しようとしたら失敗した話
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
dach
July 31, 2019
Technology
800
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Scrum導入しようとしたら失敗した話
dach
July 31, 2019
More Decks by dach
See All by dach
dbt_ベストプラクティス_完全に理解した.pdf
dach
2
1.2k
プロジェクトマネージャーと炎の回避術
dach
0
990
SLO_By_Google_Cloud_Monitoring
dach
0
240
状態遷移テスト完全に理解しよう.pdf
dach
0
900
JWT完全に理解しよう-認証編-.pptx.pdf
dach
0
840
JWT完全に理解しよう-公開鍵編-.pptx.pdf
dach
0
750
チームの垣根を越境する_チーム間交換留学
dach
0
110
設計書のないサービスとの付き合い方.pptx.pdf
dach
0
210
designからWebページを作るやりかた完全に理解した.pdf
dach
1
400
Other Decks in Technology
See All in Technology
KPIだけでは評価できないプロダクトが考えるべき Evalsという第二の評価系 / Beyond KPIs: Evals as a Second Evaluation Framework for Products #PdEConf
aki_iinuma
4
3.7k
AndroidでHDRメディアを「壊さずに」扱う
chigichan24
0
410
プロダクトエンジニアに必要な「いい感じ」に作る能力 〜たくさん作れる時代に、どこまで作るかの決め方〜
jnishime_dresscode
2
1.4k
Bet AI Day 2026丨AIによって本質に戻るシステムリスク管理
layerx
PRO
0
1.1k
Autonomous AI Databaseサービス・アップデート(FY27)/ adb-service-update-jp-fy27
oracle4engineer
PRO
0
120
AI時代に、プロダクトの数だけ積み上がる所有コストをどうエンジニアリングするか / Engineering the Cost of Ownership
kzkmaeda
0
1k
どんな手を使っても絶対間に合わせるスケジューラ
asari194617
0
1.6k
From Vanilla Kubernetes to a Batteries-Included Platform: Developer Experience at 1,300+ Clusters
yosshi_
0
560
「重なり」は迎える側がつくる ― 人もAIエージェントも歓迎するプロダクトエンジニアリング ―
go0517go
PRO
0
250
動画配信アプリでの Engage SDK 導入 — TVer Android が Play ストアにコンテンツを届けるまで
techtver
PRO
0
120
全員がプロダクトへ向き合う組織を持続成長させるために——組織づくりのフライホイールと4象限 / The Flywheel Model and Four Quadrants for Organizational Design
hiro_torii
3
850
Bet AI Day 2026丨Agentは、「金融」という巨大産業の何を変えられるのか
layerx
PRO
0
970
Featured
See All Featured
Building Applications with DynamoDB
mza
96
7.2k
The untapped power of vector embeddings
frankvandijk
2
1.9k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.4k
Six Lessons from altMBA
skipperchong
29
4.5k
From π to Pie charts
rasagy
0
350
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Git: the NoSQL Database
bkeepers
PRO
432
67k
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
230
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3.3k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.5k
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
770
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
370
Transcript
Scrum導入し ようとして失 敗した話 @i-dach 2019/07
Who are you ? qiita: @i-dach Twitter: i-dach github: i-dach
職業 • 現在:カイゼンエンジニア • 将来:カイゼンムキムキエンジニア (トレーニング中) 所属 • DesignOne Japan, inc ◦ DOG主催 / diet部部長 / キックボクシング部部長 ◦ ジェネラリストとしてカイゼン&越境活動 ◦ 設計周りの監修的なこともしてたりします 趣味 • 呼吸法の研究 • エンジニア • DIY(Iot) ←予定 最近熱いもの • O2O
最近頭を悩ませてる問題 表記ゆれ qiita / github 昔からこれ twitter / facebook SNSはこっち
閑話休題
問いかけ
あなたのチームは 「問題を抱えてますか?」
問いかけ
その問題は 「Scrumだったら」 解決すると思いますか?
Thinking
私が得た教訓
「Agileの手法」を入れる前に まず足元を見返した方がいい
ちょっとここで昔話
・オールジャンルの店舗向け口コミサイト ・登録店舗数約465万店舗(2019/07/29)
チームにJoinして問題と直面する • よくあるタスク: ◦ その場の思いつき ◦ ステークホルダーが不在 ◦ なんならPOも不在 ◦
ゴールが存在しない ◦ 効果計測をする指標がない ◦ ドメイン知識の共有がされないとできない ◦ 優先度が決まってない ◦ 計画がない ◦ チームの目標もない ◦ 消化されないで溜まっていく ◦ チームと言うか個人単位でしか動かない
なぜか
10年くらいの歴史あり
とりあえず対応!だから結構負債がある... データが噛み合わない ノイズが多い ステークホルダーがわ からない 燃え尽きてしまう
システム? 文化? 人材? 開発フロー? ドキュメント? 教育? 定義? アーキテクチャ?
どうしようか
考えた結果 ・個人で動くにはこなせる限界がある ・どの問題も最終的にはチームを越境して影響を持たせなくてはならない ・どの問題も認識をすり合わせてやる必要がある リフォームするにもまずはメンバーと一致団結しないと!
まずは「チーム」になろう!
Scrumを入れれば良くなるのでは?
None
Scrum導入初期 チーム • メンバー :2~3 人(SC未経験) • SCM :i-dachが兼任 •
PO :部長 →MGR スクラムイベント 1. スプリント0でキックオフ 2. スプリントプランニング 3. デイリースクラムで毎日情報共有 4. スプリント半ばショーケース 5. スプリントレトロスペクティブ
こんな気分
立ちはだかる壁 1.前のやりかたのゴミが多い 2.飛び込みの別案件が発生した時に勝手に割り込まれる 3.最初にチームとしての方向性を作ってなかったのであんましチーム感ない 4.スピード感が出ないと言われることが増える 5.障害がプランニング日とかに起きるとスプリントが止まる
色々対応してみたが... 1.前のやりかたのゴミが多い → チケットの棚卸しでいらないやつ一括削 2.飛び込みの別案件が発生した時に勝手に割り込まれる → スプリント中に必ず対応すべきものかどうかをPOに判断してもらった 3.最初にチームとしての方向性を作ってなかったのであんましチーム感ない → チームとしての課題を出し合って解決すべき根本を洗い出した
4.スピード感が出ないと言われることが増える → 必要性を解く 5.障害がプランニング日とかに起きるとスプリントが止まる → スプリント期間を延ばしたりして対応
POから反発を受け身動きが取れなくなり
None
None
ちゃんと振り返ろう その場の思いつき ステークホルダーが 不在 POも不在 ゴールが 存在しない 効果計測をする指標 がない ドメイン知識の共有が
されないとできない 優先度が 決まってない 計画がない チームの 目標もない 消化されないで 溜まっていく ここがなぜ存在しないのかを しっかりと考えてから動くべきだった
もし同じチームで次やるとしたら • そもそもこのチームにScrumって向いているのだろうか ◦ 目指すべきゴールはある? ◦ 不確実性との闘い • Scrumを始める前にチームの課題と方向性を決めておくべき •
もしScrumで行こう!となったとしても ◦ Agileってなんだろうということを時間をかけて伝える ◦ POとしての役割をしっかり認識してもらう • 「銀の弾丸」ではないよということをしっかりと伝える
教訓
「Agileの手法」を入れる前に まず足元を見返した方がいい