Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

1 2 3 4 5 Table of Contents 自己紹介 Before starting our presentation 会社説明 About Us イントロダクション introduction and notice 設計手法 how to be designed まとめ design concept 2

Slide 3

Slide 3 text

1 INTRODUCTION

Slide 4

Slide 4 text

Ray Toshiyuki Kataoka YUMEMI Inc. 1976 2000 1 100 1,000 EC 5,000 Company as a Service IT 2014 4 Sprocket 2 4

Slide 5

Slide 5 text

Modern Dance Artist

Slide 6

Slide 6 text

Modern Martial Artist (Aikido)

Slide 7

Slide 7 text

Magic

Slide 8

Slide 8 text

Classic Guitar

Slide 9

Slide 9 text

Whistling

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

2 ABOUT US

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

17 一見するとカオス

Slide 18

Slide 18 text

18 not Be Chaos, but Into Chaos

Slide 19

Slide 19 text

Observe the Unpredictability

Slide 20

Slide 20 text

20 Keep Order in Chaos 混沌 秩序

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

24 Boid Algorithm Cohesion Separation Alignment

Slide 25

Slide 25 text

Follow the Basic Principles

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

3 Introduction and Notice

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

32 移

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

34

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

37 General Manager Delegate General Manager SPOF Workflow Manager 移 Director

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

40

Slide 41

Slide 41 text

4 HOW TO BE DESIGNED

Slide 42

Slide 42 text

42 ࣗ཯ ෼ࢄ ڠௐ

Slide 43

Slide 43 text

KATA STEP1 Self-Control 43 ࣗ ཯

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Self-Control Adaptive Person Team Organization 48

Slide 48

Slide 48 text

More Adaptive Decision Making Process ?

Slide 49

Slide 49 text

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.

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

52

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

62 Team Wiki Confluence

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

67 Seven Samurai Rule ７人

Slide 67

Slide 67 text

68

Slide 68

Slide 68 text

69 35,000 90,000 SLOC

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

KATA STEP3 Alignment with Expectations 82 • • ڠ ௐ

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

5 Design Concept

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

No content

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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