交換可能性に対する嫌悪感

個人的には似てるとはあまり思わないが、それはさておき、 プログラマーとゲーマーは似ている

プログラミングでも - リズミカルにタイピングしているだけで楽しくなってくる私はプログラミングをしていて嫌だと思ったことはほとんどないが - サン・マイクロシステムズの新入社員研修が終わったばかりの頃、一度だけ嫌だと思ったことを記憶していて、それは仕様をポンと渡されて、この通り作ってと言われたときだった。工夫の余地がなく、誰でもよい感じが滲み出ており、こういう時には、言われた仕様の10倍くらいのものを作って、二度とつまらない仕事がやってこないようにしようと心がけるのである。

これはいわば、交換可能性に対する嫌悪感である。

ぐっときたなぁ、「交換可能性に対する嫌悪感」って言葉。

ただ悲しいかな、多くのSIer中心のシステム開発の現場では「交換可能性の向上」こそが是とされてきた歴史がある。 「交換可能性を高めることのコスト」（責務の細分化、ドキュメント中心主義）より、「エンジニアの技量不足のリスク」「エンジニアが交換不可能になることのリスク」を重視してたのだね。

でもって、いまだにそういった現場では「交換可能性の向上」が重視される文化もあるのだからしょーもない。 モチベーションが上がる筈がない。 当然それなりのモチベーションなので、品質管理のリスクも上昇する。 で、仕様ポンPGでもそれなりの品質が保てるような品質管理体制を組む必要があり、やっぱりそこにもコストがかかる。 ってどんどんカネだけがかかるわけだが、「ケタ違いのIT投資を行う業界」というものが存在しているので、それはそれでいいのかな。

いや、そんなところに一エンジニアとして潜り込んでも多分ツマランだろうなぁ。

ところで、

こういう時には、言われた仕様の10倍くらいのものを作って、二度とつまらない仕事がやってこないようにしようと心がけるのである。

これってどういうことかよく分からなかった。 １０倍の生産性で仕事をこなせば、次からはその１０倍の「仕様ポンな」仕事がくるだけだと思うけど。 ってかさ、サンみたいな会社で「お前一生仕様ポンなPGな」的なポジションがあるのかどうなのか。 ・・・いやないんじゃないの、大手だし。 中小だったらあっても全然おかしくないけども。 ってかそんな仕事ばっかりのところも山とあったり。