>技術者の価値はＳＱＬだけなのでしょうか。
>初級しすあどに合格したらプロと名乗ってかまわないとおっしゃっているようです。

どこに書いてあるんでしょうか？行間ですか？

>所詮試験でしょう。勉強すればできるようなものでしょう。

大概の事は勉強すればできますよね？
一部の天才しか評価しない人ですか？

ハツカさん、こんばんは。

失礼ですが、生島氏のコラムの内容を理解されないまま、
感情論で反論されてるように感じますし、論点がずれております…。
(デンガス氏の言う通りだと私も感じます)

反論する際は、きちんとコラムを読んでから行った方が良いと
思いますよ。(苦言、失礼致します)

皆さん、こんばんは。

なんかちょっと分からないのですけれど、そこまで伝わらないかな～。
必須というのは、必要条件で、十分条件ではありません。

高校生レベルで通るような試験は入門であって、初級シスアドが「できたらいい」じゃなくて、それすらできないのは「話にならん」と言ってるだけです。

初級シスアドの高校生の合格率って大体40％以上ですよ。
プロで、つまりその技術も使って金を貰っていて、未経験の「とりあえず試験受けてみました」みたいな超ド素人も含めた高校生の中に入って、中ぐらいって、もう私なら恥ずかしくて生きてられないですよ。

どの口で自分は「技術者」だっていうのか？ってことです。

何度も何度も、書いているけれど、「出来て当たり前」なのです。

しかし、現状では高校生にも劣る「できないカス」に合わせないと、悲しいことにプロジェクトが進められない。それを嘆いているだけです。

そんでね。
他所の業界はいざ知らず、IT業界は「効率化」のために存在しています。
この大原則を分かってない人はダメですわ。

サッカーでどんなにシュートが鋭くても、ルールを知らないのと同じです。

誤：(デンガス氏の言う通りだと私も感じます)
正：(デガンス氏の言う通りだと私も感じます)

デガンス様、失礼致しました。

書き忘れましたが、注射器を使いまわしたらいけない。というのは、今となっては医療者（どころか一般的）に考えてレベルが低すぎる話ですが、30年前の小学生（私も含む）が学校で受けていた予防接種は普通に注射器を使いまわしていたのです。

使い回しは絶対にいけないとなるまで、10～20年ぐらい期間があったと思いますよ。

IT業界でも、イロイロと新しい技術は出てくるのです。
それに飛びつくのも一興ですが、鳴り物入りの新技術も大半は消えていきました。

でね、新しいものを取捨選択する能力も必要なのですけれど、それを追い求めるよりも、定着した最低限の技術は取得しましょうよ。

それがないうちに、新技術を移り歩いても、金脈に当たる可能性は少ないし、なんか疲れて「他所の業界に行こうかな？」ってなってしまいますよ。

日本語の読解力がないのもプロとしてはどうかとも思いますし、相手の気持ちを慮ることもできなれければ、やはりプロではないかもしれません。(あ、私もですね)

これを言っちゃなんですが運の要素もあるかもしれません。

良き先輩や教育者に出会うことができなかったり、それを受け入れられる状況でなかったり、使えたほうが効率の良いことに気づけない環境だったり・・・。

考え方(考えるやりかた？頭の使い方？？思考回路？？？)の違いなんてのもあると思います。

ただ、今持っていないスキルを習得することによって、より効率があがるかもしれないのだったら、試してみてもいいんじゃない？ぐらいには思います。

すべての人を変えることは不可能だと思います。
何人かだけでもついてきてくれれば、ラッキーぐらいでちょうどいいのでは？

読解力云々を言っているのにわけのわからんことを書いてごめんなさい。
#さて、どれだけの人に伝わるのかな。

うーん、酒の力はおそろしい。

ところで、仕事のストレスでもたまっているんでしょうか？
言い回しがきついような・・・。

たいしたことは言われてないと思います。はてさて。

あけましておめでとうございます．
本年もどうぞよろしくお願いいたします．

情報処理技術者試験の資格化（免許制）して，他の士業のような位置づけとする，という話がありましたね．

----
産業構造審議会情報経済分科会情報サービス・ソフトウェア小委員会人材育成ワーキンググループ
http://www.meti.go.jp/committee/materials/g61107bj.html
----

IT 技術者の質に問題がある，と考えるエンドユーザがいて，行政もそのことを認識している，という事実は知っておいた方が良いでしょう．

銀行のシステムは，金融庁の検査対象になっていて，特に，例のみずほ銀行のシステム障害以来，検査の内容は厳しくなっているみたいです．また，一般の事業会社についても，内部統制法の施行で，情報システムが監査の対象に入ってくるはずです．

今後，IT 技術者の質に関して，厳しく問われるようになってくるのではないかと思いますね．

なお，「私財没収」，「刑務所行き」といった話は，多少誇張はあるにせよ，現実に有りうる話でしょう．プロの技術者としての適格性を欠き，そのことにより，顧客や所属組織に損害を与えれば，損害賠償請求や，最悪，刑事告訴といった事態は起き得るわけですから．

他分野の，士業の技術者は，特別法でそうした責任を負っていますね．
例えば，姉歯建築士．確か，彼もご母堂の介護をなさっていたのでは．

ハツカさん、こんばんは。

私の名前が呼ばれているのですが、残念ながら、ちょっと感情論に傾いているような気がします。この業界の方ではないので、いろいろわからない部分もあるのかもしれませんが。
確かに生島さんの論理も強引で乱暴ではありますが、半ば確信犯的にやってると思うので、そんなところ突っ込んでも「話にならん」と言われるだけです。
例の女性の件（本当にこれで最後にします）にしても、生島さんが「気の毒ですね。同情します」とか言うことは絶対にないと思って書きました。そういうスタンスで論理を展開してきているので、気の毒なんて口が裂けても言わないですよ。

（たぶん）数少ない業界外の方なので、業界の人間にはない新鮮な視点で意見を述べていただきたいと思いました。

皆さん、おはようございます。

例えば、税務署職員は嫌われても税金を取り立てるのが仕事です。
嫌われようと（私も幼稚な感情で大嫌いだ）不公平なく取り立てないといけません。
個別の事情は福祉を担当する人が受けるべきなのです。

おくりびとと、ウェディングプランナの仕事は違います。
それぞれ、自分の担当分野で、担当分野に合わせて仕事をしなければならないし、合わせたスキルをつけないといけないでしょう。

で、IT技術者というのは効率を上げるために存在していますから、そこにフォーカスが行かない人は、努力の方向性がズレている。
おくりびとが「みんなを笑わせるにはどうしたらいいか」って努力しているのと同じで、どんなに努力してもその努力は評価されない。場合によってはマイナスに評価されてしまいます。

何人かの方から「工数とパフォーマンスだけじゃない」とか訳の分からない批判を受けましたが、「だけじゃない」は正しいけれど、「工数とパフォーマンス」最重要ですから「だけじゃない」を優先してはいけない。「だけじゃない」が「大人の事情」っていうことがたくさんあって、私はそれを超えたいと思っているのですけれど、「だけじゃない」が「楽しくない」とか、「新しいモノ（が好き）だから」とか、「勉強より生活」とか、そんな個人の都合を優先するのは許されない。そいう主張は罵倒するよ。

くどいけれど、VB6 ＋ oo4o というシステムの保守を10年やっていて、職業人として当たり前の職責を理解して効率にこだわっていたら、別に教育されなくてもOracleの達人になっています。なってないとしたら、他のものを優先してきたということで同情の余地はない。

サラリーマンには多いのですけれど、自分が何で収入を得ているのか分かってない人がいる。そういう人は目標が見えてない訳ですから、仕事も楽しくないでしょうね……。

フォーカスするモノは違うけれど、他所の業界でも同じことが起きるのですが、そういう人は、嫌な仕事でもまじめに頑張ってきたのに、努力してきたのに、リストラってなってしまいます。
それは自己責任ですわ。

ですから、手遅れにならないうちに気づいてくれたらと思って書いています。
アラフォーなら、かなり手遅れに近いけど……。

同じことを優しく書いているモノは世の中にいくらでもあるのですけれど、分かっている人が少ないからきつく書いているのですけれどね。

士業みたいなことも検討されているのね……。
知らなかった。
～ん。
個人としてはうれしいけれど、中小企業にはちょっと辛いかも。

ビガーです。おはようございます。

>RDBMSを使っても「こうすればSQLを使うより効率的」。というまっとうな反論は
>1つもない。

RDBMSを使うなら最終的にSQLを使わざるを得ないのだから、反論も何もないと思います。
効率を重要視するなら、SQLを自動生成して効率化するO/Rマッパーについてもっと具体的な製品なり、思想なりに言及するべきです。

私は、DBFluteを使用しての開発効率の良さを以前のコラムで提案しています。
今一度DBFluteのよさを具体的に話しておくと、物理テーブル定義から1テーブルに対するCRUDを補完できてしまうところ(物理テーブル定義が変わってもDTOに紐付くオブジェクトにしか変更の影響がない)にあります。

ストアドも変更については同様でしょうが、初回開発時にどうしても独自実装をする必要があるはずです。(自社内であればテンプレートを作ってあるのでしょうけど)
どのようなお客様の環境であっても、オープンな仕様で、それを自動生成の設定だけで済むのは、非常に効率的です。

まっとうな反論が1つもないという結論を出す前に、システム全体の視点でOSSの有用性を検証されると、さらに良い効率化が図れると思います。

こんばんわ。

>ですから、手遅れにならないうちに気づいてくれたらと思って書いています。
>アラフォーなら、かなり手遅れに近いけど……。

生島さんが9:11に書かれた内容は、私も正しいかあなと思います。
顧客から見れば、工数とパフォーマンスは大事ですからね（あとお金も）。
話が違うかもしれませんが、特定派遣で現場を転々としながら働いて
いましたので、工数と成果物に対してはすごく意識していました。
出来が悪ければ、更新もないし今後その会社で使ってくれませんからね・・・。

アラフォーって35～44歳のひとのことをさすようですが、私も少しこの世代に
被ってます。私も手遅れなんですかね・・・。orz

生島さん、こんにちは。にゃん太郎です。

　いつも議論を起こさせる内容で読むとうまいなぁと思いますが、コメントを読むとなかなか意図が伝わらないんだなと感じます。私もそうですが、コラムってやや大げさすぎるぐらいテーマに対して表現したりピックアップしたりする事でいろいろな議論を引き起こせるのでそういう部分では上手だなと昨年のランキングからも思います。でも、ちゃんと言葉になってる部分も伝わらないのは読んで考えていない証拠だと思うので、考えていないエンジニアが多いのかなとも感じてます。

　もっともプロフィールに「イノベーションってやつ起こせたらいいな。」と書かれているのでこれはこれで起こせてるんじゃないの、って気がします。

　生島さんの事は好きな人と嫌いな人がコラムだけを読んでいる人の中では（現実に知っている人は別として）はっきりしているんじゃないでしょうか。私自身はエンジニアとしては非常に興味のある人なので機会があれば一度一緒に仕事をしてみたいとコラムを読んで思う人の1人ですが、多分けちょんけちょんにされて終わりそうなのでもっと精進が必要ですな。

　今年もガンガン進んでください。

おはようございます。

> アラフォーなら、かなり手遅れに近いけど……。

うーん、そうでしょうかね。
私もアラフォー（越えている方）ですが、去年、Flex3 憶えましたぜ。

定年退職してから英語をマスターした人だってたくさんいるので、
何かを勉強するのに年齢は関係ないんじゃないですかね。

私の考えるIT技術者は
「自分が欲しいと思った物を現実に創り出すことのできる人」
です。
でも、この定義だと技術者全般に言える事だから、ITとは限りませんね。

顧客の立場に立って顧客の欲しいものを考えるのも重要なんですが、
正直、顧客になりきるのは大変です。

「自身＝顧客」の場合、ニーズがはっきりするため
いいものができると思うのです。

自分たちが欲しいと思って作ったものが世間に受け入れられた例として
yahooとかyoutubeとかがそんな例でしょうか。

勝ち残ることができたのは「自身＝顧客」だったからで
「自身≠顧客」の場合、淘汰されてお仕舞いです。
でも、チャレンジするのはいいことだから淘汰されたとしても
その行動力は称えたいものです。

SI業界はなかなか淘汰が進まないってことなんでしょうけど
「自身＝顧客」に近づくためにも
「内製化のススメ」にあるように顧客が作る立場になったり
SI業界内に元情報システム部門の人を入れるとか
人材の交流をはかる必要があるんじゃないかなーとか思いました。

医者の例にしても、
自分が癌になって初めて患者の気持ちが分かったみたいな
話も聞いたりしますから、経験しないと理解できないものが
人間なんだと思ったり。

駄文失礼しました。

IT技術者は効率を求めなければならないという至上主義だけ
ぶちたててしまったら、極端な印象は受けますね。

「顧客の業務効率の向上」を求めるには「IT技術者」が
具体的に何をしないといけないのかという点も見えてこないので
論点がぼけてるような気もします。

そのあたりはコラムを書かれる前提にもたれているんでしょうけど。

業務の効率化にはやはり予算も期日も立ちはだかる訳ですから、
あと要件を正しく聞き出し設計し実現する能力も要されるし、
それらを正しく運用できる業務体制のコンサルや仕切りも必要になる。

それらすべて直接担当しないまでもIT技術者が求められる
スキルも多種多様になるかと思います。

多分論点はプロ意識が少ないやつが多いって話だと思うのですが、

勉強しないやつにはする必要性がないからしないだけで、
努力しないやつにはする必要性がないからしないだけです。

そういう職業人間的の連中に大義名分において○○○○”しなければならない”
ってといたところで空振りなような気がします。

なぜそうならなければならないのかというのを正義感以外の
必要性で説いていただければ非常にわかりやすいコラムになるかと。

どちらかというと他業種とちがってIT業界は国が設定しているわけでも
なければ業種枠が曖昧だと思います。税務署員は万人がみて税務署員ですが、
IT技術者ってなにってところが最大の難問ですかね。

> ビガー さん

こんにちは．

> 今一度DBFluteのよさを具体的に話しておくと、物理テーブル定義から1テーブルに対するCRUDを補完できてしまうところ(物理テーブル定義が変わってもDTOに紐付くオブジェクトにしか変更の影響がない)にあります。

あくまで，「1テーブル」に対してですよね．
(CoC ですかね）
とすると，実用上，複数プロジェクトで使いまわせるのは，1テーブルに対する，C（INSERT），U（UPDATE），D（DELETE）まで，となりませんか？

主キーを使った一行 SELECT を入れても良いですが
（私の経験上ではあまり使わない）．

write （CUD）は，トランザクション制御と絡んできますので，それも含めて手間を考えるべきかと．1 トランザクションで 1 テーブルしか書かない，というのも考えにくいですし．トランザクションには，read も絡んできます．
個人的には，ロック・プロトコル（粒度，楽観的・悲観的，RDBMS 標準・独自）の差し替えが，比較的簡単にできるような実装にしたいです．

また，O/Rマッパーに対して思うのは，アプリ実行時に DB エンジンが変わるようなことがないのであれば，実行時にコード生成するのは無駄だということ．
コンパイル前に，SQL，ホスト言語のソースコードをスクリプト使って自動生成しとく方が良い，と思ってしまいます．1テーブルに対する，CRUD 程度のものであるのなら．
例えば，アプリ実行中にテーブル構造を変更する（追加は除く）必要がある，というなら，わからなくもないですが．

（DBFlute がどうかは知りませんが）XML ファイルにマッピング定義を書かなきゃならないのなら，その作業時間で，Perl・Python・Ruby といったスクリプト言語で，自動生成するスクリプトが書けるのでは．XML は書きにくいし，設定ファイルには，（ Ant のように）制御構造は入れられないでしょうし．

# 仮に，私がO/Rマッパー使えといわれたら，スクリプト言語で，テーブル定義から，XML 設定ファイルを自動生成する^^) そうなると，O/Rマッパー使わずに，直接コード生成した方が早い，となってしまう．

はじめまして。色々と考えさせられることが多いので、当コラムはよく読ませていただいています。

私はシステムの目的が業務効率化だけだとは思っていません。
お客さんがもとめるものは、"提供価値の向上（売上、サービス品質）につながる"とか、"コストが削減できる"とか、それから"法対応"だったり、これらをすべて業務の効率化ってワードで括るのは無理があると思います。

そういう意味では枝葉末節まで全てこのコラムの内容に同意するわけではないのですが、「プロとして仕事をする上で最低限の知識を習得すること」に対して、これだけ否定的な意見がでることには違和感を感じます。

初級シスアドって、程度の差がどれだけあったとしても、2-3ヶ月もみっちり勉強すればまあ合格水準にいく試験ですよね。
そういう意味では、せいぜい生島さんが仰っていることは「公道を運転するなら運転免許ぐらいとっておかないと」というぐらいの話だと思っています。

私自身は情報システム部門で3年半働いてからコンサルに転職して10年選手です。
コンサルに転職してすぐのころに炎上しているプロジェクトに突っ込まれたとき、お客さんから「XXさん高いんだからトイレ行かないでよ」と言われました。

お客さんが掛けた分のお金に見合う品質の成果物がでてこないと駄目ですよね。
後に続く人たちがIT技術者という職業にプライドを持てる業界にしていくことが重要なんだと思っています。
私はお客さん側からじゃなく、こちら側から意識改革できると思っているんですけどね。

ビガーです。こんばんは。

生島さんと話してみたかったんですが。。

>ronさん

今回は、データアクセス層の生産性(効率)の話をしています。(生島さんのネタに合わせて)

で、DBFluteの設定の話ですが、基本的にDBの接続情報を記述するのみで、O/Rマッピングの設定などは一切不要です。(マッピングされたオブジェクトがすべて自動生成されます)
一度使ってみればわかりますが、本当に生産性は素晴らしいと思います。

それと、基本的にテーブルと1対1ですが、外だしSQLなるものを使うと結合などを伴う複雑な検索の結果とオブジェクトのマッピングが容易に記述でき、自作コード量が圧倒的に減ります。(この結果オブジェクトも設定ファイルに則り、すべて自動生成されます)
まぁ、個人的には、DBFlute自体の拡張性(Seasarにもいえる)には不満があるので、好きではないのですが、生産性という面でいうとこれほど素晴らしい実装はないと思います。

また、トランザクションやロックは、基本的にビジネスユースケースの単位となるので、サービス層で考慮すべきことで、データアクセス層で考慮する要素ではありません。
ロックについては、物理的にはDBの機能を利用することが多いですが、性能面等を加味するとインメモリで実現した方が望ましいし、今後その方向にシフトするでしょう。

ストアドで処理させるという選択肢以外の技も求められると思います。

あけましておめでとうございます。
今年も生島さんのコラム楽しみにしています。

作業を行うにあたって、OSや言語、周辺技術などの範囲が広く、勉強するにも
どの分野を勉強して行くのか的を絞ることさえも難しいってところにも問題が
あるような気がします。

勉強をしない人ってのははなっから論外ですが、進もうとする道はそれこそ無
限にあり、進もうとする道が違う人が出てくるのも致し方ないでしょう。
ただ、生島さんが仰られている「初級シスアド」程度の試験に出題されるのだ
からプロとしては最低限そのレベルにあるべきということには激しく同意しま
す。

IT技術全般をすべて抑えておくってのは不可能に近いと思っていますが、より
上流の工程で作業を行う人ほど多岐にわたる知識を身につけておく必要がある
と感じます。なぜなら、お客様との会話に出てくるものが自分のあつかってき
た技術に関連する話だけになるとは考えられないし、システム全体の会話にな
った時に正しい判断ができないと考えます。
本当に専門的な内容の話をしなければならないときはその技術に精通した人を
交えて会話すれば良いでしょうが、それすらも判断できない場合がでてくるの
ではないでしょうか。

でも実際に目にする自称上流の技術者は何もできない人が多い!!

変なプライドは捨てて、一からやり直してみるべきだろうといつも感じます。

あぁ...

自分で名前を打ち間違っているorz
なにやってんだ>おれ

コラムに関係ないコメントですみません。

> ビガー さん

回答ありがとうございます．
お邪魔してすみません^^)

> それと、基本的にテーブルと1対1ですが、外だしSQLなるものを使うと結合などを伴う複雑な検索の結果とオブジェクトのマッピングが容易に記述でき、自作コード量が圧倒的に減ります。(この結果オブジェクトも設定ファイルに則り、すべて自動生成されます)

それは良いですね．ストアドもいけるのかな？
そこだけ取り出して使えるなら欲しいかも．

> また、トランザクションやロックは、基本的にビジネスユースケースの単位となるので、サービス層で考慮すべきことで、データアクセス層で考慮する要素ではありません。

O/R マッパーはトランザクション管理はしないのですかね．
あるいは，あっても別に使わなくても良いということでしょうか．
（使う場合に，必然的にくっついてくるものではない？）

Seasar （S2Dao）に楽観的ロック（バージョン番号で管理）って付いてませんでしたっけ．
個人的には，あの手法は，ものすごく疑問に思っています．
DBFlute はまた別なんですかね．

> ロックについては、物理的にはDBの機能を利用することが多いですが、性能面等を加味するとインメモリで実現した方が望ましいし、今後その方向にシフトするでしょう。

インメモリといっても，DB サーバのメモリではなく，AP サーバのメモリを活用する，という話ですか．

今後，サーバに搭載される物理メモリ量が増えるのは間違いないでしょうけど，どの種類のサーバのメモリを活用した方が良いかはなんともいえないと思います．アプリがデータをどの程度共有するかによるのではないですかね．

もちろん，AP サーバの物理メモリ量も増えるでしょうから，それを活用するという視点は必要にはなるでしょうけど．AP サーバと，DB サーバとが同期していると難しいかな．

> ストアドで処理させるという選択肢以外の技も求められると思います。

私も色々と検討して考えてはいるのですが．
（マンネリになるとそれはそれで嫌なので）

今のところ，開発効率で圧倒的にメリットがある，といえるだけのものは見つかってないです．技術を選択する決め手は，開発効率だけでもないですし．

皆さん、こんにちは。
コメントのレベルが低いとイライラし、高くなると返すのが大変になります。
済みませんね。

取り急ぎ、ビガーさん

私も実際の現場では拒否しても進みませんから、大抵O/Rマッパーなど使うことになります。それで、私がイッチョ噛み（大阪弁）だからかも知れませんが、2回同じモノを使うのがマレなんです。

業界に入って13年ほどですけれど、DBの方は、Oracle、SQLServerをメインに、DB2とか、PostgreSQLとかもやりますが、標準SQLが分かっていたら対応可能です。
ストアドプロシージャもベンダー毎に基本的に上位互換できています。

ということからも、私はSQLの方が汎用的であると考えています。

O/Rマッパーなどは、更に、今後もたくさん出てくると予想しています。
出始めが5、6年前かな？数えたことはないけれど、僅かそれだけの間に相当な数が出てますよね。

OSSの利点とかないことはないけれど、劇的に効率が良くなるわけでもないのに、次々に新しいモノが出てくる方にシフトしたくない。変わるたびに余計な工数が掛かります。

SQLできっちり書いたときの「工数・パフォーマンス＝効率」と、O/Rマッパーの効率がひっくり返るかというと、そんなことはないと思います。

本当に単純なマスタメンテ画面などでは、O/Rマッパーを使った方が早いでしょうけれど、単純なだけに大差はないし、そういうのは個人的に新人教育用に残しておきたかったりする。
この辺はスタンスの問題だと思いますが、無駄なことをしなければ育ちませんから、フォロー出来る範囲で無駄なことはすべきだと思います。
もし、使ってないのに新人がO/Rマッパーを提案してきたら、そこは採用するかな～。

いずれにしても、O/Rマッパーを使うにしてもSQLを使い切った後に使うべきです。

O/Rマッパーを目の敵のように悪くいうのは、SQLを使い切るために作られたモノではなく、「SQLを使いたくない」「見たくもない」「SQLの方が（開発・保守ともに）難しい」という前提があると思うからです。
そうでないと、O/Rマッパーを作りたいというモチベーションが技術者にも企業にも出てこないでしょう。
憶測ですが、宣伝文句がそうなっていますからね。

もしそうだとしたら「SQLの教育が足りない」が正しいのでは？

私はプロとしては、VB4 + Oracle（＆ MDB）からスタートしました。
VB4にシフトしてたら、今は喰えてなかったと思う。

本当に簡単で、デメリットはないのですけどね……。

こんにちは。
ちょっと気になる事があるので一言。

>そうでないと、O/Rマッパーを作りたいというモチベーションが技術者にも企業にも出てこないでしょう。

これはちょっとO/Rマッパーを作った人に対して失礼だと思います。
私もO/Rマッパーを開発しましたが、その理由は開発生産性を上げるためです。
もちろんSQLは知っているのが前提で、決まったルーチンワークを自動化するために作りました。
大概のO/Rマッパーの作者の動機はそうだと思います。
何故ならば、「O/Rマッパーを作る人はSQLを知っているから」です。
何もSQLから逃げたくて実装したのではないと思います。
ただ、SQLから逃げたい人がO/Rマッパーを誤用しているのです。
宣伝は確かに頂けないものが多いです。
しかしこれはO/Rマッパーに限った話しではありません。
O/Rマッパーの作者までその様に言わない方がいいと思います。
といっても、私自身はもうO/Rマッパーを作りたいとは思いませんが・・・
何故ならば、PCはプロジェクトを知らないので、本質的に出来あがるコードの効率が悪いからです。
メタデータが無いので、最適なSQLを吐けないのです。
メタデータを加えたら簡単なシステムならば自動生成する事も可能ですが、それは最適なシステムとは言えません。
ですから、O/Rマッパーは一時的に開発生産性を上げるものであり、お客様の生産性を上げるものではないのです。
その違いが大事なのです。
どんな道具も適材適所。
使う人が賢くなければならないのです。

こんにちは．

O/R マッパーの話ではないのですが．

アプリ側のコンポーネントで， RDBMS の実装をラップして隠す，というのは，あまり良いアイデアだとは思っていません．典型的には，ODBC，JDBC がやろうとしているようなことです．

なぜかといえば，SQL 標準も，SQL-92, SQL:1999, SQL:2003, SQL:2008 と改訂され続けており，RDBMS 側のインターフェイス（つまり SQL）は，今後も進化を続けるであろうからです．

例えば，TIMESTAMP，INTERVAL といった，SQL-92 で新しく追加されたデータ型．いわゆる「ドライバモデル」だと，こうしたデータ型の追加に追随していくのは難しくなるように思います．

この点で，ADO.NET がうまいと思うのは，最小公約数のインターフェイスだけを，Framework 側で定義して，そのインターフェイスを実装したクラス定義を，各 RDBMS ベンダに委ねた形にしたことですね（統合インターフェイスがドライバを呼び出すモデルになっていない）．

ただ，LINQ to SQL で，また昔の「統合インターフェイス」モデルへ回帰しようとしているように見えるのは，不可解ではありますが．ユーザの声に押されたのかな．

＞IT技術者は「顧客の業務を効率的にする」ために存在するのです。

ここに至る考察・理由については、特に書かれていないように見えるのですが、どうなんでしょうかね？
ここがに違和感を持ってしまうと、すべてがビミョーーーになってくると思いますが。

私は違和感を持ちました。
サービス業である我々の業種が、何故、「顧客の業務を効率的にする」ために存在する事になるのか・・・
「効率」を追求すること、これは、モラルや必要条件の１つでしかないと思われます。

IT技術者は「顧客のために、無形の技術であるＩＴを駆使し、顧客にとっての価値をサービスする」ために存在するのです。とうようなニュアンスではないかと思ったのですね。文章表現うまい人は、もっと違った言い方があるのだとは思いますが。
この価値が、「効率」である場合もあれば、「魅了する」事や「安定性」である場合、その他の場合もある。（複数の価値を求められる場合がほとんだと思いますが。）
「効率」を疎かにしないという事とIT技術者云々や医者との比較はちょっと、無理があったような気がしました。（好意的に読まない場合、色々と。）

>SQLを使い切るために作られたモノではなく、「SQLを使いたくない」「見たくもない」「SQLの方が（開発・保守ともに）難しい」という前提があると思うからです。

O/Rマッパー作者の本音としては『見たくもない』というところがあるのでしょうが、
O/Rマッパー(注意:DAO/DTOではない)の登場は、まさに効率のためです。
SQLを直書きした時に比べ、パフォーマンス(特にSELECT文発行時)は、
やや落ちますが、工数・保守性・可読性においては飛躍的に向上します。

保守性の向上が実感できないのでは、失礼ながらO/Rマッパーを
まだ使い切ってはいないのではないでしょうか？
そうでなければ、ここまで支持されることはありませんから。

ただ、SQL直書きとは仕組みが大きく違いますから、間違った使用方法
を覚えてしまうと、かえって工数を増大させてしまいます。

O/Rマッパーは、まさにイラチ向きの仕組みなんですけどねぇ。

ronさん　こんばんは。

>ただ，LINQ to SQL で，また昔の「統合インターフェイス」モデルへ回帰しようとしているように見えるのは，

まぁ、あの会社は、色々な技術をかき集めていますからねぇ。
自社にはない、新しい有用そうな技術が出てきたら、それをパクって(あるいは買収して)
あたかも自社で開発したかのように発表する。

『フルライン戦略』という、マーケティングの理論上では正攻法なんですけどね。

何か統一性がないような印象を受けるのは、そのためです。

MSしかり、ディズニーしかり。。。

情報システムで飯を食って30年以上がんばってる定年間近の老人ＳＥです。若い皆さんの議論を読んでいて思わず参加してしまいました。老人のつぶやきとしてお許し下さい。

企業が業務で使用する情報システムは「顧客の業務を効率的にする」ためあります。当然です。それが、コミュニケーションを円滑にするシステムであろうと、経理システムであろうと、関係ありません。古典的なシステム感で云えば、100人の人間がする作業を10人で出来る様にする。かつ、正確に短時間で。一言でいえば「合理化」です。その情報システムを作るＩＴ技術者が「顧客の業務を効率的にする」為に頑張るのは当然です。

別の見方をすれば、ＩＴ技術者が戴く対価は、効率化の結果として得られた利益の一部を納品先から戴いているのです。導入した情報システムが利益を減らしていたのでは、対価を払って戴く原資がなくなります。

あまり書くと老人の小言になりそうなので、この辺で止めておきます。
追伸（構造型データベースで開発していたので、ＲＤＢＭＳが出た時には感動しました。ＩＢＭのＳ３８が導入された時には嬉しくて、マシン室に入り浸っていて怒られたの懐かしく思いだしました。）

システムを作る我々IT技術者という職種は、
　「情報システムを通して、客先ビジネスに貢献できること」
というところが本質だろう、と個人的に考えています。

この視点からは、IT技術者という職種にも、
コミュニケーション力が相当程度必要かな、というのが私見です。
顧客が説明しきれない部分を、こちらから誘導して聞き出すような。
このあたり、お医者様の問診に通じるところがありそうですね。

『貢献』のなかで最大の一要素が「効率」であることに異論はありませんが、
効率的なシステムも、きっちり使われなければ持ち腐れですよね。
システムを納めて、実際に活用していただいて、
客先の利益に貢献するところまでが我々の仕事だと思っています。
難しいことですが。

･･･と、コラムの題に反応してみました。
# コメントの流れをぶった切ってすみません

ビガーです。こんばんは。

生島さん、レスありがとうございます。

>OSSの利点とかないことはないけれど、劇的に効率が良くなるわけでもないのに、
>次々に新しいモノが出てくる方にシフトしたくない。変わるたびに余計な工数が掛かります。

私の認識では、OSSを利用することで劇的に効率が良くなることがあると思っています。
なぜなら、一般にOSSは十分に枯れているものが多く、自作のものより品質が間違いなく高い。

そして、新しいと思われるモノも結局古いモノの思想を流用(DBFluteもTorqueやS2Daoなどの思想を継承して良いところ取り)して、進化しつづけているわけで、新しいモノも蓋を開けてみれば、それまでの技術の組合せであり、本質的なことが理解できていれば、大した工数にはならないと感しています。

まぁ、効率以外の要素もあるので何ともいえない部分は多くありますが、自戒を込めて、新しいモノへの探究心は、なくしたくないと思っています。

>O/Rマッパーを目の敵のように悪くいうのは、SQLを使い切るために作られたモノ
>ではなく、「SQLを使いたくない」「見たくもない」「SQLの方が（開発・保守
>ともに）難しい」という前提があると思うからです。

今まで一度も発言してきませんでしたが、SQLを勉強しないというのは、あり得ないと私も思っています。O/Rマッパーを使っても、結局独自のクエリー言語を学習する必要がある場合がほとんどで、構造はSQLとほぼ一緒のため、事実上、SQLを勉強することになると思っています。

ただ、O/Rマッパーの謳い文句(SQLを隠蔽することなど)を誰が言い出しなのかわかりませんが、オブジェクト側にドメインロジックを持たせるとたくさんのメリットがあるから、比較的大規模なエンタープライズシステムでは、そうしましょうという発想ではないかと思います。

規模や開発者のスキルにより最適な技術を選ぶのがあるべき姿なので、唯一の正解はないと思うのですが、自戒を込めて、技術の選択肢が多い技術者に価値があることは間違いないと思うので、改めて精進していきたいと考えています。

こんにちは。しっぱと申します。

今年も盛り上がってますね！

皆様の育った環境で色々考え方は違って当然ですね。
でも、誰かに「雇われている」という立場でまず考えなきゃいけないのは、

①技術者として技術を提供する
②ビジネスマンとして顧客満足を提供する。

大まかに分けるとこの二つの提供をするのがIT事業なのかなと思っています。

生島様は技術者としてのお話をされていると思います。
その視点では正しいと思います。

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

ここについてはちょっと疑問があります。
カウンセリングをどの意味でつかわれているのか分かりませんが
（wikipediaによると最近「心理的な問題や悩みについて援助を目的とするものを、指すことが多い」という感じらしいので）、ここでは文脈から「問診」として扱わせて頂きます。

医療技術があっても問診ができず、患者さんがうまく表現できないために誤診して投薬ミスをしてしまったのでは話になりません。

私的には両方必要条件だと思います。

どちらかに特化することもただし、生島様のおっしゃられている通り、即命にかかわるようなことはあまりないと思います。（医療システムだとまずいか・・・・あと金融系もクリティカルかも・・・）
ですのでどちらかに特化することも「アリ」だと思います。

チーム開発を前提にすれば人間の配置でクリアできます。

また、もっとざっくり話してしまえば技術者は養成がしやすいですが、ネゴシエーションのできる人間はなかなか育てづらいなというのはありますね・・・・

技術屋はガリ勉すればできますが、コミュニケーションはどうしてもダメって人がいますので。。。。

私自身はコミュニケーション寄りでありますが、最低限の技術は常に追いかけている状態です。
やはり流行りには乗ってみないとだめですからね。
机上の知識だけじゃお客様に顔向けできません＾＾；
資格についても勉強はしますが、受験はしませんね。
知っていれば十分ですので。
資格を持ってるってことでそこに胡坐をかいてしまいそうな気がしてしまうので＾＾；

私は生来怠け者何でしょうねｗ

はじめまして。ハツカさんと同じくエンドユーザ側の人間です。
内製化のあたりから読んでます。

今回のコラムとコメントを読んで思ったのは
・問題を単純化しすぎで現実に即していない
・カスなどの罵倒は不快
・結局何がやりたいのかわからない
の３点です。

・１点目
医療技術とＩＴ技術を同列に扱うのは大間違いです。
医者になるには６年間医大に通って卒業し、国家試験に合格し、臨床医になるならさらに２年以上の研修期間が必要です。費用も国立か私立かで異なりますが、千万円単位でかかります。こんなに厳しいのは医者の知識不足は患者の命に直結するからです。本番環境のコピーを作ってデバッグすればいい、ということができないのです。

さらに医師は患者の命を救うことだけに集中していればいいわけではありません。

> 命とトレードオフするのが「医者の都合」だったら「ふざけるな！」ってなりますよね。

「ふざけるな」かもしれませんが、現実にはこんなことはザラにあります。
「緊急救命24時」とか「ＥＲ」とか見てもわかると思いますが、多数の患者が同時に来院して医師の手が足りない場合、まさしく医師の都合で助かる見込みのない患者は見捨てることがあります。
問題になっている救急車のたらい回しなど、医者（病院）の都合によって助かる命が助からない場合もあります。
患者に投与できる薬剤も、国で認可されているものだけです。つまり厚労省の都合です。
患者数が少ない病気（ある種の膠原病など）は、利益が出ないために研究すら行われない場合があります。製薬会社の都合です。
外科医が選択する術式だって、必ずしも患者にとって最適なものであるとは限りません。術者が得意な術式を選ぶこともあれば、研修医のトレーニングになるような術式を選ぶこともあります。単に○○教授派閥だから、△△法を選択という場合だってあります。論文の症例を増やしたいために、××法を行うという場合もあります。
医師が処方する薬だって、○○製薬さんにお世話になっているからとか、△△製薬さんの担当者の方が美人だからという理由で決まることがあります。

つまり、

> 医者が、患者の命より他のものを優先するとしたら、「尊厳死」のような特殊な問題以外あってはならないでしょう。

なんてことはなく、現実には患者の命以外のものが多く優先されているのです。
「医は仁術なり」は江戸時代なら通用するかもしれませんが、現代社会では（少なくとも日本では）通用しません。

それから例としてあげられている注射器の使い回しですが、例として適切ではありません。
注射器の使い回しをしないのは、知識のありなしではなく倫理の問題です。
そして今なお、注射器の使い回しは日々発覚しています。

もっと現実を知ってください。
自分に都合のよい部分だけ切り出して脚色するのではなしに。

・２点目
いろいろ問題となっている過激な罵倒の件です。
flatlineさんのコメントを拝借するなら、

> 「プロを名乗ってはいけない」のであり、
> 「リストラなどという甘いことではなく、一切の私財も没収されるぐらいの罰を受けて当然」であり、
> 「生きている資格すらない人間のカス」であり、
> 「技術を見ずに会社にしがみついているクズ」であり、
> 「派遣村に行こうとノタレ死のうと、自業自得」だと言っているわけです。

プロを名乗っていいかどうかはともかく、後は確かに読んでいて不快です。
過激な言葉を書き連ねて注目を集めて、あわよくばセミナーに来させようとしているのでしょうか？迷惑メールと同じ手口で姑息に感じられます。

一定の能力がない人間は生きている資格がない、死んでもよい、というのは、典型的な優生学思想そのもので、ナチスドイツの例を取るまでもなく、現代の民主主義社会では忌避されるべき思想です。比喩として書かれたと言うかもしれませんが、そのような思想を冗談でも口にするだけで、人は特定のバイアスをかけて聞くことになるのです。
私自身、コラムに書かれている内容うんぬん以前に、生島勘富という人物を安っぽい新興宗教の教祖と同レベルにしか見られなくなってしまいました。布教活動などと書いてあるのでなおさらです。
それから、誰も問題にしていないのに○○大学の誰かを泣かせたとか、高校中退の人を使っているとか、高校生レベルがどうとか自慢げに発言されていますが、これらも低レベルな自慢で滑稽ですらあります。学歴コンプレックスを喧伝しているようなものです。「学歴なんてばからしい」という人ほど、学歴を気にしているものです。

・３点目
過去３～４つぐらいのコラムを読んでみると、「ＩＴ技術者を名乗るなら、一定の技術力を身につけましょう。RDBMSを使うならSQLですよ」と繰り返し主張されています。その是非はおいておくとして、その主張の元に一体何がやりたいのでしょう？顧客を巻き込んでの下克上って何なのでしょう？その下克上とやらが成功すると何がどう変わるのでしょう？誰が得して誰が損するのでしょう？そのためには何が必要なのでしょう？
「～はず」と「～べき」ばかりで具体策が何も書かれていないため、過激な文言ばかりが目に付いてしまいます。
何らビジョンがないのであれば「まだ具体策はこれから考える」と書けばいいし、明確なビジョンがあるならつまらない比喩など使っていないで明確に書いていただきたいです。ビジョンはあるが企業秘密だというなら、その旨明言すればよろしいでしょう。
今のままでは、誰かがコメントで具体的なことを質問するたびに、「個別の事情」だとか「過去に言ってきた」と逃げているようにしか見えません。

以上、思いつくままに書き連ねました。乱文失礼しました。

今回のコラムって分かり安いと思っていたんですが、人によってはそうでもないみたいですね。毎回毎回内容が易しくなっていると思うんですけどね。

確かに生島さんの書いている内容はきれいごとかもしれないし、理想論かもしれない。でも、俺はそっちの方が好きなので、必死にあがいて勉強するつもりです。

顧客が知識をつければ、出来損ないのSEに言いくるめられて効率の悪いものを提供されることを減らせる。
末端の技術者が知識をつければ、顧客に対していま提案しているものよりも良いものを提案、提供ができるかもしれない。
末端の技術者が知識をつければ、上の方にある知識がない役に立たないのSEを駆逐できる。
実現するのは決して簡単ではないし、無理かもしれない。でも、やらないことには現状は変わらないわけで。
個人的には知識というのは選択肢だと思います。
選択肢の量が必ずしも絶対的ではないとはいえ、選択肢があればより顧客満足度を上げることができる可能性があるのもまた事実だと思います。（個人的には顧客満足度よりも顧客の業務の効率効率の方が適切だと思っていたり）
だからこそ学べっていうことだと思います。

初めまして、こんにちは。

SE歴2年未満のヒヨッコですが、一丁前に書かせて頂くと
記事の文面はともかく内容は理解しやすいし、
「当たり前のことを当たり前にやろう！」という内容にも
ブレを感じない文面になっていると思います。

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

生島さんがこのコラムを書く理由はコレに尽きるんじゃないのかな？
コレに対するまっとうな反論が欲しくてコラムを書いているじゃないのかな？
コレに対するまっとうな反論と対決したいんじゃないのかな？
そう感じます。参戦したいのですが、私にはまだムリだ…orz

今年こそ生島さんを堂々と真正面から "論破" する猛者が現れて
欲しいものです（読んでいる方としても＾＾）

枝葉末節に食いついて反論される方もおられる様ですが、
反論がブレているとしか思えません。生島さんの理論が
気に食わないならそれこそ正面から "論破" すればよいかと思います。
（生島さんもソレを待っていらっしゃるようですし^-^）

私も議論の輪の中に入れるようにがんばります。
駄文散文失礼しました。

/*追記*/
コメント欄全編通して感じる事ですが、経営者視点と雇用者視点の
差異が色濃く出すぎている気がします。私の気のせいかな＾＾；

> ronさん
> なお，「私財没収」，「刑務所行き」といった話は，多少誇張はあるにせよ，
> 現実に有りうる話でしょう．プロの技術者としての適格性を欠き，そのことに
> より，顧客や所属組織に損害を与えれば，損害賠償請求や，最悪，刑事告訴と
> いった事態は起き得るわけですから．

「私財没収」って日本の法律でできないのではないかと思いますが、
そういう法律ありましたっけ？
ま、それはおいといて、
現実的に、ＳＥなりプログラマなりが個人として損害賠償請求される可能性って、
どれぐらいあるんでしょうかね。
普通は会社→会社の賠償請求となるだろうし、会社の中ではせいぜい減給降格程度、
悪くて依願退職を迫られるぐらいではないでしょうか。

今のところ、彼（または彼女）に悪意があって損害を与えたと立証できない限り、
個人を対象に損害賠償請求するのはかなり難しいと思いますが。
個人情報データ漏洩とか、意図的なシステム破壊ならともかく、
技術者としての能力が低いという理由では、まず起訴までいかないのでは。
刑事裁判の場合、立証責任が検察側にあるので、「プロの技術者としての
適格性を欠いていた」という立証なんてまず無理ですから。
民事裁判にしても、この場合、原告側に同様の証明が求められると思うので、
そんな裁判するぐらいなら、適当なところで和解するでしょう。個人から取れる
損害賠償金額なんてたかがしれてるから。

雑談でした。

> flatline さん

> 「私財没収」って日本の法律でできないのではないかと思いますが、

ですから，「多少の誇張」です．

企業対企業の取引では，億単位で損害が発生しますから，
これを個人にそのまま求償されると，普通は破産でしょう．

> 現実的に、ＳＥなりプログラマなりが個人として損害賠償請求される可能性って、
> どれぐらいあるんでしょうかね。
> 普通は会社→会社の賠償請求となるだろうし、会社の中ではせいぜい減給降格程度、
> 悪くて依願退職を迫られるぐらいではないでしょうか。

古き良き日本企業の伝統に則れば，そんなところでしょうね．
発生した損害の程度によるし，企業組織の文化にもよるでしょうが．

ただ，日本企業，および法制度もアメリカ化してきてますから，
今後はわかりません．

なお，損害賠償請求は，法律上は，会社 -> 会社 への求償となってから，
さらに，会社 -> 従業員 へと求償されることになるのではないかと．

> 技術者としての能力が低いという理由では、まず起訴までいかないのでは。

これは，おそらくは，発生した事故等の社会的影響度によると思います．
検察というのは，結構，世論に反応して動いているようにみえますから．
検察審査会というのもありますしね．

民事裁判にしても，上場企業の場合，経営者は株主代表訴訟のリスクを負っているわけですから，「適当なところで和解する」で株主が納得しないと考えれば，白黒つけるところまでやる，という事態は有りうるのでは．一般株主なら，「世論」とあまり変わりはないでしょうし．また，非公開企業なら，それこそオーナーの感情次第かと．

横からですがちょっと補足を。

＞もんもんさん

>枝葉末節に食いついて反論される方もおられる様ですが、
>反論がブレているとしか思えません。

"論破"というと表現が少々キツイですが。
ビガーさんあたりが的確に反論していると思いますよ。
(反論というかアンチテーゼになるんですかね？
SQLは不要ではない、という点では一致しているようですし)

『RDBMSを使うならSQLを使い尽くすのが最も効率的』
という生島さんの主張に対して、
『自動発行SQLによる効率悪化は認めるとしても、
そのほかの寄与分で悪化分を十分回収可能。
トータルで見ればお釣りがくるかもしれない』
という別の道(の可能性)を提示しているわけで。

実際、どちらが優位かといわれると、私なんかも、
ケースバイケースじゃないかと思いますね。

＞flatlineさん、ronさん

使用者→被用者の求償、という事例は結構ありますよ。
最終的に求償するかどうかは、使用者側の裁量です。
コの業界でもやっているかは調べていませんが、
運送業界なんかでは結構あるみたいです。

あと、免許制でなおかつ独占業務を抱える医師は、
過失責任で刑法犯に問われることも多いです(業過とか)。
しかしコの業界では免許も独占業務も設定されていないので、
過失責任で検察のお世話にはならないと思います(故意犯は別)。

#雑談でした。

もんもんさん　こんばんは

>枝葉末節に食いついて反論される方もおられる様ですが、
>反論がブレているとしか思えません。生島さんの理論が
>気に食わないならそれこそ正面から "論破" すればよいかと思います。

主張がはっきりしていて、論点がわかりやすいのであれば
それに対して反論できます。しかし、いまいち論点がわからないので
反論とか論破といった種類のことをするものではないですね･･･。

少なくとも、文面どおりSQLとか効率とかそういったことに主張がある
訳ではないということは、過去のエントリーを読んでいただければ
わかると思います。

SQLを使わずにRDBMSを使うということは、インポート/エクスポートを
使うということなんでしょうかね！？

まったくもって関係ないですけど、

「内野竜馬」と「福山竜馬」って、別人が演じているとは思えませんね。
それだけ完璧な演技ということなんでしょうけど。

生島氏の定義によると、ニコニコ動画を作った戀塚氏や、IPAの未踏で暗号解読をやった渡辺氏・光成氏、同じく未踏で日本語プログラミング言語「なでしこ」を開発した酒徳氏らは、「(IT)技術者」には当らないわけですね。彼らは「効率」ではなく、「楽しさ」や「安全」や「教育」の為にITを駆使しているので。彼らは全員「技術」のレベルにおいて生島氏より上だと思いますが、それでも生島氏の定義では、彼らは「(IT)技術者」ではないということになります。

　なんと狭い了見。

　さらに生島氏は、記事を読む限り、「効率」という言葉を定義せず、恣意的に使っているように見えます。ビガー氏が書かれているように、世の中には「開発効率」や「保守効率」という「効率」もあるのに、「SQLを使え」という生島氏の主張は基本的には「実行効率」のみを追求したものになっています。

　なんという狭い視野。

　そもそも「実行効率」だけを追求するのであれば、汎用RDBMSなど使わず、アプリケーション毎にそれに特化したストレージとアクセス・メソッドをゼロから作ったほうが絶対性能は向上します。実際昔はそうやって開発が行われていて、RDBが考案された頃は、「RDBMSなどという汎用基盤を使ったら実行速度が落ちる」という理由でなかなか普及しませんでした。今そうした開発をやらないのは、RDBMSとSQLという汎用基盤を使ったほうが、「開発効率」が上がるからでしょう。

　したがって、「効率にこだわっているからSQL」という主張はそもそも変です。なぜなら、もしこの「効率」が「実行効率」を意味しているのであれば、SQLではなく自前のストレージとアクセス・メソッドに行き着くはず(もっと言うと「SQLなんぞ使わず全部機械語で書け」という話になるはず)だし、「開発効率」を意味しているのであれば、SQLを自前で書く以外の手法(例えばSQL自動生成ツール)なども受け入れるはずだからです。結局生島氏は、「効率」という言葉を恣意的に使って、「SQLを高度に使いこなすことが"技術者"にとっては必須」＝「SQLを高度に使いこなせる自分こそが技術者として正しい」という主張を正当化したいだけでしょう。

>rtさん

顧客とその人たちの目的を定義しないと根本的にずれたままですよ。

まずは顧客は何が求められているのかを定義する。（ヒューマンスキルがメイン)
それをどう提供するかを決める。（技術とヒューマンスキル）
そして、それを開発する（技術メイン）

生島さんは業務系のシステムがメインです。
業務系の人が求めているのは業務の効率化のために依頼するという考え方はそんなにずれていないと思いますが。

初期のRDBは使えないと言う話は純粋にスペックの話になってくると思います。
少なくともここ十数年のスペックの伸び率はかなりのものですから。

効率を求めるならばRDBMSではなく完全自作でと言う話は顧客の業務の効率が落ちるのではないのしょうか？
一つめは安定性
二つめは保守性
三つめは他アプリケーションとの互換性

安定性は言うまでもなくいまのRDBMSは高いです（昔のは知りませんが）。
そして、汎用システムを使うと言うことは、そいつを使える人間がわりと会社の外にも居るわけで。
外部からつれてきた人間を自社のオリジナルのシステムの教育などから始めるよりも遥かに早く起用できるわけです。
そして、安定性と重なりますがトラブルが起きないように作るのは当然ですが、発生した際に事例が多い分調べれば何とかなることもあります。
いまはいろんなソフトがRDBMSに連動しています。それらとの互換性の問題を考えると現実的ではありません。
それに顧客がRDBMSに変更したいと言うときに速やかに移行できるのか、という問題もありますし。

これらの理由を超えて効率が求められるのか言われると個人的には現実的じゃないなぁと。
むしろ、これをRDBMSを使わずに作れるんだったら汎用的にして商品化することさえ出来るような……（本末転倒）

そして、RDBMSを使うんだったらSQLってことなのでは？
O/Rマッパーは触ったことがないのでよくわかりません。
でもSQLは変な文を書くと確かに処理が遅いと言うのはあるので、それを修正できるSQLの知識がある人が前提だったらありなような気も。
まあ、触ったことがないので最後のは聞き流してくださいな。

"RDBMSと付き合って開発やっていかなきゃならん
そんなSIerのIT技術者"がSQLわからんってアホか氏ね。

それだけの話でここまで盛り上がれることにちょっと感動。
同じ感想抱えて悶々としている人たちが居るんだなぁと
ちょっと勇気付けられたりするのです。

現実はまぁ、「赤信号みんなで渡れば怖くない」業界ですやね。
それはもうイロんな意味で。

// O/Rマッパーは使い込んでみたいなーとも思うのだけれど
// SQLを十分に扱える人すら自社に居ませんので。
// そんな現状で開発に導入すると、
// 例えるなら…VB6や.Netで全部のロジックをFormに記述してしまうような
// そんなバケモノが出来上がったりするんじゃないかなぁと思ってみたり。

＞ヤスさん

> 顧客とその人たちの目的を定義しないと根本的にずれたままですよ。

その定義もなくこの記事を書き飛ばしているのは生島氏です。ここでいう「技術者」が業務系のシステムの技術者限定であるという定義があるのならば、最初っからちゃんと書けばいい。それが「コミュニケーション能力」というものです。今だって、「効率」という言葉の定義は曖昧なままです。

> 初期のRDBは使えないと言う話は純粋にスペックの話になってくると思います。

同意します。だからこそ、「かつての専用ストレージ」が「汎用RDBMS」に敗れたように、「今のRDBMS上に凝ったSQLを作り込んだシステム」が、「5割くらいしか性能は出ないけれど、開発/保守効率が2倍になる(数字は適当)SQL自動生成ツール」に敗れるという想定もまた成り立つわけです。ハードウェアの性能が上がれば、実行効率よりも開発/保守効率が重視されるようになる、というのは、この世界では普遍的なトレンドだと思います。

＃ご存知の通り、今実は大規模分散処理の分野では実行効率を求めてストレージ/アクセス系を自前で作る動きが盛んになっているのですが、それは業務系の話とは関係ないのでここでは無視します。

> 一つめは安定性
> 二つめは保守性
> 三つめは他アプリケーションとの互換性

私は実行効率以外の効率を否定しているわけではありません。上にも書いたように、むしろそういうものの方が今は重要になってきているという立場です。

たとえば業務系システムを求めている顧客企業にとって非常に重要なのは投資効率だと思います。先ほどの例に戻ると、100万円のマシンで100万円/月の優れたSQLプログラマー1人月を使って開発し、保守もそのプログラマーが担当しなければならないシステムと、性能が2倍で200万円のマシンが必要だけど、(生島氏が口を極めて罵っているレベルの)今の標準的なRDBMSプログラマー(沢山いるので50万円/月)が1人月でSQL自動生成ツールを使って開発し、保守も同程度のレベルのプログラマーが行うシステムと、どっちが顧客にとって投資効率がいいかは、ちょっと考えれば分かる話だと思います。

高度なSQLを使えるプログラマーが不要だと言っているわけではありません。今でも機械語でのプログラミングが求められるシステムもあるのと同様に、1000万円のマシンを使った上にさらに高度なSQLを駆使しなければならないシステムもあるでしょう。また、技術者個人がSQLの勉強をすることを否定しているわけでもありません。技術者が勉強することで、業界全体のレベルが向上するのはいいことです。でも、全てのプログラマーが実行効率を求めて機械語をマスターする必要がないのと同様、全てのRDBMSプログラマーが実行効率を求めてSQLをマスターしていなければならないということもまたないと思います。

長くなったので分けます。

何を習得するべきか、について、続きです。

だいたい、実行効率のために_SQL_を勉強するというのは、SQLが宣言型の言語だということを理解していれば、変な話であることはすぐにわかります。生島氏は別記事で「アルゴリズムをSQLで表現する」と書いていますが、宣言型言語であるSQLの文面にはアルゴリズムは(ほとんど)表現されません(*注)。

(*注:こう書くと生島氏は「SQLでもアルゴリズムは書ける」と言って http://el.jibun.atmarkit.co.jp/g1sys/2009/02/post-2004.html のようなSQLを挙げるのでしょうけど、1:それはSQLだから正しく書けるのではなく、計算量の概念を理解していればRubyでもJavaでも正しく書ける(逆に言えば計算量を理解していなければSQLでもRubyでもまちがった処理を書いてしまう可能性は高い); 2:従ってアルゴリズムとその計算量の関係を理解することが重要であり、それができていれば、本来宣言型の言語であるSQLを手続き的に使うよりも、もとから手続き的に処理を記述する一般的なプログラミング言語(C,Java,Ruby等)を使う方が素直で間違いも少ない、でしょう。)

宣言的に記述された処理を実際の処理手順(≒アルゴリズム)に変換するのは、RDBMSのプランナーです。つまり、最終的な実行効率はプランナーによって決まるわけです。上の注に述べた生島氏の「アルゴリズムを表現した」SQLも、実際にはプランナーによって解釈され、プランナーによっては生島氏が思い描いたのとは異なる処理手順で実行される可能性があります。そう、「プランナーによっては」です。SQLは標準ですが、プランナーは各DBMSによって異なります。AというDBMSにとっては良いSQLでも、BというDBMSではマズいという可能性も、理論上はあります。そうすると実行効率を求めて勉強するのは、SQLよりも、個々のDBMSのプランナーについて、ということになります。それはもはや学習というよりは細かいノウハウの蒐集になってしまうでしょう。

それだったら私は、SQLを勉強したり個別プランナーのノウハウを蒐集したりするよりは、例えば http://ja.wikipedia.org/wiki/%E9%96%A2%E4%BF%82%E4%BB%A3%E6%95%B0_%28%E9%96%A2%E4%BF%82%E3%83%A2%E3%83%87%E3%83%AB%29#.E5.95.8F.E3.81.84.E5.90.88.E3.82.8F.E3.81.9B.E6.9C.80.E9.81.A9.E5.8C.96 で述べられているような理論(ここでは集合論)を体系立てて学ぶ方がはるかに役立つと思います。こういう理論的な知識こそ本質的な知識であり、それは(先に述べたアルゴリズムや計算量の知識同様)言語やプラットフォームを超えて応用できる、価値ある知識だと思います。

生島氏は http://el.jibun.atmarkit.co.jp/g1sys/2009/06/sql-9a31.html のコメント欄で、集合理論や関係理論を重視しないという旨の発言をされていましたが、そういう理論軽視の態度が、日本のIT産業をいつまでもKKD(経験,勘,度胸)に依存する「土方」たらしめているという意味でも、私は生島氏の主張に賛同できません。

皆様、おはようございます。

興味深いコメントも多いのですが、ちょっと時間がないので個別に返すことが出来ません。
本当に申し訳ございません。

代わりに続きを書かせて頂きました。

チームＡさん、こんにちは。

なんかリクエストがあったので（笑）

医療関連のことなんて一般論のたとえ話ですから、普通の人が理解できたら良いのです。
少なくとも、注射器の使い回しが現在も行われてたとして、知っていたらその病院を選ぶ人はないし、一人でも感染症を出せば傷害罪で訴えられるでしょう。
医者が足りなくってどうしても命の選択をせざるを得ないのも不可抗力の特殊な例です。別に医療問題について書いている文章ではないので、その辺は普通の人は文脈で理解していると思います。

不快であるかも知れません。
しかし、「出来なくても良い」という主張は自分の利益を守りたいだけなのです。
「どうせ人はいつかは死ぬんだから」っていいながら注射器を使いまわしている医者と同じ。

本文にもあるとおり、高校生以下のレベルになっていてもOKと考える人は、倫理的に許せるレベルは超えている。理解してやっている以上、犯罪の域です。

理解してないなら、今すぐ直せ、理解してやっているなら許せない！

それだけの話です。

やりたいことは、先進国で飛び抜けて低い（事務）生産性を上げたいのです。
IT技術者はそれに大幅に貢献できる立場にあります。というか、それを実現せねばならない立場です。

普通の人は文脈で理解しているようですけどね。

お返事いただきありがとうございます。

しかし正直なところ、意図的になのか理解されていないのか、的外れもいいところです。
生島さんの主張をまとめると、

・ＩＴ技術者は効率のために存在する
・効率を上げるためには、RDBMSを使っているなら一定レベル以上のSQLを理解すべき
・理解していながら努力もしないのは犯罪
・個々の事情は関係ない

というところだと思います。
単純な比較はできませんが、あえて医療の世界に言い換えると、

・医者は患者の命を助けるために存在する
・命を助けるためには、一定以上の医学知識を理解すべき
・理解していながら努力もしないのは犯罪
・個々の事情は関係ない

となるでしょうか。その上で、注射器の使い回しを例にあげています。

まず前にも書いたとおり注射器の使い回しをする／しないは、知識の有無ではなく倫理観の有無によるものです。
ここが大きくずれています。

> 医者が足りなくってどうしても命の選択をせざるを得ないのも不可抗力の特殊な例です。

ご自分に都合のいい部分だけ適当に切り出していますが、私が言いたいのはそういうことではないとよく読めばわかるはずです。ちなみに生島さんご本人も

> 発言の一部を切り取ったらどうとでもなりますな。

と発言されていますな。

ご理解されていないようなので簡単に言うと、医療の世界において患者の命は最優先ではない、ということです。病院や医師個人の医学的・経済的な都合が優先されることの方が多いのです。
決して「不可抗力の特殊な例」なんかではない。ドラマのように大量患者が押し寄せることだって、現在の病院経営と医師不足の実態からして現実的にありえない話ではないのです。
しかしこれは、

> 「出来なくても良い」という主張は自分の利益を守りたいだけなのです。

ということではないのです。「やむをえず」そうなっているだけなのです。

患者の命より医師側の都合を優先するとき、彼らが理解してやっていないと思われますか？
事情を理解しつつ「やむをえず」やっているのですよ。医療の現場では「できなくてもよい」という場合が多々ありますが、それは「自分の利益を守りたいだけ」などではないのです。

きっと生島さんはこう言うでしょう。

> 理解してやっている以上、犯罪の域です

日本の医療従事者の大半は犯罪者ということですね。過酷な連続勤務に追われ、論文を書く暇もなく、医療ミス訴訟のリスクにおびえながら、自分のできる範囲で懸命に人の命を救おうと奮闘している人々に聞かせてあげたいものです。

> 理解してないなら、今すぐ直せ、理解してやっているなら許せない！

たいていの人間は、生島さんが思っているより善の心を持つものです。医療従事者のほとんどの人が患者を切り捨てるようなことをやめたいと心から思っているのです。しかし悲しいかな、現実は理想では動かないのです。
そういう例は世の中にたくさんあります。いやむしろそういう例の方が多いでしょう。
制限速度40キロの道を時速50キロで走行する。厳密に言えば道路交通法違反だと理解している。でも、周囲の車の流れに乗るためとか急いでいるからとか様々な理由で、現実に40キロで走行している車はほとんどありませんね。これが現実でしょう。

生島さんのご意見は、視野が狭く現実を見ていないと思わざるを得ません。
それともご自分の主張を叫ぶために、わざと無視しているのでしょうか。

おそらく生島さんはＩＴ業界では切れ者の方なのでしょう。しかし頭のよい人にありがちな過ちを犯しています。自分の考えが間違っているのかもしれない、とは考えようともしないことです。
そういう人は都合の悪い反対意見に対して、口汚く攻撃するか、巧妙にはぐらかすか、無視するかどれかを行うものです。生島さんがまさにやっていることです。

> 普通の人は文脈で理解しているようですけどね。

たまたま何人かが理解しているかのようなコメントを書いたところで「普通の人」が理解しているということにはならないでしょう。要するに「理解できないお前がカスなんだよ」とでも言いたいのでしょうか。

それから、他人のコメントに口をはさんで恐縮ですが、flatlineさんの「なぜ高校生に負けてはいけないのか？」というご質問に対して、

> 多分、エンドレスなので止めたいのですけれど、プロを名乗るなら負けたイカンでしょう。

と答えていますが、「なぜ」に答えていないですな。
これは私も知りたいので、はっきりと理由を書いていただけるとうれしいです。
くどいぐらいに「高校生に負けたら恥」「私なら腹を切る」などと言っていますが、そういえば「なぜか」を書かれていないと思われます。
「考えればわかるでしょう。わからなければ説明してもムダ」などと逃げずに書いていただきたいです。
素人目から見るとflatlineさんの、

> 私が考えるプロは、自分のスキルはどうだろうと、会社から与えられた業務を逃げずに完遂することですね。その過程で高校生に負けようと関係ない。

という考えは非常にすっきりと頭に入りますが、生島さんの「SQLで書けばパフォーマンスは出ますが...」は、お得意のはぐらかしであって、理由になっていないと思います。「負けたら恥ずかしい」というだけの面子でしかないと思いますので。

余談ですが、事業仕分けのスパコン問題で「世界一になる理由は何があるのか？２位ではダメなのか？」という、すっかり有名になったセリフを想起させますね。flatline さんはそれを意図されたのでしょうか。

分からないですかね。

例ですし、注射器を使いまわせば感染症になる。というのが、分かってなかったら知識の問題、分かった上でやるのは倫理的な問題で犯罪にもなり得る。

高校生レベルの技術がなく、遅くて高いモノを売ってる。というのは分かってなかったら知識の問題、分かった上でやるのは倫理的な問題で犯罪にもなり得る。

医師が足りないから命の選択をしなければならないというのは、一人の医師ではどうにもできない構造的な問題。そんな主題から外れたことを言われてもな～。

ごめん、なぜ負けても良いかは分かりません。

コの業界を志す高校生というのは、新人にすらなってない卵です。
その卵にいっぱしの給料を取っているプロが負けてはならないというのは、私の中では、極当たり前の話。
時給750円ならギリギリ許せるけど。
常識のレベルが違いすぎますわ。

皆さんこんにちは。

> 私が考えるプロは、自分のスキルはどうだろうと、会社から与えられた業務を逃げずに完遂することですね。その過程で高校生に負けようと関係ない。

いや、結果を出さなければだめでしょう。プロなんだから。。。
結果を出すためには、高校生に負けていたらだめでしょう。。。

カンベンシテクダサイ。
読んでいて痛々しくなってきました。