上流の技術者はSQLを習得すべき
あっちこっちで書いていることですが、上流工程を担当するコンサル、SEの皆様、一度、以下の要望を聞いたとき、どのような提案をするか、見積もりをするか、思い浮かべながら読んでみてください。
客 きめ細かい顧客サポートをしたいので、以前より、当月の取引が落ちている得意先に営業をかけたいからリストアップして欲しいんだけど。
私 以前というのはどれぐらい前ですか？
客 半年ぐらいと、今月の受注状態を比べられたらいいかな。
私 受注状態というのは、取引回数でいいでしょうか？
客 そうだね、半年間の平均とこの1カ月間の受注額の割合を画面で入力できるようにして、××％以下の顧客を抜き出すようにしてもらえれば。
私 受注額ですか……。
客 あと、小さな消耗品は省いて欲しいし、商品区分ごとに情報を出して欲しいな。
私 出力の形態は、CSV、Excel、帳票、タックシール、ＤDM差込印刷、いずれでも可能ですよ。
客 できるの？ Excelでいいや。見積もりよろしく。
何人日と思いましたか？
技術者に聞かないと判らない？ あなたは技術者じゃないのね。
私は、これぐらいなら、会話のスピードでSQL文の脳内コーディングが終わっています。
ついでに、パフォーマンスのあたりをつけてしゃべっています。
私はデータ量の多いテーブルを対象として、自分の顧客の実DBで、以下の様なSQLのレスポンスの目安としてを持っています。
-- SQL A
SELECT SUM(単価*数量), 得意先ID, 商品ID
FROM 受注トラン
WHERE
/* 以下それぞれ */
全部
1年分
半年分
1月分
GROUP BY 得意先ID, 商品ID
-- SQL B
SELECT SUM(単価*数量), 得意先ID
FROM 受注トラン
WHERE
/* 以下それぞれ */
全部
1年分
半年分
1月分
GROUP BY 得意先ID
-- SQL C
SELECT SUM(単価*数量)
FROM 受注トラン
WHERE
/* 以下それぞれ */
全部
1年分
半年分
1月分
それぞれ、どれぐらいのレスポンスで返るか把握しているでしょうか？
日中（業務中）投げてはいけないクエリーはどれか判っていますか？
-- SQL D
SELECT SUM(単価*数量), AVG(単価*数量), COUNT(*) …
FROM 受注トラン
WHERE
/* 以下それぞれ */
全部
1年分
半年分
1月分
以下のSQL E、Fでどれぐらい差が出るか知っていますか？
--SQL E
SELECT COUNT(*)
FROM
受注トラン jt
INNER JOIN 得意先マスタ tm
ON jt.得意先ID = tm.得意先ID
--SQL F
SELECT COUNT(*)
FROM
受注トラン jt
INNER JOIN 得意先マスタ tm
ON jt.得意先ID = tm.得意先ID + 0
/* SQL Fは危険すぎるのでこれぐらいの方が良いかも
SELECT COUNT(*)
FROM
(SELECT TOP 100000 FROM 受注トラン) jt
INNER JOIN 得意先マスタ tm
ON jt.得意先ID = tm.得意先ID + 0
*/
SQL CとDを比べても、ほとんどパフォーマンスの差はないと判ります。つまり、当たり前ですが四則演算は少々増えてもパフォーマンスに差は付かない。ですから、単純な集計のレスポンスの目安を持っていれば良いわけです。
SQL Eは、大きなトランをフルスキャンしながら、得意先マスタをインデックスを使って結合するときのパフォーマンスを測り、SQL Fはインデックスを外したときのパフォーマンスを測っています（得意先IDが文字列のときは、+ ’’ || ’’ などに置き換えてください）。
何件かの顧客でこれぐらいの単純な目安を持っていれば、それ以外も予測が付きます。ループで処理したら予測はできませんけど、1文のSQLで処理できるなら、レスポンスは予測できるのです。
もちろん、規模や業務によって違いますから一概には言えませんが、私も相当に大きなDBに関わってきていますけれど、普通に動いているDBなら、おそらく1年分までは大丈夫です。
逆に、保持期間が5年を超えるようなDBで、1年分（を抽出するまではインデックススキャンする必要がある）のクエリーが投げれない状態なら、他にも障害が起きている可能性が高いです。
以上の様な基準で目安を持っていれば、上の要望は
SELECT SUM(単価*数量)
FROM 受注トラン
WHERE
1年分
のレスポンスと同等かそれより早く返せると、大まかに判断できます（もちろん、出力されるデータ量によって物理的な出力の時間も掛かりますけれど）。
ですから、実際の現場では、上の要望を聞いたときに、規模や運用（サーバ負荷）などを勘案してバッチ処理を検討するか、思い浮かんだSQLで×秒ぐらいのレスポンスで返せるから「×秒ぐらい待てますか？」って返答するか、会話をしながら考える必要があるでしょう。
バッチ処理を入れたらリアルな結果（タイムラグが発生）は返ってこないし、運用の負荷も増えるのですから、この判断はまさしく上流の仕事です。
上の処理は、1つのSQL文で返せない、つまりループの中で処理すると、そこそこの大きさのシステムであれば大変なことになります。
バッチ処理を選択しなかったら、上流のSEは下流のSE・PGに「大体こんなSQLで」と、指導して始めて上流の役割が果たせるというものです。
ところが、コンサルを名乗っていても、こういうレスポンスの目安を持ってない。当然のようにSQLも書けない。
人月何百万も取って「何か難しそう」とか、「データ量が多い」からとか、そういう根拠（になっていない根拠）で、「夜間バッチで予め処理しておきます」と言い出したり、ご用聞きのように言われたとおり下流に伝えるだけだったりする人が非常に多い。というか、ほとんど全員じゃないかと思う。
上の例で顧客と話した上流技術者の選択と結果をまとめると、
- バッチ処理を選択
→ 処理のタイミングなどの調整（運用コスト増） - ループで処理するように伝える
→ 下流の技術者がループで処理（デスマーチ）
→ 下流の技術者がループではできないと反乱（大喧嘩） - とりあえず言われたとおり伝える
→ 下流の技術者がループで処理（デスマーチ）
→ 下流の技術者がSQLで処理（ラッキー） - SQL文まで指示する
→ 0.5～2人日ほどで完了
と分かれます。
1のタイプの人は、とりあえずデスマーチは回避できています。ベストソリューションを提供しているとはいえません。
2と3のタイプの人が上流に居たら、デスマーチに陥るかどうかは、運しだいですが、運に任せるなんて、技術者とも、プロともいえないのではないでしょうか？
4、つまり上流で会話のスピードで1文のSQLになっていれば、クラサバだろうが、Webだろうが、エクセルのマクロだろうが、その後の処理はダンプ出力と同じですから、大差ないです。
どんな言語でも、新人でもできて欲しいレベルです。
1であれば、アウトソーシング（オフショア）もできるでしょう。
4であれば、上流のSEと新人のPGという、一般的に見ない組み合わせになり、アウトソーシング（オフショア）するために切ろうとすると、逆に無駄が発生します。新人の客先デビューも極めて早い段階で可能になります。母言語が変わったときのショックも、母言語に大したロジックが入ってないので、大幅に減らすことができます。
「SQLなんて全く使わない」というシステムを担当しているんじゃないなら、上流のSEを名乗るなら、4まで来て欲しい。今できなくても良いのですけれど、上流で「SQLが高いレベルでできる」ということを、誰も目指していない（断定したらイカンかな）のですから、どうしようもないわけです。
こんな小さな例でも、差が付くのです。大きなシステムになれば、もう果てしない差になります。大きかったら理想どおりにいかないのではなく、もっと大きな差になります。
1、2、3のレベルの人は、本当にまったく意味がわかっていないのですけれど、その人がテーブル設計したりするのですから、大きなシステムになればなるほど、想像するだけでもゾッとします。プレハブ工法しか知らない技術者が、50階建てのビルの基礎を設計している。なんてイメージですかね。
ただ、大きな差になることを、理解できる人がいないだけの話です。
わかっていれば、最終的に半分以下の工数で済むはずですから、上流全員を1カ月かけて再教育してからかかっても元は取れます。私がかつて自習した頃よりは、環境は整っていますからできなくないはずです。それでも、あるレベルに到達できない人は「格下げする」ぐらいのお触れを出せば一変するでしょう。
つまり、「SQLが高いレベルでできること」というのが上流の技術者の必須のスキルと認識されれば、業界が変わると私は信じています。
しかし、2（3）のパターンでデスマーチになったとき、「なぜ、1を選択しなかった」と追求され、反省して1を目指すようになる。4以外ならアウトソーシング（オフショア）した方が利益率が上がりますから、それを目指すでしょう。
結果として、いつまでたっても業界は良くならない。
4のパターンは、弊社のみで終わらせることができる規模のシステムであればできます。
しかし、弊社で終わらせられない規模のシステムのときは、4以外のタイプが上流に来ることになる。3のタイプなら、ご用聞きと割り切って付き合うこともできるけれど、1と2のタイプは一般的には優秀とされていますから問題です。
それに、下流に他社の技術者が入っても、お互いに技術のギャップで悩むことになる。
いずれにしても私は、社長というある程度のパワーを持って、異を唱えるものを全力で潰しにいくことになる。内部紛争をやっていて、巨大プロジェクトが終わるわけがないけれど、「業界を変えてやる！」を目標としているので衝突は避けれないため、上流に（下流にも）バトルを挑んでいくわけです。
もっとも、会社も大きくなっていない。もちろん、業界も変わってない。ということは、バトルは敗北に終わってきたということです。情けない。
私は、技術者としての矜持と、経営者として利益を追求しなければならない（その方法を知らないわけではない）という矛盾に葛藤し、社員と対決し、上流と対決し、もう、本当に意地になって、勝手に悶々としているバカなドンキホーテです。
実際には、上流と対決しても、社員と対決しても噛み合わず、議論にならないだけで、本当に風車を相手にしているような寂しさ、虚しさがあります。
私が思うとおりできないのは、技術的にどこに問題があるのか議論したいのですけれど、
「誰もできない」
「みんなやってない」
「できるわけない」
という理由しか聞けません。
意地になる私が子供なのでしょうし、海外ではどうのと言いたくはないですが、おそらく、「誰も」「みんな」を言い出したら、海外ではプロの技術者とは認められないのではないかと思っています。
「誰もできない」ってプロが堂々と言ってどうするねん！
私は、技術者らしい理論的な反論を聞きたいのです。
ですから、ここで炎上してでも、議論ができたらと思って書いています。
ちょっと燃料投下（こんな言葉使ったの初めてです）。
弊社の高校中退の2年生PGでも、業務知識はまだまだですが、上ぐらいの例題であれば、ほぼ会話のスピードでこなします。
しかし、全員が学歴信奉者ではないだろうけれど、コンサル、上流SEというのは、ITの専門家でしょう。少なくとも自分の専門分野で、自分よりも経験の浅い技術者に負けて、結果、ベストソリューションが提供できない。
それでも、あなたは自分はプロだと胸を張って言えますか？
ぜひ、炎上して欲しいな（笑）
対決するぞ！
コメント
インドリ
仰るとおりだと思います。
私はシステムの案件を請け負って一人で構築していた者ですが、SQLなどの実装面も知っておかないとシステムは構築できません。
なので私は上流／下流の区分がある事自体を問題視しています。
プロならば、会話するのと同時に脳内で設計書などを書き、データの正規化を行い、ある程度のプログラミングまで行うものです。
現在は上流は実装を知らなくてもいいという風潮ですが、それは果たしてプロと呼べるのか？知らないことを自慢していいのかと疑問を感じています。
エンドユーザはきっと、プロだと思って注文している事でしょう。
家を建てて欲しいと思って注文した相手が建築を知らないのでは、お客様にしてみれば詐欺と同じだと思います。
これでは耐震偽装ならぬシステム偽装です。
インドリさん
はじめまして（？もしかして、CodeZineで書いてる人ですか？）
ありがたいのですけれど、炎上して欲しいのに賛同されたら…（笑）
次のエントリーに書かせていただきましたが（書き溜めてあったので連投で）私は、上流・下流じゃなく、外部・内部（・インターフェース）と分けるべきと思っています。
インターフェース（社内標準） → 外部 → 内部 の順で構築するようになれば、業界は変わると考えています。
多分、一人でシステムを仕上げるときは、なんとなくそうなるのではないでしょうか？
理解者がいれば大規模でも可能だと思うのですけれど。
tripod
お客様と会話しながらデータ構造とアルゴリズムの候補を複数頭の中に作ってどれが適切かを考える程度のことは脳が勝手にやるようになってますが、SQLでものを考えたりはしませんね。
SQLとは無関係なパッケージ製品を10年近くやってきて、RDBMSを使うようなったのはここ三年ほどなので、そっちで考えるのは難しいです。アマチュア時代はRDBMSなんて聞いたこともありませんでしたし。
そういう人間からすると、(テーブルと)SQLで考えろというのは暴論に聞こえます。データ構造とアルゴリズムを考えろ、なら理解できますが、これだと抽象度が高すぎますか？
＃要求を聞きながら実装を考えると、実装せずに済ます手を考えるという選択肢が抜け落ちやすいので、危険といえば危険です。
tripod さん
こんばんは。
本文の例で、1年分のデータ量が2G程度のシステムだったとしましょう。
対象顧客が1000件だったとして、どれぐらいの処理時間で返せて、どれぐらいの工数で作れますか？
出力がCSVなら、ある程度のデータがキャッシュされている前提で、10秒以内の処理時間で、30分あれば作ることが可能でしょう。
アルゴリズムで考えて処理時間、工数ともに超えれる可能性がありますか？
なら、文句はないです。
しかし、本文にも書きましたが、アルゴリズムで考えれば「バッチ処理で予め集計しておきます」と言いかねない。
品質も、工数も明らかに違うものになりかねないわけです。
昔々の話です。
「配列禁止」というプロジェクトがありました。
信じられなかったけれど、コーディング規約ですからやらされました。
結果、配列を使わなくても、全体の工数は3割しか変わりませんでした。
配列のできる人、できない人。
SQLのできる人、できない人。
できない人に合わせるべきですか、できる人に合わせるべきですか？
暴論とおっしゃるなら、できない人に合わせるべきとお考えのようで、その根拠は何ですか？
習得に掛かる時間ですか？
そもそもイヤだから？
RDBMSを使うなら、SQLで考えないと、どこかで必ず躓きます。
ちなみに、基本はアルゴリズムです。
アルゴリズムが浮かばない人は、チューニングできませんし、私は、実は、アルゴリズム → 等価のSQLと考えています。
DBエンジンが、最適なアルゴリズムで処理するようにSQL文で指示するのです。
↑これ、勘違いしている人が意外と多いところです。
正論じゃないでしょうか？炎上しないですよ…。
私はSEとしてあるお客さんのところに常駐していますが、データ抽出の依頼というのはかなりの頻度で来ます。その度に長いSQLをパフォーマンスを考慮しながら書いていますが（だいたい半日くらい）、それで満足するケースがほとんどです。
たまに、どうしてもSQLでは難しい要求があるので、バッチを組んでやりましょう…という話になるのですが、そうすると一気に工数が1人月くらいになってしまいます。
私が設計して、プログラマに渡して…となるのですが、データ構造とか業務知識とかの知識が曖昧なプログラマなので（大抵そうですが）、どうしても工数が膨らんでしまいます。
SIerの売上からすれば1人月かけた方が良いのでしょうが、それがお客さんのためになるかというと違いますよね。
ただ、気になることがあるとすれば、そうやってSEがこなしてしまうと、プログラマが業務知識を付ける機会が減ってしまうことです。別の議論になってしまいますが…。
inoccu さん
こんばんは。
炎上して欲しいんですよ。
現実、できない人がほとんどですから…。
できない人はこんなとこ見ないか。
PGに業務知識をつけるために、次に書かせていただきます。
書き溜めていたので連投ですみません。
tripod
たぶん、RDBMSを使うことが前提にある人間と、そうでない人間の感覚の差が出ているんだと思います。
私にとって、RDBMSはデータ構造やアルゴリズムの一部です。
RDBMSを使わないとパフォーマンスが出ないと判断した場合は、当然使います。
必要がない場合は、システムを無意味に複雑化するだけなので使いません。
私が経験してきたプロジェクトの場合、どちらかと言えばRDBMSを使うシステムが例外的です。
暴論と感じるのは、この辺の判断を飛ばしてSQLで考えろと仰る辺りですね。
(例えば)httpdを作るのにもSQLの知識がいるのかと、突っ込みたくなります。
turbo
特定の分野のプロフェッショナルがいていいのでは？
ＳＱＬができなくても、特定の分野で長けていれば、認めてもらいたいですね。
私はSQLは初心者レベルですが、Java SEの範囲は強力な守備範囲です。
SQLが初心者レベルであっても、JDBC経由で大雑把なデータを抽出して、
Java内でデータを加工することができます。
結果的に工数が1日くらい遅くなる可能性もありますが、許容範囲かもしれません。
turboさん
おはようございます。
工数が1日というのは、ベースが何日でしょう。
100日に対して1日増えるなら1%の増加ですけれど、inoccu さんも仰っている通り、SQLで処理できるものなら長くても1本1日で出来ます。
出力部分に時間を掛けても1日ぐらいでしょう。
2人日が3人日になったら、許容範囲とは行かないですよ。
顧客の目から見ても、経営者の目から見ても、それは許容できません。
「Java内でデータを加工」というのは、人によっては、ある程度、Java内でSQL文を生成しているのですね。
言語が絡み合って分けれないのですから、究極のスパゲッティプログラムと思っています。
「みんなやっているから気にならない」という人も多いですけれど…「みんなやっている」は理屈じゃないですよね。
インドリ
返信有難う生島さん。
お察しの通り、CodeZineで仮想CPUの記事を書いているインドリです。
>私は、上流・下流じゃなく、外部・内部（・インターフェース）と分けるべきと思っています。
同感です。ANSI/x3/SPARC3層スキーマ理論もある事ですし正しいと思います。
ここからはコメントの感想です。失礼、面白いので書きたくなりました。
他の方の意見を見て思ったのですが、SQLが必要の部分は確かにシステム内容により変るかもしれませんね。
基幹系業務システムではRDBMSが必須なので気にしていませんでしたが、無いプロジェクトの場合はどうなんだろ・・・
システムに必要な情報の第三正規化（頭の整理）が出来るか否かがポイントかな？
結局のところ問題の本質は、「本当にそのシステムのプロか？」という点だと思います。
特定の分野のプロフェッショナルについては居た方がいいですよね。
私の様な分散型＋熟練職人の特化型でシステムを構築するのが理想的だと思います。
複数の@ITブロガーの記事を読んで確信したのですが、やっぱり口だけの素人は要りません。
tripod さん
インドリ さん
どうもありがとうございます。
> RDBMSが必須なので気にしていませんでしたが、無いプロジェクトの場合はどうなんだろ・・・
弊社は面白そうなら何でも手を出すおバカなので、RDBMSが全く関係ないシステムも結構やるのですけれど、必須を前提で話していました。
すみません。
VB.NetでCPUも関係ないですものね。
続きも、RDBMSが必須の話ですが、また読んでいただければ幸いです。
tripod
技術者としての母国語が違うと考え方も変わってくるんだな、というのがここまでの感想ですね。
私の場合、BASIC/アセンブラ/C++/Java辺りであれば、その言語で考えるのが日常になっています。
SQLやHaskell等の関数型言語、MapReduceアルゴリズムはそれなりに身に付いてはいるものの、ネイティブではなく外国語としての位置づけに止まっています。
これは、そういう経験を積んで来たからそうなったとしか言いようがありません。
＃そもそも、興味がRDBMSに向いてなかった、というのも大きいですが。
生島さんのような、企業システム(?)を中心に経験されてきた方であれば、逆にSQLが母国語になるのでしょう。
Google社員であれば、MapReduceで考えられないと大規模データ関係は任せられないということになるのでしょう。
そういう多様性を無視して、生島さん個人の経験のみが強く反映された(悪くいえば)独善的な「べき論」を展開されているので違和感を感じるし、暴論と受け止めてしまうのだと思います。
インドリ
生島さん、こんにちは。先ほどは挨拶が抜けており失礼いたしました。
生島さんの記事大変興味深いので続きを楽しみにしております。
インドリ さん
こんにちは。
挨拶はいいんじゃないですかね。
他の人も読むので長くなると面倒だし。
今後は無礼講ということで。
明日、掲載になるそうです。
今までのは前振りなので（笑）
是非、読んでください。
turbo
コメントありがとうございます。
生島さんのコメントを拝読しますと、Javaに関してはほとんどご存じでないという印象です。
そのような方とはアプリケーションサーバやフレームワークといった話は難しいと考えます。
turboさん
おはようございます。
コメントありがとうございます。
議論したいので、ドンドンお願いします。
> 生島さんのコメントを拝読しますと、Javaに関してはほとんどご存じでないという印象です。
少なくとも、貴方はSQLは初心者なのでしょう？
初心者の貴方が、SQLで処理した方が良いという人に意見するのに、そういう言い方は良くないと思いますよ。
技術者ならもっと論理的に話できないと。
貴方のJavaのプログラムでは、
> JDBC経由で大雑把なデータを抽出して
ということは、WHERE句をJava内で作ってるでしょう。← 決め付けは良くないけど
sql += "WHERE ";
If (チェクボックス) {
sql += " KBN = 1";
}
ってなことをしてるのでは？
これ、SQL文とJavaが分離できないでしょう。
私は上のようなものが1つでも入ったら、スパゲッティと思ってますけど、全面的にやってるプロジェクトが多いですね。
私は、JavaもSQLもそれなりにやった上で、SQLで処理させた方が工数も減るし、パフォーマンスも良くなると話しているわけです。
ここまでは前振りです。
Javaでという人に向けても、続きを書きました。
今日アップされるそうですから、是非、読んでみてください。
turbo
Javaで処理させたほうが工数が減るような話になれば、
「上流の技術者はJavaを習得すべき」
という話になりますね。
私からのコメントはこれくらいにします。
U.K.
「ハンマーしか持ってない人は、問題がなんでも釘に見える」という話を思い出しました。きっと「１＋２は？」と聞かれてもSQLで考えるんでしょうね。すごいですね。家族に裏でバカにされていないか心配です。
そんな極端な話じゃ揚げ足とりだって？いやいや、
> RDBMSが全く関係ないシステムも結構やるのですけれど、必須を前提で話していました。
RDMSが全く関係ないシステムやっているにも関わらずSQL必須が前提になってるということは、あなたの脳はそう染まっているんですよ。
これまでのコメントで
> 技術者としての母国語が違うと考え方も変わってくるんだな
と書いている方がいらっしゃいますが、私も同意見です。
たまたまSQLでうまくいく経験が多かった程度で他人もそうだと思ってしまうあたりに人間としての器の小ささが透けて見えます。あなたにとってそれが良いと思うのは勝手ですが、「SQLを知らずば技術者にあらず」みたいな書き方は鼻につきますね。
あんまんが好きだからといって「あんまんにあらざれば中華まんにあらず」とか言ってたらガキでしょう。
> 初心者の貴方が、SQLで処理した方が良いという人に意見するのに、そういう言い方は良くないと思いますよ。
他人に「肉まんも悪くないですよ」と言われたら「中華まん初心者の貴方が、あんまんが良いという人に意見するのに、そういう言い方は良くないと思いますよ。」て返してるように見えます。こんなのただの好みなんですけど、あなたはとても論理的ですね。論理的過ぎて頭が痛くなります。
あんまんで止まってるあたりがあなたの限界なのでしょうね。
そうしている間に、デキる人は「肉まんも良いですね」「ほう、あんまんも悪くない」「おぉ、寝起きにカレーまんは目が覚めて良い」「なんとプリンまん！」という具合に広がって、適切な使い分け（食べ分け）ができるようになるわけです。
あなたが取り残されて淘汰されるのは自由ですが、社員がそんな「あんまん教」に入信させられて、あんまんマンセーしないと評価を下げられる環境に囲われ、そしてあなたに道連れにされるのはあまりにも不憫だなぁと思う次第です。
U.K. さん
はじめまして。
RDBMSを使わないシステムで、SQLは関係ないですから、SQLで考えることは必要ないです。あまりに当たり前すぎて書かなかっただけで、枝葉末節のことだと思います。
逆に、RDBMSを使うなら、SQLで考えた方がいい。
> たまたまSQLでうまくいく経験が多かった程度で他人もそうだと
この辺り、他人もそうだと断言できます。
言語なんて、できるようになれば、最終的な工数はコーディング量のn乗に比例してきます。パフォーマンスも、ちゃんとチューニングすればSQLの方が良くなるのは、構造上証明ができます。
もっとも、SQLができない人にやらせたら無限に時間は掛かります。
「SQLができない」人の言い訳としか思えないのですけれど、技術者が特定の技術（SQL）を避けて、結果、工数は数倍～十倍、パフォーマンスは十倍～百倍のシステムを納品しているわけです。
その現実がおかしいと考えています。
bobo
興味深く拝見しましたが、いくつか疑問点があります。
RDBMSを使う、使わない以前に用件を満たすために実装が必要かを考えることが重要であり、SQL等については別の問題だと思います。
それにコンサルなら「きめ細かい顧客サポートをしたいので・・」に対することも視野に入れる必要があると思っています。
また、見積りに対しても、SQLで指示する場合「0.5～2人日ほどで完了」となっていますが、世の中のシステムが全てSQLでまかなえるはずもなく、Webシステムなら画面デザイン、使い勝手なども工数を見積もる上で重要になると思います、逆にこちらの方が重要になる場合も多いと思います。
bobo さん
おはようございます。
> それにコンサルなら「きめ細かい顧客サポートをしたいので・・」に対することも
おっしゃるとおりですが、そこまでいくと論旨がズレちゃいますからね。
1つの記事ですから、ある論点に絞って書いているだけなのですけれど。
コンサルが登場するような局面において、顧客マスタ・受注データがRDBMSに入っていないというなら、汎用機かオフコンですね。
それ以外の余りにもマイナーなことをここで書いても意味がないですし、汎用機やオフコンは確立された手法があるので、それにケチをつけるつもりはありません。
これも論旨がズレるので無視してしまっています。すみません。
> 世の中のシステムが全てSQLでまかなえるはずもなく、Webシステムなら
> 画面デザイン、使い勝手なども工数を見積もる上で重要になると思います
次の記事に書かせていただいていますので、ご覧ください。
オブジェクト指向派（私もそうなのですけど）の人が多いようですので、MVCモデルで組んでいたとします。
記事の例でM(Model)の部分がSQLになるわけで、オブジェクト指向派の達人なら、ここが30分で作れるか、作れたとしてもパフォーマンスは構造上出せません。
つまり、
「どんなに努力しても越えられない壁がある」手法と、
「努力すれば多くの問題を越えられる」手法があるわけです。
技術者としてどちらを選択するのが正しいでしょう。
短期的には、新たなものを習得するより、（越えられない壁を認識し）とにかく自分の現在のスキルを磨くのを選択する方が良いかもしれません。
しかし、今のできるできない、好き嫌いで選択するのは、技術者としておかしくないですか？技術者であるなら、どんなに妙な言語（技術）であっても、ポテンシャルで判断すべきと思っています。
私はオヤジ(38歳)ですが、若い技術者達は、今ではなく未来を見て選択して欲しい。特に、ここでコメントをしてくれるような積極的で意識の高い技術者が、なぜ、ポテンシャルの高い方の技術を選ばないのか不思議なのです。
仮に「ポテンシャルが高いはずがない」と思うなら、上の例を30分より短い工数で、上の例より速いレスポンスで返す方法を示してもらわないと、水掛け論になってしまいます。
もっとも、経営者的には誉められる判断かどうかは微妙です。
そこはバカな社長でいいですよ。（笑）
bobo
生島勘富さん
私も34歳なので、それほど変わらないと思います。
オブジェクト指向派ですが、SQLについても使っていました。現在はコンサルの仕事をしていますが。。
ですが、ユーザのニーズはさまざまです。DBを使用すれば解決するものばかりでもないと思っています。重要なのは何を必要としているかを考え、本質を捉え提案できる力だと思っています。
>「どんなに努力しても越えられない壁がある」手法と、
>「努力すれば多くの問題を越えられる」手法があるわけです。
今回は、たまたまSQLを熟知していれば解決できただけで、全てではないと思います。
例えば、顧客のニーズが在庫を削減したいとなった場合、SQLを熟知していれば何か提案できますか？
これは、私がSEとして勤務していたとき相談されたことです。
業務知識、DB、ネットワーク、セキュリティ・・その中の一つがSQLで万能ではないと思います。
逆に知らなくても要望は満たせる場合もあるということを説明せず、SQLを理解すればいいということは納得できません。
必須のスキルというのは、必要条件の意味で、十分条件の意味ではないです。十分条件であるなら万能と読んでいただいて良いのですが……。
私の文章の本質は、所謂上流と呼ばれる技術者に「SQLの技術が不足していることが多く、そのために問題が起きる」事象について書いているわけです。
SQLも（他も）出来ること ＝ 上流技術者
SQLが出来ないこと ≠ 上流技術者
です。
繰り返しますが、十分条件とはこれっぽっちも思ってないし、どこにも書いてないと思います。
「知らなくても要望が満たせる場合もある」というのは、運が良かっただけですね。プロとしていかがなものでしょう。
「知っているけれど、検討の結果、あえて選択せずに要望が満たせた」でないと、プロとは呼べないのでは？
つまり、知らなければ検討のしようがないですから、必須（必要条件）です。
ただ、次の記事を読んでいただければ分かりますが、私は上流・下流という分け方がそもそも間違っていると思っています。
あえて上流・下流という分け方をするならば、上流にあたる技術者はSQLは必須でしょう。
ということです。
bobo
>「知らなくても要望が満たせる場合もある」というのは、
>運が良かっただけですね。プロとしていかがなものでしょう。
通信処理を行うシステム、携帯のシステムなど、SQLを使用しないシステムはあります。その分野の上流にあたる技術者がSQLは必須とはとても思えません。
20年以上技術者としてシステムを構築している人で、通信は詳しくてもSQLは知らないという人もいますが、技術者として未熟なのでしょうか？？
上流と呼ばれる人に必要なのは業務知識、技術知識を持ち、顧客が満足する提案できる人だと思っており、SQLを知らなくてもそれらが出来る人が上流と考えます。
私自身はDBは必ず使用しているため、技術者であれば、SQLの知識は当然持っているものと思っていましたが、上記のような人にあって考えが変わりました。
上流・下流の考えですが、分ける必要はないと思います。
分けるとしても、システム化が決定した段階で（要件定義以前か以降かでと。。）
> 通信処理を行うシステム、携帯のシステムなど
おっしゃるとおりです。
汎用機しかしない上流技術者は、汎用機の上流技術者だと思います。
通信処理しかしない上流技術者は、通信処理の上流技術者だと思います。
それらの言葉の定義は、本文の本質ではないです。
> 重要なのは何を必要としているかを考え、本質を捉え提案できる力
本質は、SQLを必要とする現場で、高いレベルで知らない技術者が問題を引き起こしている、ということです。
その辺は文脈でどうかご理解ください。
今更感がありますが、Java から SQL に入った人間が思ったことを書いときます。
「SQL 初心者レベルであっても、JDBC 経由で大雑把なデータを抽出して、Java 内でデータを加工することができます。」と仰った turbo さんの意見ですが、まさに昔このように考えていました。
SQL なんて、単純な SELECT 書いて、後は「ちゃんとした」プログラム言語で集計なりフィルタなりすればいいじゃん、と。
で、SQL をある程度使えるようになった今では、そう思っていた自分が恥ずかしいと感じています。
あくまで、Java で「も」できるけど、それは全然ベストじゃない。
Java やデータ構造、アルゴリズムがわかる方に向けて表現するなら、「List に入ったデータをソートするのに、わざわざ自分でバブルソート書いちゃってる」みたいな感じでしょうか。
あと、この記事ではすでに DB を使ったシステムがあることが簡単にわかりそうなものなのに、それに気づかない/気づけない人っていうのはいるんですね。
もっと記事をちゃんと読むべきだと思います。
> Java やデータ構造、アルゴリズムがわかる方に向けて表現するなら、
> 「List に入ったデータをソートするのに、わざわざ自分でバブルソート
> 書いちゃってる」みたいな感じでしょうか。
そんな感じになるのでしょうか。
テレビのリモコンを孫の手で押しているような歯痒さがあります。
「指で押せや～！」ってイライラしているわけです。
実は私も古い人間なので、SQLより先にアルゴリズムが浮かんでいて、アルゴリズムをSQLに翻訳しています。
SQLを実行するために翻訳するのは、DBエンジン（オプティマイザ）です。
翻訳したものが実行計画です。
SQL文のチューニングは、自分が思った実行計画（アルゴリズム）と、DBエンジン（オプティマイザ）が作った実行計画を見比べる作業になります。
だから、アルゴリズムができる人は、毛嫌いしなければ、実は何段も深くSQLを理解できるはずで、SQL文のチューニングをしていると、アルゴリズムが先に浮かんで、それをSQLに翻訳するってこともできるようになります。
毛嫌いしている人はほんの少しの努力で変わるはずなんですけれどね。