VSM(ValueStreamMapping)によって 実現できたリリースまでに268.5hかかっていた時間を54.5hに短縮できた秘訣

2018/04/25 DevopsDays Tokyo 2018 登壇資料

Transcript

1. VSM(ValueStreamMapping) によって 実現できた 268.5hかかっていた時間を 54.5hに短縮できた秘訣 石垣雅人 - DMM.com Labo Co., Ltd. 2018/04/25 DevopsDays Tokyo 2018 リリースまでに
2. © DMM.com labo 私 2 石垣雅人(いしがきまさと) ・プラットフォーム開発部 第2グループ(会員基盤) Account(ID) , Auth , Personalinfo バックエンド基盤担当 スクラムチーム プロダクトオーナー (2017〜) ・DMM.com Labo 2015/04~ 新卒入社 Twitter @i35_267
3. © DMM.com labo { What is VSM… } 3 Idea Value
4. © DMM.com labo 4
5. © DMM.com labo 5 VSM(ValueStreamMapping) を活用しリリースまでのリードタイムを 268.5h(45日) → 54.5h(9日)に短縮した VSMの 書き方からムダの分析/改善方法の秘訣を紹介します。 本セッションでお話すること
6. © DMM.com 6 Agenda About DMM.com DMM.comについて / サービス開発体制について 開発プロセスの「ムダ」とVSM作成の意味について VSM作成の歩み 改善事例 最後に 6
7. © DMM.com 手のひらと世界にいろどりを。 人類の想像をはるかにこえるスピードとス ケールで、私たちの生活は変化していま す。 DMM.comは1999年から時代のニーズに 合わせた多彩なコンテンツを、独自プラット フォームで安定的に提供しています。 7 40以上の幅広いサービスを展開 サービスについて About DMM.com
8. © DMM.com labo DMM.comのサービス開発体制 8 SoR (B to B) System of Record SoE (B to C) Systems of Engagement Purchase ...etc Settlement Personalinfo BI ...etc Account Antifraud
9. © DMM.com labo DMM.comのサービス開発体制 9 SoR (B to B) System of Record SoE (B to C) Systems of Engagement Purchase ...etc Settlement Personalinfo BI ...etc Account Antifraud
10. © DMM.com labo 10 Purchase ...etc Settlement Personalinfo ...etc Account Antifraud BI DX(DeveloperExperience) SoR (B to B) System of Record SoE (B to C) Systems of Engagement DMM.comのサービス開発体制
11. © DMM.com labo 11 Purchase ...etc Settlement Personalinfo ...etc Account Antifraud BI DX(DeveloperExperience) SoR (B to B) System of Record SoE (B to C) Systems of Engagement DMM.comのサービス開発体制 スピーディーな基盤機能の提供 利益貢献できる機能 高品質な機能 DX(DeveloperExperience)
12. © DMM.com labo 12 Purchase ...etc Settlement Personalinfo ...etc Account Antifraud BI DX(DeveloperExperience) SoR (B to B) System of Record SoE (B to C) Systems of Engagement DMM.comのサービス開発体制 スピーディーな基盤機能の提供 利益貢献できる機能 高品質な機能 DX(DeveloperExperience) 開発プロセスのおけるリードタイム短縮
13. © DMM.com 13 Agenda About DMM.com DMM.comについて / サービス開発体制について 組織の「ムダ」とVSM作成の意味について VSM作成の歩み 改善事例 最後に
14. © DMM.com labo 14 チームが当時抱えていた開発プロセス の問題点
15. © DMM.com labo 15 Releaseまで 2日 会員登録機能を2日で開発した！ 早くリリースして効果測定したい 開発チーム + 2日 Days
16. © DMM.com labo 16 Releaseまで 16日 ステークホルダー① グループ内で承認が必要 → 承認MTGを2週間後に設定 +14日 + 2日 Days
17. © DMM.com labo 17 Releaseまで 30日 ステークホルダー② この部署にも確認が必要です。 → ディレクターを立てて調整するのに 2週間 +14日 +14日 + 2日 Days
18. © DMM.com labo 18 Releaseまで 32日 +14日 + 2日 +14日 + 2日 開発チーム リリースが自動化されていない。 → 詳細なリリース手順書を作成するのに2日 Days
19. © DMM.com labo 19 Releaseまで 32日 +14日 + 2日 +14日 + 2日 開発者 リリースが自動化されていない。 → 詳細なリリース手順書を作成するのに 2日 組織が大きくなるほど「ムダ」は増え続ける。 開発作業 : 12時間 (2日) リリースするまで : 192時間 (32日) ※ 1日6時間計算
20. © DMM.com labo 20 Releaseまで 32日 +14日 + 2日 +14日 + 2日 開発者 リリースが自動化されていない。 → 詳細なリリース手順書を作成するのに 2日 開発作業 : 12時間 (2日) リリースするまで : 192時間 (32日) ※ 1日6時間計算 まずは開発プロセスを可視化して「ムダ」を洗い出す = VSM (Value Stream Mapping)
21. © DMM.com 21 Agenda About DMM.com DMM.comについて / サービス開発体制について 開発プロセスの「ムダ」とVSM作成の意味について VSM作成の歩み 改善事例 最後に
22. © DMM.com labo 22 VSM作成の歩み TODO TODO 1. 書き方について 3. どこから 改善するべきか 2. ムダを発見する TODO
23. © DMM.com labo 23 1. 書き方について 2. ムダを発見する A.分析メソッド ~ムダの「見える化」~ 3. どこから 改善するべきか A.改善メソッド ~ECRSの原則~ A.4ステップ VSM作成の歩み 参考 : カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで http://kaizenjourney.jp/
24. © DMM.com labo 24 書き方 (Value Stream Mapping)
25. © DMM.com labo 25 プロセスのタイトル 1 2 プロセスタイム (PT ※+WT) 3 リードタイム(LT) 4 STEPS 4 完成と正確性の割合(aka %C/A)
26. © DMM.com labo 26 顧客 顧客 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
27. © DMM.com labo 27 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
28. © DMM.com labo 28 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
29. © DMM.com labo 29 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
30. © DMM.com labo 30 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
31. © DMM.com labo 31 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
32. © DMM.com labo 32 ①現状のVSM ③改善プロセス ②理想(仮説) のVSM プロセス
33. © DMM.com labo 33 顧客 顧客 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 大事なのは、改善ポイント(=ムダ)を見つけること ※ どう改善するかはまた別のレイヤーの話
34. © DMM.com labo 34 1. 書き方について 2. ムダを発見する Done！ A.分析メソッド ~ムダの「見える化」~ 3. どこから 改善するべきか TODO VSM作成の歩み 参考 : カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで http://kaizenjourney.jp/
35. © DMM.com labo 35 分析メソッド ~ムダの「見える化」~
36. © DMM.com labo 36 ある程度のプロセスグループに分ける。 1 2 プロセスグループごとにどのくらいの LTがかかっているか算出する %C/Aが発生していて手戻りが発生している箇所 2 STEPS & 3 POINTS 待ち時間が長くボトルネックとなっているプロセ ス付近 不安な作業や心配しながら作業している プロセス付近 1 3 2
37. © DMM.com labo 37 ある程度のプロセスグループに分ける。 1 2 プロセスグループごとにどのくらいの LTがかかっているか算出する %C/Aが発生していて手戻りが発生している箇所 2 STEPS & 3 POINTS 待ち時間が長くボトルネックとなっているプロセ ス付近 不安な作業や心配しながら作業している プロセス付近 カテゴリー分け ムダを発見 1 2 3 2 steps 3 points
38. © DMM.com labo 38 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% PT : 1h WT : 0h %C/A : 20% 12h 1h 100h 2h 開発チーム 1 1 会員登録機能作成 リリース作業 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 開発チーム ディレクター 5
39. © DMM.com labo 39 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% PT : 1h WT : 0h %C/A : 20% 12h 1h 100h 2h 開発チーム 1 1 会員登録機能作成 リリース作業 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 開発チーム ディレクター 5 ある程度のプロセスグループに分ける。 1
40. © DMM.com labo 40 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% PT : 1h WT : 0h %C/A : 20% 12h 1h 100h 2h 開発チーム 1 1 会員登録機能作成 リリース作業 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 開発チーム ディレクター 5 開発作業 ステークホルダーとの調整 リリース作業
41. © DMM.com labo 41 分析メソッド No 1 PT 不安な作業 ボトルネック グループ 開発作業 ステークホルダーとの調整 リリース作業 2 3 LT %C/A
42. © DMM.com labo 42 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% PT : 1h WT : 0h %C/A : 20% 12h 1h 100h 2h 開発チーム 1 1 会員登録機能作成 リリース作業 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 開発チーム ディレクター 5 開発作業 ステークホルダーとの調整 リリース作業 2 プロセスグループごとに どのくらいのLTがかかっているか算出する
43. © DMM.com labo 43 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% PT : 1h WT : 0h %C/A : 20% 12h 1h 100h 2h 開発チーム 1 1 会員登録機能作成 リリース作業 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 開発チーム ディレクター 5 開発作業 ステークホルダーとの調整 リリース作業 85h 102h 12h
44. © DMM.com labo 44 No 1 PT 不安な作業 ボトルネック グループ 開発作業 ステークホルダーとの調整 リリース作業 2 3 LT 10h 1h 1h 12h 85h 102h %C/A 分析メソッド
45. © DMM.com labo 45 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% PT : 1h WT : 0h %C/A : 20% 12h 1h 100h 2h 開発チーム 1 1 会員登録機能作成 リリース作業 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) PT : 1h WT : 0h %C/A : 70% 承認MTG 84h 開発チーム ディレクター 5 開発作業 ステークホルダーとの調整 リリース作業 12h 85h 102h 待ち時間が長くボトルネックとなっているプロセス付近 1
46. © DMM.com labo 100h 84h 46 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% PT : 1h WT : 0h %C/A : 20% 12h 1h 2h 開発チーム 1 1 会員登録機能作成 リリース作業 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) PT : 1h WT : 0h %C/A : 70% 承認MTG 開発チーム ディレクター 5 開発作業 ステークホルダーとの調整 リリース作業 12h 102h 85h
47. © DMM.com labo 47 No 1 PT 不安な作業 ボトルネック グループ 開発作業 ステークホルダーとの調整 リリース作業 2 3 LT 10h 1h 1h 12h 85h 102h %C/A 開発完了から「承 認MTG」 実施までの84hが ムダ 承認MTGを経て のリリースまでが 長い。 分析メソッド
48. © DMM.com labo 48 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% PT : 1h WT : 0h %C/A : 20% 12h 1h 2h 開発チーム 1 1 会員登録機能作成 リリース作業 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) PT : 1h WT : 0h %C/A : 70% 承認MTG 開発チーム ディレクター 5 開発作業 ステークホルダーとの調整 リリース作業 12h 85h 102h 84h 100h %C/Aが発生していて手戻りが発生している箇所 2
49. © DMM.com labo 49 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% 12h 1h 2h 開発チーム 1 1 会員登録機能作成 リリース作業 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) 承認MTG 開発チーム ディレクター 5 開発作業 ステークホルダーとの調整 リリース作業 12h 85h 102h 84h 100h PT : 1h WT : 0h %C/A : 70% PT : 1h WT : 0h %C/A : 20%
50. © DMM.com labo 50 No 1 PT 不安な作業 ボトルネック グループ 開発作業 ステークホルダーとの調整 リリース作業 2 3 LT 10h 1h 1h 12h 85h 102h %C/A 70% 仕様の漏れ による手戻り 20% 手動リリース 失敗による 再リリース 開発完了から「承 認MTG」 実施までの84hが ムダ 承認MTGを経て のリリースまでが 長い。 分析メソッド
51. © DMM.com labo 51 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% 12h 1h 2h 開発チーム 1 1 会員登録機能作成 リリース作業 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) 承認MTG 開発チーム ディレクター 5 開発作業 ステークホルダーとの調整 リリース作業 12h 85h 102h 84h 100h PT : 1h WT : 0h %C/A : 70% PT : 1h WT : 0h %C/A : 20% 不安な作業や心配しながら作業しているプロセス付近 3
52. © DMM.com labo 52 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% 12h 1h 2h 開発チーム 1 会員登録機能作成 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) 承認MTG ディレクター 5 開発作業 ステークホルダーとの調整 リリース作業 12h 85h 102h 84h 100h PT : 1h WT : 0h %C/A : 70% PT : 1h WT : 0h %C/A : 20% 1 リリース作業 開発チーム
53. © DMM.com labo 53 No 1 PT 不安な作業 ボトルネック 手動をなくし リリース作業を 自動化する グループ 開発作業 ステークホルダーとの調整 リリース作業 2 3 LT 10h 1h 1h 12h 85h 102h %C/A 70% 仕様の漏れ による手戻り 20% 手動リリース 失敗による 再リリース 開発完了から「承 認MTG」 実施までの84hが ムダ 承認MTGを経て のリリースまでが 長い。 分析メソッド
54. © DMM.com labo 54 1. 書き方について 2. ムダを発見する Done！ A.改善メソッド ~ECRSの原則~ Done！ 3. どこから 改善するべきか VSM作成の歩み 参考 : カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで http://kaizenjourney.jp/
55. © DMM.com labo 55 改善メソッド ~ECRSの原則~
56. © DMM.com labo 56 改善メソッド ECRSの原則 ・・・業務効率を行う4原則をもとにした改善プロセス 1. Eliminate(排除) : そのプロセスは本当に必要な業務かどうか。 2. Combine(結合) : 作業分担をしずぎて、逆に待ち時間のムダを発生させていないか。 3. Rearrange(交換) : プロセスの順番を入れ替えることで効率化を測れないか。 4. Simplify (簡素化) : 作業を簡易化することで効率化できないか。
57. © DMM.com labo 57 改善メソッド ECRSの原則 ・・・業務効率を行う4原則をもとにした改善プロセス 1. Eliminate(排除) : そのプロセスは本当に必要な業務かどうか。 2. Combine(結合) : 作業分担をしずぎて、逆に待ち時間のムダを発生させていないか。 3. Rearrange(交換) : プロセスの順番を入れ替えることで効率化を測れないか。 4. Simplify (簡素化) : 作業を簡易化することで効率化できないか。 1→2→3→4の順番で改善していく
58. © DMM.com labo 58 改善メソッド ECRSの原則 ・・・業務効率を行う4原則をもとにした改善プロセス 1. Eliminate(排除) : そのプロセスは本当に必要な業務かどうか。 2. Combine(結合) : 作業分担をしずぎて、逆に待ち時間のムダを発生させていないか。 3. Rearrange(交換) : プロセスの順番を入れ替えることで効率化を測れないか。 4. Simplify (簡素化) : 作業を簡易化することで効率化できないか。
59. © DMM.com labo 59 No 1 PT 不安な作業 ボトルネック 手動をなくし リリース作業を 自動化する グループ 開発作業 ステークホルダーとの調整 リリース作業 2 3 LT 10h 1h 1h 12h 85h 102h %C/A 70% 仕様の漏れ による手戻り 20% 手動リリース 失敗による 再リリース 開発完了から「承 認MTG」 実施までの84hが ムダ 承認MTGを経て のリリースまでが 長い。 分析メソッド E E R S
60. © DMM.com labo 60 顧客 顧客 GitHub Ato GitHub Atom PT : 10h WT : 2h %C/A : 0% 12h 1h 2h 開発チーム 1 会員登録機能作成 GitHub Atom GCP ブラウザ VSM (Value Stream Mapping) 承認MTG ディレクター 5 84h 100h E E PT : 1h WT : 0h %C/A : 70% PT : 1h WT : 0h %C/A : 20% R 1 リリース作業 開発チーム S
61. © DMM.com labo 61 1. 書き方について 2. ムダを発見する Done！ Done！ 3. どこから 改善するべきか Done！ VSM作成の歩み 参考 : カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで http://kaizenjourney.jp/
62. © DMM.com 62 Agenda About DMM.com DMM.comについて / サービス開発体制について 開発プロセスの「ムダ」とVSM作成の意味について VSM作成の歩み 改善事例 最後に
63. © DMM.com labo 改善事例 63
64. © DMM.com labo 複数のVSMから見える共通点 グループ ステークホルダーとの調整 開発作業 リリース準備 + 作業 Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 2 3 64
65. © DMM.com labo ステークホルダーとの調整 開発作業 リリース準備 + 作業 複数のVSMから見える共通点 リードタイム : 268.5h Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 2 3 グループ 65
66. © DMM.com labo ステークホルダーとの調整 開発作業 リリース準備 + 作業 約85% 約5% 約10% 複数のVSMから見える共通点 (228.25h) (14h) (26.25h) Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 2 3 グループ リードタイム : 268.5h 66
67. © DMM.com labo カテゴリー ステークホルダーとの調整 開発作業 リリース準備 + 作業 約85% 約5% 約10% 4つのVSMから見える共通点 ほぼすべてのVSMがこの比率になった。 チームの行動パターン(開発プロセス)は一緒である。 この時点で「開発効率」をあげてもムダだと判断できた。 67
68. © DMM.com labo カテゴリー ステークホルダーとの調整 開発作業 リリース準備 + 作業 約85% 約5% 約10% 複数のVSMから見える共通点 (228.25h) (14h) (26.25h) Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 3 2 リードタイム : 268.5h 68
69. © DMM.com labo ≈≈ カテゴリー 複数のVSMから見える共通点 Eliminate（排除) : そのプロセスは本当に必要な業務かどうか。 MTGする意味(Why)を明確し、 不要なMTGの削除を推進 簡単な会話はSlackで完結。随時質問・疑問を解決できる環境 ステークホルダーとの調整 約85% (228.25h) Featureをリリースするために必要な調整。MTGが多い 1 リードタイム : 268.5h 69
70. © DMM.com labo ≈≈ カテゴリー 約10% 複数のVSMから見える共通点 (26.25h) リリースするための申請やリリース作業 3 chatopsによるOneClickDeploy / DeploymentPipeline + リリース申請フローをWhyを明確に削除を推進 リリース準備 + 作業 リードタイム : 268.5h Simplify (簡素化) : 作業を簡易化することで効率化できないか。 70 Eliminate（排除) : そのプロセスは本当に必要な業務かどうか。
71. © DMM.com labo 71 ステークホルダーとの調整 : 228.25h → リリース準備 + 作業 : 26.25h →
72. © DMM.com labo 72 ステークホルダーとの調整 : 228.25h →40hに短縮 リリース準備 + 作業 : 26.25h → 5mに短縮 268.5h (45日) 54.5h (9日) 早くサービス側に機能提供できる。
73. © DMM.com 73 Agenda About DMM.com DMM.comについて / サービス開発体制について 開発プロセスの「ムダ」とVSM作成の意味について VSM作成の歩み 改善事例 最後に
74. © DMM.com labo 最後に 74
75. © DMM.com labo { What is VSM… } 75 Idea Value
76. © DMM.com labo { What is VSM… } 76 Idea Value 開発プロセスを可視化する
77. © DMM.com labo { What is VSM… } 77 Idea Value 開発プロセスを可視化する 設計
78. © DMM.com labo { What is VSM… } 78 Idea Value 問題を共有するのに難しいことはいらない。 明日からすぐにVSMを作ろう。
79. © DMM.com labo 79 ご清聴ありがとうございました。