フロー効率重視の開発について考える 前編 ～短期目線の話～

TL;DR（前編のみ）

• 「リソース効率重視」、「フロー効率重視」と呼ばれる開発スタイルは、それぞれソロ開発（個人分担制）とアンサンブル開発（1つのタスクを複数人で協働する方法）を指すのが一般的
• 短期的には、ソロ開発はスループットの高さ（開発アウトプットの総量）、アンサンブル開発はリードタイムの短さ（1タスクが完了する速さ） に長所がある
  • どちらがいいかは状況次第だが、アウトプットでなくアウトカムを見て判断すべき

目次

僕はなんでこれを書いているのか

アジャイルで開発やっていると、度々「フロー効率重視」という言葉が聞こえてきます。しかし、この言葉が意味するところの理解は人によって結構バラバラだったりします。リソース効率、フロー効率 といった言葉を扱ったブログ記事なども多数ありますが、よくよく読むとちょっとずつ違うことを書いていたりして、割と混乱しがちです。

この記事では、特にアジャイルの文脈で「フロー効率重視」あるいは「リソース効率重視」と呼んだ場合、とどのつまり何を意味しているのか、結局どっちがいいのか、を考察していきます。

正確な定義を試みるというよりは、僕自身がどう解釈しているか、それぞれのメリットデメリットをどう評価しているか、という点を重視して書いています。そういう意味では、色々ある、ちょっとずつ違うフロー効率の解説記事をもう1個増やすだけかもしれません。そのへんはご留意ください。

2つの開発スタイルについて

長々と前置きした上でしょっぱなからいきなりですが、「リソース効率重視」や「フロー効率重視」という世間一般の表現は、実際にはあまり正確ではありません。

よくその2つの言葉を使って語られることは、以下に挙げるように、大別して 「ソロ開発」 と、アジャイルでよく採用される 「アンサンブル開発」 の2つのスタイルの開発方法があるよ、ということです。なお、ソロ／アンサンブル の名称は僕がここでつけたもので一般的な呼称ではありません。

• ソロ開発 .... 1人1人にタスクを割り振って、そのタスクを最初から最後まで1人で開発してもらうスタイル。個人分担方式。
  • メリット
    • リソース効率が良い
    • 短期的にはスループットが高い
  • デメリット
    • リードタイムが長い
• アンサンブル開発 ... 1つのタスクを複数人で、恊働（コラボレーション）で片づけるスタイル。
  • メリット
    • リードタイムが短い
    • フロー効率が良い
  • デメリット
    • 短期のスループットが低い

「リソース効率」、「フロー効率」、「スループット」、「リードタイム」の4つの用語を今のところ定義なく使っていますが、スループットとリードタイムはこの後説明します。リソース効率とフロー効率の説明は後編に回します。すみません。
ただ、ここで知っておいていただきたいのは、2つのスタイルそれぞれの長所・短所はリソース効率とフロー効率に限らないということです。一般的に、前者のスタイルを「リソース効率重視」、後者のスタイルを「フロー効率重視」と言ったりするのですが、実際のところはリソース効率・フロー効率だけが主要な要素ではなく、他にもメリット、デメリットが複数あります。

比較ポイント

そして、ソロとアンサンブルでそれぞれ比較すべきポイントが複数あるのですが、それが短期目線と中長期目線では少し異なってきます。
以下はそれぞれの観点で長所を表形式にまとめたものです。

	ソロ開発	アンサンブル開発
短期	スループットの高さ	リードタイムの短さ
中長期	リソース効率	フロー効率

他にも色々あると思うのですが、この記事では特に、前編は短期的視点でスループットとリードタイムに、後編は中長期視点でリソース効率とフロー効率に着目しての比較をしていきます。

短期的な比較：スループット vs リードタイム

短期的な視点に立った場合のソロのメリットはスループットの高さ、つまり開発の総量の大きさです。一方、アンサンブル開発のメリットはリードタイムの短さです。つまり、タスクが作成されてから完了（リリース）されるまでを短縮できる、ということです。

2つの開発スタイルを比較してみる

では、ソロ開発とアンサンブル開発とがそれぞれどんなものか、どういう違いがあるかを、スループット・リードタイムの2つの観点から見ていきます。

まずはソロ開発。

ソロ開発

正方形のマスがそれぞれ作業を表し、色はタスクを表します。4つの色があるので、ここでは4つの異なるタスクがある想定です。どのタスクも原点で作成されたとします。
縦軸は4人の開発者A～D、縦軸が経過時間を表します。 から $t_4$ はそれぞれ1週間分と想定します。

ソロ開発では、開発者Ａ～Dがそれぞれ別個のタスクにアサインされ、1人1人が別個のタスクをこなしていきます。
この開発スタイルの長所は、スループットの高さ、つまりアウトプットの総量が高い事です。この例だと、$t_4$ までに16マス分、4タスクを完了させています。

一方、この方法の弱点は、1つのタスクに常に1人分しか開発リソースを割けないので、どうしてもリードタイム、すなわちタスクが作成されてから完了するまで時間がかかる、ということです。この例だと、どのタスクも$t_1$から$t_4$までの4週間分の時間がかかっています。

一方アンサンブル開発では、1つのタスクを複数人で分担するので、理想的には以下のような図の状態にできます。

理想的なアンサンブル開発

黄色のタスクはリードタイムを1週間まで縮めることができています。他のタスクもまとめて書くと、

• 黄色 .. 1週間
• ç·‘ ... 2週間
• 青 ... 3週間
• ピンク ... 4週間

と、ピンクのリードタイムはソロ開発と変わらず、それ以外の3タスクは全てリードタイムを短縮できています。

しかし、これは極めて理想的なケースで、現実的にはこう上手くはいきません。共同で1つのタスクを倒そうとすると、開発者間でコミュニケーションを取りながらになりますし、待ちも発生しがちです。
なので現実は、以下の図のようになったりします。

現実的なアンサンブル開発

コミュニケーションや待ちのオーバーヘッドによって、各開発者はそれぞれきっちりすき間なく作業はできていません。 $t_4$ までに3つのタスクが完了しており、その3つに均等に作業時間がかかったとすると、それぞれのリードタイムは

• 黄色 ... 4/3 ≒ 1.33 週間
• ç·‘ ... 8/3 ≒ 2.67 週間
• 青 ... 4 週間

かかったことになります。これでも、先に着手した3タスクについてはソロ開発よりはリードタイムを短縮できているのですが、後に回したピンクのタスクは $t_4$ までに着手できていません。つまり、$t_4$ までのアウトプットの総量は12マス・3タスク分となり、スループットはソロ開発に比べて 3/4 に減少しています。

このように、ソロ開発とアンサンブル開発は、短期的にはスループットの高さとリードタイムの短さ、という点でトレードオフの関係にあって、ソロ開発はスループットに優れる一方、アンサンブル開発はリードタイムを短くすることができる、という長所があります。

結局どっちがいいの？

スループットの高さとリードタイムの短さ、どっちを取るのがベターか、は状況依存で、必ずしもどっちかが常に良いとは限りません。

ただし、今までの議論はアウトプットがベースになっていることに注意が必要です。 一方で、プロダクト開発においてはアウトカム、つまりユーザーや顧客に何かしら与える価値、があるかを意識しないといけません。つまり、スループットを取るのかリードタイムを取るのか、に関してもアウトカムを基準に考えるべきです。

そして、アウトプットの量とアウトカムの量はほとんどの場合において相関がない、というのは今日において良く知られた事実です。何かしら機能を作ってリリースしても、ユーザーが喜んでくれる保証も、それに顧客がお金を出してくれる保証も何もありません。

※ にもかかわらず、アウトカムの量はアウトプット量に比例すると錯覚して、とにかくアウトプットを求めてしまう状態が俗に「ビルドトラップ」と呼ばれるものです。

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

その上でスループットの高さ、つまりアウトプットの量を選択すべきだとしたら、それは 開発予定のアイテムが必ず価値を生むことが保証されている場合 と言えるでしょう。雑に言い換えると、「作る予定のものの中に当たりくじが必ず入ってると確信できる」なら、あとは量で攻めても良いでしょう。
受託開発はそもそもアウトプットに対して対価が支払われるビジネスモデルなので、この範疇に入ります（そういう割り切り方が良いかはともかく）。 また自社サービスの開発においても、たとえばテーブルステークス、つまり、どこかの許認可を受けないと販売できないとか、何かしらの要因で「とにかくそれがないと市場から門前払いを食らう」ような機能を作る状況もこの範疇に入るでしょう。

ただ、プロダクト開発におけるほとんどの状況において、そんな保証はありません。天井のないガチャを引き続けるのと同じで、「ここまで作れば必ず売れる」という確証がないのが普通です。
で、そんな状況でアウトプットの量で勝負してしまった場合、大量に機能を作ったのに全部ハズレ、なんてことになってしまう可能性も十分あります。それは開発のコストを丸々ロスしてしまうだけでなく、大量のゴミを自分のプロダクトに追加してしまう ことを意味します。プロダクトは無駄に複雑になり、ユーザーにとっての価値も下がるし、開発者にとっての生産性も下がってしまいます。
つまり現代のソフトウェア開発において、良い機能を作ることと同等以上に余計な機能を作らないことはとても重要です。

【ここから余談】
一定以上育ったソフトウェアは「コードを1行追加したらプロダクトとしての価値は下がる」と思った方が良い、と自分は思っています。機能を追加したければ、その複雑性増加に伴う価値の低下を大きく上回る価値を付与しないとペイしません。

僕は割とエンジニア目線で話をしていますが、PdM目線で似たようなことを語るnoteが最近公開されていました。

note.com

【余談おわり】

一方、とにかく量で攻めるのではなく、

1. 1つずつリリースして、顧客・市場からフィードバックを得る
2. そこから自分たちが顧客について学び、その学びを活かして次の弾込めをする
3. 以上2つをひたすら何度も回す

とすることで、当たりくじを引く確率をなるべく増やし、かつ無駄打ちをしなくてよい（あるいは、ハズレを引いたときの悪影響をなるべく小さくできる）アプローチが俗にリーンスタートアップと呼ばれるビジネス戦略です。

で、リーンスタートアップを実践する上では、上記のサイクル（いわゆる仮説検証のサイクル）をどれだけ速く回せるか、が開発組織としての生産力につながります。そして、この前提においてリードタイムが短いことは大きなアドバンテージになるのです。

アンサンブル開発に関する補足

ここで注意が必要なのは、アンサンブル開発はある程度慣れないとできない、ということです。
ソロ開発は、それこそ学校の授業でプログラミングを習っても、あるいは趣味で開発したとしても、だいたいこの形式に自然と収まるのでいちいち習得の時間を取らなくてもいいです。一方アンサンブル開発は、それなりに経験やトレーニングを積んで、アンサンブル開発での考え方になじまないとうまくこなせない人が大半ではないかと思います。

加えて、上の説明だけだと「リードタイムを短くしたければ人を追加すればええんや！」と安直に思う人もいるかもしれませんが、これはまさに人月の神話で、「遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れる」というブルックスの法則が示すのと同様の状況に嵌ってしまう可能性があります。
上で書いたようなアンサンブル開発への慣れも含め、開発者の学習曲線を無視してはいけない、ということです。

ここで思考を止めないで

さて、ここまで読んで、ソロ開発とアンサンブル開発はどちらもアリ？ という気分になられたかもしれません。

実際、短期的目線だとどっちにもメリットはあるんですが、中長期的な目線だとまた違った議論になっていきます。中長期的視点ではリソース効率とフロー効率の観点が中心になり、その視点だと全然異なる状況が見えてきます。

……ですがここまで長くなりすぎたので、以降の議論は後編に譲ります。

bonotake.hatenablog.com