Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
プロダクトがリリースされるまでを『見える化』 することで組織体質を変えていった話 〜改...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Masato Ishigaki / 石垣雅人
July 07, 2018
Design
730
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
プロダクトがリリースされるまでを『見える化』 することで組織体質を変えていった話 〜改善を進めるはじめの1歩目〜
2018/07/07 プロダクトオーナー祭り2018 Summer 登壇資料
Masato Ishigaki / 石垣雅人
July 07, 2018
More Decks by Masato Ishigaki / 石垣雅人
See All by Masato Ishigaki / 石垣雅人
【技術的負債conf】事業成長に伴う技術的負債の説明責任とAIによるモニタリング、認知的負債について
i35_267
4
2.9k
AI x 開発生産性を取り巻く予算戦略と投資対効果
i35_267
10
7.1k
誤解だらけの開発生産性 / Myths and Misconceptions about Developer Productivity
i35_267
3
2.2k
プロダクトマネージャーが押さえておくべき、ソフトウェア資産とAIエージェント投資効果 / pmconf2025
i35_267
2
2.4k
生成AI活用のROI、どう測る? DMM.com 開発責任者から学ぶ「AI効果検証のノウハウ」 / ROI of AI
i35_267
5
610
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
8
1.5k
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
8
26k
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
6
2.6k
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
4
540
Other Decks in Design
See All in Design
デザインレビューを「他者へのおすそわけ」に再定義し、たのしい場にする試み
webnaut
1
120
デザインツールを開く前に その画面は誰に何と言わせたい?受託UIデザイナーが顧客解像度を高める 「打ち合わせの場での確かめ方」
garyuten
1
280
デザインワークフローの最前線。 ログラスでのAI活用の現在地
ukaoli
1
3.5k
凡庸を落とすハーネス
hiromimaeo
2
990
トランジションの冒険 自分と世界を変える冒険の書 / Transition Adventure
dmattsun
2
800
Basket_of_love.pdf
terencebasart
0
360
Webブラウザで動く VJツールをつくる
akirafukuoka
0
120
信頼をデザインし、ブランドで市場を拓く。/ Designship2026
assuredjp
PRO
0
250
デザイナーの判断をAIにつなぐ ── 審美眼をハーネスする試み
kotasaito_cnt
0
1.3k
富山デザイン勉強会_生成AIを使ったデザイン制作2026最新版.pdf
keita_yoshikawa
0
160
Luna's Light
shemeetscity
0
660
デザイン組織の"次の"強みづくり
isaikaori
2
320
Featured
See All Featured
Mind Mapping
helmedeiros
1
400
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
2
1.6k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
760
YesSQL, Process and Tooling at Scale
rocio
174
15k
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
2
2.9k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
232
55k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
7k
Product Roadmaps are Hard
iamctodd
55
13k
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
2
410
Reflections from 52 weeks, 52 projects
jeffersonlam
356
22k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.3k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
53k
Transcript
プロダクトがリリースされるまでを 『見える化』 することで 組織体質を変えていった話 石垣雅人 - DMM.com 2018/07/07 プロダクトオーナー祭り2018 Summer
〜改善を進めるはじめの1歩目〜
© DMM.com 2 私 石垣雅人(いしがきまさと) ・プラットフォーム開発部 第2グループ(会員基盤) Account(ID) , Auth
, Personalinfo バックエンド基盤担当 スクラムチーム プロダクトオーナー (2017〜) ・DMM.com 2015/04~ 新卒入社 Twitter @i35_267
© DMM.com 3 3 リリースまでを『見える化』することで 本セッションでお話すること 268.5h→54hに短縮した事例を紹介します 組織体質をかえてリリースまでのリードタイムを
© DMM.com 4 Agenda About DMM.com DMM.comについて / 組織体質について 改善事例
最後に 4 4 VSM / SIPOCの書き方
© DMM.com 手のひらと世界にいろどりを。 人類の想像をはるかにこえるスピードとス ケールで、私たちの生活は変化していま す。 DMM.comは1999年から時代のニーズに 合わせた多彩なコンテンツを、独自プラット フォームで安定的に提供しています。 5
40以上の幅広いサービスを展開 サービスについて About DMM.com
© DMM.com 6 6 チームが当時抱えていた組織体質 の問題点
© DMM.com 7 { What is … 悪い組織体質} 7 自動化をもっと改善していきたい!
© DMM.com 8 { What is … 悪い組織体質} 8 今のやり方でも困ってないから
一度チームで決めたことだから 学習コストがかかるから
© DMM.com 9 { What is … 悪い組織体質} 9 今のやり方でも困ってないから
一度チームで決めたことだから 学習コストがかかるから 組織体質を変えるには色々方法はあるが....
© DMM.com 10 { What is … 悪い組織体質} 10 今のやり方でも困ってないから
一度チームで決めたことだから 学習コストがかかるから 組織体質の『ムダ』を 定量的に可視化して見せること。 効果的なのが
© DMM.com 11 11 = VSM (Value Stream Mapping) =
SIPOC分析 ・・・定量的にリードタイムを可視化 ・・・定量的にフロー(ステークホルダー)を可視化 方法論提示
© DMM.com 12 Agenda About DMM.com DMM.comについて / 組織体質について 改善事例
最後に 12 12 VSM / SIPOCの書き方
© DMM.com 13 { What is VSM… } 13 Idea
Value
© DMM.com 14
© DMM.com 15 15 書き方 (Value Stream Mapping)
© DMM.com 16 4 STEPS プロセスのタイトル 1 2 プロセスタイム (PT
※+WT) 3 リードタイム(LT) 4 完成と正確性の割合(aka %C/A)
© DMM.com 17 17 顧客 顧客 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
© DMM.com 18 18 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
© DMM.com 19 19 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
© DMM.com 20 20 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
© DMM.com 21 21 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
© DMM.com 22 22 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
© DMM.com 23 23 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
© DMM.com 24 24 24 ①現状のVSM ③改善プロセス ②理想(仮説) のVSM プロセス
© DMM.com 25 25 25 顧客 顧客 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 大事なのは、改善ポイント(=ムダ)を見つけること ※ どう改善するかはまた別のレイヤーの話
© DMM.com 26 26 26 書き方 (SIPOC分析)
© DMM.com 27 27 Supplier Input Process Output Customer 供給者
インプット プロセス アウトプット 顧客 SIPOC分析
© DMM.com 28 SIPOC分析 O : Output (アウトプット) S :
Supplier(供給者) I : Input (インプット) P : Process (プロセス) C : Customer (顧客) VSMで記載した プロセスを記載していく Process Input Supplier
© DMM.com 29 SIPOC分析 O : Output (アウトプット) S :
Supplier(供給者) I : Input (インプット) P : Process (プロセス) C : Customer (顧客) Process Input 会員登録機能作成 承認MTG リリース作業 Supplier
© DMM.com 30 SIPOC分析 O : Output (アウトプット) S :
Supplier(供給者) I : Input (インプット) P : Process (プロセス) C : Customer (顧客) Process Input 会員登録機能作成 承認MTG リリース作業 Doneの定義 Supplier
© DMM.com 31 SIPOC分析 O : Output (アウトプット) S :
Supplier(供給者) I : Input (インプット) P : Process (プロセス) C : Customer (顧客) Process Input 会員登録機能作成 承認MTG リリース作業 Doneの定義 PO Supplier
© DMM.com 32 SIPOC分析 O : Output (アウトプット) S :
Supplier(供給者) I : Input (インプット) P : Process (プロセス) C : Customer (顧客) Process Input 会員登録機能作成 承認MTG リリース作業 Doneの定義 PO Supplier
© DMM.com 33 SIPOC分析 O : Output (アウトプット) S :
Supplier(供給者) I : Input (インプット) P : Process (プロセス) C : Customer (顧客) Process 会員登録機能作成 承認MTG リリース作業 Output ソースコード Customer
© DMM.com 34 SIPOC分析 O : Output (アウトプット) S :
Supplier(供給者) I : Input (インプット) P : Process (プロセス) C : Customer (顧客) Process 会員登録機能作成 承認MTG リリース作業 Output Customer ソースコード チーム
© DMM.com 35 35 Supplier Input Process Output Customer 会員登録機能作成
承認MTG リリース作業 Doneの定義 PO チーム ソースコード ドキュメント マネジメント層 意思決定 チーム チーム ソースコード ex. SIPOC分析 プロダクト ユーザー
© DMM.com 36 Agenda About DMM.com DMM.comについて / 組織体質について 改善事例
最後に 36 36 VSM / SIPOCの書き方
© DMM.com 37 37 改善事例 Value Stream Mapping / SIPOC分析
© DMM.com 38 38 VSMから見える共通点 グループ ステークホルダーとの調整 開発作業 リリース準備 +
作業 Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 2 3
© DMM.com 39 39 ステークホルダーとの調整 開発作業 リリース準備 + 作業 VSMから見える共通点
リードタイム : 268.5h Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 2 3 グループ
© DMM.com 40 40 ステークホルダーとの調整 開発作業 リリース準備 + 作業 約85%
約5% 約10% VSMから見える共通点 (228.25h) (14h) (26.25h) Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 2 3 グループ リードタイム : 268.5h
© DMM.com 41 41 カテゴリー ステークホルダーとの調整 開発作業 リリース準備 + 作業
約85% 約5% 約10% 4つのVSMから見える共通点 ほぼすべてのVSMがこの比率になった。 チームの行動パターン(開発プロセス)は一緒である。 この時点で「開発効率」をあげてもムダだと判断できた。
© DMM.com 42 42 カテゴリー ステークホルダーとの調整 開発作業 リリース準備 + 作業
約85% 約5% 約10% VSMから見える共通点 (228.25h) (14h) (26.25h) Featureをリリースするために必要な調整。MTGが多い コーディング作業 リリースするための申請やリリース作業 1 3 2 リードタイム : 268.5h
© DMM.com 43 43 ステークホルダーとの調整 SIPOC分析から見える共通点 Featureをリリースするために必要な調整。MTGが多い 1 Supplier Input
Process Output Customer プロセス数 : 2 Output数 : 7 Output数 : 5 Customer数 : 1 Supplier数 : 1 チームメンバー 説明用の ドキュメント準備 ...etc 説明用の ドキュメント ...etc マネジメント層 承認MTG x 2
© DMM.com 44 44 44 ステークホルダーとの調整 : 228.25h → リリース準備
+ 作業 : 26.25h →
© DMM.com 45 45 45 ステークホルダーとの調整 : 228.25h →40hに短縮 リリース準備
+ 作業 : 26.25h → 5mに短縮 268.5h (45日) 54.5h (9日) こんなに改善できますよ。というのを 定量的な削減率で見せることが大事
© DMM.com 46 46 46 ステークホルダーとの調整 : 228.25h →40hに短縮 リリース準備
+ 作業 : 26.25h → 5mに短縮 268.5h (45日) 54.5h (9日)
© DMM.com 47 Agenda About DMM.com DMM.comについて / 組織体質について 改善事例
最後に 47 47 VSM / SIPOCの書き方
© DMM.com 48 48 { What is VSM… } 48
Idea Value 問題を共有するのに難しいことはいらない。 明日からすぐにVSM/SIPOC分析を作ろう。
© DMM.com 49 49 ご清聴ありがとうございました。