結論（個人的な考え）

• リファクタリングは、重要度は高いが、緊急度が低いという扱いを受けがちなため、通常後回しにされがちでコードは悪化の一途をたどる（継ぎ足しの暫定対応コードにより悪化）
• 軽微なクソコードが重大なクソコードを生む（割れ窓理論の考えの基礎）
• リファクタリングに取り組む時間を強制的に確保して、ボーイスカウト原則を文化として根付かせたり、（ひどすぎる場合には）リファクタリングに取り組む日のようなものを設けたりプロジェクト化するなどして、リファクタリングを当たり前のものにして、クソコードを消していけば徐々に生産性は上がっていく。

＊ クソコードを消していけば生産性が上がるというのは、「質とスピード / Quality and Speed」で言われているように質がスピードを上げるという考えが正しいという前提に立って考えています。

根拠

自分が今まで働いてきた環境で観察した結果から考えています。

リファクタリングが軽視されがち

顕著に新機能実装が優先されがちで内部品質を向上させるためのリファクタリングが軽視されがちだと感じたことが何度かあります。

現場を観察していると、リファクタリングが重要だと認識されており、クソコードが生産性をさげるということも認識されているが、実際に積極的に取り組まれていないように見えました。これは、リファクタリングが重要度は高いが緊急度が低いという位置づけにあり、常に後回しにされているからだと思ってます。

割れ窓理論はソフトウェア開発でも適用される

割れ窓理論とは、軽微な犯罪を取り締まると重犯罪を減らせるという理論です。

これは開発でも言えることだと思っていて（達人プログラマという本にも書いてある）、軽微なクソコードが重大なクソコードを生むと考えています。

現場を観察していると、すでにある汚い表現を真似して書いたようなコードを見かけることがあり、結果として、重大なクソコードになっていたので、軽微なクソコードが重大なクソコードを生むという考えは間違ってないと考えています。

頑張ってもどうにもならないという感情に支配されて、モチベーションが下がり、結果的にクソコードでプルリク出しがちっていうのもありそうです。

習慣は簡単に変わらないし、チームとして取り組まないと意味がない

リファクタリングが軽視されている問題は、単純に「リファクタリングして」と言って解消される問題ではないと思っています。これは一種の文化であり、やらないところは本当に誰もやらないし、やるところは何も言われなくても勝手にやると（経験則的に）思っています。

また、割れ窓理論云々に関してはチーム全体で取り組まないと意味がないです。誰かがリファクタリングしている隣で別の誰かがクソコードを生み出しているようだと意味がありません。

これを改善するためには、リファクタリングに取り組む時間を強制的に確保するのが良いと考えています。（会社によってはできないかもしれないですが）カレンダーに予定を入れて時間をちゃんと確保して取り組んでいき、ボーイスカウト原則のような考え方も伝えていくなどすれば徐々にリファクタリングすることが当たり前になっていくと考えています。

「山本五十六の「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ」という名言に従うことを繰り返し、繰り返し行えばいずれ根付いてくれるのでは。」と思っています。

終わりに

ただ楽しく皆で開発して、ユーザーに価値あるサービスを届けることがなぜこんなにも難しいのかとよく思います（僕は頑張るという考えがあまり好きではないので）。

誰かが作り出した負債を別の誰かが返済するという構図が成立するものでは、そもそも負債を貯めないことが重要だと考えています。
技術的負債は負債を作り出した人と返済する人が別になる典型的なものです。この場合には、そもそも負債を作り出すという考え方が間違っていると思います。 ビジネスに携わる人は借金と同列で語りますが、実際には、典型的な借金の返済パターンとは異なります。なぜなら、借金をした人が返済する義務を追わないからです。であるにも関わらず、借金と同列に考えている人は、もう少し思考を巡らせて考えを改めたほうが良いと思います。レバレッジは効くかもしれませんが、誰かの犠牲の上に成り立っていると自覚すべきです。