【要望】
マーケティングのため、１ヶ月間取引のない得意先で、それ以前の半年間に５回以上取引のある得意先の一覧を出力したい。
【外部仕様（基本設計）】
■ 目的
以前に頻繁に取引があり、最近、取引のない得意先の一覧をつくりマーケティングに利用する。
■ 処理概要
ｍヶ月前から当日までに取引データがない得意先のうち、受注日が（ｍ＋ｎ）ヶ月前からｍヶ月前までの間にｃ件以上の取引データがある得意先の情報を一覧表に出力する。
ｍ、ｎ、ｃはユーザから画面で入力を受付け、それぞれ１、６、５を初期表示とする。
で、５分でＳＱＬが書ける分けないと言われ考えてみました。
実は、このコラムを書くまで周りの技術者がなかなかＳＱＬが理解出来ないのはなぜなのか、分かりませんでした。
正直に言って、サボってるだけと思っていました。
逆に、自分がなぜで分かるのか、なぜで直訳できるのか、分かっていないということでした。
では、なぜ出来ない技術者が多いか、なぜ私が出来るようになったか、前回に書いたのとダブる部分もありますが書いてみたいと思います。
先ず、お客様から、上の要望を聞いたとします。
あなたが、この業界の営業、ＳＥの方であれば、話を聞きながら外部設計 ＝＞ 内部設計まで粗く考えるはずです。
で、ＳＱＬ未経験者は解答例２に近い処理フローが頭に浮かんで、ＳＱＬ経験者は解答例１に近いフローが頭に浮かんでくるのではないでしょうか？
（顧客マスタをループするパターンも含む）
お客様と話をしながら、浮かんだフローを元に超概算の見積もりを行います。
概算の見積もり（難易度）を持たないと、その後の話が進みません。
分からないときは、持ち帰って検討しますという話になってしまいます。
概算の見積もりをもって、お客様はどれぐらいの金額で考えられているのか探ったり、駆け引きが始まります。
そのまま要望をのむとか『画面でパラメータの入力をできるようにしておきましょうか？』と提案するとか、さらに余裕があれば『どんな商品を買った得意先か絞れるようにしましょうか？』とか『ＥＲＰパッケージについて興味ありますか？』などなど。
とにかく、どれぐらいの難易度かわからない状態では話できません。
だから、優秀な人ほど処理フローまで（内部仕様・詳細設計）を一生懸命考えます。
その結果、外部仕様どころか要件定義の前段階で、大前提が暗黙のうちに出来ているのです。
この大前提は、解答例１と解答例２はどちらが頭に浮かんでいても、その後、部下や技術者に伝えるときは大差がないです。
ですから、これらを納品物として考えている人にとって、ＳＥは言語を知っている必要はない。
ということは、間違いではありません。
しかし、解答例１と解答例３の差は非常に大きいです。
その理由は、こちらもご覧ください。＜つづき 解答例１、２はそんなにおかしいか？＞
結果、その打合せは私の理想とはかけ離れた…。
理想はどうでも良いですが、受注前からカマドをつくる話になっていくわけです。
私にとっては、苦しい、悲しい打ち合わせになります。
たとえば、お客さんの予算が３０万（予想）だったとします。
私はＳＱＬ１本で２０万で出来る。
あと、１０万分いろんな提案をして、予算マックスの３０万を取りたいと考えます。
こうなれば、みんなハッピーなはずなのです。
しかし、周りの営業・技術者は５０万ぐらいかと考えます。
予算に合わせて、フローのどこかを削れないかと考えます（当然です）
ということは、提案して機能を乗っけようとする私と、フローのどこかを削ろうとする技術者と、お客様を挟んで、身内でケンカが始まります…。
変に削られたりすると、これは顧客にとって必要な機能を削ることになりますから、将来必ず再燃します。
場合によっては、開発後期に押し切られることになるでしょう。
ですから、私は余程のことがない限り顧客の要望を削ることはしません。
その打ち合わせは、せっかく身内が削る方向で話を進めているのに拒否反応を示したり、とんでもなく難易度の高そうなことを出来ると言い出したり。
周りから見ると、私はとにかく変人です。
・・・
他の技術者の意見が通ると、フロー中心に考えているからＳＱＬでは実現しにくい機能になっていたりします。
そうでなくても、カマドは作らないといけないわけです。
私の意見が通ると、私しか出来ないプロジェクトになってしまいます。
それはそれで、不幸の始まり（絵に描いた餅なんです）
でも、私は『絵に描いた餅』を本物の『餅』にするために起業したのですから、その実現はどうしたらよいか、実現をあきらめたくはないと思っています。
そして、このコラムを書いてきて、きわめて単純なことが分かりました。
ほとんどのプロジェクトで、ＳＱＬが本来の使い方をされない。
その理由は技術者が話を聞いた時点で、フローが浮かんでそのとおり進むからです。
普通の人には出来ない論理的な思考を持っているからこそ、ＳＱＬは理解しにくいのです。
理解しなくても、今までの技術で動くものができてしまうということもあって、間違った理解が蔓延しています。
スタート時点の先入観が災いしているのです。
そして、私は、処理フローも考えているけれど、それを一旦、記憶の奥に追いやることが出来る。
ＳＱＬが好きになって、そういう考えが自然に出来ていました。
そして『素人にでも出来るＳＱＬなど、技術者なら誰でも出来るはず』との先入観が災いしていることが良くわかりました。
すごく高い『バカの壁』があったわけです。
先ほども書いたとおり、ＳＥレベルの人は話を聴いたときに処理フローが頭に浮かぶはずです。
すぐには処理フローが浮かばない技術者は、処理フローを考えようとするはずです。
処理フローを考えるというのは情報処理技術者のアイデンティティであり、体にしみこんだ本能でもあるかもしれません。
しかし、ＳＱＬに処理フローはありません。
フローがないから『処理フローを考える』となった時点で、ＳＱＬの本質からかけ離れてしまうのです。
もう一度、要望と、外部仕様をじっくり見てください。
細かなテクニカルな部分についてはご自分で入門書を読んでほしいのですが、あるとき（Exists）ないとき（Not Exists）というのをヒントに直訳してみてください。
解答例３に近いものが浮かんでこないでしょうか？
外部仕様から処理フローを考えるということは、技術者の重要なスキルですが、ＳＱＬを完全に習得するまでの間、この考え方を捨て去らないとＳＱＬの本質を理解するのは難しいと思います。
<< 第１９回目 「SQLについて（安い、且つ 速いシステムを作るには)」 | | 第２１回目 「SQLについて（安い、且つ 速いシステムを作るには) 解説２」 >>
コラムの全インデックス
アーカイブ
