ふと昔のブックマークを見返していて思った事をが有ります。 はてなのid:naoyaさんの「僕やはてながPerlを選ぶ理由」というエントリ。 理由としてあげているのは此方。
僕の物作りの過程においては、コンパイラにやたらと怒られたり、変数の型を気にしたり、変数に入れるオブジェクトが何者だったりするかをいちいち意識しなければならない静的型付けの言語は性に合わなかったんですね。一方で簡単なことは簡単に、難しいことでもそれなりにできる Perl という言語は、僕のやり方に合っていたし、なんとなく"Hackしている"という気分にも浸ることができたんです。
最近Javaでコーディングする機会があって、僕もこの点を強く感じました。 ファイルの文字出力するのに何段階か経て出力ストリーム取得する手法や、明示的なキャストが必要だったりと何かと手間のかかる言語なのです。確かにセキュアでは有るかもしれません。理屈も納得は行きます。コンパイラは親切です。 でも、正直うっとうしいんですよね。 コンパイラは口うるさいし(僕はJavaのコンパイラを「コンパイラおばさん」とよんでいます。) そもそもちょっとデバッグするのにいちいちコンパイルすのは非常に面倒です。 一度スクリプト言語を使うと、その軽快さと手軽さがやみつきになってしまうんですよね。 それが多少リスキーで有ろうとも、プログラムを壊しても、また直せば良いんですから。 もう一点共感する点がこちら。
僕がプログラミング言語を使わずに考え出したソフトウェアというのは、綺麗に設計されているようで、実際に作り出してみるとまったくその通りにいかない。あそこがおかしい、ここがおかしい。紙の上の設計に後戻りしては設計書の間違いを訂正するのです。
基本的にプログラムを書く際には、要件を纏めて、概要設計して、詳細設計に落として、プログラミング。 という流れがベストプラクティスと言われています。実際やると全然そんな事はなくて、SIベンダーに身を置いていると、やれ仕様違いだ、やれ仕様変更だなんて事が日常茶飯事です。 あげくの果てに、「設計で謳っている機能は技術的に不可能な事がわかりました・・」なんて事もありました。 一体なんの為の設計なのやら。 ・・・だいたい、仕様変更ってなんだよ。だたの改良じゃないのか?って最近思うんです。 でも違うんですよね。 設計書ってそもそも、「良いプログラムを書く」為のベストプラクティスではないんですよ。 設計書は、
  • 顧客を納得させて仕様変更として納得させるため
  • 成果物として出す必要があるから
  • 最低限の品質を保証するため
という目的で有るんでしょう。 そして一番重要なのは、
  • 1からプログラムを書けない人でも戦力にできるように
って所ですかね。 そもそも設計する人間が普通にプログラムやらせてもらえないんですよね。 SI業界ではプログラマの地位はかなり低くて、言われたものを作るだけのコード書き(Coder)なんて怪しげな位置付けにされています。そもそもSEですって言っている人の70%位が其れこそほんと怪しいですけどね。 同じIT業界でも、色々なパラダイムがあって、パラダイムが違えば、そこには違ったルールがある。 少なくとも、SIとか、オープン系というパラダイムでは、優れたソフトウェアを作るより、顧客から文句のでないプログラムこそが最重要なんです。そりゃレベルも上がらないわな。 どちらかというと、政治的なやりとりに重きがおかれ、プロマネ > プロジェクトリーダー > SE > プログラマ > テスタというヒエラルキーはどうやってもひっくり返らないんでしょうね。 このパラダイムに居る限り・・・ですけどね。 まぁ、最近のSI系オープン系のパラダイムにはそれはそれで面白い潮流があるんですが、それはまた別のお話になるんで、そのうち。