フロー効率性とリソース効率性について #xpjug

フロー効率性と
リソース効率性
について #xpjug
黒田　樹 @i2key リクルートジョブズ
リクルートテクノロジーズ
AgileガーとかWaterFallガーとか言う前に

「効率が良い」ってどういう意味で使いますか？

速く作業が出来ること？

「リソース効率性」が良い
（例）稼働率100%、リソースに遊びが無い
「フロー効率性」が良い
（例）機能リリースまでのリードタイムの短さ

リソース効率性とフロー効率性
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 B B B
C C C C C
C C C C C
C C C C C
月　火　水　木　金月　火　水　木　金月　火　水　木　金
リリースまでのリードタイム 1w
A機能、B機能、C機能の実装それぞれ15人日かかる場合

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 B B B
C C C C C
C C C C C
C C C C C
「リソース効率性」が良い
（例）稼働率100%、リソースに遊びが無い
「フロー効率性」が良い
（例）機能リリースまでのリードタイムの短さ

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
複数のことを同時にやるとプロダクトがユーザに届くまで・検
証を開始するまでのリードタイムが長くなる。
ただし、皆に仕事が割り振られるため、また時間の余る限り複
数の仕事を持つためリソースあたりの稼働率は高くなる。

1つのリソースを稼働率が100%になるまで分配する
例
・マルチタスク
・大きなウォーターフォール型開発
A B C
Resource
流れる対象
30%
30% 40%
リソース稼働率：100%
(作業時間を絞り出す量を最大化)
1リソースに
フォーカスする
流れる対象流れる対象

フロー効率性
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
リリースまでのリードタイム約2w
A
A
A
B B
B B
B B
同時にやることをひとつにするとプロダクトがユーザに届くま
でのリードタイムは短くなる。しかし、全員が同じことをやる
ため、一時的に手持ちがなくなる人が出たりするためリソース
の稼働率は下がる。（Aだけでみるとトータル稼働は多い）

A
Resource
流れる対象
流れる対象（タスク）が得られるリソースの時間を最大化する
流れる対象に
フォーカスする
Resource Resource
例
・ペアプログラミング/モブプログラミング
・クロスファンクショナルチーム
・システム障害発生時の動き
フロー効率性

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
リリースまでのリードタイム約2w
A
A
A
B B
B B
B B

リソース効率と
フロー効率の関係
6

リソース効率とフロー効率はトレードオフの関係になりやすい
大規模開発のような大量のものを一括でドン！と
リリースする文脈（リソース効率が支配するパラダイム）
ペアプログラミングしたいです！
（効果：フロー効率アップ）
2人で同じことやったら、
効率半分に落ちるだろ！却下！
（効果：リソース効率ダウン）エンジニア氏
偉い人氏 6

リソース効率とフロー効率はトレードオフの関係になりやすい
仮説検証型でUI/UX改善を回し、KPIを伸ばしにいく文脈。
現場は学びまでのリードタイムを限りなく最小化したい。
（無意識にフロー効率を重視している）
リリース物はすべて承認が必要だ。
だが、わしは忙しいから
一括でまとめて持ってきなさい。
（フロー効率ダウン）
（効率落ちるだろ！）
ヘイトマッハっすわー
エンジニア氏
偉い人氏
6

リソース効率
フロー効率
リソース効率とフロー効率の関係
High
HighLow
Low
稼働率100%のチーム
機能がリリースされるまでの
リードタイム長い
稼働率は100%ではないチーム
リードタイム短い
Variation
This is Lean https://www.amazon.co.jp/dp/919803930X/The Eﬃciency Matrix -

リソース効率
フロー効率
High
HighLow
Low
Variation
This is Lean https://www.amazon.co.jp/dp/919803930X/The Eﬃciency Matrix -
例：高級ホテル/旅館
(部屋稼働率:空き部屋あり)
(客数に対する従業員数:多)
例：カプセルホテル
(部屋稼働率:100%)
(客数に対する従業員数:少)

リソース効率
フロー効率
High
HighLow
Low
Variation
我々
例：高級ホテル/旅館
(部屋稼働率:空き部屋あり)
(客数に対する従業員数:多)
例：カプセルホテル
(部屋稼働率:100%)
(客数に対する従業員数:少)

リソース効率
フロー効率
High
HighLow
Low
Variation
ワラフォー
SoR
アージュル
SoE
小規模・仮説検証
大規模開発
我々

リソース効率
フロー効率
High
HighLow
Low
ワラフォー
SoR
SoE
大規模開発ココに
行きたい
我々アージュル

リソース効率
フロー効率
High
HighLow
Low
ワラフォー
SoR
SoE
行きたい
我々アージュル

リソース効率
フロー効率
High
HighLow
Low
ワラフォー
SoR
SoE
行きたい
我々
流れに着目するほうがムダを炙り出しやすい
こっちから登ったほうが
リソース効率上のムダも発見しやすい
アージュル

リソース効率とフロー効率の
ビジネスにおける効果・影響

1st week 2nd week 3rd week 4th week 5th week 6th week 7th we
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 w
0
0.75
1.5
2.25
3
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル

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
0
0.75
1.5
2.25
3
A
B
C
学んでいない期間
稼いでいない期間
学んでいない期間
稼いでいない期間
オーバーヘッドで
若干合計稼働は増える
複数の実験を
同時にやると濁る

リソース効率とフロー効率と
QCDSとの関係

「学びまでのリードタイム」「システムが稼ぎだすまでのリー
ドタイム」「価値提供までのリードタイム」という顧客に価値
が届くまでの時間軸で見ると
Quality: 品質
Cost: コスト・体制
Delivery: 価値提供迄の時間
Scope : スコープ

低下するとリードタイムを悪化させる（＝品質下げるという選択肢がそもそも無い）
• プロセス品質下げると手順ミス等により手戻りが発生しデリバリへのリードタイムが長く
なる
• 内部品質さげるとバグの発生、コードレビューの指摘、技術的負債による実装の複雑さな
どにより手戻りや速度低下を招き、デリバリへのリードタイムが長くなる
• 外部品質さげるとUXバグをうみ、本来検証したいことが検証できず学びまでのリードタイ
ムが長くなる。障害発生により、それの対応に終われリソースが枯渇し本来やるべきこと
の足かせになり、リードタイムが長くなる
• 利用時の品質さげると、カスタマーサポートが頻発しその対応に組織のパワーが持って行
かれリードタイムが長くなる
Quality: 品質
品質が悪いと手戻りを生むので速度に跳ね返る。
手戻っている時間＝価値提供しない時間、学びのない時間
12

・コストはエンジニアリングの場合、大抵、人件費に跳ね返るが体制は基本的には固定であり
頻繁に上下するものでないので固定になるケースが多い
・学びまでのリードタイムの人件費と見るのであれば、少ないにこしたことはない。結果的に
コストはリードタイムそのもの。
Delivery: 価値提供までの時間
・「学びまでのリードタイム」「システムが稼ぎだすまでのリードタイム」「価値提供までの
リードタイム」そのもの。はやければはやいほうが良い。
12

一度にやる量を決めることでリードタイムが結果的に変わってくる
• 大きくする（大きなバッチ）と、リソース効率性のバイアスがかかるため、一括でリリー
スは出来るが、デリバリまでのリードタイムは増える
• 小さくする（1個流し）と、フロー効率性のバイアスがかかるため、小出しにはなるがデ
リバリまでのリードタイムは小さくなる
12

「学びまでのリードタイム」「システムが稼ぎだすまでのリー
ドタイム」「価値提供までのリードタイム」という顧客に価値
が届くまでの時間軸で見ると
Quality: 品質
Delivery: 価値提供迄の時間
大事
大事
大事
調整ネジ
12

“How Much”どれだけ多くできるかという押し込むバイアス。
制約を前提として、まとめてたくさんのことをやるときのバイアス。
リソース効率性のパラダイムが強い。
VS
“How Little”どれだけ細かく刻めるかを考えると変化に強くなる。
どれだけ小さく価値提供できるか。
フロー効率性のパラダイムが強い。
12

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
0
0.75
1.5
2.25
3
A
B
C

POやPMはチームに大きな塊を渡した時点で、それによっ
て何が起きるか、どういう選択をしたのかを
把握しておく必要がある。
大きすぎるのでスコープ削りたいと
質問を受けた場合は「全部必要だ」と
言う前に考えて欲しい。
自らリソース効率を選択したことを。
その結果、
「エンジニアのリリースまでのスピードが遅い？」
「エンジニアの生産性が悪い？」
ちがう、バッチサイズが大きいから。
(稼働率は高いはずだよ、それを選んだのだから)
よくある話

一度にやる量を減らすには

本当に必要なことだけやる
（例：ビジネスフェーズに沿ったこと）

手戻りのムダや作り過ぎのムダを減らすために、
ニーズにあっている正しいものをつくる
→ニーズからプルする
情報の流れ
モノの流れ
ニーズ
when
what
amount
when
what
amount
when
what
amount
when
what
amount
pullpullpull

深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
顧客発見顧客実証顧客開拓組織構築
[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
最適な売り方の検証
最適な価格設定の検証
Problem
Solution
Fit
Product
Market
Fit
Scaling
Retention CAC < LTV 最大LTVセグメントの比率
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
ビジネス
フェーズ
狩野
モデル
魅力的品質最低限の性能品質
魅力的品質
当たり前品質
アップセル・クロスセルに
向けた性能品質
魅力的品質
当たり前品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って壊す
MVP
品質
最低限の
売れる状態
セグメントに応じて売れる状態
検証が既存ユーザに影響与えない

深い課題を抱えた顧客がいるか
顧客発見顧客実証顧客開拓組織構築
[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]
顧客は本当に買ってくれるか
コスト構造に無理がないか
最適な売り方の検証
最適な価格設定の検証
Problem
Solution
Fit
Product
Market
Fit
Scaling
Retention CAC < LTV 最大LTVセグメントの比率
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
ビジネス
フェーズ
狩野
モデル
魅力的品質最低限の性能品質
魅力的品質
当たり前品質
アップセル・クロスセルに
向けた性能品質
魅力的品質
当たり前品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って壊す
MVP
品質
最低限の
売れる状態
セグメントに応じて売れる状態
検証が既存ユーザに影響与えない
その課題の解決
策は妥当か

情報とモノのフローを意識した
リーンスタートアップの正しいやり方
いきなりこの流れでやると
小さくやってもムダを生む

①仮説
②何を学ぶのか
③必要なデータは？
④どうやって計測する？
⑤必要なものは？
⑥どう構築するか？
思考プロセス
（情報の流れ）
pull
pull
pull pull
pull

⑫仮説を調整する
⑪学ぶ
⑩データを元に検証
⑨計測する
⑧完成したMVP
⑦構築する
実証プロセス
(モノの流れ)

一度にやる量を減らせるのに、
自ら多くしてしまった事例

【事例】
フロー効率重視で開発プロセスを
組んだものの、チームが知らず知
らずのうちにリソース効率にフォー
カスした選択をしていった話

Sprint
#N
Sprint
#N+1
Sprint
#N+2
Sprint
#N-1
1Q 2Q 3Q
バックログ
・デザインの改善（CVR向上目的）
・UI/UX改善（CVR向上目的）
・技術負債解消（保守性）
・ログ周りの改善（モニタリング）
開発案件リスト
・Web開発タスク #1
API開発チーム(アウトソース)
3ヶ月周期のWF型の計画駆動開発
アプリ開発チーム(インハウス)
2週間スプリントのスクラム開発
↑
こっちの話
18

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
A
B
C
フロー効率性重視の当初の開発計画
A
B
デザイン改善・UI/IX改善
技術負債解消
C C C
C その他、改善
18

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
A
B
C
A
B
C
デザイン改善・UI/IX改善
技術負債解消
急遽、ビジネス的に大きな変更が舞い込んできた
商品の変更(営業連携、API連携＝リリース日FIX)
リリース日
C その他、改善
フロー効率性重視の当初の開発計画
18

リリース日固定だし、他の案件も全部まとめて
やったほうが効率がよい（特に試験とか）
（フロー効率の考えが何処かに行ってしまい、いつのまにかリソース効率で考えるように切
り替わってしまっている）
　　　　　　　　　　　　　　　↓
でも、もともとある案件と全部まとめるとリリー
ス日に間に合わないなあ
（大きなバッチサイズで一括でやることを前提にしてしまっている）
　　　　　　　　　　　　　　　↓
もともとある案件の仕様を調整して一括でリリー
ス出来るようにしよう
（期日に合わせてすべてをまとめてリリースすることが目的になる。結果的に、学びの無い期
間をチームが自ら作り出している。）
　　　　　　　　　　　　　　　↓
もとの案件の劣化版を提案する
（本来の狙ったビジネス効果は得られない）
リソース効率バイアスをかけた選択をチームがとりはじめて、
本来の目的を達成できるかわからない機能仕様になってしまう。

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
A
B
C
リリース日フロー効率性重視の当初の開発計画
CVR ±0 ±0 ±0 ±0 ±0 ±0 +3
売上
or
KPI
release
A
B
C
0
0.75
1.5
2.25
3
リソース効率性重視の大きなバッチサイズ開発リリース日
価値を生んでいない期間を最大化・・・
価値を積み上げていく予定が・・

チームがリリース日という制約を前提としてしまった
- 前提を疑うべき
- 制約をコントロール対象にする
- そのリリース日って本当に固定なの？
- 例えば事前にリリースしておき、当日に切り替える
- Feature Toggle運用とかやりようはある
- エンジニアリングで制約をコントロール対象にできれば、
フロー効率で考えられる。
- または、事前に予測していれば対応がとれる

フロー効率性を高める
プラクティス、方法論

バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
Feedback
承認レビュー
仕様確認
API開発 API開発
Front開発
デプロイ待ち待ち
エンジニア
(フロント＆バックエンド）
フロント
エンジニア
プロダクト
オーナー
顧客
Feedback
承認条件
API開発 Front開発デプロイ待ち
待ち
待ち
※先に提示された条件をパスすれば
リリース承認というルールにする等
※フルスタック（）な振る舞い
をすることで引き継ぎによる
ムダが減る
※ここにきて手戻りが
発生することも
学ぶ(顧客のフィードバックを得る)までのリードタイム

バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
Feedback
承認レビュー
仕様確認
API開発 API開発
Front開発
デプロイ待ち待ち
エンジニア
(フロント＆バックエンド）
フロント
エンジニア
プロダクト
オーナー
顧客
Feedback
承認条件
API開発 Front開発デプロイ待ち
待ち
待ち
※先に提示された条件をパスすれば
リリース承認というルールにする等
※フルスタック（）な振る舞い
をすることで引き継ぎによる
ムダが減る
※ここにきて手戻りが
発生することも
学ぶ(顧客のフィードバックを得る)までのリードタイム
クロスファンクション
フルスタック
承認イベントから
承認条件駆動に(ある意味TDD)

• カンバン（トヨタ生産方式）

◦ 一個流し

▪ WIP制限にて流す量を減らす（最適化する）

▪ WIP制限1にすることが目的ではない（最適な値にする）

▪ WIP制限を小さくすることのメリット・デメリット

▪ メリット

▪ フロー効率性に特化した改善が行いやすい。ボトルネックが可視化しやすい。

▪ デメリット

▪ WIPを1に制限すると生産ライン上のどこかでトラブルが起きた場合、後続ラインが全面停止する。デメリットではあるが、必ず異常
事態を検知でき、後続に不良品が流れないと考えるとメリットでもある。

• ペアプログラミング

◦ 二人で1つのことをするため、二人で別々のことをするよりも流れるものの数が半分＆品質が上がる（副次効果で引き継ぎが不要になり、結果的に誰
でもどんな作業もプル出来るようになる。こちらもフロー効率性に寄与する。）

• モブプログラミング

◦ ペアプロのフロー効率性の極値振り型

◦ 「あなたが売っているのは、キー入力だろうか？それとも完成した機能だろうか？」 by カンバン仕事術*3 P112

• Github-Flow & Feature Flagのコラボ

◦ FeatureFlagを仕込んだプルリクのMasterマージで本番環境への自動デプロイ

◦ 断片でのプッシュが可能になり、プルリクが小さくなる

◦ 流れるもののサイズを小さくする効果（フロー効率性）

◦ 対してGit-FlowはReleaseブランチが若干一括処理でありリソース効率性がある。

• マルチタスクをやめる

◦ カンバンのWIP制限の話と同義

• バリューストリームマップ

◦ バリューストリームマップにて、プロセスタイムとリードタイムを可視化。ムダを特定しフローを改善。

• クロスファンクショナルチーム

◦ 他組織とのやりとりは基本的にバッチ処理になりがちであり、引き継ぎのムダが発生する。それの排除。

• フルスタックエンジニア

◦ クロスファンクショナルチームの人バージョン。1人で全部できれば待ちのムダが省ける。フルスタックはある文脈では（笑）とされるが非常にフロー
効率性が高い。
http://i2key.hateblo.jp/entry/2017/05/15/082655
フロー効率性を向上させるメソッド、プラクティス、方法論

VS
ビジネスの目的・文脈に合わせて以下を選択すると同時に
その選択によってどのようなバイアスが働くかを考慮すること

マルチタスク派
か
シングルタスク派
か
という仕事の仕方の話でした。

ご清聴＆ご静聴ありがとうございました

フロー効率性とリソース効率性について #xpjug

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Mehr von Itsuki Kuroda

Mehr von Itsuki Kuroda (20)

フロー効率性とリソース効率性について #xpjug