- リソース効率がいい
- 稼働率が100%、暇な人がいない
- フロー効率がいい
- 機能リリースまでのリードタイムが短い
- 一つのタスクに複数人でとりくむ
- 一時的に手持ち無沙汰な人がいる状態
- タスクが得られるリソースの時間を最大化する
- ペアプロ・モブプロ、クロスファンクショナルチーム
同じ作業に複数人で取り組んでも、時間の浪費だ！って考えるのはリソース効率 フローとリソースはトレードオフになりやすい フロー=流れを止めずに小さいサイクルを素早く回す
余裕がある状態で機能リリース時期も変わらないんだったらフロー効率のがよくない？いいところばっかり言うけどデメリットは？銀の弾丸はないんですよね？ → すべての機能をリリースするまでの稼働時間は増える。同じタスクに複数で取り組むんだからそれはそうだよね ただ全機能出揃ってからリリース！じゃなくて一つできたらリリース！のアジャイル開発の考え方だから、順番に価値を届けられる
大きい塊を渡して、スコープを削ることなく全部必要っていうのはリソース効率 1st、2ndと順に出していきましょうよっていうのはフロー効率 どんとでかいアイテムをこなそうとすれば稼働は100%になるからリソース効率はよくなるよ、それを選んだんだから当然
toB案件だと結局、一つの完成品をお届けしようってなってでかい塊になることが多いよね… アジャイルは顧客の理解もないとできないってそういうこと
フロー効率重視で開発プロセスを組んだものの、知らず識らずのうちにリソース効率にフォーカスしてしまうっていうのはよくある リリース日が固定されていて、途中で大きな要件追加が舞い込んでくると、そういう考えになっちゃいがち
フロー効率とリソース効率について思うこと - タマネギプログラマーの雑記
曰く、「リソース効率は悪でフロー効率こそが目指すべき姿」であるとか、「フロー効率こそが価値を最大限に発揮できる方法」であるとかそういう声である。
これはリソース効率というコンセプトの理解として正しくない。
ですよね いい話ばっかり聞かされるしウォーターフォールは悪、アジャイルが最強って感じになっちゃって偏っちゃうけど違うよね
この図だけを見た人は必ずこう思うはずである。
「全てのアイテムが同じ期間で完了するのなら、トータルのリードタイムが短くなるフロー効率の方が良いに決まっているじゃないか」と。
まさにこれ、この図の書き方はよくない 実際にはフロー効率では時間はもっとかかる 一つのアイテムは素早くリリースできるけど
リソース効率は、フィードバックを入れて方向転換することには弱いが、予め決められたアイテム群をより早く完了することができる。
よって、いわゆるプロジェクト型の開発に向いていると言える。
プロジェクト型の開発では、プロジェクト完了までアイテムが価値を発揮する必要がないため、個々のリードタイムの長さは問題にならない。
納期と要件がすでに決まっているときにフロー効率がいいんだってねじ込むのは違うよ つかいどきというものがあるので 仮説検証型のプロジェクトで小さく作って反応を見たいっていうときには有効だよ