ベンチャー社長で技術者で

　あけましておめでとうございます。昨年はたくさんの方にアクセスいただき、コメントいただきありがとうございました。今年こそ良い年にしたいですね。

　で、のっけからあまり良い話題ではないのですけれど、たくさんコメントいただいて「IT技術者ってなんなんだろう？」と、いまさらながら考えています。

◇　　　　◇　　　　◇　　　　◇

　たとえば、医者について考えてみましょう。

　物資がなかった頃は、注射器は普通に使いまわしていて、せっかくの医療行為が肝炎などの感染症の拡大につながるという皮肉な結果になりました。

　それでも「注射器を使いまわすこと」が感染症の原因と分かっていない時点では、当時の医者が医療行為として努力していたことは責められません。こういった、医療が進むにつれて、過去の治療方法や処置が実は間違っていたということは、数年に1つか、もしかするともっと高い確率で起こることで、未知の事象に対してベストの対応ができないのは不可抗力で、その不可抗力を恐れていては、医療の発展はないのです。

　しかし、「注射器を使いまわすこと」が感染症の原因と分かってもなお、医者側の都合で「注射器を使いまわす」ということをやっていたとしたら、普通は許せませんよね。

　わたしは、2つの視点で問題があると考えます。

　1つは、もちろん人間として、人の命に関わる問題であるということ。

　もう1つは、職業人として、本来人の健康と命を守る立場である人間が、自分の都合で結果として人の健康を損ねることになったこと。

　後者について、考えてみましょう。

◇　　　　◇　　　　◇　　　　◇

　当たり前ですが、「注射器を使いまわす」ことが危ないと分かった時点で、使いまわしてはいけない。分かった時点というのは微妙です。初めての論文が学会で発表された時点かもしれませんし、多くの事例が紹介された時点かも知れません。

　一般に知られていなかっても、看護士学校の教科書に出てくるぐらいの常識になった時点で「注射器を使いまわすこと」をやったら、犯罪者として起訴される可能性があり、今現在「注射器を使いまわすこと」をやったら完全な犯罪者です。

　医者には、基本的な医療技術の他に、患者やその家族の不安を取り除くことも非常に重要なスキルです。つまり、僧侶や牧師に匹敵するような高いコミュニケーション能力というよりも、カウンセリング能力も必要です。

　しかし、僧侶や牧師やカウンセラーではなく、医者ならば、それらは必要であっても補助的な能力で（補助的だからカウンセラーを雇う病院はたくさんある）、最低限必須な能力は医療技術でしょう。

　逆に、もし自分は普通の医者よりカウンセリング能力が高いから、「注射器を使いまわしても、患者を満足させられるからよい」と考える医者が存在するとしたら本当に怖いですよね。カウンセリング能力が高いだけに、患者側は信じてしまいますから。

　患者側が、医者が間違っていると気づくのは非常に難しいことです。患者側がおかしいと思っても、医者が間違っていることを証明することは、素人である患者には非常に難しいことです。証明しにくいことだから、非常に多くの規制や法律で、医療を監視する体制を作ってきました。それでも、同じような馬鹿みたいな犯罪医療行為は行われていて、先日も、不潔な環境でレーシック手術をして失明させるなんていうとんでもない事件がありましたね。

◇　　　　◇　　　　◇　　　　◇

　IT技術者は命に関わるような仕事をやってないかもしれませんし、医療に比べれば規制や法律もほとんどありませんし、監査されることも多くはないのです。だから、何をしても良いわけではない。「分からない顧客を満足させるから」は、あるレベルから許されないとわたしは考えています。

　ユーザーインターフェイスのデザインセンスも、カラーコーディネートも、コミュニケーション能力も、マネージメント能力も、その他もろもろの能力が必要であったとしても最低限必要で、最重要なのは「ITの技術力」なのです。

　命に関わるような仕事でなくても、職業人としての責任は医者と同じようにある。医者は、何のために存在しているかというと、「患者の健康と命を守る」ために存在し、IT技術者は「顧客の業務を効率的にする」ために存在するのです。

　つまり、IT技術者がまずこだわるのは効率です。それをないがしろにするのであれば、よほど大きな特殊な理由が必要です。医者が、患者の命より他のものを優先するとしたら、「尊厳死」のような特殊な問題以外あってはならないでしょう。命とトレードオフするのが「医者の都合」だったら「ふざけるな！」ってなりますよね。

　繰り返しますが、IT技術者は効率をとことん追求しなければなりません。

　患者は治る病気なのか、どのぐらいの期間で治る病気なのか分かりませんから、カウンセリング能力を駆使して誤魔化してよいなんてことはあってはならないように、IT技術者は技術力がない顧客を納得させることができたとしても、とても誉められたことではありません。

　その上、誤魔化している理由が「未経験の高校生ができるレベルのことをやりたくない」では話にならない。

　医者がカウンセリング能力が高いから、それをもって医療技術のなさを補うというのは恐ろしいでしょう？ 医者も診療をしない医院長などの管理職になるなら、マネージメント能力が高ければよいかも知れませんけれど、現場を知らない医院長がいる病院にはできればいきたくないでしょう？

　SIerも職業人として考えると同じと思うのですけれど、IT技術者は技術は要らないという人が多いし、会社の方針とするところも多い。それが正しいと堂々と主張する人が出るのが信じられないのです。せめて建前上は反対すべきじゃないかな～（苦笑）。

◇　　　　◇　　　　◇　　　　◇

　もちろん、心臓外科医に眼科医と同じ技術を求めるのは間違っているように、IT技術者も、全員に全部の能力が必要とはいわないし、次々に新しい技術が出てきますから全部を知るべきとはいわないけれど、「足切りされるべき最低限のライン」があって当然ではないでしょうか。

　医者と看護士で要求されるスキルは違いますが、被っている医療技術（知識）で医者が看護士に劣るとしたらかなり問題です。つまり「注射器を使いまわしたらいけません」ということが看護士の教科書に載るようになった時点で、それを知らない医者は、もう、資格がないといえるでしょう。

　何度も書いていますけれど、初級シスアドというのはユーザー向けの試験で、この業界を目指す高校生が毎年何千人と通るレベルです。初級シスアドの範囲と被る仕事をしているのであれば、その辺を「足切りされるべき最低限のライン」としてもよいでしょう。むしろ、低すぎるような気がしますけどね。

　技術の移り変わりが激しい業界ですから、気づいたら「足切りされるレベルになっていた」ということはあるでしょう。それは気づいた時点で技術力を付ければ済む話ですから、今現在スキルがないということは責めたりしません。

　問題は、「そのレベルになくてもプロである」と開き直って主張する人が出ることです。そんな人間を「技術者じゃない」と断定しても何の問題もないと考えます。

　そういう人は、わたしには注射器の使い回しが危険なことを知りながらやる医者と同じにしか見えないのです。確信犯ですからつい罵倒してしまう。

　とにかく、IT技術者を名乗るなら「効率」を軽視することはあってはならない。初級シスアドレベルの技術を避けるために「効率」を軽視するというのは、ど～う考えてもおかしいです。

　わたしはSQLにこだわってるのではなく、「効率」にこだわっていて、RDBMSを使うのにSQLを十分に使わなかったら非常に非効率である。1年間そんなことばっかり書いていましたが、RDBMSを使っても「こうすればSQLを使うより効率的」。というまっとうな反論は1つもない。

　何だかな～。

◇　　　　◇　　　　◇　　　　◇

　タイトルから離れすぎ（笑）。

　イヤ、「JIN -仁-」を見ていて、まぁ、イロイロと思って書いたのですが、年末進行で投稿できなかったので大幅に書き直したのですけれど、タイトルは残させてもらいました。

　不本意にも、一部のコメントを非表示にせざるを得ないほどの状態になったのは本当に残念ですが、白熱（炎上）したのでまとめ。

　前の記事はこの辺です。

　常識のライン

　テレビのリモコンを孫の手で押すなって！

　オブジェクト指向言語で処理したら保守性が悪い！

　自分で書いた1年前のモノも読み直してみると、これらとほとんど同じことを延々書いている。まぁ、10年前から同じことを言ってるし、成長がないな～。

　一応、なぜ炎上したかというと、そもそもの「常識のライン」が合わない人がやってきたためです。初級シスアドというのは毎年1000人以上の高校生（高専や専門学校を入れたら10代の合格者は毎年数千人）が合格してきたぐらいのレベルの試験です。高校時代に合格するのは相当に努力とセンスが必要でしょうが、合格したら即プロというレベルでもない。

　そんな「初級シスアドレベル（以下）でも自分はプロだ」と言い切る人が出現したのが、炎上のきっかけです。

　■ 反対派の意見

　（RDBMSは使っているのに）SQLはできなくてもシステムは組めるからプロだ。でも、「複雑で遅いときにはSQLを使う」

※ 特に、こういうことをいう人の「遅いときにはSQL」のSQLは　素人レベルですから、とても読めたモノではない。これが混じると本当に保守できなくなるのですけどね……。

　■ わたしの意見

　RDBMSを使うならばSQLを使わないと無駄が多い。スキルを身に付ければ最終的には、コーディング量 ＝ 工数（保守性）となっていくので、少ないコーディング量ですむSQLの方が工数・保守性ともにメリットがある。

　2つの意見のうち、そもそも、「システムが組める」と「メリットがある」は、まったく争点が違いますね。

　後者は「どちらにメリットがあるか」、つまり、「どっちを選ぶべきか」ということを議題としているのですが、前者は「できるできない」に矮小化されています。さらに、その業界を志す高校生に自分の飯の種で負けても自分はプロであると堂々という人間が出るなんて……、100年に1人の天才石川遼選手に負けるのとはわけが違う。他所の業界ではあり得ないでしょう。

　初級シスアドって、合格率や合格者数から考えると、簿記2級かちょっと上ぐらいの難易度かな。つまり、「なんでSQL」というのは、「なんで複式簿記」というのと同じです。

　単式簿記はお小遣い帳と同じだから理解しやすいけれど、経理部に配属になって「仕訳なんてややこしいことしなくても、単式簿記でできるじゃないですか」というような、「できるできない」の議論はあり得ない。我々システム屋さんは、誰でも仕訳ができるように経理システムを作っている立場ではありますが、それでも経理部員が仕訳を分からないようでは仕事になりませんので、これは議論ではなく強制（矯正）でしょう。

　わたしの常識では、初級シスアドレベルはプロではないから、そのレベルの人にSQLについて必要なのは議論ではなく強制（矯正）です。つまり、「石に齧り付いてもスキルを身に付けるか、違う業界へ転職するかしろ！」です。

　世の中の常識に照らせば、けっして厳しい意見ではないと思います。

　しかし、業界としてそのレベルで公に反対できるほど「できなくてもよい」が常識になっています。そして高校生に負ける部分を覆い隠すために、テレビのリモコンを押すための孫の手を一生懸命作ってるのですから……本当に馬鹿げている。

　そんな馬鹿げたことが業界の常識として通用する以上、業界の内部では変えようがないので、「お客様なんとか変えてください」という情けないお願いでもあります。凝り固まった人を説得するのは外圧でないと無理です。プロを説得したいと思って書いたモノではなく、お客様はあまり見てないかもしれませんが、お客様の目に触れたらよいなと思っています。

　業界外の皆様（お客様方）、IT技術者として顧客にまで求めてきた必須といえるスキルが「わたしは高校生に負けるほどSQLは素人レベルです」と前置きすべき人達に、60～400万／人月ぐらい支払っていることに早く気づいてくださいね。

　実際問題、評価基準がユーザーにはわかりにくいから、そんな詐欺師に大金を払わざるを得なかったわけですが……、高校生も取得してきた国家試験レベルを持ち出して交渉したら、一律xx％下げてくれなんて理不尽な値引き交渉をしなくても、技術力に応じた、当たり前の交渉で一律xx％以上の値引き交渉が簡単にできますよ。お客様にいわれたら、プロとしてグウの音も出ません。

　この不況で、どうせリストラは必要なのです。ぜひ業界に巣くった詐欺師を淘汰してください。大手の数社がやってくれれば、業界はすぐに正常化できると思います。

　違う意見は重要ですけれど、素人レベルのできない人の意見というのは言い訳でしかないので、そんなものを聞いても仕方がありません。もちろん、「やったらできる」なんて意見にも、何の意味もありませんので、そのような類のコメントはよそでやってください。

　なぜ業界としてそんな事態になるかというと、「SQLを鍛えたらいいじゃないか」ということになって、実際に教育が実行されることもあったのですが、マネージャやリーダーに「SQL講座に行ってこい」と誰もいえないから、通常は残念ながら鍛える対象者が新人とか若手になります。そして、せっかく鍛えてきた人たちを、上の人間ができないために無意識でいい放った、たった一言で潰してしまいます。

　自分で潰しているのに、「鍛えてもダメだった」という結論を持っている人も多いわけです。

　その証拠に、新人に初級シスアドの取得を推奨（半ば義務づけ）しているような会社でも、納品物は初級シスアド以下になることが普通にあります。上に立つ人間が、初級シスアドに満たない技術力で設計しているので、下の人間は使いようがないのです。そして、自分で潰しているということに気づくスキルもないのですから、どうしようもありません。

　部下に複式簿記を勉強させても、単式簿記でやるように指示してたら何の意味もないですよね。つまり、上に立つ人間ができなければ何の意味もないのです。

　何度も書いているとおり、初級シスアドなんて高校生でも取ってるぐらいのものです。RDBMSは、高校生にとって他の言語を扱うよりも環境面などで遙かにハードルは高いのですが、それでも習得可能なぐらいSQLは簡単です。開発現場では、RDBMSはすぐに手の届くところにいくらでもあるのですから、上から潰さなかったら何の問題もなく習得できるはずです。

　最低限、上から潰さない程度に、上流技術者が、せめて初級シスアドをもう少し超えるレベルにSQLを習得する必要があるでしょう。

　おまけ。

　自分のプロジェクトは複数のDBベンダに対応する必要があるとか、Web系の仕事をされている方々によく絡まれます。文章をちゃんと読めば分かりますが、条件が違うならプロなんだから自分で判断すればいい。わたしは散々書いてきているのでいちいち前置きはしない。過去のを読んでください。

　Web系にもイロイロな仕組みがあります。弊社は静的なHTMLだけの仕事までやりますし、EC-CUBEなどのカスタマイズも手がけています。わたしも起業したきっかけは、http://el.jibun.atmarkit.co.jp/g1sys/2009/07/post-e118.html のように業務システムとはまったく関係ないことで、Web系システムが嫌いかというと、むしろそちらの方がやりたいことであったりもします（基幹システムをWeb系で作るのは大嫌いですが）。そのような仕事しかやらない人達は、自分たちはメインストリームにいるつもりかもしれません。

　しかし、（コンシューマ向けの）Web系は増えてはいますけれど、まだまだ、割合から見ても決してメインじゃないのですよ。日本の上場企業は約4000社ありますが、Web系（広告費除く）のシステムに投下した資本と、基幹システム、情報系システムなどなどに投下した資本って、今後も逆転するという会社はほとんどないし、中小企業に至ってはさらに顕著です。

　そんなマイナーな話をしても仕方がない。ですから、マイナーな人はご自身で判断してください。

　例えば、Yahooのようなポータルサイトを手がける会社にしても、人事システムも、物流に関するシステムも、経理システムも必要です。そういう業務には圧倒的にRDBMSを使った仕組みが現状では向いています。そういう分野のためにほとんどの企業でRDBMSはすでに導入済みですから、そう簡単にはSQLの需要というのはなくならないのです。

　どちらが汎用的で息が長い技術かは、よく考えた方がよいと思います。

　O/Rマッパーのようなもので覆い隠すようなモノにまったく価値はない。O/Rマッパーは、それなりのセンスがあれば、コメント欄でも書いていらっしゃる方があるとおり、言語を覚えたての頃に一回は企画するレベルのものです。かくいうわたしも企画はしましたから使いたくなる気持ちも若干は分かっています。そんなモノは麻疹（はしか）みたいなものです。まっとうなスキルをつけてSQLの意味が分かれば、O/Rマッパーなど、孫の手の開発でしかないと分かり、麻疹の時期は去っていきます。

　当たり前の話ですが、SQLは現在流通している中では、最も人間に近い高水準言語で、それを低水準言語でラップしても意味がない。

　SQLをやらない人にとっては、何が当たり前で、どう高水準かも分からないでしょうけれど、それが分かるまでに必要なのは議論じゃなくて勉強ですよ。

　それでも、これだけ一般的に使われているモノを拒否する気概があるなら、それはそれで立派なものですが、「SQLを使わない」ではなく、「RDBMSを使わない」とならないと意味がないのです。O/Rマッパーのような孫の手を目指すよりも（作るのではなく使うって……）、テレビそのものであるRDBMSに代わるものを開発すべきでしょう。それが技術者ってものです。

　もちろん、別のモノを開発するほどSQLに不便を感じないので、わたしにはそんなモチベーションは生まれないけどね。

　弊社でやっているSQL講座の最初の方でお話しする内容です。

　どれぐらいの人が試すのかな……、知ってる人にとっては極めて当たり前のことですけれど、知らない人は、けっこうびっくりする人もいるので、実際にやってみることを強くおすすめします。（できないという人はセミナーに来なはれ）

　では、ちょっとしたサンプルを作るか、それなりにデータ量のある既存のテーブルのインデックスを張ったカラムに対して、以下のSQLの実行計画を取ってみてください。

　【注意事項】

　実行計画を取る前に、Oracleは一応、アナライズをしておいてください。SQLServerは主キー以外のインデックスがある列を使うこと。

　【準備】

　SELECT
　　　　MIN（カラム）
　　　　, MAX（カラム）
　FROM テーブル

　※ サブクエリーではわかりにくくなるので、最小値と最大値を控えておいてください。

　【実行計画を取る】

　※ 詳細なやり方を知らない人はググってくださいな。

1. 　SELECT * FROM テーブル
   　　　WHERE カラム BETWEEN 最小値 AND 最大値／１０
   　　　※ シーケンシャルでないときは10％ぐらいの範囲にする
2. 　SELECT * FROM テーブル
   　　　WHERE カラム BETWEEN 最小値 AND 最大値／４
   　　　※ シーケンシャルでないときは25％ぐらいの範囲にする

　結果は、呼び方はRDBMSのベンダー毎に違うと思いますが、

1. INDEX RANGE SCAN
2. TABLE ACCESS FULL

　となるはずです。（2.で変わらないときは少し範囲を広げてください）

　これで何が分かるかというと、上の様な単純なSQLを実行するときにも、RDBMS（オプティマイザ）はインデックスのデータの分散具合からどれぐらいヒットするか予想して、インデックスを使うべきかどうか判断する処理を、実際のデータにアクセスする前に行っているということです。

　なぜ、実行計画を変える必要があるかというと、例えば99％が男性という団体があり、その入会順に会員情報が記載された一覧があったとしましょう。

　項目は、

　　　会員番号↓ ・ 名前 ・ かな ・ 住所 ・ 電話番号 ・ 性別 ・ 生年月日……

　その他に、性別順に並べた会員番号の一覧を作るというのが、「性別にインデックスを作る」ということになります。

　項目は、次の2つです。（実際のインデックスでは会員番号ではなく物理的なアドレスになる。）

　　　性別↓ ・ 会員番号

　さて、あなたは、この99％が男性というリストから男性の一覧表を作るとき、性別順一覧を使いますか？ 逆に、女性の一覧表を作るとき性別一覧を利用しないですか？

　どちらかが当てはまるなら、この先を読むのは無意味です。IT業界で仕事をするセンスが決定的に不足しているので、転職を考えた方が良いでしょう。

　当たり前ですが、インデックスを使う、つまり2つの一覧を見比べながら結果を作っていく作業は、結果の件数が少ないとき効率的で、結果の件数が多いときには非常に非効率になります。

　その効率の分かれ目は、B-Treeインデックスの場合、対象となる結果のデータ量が全体の20～25％を超えるかどうかというところにあり、RDBMS（オプティマイザ）は実行前にその判断をしているので、データの取得の範囲を変えるとインデックスを使ったり、使わなかったりする訳です。

　それには、当然、あらかじめデータの分散ぐあいを測っておく必要があります。Oracleではアナライズという処理で行い（10g以降では自動収集がデフォルトになったのかな）、SQLServerは自動で行うのが普通です（手動に切り替えれたハズですが、面倒なのでやったことはない）。

　SQLをRDBMSに渡すと、シンタックスチェックだけではなく、実行前に使われているテーブル（インデックス）のデータの分散度合いを調べてから実行します。ややこしくなるので、上の例には結合はしていませんが、結合処理がある場合には、データ数などから、どのテーブルから順にアクセスするか、どのインデックスを使うか、あるいは使わないか決めてから実行します。もちろん、SQLの書き方でも、オプティマイザの判断は変わりますから、最終的には「部下の癖を見て指示の出し方を変える」というような書き方をしないといけない訳です。

　つまり、SQLはプログラムというよりも設計書、実行計画がプログラム（詳細設計かな）ともいえるものなのです。RDBMSにとってトランもマスタも関係ありませんから、汎用的に判断させアクセスパスを決める処理は複雑で重い処理です。

　オプティマイザはプログラムとしては大変完成度の高いもので（もちろん、O/Rマッパーとは比べものにはならない）、年々進化していますが、それでも、人間と比べると杓子定規でデキの悪いPGレベルでしかないですから、SQL文が複雑（下手糞）だったりすると、あり得ない結果を返してきます。ですから、あるレベル以上のスキルの人は「実行計画を見ろ！」と声高にいいますが、そういう人が出るということは、裏を返せば、SQLを書いていても「実行計画を見たことがない」という恐ろしい人が多いことの証明です。

　現実問題、見てない人がメチャクチャいるから怖いよね……。Oracle9i以下だと、実行計画を見るのに実行計画を保存するためのテーブルを手作業で作らないといけないのですけれど、億を超えるシステムでも、開発環境にも本番環境にも（チューニングするには本番環境にないと意味がない）そのテーブルがない！ なんてことも珍しくなかった。

　それって、数百人月で（数十人）の技術者の中で、誰一人として実行計画を見てないことを意味するわけで……、当然、実行計画を見ると訳の分からないものになっているし、まぁ、グルグルが多かったけど（苦笑）、まるで悪夢のようなデスマーチで、死人が出なくて良かったが、鬱で戦線離脱した人はけっこう出てたね……（他社のプロジェクトで、わたしは、同じお客様の別プロジェクトをやってた）。

　同じことで、「O/Rマッパーが良い」なんていう人は、O/Rマッパーが吐き出したSQLを確認しているかも怪しいですから、その先の実行計画を見ているとは思えない。決めつけはイカンけど、実行計画を確認するような人は、自分で書いたSQLでもオプティマイザが間違うことを知っているのに、O/Rマッパーが吐き出すSQLのレベルは推して知るべしというわけで、O/Rマッパーなんて使うのは嫌がりますね。

　「何が便利と思うか」の基準は人によって違うので何とも言えませんが、2回もチェックしないといけないなんて「なんて不便な」って……。

　それはともかく、実行計画ができた後は、手続き型言語で処理するのと同じように、実行計画通りDBEngineがデータにアクセスします。DBEngineも、オプティマイザも、C++などの言語で書かれたプログラムですから当たり前の話ですね。昔はCOBOLで書かれたDBEngineもあったらしいけれど……。その先は何であっても同じなわけです。

　さて、手続き型言語で細切れにしてから処理しようとすると、処理自体は（十分にチューニングされたSQLの）実行計画とほぼ同じになります。差があったらおかしいでしょう。ただし、別サーバではDBサーバが備えている統計情報や、インデックスを使えない。DBサーバが行っている諸々の高速化するためのプログラムは一切使えませんから、手続き型言語で処理は、オプティマイザの実行計画以下のプログラムにしかなり得ません。

　これは人によって変わるものではなく、論理的に決まります。

　しかも、単純なSQLでループを多用して作ると、コンピュータは律儀ですから、毎回、実行計画を考えます（今時、バインド変数を使わないことはないでしょうけど）。RDBMSは「複雑な処理をプログラマがループを書かずにできるように」という思想の元に開発されているのですから、その思想通り使わないと威力は発揮しないどころか、デメリットばかりになってしまう。

　多くの手続き型言語で書く方がよいという意見は、「余分な工数が掛かっても、別言語で人間がもう一度、実行計画以下のプログラムをコーディングして、ネットワークを挟んで非効率な実行した方が、俺たちが分かりやすいからよい」といってるわけです。

　SQLでやった方が良いという人の意見は、「RDBMSを使う以上、オプティマイザが理解できるSQLを書いて、それをチェックするだけの方がよい。分からないなら分かるようになるべき」といってるわけです。

　「手続き型言語で書く」ということは、開発者側の都合のメリットしか入ってない。手続き型言語で処理しようとすると、余分に工数が掛かって、中途半端で遅いモノにしかなり得ない。

　前回、手続き型言語で処理するのは「テレビのリモコンを孫の手で押しているのと同じ」と書きましたが、必然的にそんな感じになるわけです。わたしは「指で押せや～（怒）！！」って言い続けていて、「SQLなんて」っていう人は「ボタンが小さいから孫の手で押しにくい」って言ってるわけで……、噛み合わない。

　外側にどんなに使いやすいツールができても言語ができても、RDBMSを使う限りインピーダンスミスマッチは存在し、RDBMSを使う以上、上に書いてきた処理は変わることがないので、どこまでいっても同じ流れにしかならない。そもそも、外側でインピーダンスミスマッチを吸収しようとする試みは、RDBMSを全く理解していない人だからこそできる馬鹿げたチャレンジといわざるを得ない訳です。スタートラインから明後日を向いた無駄な努力をやってるわけです。O/Rマッパーの発展に期待とか、「もっと押しやすい孫の手を！」ってことでしょう。わたしにはまったく理解ができない（苦笑）。

　その目的が、「初級シスアドレベル、つまり、素人レベルの技術」を避けるためって、さらに、意味が分からなくなるのです。

　外側でインピーダンスミスマッチを乗り越えても、ある規模の複雑な処理になったらSQLで書かねばならない。「ある規模の複雑な処理」って、そのシステムのコアになる処理でしょう。そこで使えず、中途半端になるぐらいなら、インピーダンスミスマッチのラインを極力SQL側にした方がよいでしょう。できる人に取ってはSQLでやった方が工数は少なくなりますから、馬鹿げたチャレンジに意味を見いだすことは、わたしにはできない。

　「そんなことできるわけがない」という人とは違う風景を見ているからね……。初級シスアドレベルから、あとは階段を2、3段のぼれば、「あれ？」っていうぐらい違う風景が見えます。それを見た後で、それでも外側でやるべきという意見は聞くに値するけれど……。初級シスアドレベルから逃げたいという感情は、わたしにはまったく分からないです。

　「まぁ、ハードがカバーしてくれるから良いじゃない」というのは、「アセンブラとC言語」の関係のように、アセンブラの開発コストとよりC言語の開発コストが低いとき成り立ちます。つまり、SQLをどれほどできるようになっても、手続き型言語で処理するよりも工数が掛かるときに成り立ちますが、工数もSQLでやった方が減るのであれば、成り立たない言い訳です。作れる人が少ない以上、メンテが難しいということもあながちウソではないけれど、できる人が増えたら勝手に解消する問題でしかない。

　つまり、「SQLを使わない ＝ RDBMSを使わない」以外のアプローチは、根本的な部分でおかしい。もちろん、何度も書いているとおり、「RDBMSを使わない」という考え方はまったく否定しません。

　「SQLができない人でもある程度作れる」。あるいは、「オブジェクト指向で書ける」この一点しかないけれど、これは顧客に対するメリットとはいえない。

　できない人って……「そもそも、SQLができない人がプロを名乗っている」ということがおかしくないか？ ということを、わたしは何度も書いているわけで「できることが常識である」という立場です。「できなくてもプロを名乗ってもおかしくない」という人とは常識のライン、つまり、議論以前の前提が違いすぎるので話は通じない。

　できなくてもプロだというなら、どちらも同じSIerを名乗るとおかしくなるので、「初級シスアドレベルを避ける会社です！」って会社のWebにでも、会社案内にでも書いて欲しいモノです。

◇　　　　◇　　　　◇　　　　◇

　いずれにしても、簡単なSQLだろうが、複雑なSQLだろうが、バインド変数を使って実行計画を再利用しようが、「ファイルアクセスの記述が変わっただけ」程度の認識と比べると、SQLはオーバーヘッドはメチャクチャ大きい。そして、オーバーヘッド以外は、手続き型言語の方で処理するときと、SQLで処理するときと、どちらも同じ結果になるのですから、DBサーバの処理量はほぼ同じです。

　手続き型言語の方で処理するとき、APサーバがDBサーバの処理を肩代わりできるのは、ソートと四則演算しかありません。基本的には、ソートと四則演算より、オーバーヘッドや余分なデータ転送に掛かるコストの方が大きいので、手続き型言語の方で処理するとDBサーバの処理も増えることになるわけです。もちろん、インデックスや共有キャッシュを使えない（マスタならキャッシュできるかも知れないけれど）APサーバの処理は、DBサーバで処理するときに比べ比較にならないほど増えます。結果、APサーバを相当数増やさないといけませんから、エコじゃない。運用コストがずいぶん違うわけです。

　よく、「DBサーバで処理すると、DBサーバの負荷が増える」という人がいますが、論理的には間違いです。地球は平らだといってるぐらい、技術者として恥ずかしい意見です。もっとも、実行計画も見ない「とんでもないSQL」を書く人がいるので、現実問題としては間違いと言えないことの方が多いのですけれど……、それは「とんでもないSQL」を書く人に問題があるわけです。

　何度も書いていますが、「とんでもないSQLを書く素人崩れが大勢いるから、SQLは使えない」は、短期的には正しいけれど、今後もRDBMSを使うなら、「早急に教育を実施しないといけない」という経営判断が必要です。とくに若い技術者ではなく、中堅以上の技術者の問題ですから、多くのSIerが気づいていない根深い問題です。若い技術者を教育しても上から潰してしまいますから現場ではどうしようもないのです。

　そんなことが分かる経営者は大手にはいないだろうから、O/Rマッパーのようなものを作って「孫の手」は絶対に離さないってことが正論になるのでしょうけれど……。

　この常識を変えれるのは、大手の情報システム部の方々が「お怒りになる」ことしかないと思う。

　もちろん、何度も書いているとおり、RDBMSを使わないという経営判断も正しいですよ。RDBMSは顧客に浸透しきっているので大手では無理ですけれど、ニッチなベンチャーとしてはありかもしれない。

◇　　　　◇　　　　◇　　　　◇

　結局、「O/Rマッパーなどがすばらしい技術だ」と無邪気に思ってしまう人も大勢いるわけですから、担当を分けるしかないのです。

　つなぎ目はストアドプロシージャの方が都合が良いと思いますけれど、まぁ、上流から順に意味を分かって設計、担当割りを行い、きっちりとしたSQLを書くなら何でやっても同じで、後は好みの問題でしょう。O/Rマッパーは、きっちりしたSQLを書いた後にマッピングために使うなら、目的外利用じゃないかと思いますけれど、何の問題もないのです。

　とにかく、どうしようもなくSQLを嫌がる人が存在する以上、担当を別にするしかないのです。

　かなり前の話です。弊社でこんなソフトを製造しているのですが、突然、アクセス数が増えて、かなりの本数がダウンロードされるということがありました。＠ITとかCodeZineとか、CNetとか2chとかに載っても（載せても）微増なのですが、それとは比べ物のにならないぐらいのダウンロード数でした。

　それで「どんな強力な人が紹介してくれたのか」とうれしくなって、「御礼をしなくては」とアクセス解析をしたのですが、ダイレクトアクセスばかりで分かりません。それで「メールマガジンかな」と考えて関連しそうなメールマガジンを探したりもしました。

　しかし、どうしても分かりませんでした。

　それで、もう一度冷静にアクセス解析してみた結果、Google Analytics のリンクで飛べないリファラーが2回あります。タイミング的にそのドメインからのアクセスが起点になって爆発的なアクセスになっているのではないか？ と思い、それでドメイン名で検索してみたところ……有名なシリアル掲示板なるものでした。

　どおりで、ダウンロード前のアンケートに入力されるメールアドレスに生きているものがほとんどなく、たまに生きてるアドレスも他人のもので、本当のメールアドレスの持ち主から苦情の電話がかかって来たりする。さもありなん。

　たかだか数万円のソフトのためにシリアルの解析をするなんて「そんな暇な奴はいないだろう！」って高をくくっていたのが悪かったのですけれど……。

　その掲示板の上位表示がなくなった時点で、ダウンロードもされなくなりましたが、ダウンロードのピークを見るに、わたしは知らなかった掲示板でも、ここのコラムより絶対にアクセス数が多いと思います。くそー！

　実はとっても有名な掲示板なのでしょうか。いろんな意味で凹んでしまう事件でした。

　バージョンアップに際して、そこに載っているシリアルはもちろん使えなくしましたが、他に対策をしてないので、また破られるのでしょう。

　まったく、めんどくさい話だ。

◇　　　　◇　　　　◇　　　　◇

　わたしはゲームをしないので最近までマジコンの意味を知なかったのですが、日本橋（大阪の電気街）で堂々と看板を出していますし、マジコンは違法とはいえないようです。Winnyの作者にも無罪判決が出ました。しかし、マジコンもWinnyも、主たる目的として「違法コピーのために存在している」といって過言ではない。

　知り合いどおしで合法的にデータのやり取りをするなら、敢えてWinnyは必要ない。「P2Pの技術」と「Winny」は同列じゃない。個人的にマジコンとWinnyの違法性は、ほぼ同じと考えています。

　多くの技術者がいってるように、確かにP2Pのような技術が否定されると問題ですが、だからってWinnyが正しいとはならない（ハズ）。微妙だな～。

◇　　　　◇　　　　◇　　　　◇

　それはさておき、なぜ、このような製品を作ったかというと、生産性を上げたかったからです。

　バインドさせて簡単に画面が作れると非常に生産性が上がる。ダミーのストアドプロシージャをバインドさせれば画面はあっという間に完成するのですが……。

　しかし、製品を使っていただいている方からの質問などを総合するに、まず、空で画面イメージを作って、その後、テーブル設計、ロジックの組み込みと進めているようだ。

　なかなか意図が伝わらない。

　もちろん、お客様に使い方を強制するわけにはいきませんけれど、サンプルの動画もあまり見てはいただけてないようで。

　そんなわけで、今回はサンプルの動画も大幅にやり直しました。弊社が誇る美人社員にナレーションも入れてもらいましたので、ぜひ、ご覧いただければと思います。

◇　　　　◇　　　　◇　　　　◇

　いろんな現場を見ていますが、つくづく、新人に対してでなくベテランに対して「SQLの教育が足りない」と感じる。

　ベテランにとって、アルゴリズムのないSQLは違和感があるのは理解できるけれど、SQLは、Javaよりも.Netよりも古い古典的な言語で、.NetがJavaに、JavaがRubyに置き換わっても使われるであろう息の長い言語です。

　しかも、ユーザ向けに作られた簡単な言語で、コーディング量が激減している。嫌がっている人も嫌々ながらも使っているのですから、ちゃんと使ったら良いと思うのですけどね……。

　Javaだ！ フレームワークだ！ ってややこしいことをいっている人が大勢いる。そういう人が作ったものって、JavaとDBって全然疎結合になってない。言語のスパゲッティになっている。本当に疎結合にしようと思えばストアドプロシージャにDB上で完結する処理を入れるのが一番です。

　ストアドプロシージャにしたらメンテできないとかいう話も、なんだかな～。慣れてない人はどんなことでもできませんわな。

　慣れるには、最初にちゃんとした教育が必要なんだけれど、極めて初期の段階で「SQLは極力使わない」とかいう方針を打ち出しちゃうと教育しようがないし、本当にどうにかならないものか。

　前にも書いたけれど、初級シスアドでこのレベルです。

　初級シスアド 過去問題 平成14年度 春期 午後（問4）

　初級シスアド 過去問題 平成16年度 春期 午後（問1）

　新人の大抵はこの程度できるのに、上司が「EXISTSを使うと理解できなくなる」なんて堂々といったりしたら、詐欺師と同じです。

　「新人やユーザが受ける試験程度の能力がない人」がプロとして存在できるなんて、コの業界以外にあり得ないと思うけど……。どうにかならないものか。

ひがさん
「プログラミングファースト開発の必要性」

小飼さん
「プログラミングファースト開発のアキレス腱」

わたし
「テーブル設計は実装の後に！」

　マッチョな人間は同じことを考えるのね。わたしはそれほどマッチョじゃないですけどね……。

　ドキュメントの内部レビューなんて、まぁ、誤字脱字やページ番号や章番号のチェックだったりすることもあるからね。本当に意味ないし、若い頃よくバックれたな（良い子はマネしちゃダメですよ！）。

　ひがさんのおっしゃる「仕様を固める部分」ってのが、わたしのいうところの「外部設計」です。「プログラムファースト開発」か、なるほど言い方の問題ですな。

　まぁ、言葉の部分はいずれ学者に補完してもらうとして、小飼さんがやる分野でSQLをどのぐらい使うのか知らないけれど、業務システムに限れば「プログラムファースト開発」のネックになるのはSQLです。SQLができるようになれば、DB設計や業務ロジックの実装など、ユーザーに見えない部分を後回しにすることはぜんぜん怖くない。

　分かってないから恐れているだけです。

　さらに、「プログラムファースト開発（仮）」はひがさんがおっしゃるおとり、下請けとかオフショアとかやりにくくて、大手でSIerでは採用しにくい。だからこそ良い、とわたしは考えているというのはこれまで書いてきたとおりですけれど、やはり大手SIerではできないでしょう。

　むしろ、大手がそんなにマッチョになったら、下々は全滅してしまう。マッチョに変わることができた中小企業はそれなりに生き残るでしょうけれど……。

　小飼さんのおっしゃるとおり、わたしは力がないので、今のところ安く取らざるを得ない。「見てたのかよ！」ってぐらいグサッときますな。

　それはともかく、ここで言葉汚く罵ってみても、大手SIerの上位には通じない。

　ですから、産学協業でこの辺の手法を、なんかカッチョイー名前をつけて確立したいと考えています。

　やっぱり、大手SIerなどに採用されるには、どの程度効果がでたのか、定量的、学術的に評価して論文にする必要性があると思う。しかし、それにはよほど大きな会社でないと余分に金を掛けれないし、よほど大きな会社は上に書いたような理由でできないのです。

　というわけで、弊社ではなく弊社が所属しているNPO法人のJASIPAを通じて、いろんな大学にアプローチしていけたらと考えています。

　「プログラムファースト開発（仮）」だけじゃなく、日本のIT産業は学術的に弱い（お前が言うか！）ので、大学で研究されている理論を、実開発で試すような協業を大学とできたらと考えています。

　ちょっと、疲れてきたのでユルめに。

　昔、イントラネット、エクストラネットなんて言葉がありました。今はほとんど聞かなくなりましたが……。

　余談ですが、SaaSなんてASPと変わらないし、エクストラネットと言ってたときも、「WEBページだからこそ、サービスを組み合わせることができる」とか、クラウドに近いことを言ってたし。その後に、やたらマッシュアップ！ マッシュアップ！ と言うようになって、クラウドとか新しい言葉を作らないとマーケティング上やりにくいってことかな。

　わたしはそういう言葉先行が大嫌いで……だから儲からないのでしょうね。

　それはさておき、今更ですが、ざっくりと比較してみると。

	リッチクライアント	WEBシステム
パフォーマンス	★★★★★	★☆☆☆☆
操作性（入力時）	★★★★★	★☆☆☆☆
操作性（参照時）	★★★★★	★★★★☆
工数	★★★★★	★★☆☆☆
インストール	★★★☆☆	★★★★★
保守性	★★★★★	★★★★★
マルチOS	★☆☆☆☆	★★★☆☆
外部公開	★★★☆☆	★★★★★
シンクライアント	☆☆☆☆☆	★★★☆☆

　Webシステムは、マルチOSや外部公開、シンクライアント対応しなければ意味がないのです。ところが「OSはWindows XP以上、とかブラウザはIE7以上、それ以外は保証しません」とかね……。これを書いちゃうということは、もう意味がわかってないのです。

　そもそもWebシステムは、Webブラウザ（閲覧ソフト）で基幹システムの入力機能を作ってしまうのはかなり問題があります。

　本来的には、Webシステムはダム端末と同じです。クライアントでの処理は表示とユーザーからのリクエストを受け付けること、ダム端末との違いは、マウス操作がベースになっていてサブ画面が簡単に開くこと、あくまで本来はね。

　ブラウザは閲覧ソフトですから、参照系には非常に便利にできています。しかし、データ入力にはそもそも向いていないので、凝ったことをしようとすると無理やりスクリプトなどを埋め込む必要があり、大変な工数が掛かったり、パフォーマンスが落ちてしまったりします。

　結果、シンクライアントやマルチブラウザなどでは実現できなくなったりします。メリットはインストールの手間だけになったりしますが、それなら、リッチクライアントでインストールプログラムや再配布のプログラムをしっかり作った方が良いわけです。

　基幹システムでも、外部公開をすることもありますが、すべてを公開することはできません。ブラウザ用と携帯用など、それぞれに合わせて作ることも多いでしょう。

　であるなら、内部用と公開用と二重に作った方がよい。そのときには、SQL（ストアドプロシージャ）にロジックを入れている方が再利用しやすい。いつもの方向ですな（笑）。

　もちろん、パッケージのようにRDBMSが変わるということもあるでしょうが、基幹システムなどではRDBMSが変わるより、他が変わる方が圧倒的に多い。

　SQLの使い方から、WEBシステムにするかどうかまで、とにかく決め打ちはいけない。必ず、それぞれの意味を考えて方針を決めなければなりません。

　「上流技術者はSQLを！」と何度も書いていますが、それは「上流技術者のスキル不足で方針が覆せなくなり、顧客に対する成果物に差が出る」からです。

　なぜ、差が出るのか、以下で説明します。

　案件のスタートラインの打ち合わせで、顧客から漠然とした要望を聞いたとき、そこにいる営業と最上流の技術者は、話しながら難易度（粗い見積り）を測っています。

　これはどんな人でもやります。新人PGだって、「あーやって、こーやって、なんだか難しそうだ」ってね。つまり、会話（打ち合わせ）で難易度を測らない人はいないです。

　営業が一般的な人であった場合、会話の仕切り役に終始することでしょうが、今までの似た案件を元にざっくり難易度（粗い見積り）を見定めながら、最上流の技術者の顔色などを見ながら仕切っていきます。ちなみに、営業が技術者上がりだった場合、SQLを使わないパターンの見積りはかなり正確に出しています。

　もちろん、最上流の技術者も難易度を測っていてます。

　もし、この場で自信を持った難易度が出なかったら、顧客に下手に言質を与えるわけにいかないので「帰って検討します」しか言えません。「ガキの使い」状態になるしかないですね。

　ですから、この瞬間というのは、最上流の技術者にとってかなり緊張を強いられる難しい（楽しい）瞬間になります。

　この時点で、VB6か.NETかなんて瑣末なことはどうでもよい（どちらで考えても誤差の範囲）のです。しかし、難易度を測る上で、ループして処理するか、SQLで処理するかで、想像した難易度やその後のプロジェクトの運営方針は全然違ってくるので、その打合せの場で話す内容も変わってきます。

　変わらないと思ったら以下を確認してください。

1. SQLで処理をしたら、工数が数倍以上、パフォーマンスが10倍以上の差がつくことがある。
2. 顧客から要望を聞いた時点で、イメージしたもので工数が数倍以上、パフォーマンスが10倍以上の違いがあれば、その後、顧客に話す内容に違いが出る。
3. 上流の技術者はコンピュータを使わない手段も含め、あらゆる手段を検討し提案すべき。

　ノーと考えたなら、顧客に話す内容は変わらないでしょうし、わたしの考える前提と違っているのでしょう。この後を読むのは時間の無駄なので読まない方がいいです。

　全部イエスとなり、SQLで処理できるのに「できない」と判断していたときは、SQLで処理した場合の工数が数倍以上、パフォーマンスが10倍以上のイメージの違いがある状態で顧客と話すことになります。

　つまり、顧客に話した内容は、工数が数倍以上、パフォーマンスが10倍以上と同等の大きな差がついています。

　新人PGが考えた難易度は周りの指導で簡単に変わりますが、最上流は誰からも指導されることもなく、顧客にも話してしまっている既成事実になっています。もう固定されてしまって覆せないのです。特に営業が優秀であった場合や、上流技術者が複数いた場合、力を持った者の複数のコンセンサスになってしまうので、絶対にひっくり返りません。

　難しい処理ほど差がつき、難しい処理ほど顧客に対して影響が大きい。顧客に対して影響が大きいものほど、上流技術者がソリューションを提供すべきものになりますが、その肝心の場面で、工数が数倍以下、パフォーマンスが10倍以下の方針へ指揮棒を振ることになります。でも、上流技術者が指揮棒を振った方向が成功ラインなのですから、上流はよほどのことがない限り、失敗することはないけどね（下流のせいにできるものね～）。

　こういう状態にならないためには、上流が会話のペースで粗くても良いので、（当然、できないこともあるので闇雲ではなく）できるかできないか確証が持てるレベルに習熟する必要があります。つまり、演習問題ぐらいの難易度で、会話のペースで判断できるかどうかが非常に重要なのです。演習問題ぐらいがこなせないと、打ち合わせの現場でSQLで処理するという方針（わたしの考える成功ライン）を採ることはできません。

　逆に確証がもてれば、自分がコーディングする必要はまったくなく、指示すればよいのです。

　ところが、現状では、上流の技術者が演習問題を見ても、SQLの問題と聞かなければSQLで処理することを検討することすらないでしょう。つまりほとんどのプロジェクトで、上流が打ち合わせの席で難易度を測りだすというわずかな時間に、SQLで処理するという方針の大部分が潰されてもう覆せません。

　潰されなかったモノが、更に下流のコーディングレベルでも差がでて、そこで起きる議論が一般的な「SQLでやれよ！」って議論なのですが、わたしはその上にもう1段あると言ってるわけです。

　では、表題に戻って。

　VB6のお陰か「継承など何が便利か分からない」って人は案外たくさんいます（多重継承の批判のため逆説的に使う人を除く）。

　継承を利用するのは、オブジェクト指向言語を使うのと同義語と言えるぐらい当たり前のことですが、それでもしばしば、機能分割からクラス設計が始まるあたりの議論が起きます。

　タイミング的にはSQLで処理するかの決定よりずいぶん後になってからで、上流というか中流というか、ともかく機能分割などを担当する技術者のスキルによって変わるでしょう。担当者がCOBOLやVB6からの流れで「継承など何が便利か分からない」という人で、それより上位も同じようなスキルだったら、たいがい難儀（大阪弁）なことになります。

　つまり、妙な機能分割をして、いい加減な（というか継承がわからない人がどうやって……）クラス設計をしながら作業を割り振っていきます。そして、作業分担が決定した時点で覆せなくなります（覆すには相当な手戻りや、調整が発生します）。

　継承の議論なんて馬鹿馬鹿しいと思う向きもあるかもしれませんが、冗談抜きでVB6と.NETの議論をされてた方々の何人かは経験があるかもしれません。

　実はわたしもこれをやられて、数千万の赤字を抱えることになったし……、そのときは精神が壊れて、本当に何度も電車に飛び込む寸前まで追い込まれました。そういう奴をアサインした時点でわたしの大ミスですけれど、さらに当事者に文句を言われるのは何とも納得できなかった（逆に、納得してたら飛び込んでたな……）。

　それはともかく、そういう人は言うのです。

　「俺はこういうやり方（継承なし）で実績上げてきた」

　「俺の方針（継承なし）で、できないというのか～！」

　継承ぐらい当たり前にできるあなたはこう思うでしょう。

　「あんたが上げた実績は成功じゃなく、成功ラインが低かっただけ！」

　「できる、できないじゃなく効率の問題だって」

　できる人から見ればものすごく馬鹿げた話で、「右折のできないタクシードライバー」ぐらいに感じると思います。しかし、相手が理解できるレベルに来るまで、まともな会話は成り立ちません（上にいる人は簡単には自分ができないとは認めないしね）。で、できない人は、今起きている問題点の存在すら分かりません。

　では、継承をSQLに置き換えて読んでもらえればどうでしょう。同じことはSQLでも起きますし、現実にもっと広範囲（継承のなかったVB6のころからずっと）に起きています。

　「そんなことはない」と思う人もいるかもしれませんが、それは「俺はこれで実績を上げてきた」ってことですよね。演習問題程度も「できない」基準で見ているからで、「できない」人が何を根拠に「そんなことない」というのか、わたしにはまったく理解できません。

　もちろん、多数決をとれば、いわゆるフルボッコでわたしは負けますけれど、技術者が多数決を持ち出したら、地球はまだ平らのままでしょう。多数決を言い出す奴は、技術者じゃなく慣習に流される作業者です。（多数決というか技術者の少なさで）リスクを考えて判断するのは、経営者（まぁPMもするけどね）が最後にすることで、技術者が多数決を持ち出す必要はないのです。

　継承ぐらいの小さな問題は、実際には下流に近いところや下流で起きますので、ボトムアップ（下流の人が言語を勉強する努力）で徐々に解決する問題で、そんな戯けたことを言う人は確実に減っていきます。

　で、継承を使わないプロジェクトもやったことがあるけれど、実際にそんなに大きな差は出ないのですよ。継承するかどうかなんて、ときに激しく議論になることもありますけれど、SQLと比べれば結果は本当に瑣末な問題で、顧客に対しての成果物にほとんど差はありません。（弊社で失敗した理由は、SQLを使うかどうかとか、もっと他のが重なってね……、そのレベルの人間に期待をかけてPMに置いてしまったわたしの責任ですけどね）。

　オブジェクト指向言語を使っていて「継承など何が便利か分からない」というのは技術者として、かなり恥ずかしいと思いますけど、顧客に対する結果の差から考えると、顧客にRDBMSを導入させておいて、「SQLができない」ことの方が相当に悪質です。

　上流の仕事を最初の打合せに戻って考えると、VB6か.NETか、などの言語の選択や、継承や、その他の問題は、決定までに猶予、つまり社に戻って他の技術者を交えて議論する余地があるのですが、SQLで処理することは、説明したとおり、本当に顧客を前にした最初の瞬間に限界が決まっていて、後からは変えられないのです。

　GOTOを駆逐するのも、継承を利用して工数を下げるのも、下流からボトムアップで解決できるから変わってきましたが、これは、上流の人間が「言語なんて……」と思っていて、言語の詳しい内容は知らないから、逆に「よきに計らえ」って言い易い。ですから変わっていくのです。

　10年かかってもSQLがまっとうに使われないのは、SQLが難しいからではなく、上流でつぶしているから、つまり、「上流がボンクラだから」なのです。

　上流のほとんどの方は、自分が顧客の前で話してきた内容を、下流の指摘によって変更して顧客に再提案するなんて、プライドが邪魔して簡単にはできません。

　プライドだけでなく、場合によっては、バッチ処理を選んだために運用チームに運用設計の指示を出しているかもしれません。リアルに答えが出ないための工夫を顧客に説明しているかもしれません。中間処理の設計を指示したかもしれません。顧客に中間の操作をお願いしたかもしれません。

　変更するときは、すべての関係者に方針の変更を説明しなければなりません。つまり、事実上、変更できない。くどいですが、上流のほんの一瞬のイメージで確定してしまいます。

　うそだと思ったら、演習問題を実際に設計してPGに詳細設計書が渡ったあと、それを見たPGが「こんなの一発でできますよ」って言ってきたときを想像しましょう。……それが理解できたとしても、どうしようもないでしょ。遡って、どの段階なら方針を変更できたかというと……。

　理解できましたでしょうか？ あなたが処理をイメージして誰かに伝え始めた時点で、もう変えれないのです。

　上流下流と分けるなら、もちろん、案件の規模が2千万以下なら上流は何もかも知らないといけないけれど、それ以上の規模なら分業せざるを得ませんから、規模によっては上流はVB6を選ぶか.NETを選ぶかなんて、（積極的にかかわってもいいけれど）下々に任せてもいいぐらいです。継承を使うかどうかなんて、まったく関係ない職域の話になることもあります。

　しかし、SQLについては会話のペースでパフォーマンスを予想するぐらいできなくては、無意識にプロジェクトの未来をつぶしてしまいます。部下の可能性も止めてしまいます。

　上にも書きましたが、上流とは、もっとも多くの選択肢（コンピュータを使わない手段も含め）を持っているべき立場ですから、顧客に対する便益が大幅に変わる可能性のある「SQLで処理する」という選択肢をもってないのは、職責にかかわる重大問題です。

　選択肢を持った上で、最終的に選択しないのと、選択肢を持っていないのは本質的にまるっきり違います。右折のできないドライバーが、たまたま直進と左折で行ける目的地だっただけの話です。結果的に使わないことになろうと、なかろうと関係ない。演習問題ぐらいできなかったら選択肢に入っていないというのが、重大問題なわけです。

　しかも、RDBMS（SQL）は業務システムでもっとも広範に使われていて、現在使われている技術の中では、一番古くからあるといえるものです。突発的に出てきた新しい技術ではない、それで、職責にかかわる重要なスキルが足りないのに「上流技術者」を名乗ったら詐欺師でしょう。相対論ですからね、上流が、右折のできないドライバーでも、ボンクラでも、詐欺師でもないなら、わたしが神になるしかないかな（笑）。

　ともかく、くどいけれど上流の技術者はSQLをできるようになるべきです。

　現状ではできない人の数が多すぎて、全員が詐欺師になっちゃいかねないので（笑）責められないですが。ならば、逆にできるだけ早く覚えておいて（もう十分遅いけどね）損はないはずです。早くスキルチェンジできれば、それだけおいしいところが取れます。.NETよりは長持ちするかもです（笑）。

　特に上流の技術者は、おいしいところを自分で作り出せるのですけどね（あまりにできる人の数が少ないと、わたしのように苦労しますけど）　。あとは、既存のお客様になんと言い訳するかですけど……。ドラスティックに変われば変わるほど、過去の自分を徹底的に否定することになるからな～。

　つまり、大きな案件で頭（上流）をいくつも取ってきて、自分の過去を否定しにくい大手は簡単には変われない。これも馬鹿な話ですが、既得権を持って、過去を否定できないからよい悪いでは判断できない。官僚と同じ構造で実に醜い。個々には非常に優秀で立派な人が多いけれど、過去を否定できないからという点は、わたしには許しがたい。

　逆に中小で下請け脱却を狙う、下克上にはちょうどいいのですけどね……。ツールもFWも言語も関係ない。導入済みのRDBMSをちゃんと使うだけですから。「上がボンクラ」を証明すれば良いわけです。

　「じゃあ、なんでお前はできないんだよ！」というのは……、前に書いたでっかい赤字を引きずっているからです。受託で頭を取りにいくには資金力が要る。たとえば、1億の案件を取るには、7～8千万はキャッシュを持ってないと取れない。7千万しか持ってないのに取りにいくのも相当なギャンブルです。そんなギャンブルをするところに、1億の案件を出す人はない。つまり、弊社ではできないのですよ。……本当に死にたいぐらいに悔しい。

　金ない、金ないと言ってても仕方ないので、NPO法人JASIPA というころに加盟したりして、ジョイントベンチャーなどもやっていきたいと考えています。まだ、わたしも入ったばっかりですけれど、もし、中小IT企業の社長さん（社長でなくてもよいのですが）がごらんになっていれば、ぜひご加入ください。

　それはともかく、SQLなんて本当に簡単なものですから、2日も勉強すれば、できるかどうかの判断と粗いパフォーマンスの見積りぐらいはできるようになります。

◇　　　　◇　　　　◇　　　　◇

　急ですが、東京でセミナーをやることになりました。わたしは、そんなに怖い人じゃないですよ（笑）。

　日程は7月16、17日、7月18、19日の2日コース2回です。

　内容は、文法の細かな説明ではなく、これはSQLで処理できるかどうか、パフォーマンスはどれぐらいになるか、といったことが会話のペースで理解できることを目標にしています。後はリファレンスを見たら書けるでしょう。

　PCのあるセミナールームを使おうと考えていたのですが、貸し会議室でSQLServer 2005 Express Edition以上をノートPCをご持参いただく形にしました。（レンタルは2台まで可能です）　

　大阪では、数人で弊社の小汚い事務所で土日に開催します。7月11日12日は開催確定です。

　価格は、次回から個人で受けられる方と、会社から受けられる方（領収書の宛名が個人か法人かで）と分けたいと思います。わたしが神なら、神の価格になるので普通人より安い今がチャンスです（笑）。詳しくはメールにて　info@g1sys.co.jp

　みんなVB6を使い続けていることを、こんなにも気にしているということが分かりました。プチ炎上したのでまとめです（うそ、まとめになってない）。

　以前、しゃれでこんなゲームを作ってみたのですが、わたしもここ5年ぐらいはほとんどVB6を触ってないので（当時としては3年ぐらいのブランクかな）、3時間って見積もって8時間もかかってしまった（苦笑）。

　これを元に、VB6か.NETか考えてみましょう。

　要件によっては差が出るものもありますが、このゲームを作るには.NET（エクセルマクロにはないけど）の方が多少都合がよい。これは通常の業務システムよりも大きな差になる。

　作った当時もブランクがあったので、「（VBAの）配列って……、あれ？ こんなことできなかったけ？」ってなことになり、.NETでできることがVBAでもできると勘違い（忘れてた）して、かなり大幅に後戻りしました。こんな小さなプログラムなら1カ所でも嵌ったら差が出るけれど、プロジェクトで嵌りっぱなしってことはないはずで、誤差の範囲でしょう。

　余談ですが、新入社員の教育用に「ゲームなら業務システムより抵抗がなかろう」と思って「3時間で作ったる！」って宣言して作ったので嵌って悔しくってね。で、新入社員には難しすぎると大不評でした。こういう自己満足のための仕事は良くないね。

　勘違いして後戻りしなかったら5時間ぐらい、でき上がったソース量からみて全盛期ならVBAで4時間ぐらいと思う。エクセルマクロに.NETが使えたらとしたら3時間ぐらいかな。

　言語（開発環境）としての特性を比較するならば、不得意の人がやると、「できない＝無限大の工数」になるので、どちらにも慣れている人で比較しないと意味がない。わたしはどちらもそれなりに慣れていると考えて（異論は受け付けるよ）、差が出る機能で20～30％の生産性の違いでしょう。

　もし、20～30％以上の差がつくと思うなら、単にいずれかが、わたしよりもはるかに得意か、ものすごく苦手かなだけじゃないですかね？

　比べてみたら「.NETは楽だね～」って思うけれど、PCのメモリを2Gから4G(3Gしか認識しないけど）変えたぐらいの差しかない。増やした瞬間は楽に感じたり、減らした瞬間はイラっとしたりするけど、次の瞬間には忘れている。

　このぐらいの差は、担当者の「能力＆慣れ」で簡単に逆転してしまいます。たとえば、.NETでやったら2時間でできるって技術者は、どこかにはいるでしょうけれど会ったことはないし、.NETが得意という技術者でも、大半は4時間じゃ無理なんじゃないかな。異論は受け付けるけど、普段の弊社の見積りは、わたし（がやったとしたら）×3 でも足らないことが……。

　つまり、VB6がかなり得意な技術者なら、同じものを.NETにちょっと得意ぐらいの技術者が作っても、まだ、VB6の方が早くできます。

　いずれにしても、顧客の都合を前にしたらごく瑣末な問題です。VB6も、.NETも無視できない数のユーザー（案件）があるのですから、両方できればよいし、片方を無視できると思えば無視すればよいのです。

　無視するかどうかは、経営者の判断で技術者がする判断ではないと思う。技術者は必要になる日のために自己研鑽はすべきですけれど、それと顧客の便益とはまったく別次元のお話です。

　もちろん、わたしは社内的にはどちらも無視することは許さないのですが（笑）、他人に変えた方が良いというほどの差はないでしょう。

　ところが、同じ（最善を尽くす）感覚で見積もっても、SQLでできることはSQLで処理した方が絶対に早い。どんなに効率的に書いてもSQLの方が処理も速い。

　これには、どんなにがんばっても超えられない壁がある。　

　あなたはすでにSQLを会話のペースでできている！

　あなたはすでにSQLを会話のペースでできている！（答え）

　こんな風にできれば、コーディング30分、テスト資料作り含めて0.5 日で終わります。一般的な開発（Java、VB6、.Net、PHP、Ruby ……）では2～5人日。0.5 日対、2～5人日って400～1000％の差になるのですけれど……。

　20～30％の差が猛烈に気になって炎上するぐらいなのに、400～1000％の差が気にならない理屈が分からない（ちょっとしたレトリックが入ってますけどね）。

　そもそも、VB6しかないところで、「.NETで！」言ったところで始まらないけれど、RDBMSは基本的に導入済みなんだから、ちゃんと使ったらいいじゃないですか？ 他に余計なツール（O/R何チャラとか）すらも要らないですよ。

　早くできても、あまり給料に差が出ないサラリーマン感覚では分からないかもしれませんが（この給与体系が技術者にはそもそもおかしい）、たとえばタクシーと同じに考えれば分かるでしょう。目的地に着くのに何倍も時間が掛かって、何倍もの料金になる。感覚的には「右折は怖いんです」って左折だけで行けるルートを通るぐらいの差です。

　顧客に提供する成果物も明らかに違うのに、プロとしてそこに問題意識がいかないのはなぜ？

　もちろん、左折と直進だけで到着する目的地もあるけれど、そんな屁理屈ばっかり聞いていると、社長として金払う立場になったら猛烈に腹立つよ～～。

　上流の技術者ってのは、タクシーの運転手をナビゲートする立場にあるのですが、これも左折だけでルートを探そうとする。左折だけではいけないときには、客をいったん降ろして（これが一番むかつくのね）客に横断歩道を渡らせて、対向車線にいる別のタクシーに乗せてしまうとか、目的地を変える交渉をするとか、そんな設計ができる人がすばらしい技術者って呼ばれてたりするけれど……。空気も読まず、鬼の形相で「右へ曲がれや！ コラぁ！！」って言うからな～、わたしは。

　日本中の技術者にケンカ売ったかな（苦笑）。

　右折する文化のない人たちにはなかなか理解できないと思うけれど、右折できる人が、右折しないタクシーに10年も乗ってたら誰でもキレると思う。

　VB4のころからSQLを使っているけれど、スキルチェンジはOracle9i、SQLServer2005からのOLAP関数だけですからね（他の今後出てくるであろう、SQLの言語的な追加機能は母言語にやらせた方が効率的と思う）。VBやったり、Delphiやったり、C#やったり、Javaやったり、PHPやったり、他にもいろいろやってきたけれど、SQLはずーとわたしの中ではメインにできてきた。VB6 → .NET 程度の違いで騒ぐぐらいなら、極力、言語の切り替えの影響を排除するためにもSQLにロジック入れるべきですけど……。

　この後も、SQLの方がある程度、息が長く使えると思います。

　SQLが消えるなら、1000％をさらに何倍も超える生産性のものが出てくるってことですから、そのときは完全にEUCが実現されてプロが要らなくなっていると思います。

　煽ろうとどうしようと、そう簡単に変わらないのですけどね。

　嫌味なことを言うと、差がありすぎると儲からない。「時代の先を行き過ぎる人は評価されないもの」って慰めてたいところですが、「10年以上前の技術で喰ってるのに」って思っているので、先に行ってるつもりがまったくなく、慰めにもならない。

　「技術者が社長になってもうまくいかない」って典型ですな、本当にエリック・シュミットに来て欲しい（笑）。

　思いがけずコメントがたくさんついたので追加。皆さんありがとうございました。

　主旨は、やたらに新しいものを追いかけるのも、古いものに固執するのもよくない。必要に応じて取捨選択すればいいじゃないのってことです。

　以下、あまり大声で言えないので独り言モードで大阪弁です（普段はこんなしゃべり方）。独り言だから、ホンネやけどくれぐれも「わたしの公式見解じゃないので」。って裏表があって大人みたいだ（笑）。おもろいと思う人にとってはおもろいかも知らんけど、分からん人は流してください。

　いきなり、余談から。ホリエモンは量刑について不満らしい。

　思わず、ヤツのブログにコメントしてしまったけど、正直ちょっとヤツのいうことにも一理があると思い始めたところだったので、ものごっつ腹立つ。アホかと。王様でないとできない、一般的に馬鹿げた仕組みを実現するために金を儲けたかったんじゃないのか。そのために、ヤツは立法精神はさておいて「法律に抵触してない」ということを根拠にアホなことをしてきたんちゃうんか？

　立法精神を無視するというのは、法に書いてあることがすべてであるという考え方で、抜け道を探して「違法じゃない！」を根拠に、それまで積み重ねてきた商習慣やモラルを踏みにじってきたわけで、逆に有罪ならば量刑は法にある内容まで可能じゃないのか？

　それをヤツは、判例を持ち出して量刑がどうの言ってるけれど、判例よりも長い歴史のある商習慣を散々踏みにじってきて、いまさら判例などというのは、冗談にしてもひどい話や！ 無罪でなかったら「量刑は法律上の最高刑であるべき」と自ら言うぐらいでちょうどいい。無罪を主張するのは許せるとしても「男を貫いてみろ」と言いたい。

　で、表題に戻って、何が言いたいかというと、法律よりも立法精神が重要なんで、さらには契約も「あなたを信じて取引します」という約束の精神が契約書（に書いてある内容）よりも、はるかに重要なわけやね。

　日本も金融機関に大量に入れたけれど、アメリカもGMに何兆という公的資金を入れるわけ。個人的には今混乱したとしても、潰したほうがよいと思うけれど（うちには絶対公的資金は入れてくれないしな～）。公的資金注入はどんな法的根拠なの？ ほとんど事後法だったりするわけで、影響が大きいときは、アメリカのような契約社会でも政府自身が平気で法律も曲げるってことなのよ。

　で、VB6が公式サポートが切れていることを気にする人がたくさんいるようで、特にセキュリティ面で気になるらいしけど……。マイクロソフト（以下MS）の立場に立って、仮にVB6 にとんでもないセキュリティホールが見つかったとしてどういう対応をするんやろ？ 現在も使っている何万というユーザが迷惑をこうむるわけやね。

　しかし、どう考えてもVB6を使い続けている何万というユーザは、今、.Netに移行していないわけで、MSにとってもっとも大切で確実性の高い見込みユーザなわけ。その見込みユーザに対して、「とっくにサポート切れているから、MSとしてはサポートしません」と言うの！？ そんなんあり得るか？

　VB6でセキュリティホールが見つかったとして、パッチを作ることも、配布するコストも、MSにとっては微々たるもので、そんなことができないほど体力のない会社ではないやん？ それでも、仮に「MSはサポートしません」と無責任なことを言ったらどうなるか？ 迷惑をこうむった何万というユーザ達が向かうのは「MS以外でのリプレース」、つまりJavaなどに（下手すればOSからOfficeスイートまで）流れるわけで、当たり前やけど、MSが一番恐れる結果になる。とはいえ、「いつまでもサポートしますよ」では、新しいモンが売れないから契約上はサポートしないとなっているけれど、大きな声では言えんけど皆まで言わすなよ、ってことヤネ（そんなわけで大阪弁）。

　そんなことが現実にあり得ると思うなら（思う人が多いらしいけれど）ちょっと、頭でっかちになりすぎじゃないの？ 社会は法律や契約だけで動いているわけやない、という単純な現実がまるで見えてヘンのじゃないかな？それでも、MSがVB6のサポート切れを言い出すほどアホやとしたら、.Netは同じように危うくって信用ならんということになるし、逆に、もし.Netが信頼して使えるなら、VB6も使って大丈夫ってことになるわけや。

　ちなみにIDEのサポートは切れているけれど、ランタイムのサポートはまだまだ続く。一説には、2017年ぐらいまで続くらしいし、まぁ、IDEでなにか問題があってもこっち（開発者）側の問題なので、わたしは全く気にならない。

　何を持って信頼に足るかというのも難しい話やれど、どんなものにも危険性も利便性もある。昔のシリンダー錠はその筋の人には針金で簡単に破れたし、大昔のアニメの「ルパン三世」でも針金で開けてた（笑）ぐらいやから、みんな針金で開けれるという認識があったはずだけれど、その鍵を信じて安心していた。日本でシリンダー錠の対策が打たれ出したのっていつごろからなんやろ？ てか、いまだにシリンダー錠はあるしね。

　それに、毎年交通事故で数千人は亡くなって、数万人は後遺症に苦しむわけやけれど、みんな道を歩いたり自動車に乗ったりするわけや。ぶっちゃけて、シリンダー錠よりも自動車よりもVB6は安全だと思いますよ。少なくとも10年間で死んだ人は……デスマで亡くなった人はいるかも知れんけど言語のせいじゃないし。

　おまけに、セキュリティで問題になるのは、OSや言語（ランタイム）とかの問題ってほとんどないわけ。今までに大問題になったものというのは、メールの操作ミスや、安易なパスワードによるウィルスやワームの被害を受けるとか、公開しているディレクトリに個人情報を置くとか、SQLインジェクションとか、つまりは人為的なミス（が重なったもの）。

　パッチはいっぱい出ているけれど、そのパッチの対象になっているセキュリティホールを突くには、そもそも特定企業のシステムの構成を熟知してなければならなかったり、LAN内へのアクセス権が必要なものがほとんど。そんな犯罪をできる人は、業務上システムの管理者権限を持っているので、セキュリティホールを突かなくても、あんなことやこんなことができてしまうから、仮に悪意を持って犯罪行為をしようとしたら、セキュリティホールを突くなんてめんどくさいことする必要ないし、できる人が限られているから簡単にアシがつくので、よほどのアホでないとやらない。

　もっとも、簡単にアシがついても、銀行員の横領とか、医者が患者に、教師が生徒に性的犯罪をするとか、当然のモラルがない犯罪も起きるわけやから、それと同じぐらいの確率では起きるやろうけどね……（教師が生徒によりも、システム管理者の犯罪の方が少ない気がするというと偏見かな？）。

　最大のセキュリティホールは人間なわけで、何べん言ってもキーボードの裏にパスワードを書いてる奴がいなくなるまで、どんな対策しても無駄なんよ。それを超えるセキュリティホールが見つかることはほとんどないから、セキュリティ対策は、パッチ、ウィルスパターン更新やパスワードの変更など基本的な対策を行った後は、教育にコストを掛けた方がいい。システム管理者に対しては、それ以上の高いモラル教育と監視を強化するしかないわな。

　ともかく、サポート契約が切れて「セキュリティ問題がものすごく大変！」というのは、システム屋（＝自分）は信用ならないと言ってるのと同じで（笑）、究極のマッチポンプをやってるよね。「サポート契約が……」とか言ってしまうのは、減点法で管理される官僚的な大企業に多い感覚です。ほかに若い人が言っちゃうのは「契約社会」とかって肩肘張って背伸びして勉強してましたって感じかな。例えば会社の呑み会は、たしかに就労規則にも何にも書いてないかもしれないけれど、「呑み会反対！」って言っちゃうようなものです。

　法律も契約も最低限のことしか書いてなく、法律も契約書もどうでもよいとはいわんけど、それ以前の不文律がある。法律や契約を守ればよいのでもなく、アメリカのような契約社会であっても、GMに対する公的資金のように、政府といえどときには踏み外すこともあるし、業界にも会社にも不文律があるわけや。

　それでも、杓子定規で頭でっかちになって、「法律！」「契約！」となってしまうところに、ホリエモンが言ってることにも、ブラック議論にもつながるんじゃないかな。わたしも不文律と戦っているのですけど、ちょっとちがうんよね～。

　それはさておき、システム屋として営業する上で、個人的には「.Netを使ってほしい」ってのもあるし、顧客が受ける便益に差が無かったら、あえて、VB6を選ぶ必要もない。官僚的で「サポート切れしたものなんてあり得ない」ってところもあるし、担当者が新しいモノ好きってところでは、VB6なんておくびにも出さんわな。

　官僚的なところに「VB6でやりましょう！」というのはアホだし、せっかく買ったVB6の開発環境や、今までの教育コストがもったいないと思っているところには「大丈夫ですよ」って言ってあげるのもプロの仕事とわたしは思っている。

　まぁ、わたしにとってはどっちを使っても一緒だから、相手が望んでいる答えを出してあげたらいいと思っているだけですけどね。わたしには、頑なまでに貫く部分と、無節操なまでに相手に合わせる部分がある。

　マージャンでも決め打ちするヤツはどうしようもなくヘボで（わたしのことやけど）、それでも運がよかったら上がれるわな。プロは運に頼ったらアカン。システムも、VB6に決め打つのも、.Netに決め打つのも、Webシステムに決め打つのも、SQLに決め打つのも駄目ってこと。

　とにかく、顧客の利益を第一のプライオリティにおいて頭を使うこと。

　見方によっては無節操なのかもしれないけれど、人になんと思われようとかまわないし、大事なのは自分の中に一貫した筋があればいいんじゃないかな。それがあるのが技術者だと思う。

　おまけなんですが。

　VB6から.Netが大変な変更だとか、Javaだとか、これからはRubyとか聞くたびに、「でも、RDBMSはまだ使うんでしょう？」って思う。わたしなんかVB4の終わりごろからSQLを使っているのね。メモリーが32～64MByteってなときに数百万件（だったかな？）扱って、ループしたら1週間とかかかるバッチがあったからね。まぁあきれ果てたけど、それを直しているうちにそれなりにSQLができるようになったわけ。

　そのころに仕入れた知識で今でも喰ってるわけです。VB4の方にこだわってたらとっくに喰えなかったやろうに。逆に考えると、SQLにロジック入れたがるわたしと、ループしたがる周りと、それだけ長い間ずーっとぶつかってきてるってことですけどね（苦笑）。もう、疲れたよ。

　常識的に考えたら、コロッコロ変わる言語にロジックを入れて振り回されるより、SQLができるようになった方がはるかに効率的って、いつもと同じオチ。

　あなたはすでにSQLを会話のペースでできている！

　あなたはすでにSQLを会話のペースでできている！（答え）

　この辺が会話のペースでできたら、数百本からなる基幹システム作っても、ループするのが3本とか5本しかない。全体から見たら1％ぐらいのイレギュラー処理で、ほぼすべての機能は母言語から見ればパラメータの受け渡しとダンプ出力になるもんね、ワークテーブルも使わんし。

　上の問題ぐらいが解けるようになったら、システム構築を頂上を目指す登山だとすると、たぶん、地べたから山頂を見ているか、ヘリコプターで空から見ているか、ぐらいに違った景色に見えます。みんなが富士の樹海へ進んでいるのを見て、何とか止めてあげたいと思っているのに、なんでか嫌がるからね……どこまで上から目線なんじゃ！って（笑）。

　VB6だろうが、.Netだろうが同じやし、いつまで枝葉末節のことでガタガタ言うんでしょうね？いい加減、この業界皆さんが気づく日が来てもよさそうなもんで、あえて知らんぷりするのかな？わたしが理解できないなんか深い理由があるのかな？ ダミーのストアドプロシージャ書いて、画面や帳票から作るようになったら、そこまでは顧客側でできてしまう。これだけFWが発展してきたら、情報システム部があるぐらいの大手なら楽勝でしょ。顧客が作るんだからUIは完璧に完了するし、ダミーのストアドプロシージャは完璧な要件定義になりうる。手戻りは最小限になって、プロはテーブル設計とSQLの差し替えだけできれば良いってことに……。

　つまり、SQLができなかったらプロと認められなくなるってことか。そうなっても、わたしは全く困んないから言ってるし、むしろ歓迎だけど（笑）。

　戦略がバレてるのか……？

　だったら、ユーザが気づいてくれたらうれしいな。システムの開発コストは滅茶苦茶下がるし、ユーザが気づいたら業界は変わるのよ。大手ベンダーは要らなくなるかもしれんけどね。大手ベンダーが作ったとんでもないテーブル設計という負の遺産と戦わないといけないのだろうけど。

　……ツッコミは歓迎するけれど、長～い独り言やって（笑）。大阪弁って書きにくいし、読みにくい。もう、やらないから許してください。

　盛り上がっているようなので、ちょっとチャチャ（最近、このパターンが多いな）。

　わたしの周りには、VB6を使い続けているところは多いです。それどころか、NEC98シリーズのN88 BASICなどを使い続けている人もいます（制御系にありますね）。さすがに、NEC98シリーズはハードの提供がないので今となってはまずいかも知れないけれど、エミュレータで動かなくもない。VB6なんて、後10年ぐらいは大丈夫じゃないかと思います。

　新しい言語（技術）に価値があるのではなく、何ができるかに価値があるのですから、別に新しい言語でなくても、何も問題ないと思うのですが？

　商売上は.NETのツールを売りたかったりするので、気持ち的には「VBもJavaもやめて.NETに！」って思っていますけど、わたし自身がPHPのプロジェクトもやれば、JavaやVB6のプロジェクトもやりますからね……。新しいことがいいとか、特定の言語にこだわりはまったくありません。

　すべての費用（教育・導入・開発・メンテナンス）と、得られる効果とを検討して、もっとも効率のよいものを選ぶことにしています。

　効果を判断するときは、それぞれのファクタに対して重みがつきますが、「技術者（会社）として新しい技術の経験を得たい」というファクタに重きを置くのは、わたしは反対です。

　VB6が良いか、.NETが良いかは、顧客の立場に立って考えるべきでしょう。サポートが切れている枯れた技術と、出始めのバグだらけの開発環境とどちらが安全かといえば、枯れた技術の方が安全なのです。つまり、.NETでないと実現できない課題がなければ、VB6でもかまわない。

　顧客側の利益が変わらないとき、「技術者（会社）として新しい技術の経験を得たい」というファクタに重きを置いて.Netを選んでも良いし、「新しいことにチャレンジするリスクを取りたくない」というファクタに重きを置いてVB6でも良いのです。

　わたしは誤解されているように思いますが、「SQL！ SQL！」というのは、RDBMSを導入した以上、その機能をしっかり使った方が効率がよく、SIerなら、SQLを習得することがもっとも利用範囲が広い。SQLにロジックを寄せて開発すれば言語への依存度が低くできる。

　結果的に教育コストも低く抑えることができ、費用対効果が高いと訴えているだけなのです。

　しかし、多くの会社の新人教育を見ましたけれど、JavaやVBはそこそこのレベルまで教えているところが多いですが、SQLはまったく足りないなと感じます。

　それは、普及率から見て、あまりにもバランスが悪い。

　ミッションが怖いのにポルシェに乗ってるって、昔のマンガにあったけれど（最近はポルシェもフェラーリもオートマなので、笑い話にもなりゃしね～）、簡単なSQLしかできない技術者ってオートマ免許の走り屋って感じかな。それなりの乗り方をしないならプリウスでいいじゃない？ せっかくポルシェを買ったらそれなりの乗り方をしようよ。

　メンテナンスをファクタに入れることはあるでしょうが、顧客自身がメンテナンスするなら顧客がこなせる範囲で作るべきですけれど、「プロが『こんなの分かりません（ミッションは怖いです）』とか言うな！」ってよくキレます（苦笑）。

　話は変わりますが、本当にまったく分からないのが、「基幹システムをWebで構築する」ことです。わたしも「イントラ（ネット）」という言葉が流行った90年代後半に2回ぐらい提案したことがありますが、流行だから営業的に取りやすいというメリットしかないと思うのですけど……。

　広域LANやVPNを構築して、Webでやるメリットって何なんでしょう。外部接続がある部分だけでよいのでは？

　外部接続、マルチOS（シンクライアントとか）、マルチブラウザという要件があるなら、必然的にWebになりますが、そうでなければ、インストールのコストが軽減できることぐらいしかメリットはありません。だったら、インストール・更新機能を簡略化できるように作りこんだ方がよっぽど安くて良いモノができる。

　ところが、いまだに神話のようにWebシステムで提案してますね。わたしが変わり者だから、わたしだけ神話が理解できてないのかな～。

　特に大手SIerで、動作条件にWindowsでIE7以上（他のWebブラウザはテストしません）とか書いているのは、ちょっとあきれる。ちなみに、わたしが経験した大手の案件（下請け）は、すべて特定のWebブラウザ限定、かつ、LAN内のWebシステムでした。まぁ、そんな提案を出してる人のメールには機種依存文字が一杯だったりしますから、さもありなん。

　最近は、大きなのをC/Sで組んだことがないので何ともいえませんが……。

　C/Sにするとコネクション数は気になるところだけれど、今のマシンのスペックって、「C/Sが流行ったころの何倍よ？」って思ってしまう。64KのフレームリレーでC/Sのシステム組んでた身からすると、コンシューマを相手にしないならコネクション数のピークも知れているから、C/Sでも十分に耐えれるはず。

　まぁ、下手糞に組んだC/Sは危険というのもあるけど……。C/Sにしたら、APサーバが減るだけ運用コスト（多少は設備費も）が落ちるし、メリットは大きいのですけどね。

　普通だから、みんながやってるから、新しいから……。理屈になってないな～。

　マシンスペック、通信環境が上がったんだから、過去に戻ってもう1回見直すってのが必要なんじゃないかな。

　……そんなことを言ってるからうちは儲からないのね。

　「とにかく、新しいものじゃないと駄目です！」っていい切って、どんどん乗りかえらせるために、使いにくかろうが新しいものをお勧めしないと……。って分かっているけどそれはできないな～。

　とにかく、わたしはベストだと思えば、エクセルマクロでも納めますし、PHPでも、Javaでも、RDBMSを使わないシステムもやります。必要であれば最新の技術にもチャレンジします。SQLにこだわっているのではなく効率にこだわっているわけです。

　「各方面にケンカ売って、ちっとも効率的じゃないじゃないか？」って……。

　ごもっともでございます。

　大手SIerは大切なお客様なのに、こんなことを書いていいのかな。って思いながら書いてますけど、まぁ、よいのです。