https://qiita.com/hirokidaichi/items/f59e611772c02f2e74ee
前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。
今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。
そして、組織における効率性の価値観が異なると、新しい効率性に関して理解をする前に「もったいない」と感じてしまい、新しい文化を取り入れづらくしてしまう点について掘り下げていきます。
効率性について考えるとき、人々はしばしば効率性の指す意味は１つであり、自明であると考えがちです。しかし、立ち止まって考えてみると、コストを下げるために効率を上げることもあれば、売上を上げるために効率的になることもありますし、時間を生み出すために効率的であろうと考えることもあります。これらは通じるところもありますが、異なるところもあります。
そして、何を効率的だと考え、何を非効率だと考えるのかは、これまでの成功体験や価値観の違いによるところが実は大きいのです。これらの違いについて、お互いに理解し合わないうちに様々な議論をしても、そもそもの価値観の物差しが違うため、トラブルに発展してしまうことが多かったりします。効率性は１つではないのです。まずは、効率性という物差しは複数あるということを理解し、自分の物差しだけで断じないことが重要です。
さて、ソフトウェア開発においても、ある２つの効率性の対比が存在します。「リソース効率」と「フロー効率」です。モダンなソフトウェアを継続的に開発するチームは、「フロー効率」をまずは重視することが多いのですが、それは旧来の「リソース効率」を重視したプロジェクト的な価値観からすると”もったいない”つまり非効率だと感じてしまうのです。このような効率性を巡る価値観の違いを理解していき、チームで開発することとはどういうことなのかを考えていきましょう。
フロー効率性とは、「価値を届けるためのリードタイム」を重視して考える効率性のことです。リードタイムとは、たとえば、これがEコマースであれば、商品が注文してから届くまでの時間のことです。ソフトウェア開発においては、あるタスクやイシューが起票されてから実際にリリースされるまでの時間のことを指しています。この時間が短くなるほど、フロー効率が良いという言い方をします。
それに対して、リソース効率とはその名の通り「人員などのリソースが遊び無く稼働している」ことを重視して考える効率性のことです。稼働率の高さを主眼に考える効率の良さのこととも言えます。
２つの効率性の違いを知るために、コンビニのレジを例に考えてみましょう。
「並んでいる人のいないレジ」と「たくさんの人が並んでいるレジ」を想像してみてください。どちらが客であるあなたにとってうれしいでしょうか。きっと、すぐに商品を買って帰ることができる前者ではないでしょうか。このようにお客様にとっての待ち時間が少ないという価値がフロー効率がよい状態です。
一方で、コンビニのスタッフの立場になると、ひっきりなしにお客さんに対応できる後者のほうが、単位時間あたりの売上は高く、売上あたりの人件費は安くつきそうです。このような状態であれば、リソース効率はよいといえます。
このようにリードタイムを重視するフロー効率にとって効率的なシチュエーションが、リソース効率ではそうではなく、逆に稼働率を重視するリソース効率にとって効率的なシチュエーションがフロー効率的は悪くなると言う一見すると二項対立的な関係があります。
それでは、ソフトウェア開発でリードタイムが重視されるのはどのようなケースなのでしょうか。それは、たとえば競合やマーケットの様々な変化に臨機応変に対応したいときや、素早い仮説検証を行いたいときなどです。つまり、近年の変化の早いソフトウェアビジネスなどではリードタイムが短いことは、価値につながりやすいと考えられているのです。そのため、これまでのリソース効率を重視したソフトウェア開発から、フロー効率を中心に考えたソフトウェア開発へと変化しつつあるのが現状です。
リソース効率の考え方で物事を進めると、価値はまとめてひとまとめにして大きな単位で届ける方が効率が良くなります。その方が、共通点をまとめたり、専門家がまとまって作業する時の効率がよくなるからです。これはトラックにたくさんの荷物を積んで、一気に運ぶのに似ています。