アジャイル組織の作り方教えます

Transcript

1. YUMEMI How to be designed as Organization being Agile ?

   アジャイル組織の作り方教えます

2. 1 2 3 4 5 Table of Contents 自己紹介 Before

   starting our presentation 会社説明 About Us イントロダクション introduction and notice 設計手法 how to be designed まとめ design concept 2

3. 1 INTRODUCTION

4. Ray Toshiyuki Kataoka YUMEMI Inc. 1976 2000 1 100 1,000

   EC 5,000 Company as a Service IT 2014 4 Sprocket 2 4

5. Modern Dance Artist

6. Modern Martial Artist (Aikido)

7. Magic

8. Classic Guitar

9. Whistling

10. DESIGN ENGINEERING MANAGEMENT デザイン・エンジニアリング・マネジメントの経験がない中で、２０年かけて失敗と苦労を重 ねてきた。苦労した中での、アンチパターン、プラクティスを共有できればと思います

11. 2 ABOUT US

12. Business Model 12 50,000,000MAU YUMEMI B and B to C

13. Our Vision ( expected by Ray ) 100,000,000 MAU 13

14. 14 We need 1,000 members with Quality & Agility Transform

    Organizational Structure

15. 15 アジャイル組織 Make Organization Being Agile(=more Adaptive )!

16. 16 全員CEO制度 給与は自己決定 有給取り放題

17. 17 一見するとカオス

18. 18 not Be Chaos, but Into Chaos

19. Observe the Unpredictability

20. 20 Keep Order in Chaos 混沌 秩序

21. 21 DOING AGILE BEING AGILE MINDSET VALUE PRINCEPLES PRATICES METHODS

    RULES >
22. None
23. None

24. 24 Boid Algorithm Cohesion Separation Alignment

25. Follow the Basic Principles

26. 3 KATAs ( Basic Principles ) 26 to be Keep

    Order in Chaos Self-Control Decoupled for Conflict Avoidance Alignment with Expectations ࣗ཯ ෼ࢄ ڠௐ

27. 27 Agile Organization is the organization that is self-designed to

    be adaptive in chaos, that is unpredictable circumstances , by keeping order (3 principles ) with transformative development YUMEMI’s definition of

28. 3 Introduction and Notice

29. 29 V U C A World Volatility 不安定 不確実 Uncertainty

    Complexity Ambiguity 複雑 曖昧 VUCA

30. 30 ING オランダの銀行 Spotify Zappos 8~9 3500

31. 31 ビジネスパートナー部門 マーケティング 営業 オペレーション 広報・コンプライアンス ファイナンス・人事 Squad Squad Tribe

    Squad Squad Tribe Squad Squad Tribe Squad Squad Tribe プラットフォーム：インフラ・ミドルウェア＆アプリケーション・ITオペレーション トランスバーサルチーム：アジャイルオーケストラ・インフォメーションセキュリティ・COOオフィス ギルド DevOps Architecture Test

32. 32 移

33. 01 02 03 ゆめみの受難と変革の歴史 33 2000 2007 2008 2013 2011

    2014 2018)

34. 34

35. 35 手段 手段 手段 目的 目的 責務（Scope） ( Scope )

    移

36. 36 Flatter 移 フラット型組織 階層のフラット化

37. 37 General Manager Delegate General Manager SPOF Workflow Manager 移

    Director

38. 38 権限委譲の難しさ（１） 権限移譲 Delegate 移 移 移

39. 39 移 権限委譲の難しさ（２） 権限委譲 領 報告 意見

40. 40

41. 4 HOW TO BE DESIGNED

42. 42 ࣗ཯ ෼ࢄ ڠௐ

43. KATA STEP1 Self-Control 43 ࣗ ཯

44. 45 Inverse Conway’s Maneuver Conway’s law organizations which design systems

    ... are constrained to produce designs which are copies of the communication structures of these organizations. recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture. 逆コンウェイの機動作戦

45. Definition in YUMEMI - We can control "Not You But

    We" - The only person whose behavior we can control is our own ( Choice Theory ) Self-Control 46

46. 47 We can control "Not You But We" We You

    We

47. Self-Control Adaptive Person Team Organization 48

48. More Adaptive Decision Making Process ?

49. 50 助言プロセス 1) 2) Any person can make any decision

    after seeking advice from 1) everyone who will be meaningfully affected, and 2) people with expertise in the matter.

50. 51 Level5 Advise I will advice but they decide Delegation

    Poker 46 Level5 Advise I will advice but they decide Delegation Poker

51. 52

52. 53 Proposal Review Request プロリク レビュー プロリク コミッター ステークホルダー 1

    2 プロリク 3 代表取締役権限

53. 54 Negative Knowledge Risk Solution プロポーザル Background Objective Proposal Effect

    . レビュー Pros LGTM shipit Problem Protect

54. 55 全社サービスのリリースプロセス ステージング環境 開発環境 本番リリース #260_ #000_whole_company プロポーザル プロポーザル レビュー

    レビュー 反映 プロポーザル

55. 大阪本社 オフィス移転 ジム・運動 補助制度導入 採用事務 アウトソーシング リベラルアーツ 研究組織新設 自プロジェクトの椅子 をアーロンチェアに

    ２０台新調 R&D 予算確保 最大１億 2019. 3~4 56

56. 57 頻繁なデプロイと定期リリース

57. KATA STEP2 Decoupled for Conflict Avoidance 58 ෼ ࢄ •

    • •

58. 59 チーム スコープ Scope Structure team team team Scope

59. 60 Team Team コミッター コントリビューター コミッター コントリビューター コミッター コミッター コントリビューター

    Scope コミッター

60. 61 100_corporate 190_recruit 195_オフィス再設計 200_hr（人事） 209_Member_Analytics 205_benefit 300_Marketing 400_ASDI 900_Board

    310_product_develop 315_branding 320_pr_media 330_salespromotion 340_sales 342_hr_renewal 組織図の例 移

61. 62 Team Wiki Confluence

62. 63 マーケティング部 広報課 一般組織の例 部長 課長 部下 取材対応・プレスリリース 媒体広告・自社メディア ソーシャルメディア

    社内広報 危機管理 マーケティング戦略立案 マーケティング子チームの戦術適合調整 権限委譲 報告 意見 Slack 権限移譲の難しさ

63. 64 親チーム 子チーム 二重連結ピン（ダブルリンキング） コミッター コントリビューター コミット権限なし コミッター コントリビューター コミット権限なし

    制約条件 ダブルリンキング

64. 65 300_Marketing 320_pr_media 「PR・メディアチーム」の例 コミッター Ray George コントリビューター コントリビューター コミッター

    コミッター Ray George Yumi 取材対応・プレスリリース 媒体広告・自社メディア ソーシャルメディア 社内広報 危機管理 マーケティング戦略立案 マーケティング子チームの戦術適合調整 5000 コミット権限なし コミット権限なし

65. 66 権限構造の比較 入れ子構造 マーケティング部 広報課 部長 課長 部下 権限分散 マーケティングチーム

    広報チーム コミッター コミッター コントリビューター コントリビューター SPOF SPOF 冗長化 冗長化

66. 67 Seven Samurai Rule ７人

67. 68

68. 69 35,000 90,000 SLOC

69. 70 Larry Maccherone – from Impact of Agile Quantified Late

    2014 The Scrum Guide recommends a scrum team size of three to nine people

70. 71 Team Decoupling pattern • チームサイズは「５ー７名」が安定 • スクラムが浸透していれば９名でも生産性が落ちない事も • 但し、10名以上はつらい（リーダー不足あるいは抱え込むリーダータイプが要因もある

    ため） • 実際には、チームの成熟段階、未経験者の割合、プロジェクトの複雑性によって上 限は変わる • あまり人数にこだわる必要はなく、重要なのは、チーム内外に後方支援の役割がある かどうかが重要

71. 400_ASDI_rep 420_ Project Management Group Project の定義 TeamA1 430_UXUI Design

    Group 440_Serverside_Group 450_Front-end Group 460_Android Group 470_iOS Group 480_Infra SRE TeamB3 TeamC5 TeamD4 TeamE5 TeamF4 Project Responsibility

72. 73 Spotify Scaling Agile Squad プロダクトオーナー • Squad • •

    Scrum Squad Agile Team Squad（分隊） • Squad プロダクトオーナー

73. 74 Spotify Matrix Organization プロダクトオーナー Squad Tribe トライブリード Squad Squad

    Chapter チャプターリード • Tribe Squad • Tribe Tribe チャプターリード • Chapter • Chapter

74. 75 マトリクス型組織の課題 PO EM PO PO PO EM EM •

    PdM/PM/PO People Management/EM 移 メリット • PO EM • 移 • デメリット

75. Team 76 ゆめみでのプロジェクトとチームの関係性の変遷 Project member member Project member Team Project

    member Team Project Unit Project

76. 77 TeamA1 UXUI Design PM Server side Front-end Android iOS

    Infra SRE TeamB1 TeamC1 TeamD1 TeamE1 TeamF1 TeamG1 TeamA2 TeamB2 TeamC2 TeamD2 TeamE2 TeamF2 TeamG2 TeamA3 TeamB3 TeamC3 TeamD3 TeamE3 TeamF3 TeamG3 TeamB4 TeamC4 TeamE4 TeamF4 TeamC5 TeamE5 Project1 Project2 Project3 Project4 • • Spotify Tribe • Spotify 過去の経緯 Group プロジェクトとチームの関係性

77. 78 From Matrix Model to YUMEMI Model PO VPoP Team

    Tech EM PO PO Team Team TeamA1 TeamB1 TeamC1 TeamD1 TeamA2 TeamB2 TeamC2 TeamD2 TeamA3 TeamB3 TeamC3 TeamD3 Project1 Project2 Project3 • Agile Team • PO/EM 移 •

78. 79 Role Design (Scope) (Role) A B C TBD TBD

    TBD a Team

79. Role Design 柔軟な役割設計 Project1 Project3 iOS Team A Project4 Android

    Team B Project3 Project5 Project7 Benefit • • 特徴

80. 1クリック部署異動 100_corporate 190_recruit 195_オフィス再設計 200_hr（人事） 209_Member_Analytics 205_benefit 300_Marketing #195_オフィス再設計 Slack

    Slack JOIN

81. KATA STEP3 Alignment with Expectations 82 • • ڠ ௐ

82. 83 プロポーザル レビュー レビュー プロリク コミッター ステークホルダー プロリクのレビュー • •

    領 We Team プロリクのレビュー

83. Role Role 84 Role Contribution コミッター Role Role Role コミッター

    コミッター コミッター TBD Role Role コミッター コントリビューター Role Role Role コミッター コミッター コミッター コントリビューター

84. 85 新規チーム作成によるスコープカバー 100_corporate 190_採用チーム 191_東京本社採用 192_京都本社採用 193_大阪本社採用 コミッター コントリビューター プロリク

    大阪本社採用チームの チーム作成提案 コミッター 作成

85. 89 リードチーム team team team チームが増えてくると方向性がずれてくる team リードチームが全体最適の役割を担う team team

    team lead team a Group of Teams a Team of Teams リードチーム • •

86. 90 フラクタル構造 team as コントリビューター team team team as コミッター

    A Team ( of Teams ) a Team コントリビューター コミッター コントリビューター コントリビューター フラクタル構造を保ちながら組織がスケールしていくことが重要

87. 91 Projectにおけるリードチームの役割 UXUI TeamA1 PM Serverside Front-end Android iOS TeamB3

    TeamC5 TeamD4 TeamE5 TeamF4 プロジェクト テックリードチーム テックリードチーム テックリードチーム 後方支援 PMリードチーム デザインリードチーム テックリードチーム リードチーム

88. 92 協調のフラクタル構造 プロジェクト team team team Lead team Lead team

    team team team team team ・・・ リードチーム 委員会組織 Committee Committee

89. 93 プロリク 直感 理性 プロポーザル レビュー レビュー プロリク 経験

90. 94 リンゲルマン効果（社会的手抜）

91. 95 二重のメンバーシップ設計 社員契約 メンバーオプション 契約

92. 96 イエローカードによる抑止

93. 97 イエローカードの対象禁止行為 • • • • • • SNS •

    • • Bad News Fast •

94. 5 Design Concept

95. 99 共感・直感 心を動かす Art Design Engineering 全体・部分の 可視化 選択・組み合わせ

96. 直感と感性で最適な行動をとる事ができる 天才 真似をして器用に最適な行動をとる事ができる 理屈やルールがないと動けない 理屈に囚われて柔軟性がない 秀才 鈍才

97. 理屈やルールに基づいて大胆に行動できる 感情に左右されずに原則に従って行動できる 鈍才 萬才 理屈やルールがないと動けない 理屈に囚われて柔軟性がない プロリク（理屈に基づいたルールを決めるルール）

98. 102 Game Master Design Game Play Player Game Game System

    Rule book Game System Designer Self Design

99. 103 We can control "Not You But We" We You

    We

100. 104 適応的≠自律＋分散＋協調 コントリビューター コミッター コントリビューター a team a team of

     teams , ,

101. 105 アジャイル組織の作り方まとめ • • • • • • • •

     •
102. None

103. Contact Me! 株式会社ゆめみ 東京都世田谷区三軒茶屋2-11-23 サンタワーズB棟 7階 facebook.com/raykataoka twitter.com/raykataoka ray@yumemi.co.jp +81

     3-5432-5801 128

104. Thank You for listening! Please contact me for any questions

     Icon: Font Awesome, the author is Dave Gandy (Changed the color by Photoshop) Typicons, the author is Stephen Hutchings (Changed the color by Photoshop) twitter @raykataoka