Scrumで組織改革

• 貝瀬 岳志さん
• SIer -> ゲームポータル -> DeNA(4年前)
• 2011年夏から、スクラム導入を開始
• 2011年秋、認定スクラムマスターに

why do we scrum

背景

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

課題

• 経営目線の課題
  • アウトプットやスピードが上がっていないように見える
  • 新人が増えても、意味のあるアウトプットが増えていない
  • 新しいアプローチやスケールする取り組みがない
• メンバーの課題
  • いつもやることが多い
  • 周囲のやっていることがわからない
• ここまで聞いていると、「残念な組織」と感じる方もいらっしゃるかもしれｍせん
• 課題を解決し、自己成長型の組織にしたい
  • スクラムを使って現場の課題を解決することにした

なぜ問題なのか

• 困難なスケジューリング
• 不明確な責任範囲
• 放置された問題、課題

なぜ緊急の案件が多いのか

• 目の前のタスクに追われていて、やらなくてはいけないことが見えていない
• 優先順位の認識が人によってバラバラ、というのが根本的な原因
• どうすれば優先順位を適切に付けられるのか、がこの課題に対するアプローチ

どうして責任が不明確なのか

• 組織の目標とかわかってないし、頻繁に組織が変わるし
• どうすればお互いの目線をあわせらるか
• 役割の可視化とマインド

なぜ目先の仕事を優先するのか

• どうすれば、課題や問題に真摯に向き合えるか
• 日々の作業と同じくらい、課題解決や問題解決が重大なことだ、と認識する

なぜスクラムなのか

• 先程の課題を解決するのに適していると考えたから

スクラムとは何か

• (メモ省略)

導入実例(時系列) Phase1

トライアル

• スマートフォンモバゲーのリニューアルプロジェクト
  • UI設計を海外、実装を日本という特殊な構成
  • 海外
    • SM * 1 IA * 2, Graphic *2
  • 日本
    • PO * 1, SM * 1 eng * 4-6
• 海外のデザイン会社がスクラムをやっていたので、日本でもそれをやることにした
• Daily standup を朝と夕方の二回実施（時差の関係で）
• プレプランニング、プランニング、
• ツール
  • Basecamp でプロダクトバックログの管理
  • 日本国内では Basecamp の情報をホワイトボードと付箋に貼り出した → 見える化
  • 全く同じ情報をJIRAにも登録

振り返りの結果

• KPTでProblemとtryばっかり、よかったことがほとんどなかった
  • 朝会がなかなか終わらない(人数が多かった)

スクラム導入の課題がどうなったか

• スケジュール、優先順位について
  • スプリント単位で優先順位を合意できたので、突発案件は減った
  • 日々のdaily standup meetingで日々の優先順位も調整できた
  • スクラムをやっていないチームからの差し込み
  • 会議やツールがうまく機能していなかった
• 責任の範囲が不明確だったこと
  • プロジェクト内部で責任の所在が明文化された
  • POが意思決定できない状況やSMが解決できない状況もあった
• 放置された課題・問題
  • 振り返りを使って問題提起、改善のサイクルが回り始めた
  • 助け合いができるようになった
  • 大きな問題ほど先送りになった

導入事例 Phase2

• トライアルが終了した直後に、スマホ版モバゲーを運用する企画・開発部門でやってみた
• Phase1からの教訓をいかし、企画者と開発者を1箇所に集めた（もともとは別の席だった）
  • 背中合わせとか隣に
• Phase1で人数が多すぎて朝会が破綻したので、10人以内に収まるようにした
• Sprint 0 を1~2週間実施した
• 使い慣れたツールに集約して整備した
  • もともとJIRAに使い慣れていたのでJIRAに
  • 付箋とホワイトボードは二度手間なので、思い切ってデジタルに一本化した

チーム

• ミッションごとに4つのチーム
• 各チームにSMとPOを1人ずつ
  • 他プロジェクトとも兼任
• チームメンバーーは専任

Sprint0のテンプレート

• 経験の浅いスクラムマスターでもできるように、テンプレートを作成した
  • ミッションの明確化
  • 責任範囲の明確化
  • 役割の明確化
  • ストーリーの抽出
  • プロダクトバックログの作成
  • Doneの定義

Phase2 振り返り

• 困難なスケジューリング
  • 突発案件は減った
• 不明確な責任範囲
  • プロジェクト内部の責任の所在が明確に
  • チーム間のポテンヒットみたいなものは減った
  • マネージャー経由で担当をアサイン、というボトルネックが解消された
  • POが意思決定できない状況やSMが解決できない状況もあった
• 放置された問題、課題
  • バックログがなかなか増えない
  • スクラムの進め方に否定的なメンバーやチームが出てきた
• スクラムの理解が浅いまま実施すると逆効果
• スクラムだけでは解消しない問題もある
• 問題の可視化やチームの成長を促すフレームワークだと実感できた

立て直し Phase2.5

• スクラムの理解を深める
• 時系列で振り返って今後に活かせるようにした

理解を深める

• 認定スクラムマスターに
• その内容を社内に持ち帰ってワークショップ形式でFB
  • Phase2 のふりかえりをやって、問題を集めてどうしたら改善できるかのアイディア出しをしてもらった
• 振り返りの風景 (写真)
  • 壁に付箋を貼って、改善したいこと一覧を書きだしてバックログとして管理
  • 課題の振り返りをした。振り返りの機会はよい場だったと実感してもらえた
• ものづくり以外にもスクラムはフレームワークとして使える

Phase3 アレンジ

• 自部門の開発に関わる前組織で導入、12のチーム、100人を超えるメンバー

アレンジした点

• スクラムは突発案件は受け入れないが、受け入れることにした
• チーム構成を変えることも容認した
  • 組織自体や市場の変化に対応していかないといけないので
• ストーリーの定義
  • ユーザーに提供するものの終わりが見える課題や作業
  • エンジニア、UIデザイナなどが見積もりできるもの
  • ポイントで見積る
• プレプランニング
  • プランニングの前に、全体の優先順位を決めるための会議。全マネージャー、全PO、全SMが参加
  • この結果次第で次のスプリントのメンバーを変更したりする
• スクラムマスター会議
  • 各チームのスクラムの状況を共有する会議
  • 良かったことはルール (common rule)に反映して共有する
• EPICの定義
  • ストーリーの上位に来る概念、企画者やアナリストが使うもの
  • ストーリー同様見積る。EPIC自体の事業価値。基準値は売上
• スクラムのスクラム
  • メンバーが10人以上の場合はサブチームに分解し、サブチームごとにDaily Scrum
  • プランニングなど、その他は全員参加
  • バックログも全チームで共有

ScrumでどうJIRAを使っているか (デモ)

• JIRAにストーリーを追加
• product backlog -> spring backlog にドラッグ＆ドロップで移動
  • 移動後の product backlog は「ただやりたいことの一覧」
• メンバーは「その日に作業する」ものを TODO から DOING に移動
• 時間を入力すると、burndown chart に自動で反映されて進捗が可視化できる

導入の結果

• 結果的に何が起こったか
  • マインド
  • 自己組織化
  • 生産性を可視化できるようになった

マインド

• チーム間だけじゃなく、他部署とのコミュニケーションが良くなった
• 素直に意見交換ができるように
• 振り返りをすることで、自発的な改善サイクルが生まれた

自己組織化

• 新規プロジェクトがスクラムで動いている
• 担当が変わっても生産性が落ちない
• バックログが増えている

生産性可視化

• JIRAのグラフ？
  • ストーリーの追加に追従して、消化したストーリー数も増えている
  • Burndown している
• 見積もりの精度が上がった
  • 過去のブレが大きかった見積を、チームの振り返りで見直す

課題はどうなった？

• 冒頭で述べた、経営者目線からの課題とメンバー目線での課題、いずれも改善されてきたと感じている

困難なスケジューリング

• POに優先順位が一任
  • 改善された
• バックログで管理ができる
• スケジューリングの参考になる指標が可視化されたので、可能性の高い粒度で考えてもらえるように

不明確な責任範囲

• PO / SM / チームの責任を明文化した
• チームのミッションも明文化した

放置された問題、課題

• 振り返りを実施するので、放置されることはなくなった
• システム改善スクラムを立ち上げて、専任で対応するということも
• 有志をつのり、プロジェクト横断で改善するような組織も作った

まとめ

• スクラム大変
• 効果はあった
• ぜひトライして
• 半年やってダメだったらDeNAにきて僕と一緒にスクラム!