わたしは向き合えないというポエムです。ぽえむだぞ。
プログラマーの生産性は、優秀な人の場合、常人の数十倍にもなるという神話があります（せいぜい数倍であると否定されつつあると小耳にはさみましたが）。ですが生産性は0や負の値を取ることもある、というのが最近思うところです。生産性0というのはわかりやすく、開発者にとってタスクの難易度が高すぎて全く書けないという状況です。では負の生産性とはなんでしょうか。
負の生産性とは
ソースコードの技術的負債の一つに、ソースコード自体の肥大化・複雑化などにより保守性・可読性が低下することが挙げられます。技術的負債はソースコードを生産すれば生まれてしまうものであり、開発とは正と負の成果を同時に作る行為です。
負の生産性とは、この負の成果が大量に生まれてしまう状況であり、開発をやればやるほど技術的負債が積み上がっていく状況を指します。結果として、 生産されたソースコードの価値や工数に対して、技術的負債の返済コストの方が大きくなってしまうわけです。
技術的負債自体は開発で避けることは不可能なもので、極論を言えばソースコード行数が増えれば負債も増加するものです。とはいえ「負の生産性」と呼びたくなるほどひどい状況がいつもあるわけではありません。何故こうなってしまうのか、これが本題です。
負の生産性が生まれる原因
原因はわたしの中でだいたい見えてきつつあります。
負の生産性を生む人間が負の生産性を生んでいるのです。
これではトートロジーなのでもっと真面目に言うと、負の生産性を生む習慣が身についた人がそれを生み出しているのです。こういう習慣は色々あるんでしょうが、わたしの思う限りは特に以下の二つが特に大きな問題です。
1. 関数抽出しない習慣
継ぎ足し継ぎ足しで最長不倒関数が生まれるこの習慣こそ最大の問題です。人類は数百行、数千行にも達する関数を読んで保守することはできんのです。特にPHPのようなファンクショナルスコープな言語では変数のデータフローが本当に読めないので関数を短くするのはとても重要です。長くなるとデータフローがしっちゃかめっちゃかになって何やってるのか本当にわからなくなるのです。
関数抽出は人手でやるのは意外と難しくて神経を使う技術なのですが、今のIDEには関数抽出リファクタリングが標準装備されており非常に簡単に行うことができます。今時関数抽出しない人は罪人のそしりを免れないでしょう。ほんとうに、ほんとうに大切なことなのです。
2. 抽象化しない習慣
抽象化をさぼる習慣もじわじわと負債を増やします。ただし抽象化といってデザインパターンとかそういうレベルの話ではなく、「マジックナンバーを出現させずに定数を使う」とか「処理をできるだけ関数化して明白な名前を与えてやる」とかそういう低い意味での抽象化です。「type == 4」というコードが出現すると真顔になるんですよ。4ってなんやねん、4って。定数化はとても簡単にできる抽象化であり、基本中の基本なんですがそれすらサボられるととてもツライです。
負の生産性と向き合えますか？
教育により負の生産性を生む習慣をやめさせるのは前向きな発想ではありますが、実効性には疑問があります。というのもこれらは今の時代では技術というより「習慣」だからです。習慣だからこそやめさせるにはかなりの根気が必要でしょう。やめてもらうまで何度も何度もレビューで指摘する必要がありますし、「リリースまで時間ないんで、今回は見送って次回直すということでお願いしま〜す♪」のような言葉を全て拒否する精神力が必要になります。リリースさせたら最後あなたの負けです。リリースされたコードを直すなんてことはそう簡単にできることじゃないのです。
おそらくは一番簡単な解決策はその方に開発からご退場頂くことでしょう。もちろん後ろ向きな解決なのは間違いないですし、有期雇用や派遣の方が相手ですと雇い止めという比較的穏当な手段を取ることができるかもしれませんが、正社員の方が相手ですとそういうことはできるのでしょうか… 当人の希望と会社と思惑が重なって消えてくれることを祈るしかないのかな…
