レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

誰も決めておらず、どこにも書いていない不条理なルール

僕の好きな本「コンサルタントの道具箱」のなかに、こんな一節がある。

誰が決めたことか、どこに書いてあることかも知らないのに、慣例に従って仕事をする人たちがいる。

なんでもかんでも慣例に従って仕事をすることへの戒めだ。
なぜいけないのかといえば、慣例は知らないうちにルールになってしまうからだ。
慣習上がりのルールには合理性がない。

そういった合理性のない慣習上がりのルールが足かせとなっていくのだ。


システム開発という仕事は、特にルールと上手く付き合っていかなくてはならない。
合理的なルールを上手く使っていけば、管理の手間が省略できたり、
情報が一箇所にまとまったりして、効率や生産性が上がることもある。


反対に、合理性のないルールはタチが悪い。
非正規化されたテーブルのようにアチコチに同じ情報があったり
不整合を時々メンテナンスする必要があったりと、足を引っ張ることになる。


しかし、非効率なだけならまだ良い。
ルールは、時間と共に成長していくものだ。
しばしば、非効率なルールは「問題を誘発するルール」に成長する。


僕は今日、その過程を見た。
上述の「コンサルタントの道具箱」に習って要約すれば以下のようになる。

誰も決めておらず、どこにも書いていないのに、
勝手にルールだと解釈して仕事をする人たちのお陰で
問題のある不条理なルールが作られる。

僕が問題のあるルールを発見したのは、あるトラブルがキッカケだ。


このトラブルの原因は、僕らが作った新たな機能のプロパティーの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と重複してしまったのだ。


馬鹿なことだと思われるかもしれない。


しかし、慣習に従うという意識で仕事をする人は現場でよく見かける。
ルールを守ることはチームで仕事をする上では大事なことだ。
それに慣習に背くよりも、慣習に従うほうが楽だ。


なぜなら
慣習に背くことは、自分の意見を主張し貫くことだからだ。


そこには主張するだけの論理武装と勇気が必要になる。
実際、それ以外にも、このルールを破ることのコストは以外に高くつく。
既存機能のコピーを簡単には流用できなくなってしまう構造だったのだ。
これだけ条件があれば、慣習に従うという選択肢を取るのは、理解可能だ。


しかし、慣習に流されて自らミスを誘発するというのは屈辱的だ。

馬鹿なルールに流されて後悔するよりも、
自分を貫いて後悔する方が、誇りを持ったプログラマーの姿勢としては正しいと思った。


コンサルタントの道具箱

コンサルタントの道具箱

*1:ただし例ではわかりやすくデフォルメしている。本当は画面IDなのか固定プレフィックスなのかがわかりにくいプレフィックスの文字列だった。