岡崎図書館事件について（再）
以前、岡崎図書館事件などの部分をお引っ越しをしたのですが、イロイロあってそこで書くのを止めてしまいまして、こちらへ復活させようと思ったらログが残っていなかった（苦笑）。
しかし、魚拓を採ってくれていた人がいたようで偶然見つけました。私がなくしてしまったぐらいなのに、ありがたい話だな〜。まあ、コアになる部分なので魚拓から復活させておきます。
事件については、ベンダーは契約上は問題のない仕事をしているのに、それを警察が「バグ（つまり、契約上のアクセス条件などが間違っている）でしょう」と言えば、警察という国家権力が民間の仕事を止めることになる。そんな権力を警察に与えられるわけがない（民事不介入の原則）し、被害届が出て、被害と行為の因果関係がはっきりしているのに「無視せよ」というのも無茶な話でしょう。推定無罪は裁判の話で、捜査当局としては「疑い」があれば逮捕して調べるのは当然の仕事です。
つまり、警察の問題じゃなく、IT業界として「被害届がでる事態になったこと」が問題なのです。
結果的には朝日新聞が報道してくれた。「新聞沙汰」なんてサラリーマンとしては、死ぬのと同じぐらい重い意味があるから、まあ、お堅いSIer系の方にも、バグと認めなかったために顧客が被害届を出すなどに至れば、部長級以上が左遷や馘になったり、場合によっては事業部がなくなったり、会社が潰れる、というぐらいの認識を持つことになったでしょう。
業界として認識を持てばクロールに限らず未知の問題にも効果があって、警察は関係なくこんな事件は起きない。
事件を知ったとき頭に血が上って５大一般紙にメールを送ったが、レスポンスがあったのは朝日新聞の神田記者だけでした。何度か電話して頂いて真摯な対応だった。最終的に思った以上に大きく、詳細に報道して貰えて感謝です。
SQLも同じ
私がSQL以外にも、エクセル方眼紙から、解雇規制撤廃、岡崎図書館事件、放射能怖い病などなどイロイロ書いてきたのは、どれも根っこは同じで、もう一段、二段、深く考えれば「直感的に感じた印象」とは違う答えが出てくるものだから。
岡崎図書館事件では、直感的には「警察は何しよるんじゃ〜」という感情が出るのは仕方がない。私も「ベンダーの話を聴かないで警察が判断したに違いない」と直感的に考え、感情的に「警察は許せん！」と思ったからね。しかし、ベンダーと相談していたなら警察の責任など問いようがない。「注意で許しといたってぇ〜な〜」と言ったところで駐禁切られて文句を言ってるのと変わらない。直感的に警察がおかしいと思っても、そこで止まってはダメなのです。
SQLも同じで「何か変な言語」って感じるのも「増強しにくいデータベースサーバに負荷を掛けないため、できる限りSQLは使わない」というのも、直感的にはそう感じるでしょう。
しかし、それは「大地は平らだ」っていうのとかわらないのです。
ちょっと考えれば「大地は平らだ」というのも「できる限りSQLは使わない」というのも、すぐにおかしいと分かる極めてレベルの低い問題です。しかし「ちょっと」すら、考えもしない技術者と呼べんカスの連中が私の所には大挙して絡んで来る。バカでも数には勝てないし、考えもしないで天動説を唱えてくるバカと議論などしようがない。
私は考えずに惰性で話している連中が生理的に嫌いで、相手が考えてない以上、議論になんかならないから感情的な対応になってしまうが、私が考えずに感情的になっているんじゃない。落ち着いて話ししようが「天動説」は「天動説」でしかなく、そのレベルの低すぎる話が出た時点で議論は止めて「もうちょっと考えろよ！」って怒っているだけの話なのです。
まあ、効率の問題ということでは、右折を禁止しているタクシー会社と同じ。運転技術がペーパードライバーレベルなら右折を禁止した方が良いかも知れないし、コストを考えなければ、右折を禁止しても、大概、目的地に着くルートはあるでしょう。しかし、プロが言うことではない。
右折なしで目的地にたどり着くルートを探す技術を鍛えるより、右折できるようになるのはプロのタクシードライバーとして当たり前のことでしょう。もちろん、右折レーンが猛烈に混む場所を把握しておいて、そこを避けて早く着くルートを出すのは本当のプロの仕事ですけどね。
JOINなんて前の初級シスアドレベルですから、自動車で言えば二種免許（普通免許の上のタクシードライバーになれる免許）以下です。右折をJOIN、タクシードライバーなどをIT技術者などにそれぞれ変えてみれば、どれだけ馬鹿げていることを言ってるのか分かるでしょう。それを真顔で言うどころか、自慢するバカまでいるんだから……。
O/Rマッパとかその類いの技術やツールって「こんなに効率的に右折を避けるルートが作れますよ！」ってことを言ってるのですけれど、そんなことを自慢するタクシーに当たったら「右へ曲がれや！ボケ！！」って、誰でも怒るんじゃないかな？出来ないから逃げる。逃げるための技術を鍛えるというのは、スタートラインの考え方からしてどこかおかしい。
一方、システムを作るのに必要な技術はSQLだけではないのだから、SQLができなくても他の言語が出来る人は必要です。そういう人が苦手なSQLをやらないですむようにする。逃げるのではなく担当分野を分けて、お互いプロとしてせめぎ合い、高め合えばいいでしょう。担当を分けることで、ウォーターフォールの呪縛からも逃れることが出来る。
しかし、既に一部の人達（技術者とは認めん）は文化として無批判に受け入れてしまっているから「俺たちはこれで結果を出してきた」「それでもシステムはできる」とか思うでしょう。それは「右折しないで目的地にたどり着く」って言ってるのと同じで（そりゃいつかは着くって……）、ベースになる感覚（理論や理屈の手前の段階）で狂っているので、視点が違いすぎて議論になるわけないのです。
それでも、罵りながらも、相手をひとかどの技術者と見てきたから議論も試みてきたし、腹も立ったりもしたのですが……。
「増強しにくいデータベースサーバの負荷を抑えるために、効率的にSQLを使いきらなければいけない」ということがよく理解できないというのは、COBOLをやってなくてもCOBOLerだからです。COBOLの経験はないだろうけれど、COBOLerのDNAを正しく引き継いでしまっていることに気づいた方がいい。詳しくはこちら→ http://d.hatena.ne.jp/Sikushima/20110815
とにかく、RDBMSを使うならば、増強しにくいデータベースサーバの負荷を抑えるために、効率的にSQLを使いきらなければいけない。でも、今日もカス共が、「増強しにくいデータベースサーバに負荷を掛けないため、できる限りSQLは使わない」って言ってるんだろう。頭に「自分たちはSQLのスキルがない（右折したら事故るレベルの）カスだから」を付けているならその通りですけどね。
2000年問題（Y2K）なんて、みんな分かっていたけれど、騒ぎになる外圧がなければ簡単には変更できなかった。「DBサーバに考えさせない」というのは、同じぐらい間違っているけれど、それに気づいたとしても、過去の自分や、上司や、会社の成功事例を全否定することになるので簡単には変えれないでしょう。しかしそれは、よく批判される前例主義の官僚と同じ構造で「理屈で技術的な答えが出るのに」分かっていて技術者としてやるのなら、カスとかクソとか言われても仕方ないでしょうが。
余談ですが、もちろん、サーバの負荷を考えたら、データベースとアプリケーションサーバが同居しているようなケースでは、SQLを使いきらないと指数的にサーバの負荷は高まる。そういう小さなシステムほどSQLを使わない傾向が強いよね。そして、ほんの僅かにアクセスが増えただけでパンクしていたり……。１台のサーバでデータベースとアプリケーションサーバを兼ねる方がシビアな設計が必要なのですけどね（苦笑）。
以下、http://megalodon.jp/2010-0714-2025-14/d.hatena.ne.jp/Sikushima/20100710 からの再録です。
