割れた窓（悪い設計、誤った意思決定、質の低いコード）を放置しないべきか

「達人プログラマー」を読んでいて、「ソフトウェアのエントロピー」の項が印象的だった。

「割れ窓理論」というものが紹介されていて、それがソフトウェア開発の世界でも当てはまるので注意しよう、という話だった。

悪い設計、誤った意思決定、質の低いコードは発見と同時に修復しよう、という主張であったが、それは完全主義なのではないか、と疑問が浮かんだので、その是非について少し考えてみた。

割れ窓理論とは

ビルは、美しく清潔に保たれているビルがある一方で、ぼろぼろの放置された朽ち果てそうなビルが存在する。

この違いが生まれてしまうのは原因は、例えば窓が1枚割れてしまい、それが長時間修理されずに放置されてしまうと、ビルの住人に投げやりな感覚（ビルのことなど気にかけないようになる感覚）が生まれてしまうことだと云う。

そして、２枚目の窓が割れ、ゴミをまき散らすようになり、落書きもされてしまう。短期間のうちにぼろぼろになってしまう、というもの。

ソフトウェア開発における割れた窓

これがソフトウェア開発の世界にも当てはまり、

割れた窓（悪い設計、誤った意思決定、質の低いコード）が放置されていると

明らかに問題があるにもかかわらず、その状況を無視することで、問題を解決する方法はおそらく「何もなく」、誰も気にしないという考えが補強され、すべてが破滅に向かうのです。あらゆるネガティブな考え方は、チームメンバーの間に浸透していき、凶悪なスパイラルを生み出すのです。

ということらしい。

だから、割れた窓は放置してはならず、

発見と同時に全て修復してください。

ということであった。

割れた窓を放置しないは完璧主義なのではないか

ここで浮かぶ疑問は、それは完璧主義に陥るのではないか、現実的に「発見と同時に全て修復する」なんてことはできるのだろうか、というものであった。

本当に割れた窓は放置しておかないべきなのだろうか、ということを考えてみて、

自分の結論としては、基本的には放置しておかないべきだが、

• 自分が実装する範囲では、割れた窓をつくらない。
• そのうえで、割れた窓を発見したときに、１チケットにつき、（全てではなく）１つ改善する。
• あとはチームに、割れた窓をつくらない、共通認識をつくる。
• チームに割れた窓を１チケットにつき、１つ改善する共通認識をつくる。

というところが現実的ではないかと思った。

自分が実装する範囲では、割れた窓をつくらない

悪い設計、誤った意思決定、質の低いコードを自分はしない、という意識を持つことは当然で、修正しづらいメンテナンスしづらいソフトウェアとなることを極力避けるために努力をする。

急な修正が必要であったとしても、コードの共通化、抽象化をし、テストを書き、わかりやすく記述することを怠けない。

それによって、余計な時間がかかってしまうと感じてしまうことがあるかもしれないが、これはトレーニング次第だと思っていて、普段から良い設計、質の高いコードをすることを自分に課していくことで、短時間でそれらをやれるようになるのではないか。

逆に、質の低いものでも良いという意識で、自分を許してしまうと、質の低いものしか書けなくなってしまうのではないか。

割れた窓を発見したときに、１チケットにつき、（全てではなく）１つ改善する

割れた窓を「発見と同時に全て修復する」ということは、現実的には難しい可能性が高く、割れた窓の修復に時間がかかりすぎる場合には、ソフトウェアに新しい機能を追加したり修正したりできなくなってしまう。

「達人プログラマー」の中でも

もし正しく修復するだけの時間がないのであれば、分かりやすいところにその旨を明示しておいてください。例えば、目障りなコードをコメント化したり、「実装していません」というメッセージを残したり、ダミーのデータを代わりに設定しておけるはずです。ダメージが広がるのを防ぎ、あなたが状況を認識していることを明確にするため、「何らかの」アクションをとってください。

とは、書かれている。

ただし、コメントだけするということになると、それはそれでコメントすればいい、という意識が生まれてしまうのではないだろうか。（もちろん、コメントしないよりはましなので、コメントはするべき。）

なので、割れた窓を放置しないし、今後割れた窓を生まない、という意識をチームに浸透させるためには、発見した割れた窓のうち１つは改善する、というルールを持たせると良いのではないか。

１つの機能の追加や修正をするチケット（タスク、ストーリー）につき、１つ割れた窓を修復する。

というルールで、実際に割れた窓が修復されるし、プロダクトオーナーも説得しやすいし、場合によってはプロダクトオーナーの承諾なしにやってしまってもいいかもしれない。

チームで割れた窓をつくらない、１つは修復するという共通意識をつくる

この「割れ窓理論」の問題点は人々に投げやりな意識をつくってしまうことにあるので、

そもそもチームメンバー間で投げやりな意識を持たないように、共通意識をつくる努力をしていけば良いと思う。それは例えば、コードレビューでテストを書かないと Approve しないというルールをつくったりすると良いと思う。

それでも、割れ窓を見た時に、自分も同じようなコードを書いていいのだ、という意識が生まれてしまうかもしれないので、やはり１つ修復するというルールを設けると良いのではないか。