コードの品質を高く保っていたからこそスピードは速くなる

　では、品質とスピードの本当の関係は、どうなっているのだろうか？

　和田氏は、書籍『エクストリームプログラミング』を引用して、「むしろ品質を高めることで、デリバリーが高速になることが多い。低品質を受け入れることで、プロジェクトが速くなることはない。高品質を要求することで、プロジェクトが遅くなることもない。 むしろ品質を高めることで、デリバリーが高速になることが多い。品質基準を下げてしまうとデリバリーが遅くなり、予測できなくなってしまう」と述べた。

　つまり、コードの品質を高く保っていた「からこそ」速くなると言えるのだ。

　そして、品質が劣化すれば、リードタイムが増加する。品質は悪いと基本的に手戻りを生むからだ。手戻っている時間は学びを生まない時間となる。だから、品質を下げるという判断が、学びの速度低下を許すことになる。

　従来、鉄板だと誤解されていた「品質を捨てて速度を上げよう」は、品質が劣化して手戻りが発生するだけで、結局はリードタイムの増加に跳ね返る。そして、リードタイムが増加すると仮説検証プロセスも回らなくなる。

　ここまで見てきたものを整理すると次のようになる。そして、「『質vs.スピード』という二律背反の関係は、局所的なものでしかない。大域的には、片方を犠牲にした場合、知らぬうちにもう一つも犠牲にしている」という、Facebookの元エンジニアであるEvan Priestley氏の言葉を紹介した。

　品質とスピードを上げる方法が、個人のレベルに依存しているとしたら、どうやって個々人の品質とスピードを上げていくのだろう。これには正解はないが、「ソフトウェアの開発に最初から最後まで関わるという経験がとても重要だ」と、再度Evan Priestley氏のコメントを取り上げた。そして、いろいろなフィードバックを自分で受け止めて、設計者として能力を上げることが決定的に重要だと思うと述べた。

品質の効果は、1か月以内にあらわれる

　保守性を犠牲にすれば、短期的にはスピードが得られるが、中長期的にはダメージにつながる。内部品質に投資すれば中長期的にスピードが上がり、その結果として競争力と売り上げの向上につながる。だとすると、短期と中期の境目は、どこにあるのだろうか。

　この疑問について和田氏は、テストの自動化を例に説明した。

　諸説あるが、書籍『Experiences of Test Automation』によると、およそ4回で手動テストと自動テストのコストが逆転するという。また、マーティン・ファウラーは「内部品質への投資の損益分岐点は1か月以内に現れる」と紹介した。

　1か月以内であれば、内部品質への投資の受益者は自分たち自身である。つまりエンジニアとしてのプライドやモラルのために品質に投資するのではなく、自分たちの損得の話になるのだ。

　結局、品質と速度についてトレードオフを意識するとき、実際には何と何を天秤にかけているのだろうか。和田氏は、このセッションを何回か行ってきて、寄せられたフィードバックとして「若者が育つ機会」「新技術の調査」「多様性の確保」が犠牲になっているのではないかと紹介して、セッションをしめくくった。