最近、開発部長がしきりに「割れ窓理論」を引き合いにだします。窓ガラスが割れたまま放置していれば加速度的にどんどん荒れていくという、あれです。多分、その理論自体に批判的な人は少ないと思います。

「達人プログラマ」には、ソースコードに当てはめて、汚いコードが混じり始めるとどんどん汚くなるということが書いてあります。「汚いコード」が何をさすのかは、議論の余地があるかもしれません。割れた窓ほど、誰が見ても明らかと言うことではないです。でも、ちらっと見ただけで読みたくなくなるようなソースコードが存在するのも事実です。かつて、一ファイルで数千行のJavaのソースコードを見たことがあります。ある意味、それを書いた人は天才かもしれません。

ソースコードでも、経験（時間じゃない）がある程度あれば、割れた窓は認識できます。チームで開発するときに問題になるのはソースコードだけではありません。ソースコードを書くのも人です。人はモチベーションに左右されます。モチベーションは、いろいろなものに影響を受けます。人のモチベーションが影響し合って、全体のモチベーションを左右することもあります。このモチベーションから割れ窓を認識するのは、ソースコードの割れ窓を認識するよりも遥かに難しいです。
そして、変化に気づかないまま、割れ窓とともに次第に荒れていくこともあります。

モチベーションの割れ窓を取り除く方法は、わかりません。その前に、割れ窓を割れ窓と認識できるようにしたいのですが、その方法さえもわかりません。

でも、実は割れているんじゃなくって、もう少しでヒビが入りそうな程度なのかも知れません。