弊社で製造しているシステムでは、データの保存場所はリレーショナルデータベース内でＳＱＬというプログラミング言語を使用します。
楽天や、アマゾンなどのＷＥＢシステムも、間違いなくＳＱＬを利用しているでしょう。
ＳＱＬは、実は、ＶＢ、Ｊａｖａ、Ｃ＋＋、Ｃ＃、ＰＨＰなどのプログラミング言語と比べても、もっとも普及していて、ユーザ向けの初級シスアドでもＳＱＬは試験範囲となっています。
ＣＯＢＯＬやＣ言語と同様にＩＳＯ・ＡＮＳＩ・ＪＩＳで規定された標準言語です。
ユーザにまで技術を習得するように求めているのですから、ＳＱＬは、情報処理技術者としては必須の技術（言語）と言っていいでしょう。
ところが、ＳＱＬをまともに出来る技術者は大変少ないです。
ではなぜ、必須の技術がまともに出来ないか、弊社の入社試験の（一部改変）問題を使って説明したいと思います。
あなたがＳＱＬを経験したことがあるなら、実際に依頼を請けたとき、どのような対応をするか、どのように工数を見積もるか想像しながら問題を解いてみてください。
【問題】
以下の要望、基本設計からデータ抽出する部分について、詳細設計をＳＱＬ文を含めて作りなさい。
（制限時間１０分）
【使用するテーブル】
得意先マスタ
得意先コード
得意先名
住所
・・・
受注テーブル
受注ＩＤ
受注日
得意先コード
・・・
受注明細テーブル（今回は不要）
受注ＩＤ
受注明細ＩＤ
商品コード
数量
単価
・・・
【要望】
マーケティングのため、１ヶ月間取引のない得意先で、それ以前の半年間に５回以上取引のある得意先の一覧を出力したい。
【基本設計（外部仕様）】
■ 目的
以前に頻繁に取引があり、最近、取引のない得意先の一覧をつくりマーケティングに利用する。
■ 処理概要
受注日が（ｍ＋ｎ）ヶ月前からｍヶ月前までの間にｃ件以上の取引データがあり、ｍヶ月前以降に取引データのない、得意先の情報を一覧表に出力する。
ｍ、ｎ、ｃはユーザから画面で入力を受付け、それぞれ１、６、５を初期表示とする。
解答例１、解答例２と解答例４、解答例５を比べると、処理速度は１０～１００倍ぐらい差が出ると思います。
実際、解答例１を１０分で書くのはかなり大変です。
もし、１０分で書けたとしたら、あなたはスーパーＳＥとか、カリスマＳＥとか呼ばれているのではないでしょうか。
でも、３５点です。
ＳＱＬを熟知している人なら解答例３を５分ぐらいで出来るでしょう。
ただし、周りから変人扱いされているかもしれません。
解答例４、解答例５を５分で書けたら・・・。
凄腕ですね。 一騎当千とはあなたのことを言うと思います（笑）。
私は解答例３を書いて『もっとエレガンスに…』と思わないと、解答例４、解答例５は出来ません。
解答例４・５が出来るということは、頭の中で実行計画を作れるということでしょう。
周りが理解してくれていることをお祈りいたします。
ＳＱＬというのは元の名前 SEQUEL (Structured English Query Language)にあるとおり、英語という自然言語に近い、ユーザでも理解できるように作られた言語です。
つまり、基本設計を直接翻訳すればプログラムになる様に作られた言語なのです。
事実、解答例３は、基本設計を直訳しただけの詳細設計というよりもプログラムです。
難しそうに見えても、WHERE句を除けば得意先マスタのダンププログラムに過ぎないということが分かるでしょうか？
では、あなたが最初に思い浮かんだ見積もりは、１０分で書けるWHERE句が付いただけの得意先マスタのダンププログラムの見積もりになっていたでしょうか？
解答例１、解答例２を想像した人とは、プログラムの処理速度だけでなく、 開発費も倍以上の差が出るでしょう。
上の例は簡単な例ですが（ただし、データ件数によっては夜間バッチで処理する必要もあるかも）、もっと大きなシステムでもまっとうなテーブル設計ができていれば、９０％以上の処理は外部設計を直接翻訳するだけで実現できます。
もちろん、ＳＱＬはどうしても実現できない処理がいくつかありますが、それを避けてテーブルの設計を行う。
それがテーブル設計者の腕の見せ所なのです。
そして、基本設計を直訳した解答例３から、解答例４、解答例５を作るのがプログラマの腕の見せ所です。
しかし、解答例１、解答例２は、ＣＯＢＯＬなど第３世代言語で作成する場合とほぼ同じ構造になるため、今までそうしてシステムを作ってきた技術者にとっては簡単と感じる様です。
実際、９０％以上の技術者が解答例１か解答例２のパターンで答えると思います。
結果、解答例１のような詳細設計が出回ることとなり、ＳＱＬのテクニックを持っているプログラマもそのとおり作るしかないということです。
そのため、出来たシステムは、ソースの量も、仕様書の量も倍以上、テスト・バグはさらに倍（私のストレスはさらに倍！）になると言っても過言ではありません。
また、新人はその作り方が正しいと信じてスキルを磨きます。
そのため、なかなか業界としての技術革新が起きません。
たとえるなら、最新のＩＨクッキングヒータを備えたキッチンなのに、カマドでご飯を炊くレシピが届く。
そのためキッチンの横にカマドを作ってご飯を炊いて、ＩＨクッキングヒータはお湯を沸かすためにしか使わない。
って感じでしょうか。
そんなプログラムが出来上がるのです。
しかも、最新のＩＨクッキングヒータは顧客に高い金を出させて買ってもらっているのです。
・・・９対１ではどちらが正しいとされるか、私がカマドをつぶして回っても単なるデストロイヤーでしかありません。
無理してやっても、全員が理解できなかったら、手法が混在してしまい、どちらも理解できる人にしかメンテナンスできなくなります。
しかし、何とか啓蒙したいと考えています。
基本設計を書く、つまり、システムのグランドデザインをする上級ＳＥが実際のプログラムを書くわけではないので『今更、プログラミング言語を…』ということで、ＳＱＬなど初歩しか知らない人がほとんどです。
これが、いつまでたってもＳＱＬが本来の使われ方をしない最大の元凶です。
ユーザにまで理解を求めているのに、プロが出来ないでどうするのか…。
たとえば、問題のような要望を受けたときどう部下に指示しますか？
どれぐらいの工数を想像しましたか？
「抽出条件このとおり、あとは単なるダンプ」
と言えますか？
言えれば、あなたの部下はインターネットで調べて解答例４、解答例５をひねり出してくる可能性があります。
その後、あなたの部下は、少ないステップで出来るＳＱＬで処理する様になるでしょう。
基本設計≒プログラムという、夢のプロジェクトに一歩近づきます。
しかし、『こんなふうに処理フローを書いてね』とか『ワークの定義書は…』って指示しますよね。
そんな指示をした時点で、あなたの部下がどんなにＳＱＬを勉強していても、解答例１のプログラムしか出来てこないのは当たり前です。
結果、勉強している部下は嫌になり、勉強していない部下は、そのまま育っていくことになります。
負のスパイラルの完成です。
私にも、上級ＳＥが『今更』と思うことは十分理解できます。しかし、ＳＱＬ≒基本設計ですから、ＳＱＬを知らずに基本設計を書くのも、基本設計（要件）を理解できずにＳＱＬを書くのも大きな問題があるのです。
Ｊａｖａのシステムの基本設計を書くのに、Ｊａｖａのプログラムが書ける必要はありませんが、ＳＱＬを理解しておかないと間違った方向（効率的ではない方向）へ連れて行ってしまう可能性が高いです。
繰り返しますが、ＳＱＬはユーザでも理解できるように作られた言語なのですから、業務を理解している上級ＳＥほど短時間に高いレベルで習得できます。
肩肘張らずに簡単と思って取り組めば、素人に出来てあなたに出来ないはずはありません。
こんな駄文は『今頃何を言ってるの？』と笑い飛ばされる時代が早く来てほしい。
そう願わずにはいられません。
<< 第１８回目 「阪神電鉄株買収問題について」 | | 第２０回目 「SQLについて（安い、且つ 速いシステムを作るには) 解説１」 >>
コラムの全インデックス
記事一覧 (42)
