優れたプログラマの生産性はそうでない奴の10倍とか100倍とかいう都市伝説

id:mizchi さんがとてもいい記事を書いていて、
最近僕も似たようなことを考えていたので、これを機にちょっと文字にしてみます。

技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog

話としては、
「デキるプログラマの生産性は、クズなプログラマの100倍」
とかいうプログラミング界の都市伝説について、
プラスの生産性だけじゃなく、
汚いコードを書いてしまうことによる将来的なマイナスの生産性まで考慮することによって、
実際のところ10倍とか100倍とかっていう開きもあり得るんじゃないの？
という話です。
ちなみにmizchiさんはこのマイナスの生産性を「技術的負債」と表現しています。

今回はこれを受けて、実際に適当な仮説で式を立て、
「週にrの成果を出し、dだけソースを汚くする」ようなエンジニアの生産性を求めてみます。

計算式

以下のように定めます。

p:生産性
r:ソースが理想的に綺麗な状態において、1週間に出せる成果の量
d:1週間に出してしまう技術的負債の量
c:技術的負債が生産性に与える影響を表す係数
x:経過日数（単位：週）

すると、単位週あたりの生産性は以下のような式で表せます。

p = rc

また、cは（これまでに発生した技術的負債の総量）によって決まる、0≦c≦1の値なので、仮に

c = 1 - dx/100

と表せるとします。
つまり、負債総量が100になっているソースは、
「もはや誰にもメンテ不可能なゲロ以下のコード」ということです。
これらを合わせると、生産性は、

p = r(1 - dx/100)

ということになり、1週間に出せるMAX成果量と出してしまう負債量を与えれば、
そのエンジニアの生産性が、経過日数によってどのように変化するかがわかるようになります。

計算

何人かのパターンのエンジニアを上記の式に当てはめて試してみます。

1.週に10の成果を出して3の負債を生む人

上記のような感じ。プロジェクト開始時は10だった生産性が、2ヶ月半ほどで7に下がります。

2.週に15の成果を出して10の負債を生む人

こんな感じ。なんと2ヵ月半後には生産性が0です。

3.週に9の成果を出して0の負債を生む人

当たり前ですが平らです。プロジェクトの開始から最後まで一定の成果を出し続けます。

なお、これを積分すればプロジェクトを通しての生産量も求められますが、
ここではそういうことをしたいわけではないのと、
そもそもcを表す式やr,dの値の妥当性がかなり怪しいので、そういうのはしません。

技術的負債を生まないエンジニアにならなきゃいけない

で、何が言いたいかというと、
汚いソースを書いてしまうことによって将来の生産性が下がるため、
プロジェクト終盤での生産性や、プロジェクトを通しての生産性という目で見れば、
「綺麗なソースを書けるエンジニアの生産性は、
汚いソースを書くエンジニアの10倍100倍になることもあり得る」
ということです。

上記の、10週目には生産性が0になるという例は極端ですが、
そうじゃなくても、技術的負債というものがある以上、
rやcをもっと妥当な値に変えてみても、やはり長期的な生産性にはかなりの開きがありそう。

それに上記の例は、あくまでも「自分が書いたソースを自分で読む」場合の話です。
実際には自分が書いたソースを他人が読むケースなんてざらにあり、
その場合は負債により減少する生産性はさらに大きくなります（要するにcが小さくなります）。
つまり、技術的負債を生まないようにすることの重要性はさらに高まるということ。

まっさらな状態から「よーいどん」でコーディングを始めれば、
おそらく生産性に100倍の開きは出ません。

が、
・1年間プロジェクトを続けたらどうなるか？
・新しい人がプロジェクトにアサインされてきた時のキャッチアップ工数はどうなるか？
・プロジェクトが一旦終了し、その1年後に追加案件のプロジェクトが始まったらどうなるか？
などを考えると、
優れた（＝綺麗なコードを書ける）エンジニアの生産性は、
そうでないエンジニアの生産性を圧倒します。

さぁみなさん、綺麗なコードを書きましょう！（結局これが言いたかっただけ）

おわり。