欠陥が多いということは、予定外の作業がそれだけ増えるということだ。Jiraで「バグ」に分類された課題の平均数が、"Healthy" と判定されたファイルと "Alert" と判定されたファイルで15倍も違うなら、コード品質の良し悪しは見積り精度に影響を与える。
バグ対応に要する時間は、開発計画にどれだけ組み込まれているだろうか。おそらく「バッファ」という形で吸収できるよう、計画に組み込まれているプロジェクトも多いと思うが、あまりにバグが多すぎてバッファを消費しきってしまうことだってあり得る。そのようなプロジェクトは、市場投入を計画通りに進められず、遅延を起こす。それが、ビジネスに悪影響を及ぼす。
さらに、顕在化されたバグがそれだけ多いということは、潜在的なバグが多いであろうことも予想できる。そういったバグが市場投入後に障害を起こす。そうして、開発者は障害対応に追われ、開発時間を失っていく。それが進行中のプロジェクトの計画にも悪影響を及ぼし、遅延に遅延を重ねる結果となる。
品質が悪ければ、開発時間がより長くなるという傾向が、計測結果によって明らかにされた。"Healthy" とされたファイルと "Alert" とされたファイルを比較した場合に、平均開発時間では後者は前者の2倍以上、最大開発時間では9倍近くとなった。
この結果は、単に開発時間が長くなるといういうだけの問題ではない。「見積り」という観点で、予測可能性が著しく下がることも意味する。算出した見積りに対し、結果として、2倍から9倍もの時間がかかってしまうかもしれないということだ。カテゴリごとに見てみると、"Healthy" では平均開発時間に対して最大開発時間が2倍弱、"Alert" だと7倍以上に達する。コード品質が悪いと、開発時間が長くなるだけでなく、ファイルごとの開発時間のばらつきも大きくなるということだろう。
先述した3つの計測結果はまさに、「市場投入までの時間」という関心事に対し、コード品質が影響することを示した。コード品質が低ければ、開発時間をより必要とし、さらに予測可能性の低下がプロジェクトの計画を瓦解させる。そしてこれらは結果として、ビジネスの機会費用や機会損失につながる。
このような状況に陥った開発チームは、見積もり時にバッファを可能な限り大きく積むことで、なるべく確実性の高い市場投入日を計画するようになる。しかし、これでは市場投入までの時間がむやみに引きのばされただけだ。こんなやり方は、プロジェクト関係者の不信感を生む。
これらの結果からも分かるように、やはり、コード品質の問題が組織の中で可視化されず、エンジニアしか認識できない状態に置かれているのだ。これでは組織としてコード品質の問題に取り組むことなどできるはずもない。だから、コード品質との闘いは、エンジニアだけの活動になるのだ。しかし、ツールを活用してコード品質を積極的に可視化し、追跡可能にできれば、組織内で問題・課題を共有できる。数多くある静的コード解析ツールの中には、コードの問題を特定したり、メトリクス化するだけでなく、その問題を解消するために要するであろう工数の参考値を出してくれるようなものもある（経験的に言って、それらの精度に期待しすぎることはできないのだが）。
考えてみれば、プロジェクトやプロダクトの定期報告には、売上やコストといったビジネスメトリクスや、アクティブユーザー数やダウンロード数といったユーザー行動に関するメトリクスは含まれても、コード品質に関する情報は含まれない。報告に含まれるのは、せいぜい、障害発生数や欠陥数ぐらいだろう。コード品質にの問題が積もり積もって大きくなり過ぎた時にはじめて、その解消に時間が欲しいとエンジニアが相談を切り出す。これではコミュニケーションが上手くいくはずもない。私たちエンジニアは、こういったコミュニケーションにも、もう少し目を向けるべきではないだろうか。