チームを『組成→安定→高速→最適化』に導くKAIZEN メソッド郡

2018/08/18 カイゼンジャーニー・カンファレンス 登壇資料

Transcript

1. チームを 『組成→安定→高速→最適化』 石垣雅人 - DMM.com 2018/08/18 カイゼンジャーニー・カンファレンス に導く KAIZEN メソッド郡
2. © 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
3. © DMM.com 3 3 約2年間の中でチームの中で行った 本セッションでお話すること 各フェーズ(組成→安定→高速→最適化)での KAIZENの事例を紹介します。
4. © DMM.com 4 Agenda About DMM.com DMM.comについて / 組織体質について 安定から高速フェーズ : 2017年4月〜 高速から最適化フェーズ : 2017年11月〜 4 4 組成から安定フェーズ : 2016年7月~ 最後に
5. © DMM.com 手のひらと世界にいろどりを。 人類の想像をはるかにこえるスピードとス ケールで、私たちの生活は変化していま す。 DMM.comは1999年から時代のニーズに 合わせた多彩なコンテンツを、独自プラット フォームで安定的に提供しています。 5 40以上の幅広いサービスを展開 サービスについて About DMM.com
6. © 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
7. © 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
8. © DMM.com 8 Agenda About DMM.com DMM.comについて / 組織体質について 安定から高速フェーズ : 2017年4月〜 高速から最適化フェーズ : 2017年11月〜 8 8 組成から安定フェーズ : 2016年7月~ 最後に
9. © DMM.com 9 9 Personalinfo Account Product プロダクトをそのまま新しいチームへ引き継ぎ 組成から安定フェーズ : 2016年7月~ チーム組成
10. © DMM.com 10 10 Personalinfo Account Product プロダクトをそのまま新しいチームへ引き継ぎ 組成から安定フェーズ : 2016年7月~ 障害多発 ※数ヶ月で大規模障害2,3件。 引き継ぎ直後....
11. © DMM.com 11 11 組成から安定フェーズ : 2016年7月~ 早急に改善策を ・リリース手順書作成 ・ダブルチェック体制 ・レビュアー追加 応急処置
12. © DMM.com 12 12 組成から安定フェーズ : 2016年7月~ 早急に改善策を ・リリース手順書作成 ・ダブルチェック体制 ・レビュアー追加 応急処置 障害はなくなったか
13. © DMM.com 13 13 組成から安定フェーズ : 2016年7月~ 早急に改善策を ・リリース手順書作成 ・ダブルチェック体制 ・レビュアー追加 応急処置 多発ではないが時々ある。 障害はなくなったか
14. © DMM.com 14 14 組成から安定フェーズ : 2016年7月~ 本質的なところを見る。 障害損害額の観点から見ると障害は発生しても、 復旧が早ければ障害にならない。 = いかに早く復旧できるかがカギになる。
15. © DMM.com 15 15 組成から安定フェーズ : 2016年7月~ 『KAIZEN Method ①』 Disaster in recovery training 〜障害訓練〜
16. © DMM.com 16 16 Disaster in recovery training 『障害シナリオ』をもとに意図的にシステムに障害を起こし、対応者が いかに早く障害を復旧させるかのプロセスを学習するプログラムで す。 Production Stress COPY
17. © DMM.com 17 効果の仮説 原因追求のアプローチ改善 障害起因に対して、障害原因の箇所の「追求」から「発見」に至るまでのアプローチ方法を改善するこ とで、全体を通した復旧までの時間を短縮する 復旧までのアプローチ改善 障害原因を「発見」したら、いかにその障害を早く「復旧」させるかのアプローチの仕方を改善すること で全体を通した復旧までの時間を短縮する。 報連相の粒度・質・タイミングの改善 報告をエスカレーションする必要がある場合は、どんな報告・連絡・相談をするべきかをある程度標 準化することで全体を通した復旧までの時間を短縮する。
18. © DMM.com 18 効果の仮説 原因追求のアプローチ改善 障害起因に対して、障害原因の箇所の「追求」から「発見」に至るまでのアプローチ方法を改善するこ とで、全体を通した復旧までの時間を短縮する 復旧までのアプローチ改善 障害原因の「発見」したら、いかにその障害を早く「復旧」させるかのアプローチの仕方を改善するこ とで全体を通した復旧までの時間を短縮する。 報連相の粒度・質・タイミングの改善 報告をエスカレーションする必要がある場合は、どんな報告・連絡・相談をするべきかをある程度標 準化することで全体を通した復旧までの時間を短縮する。 実施までの流れ 実施前 実施時 実施後
19. © DMM.com 実施前 : シナリオ作成 設定ミスによるOutOfMemoryの発生。 アプリケーションの非同期処理のためにスレッドプールを利用していますが、 誤った設定値によりス レッドが過多に生成されて、 OutOfMemoryが発生します。外部API呼び出しの終了待ちが長く、スレッ ドがプールになかなか返却されない状況下で、スレッドプールの要素数が大きい場合は、ひとつのプロ セスで生成できるスレッド数の上限に達することを学んでもらいます。 ex. 19
20. © DMM.com 実施前 : 役割決め 対応者 20 障害起因者 記録者 障害おこす 復旧させる
21. © DMM.com 実施時の注意 対応プロセスを記録する 21
22. © DMM.com 実施後の注意 振り返りの実施 対応プロセスの読み合わせ KPT 22
23. © DMM.com 23 効果の仮説→検証
24. © DMM.com https://inside.dmm.com/entry/2018/08/07/disaster-in-recovery-training 24 もっと詳しい詳細については下記のブログで
25. © DMM.com 25 Agenda About DMM.com DMM.comについて / 組織体質について 安定から高速フェーズ : 2017年4月〜 高速から最適化フェーズ : 2017年11月〜 25 25 組成から安定フェーズ : 2016年7月~ 最後に
26. © DMM.com 26 安定から高速フェーズ : 2017年4月〜 インシデント管理向上により、稼働率Up 安定期へ
27. © DMM.com 27 安定から高速フェーズ : 2017年4月〜 インシデント管理向上により、稼働率Up 安定期へ 早急にチームとして安定させるため 応急処置が多く、 開発プロセスの『ムダ』が見え始めた。
28. © DMM.com 28 安定から高速フェーズ : 2017年4月〜 インシデント管理向上により、稼働率Up 安定期へ 早急に安定させるために応急処置が多く、 開発プロセスの『ムダ』が見え始めた。 『KAIZEN Method ②』 Value Stream Mapping
29. © DMM.com 29 { What is VSM… } 29 Idea Value
30. © DMM.com 30
31. © DMM.com 31 31 書き方 (Value Stream Mapping)
32. © DMM.com 32 4 STEPS プロセスのタイトル 1 2 プロセスタイム (PT ※+WT) 3 リードタイム(LT) 4 完成と正確性の割合(aka %C/A)
33. © 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
34. © 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
35. © 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
36. © 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
37. © 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
38. © 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
39. © 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
40. © DMM.com 40 40 40 ①現状のVSM ③改善プロセス ②理想(仮説) のVSM プロセス
41. © 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 大事なのは、改善ポイント(=ムダ)を見つけること ※ どう改善するかはまた別のレイヤーの話
42. © DMM.com 42 42 改善事例
43. © DMM.com 43 43 VSMから見える共通点 グループ ステークホルダーとの調整 開発作業 リリース準備 + 作業 Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 2 3
44. © DMM.com 44 44 ステークホルダーとの調整 開発作業 リリース準備 + 作業 VSMから見える共通点 リードタイム : 268.5h Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 2 3 グループ
45. © DMM.com 45 45 ステークホルダーとの調整 開発作業 リリース準備 + 作業 約85% 約5% 約10% VSMから見える共通点 (228.25h) (14h) (26.25h) Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 2 3 グループ リードタイム : 268.5h
46. © DMM.com 46 46 カテゴリー ステークホルダーとの調整 開発作業 リリース準備 + 作業 約85% 約5% 約10% 4つのVSMから見える共通点 ほぼすべてのVSMがこの比率になった。 チームの行動パターン(開発プロセス)は一緒である。 この時点で「開発効率」をあげてもムダだと判断できた。
47. © DMM.com 47 47 カテゴリー ステークホルダーとの調整 開発作業 リリース準備 + 作業 約85% 約5% 約10% VSMから見える共通点 (228.25h) (14h) (26.25h) Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 3 2 リードタイム : 268.5h
48. © DMM.com 48 48 48 ステークホルダーとの調整 : 228.25h → リリース準備 + 作業 : 26.25h →
49. © DMM.com 49 49 49 ステークホルダーとの調整 : 228.25h →40hに短縮 リリース準備 + 作業 : 26.25h → 5mに短縮 268.5h (45日) 54.5h (9日)
50. © DMM.com 50 Agenda About DMM.com DMM.comについて / 組織体質について 安定から高速フェーズ : 2017年4月〜 高速から最適化フェーズ : 2017年11月〜 50 50 組成から安定フェーズ : 2016年7月~ 最後に
51. © DMM.com 51 高速から最適化フェーズ : 2017年11月〜 プロセスは良くなった。 システムは安定しているし高速化もできた。 (稼働率UP) (リードタイム短縮)
52. © DMM.com 52 高速から最適化フェーズ : 2017年11月〜 プロセスは良くなった。 システムは安定しているし高速化もできた。 次は、そのプロセスの流れに存在する 組織の最適化を行う。 (稼働率UP) (リードタイム短縮)
53. © DMM.com 53 53 『KAIZEN Method ③』 高速から最適化フェーズ : 2017年11月〜 ScrumTeam 組織再設計
54. © DMM.com 当時の問題点 定義にあっていないスクラム ビジネスレイヤーと開発レイヤーとの 情報共有ができていなかった。 POの負荷が大きい。 54
55. © DMM.com 当時の問題点 何をするか / 何をしないか 現状にあった役割定義 仕事量・質は変えない 左にあるようにこの改造で仕事が 増えたり減ったりはしません。 この改造によって今の仕事のスタイル を変えることはありません。あくまでも 現状にあった役割を定義します。 提案を通す際のポイント 55
56. © DMM.com 当時の問題点 定義にあっていないスクラム ビジネスレイヤーと開発レイヤーとの 情報共有ができていなかった。 POの負荷が大きい。 56
57. © DMM.com なんちゃってスクラム状態 PO, SMの人事交代(現状にあった役割を当てはめる ) ビジネスレイヤーと開発レイヤーとの 情報共有ができていなかった。 POの負荷が大きい。 当時の問題点 57
58. © DMM.com ビジネスレイヤーと開発レイヤーとの 情報共有ができていなかった。 なんちゃってスクラム状態 PO, SMの人事交代(現状にあった役割を当てはめる ) 当時の問題点 POTeam(Product Ownership Team)発足。 コミュニケションライン追加 POの負荷が大きい。 58
59. © DMM.com POの負荷が大きい。 ビジネスレイヤーと開発レイヤーとの 情報共有ができていなかった。 なんちゃってスクラム状態 PO, SMの人事交代(現状にあった役割を当てはめる ) 当時の問題点 POP(ProductOwnerProxy) 配置 POTeam(Product Ownership Team)発足。 コミュニケションライン追加 59
60. © DMM.com POの負荷が大きい。 ビジネスレイヤーと開発レイヤーとの 情報共有ができていなかった。 なんちゃってスクラム状態 PO, SMの人事交代(現状にあった役割を当てはめる ) 当時の問題点 POTeam発足。 コミュニケションライン追加 POP(ProductOwnerProxy) 配置 役割を細分化し、疎結合の部分をつなぐ コミュニケーションラインを増やすことで さらに開発プロセスが明確になった。 効果 60
61. © DMM.com 61 Agenda About DMM.com DMM.comについて / 組織体質について 安定から高速フェーズ : 2017年4月〜 高速から最適化フェーズ : 2017年11月〜 61 61 組成から安定フェーズ : 2016年7月~ 最後に
62. © DMM.com 『組成→安定→高速→最適化』 ScrumTeam 組織再設計 Disaster in recovery training ValueStreamMapping 『KAIZEN Method ①』 『KAIZEN Method ②』 『KAIZEN Method ③』 62
63. © DMM.com これからの立ち位置 新チーム発足 : Customer Decision Support Team 63
64. © DMM.com これからの立ち位置 https://dmm-corp.com/recruit/engineer/5366 絶賛募集中です！ 64
65. © DMM.com ご清聴ありがとうございました！ 65