汝、ミカン置き場をリンゴ置き場と呼ぶなかれ
バカが征く （読んだときと既に内容が変わってるのだけど）を読んで探してみたら見つかったのが インターネットコム - japan.internet.com で、思い出したのが結構昔にやった開発。
＜例え話モード開始＞
リンゴを置く場所がありました。ここにはリンゴを置く、というルールになっていたので、作業手順書にその場所のことを「リンゴ置き場」と書きました。例えば「バナナはリンゴ置き場の横」みたいな感じです。
ところが、ある日、理由はわかりませんが、今後はそこにはリンゴを置かずに、ミカンを置くようになりました。なので、作業手順書に「リンゴ置き場」と書いてあるところを「ミカン置き場」と書き換えましょう、と偉い人にお願いしたところ、偉い人たちの集まりで「全部書き換えると大変だし、今後は『ミカン置き場』のことを、通称『リンゴ置き場』と言うようにすればいい、ということに決めてしまいました。私はそんなことしたらややこしいのでイヤだと言ったのですが、まあ大丈夫だろうと軽く流されてしまいました。
私は、これは面倒なことになりそうだ、と思ったのですが、影響は想像以上でした。
もし、もうリンゴは無くなって、本当の意味でのリンゴ置き場がなければよかったのですが、実はまだリンゴがあり「新リンゴ置き場」が出来ていたのです。
こうして起こったことは…
- 「リンゴ置き場」と書いたとき、それが「新リンゴ置き場」なのか「通称リンゴ置き場・現ミカン置き場」なのか区別がつかない。（コンパイルが通ってしまう）
- 「リンゴをリンゴ置き場に置く・取ってくる」という手順書を見ても、違和感を感じないので、誤りだと思えない。誤りだと気付くまでにかかる時間が通常の誤りよりも充分長い時間がかかる。（問題発見の難易度急上昇）
- その誤りを「自分の責任」だと思うことができない。（モチベーション）
＜例え話モード終了＞
というわけで、これまで体験したプロジェクトの中でも非常に葛藤したものの一つなので印象に残っています。
で、何が言いたいかというと、大規模開発で一旦グラウンド・デザインが決まってしまい、その後混乱を招くような方針変更があった場合、上記のようなことになるのだけど、現場の偉い人が、物理的にソースが変わってしまうことを恐れて「その場しのぎ」の対策を指示してしのいだ（つもりの）ツケが未来のリスクとなる（今回の場合はすぐ発現しましたが）ことを理解していないことが多い。本当に多い。ものすごい多い。何、この高打率？ ってぐらい。
そして、現場の偉い人がもしそれを理解していても、そのリスクを片付けてしまうためのコストを偉い人の偉い人が承認してくれるかどうか。「そもそも何でそんなことになったの？」とか言い出して「経緯や対策を素人にもわかるようにブレイクダウンした資料」や「リスクが発生する確率とその根拠となる数値」を出せとか、もうわけわからなくなるケースも。今の職場ではそんなことないですけど。
偉い人や偉い人の偉い人の気持ちもわからんでもない。「これまで動いてたという保証がなくなる」というのは確かに恐怖でしょう。しかし「そんなに品質が心配なら、部分的にでもいいから自動テストを導入せんかい」と思う今日この頃であります。
もうちょっとおまけに思うこと。そもそも変数名を flag とした段階で死んでいる。半年もすれば何の状態を示す flag なのか、それが 1 ならどっちの状態なのかを半年後のあなたは覚えている自信がありますか（私はないのでコメントに絶対書くけど）。私は foo_exist_q なんて名前にしてます (foo がある場合 true)。変数名に ? が使えればよかったのにと思います。
