あの認定試験問題の品質をSI業界の代表的なプログラム品質と考えることの是非
SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？に対して、既に何人かの方々から
単に駄目試験だってだけなのでは。
これ確かにヒドイけどこんな資格試験の内容ひとつで業界全体を語られても
のようなご指摘をいただきました。実際に試験問題の品質を持ち出して、実際のSI業界全体の品質を語るのは議論の飛躍し過ぎたところがあり、私としても反省しております。
しかし、既に指摘させていただいているように、実際のSIerの開発したシステムで使われているプログラムの品質というのは会社の知的財産権や秘密主義といったことから、オープンソース化されることがめったにないというのが事実であり、本当のところどうなのかということについては残念ながら神のみぞ知る事実ということになると思います。*1
したがって、こういったところは自分の少ない経験を通して推測するしかありません。（グルーポンのおせち事件を受けてSI業界が本当に教訓とすべきことでも指摘したように、こういったプログラム品質の見えにくさはSI業界固有の問題だと思います。）
私がアーキテクトとして全体の設計や規約に対して責任を持って開発をすることができたプロジェクトでは、ここまでひどい設計はしてこなかったという自信があります。しかし、デスマプロジェクトの火消しや、うまくいっていないプロジェクトのプログラムをリファクタリングしたりレビューしたりする仕事の機会が今まで少なからずあり、そうしたプロジェクトではほぼ間違いなくこの試験問題のレベルかそれ以下の、まったくオブジェクト指向でない設計で行われたコードとなっていました。
- クラスの長さが10000行を超えるGod Class
- パラメータの数が60個を超える
- 業務レイヤーのクラスが画面固有のクラスに平気で依存する
- ほとんど同じ内容のコピペクラスが何十回となく繰り返される。
- 同一の文字列メッセージなどの定数値がいたるところに繰り返しハードコードされる。
- フレームワークの規約により無駄なクラスが大量に作られる（アンチパターン―ソフトウェア危篤患者の救出ではお邪魔妖怪アンチパターンとして紹介されている。）
- まったく利用されていないデッドコードが多数存在する。
- 番号つきのおかしなクラス名
などといったレベルのプログラムは今までに実際何度も目にしてきています。それゆえ、今回この問題のことを発見して、「やっぱりそういうことだったのか」と思ってしまい、不適切な類推で議論を進めてしまったというきらいがあります。
しかし、上のコメントをいただくような方は
- 高度な技術を発揮してSIをしている稀有な非常に恵まれた会社で仕事をしている
- SI業界での開発をした経験がない。
- 上流専門の方で下流工程のプログラムの中身にまで関与したことがない。
という方が多いのではとも思ってしまいます。実際、全体的にみればあの記事に対するコメントの多くは、例の問題の品質が実案件の多くのプログラムの品質を実際に暗示するということを裏付ける内容のものでした。これは、こうした品質の問題があるプロジェクトが多数存在する事実が無視できない件数存在する証拠であると言ってよいのではないでしょうか？
だから、私は単に資格試験の品質の問題として片付けてしまうのではなく、ここでいったん現状のSI案件の品質や設計、開発の進め方、オブジェクト指向の理解度などについて関係者が胸に手を当てて反省するタイミングなのではないかと考えています。もちろん、うちのシステム開発のやり方は問題ないと思えるのであれば、非常にすばらしいことでしょう。
