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

Transcript

1. YUMEMI
   How to be designed as Organization being Agile ?
   アジャイル組織の作り方教えます
   

   View Slide

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
   

   View Slide

3. 1
   INTRODUCTION
   

   View Slide

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
   

   View Slide

5. Modern Dance Artist
   

   View Slide

6. Modern Martial Artist (Aikido)
   

   View Slide

7. Magic
   

   View Slide

8. Classic Guitar
   

   View Slide

9. Whistling
   

   View Slide

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

    View Slide

11. 2
    ABOUT US
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

17. 17
    一見するとカオス
    

    View Slide

18. 18
    not Be Chaos, but Into Chaos
    

    View Slide

19. Observe the Unpredictability
    

    View Slide

20. 20
    Keep Order in Chaos
    混沌 秩序
    

    View Slide

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

    View Slide

22. View Slide

23. View Slide

24. 24
    Boid Algorithm
    Cohesion Separation Alignment
    

    View Slide

25. Follow the Basic Principles
    

    View Slide

26. 3 KATAs ( Basic Principles )
    26
    to be Keep Order in Chaos
    Self-Control
    Decoupled for
    Conflict Avoidance
    Alignment with
    Expectations
    ࣗ཯ ෼ࢄ ڠௐ
    

    View Slide

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
    

    View Slide

28. 3
    Introduction and
    Notice
    

    View Slide

29. 29
    V U C A World
    Volatility
    不安定 不確実
    Uncertainty Complexity Ambiguity
    複雑 曖昧
    VUCA
    

    View Slide

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

    View Slide

31. 31
    ビジネスパートナー部門
    マーケティング 営業 オペレーション
    広報・コンプライアンス
    ファイナンス・人事
    Squad Squad
    Tribe
    Squad Squad
    Tribe
    Squad Squad
    Tribe
    Squad Squad
    Tribe
    プラットフォーム：インフラ・ミドルウェア＆アプリケーション・ITオペレーション
    トランスバーサルチーム：アジャイルオーケストラ・インフォメーションセキュリティ・COOオフィス
    ギルド
    DevOps
    Architecture
    Test
    

    View Slide

32. 32
    移
    

    View Slide

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

    View Slide

34. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

40. View Slide

41. 4
    HOW TO BE
    DESIGNED
    

    View Slide

42. 42
    ࣗ཯ ෼ࢄ ڠௐ
    

    View Slide

43. KATA STEP1
    Self-Control
    43
    ࣗ
    ཯
    

    View Slide

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.
    逆コンウェイの機動作戦
    

    View Slide

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
    

    View Slide

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

    View Slide

47. Self-Control
    Adaptive
    Person Team Organization
    48
    

    View Slide

48. More Adaptive Decision Making Process ?
    

    View Slide

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.
    

    View Slide

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

    View Slide

51. View Slide

52. 53
    Proposal Review Request プロリク
    レビュー
    プロリク
    コミッター
    ステークホルダー
    1
    2
    プロリク
    3 代表取締役権限
    

    View Slide

53. 54
    Negative Knowledge Risk Solution
    プロポーザル
    Background
    Objective
    Proposal
    Effect
    .
    レビュー
    Pros
    LGTM shipit
    Problem
    Protect
    

    View Slide

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

    View Slide

55. 大阪本社
    オフィス移転
    ジム・運動
    補助制度導入
    採用事務
    アウトソーシング
    リベラルアーツ
    研究組織新設
    自プロジェクトの椅子
    をアーロンチェアに
    ２０台新調
    R&D
    予算確保
    最大１億
    2019. 3~4
    56
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    組織図の例
    移
    

    View Slide

61. 62
    Team
    Wiki
    Confluence
    

    View Slide

62. 63
    マーケティング部
    広報課
    一般組織の例
    部長
    課長
    部下
    取材対応・プレスリリース
    媒体広告・自社メディア
    ソーシャルメディア
    社内広報
    危機管理
    マーケティング戦略立案
    マーケティング子チームの戦術適合調整
    権限委譲 報告 意見
    Slack
    権限移譲の難しさ
    

    View Slide

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

    View Slide

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

    View Slide

65. 66
    権限構造の比較
    入れ子構造
    マーケティング部
    広報課
    部長
    課長
    部下
    権限分散
    マーケティングチーム
    広報チーム
    コミッター
    コミッター コントリビューター
    コントリビューター
    SPOF
    SPOF
    冗長化
    冗長化
    

    View Slide

66. 67
    Seven Samurai Rule
    ７人
    

    View Slide

67. View Slide

68. 69
    35,000 90,000 SLOC
    

    View Slide

69. 70
    Larry Maccherone – from Impact of Agile Quantified Late 2014
    The Scrum Guide recommends a scrum team size of three to nine people
    

    View Slide

70. 71
    Team Decoupling pattern
    • チームサイズは「５ー７名」が安定
    • スクラムが浸透していれば９名でも生産性が落ちない事も
    • 但し、10名以上はつらい（リーダー不足あるいは抱え込むリーダータイプが要因もある
    ため）
    • 実際には、チームの成熟段階、未経験者の割合、プロジェクトの複雑性によって上
    限は変わる
    • あまり人数にこだわる必要はなく、重要なのは、チーム内外に後方支援の役割がある
    かどうかが重要
    

    View Slide

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
    

    View Slide

72. 73
    Spotify Scaling Agile
    Squad
    プロダクトオーナー
    • Squad
    •
    • Scrum
    Squad Agile Team
    Squad（分隊）
    • Squad
    プロダクトオーナー
    

    View Slide

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

    View Slide

74. 75
    マトリクス型組織の課題
    PO
    EM
    PO PO PO
    EM
    EM
    • PdM/PM/PO People Management/EM
    移
    メリット
    • PO EM
    •
    移
    •
    デメリット
    

    View Slide

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

    View Slide

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
    プロジェクトとチームの関係性
    

    View Slide

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 移
    •
    

    View Slide

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

    View Slide

79. Role Design 柔軟な役割設計
    Project1
    Project3
    iOS Team A
    Project4
    Android Team B
    Project3
    Project5
    Project7
    Benefit
    •
    •
    特徴
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

83. Role
    Role
    84
    Role Contribution
    コミッター
    Role Role
    Role
    コミッター
    コミッター
    コミッター TBD
    Role
    Role
    コミッター
    コントリビューター
    Role Role
    Role
    コミッター
    コミッター
    コミッター
    コントリビューター
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

87. 91
    Projectにおけるリードチームの役割
    UXUI
    TeamA1
    PM
    Serverside
    Front-end
    Android
    iOS
    TeamB3
    TeamC5
    TeamD4
    TeamE5
    TeamF4
    プロジェクト
    テックリードチーム
    テックリードチーム
    テックリードチーム
    後方支援 PMリードチーム
    デザインリードチーム
    テックリードチーム
    リードチーム
    

    View Slide

88. 92
    協調のフラクタル構造
    プロジェクト
    team
    team
    team
    Lead team
    Lead team
    team
    team
    team
    team
    team
    ・・・
    リードチーム 委員会組織
    Committee
    Committee
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

94. 5
    Design Concept
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

98. 102
    Game Master
    Design Game Play
    Player Game
    Game System
    Rule book
    Game System Designer
    Self Design
    

    View Slide

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

    View Slide

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

     View Slide

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

     View Slide

102. View Slide

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

     View Slide

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
     

     View Slide