註：この記事は前後編の後編です。前編を先に読むこと推奨です。 bonotake.hatenablog.com
TL;DR（後編のみ）
- 中長期的には、ソロ開発はリソース効率（人員の稼働率の高さ）、アンサンブル開発はフロー効率（タスクが滞りなく処理される度合い）に長所がある
- アンサンブル開発はボトルネックが生じにくいため、中長期目線ではアンサンブルの方が安定的な開発ができ、スループットも高くなる逆転現象が起こりうる
目次
前編のおさらい的な何か
よく「リソース効率重視」とか「フロー効率重視」とか呼ばれるのは、特にアジャイルの文脈ではそれぞれ「ソロ開発」と「アンサンブル開発」とも呼べる2つの開発スタイルを指すのが一般的、という話を前編でしました。
- ソロ開発 ... 個人1人1人にタスクを割り当て、個人ベースで開発を進める。
- アンサンブル開発 ... 1つのタスクを複数人で、コミュニケーションを取りながら協働でやっつける。
そして、それぞれのメリットは、短期目線と中長期目線で分けて、以下のように分類できる、としました。
| ソロ開発 | アンサンブル | |
|---|---|---|
| 短期 | スループットの高さ | リードタイムの短さ |
| 中長期 | リソース効率 | フロー効率 |
短期の話は前編でしたので、この記事では中長期の話をします。
中長期的な比較：リソース効率 vs フロー効率
前編ではソロ開発について、短期的にはスループットが高い（アウトプットの総量が多い）という話をしました。一方アンサンブル開発は、コミュニケーションや待ちが発生して、すき間なく作業できない、と書きました。
しかし現実には、ソロ開発でも別の理由からすき間が生じます。インシデント対応やよくわからない雑務、予定外のミーティングなどが降ってきたりして、1人の開発者が自分の時間を100%開発に集中できることはほぼまれです。
前編の例で、もしこうした差し込みが発生したら？ ということを考えていきましょう。
これは前編のソロ開発の例で、 $t_3$ で差し込みタスクが発生した場合を考えています。開発者Cがその対応にあたり、まるまる1週間潰しています（図中の灰色のマス）。
ここで注目してほしいのは、差し込み対応をしていると、青タスクの作業が中断してしまう ということです。そのせいで、青タスクの完了は1週間延びています。
一方、アンサンブル開発をやっていて同じ差し込みタスクが発生したらどうなるか、見てみます。
同じく $t_3$ 付近で開発者Cが対応に当たったとします。 この影響がどの程度になるのか厳密に想定するのは難しいですが、もしかすると少しだけ青タスクのリードタイムが延びたかもしれません（そんな気持ちを雰囲気で図に表しています）。ただ重要なのはそこではなく、アンサンブル開発では、開発者1人が抜けても青タスクの開発作業は他の開発者によって続行される、ということです。完了までの時間は多少延びるかもしれないですが、それでも青タスクは程なく完了するでしょう。反面、ソロ開発の場合、開発者が抜けるとその間、開発は中断されたままの状態が続きます。誰かが引き継げればいいのですが、担当者が急な事情で途中で抜けた場合、他の開発者が引き継ぐのもなかなか大変です。
これが、フロー効率の効能です。フロー効率は以下の数式で表される指標で、要は「タスクがどれだけ滞りなく処理されたかの度合い」を示します。
$$フロー効率 = \frac{タスクに意味のある作業がなされた時間}{タスクのリードタイム}$$
先ほどの例でいうと、ソロ開発での青タスクのフロー効率は 4/5 = 80% となります。一方アンサンブル開発では、青タスクの開発の手は止まっていないので、フロー効率は100%です。
一方リソース効率とは以下の式で示される、人員ベースの稼働率です。
$$リソース効率 = \frac{実際に開発者が作業した時間}{開発者が作業できる総時間}$$ 双方の $t_4$ までのリソース効率を考えると、ソロ開発はどの開発者も（差し込みタスクも含めて）すき間なく作業できている、つまりフル稼働しているので、リソース効率は100%です。一方アンサンブル開発は、前編でも述べた通り、オーバーヘッドが発生してスループットが 3/4 に落ちており、よってリソース効率も 3/4 = 75% になっています。
このように、やはりフロー効率とリソース効率も、普通はトレードオフの関係になります。ソロ開発はリソース開発に優れる一方、アンサンブル開発はフロー効率に優れています。
ボトルネックの問題
先ほどの説明では、「フロー効率が劣後する例」と「フロー効率が優先される例」の比較を見ることになりました。そして、アジャイルにおいては「フロー効率重視」ということがよく言われます。
どうしてフロー効率を重視するのでしょうか。それは、フロー効率が低い、ということはそれだけボトルネックが発生していることを意味しているからです。
言い換えると、ソロ開発はボトルネックが発生しやすく、開発が意図せず中断する確率が高いのです。
更に言うと、この状態は開発が完了した後も続きます。たとえば、先ほどの青タスク開発終了から数か月後、ここで書かれたコードが起因でインシデントが発生したとします。
しかし、もし開発者Cが辞めていたり異動していたりして、既に開発から離れていた場合、どうなるでしょうか？ 恐らく、ここのコードを触ったことのない開発者がインシデントに対応することになるでしょう。多大な時間と労力をかけることになるはずです。
一方、アンサンブル開発で同様の事象が発生して、そしてやはり開発者Cがいなくなっていたとしても、残りの3人はまだ残っているので、その3人の誰かが対応に当たれば、恐らくソロ開発のケースよりは少ない時間と労力で対応できることでしょう。
ここで重要なのは、アンサンブル開発では、開発と同時にナレッジシェアが行われる ということです。この効果は文字通り計り知れなくて、様々な観点で組織を強靭にし、開発を長期にわたって安定させる効果をもたらします。
一方でソロ開発は、組織の中で特定の知識を担当者1人しか持っていない、という状態を簡単に作り出してしまいます。その担当者が簡単にボトルネックになってしまうという意味で、開発組織としてはとても脆弱です。
そして、その担当者から他の開発者に、開発後に知識を引き継ぐのはかなりコストが高いのです。僕はそうした形でナレッジシェア（いわゆる引継ぎ）がまともになされたのを見たことがありません。
そして、前編では「ソロ開発は短期的なスループットの高さが長所」という話をしたのですが、ここまでの話を踏まえると、中長期の観点では必ずしもスループットが高いとは言えなくなります。特に差し込み対応が多い開発組織では、ボトルネックが発生する頻度も跳ね上がってしまい、それだけ開発が遅延してしまいます。その分、安定して開発できるアンサンブル開発をしている方が、中長期で見ればスループットが高くなる、という逆転現象の可能性が出てくるのです。
まとめると、中長期の目線で考えれば、アンサンブル開発を採用した方が、安定してパフォーマンスを発揮できる開発組織にでき、メリットが大きいと言えます。
アジャイル本来の意味からフロー効率を考える
若干話がそれますが、よく、アジャイルのことを「スピードが速い」という意味と勘違いしている人を見かけます。しかしスピードとアジリティ（「アジャイル」の名詞形）は、実は似て非なる概念です。
スポーツの世界でのスポーツとアジリティの意味を書き出すと、こうなります。
- スピード … できるだけ短い時間で動作を行う能力。100m走の速さなど。
- アジリティ … 方向転換や動きの変更における素早さ。サッカーやバスケットボールで相手選手をかわす動き。
そしてこれは、プロダクト開発の世界でよく見るアジャイルとスピードの違いと本質的に同じです。こちらの世界でアジャイルとは「周囲の変化に俊敏に対応できる」ことを指します。
それを踏まえて、ソロ開発とアンサンブル開発、どちらがアジャイルと言えるでしょうか。ソロ開発は、開発者が安定して作業に集中できる環境ならその本来の特性を活かせますが、不確実性の高さや変化の多さにとても弱いです。アンサンブル開発の方が、差し込みが来ようが、開発方針が多少変わろうが柔軟に対応できる余地を残していて、よりアジャイルだと言えます。
アジャイルにおいてフロー効率重視のスタイルが推奨されるのは、そういう理由だからでしょう。
つまりは冗長性を確保するということ
以上などから僕は、少なくとも中長期視点では、アンサンブル開発がソロ開発より優れている、と考えます。
少し抽象的な議論になるのですが、アンサンブル開発というのは結局のところ「冗長性を持たせて信頼性やパフォーマンスを上げる」という、情報科学 / コンピュータサイエンスの世界では広く使われるテクニック、設計原理の応用だと言えます。
RAIDを想像してもらえばわかるのですが、ストレージを必要最低限のn倍だけ余分に使って、信頼性を上げたりアクセス速度を上げたりします。RAIDはデーターセンターやオンプレミスのサーバーで広く使われており、それを「リソースの無駄だ」と考えるエンジニアはほぼいないでしょう。
似たような話で、特に中長期的な視点に立てば、アンサンブル開発を採用して組織を冗長化しておくことは十分なメリットがあります。
そして中長期的に必要と思うことは、今から始めて、普段から実践しておくべきです。中長期の話をすると「今は目の前のことで余裕がないから」といって後回しに考える人も多いですが、「RAID入れとくべきだと思うけど、今はそんな余裕ないしな」という人はたいてい、将来においてもRAIDを導入しません。この話もそういった類のものかもしれません。
前編で触れたように、アンサンブル開発には学習コストも必要、ということもあります。いざというときにすぐできるものではないので、普段から少しずつ実践して取り入れていくべきでしょう。
また、RAIDはレベル（アルゴリズム）の選択によって信頼性を上げる方に寄せたり、性能を上げる方に倒したり、どちらもバランスよくいいとこどりしたり、といったことができます。 アンサンブル開発でも似たようなところがあり、スクラムのスウォーミングは比較的パフォーマンス、つまりリードタイム重視な面があり、XP由来のペアプログラミングやモブプログラミングは信頼性、つまりフロー効率重視なところがあります*1。そういった特性をうまく見極めながら工夫をすると、同じアンサンブル開発でも様々な形で効果を発揮することができます。
ソロとアンサンブルでバランスを取る
さて、今まではソロかアンサンブルか、リソース効率かフロー効率か、の2択で話してきましたが、実際のところは、どちらかに極端に寄せるのは得策ではありません。アンサンブル開発がいいと言っても、たとえば1タスクを30人でやっつける、というのは流石に非効率に過ぎる、と思うでしょう。
そうした、リソース効率もフロー効率もいい塩梅で収めるために使われるプラクティスが、カンバンのWIP制限です。
カンバンではWIP（Work In Progress、仕掛り中のタスク）の最大数を決め、それによって、開発するタスクの並列数をコントロールします。WIP制限を3に設定すれば同時に3つまでしかタスクは開発できないし、10に設定すれば10タスクまで並列にできます。
これを12人チームでやった場合、12人で3タスクだけやるのと、10タスクをやるのとではフロー効率・リソース効率に大きな違いが出るし、引いてはスループットやリードタイムにも変化があるでしょう。
僕は株式会社ログラスにおいてFASTというアジャイルフレームワークを導入していますが、FASTではWIP制限をカンバンから輸入していて、チームのメンバー数の調整に使います。12人のコレクティブ（開発メンバー全員の集団）でFASTをやったとすると、WIP = 3 では1タスクあたり平均4人のチームができ上がるし、WIP = 10 では平均1.5人と、ほぼソロ開発が主体になりそうな環境になります。この数値を、その組織が今置かれている状況にマッチするよう調整することで、適度にアンサンブルっぽく適度にソロっぽい開発体制を作れるし、その塩梅を動的に調整することもできます。
おわりに
長々と書いてきましたが、実際のところ最適な塩梅というのは個々の状況に依存するので、基本的な概念とベースとなる考え方を押さえた上で、そのときそのときの状況に適応する形で調整できるようになると良いのではないかなぁ、と思います。
業務だと普通はチーム/組織で開発すると思いますし、せっかくチームで開発しているのなら、個人に頼りきった開発しかしないよりはチームワークを覚えた方が良いし、そこにはフォーメーションが存在して、フォーメーション次第で様々な効果を発揮できます。そうしたフォーメーションまで考えて柔軟に戦略・戦術を組めると開発組織としては相当強くなるはずです。
そしてまた繰り返すのですが、アンサンブル開発はやれと言われてすぐできるものではなく、学習コストがあるし、ソロ開発に比べれば結構スキルが要求されるものです。なので、やってみたいと思うチームは、ここに書いたようなパフォーマンスを最初から出そうと思わず、しばらくは練習とだと思って色々試すところから始めてみてください。それなりにこなせるようになったら色々調整していって、より最適な塩梅を自分たちで模索していくとよいのではないでしょうか。
