SlideShare a Scribd company logo
フロー効率性と
リソース効率性
について #xpjug
黒田 樹 @i2key リクルートジョブズ
リクルートテクノロジーズ
AgileガーとかWaterFallガーとか言う前に
「効率が良い」ってどういう意味で使いますか?
稼働率が100%?
速く作業が出来ること?
「リソース効率性」が良い
(例)稼働率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
リリースまでのリードタイム 2w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
A機能、B機能、C機能の実装それぞれ15人日かかる場合
リソース効率性とフロー効率性
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
リリースまでのリードタイム 2w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
A機能、B機能、C機能の実装それぞれ15人日かかる場合
「リソース効率性」が良い
(例)稼働率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
月 火 水 木 金 月 火 水 木 金 月 火 水 木 金
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
A機能、B機能、C機能の実装それぞれ15人日かかる場合
複数のことを同時にやるとプロダクトがユーザに届くまで・検
証を開始するまでのリードタイムが長くなる。
ただし、皆に仕事が割り振られるため、また時間の余る限り複
数の仕事を持つためリソースあたりの稼働率は高くなる。
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
月 火 水 木 金 月 火 水 木 金 月 火 水 木 金
リリースまでのリードタイム 1w
リリースまでのリードタイム 約2w
A機能、B機能、C機能の実装それぞれ15人日かかる場合
A
A
A
B B
B B
B B
同時にやることをひとつにするとプロダクトがユーザに届くま
でのリードタイムは短くなる。しかし、全員が同じことをやる
ため、一時的に手持ちがなくなる人が出たりするためリソース
の稼働率は下がる。(Aだけでみるとトータル稼働は多い)
A
Resource
流れる対象
流れる対象(タスク)が得られるリソースの時間を最大化する
流れる対象に
フォーカスする
Resource Resource
例
・ペアプログラミング/モブプログラミング
・クロスファンクショナルチーム
・システム障害発生時の動き
フロー効率性
リソース効率性とフロー効率性
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
リソース効率性とフロー効率性
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
リリースまでのリードタイム 2w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
A機能、B機能、C機能の実装それぞれ15人日かかる場合
「リソース効率性」が良い
(例)稼働率100%、リソースに遊びが無い
「フロー効率性」が良い
(例)機能リリースまでのリードタイムの短さ
リソース効率と
フロー効率の関係
6
リソース効率とフロー効率はトレードオフの関係になりやすい
大規模開発のような大量のものを一括でドン!と
リリースする文脈(リソース効率が支配するパラダイム)
ペアプログラミングしたいです!
(効果:フロー効率アップ)
2人で同じことやったら、
効率半分に落ちるだろ!却下!
(効果:リソース効率ダウン) エンジニア氏
偉い人氏 6
リソース効率とフロー効率はトレードオフの関係になりやすい
仮説検証型でUI/UX改善を回し、KPIを伸ばしにいく文脈。
現場は学びまでのリードタイムを限りなく最小化したい。
(無意識にフロー効率を重視している)
リリース物はすべて承認が必要だ。
だが、わしは忙しいから
一括でまとめて持ってきなさい。
(フロー効率ダウン)
(効率落ちるだろ!)
ヘイトマッハっすわー
エンジニア氏
偉い人氏
6
リソース効率
フロー効率
リソース効率とフロー効率の関係
High
HighLow
Low
稼働率100%のチーム
機能がリリースされるまでの
リードタイム長い
稼働率は100%ではないチーム
機能がリリースされるまでの
リードタイム短い
Variation
This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
リソース効率
フロー効率
リソース効率とフロー効率の関係
High
HighLow
Low
稼働率100%のチーム
機能がリリースされるまでの
リードタイム長い
稼働率は100%ではないチーム
機能がリリースされるまでの
リードタイム短い
Variation
This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
例:高級ホテル/旅館
(部屋稼働率:空き部屋あり)
(客数に対する従業員数:多)
例:カプセルホテル
(部屋稼働率:100%)
(客数に対する従業員数:少)
リソース効率
フロー効率
リソース効率とフロー効率の関係
High
HighLow
Low
Variation
我々
稼働率100%のチーム
機能がリリースされるまでの
リードタイム長い
稼働率は100%ではないチーム
機能がリリースされるまでの
リードタイム短い
例:高級ホテル/旅館
(部屋稼働率:空き部屋あり)
(客数に対する従業員数:多)
例:カプセルホテル
(部屋稼働率: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
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
1st week 2nd week 3rd week 4th week 5th week 6th week 7th w
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル
1st week 2nd week 3rd week 4th week 5th week 6th week 7th we
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
1st week 2nd week 3rd week 4th week 5th week 6th week 7th w
A
B
C
学んでいない期間
稼いでいない期間
学んでいない期間
稼いでいない期間
オーバーヘッドで
若干合計稼働は増える
ビジネス価値とリソース効率性重視の開発スタイル
ビジネス価値とフロー効率性重視の開発スタイル
複数の実験を
同時にやると濁る
リソース効率とフロー効率と
QCDSとの関係
「学びまでのリードタイム」「システムが稼ぎだすまでのリー
ドタイム」「価値提供までのリードタイム」という顧客に価値
が届くまでの時間軸で見ると
Quality: 品質
Cost: コスト・体制
Delivery: 価値提供迄の時間
Scope : スコープ
低下するとリードタイムを悪化させる(=品質下げるという選択肢がそもそも無い)
• プロセス品質下げると手順ミス等により手戻りが発生しデリバリへのリードタイムが長く
なる
• 内部品質さげるとバグの発生、コードレビューの指摘、技術的負債による実装の複雑さな
どにより手戻りや速度低下を招き、デリバリへのリードタイムが長くなる
• 外部品質さげるとUXバグをうみ、本来検証したいことが検証できず学びまでのリードタイ
ムが長くなる。障害発生により、それの対応に終われリソースが枯渇し本来やるべきこと
の足かせになり、リードタイムが長くなる
• 利用時の品質さげると、カスタマーサポートが頻発しその対応に組織のパワーが持って行
かれリードタイムが長くなる
Quality: 品質
品質が悪いと手戻りを生むので速度に跳ね返る。
手戻っている時間=価値提供しない時間、学びのない時間
12
・コストはエンジニアリングの場合、大抵、人件費に跳ね返るが体制は基本的には固定であり
頻繁に上下するものでないので固定になるケースが多い
・学びまでのリードタイムの人件費と見るのであれば、少ないにこしたことはない。結果的に
コストはリードタイムそのもの。
Cost: コスト・体制
Delivery: 価値提供までの時間
・「学びまでのリードタイム」「システムが稼ぎだすまでのリードタイム」「価値提供までの
リードタイム」そのもの。はやければはやいほうが良い。
12
一度にやる量を決めることでリードタイムが結果的に変わってくる
• 大きくする(大きなバッチ)と、リソース効率性のバイアスがかかるため、一括でリリー
スは出来るが、デリバリまでのリードタイムは増える
• 小さくする(1個流し)と、フロー効率性のバイアスがかかるため、小出しにはなるがデ
リバリまでのリードタイムは小さくなる
Scope : スコープ
12
「学びまでのリードタイム」「システムが稼ぎだすまでのリー
ドタイム」「価値提供までのリードタイム」という顧客に価値
が届くまでの時間軸で見ると
Quality: 品質
Cost: コスト・体制
Delivery: 価値提供迄の時間
Scope : スコープ
大事
大事
大事
調整ネジ
12
“How Much”どれだけ多くできるかという押し込むバイアス。
制約を前提として、まとめてたくさんのことをやるときのバイアス。
リソース効率性のパラダイムが強い。
VS
“How Little”どれだけ細かく刻めるかを考えると変化に強くなる。
どれだけ小さく価値提供できるか。
フロー効率性のパラダイムが強い。
12
1st week 2nd week 3rd week 4th week 5th week 6th week 7th we
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
1st week 2nd week 3rd week 4th week 5th week 6th week 7th w
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル
1st week 2nd week 3rd week 4th week 5th week 6th week 7th we
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
1st week 2nd week 3rd week 4th week 5th week 6th week 7th w
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル
“How Much”どれだけ多くできるかという押し込むバイアス。
制約を前提として、まとめてたくさんのことをやるときのバイアス。
リソース効率性のパラダイムが強い。
“How Little”どれだけ細かく刻めるかを考えると変化に強くなる。
どれだけ小さく価値提供できるか。
フロー効率性のパラダイムが強い。
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
・Web開発タスク #2
・Web開発タスク #3
API開発チーム(アウトソース)
3ヶ月周期のWF型の計画駆動開発
アプリ開発チーム(インハウス)
2週間スプリントのスクラム開発
↑
こっちの話
18
1st week 2nd week 3rd week 4th week 5th week 6th week 7th we
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
1st week 2nd week 3rd week 4th week 5th week 6th week 7th we
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
C
デザイン改善・UI/IX改善
技術負債解消
急遽、ビジネス的に大きな変更が舞い込んできた
商品の変更(営業連携、API連携=リリース日FIX)
リリース日
C その他、改善
フロー効率性重視の当初の開発計画
18
リリース日固定だし、他の案件も全部まとめて
やったほうが効率がよい(特に試験とか)
(フロー効率の考えが何処かに行ってしまい、いつのまにかリソース効率で考えるように切
り替わってしまっている)
               ↓
でも、もともとある案件と全部まとめるとリリー
ス日に間に合わないなあ
(大きなバッチサイズで一括でやることを前提にしてしまっている)
               ↓
もともとある案件の仕様を調整して一括でリリー
ス出来るようにしよう
(期日に合わせてすべてをまとめてリリースすることが目的になる。結果的に、学びの無い期
間をチームが自ら作り出している。)
               ↓
もとの案件の劣化版を提案する
(本来の狙ったビジネス効果は得られない)
リソース効率バイアスをかけた選択をチームがとりはじめて、
本来の目的を達成できるかわからない機能仕様になってしまう。
1st week 2nd week 3rd week 4th week 5th week 6th week 7th we
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
リリース日フロー効率性重視の当初の開発計画
1st week 2nd week 3rd week 4th week 5th week 6th week 7th we
CVR ±0 ±0 ±0 ±0 ±0 ±0 +3
売上
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
リソース効率性重視の大きなバッチサイズ開発 リリース日
価値を生んでいない期間を最大化・・・
価値を積み上げていく予定が・・
チームがリリース日という制約を前提としてしまった
- 前提を疑うべき
- 制約をコントロール対象にする
- そのリリース日って本当に固定なの?
- 例えば事前にリリースしておき、当日に切り替える
- 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
フロー効率性を向上させるメソッド、プラクティス、方法論
まとめ
“How Much”どれだけ多くできるかという押し込むバイアス。
制約を前提として、まとめてたくさんのことをやるときのバイアス。
リソース効率性のパラダイムが強い。
VS
“How Little”どれだけ細かく刻めるかを考えると変化に強くなる。
どれだけ小さく価値提供できるか。
フロー効率性のパラダイムが強い。
ビジネスの目的・文脈に合わせて以下を選択すると同時に
その選択によってどのようなバイアスが働くかを考慮すること
1st week 2nd week 3rd week 4th week 5th week 6th week 7th we
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
1st week 2nd week 3rd week 4th week 5th week 6th week 7th w
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル
1st week 2nd week 3rd week 4th week 5th week 6th week 7th we
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
1st week 2nd week 3rd week 4th week 5th week 6th week 7th w
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル
“How Much”どれだけ多くできるかという押し込むバイアス。
制約を前提として、まとめてたくさんのことをやるときのバイアス。
リソース効率性のパラダイムが強い。
“How Little”どれだけ細かく刻めるかを考えると変化に強くなる。
どれだけ小さく価値提供できるか。
フロー効率性のパラダイムが強い。
マルチタスク派
か
シングルタスク派
か
という仕事の仕方の話でした。
ご清聴&ご静聴 ありがとうございました

More Related Content

What's hot

Javaのログ出力: 道具と考え方
Javaのログ出力: 道具と考え方Javaのログ出力: 道具と考え方
Javaのログ出力: 道具と考え方
Taku Miyakawa
 
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
 
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
 
目grep入門 +解説
目grep入門 +解説目grep入門 +解説
目grep入門 +解説
murachue
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
 
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
 
WayOfNoTrouble.pptx
WayOfNoTrouble.pptxWayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
 
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるなテスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
 
なぜコンピュータを学ばなければならないのか 21世紀の君主論
なぜコンピュータを学ばなければならないのか 21世紀の君主論なぜコンピュータを学ばなければならないのか 21世紀の君主論
なぜコンピュータを学ばなければならないのか 21世紀の君主論
Tokoroten Nakayama
 
スマホゲームのチート手法とその対策 [DeNA TechCon 2019]
スマホゲームのチート手法とその対策 [DeNA TechCon 2019]スマホゲームのチート手法とその対策 [DeNA TechCon 2019]
スマホゲームのチート手法とその対策 [DeNA TechCon 2019]
DeNA
 
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveDXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
 
GoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホンGoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホン
Akihiko Horiuchi
 
SAT/SMTソルバの仕組み
SAT/SMTソルバの仕組みSAT/SMTソルバの仕組み
SAT/SMTソルバの仕組み
Masahiro Sakai
 
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
Kohei Tokunaga
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
 
基礎からのOAuth 2.0とSpring Security 5.1による実装
基礎からのOAuth 2.0とSpring Security 5.1による実装基礎からのOAuth 2.0とSpring Security 5.1による実装
基礎からのOAuth 2.0とSpring Security 5.1による実装
Masatoshi Tada
 
正しいものを正しくつくる
正しいものを正しくつくる正しいものを正しくつくる
正しいものを正しくつくる
toshihiro ichitani
 
こわくない Git
こわくない Gitこわくない Git
こわくない Git
Kota Saito
 

What's hot (20)

Javaのログ出力: 道具と考え方
Javaのログ出力: 道具と考え方Javaのログ出力: 道具と考え方
Javaのログ出力: 道具と考え方
 
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
 
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
 
目grep入門 +解説
目grep入門 +解説目grep入門 +解説
目grep入門 +解説
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
 
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
 
WayOfNoTrouble.pptx
WayOfNoTrouble.pptxWayOfNoTrouble.pptx
WayOfNoTrouble.pptx
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
 
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるなテスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
 
なぜコンピュータを学ばなければならないのか 21世紀の君主論
なぜコンピュータを学ばなければならないのか 21世紀の君主論なぜコンピュータを学ばなければならないのか 21世紀の君主論
なぜコンピュータを学ばなければならないのか 21世紀の君主論
 
スマホゲームのチート手法とその対策 [DeNA TechCon 2019]
スマホゲームのチート手法とその対策 [DeNA TechCon 2019]スマホゲームのチート手法とその対策 [DeNA TechCon 2019]
スマホゲームのチート手法とその対策 [DeNA TechCon 2019]
 
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveDXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
 
GoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホンGoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホン
 
SAT/SMTソルバの仕組み
SAT/SMTソルバの仕組みSAT/SMTソルバの仕組み
SAT/SMTソルバの仕組み
 
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 
基礎からのOAuth 2.0とSpring Security 5.1による実装
基礎からのOAuth 2.0とSpring Security 5.1による実装基礎からのOAuth 2.0とSpring Security 5.1による実装
基礎からのOAuth 2.0とSpring Security 5.1による実装
 
正しいものを正しくつくる
正しいものを正しくつくる正しいものを正しくつくる
正しいものを正しくつくる
 
こわくない Git
こわくない Gitこわくない Git
こわくない Git
 

Viewers also liked

市場価値で給料が決まるサイボウズの社員だけど、転職ドラフトに参加して給与交渉に挑戦してみました
市場価値で給料が決まるサイボウズの社員だけど、転職ドラフトに参加して給与交渉に挑戦してみました市場価値で給料が決まるサイボウズの社員だけど、転職ドラフトに参加して給与交渉に挑戦してみました
市場価値で給料が決まるサイボウズの社員だけど、転職ドラフトに参加して給与交渉に挑戦してみました
Yusuke Amano
 
導入に困っているあなたに贈る スクラム導入コミュニケーション術
導入に困っているあなたに贈る スクラム導入コミュニケーション術導入に困っているあなたに贈る スクラム導入コミュニケーション術
導入に困っているあなたに贈る スクラム導入コミュニケーション術
Kouki Kawagoi
 
[RSGT2017] つらい問題に出会ったら
[RSGT2017] つらい問題に出会ったら[RSGT2017] つらい問題に出会ったら
[RSGT2017] つらい問題に出会ったら
Takahiro Kaihara
 
なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudyなんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
POStudy
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
 
Atlassian Summit US 2017 #augj
Atlassian Summit US 2017 #augjAtlassian Summit US 2017 #augj
Secured API Acceleration with Engineers from Amazon CloudFront and Slack
Secured API Acceleration with Engineers from Amazon CloudFront and SlackSecured API Acceleration with Engineers from Amazon CloudFront and Slack
Secured API Acceleration with Engineers from Amazon CloudFront and Slack
Amazon Web Services
 
[POStudy]大きなSIerの中で「アジャイルな開発で飯を食う」までの歩み
[POStudy]大きなSIerの中で「アジャイルな開発で飯を食う」までの歩み[POStudy]大きなSIerの中で「アジャイルな開発で飯を食う」までの歩み
[POStudy]大きなSIerの中で「アジャイルな開発で飯を食う」までの歩み
Shigeki Morizane
 
離れた場所でも最高のチームワークを実現する方法 ーサイボウズ開発チームのリモートワーク事例ー
離れた場所でも最高のチームワークを実現する方法 ーサイボウズ開発チームのリモートワーク事例ー離れた場所でも最高のチームワークを実現する方法 ーサイボウズ開発チームのリモートワーク事例ー
離れた場所でも最高のチームワークを実現する方法 ーサイボウズ開発チームのリモートワーク事例ー
Teppei Sato
 
Kubernetes in 30 minutes (2017/03/10)
Kubernetes in 30 minutes (2017/03/10)Kubernetes in 30 minutes (2017/03/10)
Kubernetes in 30 minutes (2017/03/10)
lestrrat
 
Kubernetesにまつわるエトセトラ(主に苦労話)
Kubernetesにまつわるエトセトラ(主に苦労話)Kubernetesにまつわるエトセトラ(主に苦労話)
Kubernetesにまつわるエトセトラ(主に苦労話)
Works Applications
 
形態素解析
形態素解析形態素解析
形態素解析
Works Applications
 
あなたの開発チームには、チームワークがあふれていますか?
 あなたの開発チームには、チームワークがあふれていますか? あなたの開発チームには、チームワークがあふれていますか?
あなたの開発チームには、チームワークがあふれていますか?
Yusuke Amano
 
Hack/HHVM 入門
Hack/HHVM 入門Hack/HHVM 入門
Hack/HHVM 入門
y-uti
 
小さく始める大規模スクラム
小さく始める大規模スクラム小さく始める大規模スクラム
小さく始める大規模スクラム
Keisuke Tsukagoshi
 
WalB: Real-time and Incremental Backup System for Block Devices
WalB: Real-time and Incremental Backup System for Block DevicesWalB: Real-time and Incremental Backup System for Block Devices
WalB: Real-time and Incremental Backup System for Block Devices
uchan_nos
 
3000社の業務データ絞り込みを支える技術
3000社の業務データ絞り込みを支える技術3000社の業務データ絞り込みを支える技術
3000社の業務データ絞り込みを支える技術
Ryo Mitoma
 
Jenkins 2.0 最新事情 〜Make Jenkins Great Again〜
Jenkins 2.0 最新事情 〜Make Jenkins Great Again〜Jenkins 2.0 最新事情 〜Make Jenkins Great Again〜
Jenkins 2.0 最新事情 〜Make Jenkins Great Again〜
Jumpei Miyata
 
50分でふりかえるアジャイルムーブメントの歴史 2017年版
50分でふりかえるアジャイルムーブメントの歴史 2017年版50分でふりかえるアジャイルムーブメントの歴史 2017年版
50分でふりかえるアジャイルムーブメントの歴史 2017年版
Fumihiko Kinoshita
 
【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD
【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD
【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD
満徳 関
 

Viewers also liked (20)

市場価値で給料が決まるサイボウズの社員だけど、転職ドラフトに参加して給与交渉に挑戦してみました
市場価値で給料が決まるサイボウズの社員だけど、転職ドラフトに参加して給与交渉に挑戦してみました市場価値で給料が決まるサイボウズの社員だけど、転職ドラフトに参加して給与交渉に挑戦してみました
市場価値で給料が決まるサイボウズの社員だけど、転職ドラフトに参加して給与交渉に挑戦してみました
 
導入に困っているあなたに贈る スクラム導入コミュニケーション術
導入に困っているあなたに贈る スクラム導入コミュニケーション術導入に困っているあなたに贈る スクラム導入コミュニケーション術
導入に困っているあなたに贈る スクラム導入コミュニケーション術
 
[RSGT2017] つらい問題に出会ったら
[RSGT2017] つらい問題に出会ったら[RSGT2017] つらい問題に出会ったら
[RSGT2017] つらい問題に出会ったら
 
なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudyなんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
 
Atlassian Summit US 2017 #augj
Atlassian Summit US 2017 #augjAtlassian Summit US 2017 #augj
Atlassian Summit US 2017 #augj
 
Secured API Acceleration with Engineers from Amazon CloudFront and Slack
Secured API Acceleration with Engineers from Amazon CloudFront and SlackSecured API Acceleration with Engineers from Amazon CloudFront and Slack
Secured API Acceleration with Engineers from Amazon CloudFront and Slack
 
[POStudy]大きなSIerの中で「アジャイルな開発で飯を食う」までの歩み
[POStudy]大きなSIerの中で「アジャイルな開発で飯を食う」までの歩み[POStudy]大きなSIerの中で「アジャイルな開発で飯を食う」までの歩み
[POStudy]大きなSIerの中で「アジャイルな開発で飯を食う」までの歩み
 
離れた場所でも最高のチームワークを実現する方法 ーサイボウズ開発チームのリモートワーク事例ー
離れた場所でも最高のチームワークを実現する方法 ーサイボウズ開発チームのリモートワーク事例ー離れた場所でも最高のチームワークを実現する方法 ーサイボウズ開発チームのリモートワーク事例ー
離れた場所でも最高のチームワークを実現する方法 ーサイボウズ開発チームのリモートワーク事例ー
 
Kubernetes in 30 minutes (2017/03/10)
Kubernetes in 30 minutes (2017/03/10)Kubernetes in 30 minutes (2017/03/10)
Kubernetes in 30 minutes (2017/03/10)
 
Kubernetesにまつわるエトセトラ(主に苦労話)
Kubernetesにまつわるエトセトラ(主に苦労話)Kubernetesにまつわるエトセトラ(主に苦労話)
Kubernetesにまつわるエトセトラ(主に苦労話)
 
形態素解析
形態素解析形態素解析
形態素解析
 
あなたの開発チームには、チームワークがあふれていますか?
 あなたの開発チームには、チームワークがあふれていますか? あなたの開発チームには、チームワークがあふれていますか?
あなたの開発チームには、チームワークがあふれていますか?
 
Hack/HHVM 入門
Hack/HHVM 入門Hack/HHVM 入門
Hack/HHVM 入門
 
小さく始める大規模スクラム
小さく始める大規模スクラム小さく始める大規模スクラム
小さく始める大規模スクラム
 
WalB: Real-time and Incremental Backup System for Block Devices
WalB: Real-time and Incremental Backup System for Block DevicesWalB: Real-time and Incremental Backup System for Block Devices
WalB: Real-time and Incremental Backup System for Block Devices
 
3000社の業務データ絞り込みを支える技術
3000社の業務データ絞り込みを支える技術3000社の業務データ絞り込みを支える技術
3000社の業務データ絞り込みを支える技術
 
Jenkins 2.0 最新事情 〜Make Jenkins Great Again〜
Jenkins 2.0 最新事情 〜Make Jenkins Great Again〜Jenkins 2.0 最新事情 〜Make Jenkins Great Again〜
Jenkins 2.0 最新事情 〜Make Jenkins Great Again〜
 
50分でふりかえるアジャイルムーブメントの歴史 2017年版
50分でふりかえるアジャイルムーブメントの歴史 2017年版50分でふりかえるアジャイルムーブメントの歴史 2017年版
50分でふりかえるアジャイルムーブメントの歴史 2017年版
 
【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD
【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD
【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD
 

More from Itsuki Kuroda

大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
Itsuki Kuroda
 
カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021
Itsuki Kuroda
 
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
Itsuki Kuroda
 
大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd
Itsuki Kuroda
 
カネとAgile #RSGT2018
カネとAgile #RSGT2018カネとAgile #RSGT2018
カネとAgile #RSGT2018
Itsuki Kuroda
 
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップLeanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップ
Itsuki Kuroda
 
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
Itsuki Kuroda
 
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
Itsuki Kuroda
 
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanリーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
Itsuki Kuroda
 
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
Itsuki Kuroda
 
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupLEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartup
Itsuki Kuroda
 
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
Itsuki Kuroda
 
LEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWLEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEW
Itsuki Kuroda
 
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
Itsuki Kuroda
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
Itsuki Kuroda
 
LEANSTARTUPの現場 #leanstartup
LEANSTARTUPの現場 #leanstartupLEANSTARTUPの現場 #leanstartup
LEANSTARTUPの現場 #leanstartup
Itsuki Kuroda
 
リーンスタートアップ概論
リーンスタートアップ概論リーンスタートアップ概論
リーンスタートアップ概論
Itsuki Kuroda
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
Itsuki Kuroda
 
Let's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartupLet's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartup
Itsuki Kuroda
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
Itsuki Kuroda
 

More from Itsuki Kuroda (20)

大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
 
カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021
 
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
 
大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd
 
カネとAgile #RSGT2018
カネとAgile #RSGT2018カネとAgile #RSGT2018
カネとAgile #RSGT2018
 
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップLeanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップ
 
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
 
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
 
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanリーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
 
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
 
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupLEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartup
 
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
 
LEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWLEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEW
 
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
 
LEANSTARTUPの現場 #leanstartup
LEANSTARTUPの現場 #leanstartupLEANSTARTUPの現場 #leanstartup
LEANSTARTUPの現場 #leanstartup
 
リーンスタートアップ概論
リーンスタートアップ概論リーンスタートアップ概論
リーンスタートアップ概論
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
 
Let's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartupLet's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartup
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
 

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