SIer、SEとして、仕事は基本的にデータのやり取りとなります。そして、そのデータのやり取りをする場合はSQLと言うものを使います。
SQLと言うのはデータベースとやり取りする一種の言語のような物です。
例えば、人事ＤＢと言うテーブルがあって、そこからデータを抜きたい場合に、
SELECT 社員番号 FROM 人事DB WHERE 性別=‘男’
みたいに書いたりします。この場合は、男性の社員の社員番号が欲しいと言う場合のSQL文になります。
このような場合はテーブルも一つで簡単なので、例としては分かりやすいですね。
その中で、「人事DBから人事データをもってきて欲しい、対象は今までの入社年で一番人数が多かった年、そして、さらにまだ退職していない人、その人の今までの部署の遍歴を見たい。」なんてリクエストがあったりしたりしたとします。
さすがに最初は「うーん」と思います。
結局、プログラム100行書いて、その中でSQL文を2〜3回呼ぶ、見たいなプログラムになるのが一般的です。
でも、どの業界にも「職人」が居るように、このSQL業界にも「職人」はいるのです。
職人の手に手にかかればこれらの検索も1行のSQL文に出来たりします。
素晴らしい効率化！性能もアップです！スピードも全然違います！
…でも、問題があるのです。
SQL文の特性でもあるのですが、とにかく、この命令文って複雑なんです。
「ここをこう変えて下さい。」と言うリクエストに作った職人も「もうわからない！」ってなる事もあります。
今の例で言うと、「入社年で一番人数が少ない年度で退職していない人。」に変えてくれと言うリクエストがあったりしたとします。
ある程度、通常のプログラム＋検索（SQL）だと修正も簡単かもしれません。
でも、一行で作られたSQLの場合、作った人でないエンジニアが見たら、「何やってるのこれ？」状態も珍しくありません。
と、SQL文と言うのは職人の手にかかれば最高のチューニングをしてくれますが、職人にフレキシブルさを求めては行けません。
ある程度、「誰でもわかるSQL」を面倒くさくても数回繰り返した方が保守性が高かったりするのです。
なーんて、仕事の話ですけれど、業界の人は「うんうん」って分かってくれると思います。
ちなみに、僕は15年前位は生粋のSQL職人でしたが、今では足を洗い（？）、誰でもわかるSQLを書くようにしています。
技術は大切。技術に対価が必要と言う大きなテーマの第一歩として、「とは言っても、作った本人もわからないような命令を書くのは『策士、策に落ちる』だよ。」と言う事から考えてみました。
このお仕事シリーズ（「SIer業界あるある」）、まだ続きます。
