「テスト駆動開発」と「ペアプログラミング」は、アジャイルプラクティスで最も広く知られているものの2つであるが、まだそれほど多くのアジャイルチームによって実践されてはいない。たいていその理由として、TDDやペアプログラミングなどのプラクティスを取り入れるには「忙しすぎる」点が挙げられるだろう。要するに、これは高いコード品質を得ようと努力することが生産性を低下させることを示唆している。Mike Hill氏は、この論理がなぜ重大な誤りであるか説明している。
Mike氏が語る基本は、「生産速度」を求めるなら、「品質の向上」が必要になるという点である。
内部品質と引き換えに機能を追加できるということは事実でないどころか、実際には正反対です。つまり、生産性を追求するほど、内部品質基準の向上化が必要になります。
...
より多くの生産量を求めるのであれば、まずは内部品質を上げることに目を向けます。
さらに、その理由を次のように語った。
では、なぜそのようなことをするのでしょう？
- 内部品質と外部品質は別物であるため。
- 今日の生産を決める唯一最大の要因は、昨日の成果物の品質であるため。
- タイピングは、現在もこれまでもコードを書く上で決してボトルネックではないため。
Mike氏は、続けてこの3つの理由について説明している。まず、氏は、「品質」という言葉を明確にし、外部品質 (製品機能の量とみなすことができる) と内部品質 (これら機能の背後にあるコードを意味する) を区別している。氏は、この区別をすることで、外部品質は製品化までの時間が短縮されることで低下するおそれがあるが、内部品質はそうではない点を指摘している。
次に、Mike氏は、どのように「昨日が今日を決定する」のか、つまり、既存コードの内部品質が現在の生産性にどのような影響を及ぼすかについて、次のように述べている。
一日中、何か行動を起こすたびに、そこにある既存コードに左右されることになります。コードの行の解析、他の依存関係のオープン、不適切な変数名、 (大なり小なり) 欠陥のある設計決定、などによりペースが落ちることになるでしょう。
できるだけ作業ペースを上げたいのであれば、簡潔なコードで作業すべきです。以上。
最後に、Mike氏は、ペアプログラミングとTDDは、「タイピングの人数が半分でコード生産量も半分」(本稿著者の言葉) になるため、スループット (生産性) が低下する、というよくある誤解を取りあげている。氏は、「コーディング」時に起こる11の一般的な行動リストを示し、次のように述べている。
マシンにコードをタイプするということがこのリストのごくわずかな部分しか占めていないという点に注目してください。それは、プログラミングで問題となる要素は考えることであり、タイピングではないからです。このリストでそれ以外 (おそらく物を投げることを除いて) は考えることに関しており、タイプピングではありません。
TDDは思考を支援するものとして機能するため、生産量が増加します。これにより、バックトラッキングと不要な機能を抑制し、コード解析とデバッグを減らします。ペアプログラミングは、まさにそのような理由で生産量を増加させるのです。2人の開発者が一緒にタイプする場合、別々に行う時ほど速くはありませんが、気にすることはありません。それは、ボトルネックは考えることであり (タイピングではない) 、ペアプログラミングとTDDはともにその点を改善するからです。
Mike氏は、チームの生産性向上に対し、要約した3つの提案で締めくくっている。
チームの生産性を向上させたいのであれば、次の3つのことを行います。
- いかなるコードも、失敗するマイクロテストを書いてから変更する。
- 「ペアなくして品質の維持なし」という点に合意しこれを受け入れる。
- 内部品質に対する共通の認識を確立する。
「ペアプログラミングやTDDをする時間がない」と確信している人をご存知かもしれない (ひょっとするとあなた自身かもしれない) が、Mike氏の記事が役立つだろう。