Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
開発チームクエスト
Search
N.Okamoto
February 26, 2019
Technology
0
1.5k
開発チームクエスト
【大阪】RAKUS Meetup Osaka #2 アジャイル Night
N.Okamoto
February 26, 2019
Tweet
Share
More Decks by N.Okamoto
See All by N.Okamoto
meetup_20210608_roum
ygno
0
1.5k
Other Decks in Technology
See All in Technology
Databricks向けJupyter Kernelでデータサイエンティストの開発環境をAI-Readyにする / Data+AI World Tour Tokyo After Party
genda
1
520
生成AI時代におけるグローバル戦略思考
taka_aki
0
200
Challenging Hardware Contests with Zephyr and Lessons Learned
iotengineer22
0
230
NIKKEI Tech Talk #41: セキュア・バイ・デザインからクラウド管理を考える
sekido
PRO
0
130
MLflowダイエット大作戦
lycorptech_jp
PRO
1
140
AWS re:Invent 2025で見たGrafana最新機能の紹介
hamadakoji
0
400
寫了幾年 Code,然後呢?軟體工程師必須重新認識的 DevOps
cheng_wei_chen
1
1.4k
re:Invent2025 3つの Frontier Agents を紹介 / introducing-3-frontier-agents
tomoki10
0
230
モダンデータスタック (MDS) の話とデータ分析が起こすビジネス変革
sutotakeshi
0
500
5分で知るMicrosoft Ignite
taiponrock
PRO
0
390
EM歴1年10ヶ月のぼくがぶち当たった苦悩とこれからへ向けて
maaaato
0
280
20251218_AIを活用した開発生産性向上の全社的な取り組みの進め方について / How to proceed with company-wide initiatives to improve development productivity using AI
yayoi_dd
0
100
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.8k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
YesSQL, Process and Tooling at Scale
rocio
174
15k
Rails Girls Zürich Keynote
gr2m
95
14k
BBQ
matthewcrist
89
9.9k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.1k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Typedesign – Prime Four
hannesfritz
42
2.9k
jQuery: Nuts, Bolts and Bling
dougneiner
65
8.3k
[SF Ruby Conf 2025] Rails X
palkan
0
540
Transcript
開発チームクエスト RAKUS Meetup Osaka #2 アジャイルNight 2019.2.26
• 岡本 直樹 • 2016年入社 • 担当商材 自己紹介 ちから: 10
すばやさ: 15 こうげきりょく: 28 しゅびりょく: 30 ---------------------- ぶき: Swiftのつるぎ よろい: Javaのよろい たて: Gradleのたて つよさ うぉーきんぐ ぱそこんいじり あにめ げーむ えいが しゅみ
楽楽精算開発チームがスクラムを開始して1年 1年の間にチームに起こった出来事とその対処について 振り返ってみようと思います。 今日のテーマ
iPhoneアプリ開発のため スクラムチーム発足
~チームの状況~ • 課題 ー ベテラン勢と若手の Lv差が顕著であり、若手 がタスクをこなすにはベテランのフォローが 不可欠。 ー チームメンバー全員が
iPhoneアプリの開発経 験なし。 Lv68:ベテラン Lv67:ベテラン Lv61:ベテラン Lv60:派遣 Lv20:若手 Lv17:若手 【Lvの目安】 Lv60以上:「下位メンバーのフォローが可能」 Lv50以上:「通常タスクが実施可能」 Lv30以上:「フォローありで通常タスクが実施可能」 Lv30未満:「フォローありで低難易度タスクが実施可能」
~取入れた作戦~ • ベテランによるタスクの詳細化 ー ベテラン勢と若手の間で、 遂行できるタスクの難易度にバラツキがあった ため、 スプリント開始前に ベテランがタスクを検討 し、能力に応じて各メンバーに割り当てるようにした。
▶こうげき じゅもん ぼうぎょ どうぐ ▶ろぐいんしょり がめんせんい ゆにっとてすと きーにゅうりょく APIりくえすと
~取入れた作戦~ • 役割分担による各個撃破 ー メンバーの役割をサーバサイド/アプリサイドで分け、担当者が 各領域のタスクに専念 できるように した。 AppSide ServerSide
~取入れた作戦~ • スプリントの2週間サイクル ー iPhoneアプリの作成は未経験分野であり、 1週間毎にアウトプットを出せるイメージを持てなかった ので、まずは2週間サイクルでスプリントを開始した。 HP: 50000/50000 ちから:
16 すばやさ: 20 こうげきりょく: 75 しゅびりょく: 80 ---------------------- ぶき: Javaのつるぎ よろい: DDDのよろい たて: スクラムのたて つよさ 挑む敵が強大で1週間程度ではダメージを与えられるイメージがなかった
ベテランの離脱と新規メンバーの加入
~チームの状況~ • 課題 ー ベテランの離脱と新規メンバーの加入により フォローする側とされる側の比率が 1:1 と なりフォロー体制に若干の不安が出てきた。 ー
iPhoneアプリの2次開発で、既存サービスとの機 能統合が決まり、1次開発と比べ考慮すべき仕様 が増えた。 Lv78:ベテラン Lv71:ベテラン Lv70:派遣 Lv21:若手 Lv18:若手 Lv40:派遣 【Lvの目安】 Lv60以上:「下位メンバーのフォローが可能」 Lv50以上:「通常タスクが実施可能」 Lv30以上:「フォローありで通常タスクが実施可能」 Lv30未満:「フォローありで低難易度タスクが実施可能」
~取止めた作戦~ • 役割分担による各個撃破 ー 以下2点の問題が発生し継続は不要と判断。 ・iPhoneアプリの2次開発で、既存 Webサービスとの統合を行うことになり、仕様のすり合わせを密に 行う必要が出てきたため、アプリサイドとサーバサイドで 役割を分ける意味合いが薄くなった 。
・ベテラン1名がチームから離脱してしまったため、 役割分担をするためのリソースが不足 してしまっ た。
~取入れた作戦~ • 開発内リファインメント会議 ー 2次開発で 複雑さを増した仕様に対応 するため実施。 ベテラン勢が仕様検討に時間を割けるように、スプリント毎に1回 MTG形式で行う。 ▶さくせん
こうげき じゅもん ぼうぎょ どうぐ ▶めいれいさせろ いのちをだいじに みんながんばれ じゅもんをつかうな がんがんいこうぜ 稼働に無駄が発生しないように、まずはベテラン勢で仕様を決定する。 Complex specification
さらなるメンバーの増員
~チームの状況~ • 課題 ー 新規メンバーの加入により、フォローする側 とされる側の比率が 3:5で不均衡な状態。 ー 恒常的にベテランがフォローに時間を取られ ることにより、タスクの消化速度の悪化がし
てしまった。 Lv83:ベテラン Lv76:ベテラン Lv75:派遣 Lv22:若手 Lv19:若手 Lv45:派遣 Lv45:派遣 Lv45:中堅 【Lvの目安】 Lv60以上:「下位メンバーのフォローが可能」 Lv50以上:「通常タスクが実施可能」 Lv30以上:「フォローありで通常タスクが実施可能」 Lv30未満:「フォローありで低難易度タスクが実施可能」
~取止めた作戦~ • スプリントの2週間サイクル ー メンバーの増加によって、スプリント計画時に洗い出さなければならない タスク量が飛躍的に増加 これにより、主にタスクの洗い出しを担当していたベテラン勢が疲弊してしまった。 スプリントの サイクルを1週間に縮めて相対的に計画タスクを少なく することで解決。
~変更した作戦~ • ベテランによるタスクの詳細化 ー これまではベテランがタスクを詳細化してから下位メンバーに割り当てるという手法をとっていた が、メンバーが増え、 情報伝達のオーバーヘッドが無視できないほど大きくなった ため、タスクの詳 細化自体をペアワークで実施 するようにした。
Sprint Backlog Item ベテランと わかて の ペアワークれんけい!
~取入れた作戦~ • モブプロの実践 ー メンバー間の 知識格差が目立ってきたた め、これを 埋める手法 として試験的に導入。 まずは、小粒なタスクを切り出して、効果を見極めることにした。
1つのタスクに全員で取り掛かる Small Tasks
ベテランの離脱と新卒加入
~チームの状況~ • 課題 ー フォローする側とされる側の比率が 2:5でか なり不均衡な状態になってしまた。 ー ベテラン勢の人数が下位メンバーに対して不 足しているため、フォローが行き届かず、タ
スクをこなすこと自体が困難になってしまっ た。 Lv80:ベテラン Lv79:派遣 Lv23:若手 Lv20:若手 Lv47:派遣 Lv48:中堅 Lv15:新卒 【Lvの目安】 Lv60以上:「下位メンバーのフォローが可能」 Lv50以上:「通常タスクが実施可能」 Lv30以上:「フォローありで通常タスクが実施可能」 Lv30未満:「フォローありで低難易度タスクが実施可能」
~取入れた作戦~ • チームの分割 ー 下位メンバーをフォロー可能な人員が減ってしまったため、 全メンバー一律のフォローは一旦諦め 、 ベテラン/中堅のチームと若手 /新卒のチームにメンバーを分け、それぞれのチームの上位メンバーが 下位メンバーのフォローを担当するようにした。
Training Mission Main Mission
~変更した作戦~ • 開発内リファインメント会議 ー 当初は、無駄な稼働をかけないため ベテラン勢のみで行っていた仕様検討会議だったが、 不要に知識の分断を招いた だけだったので、原則全員参加に変更。 ▶さくせん こうげき
じゅもん ぼうぎょ どうぐ めいれいさせろ いのちをだいじに ▶みんながんばれ じゅもんをつかうな がんがんいこうぜ
~変更した作戦~ • モブプロの実施 ー 試験的に導入していたモブプロを以下の要領で、本格的にプロジェクトに組込む。 ・スプリントの最終日の午後に実施。 ・題材は基本的にリファクタリング。 ・モブプロの時間を使って当該スプリントで発生した各プルリクの共有を実施。
~取止めた作戦~ • ベテランによるタスクの詳細化 ー ベテランの人数が減ってしまったため、 メンバー毎にタスクを詳細化することが難しくなった 。 そこで、タスクの詳細化をモブワークで実施 、全員でタスクの詳細化に取り組み、フォロー稼働削減 を目指した。
Sprint Backlog Item ベテランチーム の モブワークれんけい!
1年を振り返って
最も悪かった作戦 • ベテランによるタスクの詳細化 ー ベテランの稼働圧迫、知識伝達のオーバーヘッド、知識格差の拡大と、百害あって一利もなかった。 そもそも、この作戦は「 ベテランが仕様を決める →下位メンバーが実行する 」の流れのほうが 稼働が
有効に使えるというウォーターフォール的発想 により決められていた節があり、スクラムの思想に合 致していなかった。
最も良かった作戦 • モブプロ/モブワークの実践 ー 知識の共有化 、プログラミング思想の統一 、タスク内容の全体周知 と色々な面で活用することがで きた。また、結果として「ベテランによるタスクの詳細」により起こっていた、フォローされる側/ する側というチームの分断が解消でき、
お互いをフォローし合えるチーム を目指せるようになった。 LvXX:ベテラン LvXX:派遣 LvXX:派遣 LvXX:中堅 LvXX:若手 LvXX:若手 LvXX:新卒 DifficultTasks
Our battle is about to come.
素材 • RPGドット(http://www.geocities.co.jp/Milano-Cat/3319/)