-
「効率」という言葉で指し示してるものが2通りあるよね、という指摘
-
図はちょっとわかりにくいと思う
-
ここでリソース効率性と呼ばれているものは制約理論での工場機械の稼働率に対応している
- バッチサイズの話、たくさんまとめた方が安く作れる場合に、リソース効率性ばかり考えていると「一番安い大きなバッチサイズで作ろう」となってしまう
- バッチサイズが大きくなると工場機械に材料を運び込んだり、作ったものを運び出したりするところに時間がかかるようになるがそれを見落としがち
-
フロー効率性は、リードタイムの短さに相当
-
この二つを両方「効率という言葉が指しうるもの」として、トレードオフの関係になりやすいと説く
-
学びを重視する経営においては、リードタイムの短さが学びの量の増加に直結するので好まれる
-
バッチサイズを減らすためには
-
- 思考のプロセスは矢印が逆だという指摘
-
リリース日という制約を所与のものとしがち
- その結果リソース効率性重視の考え方に変わってしまう
- この制約を動かせるようにする
-
- ペアプログラミングは流量が減って品質が上がる
- 単位時間の作業量としては半分になっているが、品質が上がるのでリソース効率性は半分よりは多い
- 品質を保つために2人の人によって実装とコードレビューをやってる場合、それが1回で済むのでリードタイムが縮まる、フロー効率性は上昇する
- 副次作用として知識の共有が起きて「できる人が埋まってるので処理待ち」の発生頻度が下がる、これはリソース効率もフロー効率も上がる
-
フロー効率性（流す量を減らす）をあげると、ライン上にタスクまちの人が増えて、何もしない人がうまれる。（リソース効率性悪化）
-
リソース効率性（流す量を増やす）をあげると、ライン上に人まちのタスクが増えて、リードタイムが増える。（フロー効率性悪化）
- ペアプログラミングは流量が減って品質が上がる
関連