サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

仕事のやり方 旧館より

プロジェクトにおける「割れ窓理論」

投稿日:2010年11月28日 更新日:


環境犯罪学上の理論に「割れ窓理論」というのがあります。

「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」(Wikipediaより)

有効性などに批判もあるようですが、ここでは置いておきます。
システム開発のプロジェクトでも同様のことがあるのでは?と思いました。

例として「チケット駆動開発ですので、コミットログにRedmineのチケット番号を記述してください」というルールがあったとします。
しばらくはそれでうまくできていたのですが、ある日、(理由は別として)「どのチケットに紐付くか不明なコミットログ」がいくつか発生したとします。

そのコミットログを見た別のメンバーは「じゃあ、自分も…」と、さらにチケットに紐付かないコミットログが増えていきます。
こうなってしまうと、(チケット駆動開発のメリットである)タスクの状況確認、品質チェックなどをしやすくなっていたのが、消えてしまいます。
むしろ修正理由やその背景が分からないため、品質低下を招くかもしれません。

ではどうすれば良いか?

1つは、チェックを自動化して定期的に行うことかと思います。
「コミットログにチケット番号があるか?」をチェックするスクリプト(コミットログを取得して正規表現でチケット番号のフォーマットを見つける)を書いて(自動化して)定期的に実行します。
こうすることで、ルールと違うのがあればすぐに見つけて、それ以上増やさないように手立てを打てます。

もう1つは「なぜこのルールを守らないといけないか?」「守るとどういうメリットがあるか?」を理解することです。
余談ですが、組織のルールのいくつかは「なんで?」が明確でない…時には「昔からそうだったから」なんていう…ものもあったりします。

ルールを絶対視せずにいると、改善できる余地があり、結果としてより良いルールができるかもしれません。
またこれまでなかなかルールを守れなかったメンバーが、それをクリアできるようになったとしたら、感謝の言葉…「おかげでキチッと把握できるようになりました」…を伝えるのもアリかと思います。

最後に、ルールを守れなかったとしても、守れなかった人を責めるのではなく、そういう状況になってしまうルールやプロジェクトの状況の問題として捉える必要があります。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo by ell brown on Visual hunt / CC BY

-仕事のやり方, 旧館より

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

「アジャイルの好きなところ」(Ultimate Agile Stories2)

そろそろUltimate Agile Storiesの季節です。 というわけで、Ultimate Agile Stories1に続き、Ultimate Agile Stories2で書いた内容をほぼ原 …

「お医者さん」だって全部の病気を知らないでしょ?

仕事、プライベート問わず「パソコンの事」を質問されると結構困ります。 自分の知っている/使っているアプリケーション、OSに関する質問であれば、それなりに答えられます。 もし、答えが分からなくても、(経 …

ペアプログラミング―エンジニアとしての指南書[読書感想]

ペアプログラミング―エンジニアとしての指南書 著者:Laurie Williams, Robert Kessler 翻訳:長瀬 嘉秀, 今野 睦, テクノロジックアート 今の小規模プロジェクトで、ペア …

会社を移ることになりました

2012年6月末で会社を移ることになりました。 (何度か転職をしているのですが)今のところ、社会人経験の中で一番長く所属していた会社になっていました。 思い出1:Rubyとの出会い 入社後しばらくして …

「感謝の言葉を伝える」アクティビティ

少し前、グループでフリカエリとこれからの活動について、半日時間を取って、しっかり議論しました。 夜は、(それまでの活動が一区切り付いたこともあって)打ち上げをしたのですが、そこでちょっとしたアクティビ …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。