「フロー効率」をチームの常識にする - 『This is Lean』の内容をチームメンバーにレクチャーした話
フロー効率性と「This is Lean」
あくまで自分の観測範囲での話ではあるのですが，2017年，ソフトウェアやITシステムの開発プロセス関連に興味がある人たちの間でホットだったキーワードのひとつが「リソース効率性とフロー効率性」だったと思います．
私自身，それまで「リソース効率性とフロー効率性」という概念は知らなかったのですが，9月にあった XP 祭り2017 での発表を拝見してから，自分の中では一気に火がつきました． 具体的に「リソース効率性とフロー効率性とは何か」という話は，その時の発表者である id:i2key さんの発表資料やブログのほうが詳しいと思うので，興味のある方はご覧いただければと思います．
www.slideshare.net
簡単に言うと，「効率良く仕事をする」と言っても2つの方向性があり，それが「リソース効率性 (Resource Efficiency)」と「フロー効率性 (Flow Efficiency)」です．
「リソース効率性」とは，「プロセスを構成するリソース (ソフトウェア開発プロセスなら人，病院なら医師や医療機器) の稼働率を高くする」というアプローチで，一方で「フロー効率性」とは「プロセスを流れる価値の単位 (ソフトウェア開発なら開発機能や不具合，病院なら患者) がプロセス内で価値の付加されない待ち時間をなくしてリードタイムを短くする」というアプローチです．
この「リソース効率性とフロー効率性」という概念を明瞭に解説しているのが，i2key さんの登壇資料にもある『This is Lean: Resolving the Efficiency Paradox』という書籍です．
This is Lean: Resolving the Efficiency Paradox (English Edition)
- 作者: Niklas Modig,Pär Åhlström
- 出版社/メーカー: Rheologica Publishing
- 発売日: 2014/04/27
- メディア: Kindle版
- この商品を含むブログを見る
この書籍は，以下のような構成になっています．
- まず，前半にリソース効率性とフロー効率性について解説
- 次に「リーン」という言葉の生い立ちについて解説した
- リソース効率性とフロー効率性のバランスをどう取るかの戦略の観点から「リーン」という言葉の正しい意味を明らかにする
壮大なネタバレ: リーンとは
世間には 「リーン」という言葉を冠した書籍がたくさんありますが，簡潔に「リーンとは何か」を書いている書籍はほとんど無かったように思います．
- 「リーンな UX 開発は小規模な仮説検証を行う」
- 「リーンなソフトウェア開発では品質を作り込み，ムリ・ムダ・ムラを徹底的に排除する」
- 「リーンな製造業では在庫を持たない」
このような「リーンな組織はこういう行動をする」という具体的な手法はそれぞれの書籍に書いてあるし，リーンという言葉を知っている人だったら聞いたことがある人も多いと思います．しかし「リーンとは何か？」という問いに，上に挙げた3つのリーンな組織の具体的な手法を説明することの出来るような答えを用意できる人は多くないのではないでしょうか．
This is Lean という書籍の壮大なネタバレになってしまいますが，本書の中の解説では，Lean とは以下の2つの特徴を持つ，ビジネス戦略を実行するための実行戦略です．
- リソース効率性とフロー効率性のどちらも最高にある状態を目指すこと
- 最初にフロー効率性を高め，その後リソース効率性を高めるという順にアプローチすること
リーンはどのようなビジネス戦略を実現するか (例えば，低価格で利用できる航空便を展開するとか，高価格で至れり尽くせりのコーチングがついてくるスポーツジムを展開するとか，従来より燃費がよくリーズナブルな価格の乗用車を生産するとか) を規定するものではありません．ビジネス戦略によってリーンな実行戦略を実践する具体的な手法は異なるので，例えばリーンな乗用車生産プロセス (TOYOTA Production System とされるもの) の具体的手法のみをソフトウェア開発で模倣しようとすると，期待したとおりの効果を引き出せないことも多いでしょう．その結果として「リーンは車を作るためのもので，ソフトウェア開発には向かない」と結論付けられてしまう問題点も，This is Lean の中では指摘されています．
リソース効率性とフロー効率性のどちらも高い状態 (書籍の中では「Perfect State」と呼ばれ，その中でもそれぞれ100%な効率の状態は「The Star」と呼ばれています) を目指すのはスッと理解できそうですが，なぜリソース効率性でなくフロー効率性を最初に高めるという順になるのか，というのは書籍の前半に解説された2つの効率性の性質や，書籍のサブタイトルにもある「効率性のパラドクス」が大いに関係しているので，詳細が気になる方はぜひ書籍をご一読いただくことをおすすめします．
「This is Lean」レクチャー
で，この書籍の内容に痛く感激した自分は，2日間 (各1時間) をかけて，その内容をチームメンバーにレクチャーしてみました．
レクチャーを通じて「リソース効率」と「フロー効率」という言葉をチーム内での一種の「常識」としてしまうことを狙いとしました．例えばスプリントごとのレトロスペクティブでチームの改善をするときに方向性がブレなくなったり，プロダクトバックログを書き起こす際の粒度が大きくなることを防ぐことができるのではないかという意図です． *1 まだ明らかな効果が出ているというわけではありませんが，そこそこ良い方向に向かっているのではないかという実感はあります．
また，この書籍を自分が読んでいるときにも感じていたし，チームメンバーも気づいていたのですが，プロセスのフロー効率向上を阻害する要因として書籍の中で取り上げられている「リトルの法則」 「制約理論」「ばらつきへの対処」は，システムやマイクロサービス構成を考えるときにも有用な考え方です．2回のレクチャーを通じて，「開発プロセスを整備することも，システムを作ることも，フロー単位とプロセスを構成するリソースの最適配置を考える問題という意味では同じ」という考えをチームメンバーの間で共有できただけでもやってよかったのかなと思っています．
ということで，この記事を読んで興味が湧いた方はぜひ This is Lean を読んでみていただければ良いのではないかと思います！
