1

@IT 開発チームを改善するためのスクラムTips 最終回　5分で分かる、「スクラム」の基本まとめ

To be an agile enterprise ～ 楽天でのふつうのアジャイル・

アダプションの進め方

E-AGILITY Conference 2012　　　　　 楽天株式会社 川口恭伸 　　　　2012年9月26日

2

> whoami

Yasunobu Kawaguchi Agile Coach

3

スクラムとの出会いから現在まで

•  2008年9月 XP祭りにて、Agile2008報告会。Scrum の普及を知る。 –  同年11月から スクラムを採用したパイロットプロジェクトの機会を得る

•  2009年2月 スクラムを採用した内製ツールの開発 –  2月 スプリント0 –  ３月〜４月 第一期開発 –  ５月〜７月 第二期開発 以降翌年まで継続して保守開発 –  Agile2009 に初参加 –  12月 認定スクラムマスタ研修に初参加

•  2011年７月 スクラム普及を中心とした活動に移る –  1月 イノベーションスプリント2011 実行委員長 –  7月 アギレルゴコンサルティングに転職 –  10月 スクラムギャザリング東京 実行委員

•  2012年４月 大企業でのアジャイル普及活動へ –  アジャイル普及のための活動を行う

•  社内コーチング •  社内研修 •  教育研修の企画立案 •  楽天テクノロジーカンファレンス実行委員

4

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

5

10分でスクラム

6

楽天の状況

楽天の状況

Our Context

7

楽天主義

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

8

楽天でのアジャイル普及活動

A-team

Pilot Project Trainings

Global Experience Program

In-team Coaching

Adoption support

By Foreign Trainers

Boot Camp

Advanced Training

2010 2011 2012

For Managers, For Teams Basic Training

A-Group

Peer Support

9

楽天でのアジャイル普及状況

DU (開発部)

10

Mike Cohn の ADAPTプロセス

Awareness Desire Ability Promotion Transform

人によってギャップ

アジャイルの概要を 理解している

認知

課題を認識し アジャイルを使って 解決したい点をもつ

願望

必要なスキルを 身につけ、 できるようになる

スキル

試行し、結果 を出す

成果

周りを説得する

移行

11

イノベーション普及曲線

イノベーター

アーリー アダプター

アーリー マジョリティ

レイト マジョリティ

ラガード

キャズム

肌感覚としてはまだキャズムを越えていない印象

12

なぜアジャイルか？

なぜアジャイルか?

Why Agile?

13

なぜアジャイル？

創業以来Webサービスを中心に事業を行ってきた。

激しい競争に勝ち抜くため、常に新たな施策を投入 しつづける文化。

ベンチャー企業として、スピード優先で行ってきた反面 おそらく品質面で課題を抱えた経験があり、邪魔に ならない範囲でプロセス(チェック)を強化。

ビジネス部門と開発部門の分業。

開発と運用は分業しない主義。技術もなるべく自前主義。

→ アジャイルは自然

14

アジャイルの構成要素

Scrum チーム活動

CI, TDD

ATDD, BDD

Delivery 技術プラクティス テスト、品質 スムーズなリリース

UX Lean ビジネス/ユーザー

プロセス 顧客満足 要求、仕様

Metrics

計測

15

アジャイルの構成要素

Scrum チーム活動

CI, TDD

ATDD, BDD

Delivery 技術プラクティス テスト、品質 スムーズなリリース

UX Lean ビジネス/ユーザー

プロセス 顧客満足 要求、仕様

Metrics

計測

16

Scrum

Scrum チーム活動のフレームワーク

概要 主な教授方法 -  書籍

「塹壕よりスクラムとXP」 「アジャイルな見積りと計画作り」

-  認定スクラム研修

-  チームに入る

-  現場へのコーチング

チーム活動なので一人に教えても定着しづらい

注意点

最も普及したアジャイル プロジェクトマネジメント。 チーム主体の活動を定義。 プロセスとプロダクトの責任分離。 サーバントリーダーシップ。 タイムボックス、デモ、ふりかえり

17

アジャイルの構成要素

Scrum チーム活動

CI, TDD

ATDD, BDD

Delivery 技術プラクティス テスト、品質 スムーズなリリース

UX Lean ビジネス/ユーザー

プロセス 顧客満足 要求、仕様

Metrics

計測

18

TDD (テスト駆動開発)

TDD テストコードでソフトウェアを育てる開発技法

概要 主な教授方法 -  書籍

「テスト駆動開発入門」 「実践テスト駆動開発」 「レガシーコード改善ガイド」

-  ハンズオン研修、デモ

-  現場でのペアプログラミング

座学では教えづらい。テンポやツールの使いこなしをセットで。

注意点

テストコードとソースコードを 交互に書いていく開発技法。 一人からでも始められるが、 ペアプログラミングを通じて、 教授することが効率的。 リファクタリングでコードを 洗練していく。

テスト駆動開発

19

CI (継続的インテグレーション)

CI テストコードでソフトウェアを育てる開発技法

概要 主な教授方法 -  書籍/Webサイト

「継続的デリバリー」

-  勉強会で実例の共有

-  構築手順書や操作手順

舞台装置家が必要。誰かがサーバを立て管理する必要がある。

注意点

バージョン管理システムに コミットされたコードを 随時ビルドして、自動テストを 走らせ、品質を確認する。 Jenkinsが代表的だが、 各社の開発ツールにも 含まれている。

継続的インテグレーション

20

Metrics

Metrics アクセス解析を通じてユーザー行動をつかむ

概要 主な教授方法 -  書籍/Webサイト

「リーンスタートアップ」 「実践IA*CMS」

-  勉強会で実例の共有

-  構築手順書や操作手順

舞台装置家が必要。仮説検証スキルが必要。

注意点

アクセス解析を通じて実際のユーザー行動を分析し、学ぶ。 A/Bテスト(スプリットテスト)を 併用することも。 Google Analytics は無償で 設備なしではじめられる。

21

アジャイルの構成要素

Scrum チーム活動

CI, TDD

ATDD, BDD

Delivery 技術プラクティス テスト、品質 スムーズなリリース

UX Lean ビジネス/ユーザー

プロセス 顧客満足 要求、仕様

Metrics

計測

22

Metrics

Lean 全体プロセスを改善する

概要 主な教授方法 -  書籍/Webサイト

「リーンソフトウェア開発」 「リーン開発の本質」 「リーンソフトウェア開発と 　組織改革」

-  バリューストリームマップ、 カンバン作り

意思決定者の巻き込み。部署を越えた取り組みの具体化が必要

注意点

バリューストリームマッピング で部署をまたぐ価値の流れを 見える化し、改善を促す。 ムダとりによる継続的なプロセス改善

23

Metrics

UX 利用者の隠れた本当のニーズを探り出す

概要 主な教授方法 -  書籍/Webサイト

「ユーザビリティエンジニアリング」 「アジャイル・ユーザビリティ」 「ゲームストーミング」

-  勉強会で実例の共有

-  構築手順書や操作手順

舞台装置家が必要。仮説検証スキルが必要。

注意点

利用者の行動分析から、 潜在的なニーズを満たす 解決策を発想する。 「師匠と弟子モデル」 「ユーザー行動モデリング」 「ユーザーストーリーマッピング」

24

Metrics

ATDD/BDD 実例による要件定義と受入テスト

概要 主な教授方法 -  書籍/Webサイト

「実践アジャイルテスト」

アジャイル開発を理解したテスト技法の専門家育成が急務

注意点

受入テストを自動化する。 要件定義を行うプロダクト担当や顧客と開発者、テスト担当が 共通言語を持って仕様を理解する。

25

アジャイルの構成要素

Scrum チーム活動

CI, TDD

ATDD, BDD

Delivery 技術プラクティス テスト、品質 スムーズなリリース

UX Lean ビジネス/ユーザー

プロセス 顧客満足 要求、仕様

Metrics

計測

26

楽天の状況

フィードバックと方向転換

Metrics and Pivot

27

イノベーション普及曲線

イノベーター

アーリー アダプター

アーリー マジョリティ

レイト マジョリティ

ラガード

キャズム

まず最初に基盤を整えてくれるのはイノベーター。 イノベーターは、「新しい」というだけで協力してくれるが、そのうち飽きて、去っていく。 イノベーターはマジョリティからみれば「新し物好き」「なんかわからんけどすごい人」

マジョリティにアクセスするためには、次のアーリーアダプターから伝える事が必要。

参考: Fearless Change

28

教育研修としての考慮

従来の教育研修は座学による 個人スキルの向上を目的とするものが多い

チーム研修 ペアコーチング

チームへのコーチング/技術指導

認定スクラム研修 ペアプログラミング指導

チームファシリテーション

投資判断や評価のやり方を考えなければならない

29

アジャイルの構成要素

Scrum チーム活動

CI, TDD

ATDD, BDD

Delivery 技術プラクティス テスト、品質 スムーズなリリース

UX Lean ビジネス/ユーザー

プロセス 顧客満足 要求、仕様

Metrics

計測

チーム研修

ペアコーチング チームへのコーチング/技術指導

30

Fearless Change

Fearless Change

変化には時間がかかることを理解する。

本質的な変化には３〜５年かかる

変化は一人一人が行うもの (イノベーション普及曲線に従う)

計画できないが戦略は必要

31

マインドセットの力

http://enterprisezine.jp/iti/detail/3400?p=2

32

楽天英語化の影響

海外講師の招聘

-  Jonathan Rasmusson

-  Mary Poppendieck

-  Janet Gregory

-  Jeff Patton

グローバルエクスペリエンスプログラム (海外グループ企業での研修)

英語化の影響

33

狩野先生との対話

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.”

34

時間があれば紹介

35

ウォーターフォールとの対比

http://www.slideshare.net/yoichitamamaki/ss-14456822

36

玉牧さんの分類

http://www.slideshare.net/yoichitamamaki/ss-14456822