リソース効率よりフロー効率を重視する
はじめに
カラダノートの堀内です。 今回は作業効率や生産性について持論を展開します。
それは、 仕事の進め方には リソース効率 と フロー効率 があるよね、という話と フロー効率を重視したほうがいいよね という話です。
リソース効率とフロー効率
リソース効率とは
- リソース(キャパ)を最大限に利用しよう、という考え方です。
- 交通に例えると、道路に車を詰められるだけ詰めよう、という考え方です。
フロー効率とは
- 仕事の流れを最大限に良くしよう、という考え方です。
- 交通に例えると、車間距離をとって車の流れを良くしよう、という考え方です。
交通流の世界を覗く
理論的な背景は交通流の分野に通じるものがあります。
道路のリソース効率を上げる(道路に車を詰められるだけ詰める)と、ある一定までは交通流量(単位時間あたりに通過した車両数)が向上しますが、ある閾値を境に交通流量が低下していきます。イメージとしては、車がびっしり道路にうまってノロノロ走っている状態です。
図にすると以下のようになります。
この図は交通流の世界では基本図(Q-k図)と呼ばれています。 (学術的な数値の正確さはすみませんがググってください)。
この図から読み取れるのは、
- 「臨界密度を境に、車両密度に比例して交通流量が低下する」領域と、
- 「臨界密度を境に、車両密度に比例して交通流量が上昇する」領域がある、
ということです。
なぜ密度が高くなるほど交通流量が低下するか。
たとえば、ある一台がブレーキを踏むと、その後ろのすべての車に影響を及ぼします。
すると、全体の車の流れが悪くなり、その結果、交通流量が低下するイメージです。
ちなみに、海外の高速道路では車の密度を制御するために、入り口に one vehicle per green という標識や信号があります。 フロー効率ですね。
何が言いたいか
縦軸(交通流量)に注目すると、密度が低いところと高いところで、交通流量が同じところがあります。
このとき、密度が低い方が、目的地への到着時刻の精度が上がります。 なぜなら、一台がブレーキを踏んでも、その影響を受けにくいからです。
これがフロー効率の恩恵です。
要するに
仕事の世界に話を戻します。
車の流れ = 捌いた仕事量、車の密度 = 対応中の仕事量 だとしたら、
フロー効率を重視すれば、仕事の期限の精度があがる
ということになります。
あるいは、対応中の仕事量を閾値より増やすと、捌いた仕事量が低下する、ということです。
「一台がブレーキを踏むと、それ以降のすべての車に影響を及ぼし、車の流れが悪くなる」に例えるなら、ある工程や誰かの作業が遅れたとき、
それが全体に及ぼす影響が大きく、チーム全体として捌いた仕事量が低下する
ということです。
もしそういう状態に陥っているのであれば対応中の仕事量を減らせばよいのです。 これは単に「仕事の量を減らす」という意味ではなくて、「仕掛りの仕事を減らす」、ということです。
WEBサーバで言えば、リソース効率を重視するのが Apache で、フロー効率を重視するのが Nginx だと言うこともできます。
私達は「対応中の仕事量」ではなく「捌いた仕事量」を重視しています。 アジャイルやモブプログラミングを採用しているのはそのためです。 そちらについては他の記事も読んでいただければと思います。