優秀なデベロッパに光を！
僕ももう30歳になり，自らアプリケーションのコーディングを仕事で行うことは，めっきり少なくなった。設計やベース部分，開発ツールなどを手がけることが多くなり，もしかしたらMicrosoft Office製品を触っている時間の方が多いかもしれない(いや，確実に多い)。プロジェクトに参加する数多くのプログラマを面倒見つつ，いろんな雑務をこなしながら，システムの実装作業を指揮する。はっきり言って，自分が何人いても足りない。
実装作業に秀でたデベロッパを数人知っている。彼らが描くプログラムは，合理的であり，生産性が高く，多くの視点に基づいていて，しかも芸術的である。視点が多いということは，プログラムの実行時に生じる可能性のある，あらゆる状況に対して適切な対処を講じることができていることを示す。安心できるコードはつまり，そういうことだ。
しかし，何故かこのソフトウェア開発業界は，優秀なデベロッパから得意分野を取り上げる。実装作業について優秀な人材は，設計者に「格上げ」される。つまり，コンパイラは取り上げられ，その代わりにMicrosoft Officeを与えられるのだ。少なくとも，Officeにコンパイル機能はない(モジュールは別)。実装感覚を持ったデベロッパは確かに優秀な設計者になり得るが，相変わらず実装をやらせた方が生き生きとしているデベロッパも大多数を占めるはずだ。
優秀なデベロッパを設計者にしてしまえば，残るのは「新人，あるいは優秀ではないデベロッパ」である。優秀かそうでないかの違いからくる生産性は，相乗以上に大きい。つまり，結局はプロジェクトに集められるプログラマは「優秀でない」人が集まる。その分，教育もかかるし，生産性も優秀なデベロッパに比べると，かなり期待できない。結果，プロジェクトの生産性は上がらない。そりゃそうである。優秀な人材を除外してしまっているのだから。
それを仕方ないと考えるのは簡単だが，現場はホントに深刻である。例えば，こんなコードを平気で記述される。
interface Dao {
void save(Model m);
}
void foo() {
Dao dao = …;
try {
dao.save(…);
} catch(Exception e) {
throw new IllegalStateException(“エラー”);
}
}
あり得ない。デバッグを放棄しているようなものである。「catch(Exception e)」は，Javaの仕様でコンパイルエラーにして欲しいと思ってしまうほど，これはひどい。しかし，プロジェクトに配属されるプログラマは，こんなもんなのだ。
優秀なデベロッパなら，「もし実行時例外が発生しても，それはバグや環境のはずだから，catchしなくてもいいはず」などの想像をすることができるはずだ。少なくとも，必要以上の例外補足がもたらす弊害を知っている。だからこそ，実装作業を任せられるし，品質を考えられるようになるのだ。しかし，上記のようなコードを書かれたら，いくら「 第1段階，第2段階のEoD」を進めたとしても，すべては水の泡である。
実装作業が好きで，実装作業にプライドを持ち，実装作業が得意で，実装作業について周囲から認められている人間は，身近にわんさかと存在する。彼らの得意作業は，実装であり，設計ではない。プロジェクトを成功させるためには，結局は実装者の手にゆだねられる。実装作業を行う人間は，最も評価されていいはずなのだ。評価されるということは，他人の手本になれる人だということになる。そんな優秀なデベロッパを引っこ抜いてしまって，その後優秀なデベロッパが育つわけがない。
プログラミングは単純作業ではない。まだまだ職人技だ。プログラムの得意なデベロッパを「職人」として見ることで，高い評価を与えてあげることはできないのだろうか？ねぇ，世の中の開発ベンダーさん，システム構築を依頼する顧客の皆さん！
