アプリ基盤的勘所を押さえた技術者の不足

いや、これはひどいｗｗｗ

Rockだ。Rock過ぎる。DBろけんろーる。統計情報の自動更新が止められていた為、最後の統計取得履歴は半年以上前になっていたが、もうそんなことは枝葉の問題として切り捨ててしまいたくなるくらいのRockっぷりである。

どうも世間では、思ったよりDBエンジニアが不足している様だ: 不倒城

まあどうRockかはリンク先を見てくれたまへ。
でもって、これってアプリケーションプログラミングの問題でもあるんだけど、それ以上に「コンピューターはどうやって動くのか」的な勘所を押さえてなさ過ぎることに起因する問題でもある。
特に近年の業務アプリケーションはコア部分のブラックボックス化が進んで(と言っても、ちゃんと勉強は出来る。しなくても業務アプリが作れるから見ない人が増えた)、テンプレどおりに作れば仕事になる、という状況ですから、個人のノウハウの蓄積がされにくくなっています。ちょっとした規模のプロジェクトばかりやっていたアプリ屋さんでJVMの設定値とか考えて決めた経験がある人ってどのくらいの割合いるのでしょうか。out of memoryが出たら右往左往。何で出るんですか？そりゃヒープ使いすぎだからだよ！ヒープって何ですか？orz。
DBの話をすると、僕がやってきたプロジェクトでは、大体DB基盤チームとして専門知識のある人が揃っていて、適切なIndex張ったり、適切にパフォーマンスを保つための運用をしたし、アプリケーションの性能テストでパフォーマンス分析もしてたし、explainして不要なフルスキャンは潰すし、そんなのが普通だと思っていたけど、一社がなんでもやるこじんまりしたプロジェクトだとそうでもないんだよね。
まあこれも基盤とアプリの境目にある仕事ですね。そのあたりのスキルちゃんと持っている人は少ない。境目のところは仕方がないとしても、完全にアプリケーションに属する部分があまりにダメなのは困る。SQL書けます！って言ってやってきた人がなぞのクロス結合とかし始めたらそりゃ問題だよ。
DBエンジニアが不足しているというよりは、DBエンジニアの必要性が理解されてない(SQLかけるプログラマがいればDBは動く、みたいな)からだとは思うけれども(現に理解がある現場ではここまでの自体が起きるわけもない。はじめからDBエンジニアがいるから)。その点を除いても、リンク先の問題はひどい。業務アプリケーションと言っても、SQL(に限らずDBを触る言語)はパフォーマンスをかなり意識すべきという大前提があるものだと僕は思うけれども、世の中全然そうじゃないんだよね。
前にも書いたソフトウェアエンジニアリングとかコンピューターサイエンスへの無知という問題もある。そもそも、DBにまつわるアプリケーションの問題の大半は、ノウハウが蓄積されていて、テンプレ化されているようなものだと思うんだけどね。特にOracleだったら。
アプリケーションだって、ソート済みの配列を全量マッチングしてみたりとかそういうロジックは良く見かける。SQLはたまたまデータ量が多くてパフォーマンスの問題が見えやすいだけだったりする。
なんでも知って、何でも出来るようになってくれとは言わないまでも、どういう仕掛けになっていて、どうすれば効率が良くなるのかということはちゃんと考えてほしいと思う。
最近、あるJava案件の提案に乗っかっていたパッケージのようなものの仕様を調べてみたら、昔のHOSTのパッケージと仕様がそっくりだったことがありました。それって古くてダサいというわけではない。実現したいことが一緒なら基本的な設計は言語が変わっても変わらないということだよね。もちろん、もともとの設計が美しくないとダメなんだけど。そういう風に、過去のものから学べることは沢山ある。DB重くて業務にならないって時に知識の不足を外部から補って、最善の手を打つことを考えることが出来るエンジニアにみんななってほしいなあ。