窓を守る

こまつ みつのり(Mitsunori Komatsu) 2007-09-22 16:27:00

割れ窓理論というのがあります。詳細はいつも通りリンク先などを見てもらうとして、強引に一言に纏めると

建物などの窓が割れたままになっていると「この辺は誰も注意を払っていないのだろう」と住民のモラルが低下し、犯罪が多発し治安が悪くなる

そうです。なので、

軽微な問題や違反であっても手を抜かず対応していくことで重大な問題が発生しにくい環境にすることができるよ

というものです。

 

私は新人の頃に、達人プログラマーという本を読んでこの理論を知りました。この本では品質の低い一部のコードを放置しておくとプログラム全体の品質が落ちるという内容だったと思います(今、手元に無いのでうろ覚え)。読んだ当時は半信半疑でした。だってだって、プロのプログラマー達が作るプログラムにそんな情けない現象が発生するものでしょうか?します。これまでいくつかの開発現場を経験してきましたが、結構。

個人的な意見ですが、窓が破壊されプログラムの治安が悪化するのを防ぐポイントは以下かなぁと思います。

・ある程度スキルが高く、かつプログラム全体に愛情を注げるメンバーを増やす。

・やたらと開発体制を大きくしない。できるだけコンパクトに。

「ある程度スキルが高く、かつプログラム全体に愛情を注げるメンバーを増やす」について。品質の低いコードと判定するにはある程度のスキルが必要ですが、自分のコードだけしか興味を持たず他人のコードの品質は全然気にしない人だと窓が割れていることすらも気づかないでしょう。その場合でも、全体を見るよう指示をすれば多少は効果がありますが、テンションが低いままの作業になるので、別の弊害が出てくるかもしれません(自分の担当分のコーディングがはかどらなくなる、等)。理想を言えば、そういったメンバーでも自発的に全体を見るようになる仕組み作り(意識改革?)をすべきなのですが…現実的には「プログラム全体に愛情を注げるメンバー」を重視したほうが良いと思います。今回の窓の話から逸れますが、経験上、自発的にプログラム全体を見て意見してしまう人は成長が早いと思います。プロジェクトに入ってきて間もないくせに担当外のコードについて言及するプログラマが居たならば「生意気だ」と思うより「期待できる」と思ってみては如何でしょうか(まぁ、その意見の内容にもよりますが)。

「やたらと開発体制を大きくしない。できるだけコンパクトに。」について。まず開発体制が大きくなりすぎると、意思の疎通を行うのに時間がかかり気持ち的に面倒になってきます。意思の疎通が面倒になると誰も気にかけないコードというのが発生しやすくなり無法地帯化してしまいます。あと、「ある程度スキルが〜〜〜」とも関連するのですが、窓壊し人と窓直し人の割合を適正に保つのが難しくなる傾向があります。人が多すぎると、プロジェクト体制を決める際に、隅々まで気が回らなくなるのかも知れません。

と、ここまで書いてみて「初心者向けのBlogとか何とか言いながら開発体制がどうこうって、上から目線はやめろっ!」という自己感想をもってしまったのですが、「初心者の場合であっても自分のコードだけでなくプログラム全体にも気を使ってあげてね。余裕があればオープンソースのコードも見てね。勉強になるしパッチとか送れるようになると良いよ。」と書き加えて、バランスをとってみたりして。

※このエントリはZDNetブロガーにより投稿されたものです。朝日インタラクティブ および ZDNet編集部の見解・意向を示すものではありません。

SpecialPR

  • デジタル変革か?ゲームセットか?

    デジタルを駆使する破壊的なプレーヤーの出現、既存のビジネスモデルで競争力を持つ
    プレイヤーはデジタル活用による変革が迫られている。これを読めばデジタル変革の全体像がわかる!

  • 【3/31まで早期割引受付中!】「IBM Watson Summit 2017」開催

    日本IBMが主催する最大の国内総合イベント。テクノロジー・リーダーの疑問を紐解く「企業IT、セキュリティー、モバイル、データ解析などの進化を探る」詳細はこちらから!