#はじめに
前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。
今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。
そして、組織における効率性の価値観が異なると、新しい効率性に関して理解をする前に「もったいない」と感じてしまい、新しい文化を取り入れづらくしてしまう点について掘り下げていきます。
効率性は１つではない。
効率性について考えるとき、人々はしばしば効率性の指す意味は１つであり、自明であると考えがちです。しかし、立ち止まって考えてみると、コストを下げるために効率を上げることもあれば、売上を上げるために効率的になることもありますし、時間を生み出すために効率的であろうと考えることもあります。これらは通じるところもありますが、異なるところもあります。
そして、何を効率的だと考え、何を非効率だと考えるのかは、これまでの成功体験や価値観の違いによるところが実は大きいのです。これらの違いについて、お互いに理解し合わないうちに様々な議論をしても、そもそもの価値観の物差しが違うため、トラブルに発展してしまうことが多かったりします。効率性は１つではないのです。まずは、効率性という物差しは複数あるということを理解し、自分の物差しだけで断じないことが重要です。
さて、ソフトウェア開発においても、ある２つの効率性の対比が存在します。「リソース効率」と「フロー効率」です。モダンなソフトウェアを継続的に開発するチームは、「フロー効率」をまずは重視することが多いのですが、それは旧来の「リソース効率」を重視したプロジェクト的な価値観からすると”もったいない”つまり非効率だと感じてしまうのです。このような効率性を巡る価値観の違いを理解していき、チームで開発することとはどういうことなのかを考えていきましょう。
「フロー効率」と「リソース効率」
フロー効率性とは、「価値を届けるためのリードタイム」を重視して考える効率性のことです。リードタイムとは、たとえば、これがEコマースであれば、商品が注文してから届くまでの時間のことです。ソフトウェア開発においては、あるタスクやイシューが起票されてから実際にリリースされるまでの時間のことを指しています。この時間が短くなるほど、フロー効率が良いという言い方をします。
それに対して、リソース効率とはその名の通り「人員などのリソースが遊び無く稼働している」ことを重視して考える効率性のことです。稼働率の高さを主眼に考える効率の良さのこととも言えます。
２つの効率性の違いを知るために、コンビニのレジを例に考えてみましょう。
「並んでいる人のいないレジ」と「たくさんの人が並んでいるレジ」を想像してみてください。どちらが客であるあなたにとってうれしいでしょうか。きっと、すぐに商品を買って帰ることができる前者ではないでしょうか。このようにお客様にとっての待ち時間が少ないという価値がフロー効率がよい状態です。
一方で、コンビニのスタッフの立場になると、ひっきりなしにお客さんに対応できる後者のほうが、単位時間あたりの売上は高く、売上あたりの人件費は安くつきそうです。このような状態であれば、リソース効率はよいといえます。
このようにリードタイムを重視するフロー効率にとって効率的なシチュエーションが、リソース効率ではそうではなく、逆に稼働率を重視するリソース効率にとって効率的なシチュエーションがフロー効率的は悪くなると言う一見すると二項対立的な関係があります。
それでは、ソフトウェア開発でリードタイムが重視されるのはどのようなケースなのでしょうか。それは、たとえば競合やマーケットの様々な変化に臨機応変に対応したいときや、素早い仮説検証を行いたいときなどです。つまり、近年の変化の早いソフトウェアビジネスなどではリードタイムが短いことは、価値につながりやすいと考えられているのです。そのため、これまでのリソース効率を重視したソフトウェア開発から、フロー効率を中心に考えたソフトウェア開発へと変化しつつあるのが現状です。
リソース効率はトラック、フロー効率はベルトコンベア
リソース効率の考え方で物事を進めると、価値はまとめてひとまとめにして大きな単位で届ける方が効率が良くなります。その方が、共通点をまとめたり、専門家がまとまって作業する時の効率がよくなるからです。これはトラックにたくさんの荷物を積んで、一気に運ぶのに似ています。
フロー効率の考え方はベルトコンベア的です。単位時間あたりにどれだけ価値を届けられるかを重視して、価値を分割しながら届けます。
このような価値の届け方をしたときに、ソフトウェア開発の性質にどのような違いが生まれるでしょうか。以下に二つのスタイルにおける価値と時間経過のグラフを示します。
リソース効率を重視する場合、チームとして固定の人数で開発するよりもプロジェクトとして必要なタイミングで必要なスキルを持った人員を柔軟に動員できる方が効率的になります。そのため、いわゆるウォータフォール的な開発スタイルを採用することが多くなります。もし、実際に動員した分の費用しか支払わなくて良いのであれば、コスト的にも納期的に短く機能をリリースすることができます。
一方、フロー効率を重視した場合、要求から必要な機能を細切れにして顧客に提供することになります。大きな機能はリードタイムが長くなるため、顧客への価値のある最低限の単位をブラッシュアップしながら提供してくことになります。そのため、いわゆるアジャイル的な開発スタイルを採用することが多くなります。動員も、一時的たくさんの人員に関わってもらうというよりも、固定的なチームで設計からリリースまで自分たちでできるような単位に分解していくことに投資するようになります。そうすると、設計もできる人月単価の高い人にも実装やテストをお願いすることも出てきますし、フロントエンドが得意な人が必要に応じてバックエンドも改修できた方がフロー効率がよいことが出てきます。したがって、ある期間で区切った場合の累計した価値提供の大きさはフロー効率重視スタイルの方が大きくなります。
もし「すべてのまとまった機能」を顧客に早く届けたいのであれば、リソース効率を重視して、プロジェクトを進めることを選ぶこともあるかもしれません。
しかし、顧客向けに提供するサービスでは特にまとまってどんと大きな機能がリリースされるよりも、段階的に早期に最低限の機能が提供できるスタイルあったほうが、競合に先行されお客様を取られてしまったりするリスクが低くなるため、フロー効率への関心が高くなるのです。
部品ではなく価値の単位に分解する
しかし、フロー効率の考え方でソフトウェア開発の仕事を進めるのは意外と難しいものです。これまでまとまって開発していたものを、細かく価値の単位で仕事を区切っていくことが重要になるからです。
このような小さく分割された機能価値の単位を最小市場化機能（MMF : minimal marketable function）と言います。フロー効率を重視した開発を行うには、MMFに分割をしていく方法論が必要になります。
たとえば、自動車を作ろうとしたら、プロジェクト的な発想としては、タイヤなどの部品に分解して、それらを１つずつくっていき、すべてをくみ上げた後に市場に投入するという形で作業を分解します。
「全部完成」までのコストは大きくなる
一方、フロー効率を求めるプロダクト的な発想としては、自動車の「乗って移動できるという価値」を基準に考えていきます。スケートボード、キックボード、自転車、バイク、自動車のように顧客に常に価値のある単位に分割し、直す/作り直すという発想で開発単位を分割していきます。
“The Myth of Incremental Development” by Herding Cats under CC BY-NC-ND 3.0
このように価値の単位に小さく分割しながら機能提供するのは、ゼロから自動車を作るだけよりも単純に考えればコストはかかります。毎回毎回、設計が大きく変わったり、同じようなテストを実施する必要が出てくるからです。しかし、CI/CDなどのデリバリーパイプラインを効率化したり、柔軟で捨てやすいアーキテクチャ(犠牲的アーキテクチャ）などの工夫をする必要が出てきます。
このような努力や工夫を行ったとしても、多くの場合、開発コストは大きいままです。しかし、提供する価値やその市場性はどうでしょうか。生産性について考えるときに、フロー効率とリソース効率のどちらに目が向いているかは大きな違いになります。
「もったいない」マインドがチームを解体させる
このように、「リソース効率」の世界から見ると「フロー効率」を高めるための活動は、一見するとコストがかかり「もったいない」と感じさせてしまうことが多いのです。
えてして、物事は共通するところをしっかり計画して、まとめてやったら効率が良くなります。でも、それをしすぎると、思いついてから顧客に価値を実現するまでの待ち時間は長くなってしまうかも知れません。
複数プロジェクトが走っていると、特殊な/高いスキルを持つ人は兼務が多くなりがちです。これはリソース効率を追い求めた発想です。兼務が重なることは、一方ではフロー効率を悪化させます。
たとえば、10分かかる仕事があるとします。Aさんは、この仕事を様々な人から頼まれていて、9割の時間この仕事にかかりっきり(稼働率90%)だとします。このとき、あなたが新たにこの仕事を頼んだとき、完了までにどのくらいの時間がかかるでしょうか。
これは典型的な待ち行列理論の問題で、結果は100分になります。実際にかかる10倍も待つ必要があるのです。これが、稼働率が50%になれば20分ですみます。自分の仕事のために忙しい誰かの仕事が必要で、そのための行列に並んでいるとどんどんとフロー効率は悪化していくのです。
コンポーネントチームとフィーチャーチーム
フロー効率を重視する組織は、次第にフィーチャーチームと呼ばれるチーム形態を広く採用するようになります。１つの価値を生むことのできる多様な技能を持ったメンバーで構成されたチームです。1つの価値を生むために同じチーム内で連携するため、待ち行列の段数が少なくなりフロー効率は良くなります。
それに対して、企画、マーケティング、開発、テスト、デザインなどスペシャリティで分けられたチームをコンポーネントチームと言います。１つのチームでは価値を生み出すことができず、コラボレーションをしながらアウトプットを出していく形態です。
コンポーネントチームは、１つの特殊技能を深めていくことができるため、リソース効率は良いのですが、価値が出てくるまでに多段の待ち行列を通過する必要があります。そのためフロー効率は悪化してしまいます。
これは「両利き経営」においては、知の探索型の組織と、知の深化型の組織の対比で捉えることができます。
二項対立を超えて効率フロンティアへ
ここまで、あえてリソース効率とフロー効率は相反する概念のように伝えてきました。しかし、それは正しくありません。どちらも違った観点の効率性で、衝突してしまいがちなポイントがあるだけで、両方悪いこともあれば、両方が良いと言うことも十分にありうるのです。
今の自分たちに適切なリソース効率とフロー効率のバランス点を効率フロンティアと言います。このポイントに向かっていくための学習こそが重要なのです。
しかし、多くの開発現場の場合、これまでのビジネスでは一般的であった「リソース効率」特化型の価値観が支配的であったりします。そのため、一足飛びにバランスと言ってもフロー効率の良さを「体験」したことがないと、どのように改善していけば良いかわからなくなってしまいます。
バランスを取るためには二つの効率性をどちらも経験的・身体的に理解している必要があります。
もし、自分たちが「リソース効率」ばかり重視してしまっているなと感じたら、それを実現するためにフロー効率をまずは重視した形でのチーム開発を進めていく必要があります。そのようにして、フロー効率重視の良し悪しを理解したあとに、段階的にリソース効率を上げていけばいいのです。これは逆もしかりです。
このように異なる価値観の対立を超えていき、新しい価値観の文化を創っていくことが、チームで仕事をする意義であり、最大のメリットなのです。