Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
大規模レガシー環境に
立ち向かう有機的な
開発フォーメーション
黒田 樹 @i2key
#devsumi
ニーズ発生に対してJUST IN TIMEでリソースを割り当て、
スループットに最速で変換できること
ニーズ発生に対してJUST IN TIMEでリソースを割り当て、
スループットに最速で変換できること
ヒト・モノ・カネ
実利・売上・KPI
ニーズ発生に対してJUST IN TIMEでリソースを割り当て、
スループットに最速で変換できること
ジャストインタイムの有機的なメンバアサイン
✓組織的ゆとりによる戦略領域におけるリソース集中投下
✓リソース調達チャネルの多様化
✓大部屋化の...
ニーズ発生に対してJUST IN TIMEでリソースを割り当て、
スループットに最速で変換できること
スループット変換効率の最大化
✓フロー効率性/リソース効率性の両方取りの追求
✓セットベース
✓安定稼働
ニーズ発生に対してJUST IN TIMEでリソースを割り当て、
スループットに最速で変換できること
スループット変換効率の最大化
✓フロー効率性/リソース効率性の両方取りの追求
✓セットベース
✓安定稼働
リソース効率性とフロー効率性
A A A A A A A A A A A A A A A
B
C
B
C
B
C
B
C
B
C
B
C
B
C
B
C
B
C
B
C
B
C
B
C
B
C
B
C
B
C
A A A A A
A A A A...
1つのリソースを稼働率が100%になるまで分配する
例
・マルチタスク
・大きなウォーターフォール型開発
A B C
Resource
流れる対象
30%
30% 40%
リソース稼働率:100%
(作業時間を絞り出す量を最大化)
1リソースに...
A
Resource
流れる対象
流れる対象(タスク)が得られるリソースの時間を最大化する
流れる対象に
フォーカスする
Resource Resource
例
・ペアプログラミング/モブプログラミング
・クロスファンクショナルチーム
・システ...
検索条件
入力画面
検索結果
一覧画面
詳細画面 予約画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
掲載枠検索
¥0
利用者 クライアント
広告
ビジネス
CVR改...
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th w...
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th w...
リソース効率
フロー効率
リソース効率とフロー効率の関係
High
HighLow
Low
Variation
一度に沢山
SoR
一個ずつ
SoE
小規模・仮説検証
大規模開発
我々
This is Lean https://www.amaz...
リソース効率
フロー効率
リソース効率とフロー効率の関係
High
HighLow
Low
ココに
行きたい
我々
This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency...
ニーズ発生に対してJUST IN TIMEでリソースを割り当て、
スループットに最速で変換できること
スループット変換効率の最大化
✓フロー効率性/リソース効率性の両方取りの追求
✓セットベース
✓安定稼働
不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
(作る対象の不確実性)
正しいものを正しくつくる
(作り方の不確実性)
正しくつくる
正しいもの
原型
不確実性に対してどう対応していくのか
不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
(作る対象の不確実性)
正しいものを正しくつくる
(作り方の不確実性)
正しくつくる
正しいもの
原型
ポイントベース(最初に決定、うまく行けば最小コスト)
・うまくいけば最短LT...
不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
(作る対象の不確実性)
正しいものを正しくつくる
(作り方の不確実性)
正しくつくる
正しいもの
原型
判
断
ポ
イ
ン
ト
判
断
セットベース(決定を遅らせ手戻りを最小化)
...
ビジネス構造の理解
既存事業におけるビジネス構造の理解
https://recruit-holdings.co.jp/ir/library/upload/report_201903Q4_pm_jp.pdfリクルートホールディングス 2019年3月期通期決算説明資料
https://recruit-holdings.co.jp/ir/library/upload/report_201903Q4_pm_jp.pdfリクルートホールディングス 2019年3月期通期決算説明資料
各ドメインに事業展開することで市場...
既存事業におけるビジネス構造の理解
クライアント
様向け画面
アルバイト先を
探している人
アルバイトを
募集している企業
既存事業におけるビジネス構造の理解
クライアント
様向け画面
商品開発
サイト改善 サイト改善
求人情報に対するコンバージョンレートの向上
UI/UXの継続的改善(仮説検証型)
求人情報の出稿枠の追加
掲載期間、掲載形式等の商品に関する開発
(営業広報あるため計画駆動、シッカリカ...
SoR
Bimodal IT Mode1 Mode2
正式名称 System of Record(SoR) System of Engagement(SoE)
適正
基幹系・勘定系、
ミッションクリティカルな機能・システム
(決済システム、顧客...
クライアント
様向け画面
商品開発
サイト改善 サイト改善
求人情報に対するコンバージョンレートの向上
UI/UXの継続的改善(仮説検証型)
求人情報の出稿枠の追加
掲載期間、掲載形式等の商品に関する開発
(営業広報あるため計画駆動、シッカリカ...
クライアント
様向け画面
商品開発
サイト改善 サイト改善
求人情報に対するコンバージョンレートの向上
UI/UXの継続的改善(仮説検証型)
求人情報の出向枠の追加
掲載期間、掲載形式等の商品に関する開発
(営業広報あるため計画駆動、シッカリカ...
クライアント
様向け画面
商品開発
サイト改善 サイト改善
求人情報に対するコンバージョンレートの向上
UI/UXの継続的改善(仮説検証型)
求人情報の出向枠の追加
掲載期間、掲載形式等の商品に関する開発
(営業広報あるため計画駆動、シッカリカ...
タウンワーク
FromA Navi
はたらいく
とらばーゆ
入稿システム
応募管理
システム
タウンワーク
FromA Navi
はたらいく
とらばーゆ
入稿システム
応募管理
システム
商品開発
求人情報の出稿枠の追加
掲載期間、掲載形式等の商品に関する開発
(営業広報あるため計画駆動、シッカリカッチリ)
タウンワーク
FromA Navi
はたらいく
とらばーゆ
入稿システム
応募管理
システム
サイト改善
求人情報に対するコンバージョンレートの向上
UI/UXの継続的改善(仮説検証型)
構造的アプローチで
自己組織化チームを作る
クライアント
様向け画面
商品開発
サイト改善 サイト改善
求人情報に対するコンバージョンレートの向上
UI/UXの継続的改善(仮説検証型)
グロースハック
求人情報の出稿枠の追加
掲載期間、掲載形式等の商品に関する開発
(営業広報あるため計画...
マーケ組織 商品企画組織 営業組織 データ系組織
プロダクト開発組織
プロダクトオーナー
プロジェクト(WF) スクラム or カンバン スクラム or カンバン
アーキテクト
プロダクトオーナー
プロキシー
プロダクトオーナー
プロキシー
プ...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
年次の予算計画
1年分の活動予算
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
予算枠
目的① チーム
例えば、予算枠とチームが目...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔...
マーケ組織 商品企画組織 営業組織 データ系組織
プロダクト開発組織
プロダクトオーナー
プロジェクト(WF) スクラム or カンバン スクラム or カンバン
アーキテクト
プロダクトオーナー
プロキシー
プロダクトオーナー
プロキシー
プ...
組織的「ゆとり」を投資し
「ゆとり」を創出する
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
±0 ±0 +1 +1 +1+1 +1
±0 ±0 +1 +1+1±0 ±0
±0 ±0 +1±0 ±0 ±0...
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
±0 ±0 +1 +1 +1+1 +1
±0 ±0 +1 +1+1±0 ±0
±0 ±0 +1±0 ±0 ±0...
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
±0 ±0 +1 +1 +1+1 +1
±0 ±0 +1 +1+1±0 ±0
±0 ±0 +1±0 ±0 ±0...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔...
ニーズ発生に対してJUST IN TIMEでリソースを割り当て、
スループットに最速で変換できること
ジャストインタイムの有機的なメンバアサイン
✓組織的ゆとりによる戦略領域におけるリソース集中投下
✓リソース調達チャネルの多様化
✓大部屋化の...
リソース効率
フロー効率
High
HighLow
Low
Variation
目指す場所
組織的ゆとり枠でリソース効率とフロー効率の両面張り
納期コミット業務を持っていないため、
ニーズ発生時にJUST IN TIMEでアサインできる
納期コ...
テストコードが書きにくい構造に対して、
リファクタリングを行えるようにするためのE2Eの整備
(UIを除くE2Eにおける品質担保)
 ↓
リファクタリング&テストコード
 ↓
画面を含むE2Eテスト(UI含む)
リファクタリングが難しい状態から...
SQLのI/O
RequestのI/O
コードカバレッジ
画面のUI変更追従を意図的に捨てたE2Eテスト基盤
JSON
SQLのI/O
RequestのI/O
コードカバレッジ
JSON
Requestの順次実行
結果は全I/OのDiffのため...
テストコードが書きにくい構造に対して、
リファクタリングを行えるようにするためのE2Eの整備
(UIを除くE2Eにおける品質担保)
 ↓
リファクタリング&テストコード
 ↓
画面を含むE2Eテスト(UI含む)
リファクタリングが難しい状態から...
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
±0 ±0 +1 +1 +1+1 +1
±0 ±0 +1 +1+1±0 ±0
±0 ±0 +1±0 ±0 ±0...
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
±0 ±0 +1 +1 +1+1 +1
±0 ±0 +1 +1+1±0 ±0
±0 ±0 +1±0 ±0 ±0...
SoEにおける
エンジニアリング
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th w...
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th w...
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th w...
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
±0 ±0 +1 +1 +1+1 +1
±0 ±0 +1 +1+1±0 ±0
±0 ±0 +1±0 ±0 ±0...
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
±0 ±0 +1 +1 +1+1 +1
±0 ±0 +1 +1+1±0 ±0
±0 ±0 +1±0 ±0 ±0...
リードタイム
プロセスタイム(PT) ムダ+
顧客への価値を作り出している時間 価値を作っていない時間
➡設計
➡コーディング
➡ビルド待ち
➡手戻り
➡承認待ち
DevelopmentPlanning Design Measure
Ph.1 Ph.2 Ready会 SprintDesign AB Testing
工程別
滞留数
(在庫数)
工程別
スルー
プット 4個/2週 3個/2週 3個/2週 4個...
DevelopmentPlanning Design Measure
Ph.1 Ph.2 Ready会 SprintDesign AB Testing
工程別
滞留数
(在庫数)
工程別
スルー
プット 4個/2週 3個/2週 3個/2週 4個...
DevelopmentPlanning Design Measure
Ph.1 Ph.2 Ready会 SprintDesign AB Testing
工程別
滞留数
(在庫数)
工程別
スルー
プット 4個/2週 3個/2週 3個/2週 4個...
DevelopmentPlanning Design Measure
Ph.1 Ph.2 Ready会 SprintDesign AB Testing
工程別
滞留数
(在庫数)
工程別
スルー
プット 4個/2週 3個/2週 3個/2週 4個...
SoRにおける
エンジニアリング
タウンワーク
FromA Navi
はたらいく
とらばーゆ
入稿システム
応募管理
システム
商品開発
求人情報の出稿枠の追加
掲載期間、掲載形式等の商品に関する開発
(営業広報あるため計画駆動、シッカリカッチリ)
タウンワーク
FromA Navi
はたらいく
とらばーゆ
入稿システム
応募管理
システム
商品開発
求人情報の出稿枠の追加
掲載期間、掲載形式等の商品に関する開発
(営業広報あるため計画駆動、シッカリカッチリ)
掲載原稿数増えすぎて、
掲載...
12
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eru...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔...
65
Solr
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozh...
66
Solr
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozh...
67
Solr
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozh...
68
Solr
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozh...
69
Solr
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozh...
これを繰り返した結果
71
Solr
SQL
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-...
72
Solr
SQL
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-...
73
Solr
SQL
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-...
74
Solr
SQL
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-...
これを倒す
76
Solr
SQL
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-...
77
Solr
SQL
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-...
83
JOB
JOB
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング
https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-w...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
実証された方式で
しっかりかっちり実装
テストは火...
不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
(作る対象の不確実性)
正しいものを正しくつくる
(作り方の不確実性)
正しくつくる
正しいもの
原型
突発的な不確実性に対してどう対応していくのか
→社員+SIerさん+オフショ...
不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
(作る対象の不確実性)
正しいものを正しくつくる
(作り方の不確実性)
正しくつくる
正しいもの
原型
突発的な不確実性に対してどう対応していくのか
→社員+SIerさん+オフショ...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
社員+SIerさん
一般的な開発時のフォーメーショ...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
社員+SIerさん ベトナム
最大出力フォーメーシ...
ニーズ発生に対してJUST IN TIMEでリソースを割り当て、
スループットに最速で変換できること
ジャストインタイムの有機的なメンバアサイン
✓組織的ゆとりによる戦略領域におけるリソース集中投下
✓リソース調達チャネルの多様化
✓大部屋化の...
固
定
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
必要工数ゆとり
予算は固定であるが、
通常...
固
定
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
必要工数ゆとり
・組織力強化への投資
・育...
不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
(作る対象の不確実性)
正しいものを正しくつくる
(作り方の不確実性)
正しくつくる
正しいもの
原型
判
断
ポ
イ
ン
ト
判
断
セットベース(決定を遅らせ手戻りを最小化)
...
不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
(作る対象の不確実性)
正しいものを正しくつくる
(作り方の不確実性)
正しくつくる
正しいもの
原型
判
断
ポ
イ
ン
ト
判
断
セットベース(決定を遅らせ手戻りを最小化)オ...
不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
(作る対象の不確実性)
正しいものを正しくつくる
(作り方の不確実性)
正しくつくる
正しいもの
原型
不確実性に対してどう対応していくのか
国内
不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
(作る対象の不確実性)
正しいものを正しくつくる
(作り方の不確実性)
正しくつくる
正しいもの
原型
不確実性に対してどう対応していくのか
オフショアで多重化し
リードタイム短縮...
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
予算は枠として固定で持っているので、
全体的なコス...
リソース効率
フロー効率
High
HighLow
Low
ココに
行きたい
我々
This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
稼働率
リー...
リソース効率
フロー効率
High
HighLow
Low
ココに
行きたい
我々
This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
稼働率
リー...
リソース効率
フロー効率
High
HighLow
Low
ココに
行きたい
我々
This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
稼働率
リー...
まとめ
ニーズ発生に対してJUST IN TIMEでリソースを割り当て、
スループットに最速で変換できること
ヒト・モノ・カネ
実利・売上・KPI
ニーズ発生に対してJUST IN TIMEでリソースを割り当て、
スループットに最速で変換できること
ジャストインタイムの有機的なメンバアサイン
✓組織的ゆとりによる戦略領域におけるリソース集中投下
✓リソース調達チャネルの多様化
✓大部屋化の...
ニーズ発生に対してJUST IN TIMEでリソースを割り当て、
スループットに最速で変換できること
スループット変換効率の最大化
✓フロー効率性/リソース効率性の両方取りの追求
✓セットベース
✓安定稼働
ご静聴&ご清聴
ありがとうございました
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
You’ve finished this document.
Download and read it offline.
Upcoming SlideShare
What to Upload to SlideShare
Next
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

Share

大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic

Download to read offline

https://event.shoeisha.jp/devsumi/20190702/session/2083/
デベロッパーズサミット2019夏のスライドです。

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic

  1. 1. 大規模レガシー環境に 立ち向かう有機的な 開発フォーメーション 黒田 樹 @i2key #devsumi
  2. 2. ニーズ発生に対してJUST IN TIMEでリソースを割り当て、 スループットに最速で変換できること
  3. 3. ニーズ発生に対してJUST IN TIMEでリソースを割り当て、 スループットに最速で変換できること ヒト・モノ・カネ 実利・売上・KPI
  4. 4. ニーズ発生に対してJUST IN TIMEでリソースを割り当て、 スループットに最速で変換できること ジャストインタイムの有機的なメンバアサイン ✓組織的ゆとりによる戦略領域におけるリソース集中投下 ✓リソース調達チャネルの多様化 ✓大部屋化の推進
  5. 5. ニーズ発生に対してJUST IN TIMEでリソースを割り当て、 スループットに最速で変換できること スループット変換効率の最大化 ✓フロー効率性/リソース効率性の両方取りの追求 ✓セットベース ✓安定稼働
  6. 6. ニーズ発生に対してJUST IN TIMEでリソースを割り当て、 スループットに最速で変換できること スループット変換効率の最大化 ✓フロー効率性/リソース効率性の両方取りの追求 ✓セットベース ✓安定稼働
  7. 7. リソース効率性とフロー効率性 A A A A A A A A A A A A A A A B C B C B C B C B C B C B C B C B C B C B C B C B C B C B C A A A A A A A A A A A A A A A B B B B B B B B B B B B C C C C C C C C C 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リリースまでのリードタイム 約2w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w A機能、B機能、C機能の実装それぞれ15人日かかる場合 A A A B B B B B B
  8. 8. 1つのリソースを稼働率が100%になるまで分配する 例 ・マルチタスク ・大きなウォーターフォール型開発 A B C Resource 流れる対象 30% 30% 40% リソース稼働率:100% (作業時間を絞り出す量を最大化) 1リソースに フォーカスする 流れる対象 流れる対象 リソース効率性
  9. 9. A Resource 流れる対象 流れる対象(タスク)が得られるリソースの時間を最大化する 流れる対象に フォーカスする Resource Resource 例 ・ペアプログラミング/モブプログラミング ・クロスファンクショナルチーム ・システム障害発生時の動き フロー効率性
  10. 10. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 掲載枠検索 ¥0 利用者 クライアント 広告 ビジネス CVR改善 = 売上直結 例:CVR最大化に向けたUI/UX仮説検証 流入数
  11. 11. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR CVR ±0 ±0 ±0 ±0 ±0 ±0 +3 ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 売上 or KPI release A B C 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C リソース効率を重視して開発した場合 フロー効率を重視して開発した場合
  12. 12. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR CVR ±0 ±0 ±0 ±0 ±0 ±0 +3 ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 売上 or KPI release A B C 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C 学んでいない期間 稼いでいない期間 学んでいない期間 稼いでいない期間 オーバーヘッドで 若干合計稼働は増える 複数の実験を 同時にやると濁る リソース効率を重視して開発した場合 フロー効率を重視して開発した場合
  13. 13. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low Variation 一度に沢山 SoR 一個ずつ SoE 小規模・仮説検証 大規模開発 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
  14. 14. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - どう登っていくか
  15. 15. ニーズ発生に対してJUST IN TIMEでリソースを割り当て、 スループットに最速で変換できること スループット変換効率の最大化 ✓フロー効率性/リソース効率性の両方取りの追求 ✓セットベース ✓安定稼働
  16. 16. 不確実性 大 不確実性 中 不確実性 小 正しいものを探索する (作る対象の不確実性) 正しいものを正しくつくる (作り方の不確実性) 正しくつくる 正しいもの 原型 不確実性に対してどう対応していくのか
  17. 17. 不確実性 大 不確実性 中 不確実性 小 正しいものを探索する (作る対象の不確実性) 正しいものを正しくつくる (作り方の不確実性) 正しくつくる 正しいもの 原型 ポイントベース(最初に決定、うまく行けば最小コスト) ・うまくいけば最短LT最小コストで走れる ・変更が入る度に手戻りが発生し、リードタイムが伸びる ・変更が入る度にコストがかかる  例:年次法改正対応のような確定している要件 あ、違った最初に決定 また違った
  18. 18. 不確実性 大 不確実性 中 不確実性 小 正しいものを探索する (作る対象の不確実性) 正しいものを正しくつくる (作り方の不確実性) 正しくつくる 正しいもの 原型 判 断 ポ イ ン ト 判 断 セットベース(決定を遅らせ手戻りを最小化) ・情報がそろうまで決定をおくらせる ・複数案並走させることでコストかかる ・複数案走ることで手戻りを無くしリードタイムを最短にする  例:リスクがあるアーキテクチャ候補の並走検討
  19. 19. ビジネス構造の理解
  20. 20. 既存事業におけるビジネス構造の理解
  21. 21. https://recruit-holdings.co.jp/ir/library/upload/report_201903Q4_pm_jp.pdfリクルートホールディングス 2019年3月期通期決算説明資料
  22. 22. https://recruit-holdings.co.jp/ir/library/upload/report_201903Q4_pm_jp.pdfリクルートホールディングス 2019年3月期通期決算説明資料 各ドメインに事業展開することで市場のボラティリティに適応するための コングロマリットに見えるが、見方をかえるとセットベース的にも見える
  23. 23. 既存事業におけるビジネス構造の理解
  24. 24. クライアント 様向け画面 アルバイト先を 探している人 アルバイトを 募集している企業 既存事業におけるビジネス構造の理解
  25. 25. クライアント 様向け画面 商品開発 サイト改善 サイト改善 求人情報に対するコンバージョンレートの向上 UI/UXの継続的改善(仮説検証型) 求人情報の出稿枠の追加 掲載期間、掲載形式等の商品に関する開発 (営業広報あるため計画駆動、シッカリカッチリ) 既存事業におけるビジネス構造の理解
  26. 26. SoR Bimodal IT Mode1 Mode2 正式名称 System of Record(SoR) System of Engagement(SoE) 適正 基幹系・勘定系、 ミッションクリティカルな機能・システム (決済システム、顧客管理等) 正解が無い中、柔軟に変化をしながら走り続ける必要がある機 能・サービス (スマホアプリ、ウェブサービスのフロント) 目的 信頼性、安定性 定めた仕様に従って安定性や品質を担保しながら開発して いく必要がある 俊敏性、速度 フィードバックに基づいて速やかに改善を加え、頻繁にリリー スする 価値・評価 費用対効果、コスト 売上、ブランド、UX アプローチ ウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID 調達 エンタープライズサプライヤー、 長期的な取引 小さい、新しいベンダー、短期間の取引 メンバ適正 従来のプロセス、プロジェクトが得意 新しくて不確実なプロジェクトが得意 組織/文化 開発部門・計画型 ビジネス&開発混在・探索型 サイクルタイム 数ヶ月 数日、数週間 SoE 計画型 シッカリカッチリ 探索型 速さ、柔軟さ
  27. 27. クライアント 様向け画面 商品開発 サイト改善 サイト改善 求人情報に対するコンバージョンレートの向上 UI/UXの継続的改善(仮説検証型) 求人情報の出稿枠の追加 掲載期間、掲載形式等の商品に関する開発 (営業広報あるため計画駆動、シッカリカッチリ) SoRSoE SoE
  28. 28. クライアント 様向け画面 商品開発 サイト改善 サイト改善 求人情報に対するコンバージョンレートの向上 UI/UXの継続的改善(仮説検証型) 求人情報の出向枠の追加 掲載期間、掲載形式等の商品に関する開発 (営業広報あるため計画駆動、シッカリカッチリ) SoRSoE SoE SE力高い人材がいな いと立ち行かない アジャイルな感 じの人材向き
  29. 29. クライアント 様向け画面 商品開発 サイト改善 サイト改善 求人情報に対するコンバージョンレートの向上 UI/UXの継続的改善(仮説検証型) 求人情報の出向枠の追加 掲載期間、掲載形式等の商品に関する開発 (営業広報あるため計画駆動、シッカリカッチリ) SoRSoE SoE SE力高い人材がいな いと立ち行かない アジャイルな感 じの人材向き
  30. 30. タウンワーク FromA Navi はたらいく とらばーゆ 入稿システム 応募管理 システム
  31. 31. タウンワーク FromA Navi はたらいく とらばーゆ 入稿システム 応募管理 システム 商品開発 求人情報の出稿枠の追加 掲載期間、掲載形式等の商品に関する開発 (営業広報あるため計画駆動、シッカリカッチリ)
  32. 32. タウンワーク FromA Navi はたらいく とらばーゆ 入稿システム 応募管理 システム サイト改善 求人情報に対するコンバージョンレートの向上 UI/UXの継続的改善(仮説検証型)
  33. 33. 構造的アプローチで 自己組織化チームを作る
  34. 34. クライアント 様向け画面 商品開発 サイト改善 サイト改善 求人情報に対するコンバージョンレートの向上 UI/UXの継続的改善(仮説検証型) グロースハック 求人情報の出稿枠の追加 掲載期間、掲載形式等の商品に関する開発 (営業広報あるため計画駆動、シッカリカッチリ) SoRSoE SoE
  35. 35. マーケ組織 商品企画組織 営業組織 データ系組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム or カンバン スクラム or カンバン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア :エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア : SoR SoE SoE カンバン ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア : 安定稼働、アーキ (組織的ゆとり) グロースハックチーム商品開発チーム
  36. 36. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 年次の予算計画 1年分の活動予算
  37. 37. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟
  38. 38. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム
  39. 39. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム 調 整 ネ ジ
  40. 40. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム 予算枠 目的&責任 チーム 予算:目的:責任:チームが1対1の状態 投資側からすれば目 的が達成できればよ いのでHOWは自由。 あとは任せた! →チームに自治権 →現場裁量で推進 →精神論ではなく構 造的アプローチによ る自己組織化
  41. 41. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム 予算枠 目的&責任 チーム アーキテクチャ (余談)マイクロサービス 予算:目的:責任:チームが1対1の状態
  42. 42. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム 予算枠 目的&責任 チーム 予算:目的:責任:チームが1対1の状態 予算枠 目的&責任 チーム 予算枠 目的&責任 チーム
  43. 43. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 予算枠 目的① チーム 例えば、予算枠とチームが目的単位でない場合 目的② 投資目的が混ざるの で、優先順位付けにお いて、一つ上位レイ ヤーの意思決定お伺い が発生するかもしれな い。 →現場で決めれない →現場に自治権がない
  44. 44. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム =>フロー効率重視 =>リソース効率重視 =>組織的「ゆとり」
  45. 45. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム =>フロー効率重視 =>リソース効率重視 =>組織的「ゆとり」 複数のことをまとめてV字 モデルでやる (ウォーターフォール?) 一個ずつV字モデルでやる (アジャイル?カンバン? スクラム?それ系のやつ) 「ゆとり」を投資して効率 化で「ゆとり」をつくる
  46. 46. マーケ組織 商品企画組織 営業組織 データ系組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム or カンバン スクラム or カンバン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア :エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア : リソース効率 フロー効率 フロー効率 カンバン ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア : 安定稼働、アーキ (組織的ゆとり) グロースハックチーム商品開発チーム
  47. 47. 組織的「ゆとり」を投資し 「ゆとり」を創出する
  48. 48. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C フロー効率を重視して開発した場合 毎回リグレッションテストを 手動でやるのだるいし、オーバーヘッド大きすぎ。 だったら複数まとめて一回でテストしたほうが効率が良い →リソース効率のパラダイムに戻りたい 1個流しを志向すると最初に発生する壁
  49. 49. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C フロー効率を重視して開発した場合 毎回リグレッションテストを 手動でやるのだるいし、オーバーヘッド大きすぎ。 だったら複数まとめて一回でテストしたほうが効率が良い →リソース効率のパラダイムに戻りたい 1個流しを志向すると最初に発生する壁 テストコードかけばいいのでは?
  50. 50. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C フロー効率を重視して開発した場合 毎回リグレッションテストを 手動でやるのだるいし、オーバーヘッド大きすぎ。 だったら複数まとめて一回でテストしたほうが効率が良い →リソース効率のパラダイムに戻りたい 1個流しを志向すると最初に発生する壁 テストコードかけばいいのでは? メソッド単位が大きすぎるし、テストコード書くなら リファクタリングしないととんでもないテストコードになる でも、リファクタリングして品質担保できる気がしない
  51. 51. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム =>フロー効率重視 =>リソース効率重視 =>組織的「ゆとり」
  52. 52. ニーズ発生に対してJUST IN TIMEでリソースを割り当て、 スループットに最速で変換できること ジャストインタイムの有機的なメンバアサイン ✓組織的ゆとりによる戦略領域におけるリソース集中投下 ✓リソース調達チャネルの多様化 ✓大部屋化の推進
  53. 53. リソース効率 フロー効率 High HighLow Low Variation 目指す場所 組織的ゆとり枠でリソース効率とフロー効率の両面張り 納期コミット業務を持っていないため、 ニーズ発生時にJUST IN TIMEでアサインできる 納期コミットしていない改善系 業務、アーキテクト系業務を普 段行うので高稼働率を維持。 意図的に納期コミットしない仕 事をさせている。 開発現場に発生するボラティリティに組織の「ゆとり」で対応する
  54. 54. テストコードが書きにくい構造に対して、 リファクタリングを行えるようにするためのE2Eの整備 (UIを除くE2Eにおける品質担保)  ↓ リファクタリング&テストコード  ↓ 画面を含むE2Eテスト(UI含む) リファクタリングが難しい状態からの自動テスト戦略
  55. 55. SQLのI/O RequestのI/O コードカバレッジ 画面のUI変更追従を意図的に捨てたE2Eテスト基盤 JSON SQLのI/O RequestのI/O コードカバレッジ JSON Requestの順次実行 結果は全I/OのDiffのため Assert的なものは無し VIEW VIEW Diff masterのソースコード 開発中branchのソースコード CI 管理画面 前日差分見るため 日次実行 同じdmpデータ APIのI/O APIs APIのI/O APIs
  56. 56. テストコードが書きにくい構造に対して、 リファクタリングを行えるようにするためのE2Eの整備 (UIを除くE2Eにおける品質担保)  ↓ リファクタリング&テストコード  ↓ 画面を含むE2Eテスト(UI含む) リファクタリングが難しい状態からの自動テスト戦略
  57. 57. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C フロー効率を重視して開発した場合 1個流しを志向すると最初に発生する壁 2週間サイクルの開発においてリグレッションテスト時間が 3日→45分
  58. 58. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C フロー効率を重視して開発した場合 1個流しを志向すると最初に発生する壁 2週間サイクルの開発においてリグレッションテスト時間が 3日→45分 「ゆとり」の投資でさらなる 「ゆとり」を創出
  59. 59. SoEにおける エンジニアリング
  60. 60. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR CVR ±0 ±0 ±0 ±0 ±0 ±0 +3 ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 売上 or KPI release A B C 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week ビジネス価値とリソース効率性重視の開発スタイル A B C ビジネス価値とフロー効率性重視の開発スタイル
  61. 61. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR CVR ±0 ±0 ±0 ±0 ±0 ±0 +3 ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 売上 or KPI release A B C 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week ビジネス価値とリソース効率性重視の開発スタイル A B C ビジネス価値とフロー効率性重視の開発スタイル 1個ずつV字モデル開発 複数まとめてV字モデル開発
  62. 62. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR CVR ±0 ±0 ±0 ±0 ±0 ±0 +3 ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 売上 or KPI release A B C 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week ビジネス価値とリソース効率性重視の開発スタイル A B C ビジネス価値とフロー効率性重視の開発スタイル リードタイム リードタイム
  63. 63. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上or KPI 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 +1 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち待ち テスト テスト ビジネス価値とフロー効率性重視の開発スタイル
  64. 64. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上or KPI 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 +1 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち待ち テスト テスト ビジネス価値とフロー効率性重視の開発スタイル リードタイム リードタイム短縮 エンジニアリングによってLTを短縮したい
  65. 65. リードタイム プロセスタイム(PT) ムダ+ 顧客への価値を作り出している時間 価値を作っていない時間 ➡設計 ➡コーディング ➡ビルド待ち ➡手戻り ➡承認待ち
  66. 66. DevelopmentPlanning Design Measure Ph.1 Ph.2 Ready会 SprintDesign AB Testing 工程別 滞留数 (在庫数) 工程別 スルー プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週 未着手案件の在庫推移を可視化し組織生産性の可視化 1案件あたりのリードタイムを最小化したい
  67. 67. DevelopmentPlanning Design Measure Ph.1 Ph.2 Ready会 SprintDesign AB Testing 工程別 滞留数 (在庫数) 工程別 スルー プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週 Ready状態の在庫を作る スループット 在庫を出荷する スループット 在 庫 量 推 移 Ready化数 リリース数 未着手案件の在庫推移を可視化し組織生産性の可視化 1案件あたりのリードタイムを最小化したい
  68. 68. DevelopmentPlanning Design Measure Ph.1 Ph.2 Ready会 SprintDesign AB Testing 工程別 滞留数 (在庫数) 工程別 スルー プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週 Ready状態の在庫を作る スループット 在庫を出荷する スループット 在 庫 量 推 移 ① ② ③ ① ② リードタイム ③ ③=①-②  =在庫量 Ready化数 リリース数累積フロー図 未着手案件の在庫推移を可視化し組織生産性の可視化
  69. 69. DevelopmentPlanning Design Measure Ph.1 Ph.2 Ready会 SprintDesign AB Testing 工程別 滞留数 (在庫数) 工程別 スルー プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週 Ready状態の在庫を作る スループット 在庫を出荷する スループット 在 庫 量 推 移 ① ② ③ ③① ② Ready化数 リリース数 Readyにした数とリリースした数 在庫数推移 未着手案件の在庫推移を可視化し組織生産性の可視化
  70. 70. SoRにおける エンジニアリング
  71. 71. タウンワーク FromA Navi はたらいく とらばーゆ 入稿システム 応募管理 システム 商品開発 求人情報の出稿枠の追加 掲載期間、掲載形式等の商品に関する開発 (営業広報あるため計画駆動、シッカリカッチリ)
  72. 72. タウンワーク FromA Navi はたらいく とらばーゆ 入稿システム 応募管理 システム 商品開発 求人情報の出稿枠の追加 掲載期間、掲載形式等の商品に関する開発 (営業広報あるため計画駆動、シッカリカッチリ) 掲載原稿数増えすぎて、 掲載まにあわない・・・
  73. 73. 12 タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid
  74. 74. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム =>フロー効率重視 =>リソース効率重視 =>組織的「ゆとり」
  75. 75. 65 Solr タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid こうなるまでの経緯
  76. 76. 66 Solr タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid こうなるまでの経緯
  77. 77. 67 Solr タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid こうなるまでの経緯
  78. 78. 68 Solr タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid こうなるまでの経緯
  79. 79. 69 Solr タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid こうなるまでの経緯
  80. 80. これを繰り返した結果
  81. 81. 71 Solr SQL タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid こうなるまでの経緯
  82. 82. 72 Solr SQL タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid こうなるまでの経緯
  83. 83. 73 Solr SQL タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid こうなるまでの経緯
  84. 84. 74 Solr SQL タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid こうなるまでの経緯
  85. 85. これを倒す
  86. 86. 76 Solr SQL タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid 対策
  87. 87. 77 Solr SQL タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid 対策
  88. 88. 83 JOB JOB タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai-wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number-devisumid 一時的にパワーが必要 テスト方針
  89. 89. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 実証された方式で しっかりかっちり実装 テストは火力必須のため オフショアも活用 解決策の立案と解決策の効 果の仮説検証を実施
  90. 90. 不確実性 大 不確実性 中 不確実性 小 正しいものを探索する (作る対象の不確実性) 正しいものを正しくつくる (作り方の不確実性) 正しくつくる 正しいもの 原型 突発的な不確実性に対してどう対応していくのか →社員+SIerさん+オフショアで  フォーメーションを組む
  91. 91. 不確実性 大 不確実性 中 不確実性 小 正しいものを探索する (作る対象の不確実性) 正しいものを正しくつくる (作り方の不確実性) 正しくつくる 正しいもの 原型 突発的な不確実性に対してどう対応していくのか →社員+SIerさん+オフショアで  フォーメーションを組む 組織的「ゆとり」の活用 <安定稼働チーム> 強い社員エンジニア 強いSIerのメンバで 解決策を検証する <SoRチーム> 計画的にしっかりかっちり 本実装。テストは高火力の オフショア活用。
  92. 92. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 社員+SIerさん 一般的な開発時のフォーメーション 固 定 SE力高い人材活躍領域  ※SEな方、積極採用中です!
  93. 93. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 社員+SIerさん ベトナム 最大出力フォーメーション 固 定
  94. 94. ニーズ発生に対してJUST IN TIMEでリソースを割り当て、 スループットに最速で変換できること ジャストインタイムの有機的なメンバアサイン ✓組織的ゆとりによる戦略領域におけるリソース集中投下 ✓リソース調達チャネルの多様化 ✓大部屋化の推進
  95. 95. 固 定 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 必要工数ゆとり 予算は固定であるが、 通常時よりも人が増えるため ゆとりが生まれやすい構造
  96. 96. 固 定 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 必要工数ゆとり ・組織力強化への投資 ・育成への投資 ・「ゆとり」で「ゆとり」を増やす
  97. 97. 不確実性 大 不確実性 中 不確実性 小 正しいものを探索する (作る対象の不確実性) 正しいものを正しくつくる (作り方の不確実性) 正しくつくる 正しいもの 原型 判 断 ポ イ ン ト 判 断 セットベース(決定を遅らせ手戻りを最小化) 国内 国内
  98. 98. 不確実性 大 不確実性 中 不確実性 小 正しいものを探索する (作る対象の不確実性) 正しいものを正しくつくる (作り方の不確実性) 正しくつくる 正しいもの 原型 判 断 ポ イ ン ト 判 断 セットベース(決定を遅らせ手戻りを最小化)オフショア 国内 国内 オフショア オフショア オフショアで検証多重化
  99. 99. 不確実性 大 不確実性 中 不確実性 小 正しいものを探索する (作る対象の不確実性) 正しいものを正しくつくる (作り方の不確実性) 正しくつくる 正しいもの 原型 不確実性に対してどう対応していくのか 国内
  100. 100. 不確実性 大 不確実性 中 不確実性 小 正しいものを探索する (作る対象の不確実性) 正しいものを正しくつくる (作り方の不確実性) 正しくつくる 正しいもの 原型 不確実性に対してどう対応していくのか オフショアで多重化し リードタイム短縮 国内 オフショア 例:掲載バッチ遅延のテスト工数増強
  101. 101. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 予算は枠として固定で持っているので、 全体的なコストリダクションを目的としていない (コストリダクション目的のオフショア開発も他には実際ある  が今回は割愛) 事業現場で感じるオフショアの価値 ・要員調達力(調達リードタイム:一気に組織をスケール可) ・固定予算内における開発ボラティリティへの弾力性  →固定予算で人数の増減コントロール可能 ・コスト効率に目を向けがちであるが、  実はフロー効率(リードタイム短縮)に非常に向いている  「一個流しできるレーンが増える」  「モブワークできるレーンが増える」とリフレームすると   秘めたる可能性がすごいことになる。 固 定
  102. 102. リソース効率 フロー効率 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 稼働率 リードタイム 高稼働率 高バッチサイズ コスト効率を目指すオフショア(これもやってます) より安く
  103. 103. リソース効率 フロー効率 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 稼働率 リードタイム 高稼働率 高バッチサイズ フロー効率でリフレームするオフショア(今回の話)
  104. 104. リソース効率 フロー効率 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 稼働率 リードタイム オフショアで リードタイム短縮 オフショアはセットベースやフロー効率を意識することで、 人月の神話(ブルックス)の逆張りで効率化を図ることが可能 (組織としての予算は固定でスループットは増加している) フロー効率でリフレームするオフショア(今回の話)
  105. 105. まとめ
  106. 106. ニーズ発生に対してJUST IN TIMEでリソースを割り当て、 スループットに最速で変換できること ヒト・モノ・カネ 実利・売上・KPI
  107. 107. ニーズ発生に対してJUST IN TIMEでリソースを割り当て、 スループットに最速で変換できること ジャストインタイムの有機的なメンバアサイン ✓組織的ゆとりによる戦略領域におけるリソース集中投下 ✓リソース調達チャネルの多様化 ✓大部屋化の推進
  108. 108. ニーズ発生に対してJUST IN TIMEでリソースを割り当て、 スループットに最速で変換できること スループット変換効率の最大化 ✓フロー効率性/リソース効率性の両方取りの追求 ✓セットベース ✓安定稼働
  109. 109. ご静聴&ご清聴 ありがとうございました
  • nemurin

    May. 20, 2020
  • akinorikohno5

    Apr. 16, 2020
  • hiroaki_imai

    Dec. 27, 2019
  • YojiKojima

    Oct. 22, 2019
  • MasachikaYamaguchi

    Aug. 17, 2019
  • hikarusaitoh9

    Jul. 21, 2019
  • inosuke

    Jul. 11, 2019
  • osamuwatanabe1

    Jul. 7, 2019
  • tsuyoshicho

    Jul. 3, 2019
  • Satully

    Jul. 3, 2019
  • sl65565

    Jul. 3, 2019
  • yumios

    Jul. 2, 2019
  • 36ra3

    Jul. 2, 2019
  • NeoXrea

    Jul. 2, 2019
  • RyoichiFurukawa

    Jul. 2, 2019
  • tosikawa

    Jul. 2, 2019

https://event.shoeisha.jp/devsumi/20190702/session/2083/ デベロッパーズサミット2019夏のスライドです。

Views

Total views

12,755

On Slideshare

0

From embeds

0

Number of embeds

3,607

Actions

Downloads

64

Shares

0

Comments

0

Likes

16

×