誰も決めておらず、どこにも書いていない不条理なルール
僕の好きな本「コンサルタントの道具箱」のなかに、こんな一節がある。
誰が決めたことか、どこに書いてあることかも知らないのに、慣例に従って仕事をする人たちがいる。
なんでもかんでも慣例に従って仕事をすることへの戒めだ。
なぜいけないのかといえば、慣例は知らないうちにルールになってしまうからだ。
慣習上がりのルールには合理性がない。
そういった合理性のない慣習上がりのルールが足かせとなっていくのだ。
システム開発という仕事は、特にルールと上手く付き合っていかなくてはならない。
合理的なルールを上手く使っていけば、管理の手間が省略できたり、
情報が一箇所にまとまったりして、効率や生産性が上がることもある。
反対に、合理性のないルールはタチが悪い。
非正規化されたテーブルのようにアチコチに同じ情報があったり
不整合を時々メンテナンスする必要があったりと、足を引っ張ることになる。
しかし、非効率なだけならまだ良い。
ルールは、時間と共に成長していくものだ。
しばしば、非効率なルールは「問題を誘発するルール」に成長する。
僕は今日、その過程を見た。
上述の「コンサルタントの道具箱」に習って要約すれば以下のようになる。
誰も決めておらず、どこにも書いていないのに、
勝手にルールだと解釈して仕事をする人たちのお陰で
問題のある不条理なルールが作られる。
僕が問題のあるルールを発見したのは、あるトラブルがキッカケだ。
このトラブルの原因は、僕らが作った新たな機能のプロパティーのIDが
プロパティーファイル上で重複していたのが原因だった。
しかしなぜこのような事が起きたのか。それが核心部分だ。
プロパティファイルは、もともと以下のようになっていた。
#AAA0001画面用
AAA0001S001=SELECT * FROM 〜〜〜
AAA0001S002=SELECT * FROM 〜〜〜
AAA0001S003=SELECT * FROM 〜〜〜
AAA0001I001=INSERT INTO 〜〜〜〜
AAA0001I002=INSERT INTO 〜〜〜〜
#BBB0002画面用
AAA0001S004=SELECT * FROM 〜〜〜
AAA0001S005=SELECT * FROM 〜〜〜
AAA0001S006=SELECT * FROM 〜〜〜
AAA0001I003=INSERT INTO 〜〜〜〜
AAA0001I004=INSERT INTO 〜〜〜〜
このファイルの問題に気づいただろうか。
AAA0001画面と、BBB0002画面は別画面でありIDのプレフィックスは本来「画面ID」なのに、それを無視して
「I(INSERT)」や「S(SELECT)」、「U(UPDATE)」という処理ごとの連番になってしまっているのだ。*1
ここで、新しい機能を作ったプログラマさんは「CCC003」の機能を作るために
プロパティーを追加したのだが、悩んだ挙句、上の二つの悪しき慣習に従ってしまった。
つまり慣例をルールだと勝手に決め付けてしまい、以下のように追記したのだ。
#AAA0001画面用
AAA0001S001=SELECT * FROM 〜〜〜
AAA0001S002=SELECT * FROM 〜〜〜
AAA0001S003=SELECT * FROM 〜〜〜
AAA0001I001=INSERT INTO 〜〜〜〜
AAA0001I002=INSERT INTO 〜〜〜〜
#BBB0002画面用
AAA0001S004=SELECT * FROM 〜〜〜
AAA0001S005=SELECT * FROM 〜〜〜
AAA0001S006=SELECT * FROM 〜〜〜
AAA0001I003=INSERT INTO 〜〜〜〜
AAA0001I004=INSERT INTO 〜〜〜〜
#CCC0003画面用
AAA0001S007=SELECT * FROM 〜〜〜
AAA0001S008=SELECT * FROM 〜〜〜
AAA0001S009=SELECT * FROM 〜〜〜
AAA0001I005=INSERT INTO 〜〜〜〜
AAA0001I006=INSERT INTO 〜〜〜〜
CCC0003機能のプロパティーの1つでタイプミスがあり、
他の画面で使われているプロパティーIDと重複してしまったのだ。
馬鹿なことだと思われるかもしれない。
しかし、慣習に従うという意識で仕事をする人は現場でよく見かける。
ルールを守ることはチームで仕事をする上では大事なことだ。
それに慣習に背くよりも、慣習に従うほうが楽だ。
なぜなら
慣習に背くことは、自分の意見を主張し貫くことだからだ。
そこには主張するだけの論理武装と勇気が必要になる。
実際、それ以外にも、このルールを破ることのコストは以外に高くつく。
既存機能のコピーを簡単には流用できなくなってしまう構造だったのだ。
これだけ条件があれば、慣習に従うという選択肢を取るのは、理解可能だ。
しかし、慣習に流されて自らミスを誘発するというのは屈辱的だ。
馬鹿なルールに流されて後悔するよりも、
自分を貫いて後悔する方が、誇りを持ったプログラマーの姿勢としては正しいと思った。
- 作者: ジェラルド・M・ワインバーグ,伊豆原弓
- 出版社/メーカー: 日経BP社
- 発売日: 2003/07/29
- メディア: 単行本(ソフトカバー)
- 購入: 8人 クリック: 133回
- この商品を含むブログ (78件) を見る