はいどうも～！お鼻がmzmzマスク必須エンジニアの吉田です。
地震にも負けず、津波にも負けず、停電にも原発の放射能にも負けぬ、丈夫なココロを持って、
まずは自分の出来るところから日本の復興に貢献していきましょう！
ということで、
今までのブログ記事はどちらかというとプログラム実装寄りな内容を綴っていましたが、
今回はプログラムを書く上での一般論寄りな内容を綴ってみたいと思います。
では、早速本題へ。
みなさんは「割れ窓理論」という言葉を聞いたことがありますか？
Wikipedia[1]によると、
> 「軽微な犯罪も徹底的に取り締まることで凶悪犯罪を含めた犯罪を抑止できるとする環境犯罪学上の理論」
と紹介されています。
これが、なぜ「割れ窓」という名前がつけられているのかというと、
> 「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、
> やがて他の窓もまもなく全て壊される」との考え方からこの名がある。
とのことです。
[1] 割れ窓理論 - Wikipedia
これがソフトウェア開発とどのような関係があるのでしょうか？
割れ窓理論は、名著『達人プログラマー―システム開発の職人から名匠への道』[2]でも
紹介されている、優れたプログラマーになるためのヒントの一つです。
[2] Amazon.co.jp： 達人プログラマー―システム開発の職人から名匠への道
プログラマーは、プログラムを書くときにどのようなことを意識しているでしょうか。
常に自問自答しながら、あらゆる状況に陥ってもシステムが稼働するように、
考えられうる可能性の全てに対応できるような仕組みを考え続け、
脳内の思考回路をソースコードという成果物にアウトプットしていきます。
「このシステムの目的は何か？」
「このシステムのユーザーは誰か？」
「このシステムのスポンサーは何を期待しているか？」
「この機能に対してユーザーはどのような振る舞いを期待しているか？」
「この変数に想定外の値が入った場合そのコードはどのように振る舞うか？」
「このコードを他の誰か（未来の自分を含む）が読んだときに理解できるか？」
「この変数名は簡潔に意味を示唆する名前になっているか？」
「この複雑さはもっと簡潔に表現できないか？」
「顧客の要求がどのように変化する可能性があるか？その場合変更に耐えやすいか？」
「この処理はどの程度の計算回数か？ランダウ記法でのオーダーはどの程度となるか？」
「このフォーマットはRFCに準拠しているか？準拠していても対外システムは本当に正しく動作するか？」
「このSQLはテーブルのどのインデックスが採用されるか？フルスキャンされないか？」
「このネットワークアクセス関数は名前解決に時間を要しないか？タイムアウト時間は？」
「このプログラムはシステムアーキテクチャのどの部分に属すべきか？」
「エラーが発生した場合に予期しない動作をしないか？エラーとなりうる部分は他にもうないか？」
「このメソッドはテストしやすいか？デバッグしやすいか？不具合調査で後から処理を追うことができるか？」
「この機能はいつまでに開発完了させなければならないか？遅延した場合のリスクはどれ程か？」
他にも様々なことを考え続けます。
そして、それら様々な考えの中のひとつである
「自分は窓を割っていないか？」
という意識を紹介します。
この「割れた窓を作らない」という意識は、非常に大切なものだと思っています。
では、割れた窓を作るという行為は、具体的にどのようなものなのでしょうか？
まず、割れ窓理論における治安の悪化プロセスをみてみます。
1. 建物の窓が壊れているのを放置すると、それが「誰も当該地域に対し関心を払っていない」というサインとなり、犯罪を起こしやすい環境を作り出す。
2. ゴミのポイ捨てなどの軽犯罪が起きるようになる。
3. 住民のモラルが低下して、地域の振興、安全確保に協力しなくなる。それがさらに環境を悪化させる。
4. 凶悪犯罪を含めた犯罪が多発するようになる。
これをソフトウェア開発に置き換えてみると、
1. スパゲッティな汚いコードを放置すると、それが「誰も品質を高めようと意識していない」というサインとなり、汚いコードを書きやすい環境を作り出す。
2. コピペや、投げやりなコードなどにより軽微な不具合が発生するようになる。
3. プログラマーのモラルが低下して、プログラムの保守、システムの品質確保に興味がなくなる。それがさらに品質を低下させる。
4. 金銭的損失を伴う重大な障害を含めた障害が多発するようになり、ユーザからのクレームも多発するようになる。
5. 障害やクレームに対応したいが、システム内部がブラックボックス化し、品質を保った保守が不能な状態に陥る。
ということになります。
つまり、実社会における 「窓を割る」 という行為は、
プログラマーの世界では 「なんだか汚らしいコードを書く」 ということなのです。
では、悪化した治安を回復させるためにはどのようなことが必要なのでしょうか。
こちらもWikipediaを参考にしてみます。
・一見無害であったり、軽微な秩序違反行為でも取り締まる（ごみはきちんと分類して捨てるなど）。
・警察職員による徒歩パトロールや交通違反の取り締まりを強化する。
・地域社会は警察職員に協力し、秩序の維持に努力する。
これもソフトウェア開発に置き換えてみると、
・少し読みにくいコードであったり、軽微なミスでもすぐに修正する（スペルミスは直す、命名規則を揃える、など）
・プログラマーは他の人のプログラムにも目を凝らし、お互いにソースコードの問題を指摘する。
・プロジェクトマネージャやクライアントなどのステークホルダもプログラマーに協力し、品質の維持に努力する。
ということになります。
「いちいち人のコードを指摘するなんて！」と思う方もいるかもしれませんが、ケント・ベックが
エクストリーム・プログラミングで提唱している「5つの価値」（コミュニケーション・シンプル・
フィードバック・勇気・尊重）の考え方を全員が持っていれば、必然的にその意識が生まれ、
結果的にその方がいいアウトプットが出来ると思っています。
品質を低下させにくい環境を作ることで、各プログラマーの意識が高くなり、
結果的にそのシステムの品質は向上するのではないでしょうか。
プロジェクトの性質によっては窓を割らざるを得ない時もありますが、
窓は割らないよう心がけてプログラムを書いていきたいですね！
（余談）
今回は割れ窓理論をソフトウェア業界で考えてみましたが、
Wikipediaにもあるように、ビジネスでも応用できる考え方みたいです。
> 日本・東京ディズニーランド・東京ディズニーシーでは、ささいな傷をおろそかにせず、
> ペンキの塗りなおし等の修繕を惜しみなく夜間に頻繁に行うことで、従業員や来客の
> マナーを向上させることに成功している。
今回はこの辺で。
デワデワ。
