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