SIerの仕事とお勉強

絶対的な性能を求めるとき、データはコンパクトであるべきだけど、必要以上にリソース不足を意識しすぎてベタベタな設計をすることによって余分にかかる開発工数の3分の1くらいをサーバーやディスクに費やしたら余裕でプロジェクト完遂できますよ、と思いつつ、きっとハード代と開発人員のコストでは後者を優先しないとおまんま食い上げと思っている人が多いんだろうなあと遠い目をしたくなる今日この頃ですが皆様いかがお過ごしでしょうか。

冗談はさておき。いや、冗談じゃないというかなんというか。

私としてはちょっと興味があったので、以下から1級の試験問題のサンプルを実際ダウンロードして、試験で改変する対象となるプログラムの設計書とコードを読んでみました。

SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指して

以下目が点。

さて、一体全体どのようにアレしてコレするとこのような話になってしまうかさっぱりわかりません…というのは嘘で、大体想像はついている。何年か前に、Javaの現場に颯爽と現れた「配列の添字を１から始めるプログラマー」ような人向けの資格である。間違いない。つまり、COBOLが出来ればJavaも出来るということを客観的に証明してあげるための資格なのだ！なんて恐ろしい…

冗談はさておき。いや、冗談じゃないというかなんというか。

いやね、僕もCやってJavaやって、それなりに長いけど、次に他の言語になって困らないように、少なくとも言語の特徴と重要な概念くらいは頭の片隅に入れておいて、いざ使うことになったらちゃんと勉強する、と言う風にはしているんだけどね。

SIerでやっている人がよく言うのは「言語は関係ない。業務要件さえ理解できてればなんとかなる」。確かに間違っちゃいない。業務プログラムの大半は業務要件を如何に実現するかであり、業務要件をきちんと理解できたら出来ちゃったようなものだ。ただし、方法論をちゃんと後ろに抱えている限り。方法論ってのは一朝一夕で身につくものでもないし。やりゃあなんだって出来ます！って言って自爆しているSIerを何度見たことか。

まあね、僕も言語は関係ないって思うよ。業務プログラマーが知らなければならない部分ってものすごいコアな部分ではないしね。コンパイラ書けなくてもVM作れなくてもやっていける。

でもさ、やっぱりその言語がなぜその言語なのかをわかってないとどうにもこうにもならないと思うんだよね。

それは言語に限らない。データ構造だってそう。「XMLは重たいから負荷に耐えられない。平電文で行きましょう」ってね。そして、電文ごとのコピー句をみんなで共有するのである。XMLしか選択肢はないのかって。

まあね、言語は関係ないし、何とかなる。それ相応の努力を伴えば。JavaでCOBOLの真似事をして「ほら、なんとかなっただろ？」ってドヤ顔するような人はいずれ滅び去るのである。そしたらこの業界も適正人数になってよいかな。どうかな。