DevopsDays Tokyo 2018

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
100h84h
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
102h85h

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（排除) : そのプロセスは本当に必要な業務かどうか。
x

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
ご清聴ありがとうございました。