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

　これができれば、SQLが会話のペースでできるようになる！（かも？）という、わたしの勉強法です。長いけれど、平易に書いたつもりなので、読んでいただければ幸いです。

■ まずはプログラムの勉強法

　わたしは裕福な家庭で育ったわけではないので、ファミコンも、ステレオも、ラジカセもなかった。

　もちろんPCなんてなかった。

　そんな小学生の頃、「中学生がゲームソフトを作って何百万儲かった！」なんてTVで見たのだろう。貧乏がイヤで仕方なかったわたしは「何百万」に即座に感化されて、雑誌（多分BASIC Magazineかな？）を立ち読みした。とはいっても、小学生の脳味噌でPCなしに雑誌を読むだけでプログラムが勉強できるわけもなく、「プログラムの前にフローチャートを書きましょう」と書いていたのだけが頭に残ったようだ。

　それで、なんとなくプログラム、例えば、ゲームウオッチとか、インベーダーゲームとか、それ以外にも、ビデオの予約機能などを見ると、言語はまったく知らないのですが、とにかくフローチャートを想像するようになり、さらに、何でもフローチャートを考えるようになりました。

　例えば、朝起きるときに、

寒くて布団から出たくない
→ あと5分
→ もう5分
→ もう5分
→ トイレに行きたくなった（割込処理という言葉は知らない）
→ でも、布団から出たくない
→ トイレに行きたい ……

　突発的に「トイレ行きたい」が発生するのは、インベーダーゲームでボタンを押されたとき、ミサイルが出るのと同じか。

　コンピュータは決まったことしかできないから、「トイレ行きたい」の他に、「親が怒ってくる」とか、「腹減った」とか、「TVから面白そうな音が聞こえてくる」とか、そういうパターンをすべて書いておく必要があるのか……。

　（乱数という言葉だけは覚えていて）乱数で何分の1かの確立で用意した処理を起こせばいいわけだ。

　（ループがあって、ブレイクの判断をしていて、という言葉は当時は知らないけど）整理したらフローチャートになるな。

　でも、ゲームにしても面白くないな。

　「トイレ行こ」

ってなことを考えたりしていたわけです。

　わたしはそっちの才能がないようで、ゲームのシナリオはまったく思いつかなかったし、言語はまったく知らなかったのですけれど、正しいかどうかは別にして、何でもそんな風に考える癖が勝手についてしまったようです。

　小学校高学年でそうなっていたわたしにとっては、ごく自然な考え方ですから、「みんなも同じように考えている」と、つい最近まで思ってました。

　あまりにも周りと話が噛み合わないことがあって、自分の思考ルーチンを見直したところ、もしかして、「みんなはそんな風に考えてないのかな？」と思い至りました。社員に聞いてみると、「普通の人はそんなこと考えません」とのこと。

　自分が異常だとはなかなか認められないのですが……。異常なのでしょうか？　

　それはともかく、アルゴリズムは小学校のときに体得していたようで、19歳でHP社のワークステーションを触るようになって、実際のプログラムを見たときに何をしたかというと、仕様書なんてない、コメントもほとんどない生のソースコードを見て、分岐、ループ、サブルーチン（笑）などを探して、頭の中でフローチャートに戻し、間の処理を想像しました。

　インデントはちゃんとしてあったので、流れは何の苦もなくすぐに理解できました。

　想像したフローチャートと、プログラムの実行結果から、このIFの後の処理は「×××の処理をしているはず」「つまり、×××の処理はこんな書き方をするんだ」と理解していきます。

　全部の行の意味を理解する必要はないし、必要があればリファレンスを開けばいい。

　ソース丸ごと見えているのでブラックボックスではないのですけれど、分からないところはブラックボックスとして判断して、とにかく全体をざっくりと把握し、自分の必要なところだけを見ていました。

　分からないところはすっ飛ばせばいい、と考えていたおかげか、ブラックボックスを気にしない大雑把な性格だからか、オブジェクト指向はブラックボックスの組み合わせなので、違和感なく移行できました（毎度、苦労するのはツールの使い方の方ですね）。

　そんなわけで、初心者がどんな勉強をするのか分からないのです。

　もしかして、フローが浮かばない状態で「Hello World!」から始めるのでしょうか？ それで、プログラムができるようになるのかな……。

　無意識で考えていることが違うということは文化が違うということですから、わたしには初心者の考えることは分かりようもないのに決め付けてはいけないけれど、プログラムができない人は、フローチャートらしきものも頭にない状態で、プログラムソースの1行目から見ていくとか、言語仕様を覚えることから始めたり、人間というオブジェクトを作るのが目的なのに爪クラスから作ろうとしているのじゃないかと思う。

　そういう勉強方法よりも、最低限のアルゴリズムを理解することと、全体から見る考え方が必要なんじゃないかと思います。

　わたしが子供の頃になんとなく身に付いてしまった、何についてもフローチャートにしてみるというのは、電車の中でも、風呂の中でも、寝る前でもできる頭の体操です。これが効果的な勉強法なのかよく分かりませんが、もしかしたら、効果があるかもしれません。

■ わたしがSQLを覚えたのは？

　というわけで、小学生の頃に勝手に覚えたので、わたしはフローチャート（アルゴリズム）にするのはネイティブ（会話のペース）と言えます。オブジェクト指向も抵抗なくネイティブ並みです。

　しかし、SQLを考えるときは、当然、今までとは思考を切り替えねばなりませんでした。

　わたしはSQLは以下のように（本当はちょっと違うけど）ビジュアルで考えています。

　テーブルごとにExcelシートを思い浮かべています。

• それぞれのテーブルを並び替えて、必要なデータを抜き出す
• ブロック単位でワークのファイルに持ってくる
• 結合処理
• グループ化のための並び替え
• 計算処理（同一データの間引き）
• さらに抜き出す
• 最後に並び替え

　昔、この処理をDOS版のLotus 1-2-3で手作業でやっていました（複数のシートが扱えない頃は、横のエリアを使って……）。

　これはDBEngineの処理そのものです。

　わたしはこのような処理をLotus 1-2-3で手作業でしながら、「無駄やな～、なんか簡単に汎用的にできる仕組みにできないかな～」と、つまり「SQLみたいなものを作れないか」と思って、Lotus 1-2-3でマクロを書いたり（完成できなかったけど）していました。

　ですから、SQLを知ったときに衝撃を受け、なんとしても習得したいと思ったためか、思考の切り替えは苦にならなかったのです。

　しかし、結果的にプログラムを覚えたときと同じように、文法から入るのではなく、やりたいこと（SQLの実行計画）があってそれをSQLにするにはどうしたらいいか？ という勉強方法になりました。

　最初はAccessのGUIで書いてたのですけれど、あくまでも処理のイメージを変換していたわけです。

■ 「SQL」わたしの勉強法

　前振りが長すぎですが、SQLの勉強法についてです。

　わたしは意識してやったものではないけれど、同じことをしたらどうでしょう。時間がかかるかもしれませんが、力が付くと思います。

　というわけで、実践方法です。

　まず最初に、例題を何か用意しましょう。できればHAVING句まで使っているSQLの設計書なり、要件定義なり、基本設計なりを準備しましょう（HAVINGは使ってないけれど、前のMartin Fowler氏のでもよい）。

　それと、エクセルを用意します。

　まず、結果用のワークシートを用意してください。次に、必要なテーブルをすべてエクセルのシートにする。レコード数は数十～百件でよいので、主キー順に作ってください。

　さらに、インデックスがある場合、設定されているインデックスの数だけワークシートをコピーして、それぞれのインデックスの並び順にしてください。

　データが用意できたら、要件どおりの結果になるように、結果用のワークシートに手作業で埋めてみてください。

　あなたが行った手順こそが、ほぼDBEngineの処理です。

　その処理を記述するのに、人間に分かりやすく、DBEngineにも分かるように作られたのがSQLなのです。

　手作業でやれば判りますが、余程の間抜け（失礼）でない限り、自然に適切な並び順のデータ（インデックス）を使いますし、次の順で処理しているのが分かります。

SELECT（結果ワークシートの準備）
FROM（データの準備）
JOIN OR WHERE
GRUOP BY（グループごとに集計行を挿入して、挿入した集計行だけ見せるイメージ）
SELECT（計算処理）
HAVING
ORDER BY

　そして、あなたが行った手順では、データの塊をコピーしてることでしょう。

　つまり、その手順は集合理論で行われています。

　このとき注意することとして、作業を行うときに、SELECT、FROM……ORDER BYのどの部分を処理しているか意識しましょう。

　エクセルでは上下のレコードを参照する処理は簡単にできますが、SQLではOLAP関数でできる範囲でしかできませんから、GROUP BYの処理中以外は集計関数を使ってはいけません。

　OLAP関数が理解できるようになったらその部分は使ってもいいですけど、エクセルの式や関数の引数には同じ行にあるもののみを使うようにします。

　上下の計算が必要になるとき、つまり、結果用のワークシートの同じ行だけでは計算処理が終わらないときや、計算結果を再度処理するときは、それまでの結果を新しいワークシートにコピーして、その新しいワークシートを最終の結果用ワークシートとします。

　つまり、今まで結果用と思っていたものは、サブクエリーになるわけです。他にも、作業用のワークシートが必要になったら、それらはサブクエリーになります。

　上の条件でどんなに考えても、最終結果のワークシートができないときは、「SQLでは出来ない処理」ということになります。

　次に、実際にエクセルシートを使うのではなく、脳内にエクセルシートをイメージ出来て（このとき名称を取るだけのマスターは当然無視する）手順まで考えられるようになれば、「集合理論で手順（処理）を考えられるようになった」ことになります。慣れたら会話のペースでできるようになります（学問的には集合理論じゃないとか、そういうツッコミはちょっと置いてください）。

　あとは、

• 手順（処理） → SQL
• SQL → 手順（処理）

どちらも自在にできるようになるまで訓練です。

　会話のペースでは手順（処理）までしか考えなくてもよいけれど（でも、考えたものを記憶するにはSQL文の方が効率的です）、サブクエリーがどの部分で、何個あって、その結果が何件ぐらいになって、インデックスが使えない検索がどれぐらいあって、最終の出力数が何件ぐらいになる……ということは、「パフォーマンスは××秒ぐらい」と予想までできるようになります。

　ここまでできるようになれば、今までのプログラムは何だったの？ と思うぐらいに、爆発的な生産性＆パフォーマンスになるでしょう。

　次にテーブル設計の訓練をすればいいけれど、おそらく自然にできるようになっているし、チューニングもできるようになったのと同じです。

　このように考えると、Martin Fowler氏のSQLは不合理な手順（処理）になりますから、手順（処理）から考えれば、なかなか出てこないSQLになります。ところが同様のSQLは現場でよく見るのです。それらは、わたしの思考ルーチンでは出てこないSQLなので、どういう思考ルーチンで考えれば出てくるのか分かりませんでした。

　とはいうものの、自分の思考ルーチンも無意識にやっているのでなかなか気づかないものです。しかし、この文章を書いたおかげで気が付きました。同時に、現場でよく見るSQLが、どんな思考ルーチンで考え出されたものなのかなんとなく分かりました。

　手順（処理）を考えずに文法からSQL文を考えているでしょう？（そら、でけへんわ～）

　文法としてはSQLは最低ですからね（笑）。文法から考えたら途中で投げ出したくなるのも無理ないですし、嫌いになるでしょう。文法から考えて書ける人はある意味すごいと思う。

　わたしもSQL文の記述はなんとなく気持ち悪いし、手順はできているのに記述法が分からないってことも最初のうちはありましたから、勉強法としてSQL文の記述方法や文法から入ると、「よー分からん気持ち悪い記述」になって終わってしまうのは理解できた（のかも知れません）。

　そういえば、総務や経理の方が、短時間にSQLを高いレベルで理解できることがあるのですけれど、普段エクセルでこういう手作業をやっていて、すでに脳内に集合理論での手順ができているから、と説明も付きました。

　ともかく、やりたい手順が集合理論で脳内にイメージできていれば、それは必ずSQLで処理できます。

■ 文法について（面倒な人は飛ばして読んでください）

　余談ですが、処理順はSELECTの後にORDER BYが来てるでしょう。

　なぜかというと、計算結果でソートする必要があるときに対応するため、計算処理をするSELECTは先に処理されるわけです。

　だから、ORACLEでORDER BYした後の行位置を取りたいとき、サブクエリーで先にORDER BYを掛けてから、ROWNUM関数を使うことになります（以前はサブクエリーでORDER BYはできなかったので使えなかったですよね）。

　DBEngineは出力のORDER BYを一番最後にしますので、出力のORDER BYの結果を別のエクセルシートに貼り付けて（つまり、サブクエリー）、ROWNOM関数（エクセルではROW関数）を追加するイメージを持てば理解できます。

　なぜ、上下の計算ができないかというと、ORDER BYまでは並び順は決定されていないため、ORDER BYの処理の前に行われるSELECTで上下の計算をすることができないのです。

　OLAP関数は上下の計算ができない不便さを解消するためにできた関数です。SELECT句内（つまり、ORDER BYの手前のエクセルシート）で計算することができます。

　ですから、OLAP関数のROW_NUMBER はサブクエリーを使わなくても利用できます。

　しかし、SELECT句よりも先に実行されるWHERE句では使えませんので、OLAP関数の結果で抽出するには、サブクエリーが必要になります。

　SQLは魔法ではないのですから、自分が「DBEngineを作るとしたら」「SQLの規格を作るとしたら」と考えれば、エクセルですらできるのにSQLが上下の計算が苦手な意味も分かると思います。

■ 覚えようとしたら覚えられない

　わたしは、プログラム言語にしても、SQLにしても覚えようとはしていない。

　覚えようとしたら覚えられないものです。

　ところが、新人君のノートを見たら、ヘルプやリファレンスをまんま書き写したり、びっしり板書してたりってこともあります。

　わたしなんて、ほとんどの関数やその引数を覚えていないのに（笑）。

　学生の延長ですね。そんな字を書く練習より、理解するために脳味噌に汗をかかないとダメです。

　とにかく覚えようとする人や、何でもよいから資格を取ろうとする人（勉強したことが実務に結びつかない人）は、苦行をやっているだけで努力の方向性が間違っています。資格を取ることが悪いとは言いませんけれど、もし、資格が取れたとしても、それはさらなる苦行の入り口に立っただけですよ。

　わたしは、理解はしているけれど、記憶しているのはイメージだけです。

　そして言語を習得するのに文法は後回しです。言語が何か、RDBMSのベンダが何かなんて、最後の最後まで気にしてないのです。それは、ものすごく遠回りに思えるでしょうし、一般的な教育とは真逆で、乱暴過ぎる勉強法かもしれません。

　しかし、急がば回れです。

　イメージがつくようになれば、例えば、「OLAP関数はSELECT句内で上下にも計算できる関数」と覚える（理解する）だけで、「必要なときにリファレンスを引けばよい」という状態になるし、「平均を取るには、多分、AVG関数ってのがあるのじゃないか？」ってあたりをつけて調べられます。

　結論として、記憶力ではコンピュータには絶対に敵いませんから、最も重要な勉強法は「覚えずに理解することを心がける」ことじゃないでしょうか？

　とはいうものの、勉強法なんて性格によって違うはず。さらに、わたしは相当の変わり者なので、万人に通用しないでしょうが、1人でもエクセルで試してくれる人が居たらうれしいです。

　身に付いたら、ホントに変わるよ～。

■ 上流の人に（いい加減くどいな）　

　上流でコーディングすることがないのであれば（できたらした方がいいけどね）、手順をイメージできるようになるだけでとりあえずはOKです。「SQLで処理して欲しい」と言えるようになりますし、サブクエリーを使わねばならないポイントぐらいは指示できるし、DBサーバで処理する方を選べるようになります。

　もちろん、下流にSQLが書ける人がいなければ指示を出す必要があるので、あなたも書ける必要があるのですけどね。できる人を呼んで来れるなら、あなたは手順をイメージできるだけでもよいです。

　結果的に、テーブル設計も実にスマートになることでしょうし、テーブル設計より実装を先にした方が効率的というのも、体感的に分かるようになるでしょう。

　どんな言語でも文法なんてどうでもよく、概念の方が重要なのです。それを理解せずに、すぐに文法をイメージするから低レベルの拒否反応が出るのだと思います。

　ちなみに、APサーバで処理するということは、途中の結果のシートをメールで添付して他の人にやってもらい、次の処理依頼メール（SQL）を待つような処理になります。余程、特殊な処理でない限り、結果だけを返す方が効率的で、DBサーバの計算処理を少々減らしても、メールの送受信の回数や通信量が増えるなら、結果的にDBサーバの処理は増えてしまい逆効果です。

■ おまけ

　他人の考えていることなど分かりようもないので、憶測で「（手順も考えず）文法から考えている」っていうのは、言いすぎかなとも思う。

　わたしの文化では、手順が頭にないのに「書けるわけがない」ですから……。でも、みんな実行計画を見てないし、他の人の書いたサブクエリーがたくさん入ったSQLを解きほぐしても手順にならなくって、「何がしたいのかさっぱり分からない」って言ったら、「SQL分かんないんですか？」って言われたり（苦笑）。

　「どう考えたらこのSQLになるの？」って思うことがよくある。

　それで、もしかして（手順も考えず）文法にあてはめるだけで書こうといるのかな？ と思って書いてみました。憶測（おくそく）ですし、他の人がどう考えて書いているのか非常に興味がありますから、反論は大歓迎です。

　しかし、もし、わたしの仮説「文法から考えている」が正しくて、本当に多くの人が手順を考えずにSQLを書いているのだとしたら、

• 手順（処理） → SQL
• SQL → 手順（処理）　※これはデバッグとチューニングに必要

の翻訳も、相当、苦労するのかも知れない。

　これについて本でも書くとか、セミナーでもしたら儲かるかな（笑）。

　一応、社長なので商売、商売！

　もし、興味があるという方は info@g1sys.co.jp へメールをいただければ幸いです。