SQLと手続き型プログラム言語での綱引きの顛末
去年の夏より、弊社は関西では割と大きな案件に携わらせていただいていました。元請はお堅い会社でしたが、PMが「技術的な面は任せます」といってくれたため、わたしとしては大赤字の単価で請けました。
任された以上、わたしはもちろんロジックをストアドプロシージャに詰め込むよう準備を進めていました。わたしは自社の利益よりも、大きな案件での成功実績を作りたかったわけです。
ところが、要件定義、基本設計と進むにつれ、大手の社内事情もあってか、東京からPM補佐だか何だかといった肩書きで、何も分かってない落下傘部隊がやってきます。また、コンピテンスセンターなどという大仰な肩書きの方がやってきて、技術指導をしてくれるわけです。
しかし、コンピテンスセンターの方が作られたSQLのコーディング規約は、「Existsは読めなくなるのでInで書き直すように検討すること」とか、「SQLのヒントは可読性が落ちるので使わないこと」など、それを読むだけでレベルが分かるものでした。SQLにおいては、わたしが高校生レベル以下といつもいっているレベルです。
わたしなど想像もつかないコンピテンツな技術です……。
SQLのコーディング規約を見た瞬間に暗澹（あんたん）たる気持ちになりましたが、案の定、東京から来たPM補佐だかの肩書きの人を先頭として、コンピテンツな技術を持つ方々であろう人たちといらっしゃって、綱引きが始まります。大阪にいる技術者はきちんと技術が分かっていたから、当初はわたしの話が通っていたのですが、まったくおかしな話です。東京ってそんなにレベルが低いんでしょうか？ あの会社だけの話だと思うけれど。
いずれにしても、議論しようにも相手の方が立場が強く、かつ技術レベルが高校生以下であるために議論が成り立ちません。
コーディング規約から分かるレベル感のとおり、コンピテンスセンターが手がけた案件で、過去にストアドプロシージャを全面に使ってDBサーバをパンクさせた案件があるようで。その原因がストアドプロシージャにあると信じておられるようで、今回もストアドプロシージャを使うことに大変な嫌悪感を示されます。かの会社のコンピテンツな技術では「原因調査はしないで、分からないもののせいにすればいい」とでも考えているのでしょうか。「ストアドプロシージャは全体の15％以内に抑えること」などという、何の根拠があるのか分からない通達でストアドプロシージャの使用をつぶされてしまいました。コンピテンツな技術を持っている技術者？に原因を質問しても、「とにかく15％以内で」という、とても技術者とはいえない素人レベルの主張しか返ってこないので議論にはならないしね……。
もちろん、当初PMから技術面は任せるといわれていたから、こっちはそんな条件では見積もってないため大変な状態になりました。
確かに、ストアドプロシージャを使ってDBサーバがパンクするというパターンは存在します。
SELECT系のストアドプロシージャで、ワークテーブルにデータを作り、外側の言語でSELECTし直すパターンです。過去に、ワークテーブルの数が3000個以上というプロジェクトを見たことがありますし、「ストアドプロシージャで作るべき」と主張してきましたが、その反論として「そんなことをしたらワークテーブルが増えて大変」という反論が割と多く寄せられることからも、決して少なくない構成なのだろうし、パンクした案件も同じ構造ではないのかと予想はしております。
この構造は、SELECTする度にINSERT処理が走るということになり、通常の構造の何倍もDBサーバに負荷をかけることになります。一時テーブルであればまだましですけれど、「実テーブルにデータが入ることでデバッグがやりやすい」と、開発効率をかなり誤った方向に評価して採用する人も多くいるようです。REDOログまで出力してたり、もう、ものすごい負荷です。
そんなレベルと同じにして欲しくはないのだが……。
こういう構造を見ることが少なくないのは、OracleがRDB市場の大きなシェアを獲り、OracleではSELECT系のストアドプロシージャが非常に書きにくいことに由来しているのではないかと思います。Oracleが汎用機からのダウンサイジングに対して果たした役割は決して小さくないですが、SELECT系のストアドプロシージャが書きにくいということと、WHERE句に結合条件を書くということは、業界にとって非常にマイナスだったのではないでしょうか。
SELECT系のストアドプロシージャが簡単に書けるSQL Serverが、先にもっと大きなシェアを獲っていたらこんな事態にはなっていなかったと思うのですが……。
件（くだん）のPM補佐とかいう方は、結果的にPMの座を乗っ取りました。まぁ、見事な政治力というところだけれど「ただ、乗っ取りたかっただけ」としか思えません。
実際の現場では、技術力より政治力でことが動くのはある程度仕方がない。しかし、せめて技術的な会話が成りたつレベルの人間が出てきてほしい。
まぁ、過去の失敗を「ストアドプロシージャで作ったため」というオチにしてしまったため、「今回ストアドプロシージャの採用を認めるためには、過去の過ちをもう一度暴かねばならない」という事情があったのは分かるけれど、それはうちには関係ない事情だし、完全に顧客に迷惑を掛けているし……。
なんにしても、わたしも愚痴っているだけで先はない。いまはインターネットの時代です。こうやって恥も含め発信することで、業界を変えたいという努力は続けたいです。
コメント
evergreen
お疲れさまです。
まだ目の前で政治力を見られるならいいのだろうと思いますよ。
頭の上を政治力が飛び交い、いろいろ決まっていく。
相手の担当との関係は悪くなるばかりという状況もありますからね。
で、以前お話した話ですよ。
スキル・コミニュケーションといったところで、
正等に評価される事、
正等に発揮される事、
がどれだけあるの？という話です。
幻想だと思いません？
スキルやコミニュケーションじゃない価値観で物をみないと、
「この人は正直に話してくれる」とか「正しい提案をしてくれる」とか・・・
何も変わらないのだと思っています。
evergreenさん、こんばんは。
政治力というのは、上から下まであります。
下の方では先輩・後輩とかね。
その簡単な時代に大いに鍛えておかないといけないですね。
元請け、下請け、孫請けというのは、技術者レベルでは、技術力でひっくり返せたりするのですけれど、経営レベルではなかなかひっくり返らない。難しい問題なのですわ。
evergreen
可笑しいですね。
経営レベルの政治力とは資金力や力関係ですよね。
同じ土俵にいる限りは絶対にひっくり返らないと思いませんか？
「極論すれば」生死を握られていては、
スキルもコミニュケーションも無意味ですね。
せいぜい自分の立場をよくする事しか出来ませんよね。
生島さんはそれでも、「生き残る」スキルが必要というでしょうね。
でもそれは、今それをしているか、過去それをしていたかの違いなんですよ。
evergreenさん、こんばんは。
経営レベルでは絶対にひっくり返りませんよ。
そう書いたつもりですけれど。
技術者レベルでは、孫請けでも、元請けの技術者をボロカスにしごくのはあります。
まぁ、それも大半は依頼されてやるのですけれど（苦笑）
evergreen
私の用法では「なかなか」を「絶対」と理解する事ができませんでした。
言葉尻を捕まえる気は全くありません。
ただ、この業界の硬直と政治力に対する憤りと、
業界を変えなければならないという思いは、
形は違えど共有しているとかなと思いましたので、書き込みさせていただいた次第です。
ヤス
生島さん
なるほど。そういう現場もあるんですね。
うちの会社なんかは逆にETLなんかを使っていても、「遅いからプロシージャを作って埋め込んでしまえ」う指示が飛んでくるので、どこでもそんなものだと思っていました。
SQL等を使わない場合は明らかにプロシージャよりも処理が早い場合やRDB向きじゃない作業などは外部プログラムという感じでしょうか。
実際DBのスペックををフルに使うんだったらSQLが早いのは明らかだと思うんですけどねぇ。やっぱり、プログラムの歴史と比べると浅いし、プログラマ系の人がDBをあつかっている時間が割と長かったというのが現状の原因なんですかね。
SES
グーグルや本がないと仕事が出来ない人は、弊社では仕事が出来ない人と同じランクになる。
生島氏は常々、記憶力はグーグルに、というが、業務であってもネットは一歳禁止の会社など多数ある。
理解していれば、グーグルは必要ない。
体で覚えてしまうからだ。
そしてそのレベルにまでいけば、資格を取ることに学習は必要ない。
資格を取るのに学習が必要という先入観から抜け出せていないところから見ても、
技術者としてのレベルが伺える。
初音玲
SELECT系のストアドの失敗分析の結果が「ストアドを使ったため」という理由で通ってしまってる時点でアウトな気がします。
変なストアド書いた部門なり本人に分析させているので、
「ワークテーブルをむやみに作ってしまったためであり、○○のときは○○という機能を使うようにしてワークテーブルを使わないSELECT系ストアドを作成すべきだった。」
のような分析結果が出てこないでしょうね。
kim
いつも拝見させて頂いております、kimです。（Twitterも拝見してますよ）
私もOracleのSELECT系ストアドの面倒臭さに嫌気を感じています。
その面倒臭さから過去のプロジェクトで、
例えば
・売上履歴
・入金履歴
・請求履歴
を一画面で出力したいときは、ストアドで
一時表(Global Temporary Table)へinsertした方が
開発生産性と保守性が向上する。
そう自分を信じ、周囲を何とか啓蒙し、運よく安定稼働している感じです。
しかし今思えば、
・ピーク時の同時実行数が多くても２０くらいしかない。
・ストレージがちょっと高級（４００万円）。
・とりあえず一時表領域グループを複数作成しておいた。
という偶然の一致で何とか動いているのでしょう。
大規模基幹システムでは、きっとグダグダなシステムになっていたと思います。
AC/DC
関係ないけど、生島さんがみながわけんじさんを、twitterで擁護したってホント？
どこに擁護すべき点があったのかすっごく疑問なんだけど。
へぼＰＧ
元請け技術力無いですね。○ＴＴデータか○立あたりですよね？
○士通とかならそんなことはないと思いますよ。良くも悪くも仕様さえ満たせば、結構自由に組ませてくれます。
AC/DC
> ○士通とかならそんなことはないと思いますよ。良くも悪くも仕様さえ満たせば、結構自由に組ませてくれます。
そうすか？
前に○士ソフトＡ○Ｃが元請けさんだったとき、最初の打ち合わせで「で、ステップ数はどれぐらいになります？」って訊かれて凝固したよ。
ステップ数だよ。今どき。
おまけにテストの成果物の中に「バグ出現率表」みたいなのが含まれてたときには、またまた凝固したよ。
へぼＰＧ
Ａ○Ｃは典型的なブラックだろうという話は置いておいて、
ステップ数はともかく、バグ出現率表みたいのは正しい。
プログラマ個人の技術力に起因するバグか、糞仕様、糞設計によるものか程度の要因分析は必要。
分析する材料がろくにないと適切な対策が立てられない。
へぼＰＧ
SESさんの5/2のコメントについて
残念な発言が多すぎる‥
>グーグルや本がないと仕事が出来ない人は、弊社では仕事が出来ない人と同じランクになる。
>生島氏は常々、記憶力はグーグルに、というが、業務であってもネットは一歳禁止の会社など多数ある。
>理解していれば、グーグルは必要ない。
OS、言語、DBMSには必ずバグがあるから、グーグルなんかの情報源は有用。情弱という言葉を知らないようで‥
>>資格を取ることに学習は必要ない。
資格試験の問題が適切に実力を測れる良問ならそうかもしれないが、実際は、奇門、悪問といったものが数多く存在する。
国立大学は独学でも受かるが、有名私立は予備校に行ってないと受からなかったりするのと一緒。試験のための問題というのは癖があり、ある程度の学習は必要。
皆さん、こんばんは。
えーと。どこの会社はおいておいて、とにかくストアドプロシージャを使いこなせない人はたくさんいますね。私はOracleが誤った方向へ連れて行ってしまったと思っています。それをなんとかしたいと作戦を練っているところです。
みながわさんについては、社内SEと職業SEでは求められるモノが違うということです。（ケンカ売っちゃったのは、売り言葉に買い言葉だろうね）
みながわさんみたいな上司の下に社内SEとして入ったらどうするか。
技術はあきらめたらいい。
社内SEというのは現場で企画に関わることが出来る。そっちのスキルの方が価値がある。
資格云々については、何だかな～。まぁ、どうでもいいのですけれど、私は金融出身ですので繋がらない環境にもいてましたし、ソースはPCのスペックが低すぎてエディタで書いていた世代だし。個人的には、ぶっちゃけ繋がらない環境の方が生産性は高いでしょうね。遊べなくなるから（笑）
それはともかく、インターネットに繋がらない環境というのは、どれぐらいあるのでしょうね。金融系では、まだあるみたいだけれど、よほどネットワーク管理者の能力が低いんだろうな～。そこについての改善提案を出した方がいいんじゃないの。
AC/DC
>ステップ数はともかく、バグ出現率表みたいのは正しい。
>プログラマ個人の技術力に起因するバグか、糞仕様、糞設計によるものか程度の要因分析は必要。
いらないよ、そんな表。
いや、要因分析は必要だけど、バグ出現率表なんて何の役にも立たないし、人的リソースの無駄遣いでしかない。
その表を求めたのは○士ソフトＡ○Ｃの営業の人だったんだけど、後でエンジニアの人が「どうせ誰も見ないから適当に数字でっちあげてＯＫＯＫ」って言ってた。
oumi
皆様お分かりとは思いますが・・・
F通と○士ソフトＡ○Ｃとは、全く関係の無い企業です。よろしくお願いします。