ソフトウェア開発現場は
全てが順調にいくというケースは
少なく、
何かしらの問題が出る事が
ほとんどですが、
その際、問題を解決する為に
ルールを決める
という手段が、しばしば使われます。

例えば、

(問題)
リーダーとメンバー達の意思疎通が
うまく取れていなかった。

(解決法)
メンバーは毎日リーダーに作業状況を
報告する様にする。

(問題)
バージョンアップに伴い、仕様が変更されたが
取扱説明書には反映されていなかった。

(解決法)
仕様変更があった際には仕様書だけでなく
説明書の変更もすぐに行なう様にする。

といった具合です。
一見、問題なさそうですが
実はこの「ルールを決める」という解決方法・・・
最も安直で避けるべき解決方法です。

なぜなら、まさにこの方法が
「木を見て森を見ず」の
解決方法だからです。

ルールも少数なら
メンバーは覚えて守る事ができます。

しかし、事ある毎に
ルールを作っていたのでは、
ルールの数が多くなりすぎて
メンバー達も把握できず、
必ず、忘れられるルールというのが
出てきます。

チームで開発する以上、
全くルールなしで開発するという訳にはいきません。

しかし、その数が多くなりすぎると
ルール1つ1つの価値が軽視されてしまって
本当に守って欲しい重要なルールも
他のルールの中に埋もれてしまうのです。

私に言わせれば
ルールを作って解決するなんていうのは
担当者の怠慢です。

自分は問題を解決したと
アリバイ作りの為に
ルールを作って、そして次に問題が起きた時には
「ルールを守らないから悪い。」
と、その人に責任を転嫁するのです。

ですから、何か問題が起きた時には
極力ルールを作る事は避け

  • その問題がルール以外で解決できないのか?
  • そもそも、その問題が優先して解決すべきものなのか?
  • システムやツールの導入で、解決している形に自然に持っていけないか?
  • もっと根本のところに解決すべき問題がないのか?

といった事を考えるべきです。

問題解決というのは、
本来、ルールを作るといった表面的な事で
できる部類の事ではないのです。