フロー効率とリソース効率について思うこと
最近、フロー効率、リソース効率という言葉をよく聞くようになってきた。
業界でどの程度流行っているのかは知らないが、少なくとも@i2key御大将の近くのコミュニティに属している関係で、僕は日常的によく聞く。
リソース効率に偏りがちなシステム開発の環境において、フロー効率という考え方が広まっていることは単純に良いことだと思う。
一方で、フロー効率がバズワード的になるにつれて、正しく理解されていないのではないかと思える声もしばしば聞くようになった。
曰く、「リソース効率は悪でフロー効率こそが目指すべき姿」であるとか、「フロー効率こそが価値を最大限に発揮できる方法」であるとかそういう声である。
これはリソース効率というコンセプトの理解として正しくない。
もっとも、これは僕の観測範囲での話なので、実際そう勘違いしている人は少ないのかもしれない。
しかし、もしかしたら多数いるそういう人達へ向けて、そうでなくとも一回自分の考えをまとめる意味も込めて、フロー効率とリソース効率について文章を書いてみる。
但し書き
- 僕は学生時代の知識から、工程管理的なアプローチでフロー効率とリソース効率について書いていく
- 僕はリーンやXPの専門家ではない。「こういう解釈もある」程度に思うのがおすすめ
- フロー効率を銀の弾丸だと思っている人をメインの対象にしている。そうでない人には、焼き直しになって退屈かもしれない
- この記事は、Recruit Engineers Advent Calendar 201710日目の記事である
フロー効率とリソース効率
まず、フロー効率とリソース効率という言葉についておさらいしてみたいと思う。
これは正直、前述の@i2keyさんのこの記事を読んでしまうのが一番はやいと思う。
簡単に一言で表すならば
フロー効率: それぞれのアイテムが最も効率よく工程を進むことにフィーチャーすること
リソース効率: それぞれのリソースが最大限稼働することにフィーチャーすること
と言える。
とどのつまりこの二つは、何の効率に焦点を当てて考えるかというコンセプトの違いを表す言葉である。
フロー効率は正義なのか
上記の@i2keyさんの記事を読めば、「フロー効率はとても良いものだ」という印象を持つ人が多いだろう。
それ自体は問題ないのだが、「良いものだ」と思いすぎてしまう場合これはまずい。
この記事はとてもいい記事なのだが、バイアスがかかりやすい箇所が多少ある。
例えば、こちらの図などは誤解を生みやすい。
引用: (http://i2key.hateblo.jp/entry/2017/05/15/082655)
この図だけを見た人は必ずこう思うはずである。
「全てのアイテムが同じ期間で完了するのなら、トータルのリードタイムが短くなるフロー効率の方が良いに決まっているじゃないか」と。
しかし、実際には多くの場合で、フロー効率の方が全てのアイテムが完了するタイミングは遅くなる。
フロー効率側は大体においてオーバーヘッドが発生するため、一つ一つのアイテムが完了するのにかかる時間が長くなってしまうからだ。
@i2keyさんがこの記事の内容を口頭で説明するときには補足してくれるのだが、記事内では充分ではない。
フロー効率に集中するということは、一部のリソースを遊ばせてでもあるアイテムのリードタイムを短くするということである。
そのため、リソース効率に比べオーバーヘッドが発生しやすい。
具体的な例を下に示す。
完了に1単位時間かかる行程が3つずつあるアイテムA・Bを、作業者A・Bの二人で完了させる場合を考える。
ただし、アイテムAの工程2は、同アイテムの工程1が完了しない限り取り掛かれないという制約があるものとする。
フロー効率、リソース効率、それぞれのアプローチで工程を組むと以下のようになる。
これを見ると、フロー効率の場合、アイテムAのリードタイムは短くなるが、全てのアイテムの完了が遅くなることがわかる。
フロー効率では、個々のアイテムのリードタイムは減るが、フローを優先するために、発揮できる総生産量が低くなってしまうのである。
一方リソース効率は、個々のアイテムのリードタイムは増えるが、極力リソースを遊ばせないため、発揮できる総生産量が高くなる。
最も、アイテムAの工程間に制約がなければフロー効率でも3単位時間で全てのアイテムは完了するのだが、実際の開発においては多くの場合こういった制約がついて回るはずだ。
このように、基本的には、組織の総生産量の観点で有利なのはリソース効率の方である。
ではフロー効率はいけないのか
上で、組織の総生産量の文脈ではリソース効率の方が優れているという話をした。
しかし、だからと言ってフロー効率がいけないというわけではない。
この文章の主旨はフロー効率disではなく、それぞれの特性を理解し、正しく使うことが大事だということである。
もう一度それぞれの特性をまとめてみよう。
フロー効率: あるアイテムのリードタイムを短くすることができるが、総生産量の面で不利
リソース効率: 組織の総生産量の最大化に有利であるが、個々のアイテムのリードタイムの面で不利
こうして見ると、総生産量とリードタイムのコンテクストにおいては、きれいにトレードオフになることがわかる。
では、それぞれはどのような場合に適材なのだろうか。
フロー効率は、任意のアイテムのリードタイムを短くできる。
ということは、仮説検証型の開発にもってこいと言える。
一回のリリースサイクルのリードタイムを短くすることで、仮説検証の試行回数を増やすことができるからだ。
イテレーティブな開発では、完了しなければならないアイテムの総数は一般的に決まっていないため、総生産量はある程度犠牲にしても良い。
リソース効率は、フィードバックを入れて方向転換することには弱いが、予め決められたアイテム群をより早く完了することができる。
よって、いわゆるプロジェクト型の開発に向いていると言える。
プロジェクト型の開発では、プロジェクト完了までアイテムが価値を発揮する必要がないため、個々のリードタイムの長さは問題にならない。
じゃあGoogleとかはどうなの？
こういう話をすると、フロー効率擁護のニュアンスで
「それでもGoogleは、週の20%をフリーにすることで生産性を上げた」や、「稼働率100%のCPUはまともに動かない」といった意見を言ってくる人がたまにいるが、これは詭弁ないしは勘違いである。
というのも、上記2例は本質的にフロー効率とリソース効率とは違う文脈の話だからだ。
(僕が考えるに)フロー効率とリソース効率という言葉は、工程設計の戦略を表す言葉である。
工程設計とはある種の制約充足問題であって、個々のリソースの稼働率は一定であるという前提が必要である。
そのため、フロー効率的なアプローチでも、リソースである人間は制約上可能な限り最大限に稼働することが前提となる。
100%の稼働による人間の生産性の低下は、議論の埒外の話なのである。
それはどちらかというと、リソースとしての人間の特性の話であり、これは人間工学などの方が対象分野としては近いだろう。
そういった点は、フロー効率だろうとリソース効率だろうと、一日の工数を低めに設定することで実現を目指すことができる。
まとめ
リソース効率は銀の弾丸ではなく、利点と欠点を持った一つのアプローチにすぎない。
トレードオフを理解し、適材適所で使う事が大事だ。
もちろん、理想的な状況は、リードタイムが短くかつ総生産量も損ねない状況であるため、フロー効率的な工程でリソースが遊ばないような工程設計ができるのが一番良い。
しかし、現実には制約があり、そのような理想的な工程設計は多くの場合できない。
そのため、自分たちが置かれた状況を理解し、より良い手段を選択しなければならないのである。
