株式会社ディー・エヌ・エー 貝瀬 岳志

Scrumで変わる組織

自己紹介• SIer、ゲームポータルサイトを経てディー・エヌ・エーに

•主にMobageのコミュニティ領域を担当

• 2011年夏、自部門にスクラムの導入を開始

• 2011年秋、認定スクラムマスター取得

ToDo 進行中 完了

導入のきっかけ

8

導入の実例

20

導入の結果 3

ToDo 進行中 完了

導入のきっかけ 8

導入の実例

20

導入の結果 3

我々がなぜスクラムを導入したのか？

Why do we Scrum?

背景

•急成長するスマートフォン業界

•急拡大する組織

•スピーディな意思決定と施策の実施

課題認識 (経営陣)

•アウトプットや業務進行のクオリティ・スピードが上がっていない

•人が増えても意味のあるアウトプットが増えていない

•新しいアプローチやスケールする取り組みがない

課題認識 (メンバー)

•いつまでたっても「やるべきこと」が多い

•やっていることの背景・位置づけがよくわからない

•先を見通す余裕がない

•周囲のやっていることが分からない

•課題・問題は認識できているが変えるに至らない

課題認識 (マネージャー)

•経営陣、現場の課題を解決したい

•自己成長型の組織にしたい

解決すべき課題

•困難なスケジューリング

•不明確な責任範囲

•放置された問題・課題

Why scheduling is difficult?

なぜスケジューリングは困難なのか？

Why : なぜスケジューリングは困難なのか

Because : 突発、緊急の案件が多い

Why : なぜ突発、緊急の案件が多いのか

Because : 状況を見渡せていない

Why : なぜ状況を見渡せていないのか

Because : 目の前のタスクに追われている

Why : なぜ目の前のタスクに追われているのか

Because : やらなければいけないことが多すぎる

Why : なぜやらなければいけないことが多すぎるのか

Because : 優先順位の認識が人によってバラバラ

How : どうすれば適切な優先順位を全体で共有し続けることができるのか？

Why responsibility isn't clear?

なぜ責任の所在が不明確なのか？

Why : なぜ責任の所在が不明確なのか

Because : 他人、他組織の責任を理解していない

Why : なぜ他人、他組織の責任を理解していないのか

Because : 可視化が不十分

Why : なぜ可視化が不十分なのか

Because : 事業拡大にともない人や組織の役割や責任が頻繁に変わる

How : どうすれば頻繁に変わる組織に合わせて責任範囲と役割を共有することができるのか？

Why problem is left uncontrolled?

なぜ課題・問題が放置されているのか？

Why : なぜ課題・問題が放置されているのか

Because : 目先の仕事を優先してしまう

Why : なぜ目先の仕事を優先してしまうのか

Because : 期日、アウトプット、価値がわかりやすく取り組みやすい

How : ではどうすれば課題や問題に対しても真剣に向き合うことができるのか？

解決すべき課題（再掲）

•困難なスケジューリング

•不明確な責任範囲

•放置された課題・問題

解決のアプローチ

困難なスケジューリング

ー＞ 適切に優先順位をつけられる仕組み

解決のアプローチ

不明確な責任範囲

ー＞ 役割の可視化とそれを果たすマインド形成

解決のアプローチ

放置された課題・問題

ー＞課題の抽出、実行、評価を回し続ける一定のサイクル

Why do we Scrum?我々がなぜスクラムを導入したのか？

Because Scrum might be able to solve theseスクラムでこれらの課題を解決できそうだった

ToDo 進行中 完了

導入のきっかけ 8

導入の実例

20

導入の結果 3

我々がどのようにスクラムを行っているのか？

How do we Scrum?

ToDo 進行中 完了

導入のきっかけ 8

導入の実例

20

導入の結果 3

ToDo 進行中 完了

導入のきっかけ 8

導入の実例Phase1 5

導入の結果 3

導入の実例Phase2 5

導入の実例Phase3 5

スクラムとは 2

ToDo 進行中 完了

導入のきっかけ 8

導入の実例Phase1 5

導入の結果 3

導入の実例Phase2 5

導入の実例Phase3 5

スクラムとは 2

What is Scrum?スクラムとは何か

PO

SM

Team

スクラムとは

• 3つの役割

• 3つのツール

• 4つの会議

3つの役割

•プロダクトオーナー

•スクラムマスター

•チーム

3つのツール

•プロダクトバックログ

•スプリントバックログ

•バーンダウンチャート

4つの会議

•スプリント計画

•デイリーStandUp

•スプリントレビュー

•ふりかえり

ToDo 進行中 完了

導入のきっかけ 8

導入の実例Phase1 5

導入の結果 3

導入の実例Phase2 5

導入の実例Phase3 5

スクラムとは 2

Phase1：Try Scrumスクラムトライアル

導入したプロジェクト

• SP版Mobageのリニューアルプロジェクト

• UI設計を海外、実装を日本で実施

•若手の専任メンバーで構成

チーム•海外

• SM×1、IA×2、グラフィック×2、その他×2

•日本

• PO×1、SM×1、エンジニア×4～6、マークアップ×2、グラフィック×1～2）

•最大約20名

会議•朝会（日本のメンバー全員）

•夜会（海外のメンバー＋一部の日本メンバー）

•プレプランニング（海外のメンバー＋一部の日本メンバー）

•プランニング（全員）

•レビュー（全員）

•ふりかえり（全員）

ツール• Basecamp

•日本・海外のバックログ管理

•ホワイトボード＆付箋

•スプリントバックログの見える化

• JIRA

•バックログの蓄積

Anyway we gave it a try...

とりあえずやってみた...

Retrospectiveチームのふりかえり（スクラムに関するもののみ抜粋）

Keep（続けたいこと）

企画者、開発者、デザイナーの席を近づける

Problem（問題）経験不足で立ち上げにもたついた

Planningでコミットしたストーリーをレビューできないことが多かった

モックー>レビューー>インプット反映のサイクルが回らない

ウォーターフォールっぽくなる部分が多く後ろの工程がつまる

時差の問題で指摘事項の反映・確認に手間取った

海外とのコミュニケーションがとりづらくストレスがたまった

バーンダウンチャートがバーンダウンしない

途中から朝会がグダグダに

準備期間を設ける（Sprint0のToDo整理と実施）

できないことはできないという

海外と場所を一箇所に固める

企画、デザイン素案はSprintが始まる前に終わらせる

ストーリーの粒度をみなおす

人数、チームを適切に構成

Try（改善したいこと）

Retrospective導入のきっかけとなった課題に対してのふりかえり

困難なスケジューリング＋ スプリント単位で優先順位を合意でき、突発案件が減った

＋ 日々の差し込み、問題を共有でき、優先順位の調整ができた

Δ 動作可能なソフトウェアでレビューはできたが「完了」しない

Δ スクラム外からの差し込みには対応せざるを得なかった

Δ いつまでたってもリリースできる品質にならない

Δ 会議、ツールがうまく機能していない

不明確な責任範囲＋ プロジェクト内部では責任の所在が明文化された

＋ レビューに向けてチーム一丸となって取り組めた

Δ POが意思決定できない状況、SMが問題解決できない状況が発生した

放置された問題・課題＋ ふりかえりを使って問題提起、改善のサイクルが回り始めた

＋ 他のメンバーを助け合う体制・マインドが構築できた

Δ 大きな問題ほど先延ばしになった

Δ バックログは増えたもののなかなか消化できない

Phase1 : SummaryPhase1まとめ

まとめ•問題の可視化、共有が可能

•スプリントを繰り返す毎にチームは成長

•スクラムの難しさを実感

• 3つの課題を解決する可能性

ToDo 進行中 完了

導入のきっかけ 8

導入の実例Phase1 5

導入の結果 3

導入の実例Phase2 5

導入の実例Phase3 5

スクラムとは 2

Phase2：Expand Scrumスクラム拡大

導入した組織

• SP版Mobageの運用を担当する企画部門と開発部門

•短期間で企画から開発まで行うものが多い

•これまでやってきたことをスクラムにあてはめてみる試み

Phase1からの教訓

•企画者、開発者を一箇所に集める

•人数、チームを適切に構成

•スクラム実施前の準備期間（Sprint0）

•ツールの整備

チーム•ミッションごとに構成された4つのチーム

• PO、SM、メンバーを各チームに配置

• PO、SMはチームごとに1人

•各チームは最大でも10名以内

•メンバーは他チームと兼任しない

ツール• JIRA

•バックログ管理と蓄積をJIRAに集約

•プランニングポーカー、付箋、ホワイトボード、スケッチブック

•ふりかえりやプランニング時の補助ツール

• GoogleApps

• JIRAでカバーできない範囲の見える化を補助

Sprint0のテンプレート•ミッションの明確化

•責任範囲の明確化

•役割の明確化

•優先順位の明確化

•ストーリー抽出

•プロダクトバックログの作成

• Doneの定義

• Sprint1用バックログの作成

•ツールの整備

We tried again...再びやってみた...

Retrospectiveふりかえり

困難なスケジューリング＋＋ スプリント単位で優先順位を合意でき、突発案件が減った

＋＋ 日々の差し込み、問題を共有でき、優先順位の調整ができた

Δ 動作可能なソフトウェアでレビューはできたが「完了」しない

Δ スクラム外からの差し込みには対応せざるを得なかった

Δ 単にタスクをストーリー化しているだけでやりたいことができていない

不明確な責任範囲＋＋ プロジェクト内部では責任の所在が明文化された

＋ 4チームの間で責任範囲が明確になった

＋ マネージャーのボトルネックが解消された

＋ レビューに向けてチーム一丸となって取り組めた

ΔΔ POが意思決定できない状況、SMが問題解決できない状況が発生した

放置された問題・課題＋＋ ふりかえりを使って問題提起、改善のサイクルが回り始めた

＋＋ 他のメンバーを助け合う体制・マインドが構築できた

ΔΔ 大きな問題ほど先延ばしになった

Δ バックログが増える一方で、リリースするまでに時間がかかった

Δ バックログが増えない

Δ ふりかえりをはじめとする会議に否定的なチームががでてきた

Phase2 : SummaryPhase2まとめ

まとめ•スクラムの理解が浅いまま実施することの逆効果

•スクラムだけでは解決しきれない問題

•問題の可視化、チームの成長を促すフレームワークであることは再び実感

Phase2.5 : Rebuild立て直し

目的

•スクラムの理解を深める

•スクラムをふりかえって今後の改善につなげる

理解を深める

•認定スクラムマスター研修に参加

•研修の内容をワークショップ形式で部内に展開

Phase2のふりかえりPhase2の参加メンバー全員で実施

•データ収集

•アイデア出し

•何をすべきか決定

•ふりかえりのふりかえり

進め方•個人ワーク

•チーム内ですり合わせ

•他チームに向けてレビュー

•タスクボード、バーンダウンチャートで進捗管理

•ふりかえり

Photosふりかえりの風景

Phase2.5 : SummarySprint2.5まとめ

まとめ

•ふりかえることの有効性を改めて実感

•モノづくり以外でもスクラムフレームワークは機能する

ToDo 進行中 完了

導入のきっかけ 8

導入の実例Phase1 5

導入の結果 3

導入の実例Phase2 5

導入の実例Phase3 5

スクラムとは 2

Phase3：Arrange Scrumスクラムアレンジ

導入した組織

•自部門の開発に関わる全組織

• 12のチーム、100人を超えるメンバー

•開発者、企画者、デザイナーで構成

アレンジ例•突発案件を受け入れる

• Sprintごとのチーム再構成

•デイリースタンドアップの構成変更

•いろんなスタイルのふりかえり

•大規模プロジェクトでのスクラム

•業務改善のスクラム

•共通ルールとチームのルール

Common rules共通ルールから一部紹介

ストーリーの定義•ユーザに提供するモノの終わりが見える課題や作業

•エンジニア、UIデザイナー、マークアップエンジニアが見積もることのできる課題や作業

•エンジニア、UIデザイナー、マークアップエンジニアが手を動して行うべき課題や作業

ストーリーの見積もり

•ポイントで見積もる

• 1～2日で終わりそうなストーリーが基準

•プランニングポーカー

プレプランニング

•チーム全体の優先順位を決めるための会議

•全マネージャー陣、全PO、全SMが参加

• PO、SMが主体

•結果次第で次スプリントのチーム構成を変更

スクラムマスター会議

•各チームのスクラムの状況を共有する会議

• Tryしてよかった・悪かったことを他チームに共有

•良いものは共通ルールに反映

Team rulesチームのルールから一部紹介

エピックの定義

•企画者、アナリストのための課題や作業

•エンジニア等がモノづくりを開始するための情報を集める作業

エピックの見積もり

•事業価値で見積もる

•基準値はx月あたりの売り上げ

•プランニングポーカー

スクラムのスクラム•メンバーが10名以上のプロジェクトをサブチームに分割

•サブチームごとのStandUp、サブチームの代表者のStandUpを実施

•その他の会議は全員参加

•バックログは共通

We continue doing...現在も継続中...

Demo : How to use JIRA for Scrum

ScrumにおけるJIRAの使い方

ToDo 進行中 完了

導入のきっかけ 8

導入の実例Phase1 5

導入の結果 3

導入の実例Phase2 5

導入の実例Phase3 5

スクラムとは 2

我々に何がおきたか？

What happened to us?

Things have been changed変化してきたこと

Mindマインド

•組織間のコミュニケーション

•自らやりたいことを生み出す風土と仕組み

•自発的な改善サイクル

Self-organization自己組織化

•新規プロジェクトのスクラムが発生

•担当が変わっても生産性が落ちない

•プロダクトバックログが増えている

•レビュー、ふりかえりからストーリー化・エピック化が行われている

Things have been visualized

見えてきたこと

Productivity生産性

Accuracy of estimation見積もり精度

我々がなぜスクラムを導入したのか？

Why do we Scrum?

課題認識 asトップマネジメント

•アウトプットや業務進行のクオリティ・スピードが上がっていない

•新人が増えても意味のあるアウトプットが増えていない

•新しいアプローチやスケールする取り組みがない

課題認識 as メンバー

•いつまでたっても「やるべきこと」が多い

•やっていることの背景・位置づけがよくわからない

•先を見通す余裕がない

•周囲のやっていることが分からない

•課題・問題は認識できているが変えるに至らない

課題認識 as マネージャー

•経営陣、現場の課題を解決したい

•自己成長型の組織にしたい

解決すべき課題（再掲）

•困難なスケジューリング

•不明確な責任範囲

•放置された課題・問題

「困難なスケジューリング」 に対して

•優先順位をつける役割をPOに一任

•緊急案件、ステークホルダニーズも受容

•やりたいこと、やるべきことをバックログで管理職

•スケジューリングの参考になる指標（生産性、見積もり精度）

「不明確な責任範囲」 に対して

• PO、SM、チームの役割と責任を明文化し共有

•スクラムチームのミッションを明文化し、他チームや他部署と共有

「放置された問題・課題」 に対して

• Sprintのたびにふりかえり、問題を抽出、改善

•システム改善スクラムを立ち上げ専任で対応

•業務改善スクラムを立ち上げ有志で対応

伝えたいこと

Message

ToDo 進行中 完了

導入のきっかけ 8

導入の実例Phase1 5

導入の結果 3

導入の実例Phase2 5

導入の実例Phase3 5

スクラムとは 2

Done以上