開発のスループットを犠牲にしてレイテンシを向上させる

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

ソフトウェア製品の一部をまず完成させる。次に、別の一部を完成させる。もう一つ、別の一部を完成させる。こういうやり方を続けていくと、最初のほうに作った部分と最近になって作った部分のコードは、かなり違ったものになってしまう。最近になって必要になったモデルの機能は、最初のほうに書いたコードのデザインとうまく一体化していない。そこで、全体を直す作業が必要になる。これをリファクタリングと言う。一つ機能を追加するたびにリファクタリングする必要があるので、当然、開発のスループットは落ちる。それでも、一部ずつソフトウェアができあがっていくので、進捗を開発者以外とも共有しやすいし、できてから初めて気づいた問題にも素早く対処できる。実は必要がなかった機能を実装してしまう可能性は、少なくなる。スループットが落ちる代わりに、ソフトウェアの価値が発生し始めるまでのレイテンシは短い。

最初に全部を見渡して完璧な設計を導出できるなら、リファクタリングは必要がない。リファクタリングに必要な時間がいらなくなるので、スループットは向上する。一方で、完璧な設計にたどり着くまで、ソフトウェアの設計はなかなか進まない。レイテンシは悪化する。

もちろんビジネスの種類にはよるんだけど、ものすごいざっくりと言えば、原則としてスループットを捨ててレイテンシを取るほうが賢い戦略だと思う。少なくとも僕が生きている自分で適当なWebサービスを開発するような世界では、レイテンシ向上をデフォルトの戦略にするのが良いと思う。

ただし、当然だけど例外があって、レイテンシの向上でもたらせる利益によって帳消しにできないくらいにスループットの低下が激しい場合には、後者の戦略のほうが正しい。

レイテンシの向上が利益をもたらさないのはどういう場合かというと、スコープと期間があらかじめ厳密に定められていて、変更ができない場合である。スループットの低下が無視できないくらい大きいのはどういう場合かというと、リファクタリング（に相当する作業）のコストが大きい場合である。例えば、よく知らないけどハードウェアの開発とかそれに関するものとかだときっと大変でしょうね。

僕の感想だけど、どっちの条件についても緩和される方向に、人類が進化するのが正しいと思う。