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