本当に犠牲にしているのは、品質ではなくシステムの保守性
最初に、和田氏は書籍『アジャイルサムライ』に載っていた「荒ぶる四天王」を紹介した。これは、開発に与えられた「時間」に対して「予算」「品質」「スコープ」が限られている場合、どれを犠牲にすべきかという問題だ。多くの現場では、品質を犠牲にして、スピードを得ようとするだろう。
しかし、和田氏は、品質を犠牲にすれば短期的にはスピードが得られるが、中期的には逆効果になり、長期的には致命傷になると述べた。これには、多くの人が同意するだろう。しかし、本当は何を犠牲にしているのだろう。そして、この短期・中期・長期とは、どのくらいの期間を指すのだろうか？
そこで、和田氏は、品質という言葉に注目した。品質は、操作性や信頼性など「○○性」がつく言葉であらわされる。英語では「Usability」や「Reliability」など、末尾に「ility」がつく多くの言葉が該当するという。
ソフトウェアの品質には、お客様から見える外部品質と見えない内部品質があり、「内部品質を作り込んだ結果として、外部品質として定義される特性の実現に近づくことができる。内部品質は結果ではなく原因であり、良いソフトウェアが備えているべきものだ」と、『レガシーコードからの脱却』という本を引用して説明した。さらに、品質を犠牲にしてスピードを得ようというとき、この内部品質の保守性（Maintainability）や柔軟性（Flexibility）を犠牲にしていると述べた。
保守性を犠牲にしても、中長期的にスピードは上がらない
では、保守性の低さという技術的負債は、何をもたらすのだろうか？
和田氏が描写したのは、第1次世界大戦の野戦病院のように疲弊しきった現場、どこに影響があるか分からないスラム街の長屋のように荒みきったコード、爆弾処理のようなリリースという、短期的に無理し続けたプロジェクトの姿だった。
このような現場では、技術的な負債が蓄積された結果、いろんなところが裏で手をつないで、足を引っ張りあっており、ひとつひとつの変更に余計な時間がかかるようになっている。その結果、単位時間あたりの生産量は下がっていく。
つまり、保守性を落とした結果、スピードも落ちてしまうのだ。
それでは、スピードを落として時間をかけたら、保守性は向上するだろうか？
これについては、「技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。逆に、技術力が高くない人が時間をかけて作ったとしても、その人の技術力以上の品質のコードは書けないだろう」と述べた。
保守性とスピードは、トレードオフの関係ではないのだ。
