カップラーメンに例える炎上案件

案件が炎上したら人を増やしてリカバリする、というのがバッドプラクティスであることは散々言い尽くされています。またこれをカップラーメンに例えるのもやり尽くされていることではありますが、従来の例えよりもう少し詳細に問題を語ってみたいと思います。

前提

* 私はWeb屋なので、そういう系の業種の炎上案件と思ってください
* お湯を沸かすのに3分、お湯を注いで出来上がるまでに3分かかるとします

1. 作業分担に伴いマネジメントコストが発生する

1人（1つのコンロ）で180mlのお湯を沸かすのに3分かかるのであれば、3人（3つのコンロ）で60mlずつ分担して沸かせばざっくり単純計算で3倍速になり1分で済みます。と、考える人が多いのがこの問題の発端です（厳密に考えると水の温度上昇はそう単純ではないような気がしますが、ここでは考えません）。この単純計算がよろしくないのは、作業分担に伴い発生するマネジメント作業が視野に入っていないためです。よくある話です。

追加で投入される人含め、全員が全く同じスキルレベルであれば問題ありません。しかし現実の案件でそんなことは基本なく、少なからずスキルにバラつきがあります。ここでは「それぞれのコンロの火力が違う」とでも思ってください。3人がそれぞれ強火・中火・弱火を出せるとなると、均等に60mlずつ分担するのはナンセンスです。強火の人の水の量は多めに、弱火の人には少なめにするのが合理的です。

現実の案件ではこういった「誰がどんなことを、どんなスピードと品質で処理できるのか」というメンバーの把握、及び作業の整理と分解、アサインにまず時間がかかります。これは1人でお湯を沸かす場合は全く考える必要がなかったものです。

2. 品質にバラつきが出る

前述の通り、メンバー全員が近しいスキルレベルであることは稀です。だいたいバラつきがあります。スキルにバラつきがあると、次にズバリ品質にバラつきが出始めます。

カップラーメンプロジェクトでは「お湯を沸かすのに使うやかんの綺麗さがそれぞれ違う」と例えてみます。綺麗なやかんを使っている人もいれば、お湯にサビが出ちゃうような汚いやかんを使っている人もいます（鉄分が豊富に取れそうですね）。

仮に1人だけで進めるのに、その人のやかんがサビだらけなのは、ある意味問題ありません。「品質が一定であれば、その品質が標準となる」からです。もちろんサビなど入っていないのが望ましいのは当然ですが、プログラミングの世界は奥が深いので「もっと良い品質を」と求め続けてもキリがありません。「品質の良さ」も時代とともに変わります。そこで大事になってくるのが「品質が一定であること」です。品質が一定であれば、将来的に別のフレームワークやミドルウェアに載せ替える際も、コードのクセに慣れてしまえばさほど苦労しません（当然限度はありますが……）。

繰り返しになりますが、問題なのは品質にバラつきがある状態です。その状態だと「こっちのコードはこういう規則性なのに、あっちのコードは全然違う規則性になっている」みたいなことが起こり始めます。そうなると開発中はもちろん、将来アップデートする際も常に細心の注意を払わなければなりません。現実にはあり得ませんが、あえてカップラーメンに例えるなら真ん中1/3のお湯の部分だけサビ臭くて食べれたもんじゃないので、頑張って上か下の部分だけ食べようとする感じでしょうか。細心の注意を払いそうです。

もちろん現実のカップラーメンはお湯が綺麗に分離することはなく混ざり合いますが、結果「全体的にそこはかとなくサビ臭い」みたいなカップラーメンになると思います。開発も同じで、ある部分が一定以上の割合を占めて品質が悪いと、そのうち他の良い部分の足も引っ張り始めます。

仮にそれを防ごうとすると、サビの混じったお湯が上がって来た段階で一度ろ過なり蒸留なりする必要があります。開発で言えばいわゆるコードレビュー（・リファクタリング）ですね。これも、1人開発のときはなかった作業です（外部にレビューを依頼するとかは別として）。量が多くなければそこまで時間はかかりませんが、量が多いとレビューにばかり時間が取られるようになってしまい、結果ある特定の人の作業量が激増します。最悪の場合は残念ながら「この人に任せない方がむしろ早い」みたいな感じになっちゃったりします。

3. ボトルネックは必ずと言っていいほど存在する

作業を分担することで生じる問題を今まで解説してきましたが、仮にめちゃくちゃ分担が上手くいき、お湯を沸かすのを3人で分担したら3分から1分になったとしましょう。じゃあ「お湯を注いでからの待ち時間も1分に短縮できるか」と言われると、そんなことはありません。ここだけはどうしようもありません。せいぜい、1人がお湯を注ぐところを3人で分担して一緒にお湯を注ぐくらいのことは出来るかもしれません。想像してみるとなんか仲良さそうで可愛いですね。

こういう「どうしても時間がかかってしまう」みたいな箇所のことをボトルネックといいます。直訳すると「ボトルの首」で要は2Lペットボトルでも500mlペットボトルでも水が出る速度は同じ、みたいなやつですね。そこを通過するには、どうしてもそこの部分の処理性能に依存してしまいます。

開発で例えると1番分かりやすいのは、ビルドにかかる時間だったり、CI/CDを動かしている時間でだったりでしょうか。ここの速度はいくら人を増やしてもどうにもなりません。またある特定の人がコードレビューを行っている場合は、コードレビューがボトルネックになる場合もあります（その人のレビューを待たないと先に進めない」というような状況が発生するため）。

結局人を増やしたからといってどうにもならない領域は確実に存在し、そこも軽視されがちなのが「人を増やせば作業速度は向上する」という考えが陥りがちな罠です。

結論：じゃあどうするべきなのか？

できればスケジュールを延ばしましょう。それが1番健全です。
それが難しければ1人で不夜城に突入するか、仕方なく人を増やすかですが、どちらにせよ品質が落ちることは覚悟しなければなりません。「スケジュールが延ばせないのであれば、品質は少なからず落ちる」と考えてよいでしょう。

それで聞き入れて貰える現場なら、幸せなんですけどね……。（昔の話）
あと私は、なんやかんやカップヌードルが1番好きです。王道というか安定感というか。