環境犯罪学上の理論に「割れ窓理論」というのがあります。
「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」(Wikipediaより)
有効性などに批判もあるようですが、ここでは置いておきます。
システム開発のプロジェクトでも同様のことがあるのでは？と思いました。
例として「チケット駆動開発ですので、コミットログにRedmineのチケット番号を記述してください」というルールがあったとします。
しばらくはそれでうまくできていたのですが、ある日、(理由は別として)「どのチケットに紐付くか不明なコミットログ」がいくつか発生したとします。
そのコミットログを見た別のメンバーは「じゃあ、自分も…」と、さらにチケットに紐付かないコミットログが増えていきます。
こうなってしまうと、(チケット駆動開発のメリットである)タスクの状況確認、品質チェックなどをしやすくなっていたのが、消えてしまいます。
むしろ修正理由やその背景が分からないため、品質低下を招くかもしれません。
ではどうすれば良いか？
1つは、チェックを自動化して定期的に行うことかと思います。
「コミットログにチケット番号があるか？」をチェックするスクリプト(コミットログを取得して正規表現でチケット番号のフォーマットを見つける)を書いて(自動化して)定期的に実行します。
こうすることで、ルールと違うのがあればすぐに見つけて、それ以上増やさないように手立てを打てます。
もう1つは「なぜこのルールを守らないといけないか？」「守るとどういうメリットがあるか？」を理解することです。
余談ですが、組織のルールのいくつかは「なんで？」が明確でない…時には「昔からそうだったから」なんていう…ものもあったりします。
ルールを絶対視せずにいると、改善できる余地があり、結果としてより良いルールができるかもしれません。
またこれまでなかなかルールを守れなかったメンバーが、それをクリアできるようになったとしたら、感謝の言葉…「おかげでキチッと把握できるようになりました」…を伝えるのもアリかと思います。
最後に、ルールを守れなかったとしても、守れなかった人を責めるのではなく、そういう状況になってしまうルールやプロジェクトの状況の問題として捉える必要があります。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo by ell brown on Visual hunt / CC BY
コメント