大規模システムScrum実践効果と課題 #rsgt2015

!
⼤大規模システム Scrum 実践
効果と課題
NAKATO ARASE Platform development Division
System Management Group

!
Yahoo! JAPAN!
システム統括本部
プラットフォーム開発本部所属
!
Yahoo!サービスプラットフォーム開発
社内Scrum推進&サポート
認定ScrumMaster
self-introduction
Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

Scrum Support
agenda
PF Scrum Team Level UP Approach
○
○
○ PF Scrum Team

PF Scrum Team
(C) AﬂoCopyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

PF Scrum Team
○1
○2
○3
Yahoo! JAPAN PFとは?
PF Scrum 導⼊入について
PF Scrum 現場レポート

PF Scrum Team
○1 Yahoo! JAPAN PFとは?

約６０サービスのインフラ
○1

！なサービスを⽣生み出す環境作り
○1
(C) Aﬂo

爆速開発の為の環境提供
○1
(C) Aﬂo

爆速開発の為の環境提供
マルチビッグデータ活⽤用基盤
○1
(C) Aﬂo

PF Scrum Team
○2 PF Scrum 導⼊入について

Scrum導⼊入率率率
○2
13%
35%
57%
100%
2013 2014 2015

Scrum導⼊入理理由
○2
80%可視化
脱属⼈人化
⾒見見積もり通りで進まない。
隣隣のチームを⾒見見て。。
数%...

PF Scrum Team
○3 PF Scrum 現場レポート

Team List○3
アプリ⾃自動ビルド・配信チーム○
Yahoo! JAPANが提供する
Android/iOSアプリのコードを
gitリポジトリからダウンロードし
ビルド、⾃自動テスト、配信するシ
ステムを提供

Team List○3
データ監視チーム○
Yahoo! JAPANサービスの
全データ可視化、モニタリング、
横断的に提供

Team List○3
WebAPI管理理チーム○
Yahoo! JAPANが公開・非公開API
の登録・更新等の運用、トラフィッ
クの管理等行っている
Yahoo!デベロッパーネットワーク
http://developer.yahoo.co.jp/

○3
WebAPI管理理チーム○
アプリ⾃自動ビルド・配信チーム○
データ監視チーム○
Team List

アプリ⾃自動ビルド・配信チーム
○3

アプリ⾃自動ビルド・配信チーム○3
Yahoo! JAPANリリース・プロトタイプ含めた
約1300アプリのビルド、テスト、配信を
⼀一括管理理しているシステム
詳細

Yahoo! JAPANのリリース・開発中・プロトタイプ
含めた約1300アプリのビルド、テスト、配信を
⼀一括管理理しているシステム
詳細
⼀一⽇日に約9000回駆動

!SM
エンジニア1名
!PO
兼任エンジニア1名
!開発Team
UXデザイナー2名
エンジニア4名(PO含む)
TEAM 7名
Scrum歴 11ヶ月

WHY!
スタートアップ時はシステム規模も⼩小さく、
少数メンバーでオールカバーできたが、
⼤大規模になるにつれてシステム拡張、UX向上の必要性を感
じ異異なる専⾨門スキルメンバー同⼠士の業務連携に⽀支障が出ると
危惧し始めた。

Changed

Changed
開発の脱属⼈人化
Before
システム拡張する度度にアサインされ
属⼈人化していきました。
担当以外のシステムはわからず進捗、リソースに
偏りがでた。

Changed
Try
acceptance criteriaを明確にし、
SprintPlanning時にやるタスクだけではなく、
やらないタスクも明確にした。

After
やるべきタスク、やらないタスクを明確化する為に
開発Teamで話し合った事により、
ストーリー完了了の為に作業が開発Teamで
共通認識識し、誰でもタスクアサイン
できるようになった。
Changed

Changed
職種を横断したスキルUP
Before
UX、開発と専⾨門スキルが分かれていた為、
各職種のリソースを考慮して⾒見見積もりしていた。

Changed
Try
１ストーリーに必ず
UX/開発誰でも取れる
ユニバーサルタスクを作り
誰でも担当できるように
ルール化した。

After
PBIの並び替えも少しずつですが専⾨門スキルを
考慮せず市場の事を考え並び替えが
できるようになりました。
また、メンバーのスキルの幅も広がり
職種間の引き継ぎコスト、仕様相談、⽅方針決定
MTG等のコストが減りベロシティも安定しました。
Changed

Changed
プロジェクトに対する意識識の向上
Before
プロジェクト初期段階の仕様やスケジュールを
⾒見見直す機会が少なくリリースライン間際で
ピボットやスケジュール変更更していた。
また、開発Teamも全体的な進捗や位置が
把握していなかった。

Changed
Try
SprintPlanning、リファイメントにTEAM全員で!
参加しPOがプロジェクトの方向やスケジュール、!
最優先でやるべきことを説明しTEAMで合議した。

After
プロジェクトの将来や現状の位置確認、⽅方向性が
共有でき、優先事項がTEAMでコンセンサスが取れ
仕様変更更やスケジュール変更更に対しても柔軟に
対応できた。
Changed

Unchanged

Unchanged
ウォータフォールなPBL
Now
案件の規模が⼤大きくリリースまでに⼯工数を要する。
⽬目標が案件ベースで決まってる為、PBIが⼯工程毎に
並んでる。
その為リリースまでの間、利利⽤用者に対して
価値を提供できていない。

規模が⼤大きい!!
IDEAS
BUILD
CODE
MEASURE
DATA
Now
Unchanged
LEARN

当然⼯工数かかる！
IDEAS
BUILD
CODE
MEASURE
DATA
Now
Unchanged
LEARN

回転が遅い。。。
IDEAS
BUILD
CODE
MEASURE
DATA
Now
Unchanged
LEARN

Try
プロジェクトKGI(数値⽬目標)を決め
KPI(⽬目標達成までの指標)を意識識し
PBI作成・リファイメントする
Unchanged

Try
IDEAS
BUILD
CODE
MEASURE
DATA
LEARN
常に意識識したPBI!!
Unchanged
Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

Try
IDEAS
BUILD
CODE
MEASURE
DATA
Scrumでとことん
アジャイル!!
Unchanged
LEARN

Try
IDEAS
BUILD
CODE
MEASURE
DATA
⼩小さく速く！
Unchanged
LEARN

データ監視チーム
○3

データ監視チーム○3
Yahoo! JAPANの全サービス利利⽤用サーバを監視！
詳細

!SM
エンジニア1名
!PO
エンジニア1名
!開発Team
TEAM 7名
Scrum歴 6ヶ月
エンジニア5名
(内リモート作業4名)

WHY!
リモート作業メンバーをアサインすることにり、
異異なる環境で業務していく中でイベントが決まっ
ているScrumはPDCAを回す上で最適と考え
導⼊入した。

Changed
Before
リモートで作業するメンバーのタスクや進捗が
把握しづらくコミュニケーションコストも
かかると思い
可視化

Changed
SprintPlanning Review Retrospectiveを同⽇日に
実施しTEAM全員参加するルールにした。
Try
可視化

Changed
移動コストも削減できタスクによる
進捗報告のため、認識識連れも防げ
管理理コストが下がりました。
After
可視化

Changed
Before
作業環境や役職の都合上、単独アサインせざるを
得ない場⾯面がある
タスクアサイン

Changed
SprintPlanning時、優先度度の⾼高いPBLからSBIに
追加するのですがSBLの2割程度度のストーリーは
権限を考慮し⼊入れ替えた。
Try

Changed
PBLでプロジェクトの全体が把握できている為、
ストーリーの⼊入れ替えが容易易。
また、リソースの偏りもなくせた。
After

Changed
ストーリーアサイン
Before
初期リリースはスピードと品質を優先する為
ある程度度スキルを考慮したアサインに
したいが脱属⼈人化もしたく進め⽅方を試⾏行行錯誤
していた。

Changed
SprintPlanning時にストーリー毎に担当アサイン
かつスキルの幅を徐々に広げる為に未経験スキルを
要するストーリーにも担当アサインした。
Try

Changed
スキルセットに合わせたアサインするので
スピードと品質は担保され、スキル幅も
徐々に広がりました。
After

Changed
Doneの定義
Before
リモート作業メンバーとの品質担保の認識識が
合意取りづらかった。

Changed
タスクの完了了基準をルール化。
リモート環境同⼠士でレビュー完了了後、
⾃自動テストツールをクリアした
タスクのみをDone
Try
Doneの定義

Changed
品質は担保されレビューコストも軽減。
After
Doneの定義

Changed
⾃自⽴立立したTEAM
Before
アサインされたタスクに責任をもってもらいたい
⾃自主的に仕事する⼈人間になってほしい
という願いがある。

Changed
・タスクに理理想時間は書かない。
・直近の優先度度の低いストーリーは⾃自由に着⼿手OK
Try

Changed
開発メンバーのセルフマネージメント向上
タスクに責任を持つ為、課題発⾒見見時、積極的に
相談するようになった。
After

Unchanged

Unchanged
ステークホルダーへの説明
Now
常に変動する中⻑⾧長期⾒見見積もりや成果物に対して
ステークホルダーに説明できていない。
SprintReview時に完了了ストーリーを
説明しても伝わりづらい

エピックを作成しエピックに紐紐づくストーリーが
完了了したらステークホルダーに説明する。
エピックはステークホルダーが理理解できるレベルで
書く(ユーザー価値等)
Try
Unchanged

Try
エピック
ストーリー
ストーリー
ストーリー
分解
Unchanged
ユーザー価値

Try
ストーリー
ストーリー
ストーリー
Done
"#
エピック
Unchanged

○3
WebAPI管理理チーム

Yahoo! JAPANのWebAPI全リクエストを管理理
詳細
○3 WebAPI管理理チーム

詳細
毎⽇日API追加・更更新リリース！！
Yahoo! JAPANのWebAPI全リクエストを管理理

!SM
PO・兼任エンジニア1名
!PO
開発Team・兼任エンジニア6名
!開発Team
エンジニア6名(PO含む)
TEAM 7名
Scrum歴 6ヶ月

WHY!
属⼈人的にプロジェクトを進めていたが担当者が抜ける事に
なり担当システムのメンテナンスが困難になった。
また、プロジェクトの管理理に電⼦子ツールを使っていたが更更
新作業が滞り定期的に管理理する為にScrumを導⼊入した。

Changed

Changed
Before
属⼈人化の為、担当システム以外はわからない
脱属⼈人化

Changed
SBL作成時、
全てのストーリーにレビュータスクと
テストタスクを追加。
Try
脱属⼈人化

Changed
脱属⼈人化
担当外システムを把握でき脱属⼈人化が進んだ。
After

Changed
Before
リリースラインを守れなかった。。。
トレードオフ

Changed
ベロシティからリリースラインまでの⾒見見積もり
を逆算しスケジュール遅延発⽣生時にスコープ、
品質等をトレードオフ。
ベロシティを基にステークホルダーに説明。
Try
トレードオフ

Changed
トレードオフによるリリースライン厳守。
ベロシティを基にした⾒見見積もり説明で
ステークホルダーとスコープコントロールに
ついて合意できた。
After
トレードオフ

Unchanged

Unchanged
Iterativeな開発
Now
プロジェクト初期、ゴールまでの詳細な設計書を
作成したが、変化する仕様に対して設計書の更更新が
追いつかず結果的に成果物と差異異ができ無駄な
ドキュメントができてしまった。
また、ドキュメント作成担当者をコンポーネント毎ア
サインしたためドキュメント粒粒度度や認識識がバラバラ
だった。

Un Changed
ゴールまでの詳細部分を決めてから
作り込むスタイルではなく
⼤大まかな全体像を決めた後TEAMで話を⾏行行い、
作り込みながら詳細を決めるスタイルに
変えていきたい。
(Iterativeな開発スタイルに変更更したい)
!
Try
Iterativeな開発

(C) Aﬂo
retrospective
○ Yahoo! JAPAN PFとは?
○ !なサービスを⽣生み出す為の環境
○ 爆速開発の⽀支援
○ マルチビックデータ活⽤用基盤

(C) Aﬂo
retrospective
○ PFのScrum導入
○ 57%のチームが導⼊入
○ 理理由の80%が“可視化”、”脱属⼈人化”

(C) Aﬂo
retrospective
○ PFのScrum導入
○ 57%のチームが導⼊入
○ 理理由の80%が“可視化”、”脱属⼈人化”
○ PF Scrum 現場レポート
○ aceptance criteriaを明確にする事によるタスク共有
○ 職種を横断したスキルUP
○ チームの意識識改⾰革
○ Iterativeな開発にする為のtry
○ リモート環境メンバーとのコミュニケーション
○ ⾃自⽴立立したチームになるために
○ ステークホルダーの巻き込み⽅方
○ トレードオフの有効活⽤用

PF Scrum Team Level UP
Approach

Switch Scrum !
PF Scrum Masters Night
approach
○1
○2

Switch Scrum
(C) Aﬂo
○1

(C) Aﬂo
○1
PF Scrum TEAMのScrumMasterを
交換する取り組みです。
他チームのScrumを体験することにより
良良いところを⾃自チームに取り⼊入れたり、
改善点をフィードバック！
PF Scrumの全体のLevel UPを期待！
what

(C) Aﬂo
○1
システム同⼠士の連携のきっかけになってほしい
what
慣れないTEAMのScrumを仕切切り
ファシリテーション⼒力力UP
他にも・・・

(C) Aﬂo
○1
how
"
"
"
"
#SM
#SM
#SM
#SM
PF !
Scrum!
TEAM

(C) Aﬂo
○1
how
"
"
"
"
#SM
#SM
#SM
#SM
Daily !
Scrum
PF !
Scrum!
TEAM

(C) Aﬂo
○1
how
#SM
Retrospective
PF !
Scrum!
TEAM
$
"SM

(C) Aﬂo
○1
feedback

(C) Aﬂo
○1
feedback
TaskBoardのレイアウト
Doneのスペースが広くタスクをデイリー毎にまと
めてるのでRetrospective時に作業の流流れが振り返
りやすい。

(C) Aﬂo
○1
feedback
Doing枠が２カ所あり奇数⽇日と偶数⽇日で分けている
ので停滞しているタスクが可視化できる。
odd
even
Doing
TaskBoardのレイアウト
Day 1
odd
even
Doing
Day 2
どうしたの!?
#SM"

(C) Aﬂo
○1
feedback
Planning時タスクとScrum中に追加したタスクを
⾊色を分けて⾒見見積もりのズレを可視化している。
タスクルール
START FIN
緊急、追加、
Invalid etc...
ToDo Done

(C) Aﬂo
○1
feedback
SMファシリテーション
Workng Agreementを守れているか確認し全員が
守れていたら削除し、ルールが増えすぎないよう⼯工
夫していました。
Daily Scrum

(C) Aﬂo
○1
feedback
アイスブレイクを実施して和ませていた。
”今⽇日は何の⽇日”、”英語で朝会”、”クイズ” etc...
Daily Scrum

(C) Aﬂo
○1
feedback
Scrum導⼊入前の課題は解決に向かってるか
確認したました。
Daily Scrum

(C) Aﬂo
○1
feedback
課題に対して深堀するが、⼀一貫してメンバーに話
をさせるスタイルでコーチングできてると感じ
た。
Retrospective

(C) Aﬂo
○1
feedback
課題に対して、
1.なぜ課題に感じたのか？
2.引き起こした原因は何だったのか？
3.解決後のTEAMの状態とは？
4.解決後のTEAMになるために具体的に何をすべきか？
の順番で話されてた。
すぐに対策を話さず、問題を明確、共通認識識するので
対策が課題に対してずれにくい。
Retrospective

(C) Aﬂo
○2

(C) Aﬂo
○2
what
⽇日々Scrumで感じている
課題を参加者で話し合い
解決のきっかけをつくる。
PF Scrumの推進やサポート、
SwitchScrum等の取り組みについて
ざっくばらんに話し改善する。
!
SMN：http://smn.tokyo/

(C) Aﬂo
content
ScrumについてTEAMの温度度感バラバラ？
他にScrum始めそうなチームある？
SwitchScrumでバーンダウンチャートの書き⽅方
知らない⼈人いたけど教えなくていいの？
ScrumMasterは課題に対してどこまで応えればいいん
だろー!?
アイスブレイクいいのない！？
セレモニー⾒見見学してもいい？
PBLの書き⽅方わからないです。。
Scrum上⼿手くいってないけど何が原因かもわからない。。
○2
○
○
○
○
○
○
○
○

(C) Aﬂo
感想
コードで会話するのが好きなPFエンジニアの性上、
軽いアジェンダのほうがざっくばらんに話す
○2
”
“

(C) Aﬂo
action
○2
ScrumについてTEAMの温度度感バラバラ○
⽬目的を明確にし、共有する
可視化したい! →
可視化すると誰に取ってどんな良良い事が有る？
(ステークホルダー!?,チーム!?,プロジェクト!?)
脱属⼈人化したい! →
脱属⼈人化したチームはどうなっている？
TEAMは同じ⽬目的に進めてるか
チェックする事が⼤大事!!

(C) Aﬂo
action
○2
観察し潜在的な課題を⾒見見つけアドバイス
Scrum上⼿手く⾔言ってないけど何が原因かもわからない。。○
Point
複数課題が⾒見見つかっても最優先課題1つ選び、
解決し成功体験をしてもらうこと。
⼩小さい成功体験を積み上げることによる
Scrumへのモチベーションを維持する

(C) Aﬂo
action
○2
⾒見見学会実施
セレモニー⾒見見学してもいい？○

(C) Aﬂo
action
○2
教えました。
○ SwitchScrumでバーンダウンチャートの書き⽅方
知らない⼈人いたけど教えなくていいの？
普段気づかない事も他SMが気づかせてくれます

(C) Aﬂo
感想
ScrumMasterがTEAMに対して常に改善意識識を
持っているTEAMは、
改善を繰り返し⾃自⽴立立したTEAMに向かう
周囲のTEAMにもFeedBackが多い
○2
”
“

(C) Aﬂo
感想
ScrumMaster通しつながりができて、取り組みや
サポートについて協⼒力力してくれて助かる
⾃自⽴立立した組織になりやすい
○2
”
“

(C) Aﬂo
retrospective
○ SwitchScrumの目的、方法
○ ScrumMasterを交換しセレモニーを担当
○ 気付き、学びを得る
○ feedbackし改善のきっかけを与えて上げる
○ feedback
○ taskboardの⼯工夫
○ ScrumMasterのファシリテーション
○ PF Scrum Masters Night
○ ScrumTEAMの温度度感を無くす為には。
○ Scrum上⼿手くいかないけど原因がわからない
○ ⾒見見学会のお話
○ TEAMに対して常に改善意識識を持つ

!
Scrum Support

!
初⼼心者チーム
過去経験者チーム
実践中チーム
○1
○3
○2
category

!
初⼼心者チーム○1

WorkShop!
アジャイル開発における，⾃自⼰己組織化・仕事の量量/仕⽅方に
ついて役割を分担しながら体験してもらう
(C) Aﬂo
○1
what!
why?
Scrumの原理理原則を理理解してもらいたい。

seminar!
what!
why?
○1
Team課題解決にScrumが適しているのか!
確認してもらいたい。
Scrumできること
Scrumできないこと
の説明

practice!
チームがScrumに慣れるまで2∼3Sprint、ScrumMaster担当
○1
Scrumの守破離の守を覚える
why?
what!

!
過去経験者チーム○2

seminar!
Scrum幻想から解放する話
what!
why?
Scrumを⽬目的としないように
Scrumの先にある課題を解決してもう為
○2

(C) Aﬂo
coaching
経験者にScrumMaster担当してもらいScrumイベン
トを後⽅方から参加
what!
why?
Teamで解決できない課題や疑問に対してフォロー
○2

!
実践中チーム○3

Switch Scrum !
○1
○2

一緒にPF Scrum 盛り上げましょ
(C) Aﬂo
everybody
up!!

Scrum Support
retrospective
PF Scrum Team Level UP Approach
○
○
○ Yahoo! JAPAN PF ,Scrum普及率率率
○ PF Scrum TEAMの紹介
○
○
○
○ 57% Scrum実践中
○ 80% 可視化、脱属⼈人化
Changed
○ try
Switch Scrum
○ PF Scrum Masters Night
○
○
初⼼心者チーム
経験者チーム
実践中チーム

大規模システムScrum実践効果と課題 #rsgt2015

More Related Content

What's hot (15)

Viewers also liked (8)

Similar to 大規模システムScrum実践効果と課題 #rsgt2015 (20)

More from Yahoo!デベロッパーネットワーク (20)