To be sn agile enterprise

1,104 views

Published on

川口 恭伸、楽天株式会社
『E-Agility Conference 2012』 講演資料

企業でのアジャイル適用について、私が楽天で進めている方法についてお話しします。
まず、アジャイルを構成するいくつかの手法を概観し、企業や事業ごとに目指すべきアジャイルの形を描く必要性について議論します。
そして、アジャイル適用を進めるプロセスとしてMike CohnのADAPTモデルを参照しながら楽天でのアジャイル適用の進め方について説明します。
また、社内公用語の英語化によって海外講師を通訳なしで招聘できるようになっている点についても紹介いたします。

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,104
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

To be sn agile enterprise

  1. 1. To be an agile enterprise~ 楽天でのふつうのアジャイル・ アダプションの進め方 @IT 開発チームを改善するためのスクラムTips 最終回 5分で分かる、「スクラム」の基本まとめ E-AGILITY Conference 2012      楽天株式会社 川口恭伸     2012年9月26日 1
  2. 2. > whoamiYasunobu Kawaguchi Agile Coach 2
  3. 3. スクラムとの出会いから現在まで •  2008年9月 XP祭りにて、Agile2008報告会。Scrum の普及を知る。 –  同年11月から スクラムを採用したパイロットプロジェクトの機会を得る•  2009年2月 スクラムを採用した内製ツールの開発 –  2月 スプリント0 –  3月〜4月 第一期開発 –  5月〜7月 第二期開発 以降翌年まで継続して保守開発 –  Agile2009 に初参加 –  12月 認定スクラムマスタ研修に初参加•  2011年7月 スクラム普及を中心とした活動に移る –  1月 イノベーションスプリント2011 実行委員長 –  7月 アギレルゴコンサルティングに転職 –  10月 スクラムギャザリング東京 実行委員•  2012年4月 大企業でのアジャイル普及活動へ –  アジャイル普及のための活動を行う •  社内コーチング •  社内研修 •  教育研修の企画立案 •  楽天テクノロジーカンファレンス実行委員 3
  4. 4. 5分で分かる、「スクラム」の基本まとめ 4
  5. 5. 10分でスクラム 5
  6. 6. 楽天の状況 Our Context 楽天の状況 6
  7. 7. 楽天主義常に改善、常に前進Professionalismの徹底仮説->実行->検証->仕組み化顧客満足の最大化スピード!! スピード!! スピード!! 7
  8. 8. 楽天でのアジャイル普及活動2010 2011 2012 In-team CoachingA-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
  9. 9. 楽天でのアジャイル普及状況 DU (開発部) 9
  10. 10. Mike Cohn の ADAPTプロセス 人によってギャップAwareness Desire Ability Promotion Transform 認知 願望 スキル 成果 移行 アジャイルの概要を理解している 周りを説得する 必要なスキルを 課題を認識し 身につけ、 試行し、結果 アジャイルを使って できるようになる を出す 解決したい点をもつ 10
  11. 11. イノベーション普及曲線肌感覚としてはまだキャズムを越えていない印象 アーリー レイト マジョリティ マジョリティ アーリー ラガード アダプター イノベーター キャズム 11
  12. 12. なぜアジャイルか? Why Agile? なぜアジャイルか? 12
  13. 13. なぜアジャイル? 創業以来Webサービスを中心に事業を行ってきた。 激しい競争に勝ち抜くため、常に新たな施策を投入 しつづける文化。 ベンチャー企業として、スピード優先で行ってきた反面 おそらく品質面で課題を抱えた経験があり、邪魔に ならない範囲でプロセス(チェック)を強化。 ビジネス部門と開発部門の分業。 開発と運用は分業しない主義。技術もなるべく自前主義。 → アジャイルは自然 13
  14. 14. アジャイルの構成要素 プロセス 顧客満足 要求、仕様ビジネス/ユーザー Lean UX ATDD, BDD チーム活動 Scrum技術プラクティス CI, TDD Metrics Delivery テスト、品質 計測 スムーズなリリース 14
  15. 15. アジャイルの構成要素 プロセス 顧客満足 要求、仕様ビジネス/ユーザー Lean UX ATDD, BDD チーム活動 Scrum技術プラクティス CI, TDD Metrics Delivery テスト、品質 計測 スムーズなリリース 15
  16. 16. ScrumScrum チーム活動のフレームワーク概要 主な教授方法最も普及したアジャイル -  書籍プロジェクトマネジメント。 「塹壕よりスクラムとXP」チーム主体の活動を定義。 「アジャイルな見積りと計画作り」プロセスとプロダクトの責任分離。 -  認定スクラム研修サーバントリーダーシップ。タイムボックス、デモ、ふりかえり -  チームに入る -  現場へのコーチング注意点 チーム活動なので一人に教えても定着しづらい 16
  17. 17. アジャイルの構成要素 プロセス 顧客満足 要求、仕様ビジネス/ユーザー Lean UX ATDD, BDD チーム活動 Scrum技術プラクティス CI, TDD Metrics Delivery テスト、品質 計測 スムーズなリリース 17
  18. 18. TDD (テスト駆動開発)テスト駆動開発TDD テストコードでソフトウェアを育てる開発技法 概要 主な教授方法 テストコードとソースコードを -  書籍 交互に書いていく開発技法。 「テスト駆動開発入門」 一人からでも始められるが、 「実践テスト駆動開発」 ペアプログラミングを通じて、 「レガシーコード改善ガイド」 教授することが効率的。 -  ハンズオン研修、デモ リファクタリングでコードを 洗練していく。 -  現場でのペアプログラミング 注意点 座学では教えづらい。テンポやツールの使いこなしをセットで。 18
  19. 19. CI (継続的インテグレーション)継続的インテグレーションCI テストコードでソフトウェアを育てる開発技法 概要 主な教授方法 バージョン管理システムに -  書籍/Webサイト コミットされたコードを 「継続的デリバリー」 随時ビルドして、自動テストを -  勉強会で実例の共有 走らせ、品質を確認する。 Jenkinsが代表的だが、 -  構築手順書や操作手順 各社の開発ツールにも 含まれている。 注意点 舞台装置家が必要。誰かがサーバを立て管理する必要がある。 19
  20. 20. MetricsMetrics アクセス解析を通じてユーザー行動をつかむ概要 主な教授方法アクセス解析を通じて実際の -  書籍/Webサイトユーザー行動を分析し、学ぶ。 「リーンスタートアップ」A/Bテスト(スプリットテスト)を 「実践IA*CMS」併用することも。 -  勉強会で実例の共有Google Analytics は無償で設備なしではじめられる。 -  構築手順書や操作手順 注意点 舞台装置家が必要。仮説検証スキルが必要。 20
  21. 21. アジャイルの構成要素 プロセス 顧客満足 要求、仕様ビジネス/ユーザー Lean UX ATDD, BDD チーム活動 Scrum技術プラクティス CI, TDD Metrics Delivery テスト、品質 計測 スムーズなリリース 21
  22. 22. MetricsLean 全体プロセスを改善する概要 主な教授方法バリューストリームマッピング -  書籍/Webサイトで部署をまたぐ価値の流れを 「リーンソフトウェア開発」見える化し、改善を促す。 「リーン開発の本質」 「リーンソフトウェア開発とムダとりによる継続的なプロセス  組織改革」改善 -  バリューストリームマップ、 カンバン作り注意点 意思決定者の巻き込み。部署を越えた取り組みの具体化が必要 22
  23. 23. MetricsUX 利用者の隠れた本当のニーズを探り出す概要 主な教授方法利用者の行動分析から、 -  書籍/Webサイト潜在的なニーズを満たす 「ユーザビリティエンジニアリング」解決策を発想する。 「アジャイル・ユーザビリティ」「師匠と弟子モデル」 「ゲームストーミング」「ユーザー行動モデリング」 -  勉強会で実例の共有「ユーザーストーリーマッピング」 -  構築手順書や操作手順注意点舞台装置家が必要。仮説検証スキルが必要。 23
  24. 24. MetricsATDD/BDD 実例による要件定義と受入テスト概要 主な教授方法受入テストを自動化する。 -  書籍/Webサイト要件定義を行うプロダクト担当 「実践アジャイルテスト」や顧客と開発者、テスト担当が共通言語を持って仕様を理解する。注意点アジャイル開発を理解したテスト技法の専門家育成が急務 24
  25. 25. アジャイルの構成要素 プロセス 顧客満足 要求、仕様ビジネス/ユーザー Lean UX ATDD, BDD チーム活動 Scrum技術プラクティス CI, TDD Metrics Delivery テスト、品質 計測 スムーズなリリース 25
  26. 26. 楽天の状況 Metrics and Pivot フィードバックと方向転換 26
  27. 27. イノベーション普及曲線 アーリー レイト マジョリティ マジョリティ アーリー ラガード アダプター イノベーター キャズムまず最初に基盤を整えてくれるのはイノベーター。イノベーターは、「新しい」というだけで協力してくれるが、そのうち飽きて、去っていく。イノベーターはマジョリティからみれば「新し物好き」「なんかわからんけどすごい人」マジョリティにアクセスするためには、次のアーリーアダプターから伝える事が必要。 参考: Fearless Change 27
  28. 28. 教育研修としての考慮 従来の教育研修は座学による個人スキルの向上を目的とするものが多い ペアコーチング チーム研修 ペアプログラミング指導 認定スクラム研修 チームへのコーチング/技術指導 チームファシリテーション投資判断や評価のやり方を考えなければならない 28
  29. 29. アジャイルの構成要素 プロセス 顧客満足 要求、仕様ビジネス/ユーザー Lean UX ATDD, BDD チーム活動 Scrum チーム研修技術プラクティス CI, TDD Metrics Delivery テスト、品質 計測 スムーズなリリースペアコーチング チームへのコーチング/技術指導 29
  30. 30. Fearless Change Fearless Change 変化には時間がかかることを理解する。 本質的な変化には3〜5年かかる 変化は一人一人が行うもの (イノベーション普及曲線に従う) 計画できないが戦略は必要 30
  31. 31. マインドセットの力 http://enterprisezine.jp/iti/detail/3400?p=2 31
  32. 32. 楽天英語化の影響英語化の影響 海外講師の招聘 -  Jonathan Rasmusson -  Mary Poppendieck -  Janet Gregory -  Jeff Pattonグローバルエクスペリエンスプログラム(海外グループ企業での研修) 32
  33. 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. ExcitedI asked him “How can we make newproduct such a short term?”He answered “You can not in such ashort term.CEO should put much time forinnovation.” 33
  34. 34. 時間があれば紹介 34
  35. 35. ウォーターフォールとの対比http://www.slideshare.net/yoichitamamaki/ss-14456822 35
  36. 36. 玉牧さんの分類http://www.slideshare.net/yoichitamamaki/ss-14456822 36

×