Tweet
Tweet

Slide 1

Slide 1 text

チームを 『組成→安定→高速→最適化』 石垣雅人 - DMM.com 2018/08/18 カイゼンジャーニー・カンファレンス に導く KAIZEN メソッド郡

Slide 2

Slide 2 text

© DMM.com 2 私 石垣雅人(いしがきまさと) ・プラットフォーム事業本部 ~2018/07 : Account(ID) , Auth , Personalinfo : Backend System ・DMM.com Labo(現:DMM.com) 2015/04~ Scrum Team : Product Owner(2017〜) @i35_267 2018/07 ~ : Customer Review, Push

Slide 3

Slide 3 text

© DMM.com 3 3 約2年間の中でチームの中で行った 本セッションでお話すること 各フェーズ(組成→安定→高速→最適化)での KAIZENの事例を紹介します。

Slide 4

Slide 4 text

© DMM.com 4 Agenda About DMM.com DMM.comについて / 組織体質について 安定から高速フェーズ : 2017年4月〜 高速から最適化フェーズ : 2017年11月〜 4 4 組成から安定フェーズ : 2016年7月~ 最後に

Slide 5

Slide 5 text

© DMM.com 手のひらと世界にいろどりを。 人類の想像をはるかにこえるスピードとス ケールで、私たちの生活は変化していま す。 DMM.comは1999年から時代のニーズに 合わせた多彩なコンテンツを、独自プラット フォームで安定的に提供しています。 5 40以上の幅広いサービスを展開 サービスについて About DMM.com

Slide 6

Slide 6 text

© DMM.com 6 6 DMM.comのサービス開発体制 SoR (B to B) System of Record SoE (B to C) Systems of Engagement Purchase ...etc Settlement Personalinfo Push ...etc Account Antifraud

Slide 7

Slide 7 text

© DMM.com 7 7 Purchase ...etc Settlement Personalinfo Push ...etc Account Antifraud DX(DeveloperExperience) DMM.comのサービス開発体制 SoR (B to B) System of Record SoE (B to C) Systems of Engagement

Slide 8

Slide 8 text

© DMM.com 8 Agenda About DMM.com DMM.comについて / 組織体質について 安定から高速フェーズ : 2017年4月〜 高速から最適化フェーズ : 2017年11月〜 8 8 組成から安定フェーズ : 2016年7月~ 最後に

Slide 9

Slide 9 text

© DMM.com 9 9 Personalinfo Account Product プロダクトをそのまま新しいチームへ引き継ぎ 組成から安定フェーズ : 2016年7月~ チーム組成

Slide 10

Slide 10 text

© DMM.com 10 10 Personalinfo Account Product プロダクトをそのまま新しいチームへ引き継ぎ 組成から安定フェーズ : 2016年7月~ 障害多発 ※数ヶ月で大規模障害2,3件。 引き継ぎ直後....

Slide 11

Slide 11 text

© DMM.com 11 11 組成から安定フェーズ : 2016年7月~ 早急に改善策を ・リリース手順書作成 ・ダブルチェック体制 ・レビュアー追加 応急処置

Slide 12

Slide 12 text

© DMM.com 12 12 組成から安定フェーズ : 2016年7月~ 早急に改善策を ・リリース手順書作成 ・ダブルチェック体制 ・レビュアー追加 応急処置 障害はなくなったか

Slide 13

Slide 13 text

© DMM.com 13 13 組成から安定フェーズ : 2016年7月~ 早急に改善策を ・リリース手順書作成 ・ダブルチェック体制 ・レビュアー追加 応急処置 多発ではないが時々ある。 障害はなくなったか

Slide 14

Slide 14 text

© DMM.com 14 14 組成から安定フェーズ : 2016年7月~ 本質的なところを見る。 障害損害額の観点から見ると障害は発生しても、 復旧が早ければ障害にならない。 = いかに早く復旧できるかがカギになる。

Slide 15

Slide 15 text

© DMM.com 15 15 組成から安定フェーズ : 2016年7月~ 『KAIZEN Method ①』 Disaster in recovery training 〜障害訓練〜

Slide 16

Slide 16 text

© DMM.com 16 16 Disaster in recovery training 『障害シナリオ』をもとに意図的にシステムに障害を起こし、対応者が いかに早く障害を復旧させるかのプロセスを学習するプログラムで す。 Production Stress COPY

Slide 17

Slide 17 text

© DMM.com 17 効果の仮説 原因追求のアプローチ改善 障害起因に対して、障害原因の箇所の「追求」から「発見」に至るまでのアプローチ方法を改善するこ とで、全体を通した復旧までの時間を短縮する 復旧までのアプローチ改善 障害原因を「発見」したら、いかにその障害を早く「復旧」させるかのアプローチの仕方を改善すること で全体を通した復旧までの時間を短縮する。 報連相の粒度・質・タイミングの改善 報告をエスカレーションする必要がある場合は、どんな報告・連絡・相談をするべきかをある程度標 準化することで全体を通した復旧までの時間を短縮する。

Slide 18

Slide 18 text

© DMM.com 18 効果の仮説 原因追求のアプローチ改善 障害起因に対して、障害原因の箇所の「追求」から「発見」に至るまでのアプローチ方法を改善するこ とで、全体を通した復旧までの時間を短縮する 復旧までのアプローチ改善 障害原因の「発見」したら、いかにその障害を早く「復旧」させるかのアプローチの仕方を改善するこ とで全体を通した復旧までの時間を短縮する。 報連相の粒度・質・タイミングの改善 報告をエスカレーションする必要がある場合は、どんな報告・連絡・相談をするべきかをある程度標 準化することで全体を通した復旧までの時間を短縮する。 実施までの流れ 実施前 実施時 実施後

Slide 19

Slide 19 text

© DMM.com 実施前 : シナリオ作成 設定ミスによるOutOfMemoryの発生。 アプリケーションの非同期処理のためにスレッドプールを利用していますが、 誤った設定値によりス レッドが過多に生成されて、 OutOfMemoryが発生します。外部API呼び出しの終了待ちが長く、スレッ ドがプールになかなか返却されない状況下で、スレッドプールの要素数が大きい場合は、ひとつのプロ セスで生成できるスレッド数の上限に達することを学んでもらいます。 ex. 19

Slide 20

Slide 20 text

© DMM.com 実施前 : 役割決め 対応者 20 障害起因者 記録者 障害おこす 復旧させる

Slide 21

Slide 21 text

© DMM.com 実施時の注意 対応プロセスを記録する 21

Slide 22

Slide 22 text

© DMM.com 実施後の注意 振り返りの実施 対応プロセスの読み合わせ KPT 22

Slide 23

Slide 23 text

© DMM.com 23 効果の仮説→検証

Slide 24

Slide 24 text

© DMM.com https://inside.dmm.com/entry/2018/08/07/disaster-in-recovery-training 24 もっと詳しい詳細については下記のブログで

Slide 25

Slide 25 text

© DMM.com 25 Agenda About DMM.com DMM.comについて / 組織体質について 安定から高速フェーズ : 2017年4月〜 高速から最適化フェーズ : 2017年11月〜 25 25 組成から安定フェーズ : 2016年7月~ 最後に

Slide 26

Slide 26 text

© DMM.com 26 安定から高速フェーズ : 2017年4月〜 インシデント管理向上により、稼働率Up 安定期へ

Slide 27

Slide 27 text

© DMM.com 27 安定から高速フェーズ : 2017年4月〜 インシデント管理向上により、稼働率Up 安定期へ 早急にチームとして安定させるため 応急処置が多く、 開発プロセスの『ムダ』が見え始めた。

Slide 28

Slide 28 text

© DMM.com 28 安定から高速フェーズ : 2017年4月〜 インシデント管理向上により、稼働率Up 安定期へ 早急に安定させるために応急処置が多く、 開発プロセスの『ムダ』が見え始めた。 『KAIZEN Method ②』 Value Stream Mapping

Slide 29

Slide 29 text

© DMM.com 29 { What is VSM… } 29 Idea Value

Slide 30

Slide 30 text

© DMM.com 30

Slide 31

Slide 31 text

© DMM.com 31 31 書き方 (Value Stream Mapping)

Slide 32

Slide 32 text

© DMM.com 32 4 STEPS プロセスのタイトル 1 2 プロセスタイム (PT ※+WT) 3 リードタイム(LT) 4 完成と正確性の割合(aka %C/A)

Slide 33

Slide 33 text

© DMM.com 33 33 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% PT : 1h WT : 0h %C/A : 20% 12h 1h 100h 1h 開発チーム 1 1 会員登録機能作成 リリース作業 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 開発チーム ディレクター 5

Slide 34

Slide 34 text

© DMM.com 34 34 STEP 0 PT : Process Time WT : Wasting Time リードタイム (LT) プロセスのタイトル GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% 12h 1h 開発チーム 1 会員登録機能作成 PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 完成と正確性の割合 (%C/A) ディレクター 5

Slide 35

Slide 35 text

© DMM.com 35 35 STEP 1 PT : Process Time WT : Wasting Time リードタイム (LT) プロセスのタイトル GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% 12h 1h 開発チーム 1 会員登録機能作成 PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 完成と正確性の割合 (%C/A) ディレクター 5

Slide 36

Slide 36 text

© DMM.com 36 36 STEP 2 PT : Process Time WT : Wasting Time リードタイム (LT) プロセスのタイトル GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% 12h 1h 開発チーム 1 会員登録機能作成 PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 完成と正確性の割合 (%C/A) ディレクター 5

Slide 37

Slide 37 text

© DMM.com 37 37 STEP 3 PT : Process Time WT : Wasting Time リードタイム (LT) プロセスのタイトル GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% 12h 1h 開発チーム 1 会員登録機能作成 PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 完成と正確性の割合 (%C/A) ディレクター 5

Slide 38

Slide 38 text

© DMM.com 38 38 STEP 3 PT : Process Time WT : Wasting Time リードタイム (LT) プロセスのタイトル GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% 12h 1h 開発チーム 1 会員登録機能作成 PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 完成と正確性の割合 (%C/A) ディレクター 5

Slide 39

Slide 39 text

© DMM.com 39 39 STEP 4 PT : Process Time WT : Wasting Time リードタイム (LT) プロセスのタイトル GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% 12h 1h 開発チーム 1 会員登録機能作成 PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 完成と正確性の割合 (%C/A) ディレクター 5

Slide 40

Slide 40 text

© DMM.com 40 40 40 ①現状のVSM ③改善プロセス ②理想(仮説) のVSM プロセス

Slide 41

Slide 41 text

© DMM.com 41 41 41 顧客 顧客 GitHub Ato GitHub Atom LT : 12h PT : 10h WT : 2h %C/A : 0% LT : 1h PT : 1h WT : 0h %C/A : 20% 12h 1h 100h 2h 開発チーム 1 1 会員登録機能作成 リリース作業 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) LT : 1h PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 開発チーム ディレクター 5 大事なのは、改善ポイント(=ムダ)を見つけること ※ どう改善するかはまた別のレイヤーの話

Slide 42

Slide 42 text

© DMM.com 42 42 改善事例

Slide 43

Slide 43 text

© DMM.com 43 43 VSMから見える共通点 グループ ステークホルダーとの調整 開発作業 リリース準備 + 作業 Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 2 3

Slide 44

Slide 44 text

© DMM.com 44 44 ステークホルダーとの調整 開発作業 リリース準備 + 作業 VSMから見える共通点 リードタイム : 268.5h Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 2 3 グループ

Slide 45

Slide 45 text

© DMM.com 45 45 ステークホルダーとの調整 開発作業 リリース準備 + 作業 約85% 約5% 約10% VSMから見える共通点 (228.25h) (14h) (26.25h) Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 2 3 グループ リードタイム : 268.5h

Slide 46

Slide 46 text

© DMM.com 46 46 カテゴリー ステークホルダーとの調整 開発作業 リリース準備 + 作業 約85% 約5% 約10% 4つのVSMから見える共通点 ほぼすべてのVSMがこの比率になった。 チームの行動パターン(開発プロセス)は一緒である。 この時点で「開発効率」をあげてもムダだと判断できた。

Slide 47

Slide 47 text

© DMM.com 47 47 カテゴリー ステークホルダーとの調整 開発作業 リリース準備 + 作業 約85% 約5% 約10% VSMから見える共通点 (228.25h) (14h) (26.25h) Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 3 2 リードタイム : 268.5h

Slide 48

Slide 48 text

© DMM.com 48 48 48 ステークホルダーとの調整 : 228.25h → リリース準備 + 作業 : 26.25h →

Slide 49

Slide 49 text

© DMM.com 49 49 49 ステークホルダーとの調整 : 228.25h →40hに短縮 リリース準備 + 作業 : 26.25h → 5mに短縮 268.5h (45日) 54.5h (9日)

Slide 50

Slide 50 text

© DMM.com 50 Agenda About DMM.com DMM.comについて / 組織体質について 安定から高速フェーズ : 2017年4月〜 高速から最適化フェーズ : 2017年11月〜 50 50 組成から安定フェーズ : 2016年7月~ 最後に

Slide 51

Slide 51 text

© DMM.com 51 高速から最適化フェーズ : 2017年11月〜 プロセスは良くなった。 システムは安定しているし高速化もできた。 (稼働率UP) (リードタイム短縮)

Slide 52

Slide 52 text

© DMM.com 52 高速から最適化フェーズ : 2017年11月〜 プロセスは良くなった。 システムは安定しているし高速化もできた。 次は、そのプロセスの流れに存在する 組織の最適化を行う。 (稼働率UP) (リードタイム短縮)

Slide 53

Slide 53 text

© DMM.com 53 53 『KAIZEN Method ③』 高速から最適化フェーズ : 2017年11月〜 ScrumTeam 組織再設計

Slide 54

Slide 54 text

© DMM.com 当時の問題点 定義にあっていないスクラム ビジネスレイヤーと開発レイヤーとの 情報共有ができていなかった。 POの負荷が大きい。 54

Slide 55

Slide 55 text

© DMM.com 当時の問題点 何をするか / 何をしないか 現状にあった役割定義 仕事量・質は変えない 左にあるようにこの改造で仕事が 増えたり減ったりはしません。 この改造によって今の仕事のスタイル を変えることはありません。あくまでも 現状にあった役割を定義します。 提案を通す際のポイント 55

Slide 56

Slide 56 text

© DMM.com 当時の問題点 定義にあっていないスクラム ビジネスレイヤーと開発レイヤーとの 情報共有ができていなかった。 POの負荷が大きい。 56

Slide 57

Slide 57 text

© DMM.com なんちゃってスクラム状態 PO, SMの人事交代(現状にあった役割を当てはめる ) ビジネスレイヤーと開発レイヤーとの 情報共有ができていなかった。 POの負荷が大きい。 当時の問題点 57

Slide 58

Slide 58 text

© DMM.com ビジネスレイヤーと開発レイヤーとの 情報共有ができていなかった。 なんちゃってスクラム状態 PO, SMの人事交代(現状にあった役割を当てはめる ) 当時の問題点 POTeam(Product Ownership Team)発足。 コミュニケションライン追加 POの負荷が大きい。 58

Slide 59

Slide 59 text

© DMM.com POの負荷が大きい。 ビジネスレイヤーと開発レイヤーとの 情報共有ができていなかった。 なんちゃってスクラム状態 PO, SMの人事交代(現状にあった役割を当てはめる ) 当時の問題点 POP(ProductOwnerProxy) 配置 POTeam(Product Ownership Team)発足。 コミュニケションライン追加 59

Slide 60

Slide 60 text

© DMM.com POの負荷が大きい。 ビジネスレイヤーと開発レイヤーとの 情報共有ができていなかった。 なんちゃってスクラム状態 PO, SMの人事交代(現状にあった役割を当てはめる ) 当時の問題点 POTeam発足。 コミュニケションライン追加 POP(ProductOwnerProxy) 配置 役割を細分化し、疎結合の部分をつなぐ コミュニケーションラインを増やすことで さらに開発プロセスが明確になった。 効果 60

Slide 61

Slide 61 text

© DMM.com 61 Agenda About DMM.com DMM.comについて / 組織体質について 安定から高速フェーズ : 2017年4月〜 高速から最適化フェーズ : 2017年11月〜 61 61 組成から安定フェーズ : 2016年7月~ 最後に

Slide 62

Slide 62 text

© DMM.com 『組成→安定→高速→最適化』 ScrumTeam 組織再設計 Disaster in recovery training ValueStreamMapping 『KAIZEN Method ①』 『KAIZEN Method ②』 『KAIZEN Method ③』 62

Slide 63

Slide 63 text

© DMM.com これからの立ち位置 新チーム発足 : Customer Decision Support Team 63

Slide 64

Slide 64 text

© DMM.com これからの立ち位置 https://dmm-corp.com/recruit/engineer/5366 絶賛募集中です！ 64

Slide 65

Slide 65 text

© DMM.com ご清聴ありがとうございました！ 65