井上 研一 これに関しては、自信を持って言えるのだが、「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。
こういうことについて、いろいろ書いてみたのだが、今の自分の能力では、まだきちんと書けないようだし、実に素晴らしく書いている記事を見つけたので、それにすがることにする。2006年3月に書かれたものだが、まさに、そのとおり！と、膝を叩いて何度も頷いた。
実は、今、私がやっている仕事、そして私の役回りが、完全なアンチパターンなのだ。一度も実装を経験したことのない技術で、詳細設計をやっている。設計したところで、それが純粋な業務要件的に合致しているのは何とか分かるとしても、それがどう実装されるのか、そもそも実装可能なのかは、まったく理解できていない。半年もやっているので、それなりに分かってきた部分もあるが、それが効果的な設計かといえば、「そうではない」と言える自信だけがあるような状態だ。そういう立場にいるからこそ、なおさら、それがいかにアンチパターンかが、分かるのである。（そんなわけで、少なくとも要素技術的にプロジェクトに貢献するのはなかなか難しい。別の側面で貢献が出来れば…と思っているところだ。
敢えて私から付け加えるならば、そういうメンバーの存在を許しているのは、「SE」という名前の職種が存在するからではないかということだ。一般的に「SE」と「プログラマ」という職種の分類は、「設計する人」と「プログラムする人」の違いだ。逆に言えば、「プログラムしない人」と「設計しない人」であり、もっと言えば「プログラムできない人」と「設計できない人」となる。（現状では、待遇面から皆、SEを目指さざるを得ない。それは、プログラムする人→プログラムしない人→プログラムできない人への進化…退化？の過程でもある。）
設計できないプログラマが、本当に良いプログラムを作れるのかは、大きな疑問である。そして、それ以上に、プログラムするための設計を行うべきSEが、プログラムできない人であるというのは、致命的だ。それでも、「プログラマ」という名前が付けば、設計できなくても仕方ない（安いし or 新人だし…）となり、「SE」という名前が付けば、プログラムできなくても、表面上は勤まるのである。（高いし and それなりの経験もあるのに…）
だったら、日本のソフトウェア産業から、「SE」という職種がなくなれば良いのに…と、思う。プロジェクトマネージャは必要としても、あとは全員、プログラマ。で、プログラマの中でリーダーだのチーフだの単なるメンバーだのといった階層があったり、どちらかといえば顧客寄りとか、実装寄りといった相対的な役割があれば、それで良いのではないか。「アーキテクト」という職種も最近増えたが、それもやはりプログラムが出来る人でないと職責を果たせないのではないか。
そんなわけで、私はずっと「職業：SE」と思っていたが（去年の秋～冬あたりは置いておくとして…。）、「SE」と言うのはやめたほうが良いと思っている。「職業：SE」と思っているあなたは、どうだろうか？