Soumettre la recherche
Mettre en ligne
VSM(ValueStreamMapping)によって 実現できたリリースまでに268.5hかかっていた時間を54.5hに短縮できた秘訣
•
8 j'aime
•
9,422 vues
i35_267 Ishigaki
Suivre
DevopsDays Tokyo 2018
Lire moins
Lire la suite
Ingénierie
Signaler
Partager
Signaler
Partager
1 sur 79
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
VSM (Value Stream Mapping)を用いた開発プロセス可視化のお話
VSM (Value Stream Mapping)を用いた開発プロセス可視化のお話
i35_267 Ishigaki
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門
H Iseri
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Yasuharu Nishi
DevOps Overview
DevOps Overview
IIJ
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
App013 ここはあえて紙と
App013 ここはあえて紙と
Tech Summit 2016
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
Kinji Akemine
Recommandé
VSM (Value Stream Mapping)を用いた開発プロセス可視化のお話
VSM (Value Stream Mapping)を用いた開発プロセス可視化のお話
i35_267 Ishigaki
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門
H Iseri
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Yasuharu Nishi
DevOps Overview
DevOps Overview
IIJ
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
App013 ここはあえて紙と
App013 ここはあえて紙と
Tech Summit 2016
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
Kinji Akemine
ぱぱっと理解するSpring Cloudの基本
ぱぱっと理解するSpring Cloudの基本
kazuki kumagai
NetflixにおけるPresto/Spark活用事例
NetflixにおけるPresto/Spark活用事例
Amazon Web Services Japan
Jenkins 再入門
Jenkins 再入門
Jumpei Miyata
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
Hironori Washizaki
Google Cloud で実践する SRE
Google Cloud で実践する SRE
Google Cloud Platform - Japan
私にとってのテスト
私にとってのテスト
Takuto Wada
スクラムパタン入門
スクラムパタン入門
Kiro Harada
ユーザーストーリーマッピングを使ってプロダクトバックログを作ろう
ユーザーストーリーマッピングを使ってプロダクトバックログを作ろう
izumi ito
とあるスタートアップの評価指標(メトリクス)
とあるスタートアップの評価指標(メトリクス)
Takaaki Umada
開発者の生産性向上を妨げる障壁とサイボウズの生産性向上チームの取り組み
開発者の生産性向上を妨げる障壁とサイボウズの生産性向上チームの取り組み
Jumpei Miyata
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
Akinori SAKATA
3 Amigosの考え方で、独立したQAチームがアジャイルテストチームになるまでの話
3 Amigosの考え方で、独立したQAチームがアジャイルテストチームになるまでの話
Koichiro Takashima
kintoneがAWSで目指すDevOpsQAな開発
kintoneがAWSで目指すDevOpsQAな開発
Teppei Sato
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Masashi Umezawa
Kafka vs Pulsar @KafkaMeetup_20180316
Kafka vs Pulsar @KafkaMeetup_20180316
Nozomi Kurihara
はじめてのPRD
はじめてのPRD
Takuya Oikawa
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu Nishi
大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b
大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b
Yahoo!デベロッパーネットワーク
Head First Inception Deck
Head First Inception Deck
Naoto Nishimura
チームを『組成→安定→高速→最適化』に導くKAIZEN メソッド郡
チームを『組成→安定→高速→最適化』に導くKAIZEN メソッド郡
i35_267 Ishigaki
プロダクトがリリースされるまでを『見える化』することで組織体質を変えていった話
プロダクトがリリースされるまでを『見える化』することで組織体質を変えていった話
i35_267 Ishigaki
Contenu connexe
Tendances
ぱぱっと理解するSpring Cloudの基本
ぱぱっと理解するSpring Cloudの基本
kazuki kumagai
NetflixにおけるPresto/Spark活用事例
NetflixにおけるPresto/Spark活用事例
Amazon Web Services Japan
Jenkins 再入門
Jenkins 再入門
Jumpei Miyata
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
Hironori Washizaki
Google Cloud で実践する SRE
Google Cloud で実践する SRE
Google Cloud Platform - Japan
私にとってのテスト
私にとってのテスト
Takuto Wada
スクラムパタン入門
スクラムパタン入門
Kiro Harada
ユーザーストーリーマッピングを使ってプロダクトバックログを作ろう
ユーザーストーリーマッピングを使ってプロダクトバックログを作ろう
izumi ito
とあるスタートアップの評価指標(メトリクス)
とあるスタートアップの評価指標(メトリクス)
Takaaki Umada
開発者の生産性向上を妨げる障壁とサイボウズの生産性向上チームの取り組み
開発者の生産性向上を妨げる障壁とサイボウズの生産性向上チームの取り組み
Jumpei Miyata
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
Akinori SAKATA
3 Amigosの考え方で、独立したQAチームがアジャイルテストチームになるまでの話
3 Amigosの考え方で、独立したQAチームがアジャイルテストチームになるまでの話
Koichiro Takashima
kintoneがAWSで目指すDevOpsQAな開発
kintoneがAWSで目指すDevOpsQAな開発
Teppei Sato
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Masashi Umezawa
Kafka vs Pulsar @KafkaMeetup_20180316
Kafka vs Pulsar @KafkaMeetup_20180316
Nozomi Kurihara
はじめてのPRD
はじめてのPRD
Takuya Oikawa
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu Nishi
大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b
大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b
Yahoo!デベロッパーネットワーク
Head First Inception Deck
Head First Inception Deck
Naoto Nishimura
Tendances
(20)
ぱぱっと理解するSpring Cloudの基本
ぱぱっと理解するSpring Cloudの基本
NetflixにおけるPresto/Spark活用事例
NetflixにおけるPresto/Spark活用事例
Jenkins 再入門
Jenkins 再入門
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
Google Cloud で実践する SRE
Google Cloud で実践する SRE
私にとってのテスト
私にとってのテスト
スクラムパタン入門
スクラムパタン入門
ユーザーストーリーマッピングを使ってプロダクトバックログを作ろう
ユーザーストーリーマッピングを使ってプロダクトバックログを作ろう
とあるスタートアップの評価指標(メトリクス)
とあるスタートアップの評価指標(メトリクス)
開発者の生産性向上を妨げる障壁とサイボウズの生産性向上チームの取り組み
開発者の生産性向上を妨げる障壁とサイボウズの生産性向上チームの取り組み
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
3 Amigosの考え方で、独立したQAチームがアジャイルテストチームになるまでの話
3 Amigosの考え方で、独立したQAチームがアジャイルテストチームになるまでの話
kintoneがAWSで目指すDevOpsQAな開発
kintoneがAWSで目指すDevOpsQAな開発
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Kafka vs Pulsar @KafkaMeetup_20180316
Kafka vs Pulsar @KafkaMeetup_20180316
はじめてのPRD
はじめてのPRD
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b
大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b
Head First Inception Deck
Head First Inception Deck
Similaire à VSM(ValueStreamMapping)によって 実現できたリリースまでに268.5hかかっていた時間を54.5hに短縮できた秘訣
チームを『組成→安定→高速→最適化』に導くKAIZEN メソッド郡
チームを『組成→安定→高速→最適化』に導くKAIZEN メソッド郡
i35_267 Ishigaki
プロダクトがリリースされるまでを『見える化』することで組織体質を変えていった話
プロダクトがリリースされるまでを『見える化』することで組織体質を変えていった話
i35_267 Ishigaki
CircleCIを使ったSpringBoot/GAEアプリ開発の効率化ノウハウ
CircleCIを使ったSpringBoot/GAEアプリ開発の効率化ノウハウ
Takeshi Mikami
Redmine Applied for Large Scale
Redmine Applied for Large Scale
Rakuten Group, Inc.
GitHubの機能を活用したGitHub Flowによる開発の進め方
GitHubの機能を活用したGitHub Flowによる開発の進め方
Takeshi Mikami
Prometheus超基礎公開用.pdf
Prometheus超基礎公開用.pdf
勇 黒沢
20120324 git training
20120324 git training
Takeshi AKIMA
Upstream University
Upstream University
NTT Communications Technology Development
Kubernetes、Flannel、CNIでWindows Container Clusterオーケストレーション
Kubernetes、Flannel、CNIでWindows Container Clusterオーケストレーション
Takashi Kanai
分散バージョン管理システムって何なん 20101218
分散バージョン管理システムって何なん 20101218
Takashi Okamoto
RICOH THETA プラグイン開発 ワークショップ #1
RICOH THETA プラグイン開発 ワークショップ #1
RICOHTHETAPluginDevloperCommunity
Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -
Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -
Yahoo!デベロッパーネットワーク
WebRTC開発者向けプラットフォーム SkyWayの裏側
WebRTC開発者向けプラットフォーム SkyWayの裏側
Yusuke Naka
TensorFlowを使ってテキストをクラス分類してみた
TensorFlowを使ってテキストをクラス分類してみた
Yuya Kato
GitHub最新情報キャッチアップ 2023年6月
GitHub最新情報キャッチアップ 2023年6月
Kazumi IWANAGA
HTTP/2時代のウェブサイト設計
HTTP/2時代のウェブサイト設計
Kazuho Oku
qmake入門
qmake入門
hermit4 Ishida
Mattermost Plugin Bounty Programについて
Mattermost Plugin Bounty Programについて
Nemoto Yusuke
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
iOSにおけるコードレビューを一歩先へ進める
iOSにおけるコードレビューを一歩先へ進める
Shunsuke Maeda
Similaire à VSM(ValueStreamMapping)によって 実現できたリリースまでに268.5hかかっていた時間を54.5hに短縮できた秘訣
(20)
チームを『組成→安定→高速→最適化』に導くKAIZEN メソッド郡
チームを『組成→安定→高速→最適化』に導くKAIZEN メソッド郡
プロダクトがリリースされるまでを『見える化』することで組織体質を変えていった話
プロダクトがリリースされるまでを『見える化』することで組織体質を変えていった話
CircleCIを使ったSpringBoot/GAEアプリ開発の効率化ノウハウ
CircleCIを使ったSpringBoot/GAEアプリ開発の効率化ノウハウ
Redmine Applied for Large Scale
Redmine Applied for Large Scale
GitHubの機能を活用したGitHub Flowによる開発の進め方
GitHubの機能を活用したGitHub Flowによる開発の進め方
Prometheus超基礎公開用.pdf
Prometheus超基礎公開用.pdf
20120324 git training
20120324 git training
Upstream University
Upstream University
Kubernetes、Flannel、CNIでWindows Container Clusterオーケストレーション
Kubernetes、Flannel、CNIでWindows Container Clusterオーケストレーション
分散バージョン管理システムって何なん 20101218
分散バージョン管理システムって何なん 20101218
RICOH THETA プラグイン開発 ワークショップ #1
RICOH THETA プラグイン開発 ワークショップ #1
Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -
Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -
WebRTC開発者向けプラットフォーム SkyWayの裏側
WebRTC開発者向けプラットフォーム SkyWayの裏側
TensorFlowを使ってテキストをクラス分類してみた
TensorFlowを使ってテキストをクラス分類してみた
GitHub最新情報キャッチアップ 2023年6月
GitHub最新情報キャッチアップ 2023年6月
HTTP/2時代のウェブサイト設計
HTTP/2時代のウェブサイト設計
qmake入門
qmake入門
Mattermost Plugin Bounty Programについて
Mattermost Plugin Bounty Programについて
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
iOSにおけるコードレビューを一歩先へ進める
iOSにおけるコードレビューを一歩先へ進める
VSM(ValueStreamMapping)によって 実現できたリリースまでに268.5hかかっていた時間を54.5hに短縮できた秘訣
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 ご清聴ありがとうございました。
Télécharger maintenant