”日本最大のオフショア開発専門マガジン”というメルマガを購読している（といっても無料会員ですが）

これは、中国にプログラミングを発注しているSEたちのためのメルマガで、建築図面とは分野が違うのだけど、たいへん興味深い。

プログラムの世界には、コーディング規約というものがあるらしく、変数の名前のつけ方から、コメントの空白の数まで、細かく決められることがある、ということを初めて知った。

これは図面で言えば、レイヤーとか、引き出し線の角度とか、ドア枠の表現方法の作図標準にあたる。

以前は、「プログラムのアウトソーシングの方が図面より楽だ」と思っていた。その理由は

・プログラムはきちんと動くかどうかで正解か不正解かが明らかである。図面の場合は、チェックする明確な方法がない。
・プログラムの関数がわからなければいくらでインターネットなどで、しかも英語で調べることができるが、建築の場合は、材料や工法が多岐に渡り、国によっても設計者によっても異なり、どう納めてよいのか、極論を言えば誰に聞いても正解がわからない。

しかし、どっこい、プログラムの世界も大変である。

以前、日本のJRの自動改札がプログラムミスでいっせいに停止した、という事故があったが、日経ビジネスの記事によれば、「フラッシュメモリにデータを転送する際に、データの件数がある特定の件数の時にだけ起きる不具合」だったそうで、たまたまその日はの条件に合致してしまったため発生した不具合だったそうだ。

プログラムにおいて、あらゆる条件を想定しても対処できるようにする、というのは、かなり大変である。ちょっと試して動いたから「OK」では済まされない。その点、建築図面の方が甘いかもしれない。

そしてコーディング規約。あるんですねぇ、そういうのが。

私も、プログラマーを雇っていくつかAutoLISPを書かせましたが、結果的に、ほとんどのプログラムを自分で書き直すハメになった。一番の理由は、「コードそのものが気持ち悪い。」「気持ち悪いので、不具合を直せない。改良できない」というもの

厳密なコーディング規約の是非も議論されているようですが、僕はコーディング規約に絶対賛成派。

厳密であれば厳密であるほど、発注しやすいし、成果品を直しやすいし、請けるほうもやりやすい。

前述のメルマガには、中国人プログラマーに対する不平不満もいっぱい書かれているわけですが、やはり大切なのはお互いに”誠実であること”それに尽きると思います。