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

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

2. © DMM.com
私
石垣雅人(いしがきまさと)
・プラットフォーム事業本部
~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
約2年間の中でチームの中で行った
本セッションでお話すること
各フェーズ(組成→安定→高速→最適化)での
KAIZENの事例を紹介します。

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

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

6. © DMM.com
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
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
DMM.comについて / 組織体質について
安定から高速フェーズ : 2017年4月〜
高速から最適化フェーズ : 2017年11月〜
組成から安定フェーズ : 2016年7月~
最後に

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30. © DMM.com

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

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

33. © DMM.com
顧客 顧客
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
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
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
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
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
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
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
①現状のVSM
③改善プロセス
②理想(仮説)
のVSM
プロセス

41. © DMM.com
顧客 顧客
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
改善事例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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