To be an agile enterprise
～ 楽天でのふつうのアジャイル・
アダプションの進め方
@IT 開発チームを改善するためのスクラムTips
最終回 5分で分かる、「スクラム」の基本まとめ
E-AGILITY Conference 2012 楽天株式会社 川口恭伸 2012年9月26日
1

> whoami
Yasunobu Kawaguchi
Agile Coach
2

スクラムとの出会いから現在まで
• 2008年9月 XP祭りにて、Agile2008報告会。Scrum の普及を知る。
– 同年11月から スクラムを採用したパイロットプロジェクトの機会を得る
• 2009年2月 スクラムを採用した内製ツールの開発
– 2月 スプリント0
– ３月〜４月 第一期開発
– ５月〜７月 第二期開発 以降翌年まで継続して保守開発
– Agile2009 に初参加
– 12月 認定スクラムマスタ研修に初参加
• 2011年７月 スクラム普及を中心とした活動に移る
– 1月 イノベーションスプリント2011 実行委員長
– 7月 アギレルゴコンサルティングに転職
– 10月 スクラムギャザリング東京 実行委員
• 2012年４月 大企業でのアジャイル普及活動へ
– アジャイル普及のための活動を行う
• 社内コーチング
• 社内研修
• 教育研修の企画立案
• 楽天テクノロジーカンファレンス実行委員
3

5分で分かる、「スクラム」の基本まとめ
4

10分でスクラム
5

楽天の状況
Our Context
楽天の状況
6

楽天主義
常に改善、常に前進
Professionalismの徹底
仮説->実行->検証->仕組み化
顧客満足の最大化
スピード!! スピード!! スピード!!
7

楽天でのアジャイル普及活動
2010 2011 2012
In-team Coaching
A-team A-Group
Adoption support
Pilot Project Trainings Peer Support
Boot Camp
Global Experience Program
Advanced Training
By Foreign Trainers
Basic Training
For Managers, For Teams
8

楽天でのアジャイル普及状況
DU (開発部)
9

Mike Cohn の ADAPTプロセス
人によってギャップ
Awareness Desire Ability Promotion Transform
認知
願望
スキル
成果
移行
アジャイルの概要を
理解している 周りを説得する
必要なスキルを
課題を認識し 身につけ、 試行し、結果
アジャイルを使って できるようになる を出す
解決したい点をもつ
10

イノベーション普及曲線
肌感覚としてはまだキャズムを越えていない印象
アーリー レイト
マジョリティ マジョリティ
アーリー ラガード
アダプター
イノベーター
キャズム
11

なぜアジャイルか？
Why Agile?
なぜアジャイルか?
12

なぜアジャイル？
創業以来Webサービスを中心に事業を行ってきた。
激しい競争に勝ち抜くため、常に新たな施策を投入
しつづける文化。
ベンチャー企業として、スピード優先で行ってきた反面
おそらく品質面で課題を抱えた経験があり、邪魔に
ならない範囲でプロセス(チェック)を強化。
ビジネス部門と開発部門の分業。
開発と運用は分業しない主義。技術もなるべく自前主義。
→ アジャイルは自然
13

アジャイルの構成要素
プロセス 顧客満足 要求、仕様
ビジネス/ユーザー Lean UX ATDD, BDD
チーム活動 Scrum
技術プラクティス CI, TDD Metrics Delivery
テスト、品質 計測 スムーズなリリース
14

アジャイルの構成要素
プロセス 顧客満足 要求、仕様
ビジネス/ユーザー Lean UX ATDD, BDD
チーム活動 Scrum
技術プラクティス CI, TDD Metrics Delivery
テスト、品質 計測 スムーズなリリース
15

Scrum
Scrum チーム活動のフレームワーク
概要 主な教授方法
最も普及したアジャイル - 書籍
プロジェクトマネジメント。 「塹壕よりスクラムとXP」
チーム主体の活動を定義。 「アジャイルな見積りと計画作り」
プロセスとプロダクトの責任分離。
- 認定スクラム研修
サーバントリーダーシップ。
タイムボックス、デモ、ふりかえり - チームに入る
- 現場へのコーチング
注意点
チーム活動なので一人に教えても定着しづらい
16

アジャイルの構成要素
プロセス 顧客満足 要求、仕様
ビジネス/ユーザー Lean UX ATDD, BDD
チーム活動 Scrum
技術プラクティス CI, TDD Metrics Delivery
テスト、品質 計測 スムーズなリリース
17

TDD (テスト駆動開発)
テスト駆動開発
TDD テストコードでソフトウェアを育てる開発技法
概要 主な教授方法
テストコードとソースコードを - 書籍
交互に書いていく開発技法。 「テスト駆動開発入門」
一人からでも始められるが、 「実践テスト駆動開発」
ペアプログラミングを通じて、 「レガシーコード改善ガイド」
教授することが効率的。
- ハンズオン研修、デモ
リファクタリングでコードを
洗練していく。 - 現場でのペアプログラミング
注意点
座学では教えづらい。テンポやツールの使いこなしをセットで。
18

CI (継続的インテグレーション)
継続的インテグレーション
CI テストコードでソフトウェアを育てる開発技法
概要 主な教授方法
バージョン管理システムに - 書籍/Webサイト
コミットされたコードを 「継続的デリバリー」
随時ビルドして、自動テストを
- 勉強会で実例の共有
走らせ、品質を確認する。
Jenkinsが代表的だが、 - 構築手順書や操作手順
各社の開発ツールにも
含まれている。
注意点
舞台装置家が必要。誰かがサーバを立て管理する必要がある。
19

Metrics
Metrics アクセス解析を通じてユーザー行動をつかむ
概要 主な教授方法
アクセス解析を通じて実際の - 書籍/Webサイト
ユーザー行動を分析し、学ぶ。 「リーンスタートアップ」
A/Bテスト(スプリットテスト)を 「実践IA*CMS」
併用することも。
- 勉強会で実例の共有
Google Analytics は無償で
設備なしではじめられる。 - 構築手順書や操作手順
注意点
舞台装置家が必要。仮説検証スキルが必要。
20

アジャイルの構成要素
プロセス 顧客満足 要求、仕様
ビジネス/ユーザー Lean UX ATDD, BDD
チーム活動 Scrum
技術プラクティス CI, TDD Metrics Delivery
テスト、品質 計測 スムーズなリリース
21

Metrics
Lean 全体プロセスを改善する
概要 主な教授方法
バリューストリームマッピング - 書籍/Webサイト
で部署をまたぐ価値の流れを 「リーンソフトウェア開発」
見える化し、改善を促す。 「リーン開発の本質」
「リーンソフトウェア開発と
ムダとりによる継続的なプロセス 組織改革」
改善
- バリューストリームマップ、
カンバン作り
注意点
意思決定者の巻き込み。部署を越えた取り組みの具体化が必要
22

Metrics
UX 利用者の隠れた本当のニーズを探り出す
概要 主な教授方法
利用者の行動分析から、 - 書籍/Webサイト
潜在的なニーズを満たす 「ユーザビリティエンジニアリング」
解決策を発想する。 「アジャイル・ユーザビリティ」
「師匠と弟子モデル」 「ゲームストーミング」
「ユーザー行動モデリング」
- 勉強会で実例の共有
「ユーザーストーリーマッピング」
- 構築手順書や操作手順
注意点
舞台装置家が必要。仮説検証スキルが必要。
23

Metrics
ATDD/BDD 実例による要件定義と受入テスト
概要 主な教授方法
受入テストを自動化する。 - 書籍/Webサイト
要件定義を行うプロダクト担当 「実践アジャイルテスト」
や顧客と開発者、テスト担当が
共通言語を持って仕様を理解す
る。
注意点
アジャイル開発を理解したテスト技法の専門家育成が急務
24

アジャイルの構成要素
プロセス 顧客満足 要求、仕様
ビジネス/ユーザー Lean UX ATDD, BDD
チーム活動 Scrum
技術プラクティス CI, TDD Metrics Delivery
テスト、品質 計測 スムーズなリリース
25

楽天の状況
Metrics and Pivot
フィードバックと方向転換
26

イノベーション普及曲線
アーリー レイト
マジョリティ マジョリティ
アーリー ラガード
アダプター
イノベーター
キャズム
まず最初に基盤を整えてくれるのはイノベーター。
イノベーターは、「新しい」というだけで協力してくれるが、そのうち飽きて、去っていく。
イノベーターはマジョリティからみれば「新し物好き」「なんかわからんけどすごい人」
マジョリティにアクセスするためには、次のアーリーアダプターから伝える事が必要。
参考: Fearless Change
27

教育研修としての考慮
従来の教育研修は座学による
個人スキルの向上を目的とするものが多い
ペアコーチング
チーム研修 ペアプログラミング指導
認定スクラム研修
チームへのコーチング/技術指導
チームファシリテーション
投資判断や評価のやり方を考えなければならない 28

アジャイルの構成要素
プロセス 顧客満足 要求、仕様
ビジネス/ユーザー Lean UX ATDD, BDD
チーム活動 Scrum チーム研修
技術プラクティス CI, TDD Metrics Delivery
テスト、品質 計測 スムーズなリリース
ペアコーチング
チームへのコーチング/技術指導 29

Fearless Change
Fearless Change
変化には時間がかかることを理解する。
本質的な変化には３〜５年かかる
変化は一人一人が行うもの
(イノベーション普及曲線に従う)
計画できないが戦略は必要
30

マインドセットの力
http://enterprisezine.jp/iti/detail/3400?p=2
31

楽天英語化の影響
英語化の影響
海外講師の招聘
- Jonathan Rasmusson
- Mary Poppendieck
- Janet Gregory
- Jeff Patton
グローバルエクスペリエンスプログラム
(海外グループ企業での研修) 32

狩野先生との対話
Kano –sensei explains his customer
satisfaction model. This model is very
famous in worldwide.
Typical products follows these steps.
1. No interest
2. Must have
3. Performance
4. Excited
I asked him “How can we make new
product such a short term?”
He answered “You can not in such a
short term.
CEO should put much time for
innovation.” 33

時間があれば紹介
34

ウォーターフォールとの対比
http://www.slideshare.net/yoichitamamaki/ss-14456822 35

玉牧さんの分類
http://www.slideshare.net/yoichitamamaki/ss-14456822 36