リーンとはフロー効率を優先する絶え間ない改善である

This is Lean という本を読んでとても良かったので忘れないうちにまとめておこうと思う

リーンとはフロー効率を優先する絶え間ない改善である

タイトルにも書いたけど、これが本書で言いたいことだと思う。

最初にいい例があって、これを頭に入れておくとその後の話が入って来やすい。

リソース効率とフロー効率

リソース効率とは、サービスにおいてサービスを提供する側のリソースの効率のこと。

本の例では胸のしこりを見つけた患者が最初に行った病院では結果が分からず、その後複数病院を回って結果が出たのが2ヶ月後という内容。

これは各病院でできることに対してリソースを効率化しているために起こっている。

フロー効率とは、サービスを受ける側のニーズを満たす効率のこと。

胸のしこりがあって乳がん専門の病院に行くと、そのニーズに応えることに特化したリソースが準備されており数時間で結果がわかる。

これはサービスを受ける側のニーズを最短で満たしている。

スループット時間

上記の例で患者をフローユニットと呼ぶ。フローユニットとは、リソースが価値を付加する対象のこと。

このフローユニットがニーズに気づいてから、それを満たすまでの時間をスループット時間と呼び、フロー効率を高めるとこの時間が短くなり、リソース効率を高めるとこの時間が長くなっていくというもの。

リソース効率化によってスループット時間が長くなる

病院の例で患者はニーズを満たすまで2ヶ月かかっている。これは最初のニーズが発生してすぐに解決できないことによって別のニーズ（別の病院に行って検査が必要）が発生している状態。

１つの病院で全て終われば発生しなかったことであり、2ヶ月という期間によって患者は不安な2ヶ月を過ごさねばならないため、さらなるニーズ（不安）を発生させている。

フロー効率を優先する

フロー効率を優先することで患者はすぐに結果がわかり、時間的に早く、メンタル的にも不安な日々を送らなくてよくなる（結果が早く出すぎて心の準備が...という話も本では上がっていた）

開発で考えるとフロー効率はリリースまでの時間の短縮化

ふと自分たちの開発に当てはめてみるとフロー効率は機能リリースまでの時間を以下に短くしていくかだなと感じた。

フロー効率を上げるには、仕様ぎめ、実装、レビュー、リリースまでの時間の短縮と考えると、例えば実装に時間がかかっているのは仕様に曖昧なところが残っているのでは？とか、レビューに時間がかかっているのは Pull Request 自体が大きかったり、タスクの細分化がうまくできてなかったりなど、改善する視点がいろいろと出てくるんじゃないかなと感じた。

まとめ

フロー効率という視点を得たことで、自分の開発フローをどう改善すると良くなるか考える新しい視点が加わった気がする。

あと、本の最初の例がそれ以降の話の全ての具体例になっていて理解しやすい構造になっていたのも良かった。

開発体制をもっと良くしていくためにチームメンバーと共有してもっといいチームにできるようにしていきたい。