リソース効率は、ほとんどの業界で重視されているのではないでしょうか。雇っている人にはできるだけ仕事をさせるのは、wikipedia:機会費用 の考え方からしても当たり前ですよね。一人のエンジニアには一人月の仕事を割り振るというのも、ある種リソース効率的な考え方だと認識しています。
処理をする側（IT でいえばエンジニア）に焦点を合わせたリソース効率に対し、フロー効率は処理される側（例えば顧客）に焦点を合わせています。そしてリソース効率をあげる戦略を取った場合、一般的にはフロー効率が下がる、両立できないとされています。これはなぜなのでしょうか。
引き続き読み進めている THIS IS LEAN には色々と目に鱗な話があったので、ここにまとめておきます。
フローの効率化は待ち行列理論で説明される
The DevOps ハンドブックでも、DevOps の一丁目一番地は「フローの高速化」とされています。
フローは何で測られるかと言うとリードタイムであり、特定の要求を受けてから当該の要求が実現されるまでの時間、といった形で定義されます。 フロー効率についても、THIS IS LEAN では以下のように定義されており、リードタイムが小さくなればフロー効率が上がります。
we defined flow efficiency as the sum of value-adding activities in relation to the throughput time.
(意訳)フロー効率は、スループット時間に対する(対象に)価値を付与したアクティビティの時間の割合
リードタイムに含まれる待ち時間
このリードタイム、なんとなく「作業時間」のみを言っているように見えますが、実のところ「待ち時間」が含まれます。 The DevOps ハンドブックでは、リードタイムに含まれる「作業時間」には「プロセスタイム」という名前を当てて、この概念を整理しています。
つまり、リードタイムを短縮するには、プロセスタイムだけではなく待ち時間も短縮しなければなりません。場合によっては作業時間よりも待ち時間の方が支配的になりますし、特に忙しいプロジェクトにおいてはそちらの方が多いのではないでしょうか。この「経験上」の感覚を説明してくれる理論が待ち行列理論です。
リトルの法則
待ち行列理論において、一番有名であろう法則が wikipedia:リトルの法則 です。リトルの法則は、処理を待っている顧客数 は顧客の到着率
と顧客あたりの処理時間
に等しいという法則です。特筆すべきは以下の点でしょうか。
本法則は直感的には理にかなったものであるが、対象がどのような確率分布であってもこの振る舞いをするという点と、到着した顧客やサービスする顧客に基づいてどのようにスケジュールするかについて何の仮定も設けない点は特筆すべきである。
何が言いたいのかというと、リードタイムを減らしフロー効率をあげるには、「待っている顧客の数」を減らす必要があると言うことです。ここでの顧客数は、タスク数と言い換えても良いでしょう。つまり、いかにして「滞留しているタスクの行列の長さを減らすか」がリードタイム・フロー効率に直結するということです。
稼働率と行列の長さの関係
ところが待ち行列理論が示すのは、処理をするリソース（例えばエンジニア）稼働率が高くなると、待ち行列長が指数関数的に長くなると言う結論です。待ち行列が長くなれば、当然待ち時間が増大します。
以下は待ち行列モデルにおいてもっともシンプルとされるモデル1ですが、稼働率が高い領域では飛躍的に待ち時間が伸びていることがわかります。
つまり、エンジニアの稼働率を高くすればするほど、リードタイムが伸びるという関係にあります。
リードタイムを輪をかけて悪くするもの
さらにリードタイムを悪化させるのが「変動」です。変動にも様々ありますが、具体例としてはタスクの処理時間の変動があります。手戻り、横やり、マルチタスクと、処理時間を変動させる要素は多数あります。そして、この変動が待ち時間にどう影響するのかを解析したのが wikipedia:en:Kingsman's formula です。
(Guest Blog: Finding Science and Success with Lean Principles in R&Dより引用)
要するに、処理時間が変動すればするほど待ち時間が伸び、そしてフロー効率が下がる。
リソース効率とフロー効率が両立できない理由
リソース効率を高めるためには、処理を行うリソースに「遊び」が出ないように、タスクを割り当てていかなければなりません。場合によっては、早くタスクを消化した場合に備えて「バッファとなるタスク」すらアサインする必要があるでしょう。 そうするとタスクは待ち行列に並び、リソースの稼働率はあがります。
待ち行列が長くなり、リソースの稼働率があがれば、待ち時間が飛躍的に増加します。待ち時間が増加すればリードタイムが上昇し、フロー効率が下がります2。
感想
このようにリソース効率で物事を考えると言うことは、その時点でフロー効率を捨てているようにぼくには感じられます。 リーン、アジャイルといったプロジェクトに人月を当てはめて良いのかどうかという点で、当てはめるのがよくないとして代替案はどうあるべきか、悩ましい問題が続きます。
-
http://pages.cs.wisc.edu/~dsmyers/cs547/lecture_12_mm1_queue.pdf より引用。↩
-
厳密には、リードタイムが長くなった分だけ価値を付与する時間も長くなれば良いが、現実的には難しい。↩
