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
開発チームクエスト
Search
N.Okamoto
February 26, 2019
Technology
0
1.4k
開発チームクエスト
【大阪】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.4k
Other Decks in Technology
See All in Technology
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
26k
rubygem開発で鍛える設計力
joker1007
2
200
生成AIでwebアプリケーションを作ってみた
tajimon
2
150
Navigation3でViewModelにデータを渡す方法
mikanichinose
0
220
Oracle Cloud Infrastructure:2025年6月度サービス・アップデート
oracle4engineer
PRO
2
240
本が全く読めなかった過去の自分へ
genshun9
0
270
エンジニア向け技術スタック情報
kauche
1
250
生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜
itohiro73
0
140
AWS Summit Japan 2025 Community Stage - App workflow automation by AWS Step Functions
matsuihidetoshi
1
260
Welcome to the LLM Club
koic
0
170
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
700
GitHub Copilot の概要
tomokusaba
1
130
Featured
See All Featured
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
5
210
The Cult of Friendly URLs
andyhume
79
6.5k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
930
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Optimizing for Happiness
mojombo
379
70k
The World Runs on Bad Software
bkeepers
PRO
69
11k
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/)