個人としてはうれしいけれど、中小企業にはちょっと辛いかも。09:40ビガーです。>RDBMSを使っても「こうすればSQLを使うより効率的」。いうまっとうな反論は>1つもない。RDBMSを使うなら最終的にSQLを使わざるを得ないのだから、反論も何もないと思います。効率を重要視するなら、SQLを自動生成して効率化するO/Rマッパーについてもっと具体的な製品なり、思想なりに言及するべきです。私は、DBFluteを使用しての開発効率の良さを以前のコラムで提案しています。今一度DBFluteのよさを具体的に話しておくと、物理テーブル定義から1テーブルに対するCRUDを補完できてしまうところ(物理テーブル定義が変わってもDTOに紐付くオブジェクトにしか変更の影響がない)にあります。ストアドも変更については同様でしょうが、初回開発時にどうしても独自実装をする必要があるはずです。(自社内であればテンプレートを作ってあるのでしょうけど)どのようなお客様の環境であっても、オープンな仕様で、それを自動生成の設定だけで済むのは、非常に効率的です。まっとうな反論が1つもないという結論を出す前に、システム全体の視点でOSSの有用性を検証されると、さらに良い効率化が図れると思います。11:16こんばんわ。>ですから、手遅れにならないうちに気づいてくれたらと思って書いています。>アラフォーなら、かなり手遅れに近いけど......。生島さんが9:11に書かれた内容は、私も正しいかあなと思います。顧客から見れば、工数とパフォーマンスは大事ですからね(あとお金も)。話が違うかもしれませんが、特定派遣で現場を転々としながら働いていましたので、工数と成果物に対してはすごく意識していました。出来が悪ければ、更新もないし今後その会社で使ってくれませんからね・・・。アラフォーって35~44歳のひとのことをさすようですが、私も少しこの世代に被ってます。私も手遅れなんですかね・・・。11:46生島さん、こんにちは。いつも議論を起こさせる内容で読むとうまいなぁと思いますが、コメントを読むとなかなか意図が伝わらないんだなと感じます。私もそうですが、コラムってやや大げさすぎるぐらいテーマに対して表現したりピックアップしたりする事でいろいろな議論を引き起こせるのでそういう部分では上手だなと昨年のランキングからも思います。言葉になってる部分も伝わらないのは読んで考えていない証拠だと思うので、考えていないエンジニアが多いのかなとも感じてます。プロフィールに「イノベーションってやつ起こせたらいいな。」と書かれているのでこれはこれで起こせてるんじゃないの、って気がします。生島さんの事は好きな人と嫌いな人がコラムだけを読んでいる人の中では(現実に知っている人は別として)はっきりしているんじゃないでしょうか。私自身はエンジニアとしては非常に興味のある人なので機会があれば一度一緒に仕事をしてみたいとコラムを読んで思う人の1人ですが、多分けちょんけちょんにされて終わりそうなのでもっと精進が必要ですな。今年もガンガン進んでください。13:31おはようございます。アラフォーなら、かなり手遅れに近いけど......。うーん、そうでしょうかね。何かを勉強するのに年齢は関係ないんじゃないですかね。13:41私の考えるIT技術者は「自分が欲しいと思った物を現実に創り出すことのできる人」です。この定義だと技術者全般に言える事だから、ITとは限りませんね。顧客になりきるのは大変です。「自身=顧客」の場合、ニーズがはっきりするためいいものができると思うのです。自分たちが欲しいと思って作ったものが世間に受け入れられた例としてyahooとかyoutubeとかがそんな例でしょうか。勝ち残ることができたのは「自身=顧客」だったからで「自身≠顧客」の場合、淘汰されてお仕舞いです。チャレンジするのはいいことだから淘汰されたとしてもその行動力は称えたいものです。SI業界はなかなか淘汰が進まないってことなんでしょうけど「自身=顧客」に近づくためにも「内製化のススメ」にあるように顧客が作る立場になったりSI業界内に元情報システム部門の人を入れるとか人材の交流をはかる必要があるんじゃないかなーとか思いました。自分が癌になって初めて患者の気持ちが分かったみたいな話も聞いたりしますから、経験しないと理解できないものが人間なんだと思ったり。14:29IT技術者は効率を求めなければならないという至上主義だけぶちたててしまったら、極端な印象は受けますね。「顧客の業務効率の向上」を求めるには「IT技術者」が具体的に何をしないといけないのかという点も見えてこないので論点がぼけてるような気もします。そのあたりはコラムを書かれる前提にもたれているんでしょうけど。業務の効率化にはやはり予算も期日も立ちはだかる訳ですから、あと要件を正しく聞き出し設計し実現する能力も要されるし、それらを正しく運用できる業務体制のコンサルや仕切りも必要になる。それらすべて直接担当しないまでもIT技術者が求められるスキルも多種多様になるかと思います。努力しないやつにはする必要性がないからしないだけです。いう職業人間的の連中に大義名分において○○○○”しなければならない”ってといたところで空振りなような気がします。ならなければならないのかというのを正義感以外の必要性で説いていただければ非常にわかりやすいコラムになるかと。どちらかというと他業種とちがってIT業界は国が設定しているわけでもなければ業種枠が曖昧だと思います。税務署員は万人がみて税務署員ですが、IT技術者ってなにってところが最大の難問ですかね。今一度DBFluteのよさを具体的に話しておくと、物理テーブル定義から1テーブルに対するCRUDを補完できてしまうところ(物理テーブル定義が変わってもDTOに紐付くオブジェクトにしか変更の影響がない)にあります。17:23はじめまして。考えさせられることが多いので、当コラムはよく読ませていただいています。私はシステムの目的が業務効率化だけだとは思っていません。お客さんがもとめるものは、"提供価値の向上(売上、サービス品質)につながる"とか、"コストが削減できる"とか、それから"法対応"だったり、これらをすべて業務の効率化ってワードで括るのは無理があると思います。いう意味では枝葉末節まで全てこのコラムの内容に同意するわけではないのですが、「プロとして仕事をする上で最低限の知識を習得すること」に対して、これだけ否定的な意見がでることには違和感を感じます。初級シスアドって、程度の差がどれだけあったとしても、2-3ヶ月もみっちり勉強すればまあ合格水準にいく試験ですよね。いう意味では、せいぜい生島さんが仰っていることは「公道を運転するなら運転免許ぐらいとっておかないと」というぐらいの話だと思っています。私自身は情報システム部門で3年半働いてからコンサルに転職して10年選手です。サルに転職してすぐのころに炎上しているプロジェクトに突っ込まれたとき、お客さんから「XXさん高いんだからトイレ行かないでよ」と言われました。お客さんが掛けた分のお金に見合う品質の成果物がでてこないと駄目ですよね。後に続く人たちがIT技術者という職業にプライドを持てる業界にしていくことが重要なんだと思っています。私はお客さん側からじゃなく、こちら側から意識改革できると思っているんですけどね。18:04ビガーです。生島さんと話してみたかったんですが。>ronさん今回は、データアクセス層の生産性(効率)の話をしています。(生島さんのネタに合わせて)で、DBFluteの設定の話ですが、基本的にDBの接続情報を記述するのみで、O/Rマッピングの設定などは一切不要です。(マッピングされたオブジェクトがすべて自動生成されます)一度使ってみればわかりますが、本当に生産性は素晴らしいと思います。それと、基本的にテーブルと1対1ですが、外だしSQLなるものを使うと結合などを伴う複雑な検索の結果とオブジェクトのマッピングが容易に記述でき、自作コード量が圧倒的に減ります。(この結果オブジェクトも設定ファイルに則り、すべて自動生成されます)まぁ、個人的には、DBFlute自体の拡張性(Seasarにもいえる)には不満があるので、好きではないのですが、生産性という面でいうとこれほど素晴らしい実装はないと思います。トランザクションやロックは、基本的にビジネスユースケースの単位となるので、サービス層で考慮すべきことで、データアクセス層で考慮する要素ではありません。ロックについては、物理的にはDBの機能を利用することが多いですが、性能面等を加味するとインメモリで実現した方が望ましいし、今後その方向にシフトするでしょう。ストアドで処理させるという選択肢以外の技も求められると思います。20:07あけましておめでとうございます。今年も生島さんのコラム楽しみにしています。作業を行うにあたって、OSや言語、周辺技術などの範囲が広く、勉強するにもどの分野を勉強して行くのか的を絞ることさえも難しいってところにも問題があるような気がします。限にあり、進もうとする道が違う人が出てくるのも致し方ないでしょう。生島さんが仰られている「初級シスアド」程度の試験に出題されるのだからプロとしては最低限そのレベルにあるべきということには激しく同意します。IT技術全般をすべて抑えておくってのは不可能に近いと思っていますが、より上流の工程で作業を行う人ほど多岐にわたる知識を身につけておく必要があると感じます。お客様との会話に出てくるものが自分のあつかってきた技術に関連する話だけになるとは考えられないし、システム全体の会話になった時に正しい判断ができないと考えます。本当に専門的な内容の話をしなければならないときはその技術に精通した人を交えて会話すれば良いでしょうが、それすらも判断できない場合がでてくるのではないでしょうか。実際に目にする自称上流の技術者は何もできない人が多い!!変なプライドは捨てて、一からやり直してみるべきだろうといつも感じます。21:54あぁ...自分で名前を打ち間違っているorzなにやってんだ>おれコラムに関係ないコメントですみません。それと、基本的にテーブルと1対1ですが、外だしSQLなるものを使うと結合などを伴う複雑な検索の結果とオブジェクトのマッピングが容易に記述でき、自作コード量が圧倒的に減ります。トランザクションやロックは、基本的にビジネスユースケースの単位となるので、サービス層で考慮すべきことで、データアクセス層で考慮する要素ではありません。ロックについては、物理的にはDBの機能を利用することが多いですが、性能面等を加味するとインメモリで実現した方が望ましいし、今後その方向にシフトするでしょう。ストアドで処理させるという選択肢以外の技も求められると思います。12:42皆さん、こんにちは。コメントのレベルが低いとイライラし、高くなると返すのが大変になります。取り急ぎ、ビガーさん私も実際の現場では拒否しても進みませんから、大抵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マッパーを作りたいというモチベーションが技術者にも企業にも出てこないでしょう。憶測ですが、宣伝文句がそうなっていますからね。MDB)からスタートしました。VB4にシフトしてたら、今は喰えてなかったと思う。本当に簡単で、デメリットはないのですけどね......。16:52こんにちは。気になる事があるので一言。>そうでないと、O/Rマッパーを作りたいというモチベーションが技術者にも企業にも出てこないでしょう。これはちょっとO/Rマッパーを作った人に対して失礼だと思います。私もO/Rマッパーを開発しましたが、その理由は開発生産性を上げるためです。SQLは知っているのが前提で、決まったルーチンワークを自動化するために作りました。大概のO/Rマッパーの作者の動機はそうだと思います。「O/Rマッパーを作る人はSQLを知っているから」です。何もSQLから逃げたくて実装したのではないと思います。SQLから逃げたい人がO/Rマッパーを誤用しているのです。宣伝は確かに頂けないものが多いです。これはO/Rマッパーに限った話しではありません。O/Rマッパーの作者までその様に言わない方がいいと思います。PCはプロジェクトを知らないので、本質的に出来あがるコードの効率が悪いからです。メタデータが無いので、最適なSQLを吐けないのです。メタデータを加えたら簡単なシステムならば自動生成する事も可能ですが、それは最適なシステムとは言えません。O/Rマッパーは一時的に開発生産性を上げるものであり、お客様の生産性を上げるものではないのです。その違いが大事なのです。どんな道具も適材適所。使う人が賢くなければならないのです。18:52>IT技術者は「顧客の業務を効率的にする」ために存在するのです。ここに至る考察・理由については、特に書かれていないように見えるのですが、どうなんでしょうかね?ここがに違和感を持ってしまうと、すべてがビミョーーーになってくると思いますが。私は違和感を持ちました。「効率」を追求すること、これは、モラルや必要条件の1つでしかないと思われます。IT技術者は「顧客のために、無形の技術であるITを駆使し、顧客にとっての価値をサービスする」ために存在するのです。とうようなニュアンスではないかと思ったのですね。文章表現うまい人は、もっと違った言い方があるのだとは思いますが。この価値が、「効率」である場合もあれば、「魅了する」事や「安定性」である場合、その他の場合もある。(複数の価値を求められる場合がほとんだと思いますが。)「効率」を疎かにしないという事とIT技術者云々や医者との比較はちょっと、無理があったような気がしました。(好意的に読まない場合、色々と。00:14>SQLを使い切るために作られたモノではなく、「SQLを使いたくない」「見たくもない」「SQLの方が(開発・保守ともに)難しい」という前提があると思うからです。O/Rマッパー作者の本音としては『見たくもない』というところがあるのでしょうが、O/Rマッパー(注意:DAO/DTOではない)の登場は、まさに効率のためです。おいては飛躍的に向上します。保守性の向上が実感できないのでは、失礼ながらO/Rマッパーをまだ使い切ってはいないのではないでしょうか?そうでなければ、ここまで支持されることはありませんから。SQL直書きとは仕組みが大きく違いますから、間違った使用方法を覚えてしまうと、かえって工数を増大させてしまいます。O/Rマッパーは、まさにイラチ向きの仕組みなんですけどねぇ。昔の「統合インターフェイス」モデルへ回帰しようとしているように見えるのは,まぁ、あの会社は、色々な技術をかき集めていますからねぇ。自社にはない、新しい有用そうな技術が出てきたら、それをパクって(あるいは買収して)あたかも自社で開発したかのように発表する。『フルライン戦略』という、マーケティングの理論上では正攻法なんですけどね。何か統一性がないような印象を受けるのは、そのためです。MSしかり、ディズニーしかり。03:10情報システムで飯を食って30年以上がんばってる定年間近の老人SEです。若い皆さんの議論を読んでいて思わず参加してしまいました。老人のつぶやきとしてお許し下さい。企業が業務で使用する情報システムは「顧客の業務を効率的にする」ためあります。それが、コミュニケーションを円滑にするシステムであろうと、経理システムであろうと、関係ありません。古典的なシステム感で云えば、100人の人間がする作業を10人で出来る様にする。一言でいえば「合理化」です。その情報システムを作るIT技術者が「顧客の業務を効率的にする」為に頑張るのは当然です。別の見方をすれば、IT技術者が戴く対価は、効率化の結果として得られた利益の一部を納品先から戴いているのです。導入した情報システムが利益を減らしていたのでは、対価を払って戴く原資がなくなります。書くと老人の小言になりそうなので、この辺で止めておきます。追伸(構造型データベースで開発していたので、RDBMSが出た時には感動しました。IBMのS38が導入された時には嬉しくて、マシン室に入り浸っていて怒られたの懐かしく思いだしました。「情報システムを通して、客先ビジネスに貢献できること」というところが本質だろう、と個人的に考えています。この視点からは、IT技術者という職種にも、コミュニケーション力が相当程度必要かな、というのが私見です。顧客が説明しきれない部分を、こちらから誘導して聞き出すような。このあたり、お医者様の問診に通じるところがありそうですね。効率的なシステムも、きっちり使われなければ持ち腐れですよね。客先の利益に貢献するところまでが我々の仕事だと思っています。・・・と、コラムの題に反応してみました。00:39ビガーです。生島さん、レスありがとうございます。>OSSの利点とかないことはないけれど、劇的に効率が良くなるわけでもないのに、>次々に新しいモノが出てくる方にシフトしたくない。変わるたびに余計な工数が掛かります。私の認識では、OSSを利用することで劇的に効率が良くなることがあると思っています。一般にOSSは十分に枯れているものが多く、自作のものより品質が間違いなく高い。新しいと思われるモノも結局古いモノの思想を流用(DBFluteもTorqueやS2Daoなどの思想を継承して良いところ取り)して、進化しつづけているわけで、新しいモノも蓋を開けてみれば、それまでの技術の組合せであり、本質的なことが理解できていれば、大した工数にはならないと感しています。効率以外の要素もあるので何ともいえない部分は多くありますが、自戒を込めて、新しいモノへの探究心は、なくしたくないと思っています。>O/Rマッパーを目の敵のように悪くいうのは、SQLを使い切るために作られたモノ>ではなく、「SQLを使いたくない」「見たくもない」「SQLの方が(開発・保守>ともに)難しい」という前提があると思うからです。今まで一度も発言してきませんでしたが、SQLを勉強しないというのは、あり得ないと私も思っています。O/Rマッパーを使っても、結局独自のクエリー言語を学習する必要がある場合がほとんどで、構造はSQLとほぼ一緒のため、事実上、SQLを勉強することになると思っています。O/Rマッパーの謳い文句(SQLを隠蔽することなど)を誰が言い出しなのかわかりませんが、オブジェクト側にドメインロジックを持たせるとたくさんのメリットがあるから、比較的大規模なエンタープライズシステムでは、そうしましょうという発想ではないかと思います。規模や開発者のスキルにより最適な技術を選ぶのがあるべき姿なので、唯一の正解はないと思うのですが、自戒を込めて、技術の選択肢が多い技術者に価値があることは間違いないと思うので、改めて精進していきたいと考えています。11:25こんにちは。今年も盛り上がってますね!皆様の育った環境で色々考え方は違って当然ですね。誰かに「雇われている」という立場でまず考えなきゃいけないのは、1技術者として技術を提供する2ビジネスマンとして顧客満足を提供する。大まかに分けるとこの二つの提供をするのがIT事業なのかなと思っています。生島様は技術者としてのお話をされていると思います。その視点では正しいと思います。僧侶や牧師やカウンセラーではなく、医者ならば、それらは必要であっても補助的な能力で(補助的だからカウンセラーを雇う病院はたくさんある)、最低限必須な能力は医療技術でしょう。ここについてはちょっと疑問があります。カウンセリングをどの意味でつかわれているのか分かりませんが(wikipediaによると最近「心理的な問題や悩みについて援助を目的とするものを、指すことが多い」という感じらしいので)、ここでは文脈から「問診」として扱わせて頂きます。医療技術があっても問診ができず、患者さんがうまく表現できないために誤診して投薬ミスをしてしまったのでは話になりません。私的には両方必要条件だと思います。どちらかに特化することもただし、生島様のおっしゃられている通り、即命にかかわるようなことはあまりないと思います。(医療システムだとまずいか・・・・あと金融系もクリティカルかも・・・)ですのでどちらかに特化することも「アリ」だと思います。チーム開発を前提にすれば人間の配置でクリアできます。技術屋はガリ勉すればできますが、コミュニケーションはどうしてもダメって人がいますので。私自身はコミュニケーション寄りでありますが、最低限の技術は常に追いかけている状態です。流行りには乗ってみないとだめですからね。机上の知識だけじゃお客様に顔向けできません^^;資格についても勉強はしますが、受験はしませんね。知っていれば十分ですので。19:26はじめまして。ハツカさんと同じくエンドユーザ側の人間です。内製化のあたりから読んでます。・結局何がやりたいのかわからないの3点です。医療技術とIT技術を同列に扱うのは大間違いです。医者になるには6年間医大に通って卒業し、国家試験に合格し、臨床医になるならさらに2年以上の研修期間が必要です。費用も国立か私立かで異なりますが、千万円単位でかかります。こんなに厳しいのは医者の知識不足は患者の命に直結するからです。本番環境のコピーを作ってデバッグすればいい、ということができないのです。医師は患者の命を救うことだけに集中していればいいわけではありません。命とトレードオフするのが「医者の都合」だったら「ふざけるな!」ってなりますよね。「ふざけるな」かもしれませんが、現実にはこんなことはザラにあります。「緊急救命24時」とか「ER」とか見てもわかると思いますが、多数の患者が同時に来院して医師の手が足りない場合、まさしく医師の都合で助かる見込みのない患者は見捨てることがあります。問題になっている救急車のたらい回しなど、医者(病院)の都合によって助かる命が助からない場合もあります。患者に投与できる薬剤も、国で認可されているものだけです。患者数が少ない病気(ある種の膠原病など)は、利益が出ないために研究すら行われない場合があります。外科医が選択する術式だって、必ずしも患者にとって最適なものであるとは限りません。術者が得意な術式を選ぶこともあれば、研修医のトレーニングになるような術式を選ぶこともあります。○○教授派閥だから、△△法を選択という場合だってあります。論文の症例を増やしたいために、××法を行うという場合もあります。医師が処方する薬だって、○○製薬さんにお世話になっているからとか、△△製薬さんの担当者の方が美人だからという理由で決まることがあります。医者が、患者の命より他のものを優先するとしたら、「尊厳死」のような特殊な問題以外あってはならないでしょう。なんてことはなく、現実には患者の命以外のものが多く優先されているのです。「医は仁術なり」は江戸時代なら通用するかもしれませんが、現代社会では(少なくとも日本では)通用しません。それから例としてあげられている注射器の使い回しですが、例として適切ではありません。注射器の使い回しをしないのは、知識のありなしではなく倫理の問題です。今なお、注射器の使い回しは日々発覚しています。現実を知ってください。自分に都合のよい部分だけ切り出して脚色するのではなしに。・2点目いろいろ問題となっている過激な罵倒の件です。「派遣村に行こうとノタレ死のうと、自業自得」だと言っているわけです。プロを名乗っていいかどうかはともかく、後は確かに読んでいて不快です。過激な言葉を書き連ねて注目を集めて、あわよくばセミナーに来させようとしているのでしょうか?迷惑メールと同じ手口で姑息に感じられます。一定の能力がない人間は生きている資格がない、死んでもよい、というのは、典型的な優生学思想そのもので、ナチスドイツの例を取るまでもなく、現代の民主主義社会では忌避されるべき思想です。比喩として書かれたと言うかもしれませんが、そのような思想を冗談でも口にするだけで、人は特定のバイアスをかけて聞くことになるのです。私自身、コラムに書かれている内容うんぬん以前に、生島勘富という人物を安っぽい新興宗教の教祖と同レベルにしか見られなくなってしまいました。布教活動などと書いてあるのでなおさらです。それから、誰も問題にしていないのに○○大学の誰かを泣かせたとか、高校中退の人を使っているとか、高校生レベルがどうとか自慢げに発言されていますが、これらも低レベルな自慢で滑稽ですらあります。学歴コンプレックスを喧伝しているようなものです。「学歴なんてばからしい」という人ほど、学歴を気にしているものです。過去3~4つぐらいのコラムを読んでみると、「IT技術者を名乗るなら、一定の技術力を身につけましょう。RDBMSを使うならSQLですよ」と繰り返し主張されています。その是非はおいておくとして、その主張の元に一体何がやりたいのでしょう?顧客を巻き込んでの下克上って何なのでしょう?その下克上とやらが成功すると何がどう変わるのでしょう?誰が得して誰が損するのでしょう?そのためには何が必要なのでしょう?「~はず」と「~べき」ばかりで具体策が何も書かれていないため、過激な文言ばかりが目に付いてしまいます。何らビジョンがないのであれば「まだ具体策はこれから考える」と書けばいいし、明確なビジョンがあるならつまらない比喩など使っていないで明確に書いていただきたいです。ビジョンはあるが企業秘密だというなら、その旨明言すればよろしいでしょう。今のままでは、誰かがコメントで具体的なことを質問するたびに、「個別の事情」だとか「過去に言ってきた」と逃げているようにしか見えません。以上、思いつくままに書き連ねました。20:29今回のコラムって分かり安いと思っていたんですが、人によってはそうでもないみたいですね。毎回毎回内容が易しくなっていると思うんですけどね。確かに生島さんの書いている内容はきれいごとかもしれないし、理想論かもしれない。俺はそっちの方が好きなので、必死にあがいて勉強するつもりです。顧客が知識をつければ、出来損ないのSEに言いくるめられて効率の悪いものを提供されることを減らせる。末端の技術者が知識をつければ、顧客に対していま提案しているものよりも良いものを提案、提供ができるかもしれない。末端の技術者が知識をつければ、上の方にある知識がない役に立たないのSEを駆逐できる。実現するのは決して簡単ではないし、無理かもしれない。やらないことには現状は変わらないわけで。個人的には知識というのは選択肢だと思います。選択肢の量が必ずしも絶対的ではないとはいえ、選択肢があればより顧客満足度を上げることができる可能性があるのもまた事実だと思います。(個人的には顧客満足度よりも顧客の業務の効率効率の方が適切だと思っていたり)だからこそ学べっていうことだと思います。00:25初めまして、こんにちは。「当たり前のことを当たり前にやろう!」という内容にもブレを感じない文面になっていると思います。>「わたしはSQLにこだわってるのではなく、「効率」に>こだわっていて、RDBMSを使うのにSQLを十分に使わなかったら>非常に非効率である。1年間そんなことばっかり書いていましたが、>RDBMSを使っても「こうすればSQLを使うより効率的」。いう>まっとうな反論は1つもない。生島さんがこのコラムを書く理由はコレに尽きるんじゃないのかな?コレに対するまっとうな反論が欲しくてコラムを書いているじゃないのかな?コレに対するまっとうな反論と対決したいんじゃないのかな?そう感じます。反論がブレているとしか思えません。すればよいかと思います。(生島さんもソレを待っていらっしゃるようですし^-^)私も議論の輪の中に入れるようにがんばります。駄文散文失礼しました。/*追記*/コメント欄全編通して感じる事ですが、経営者視点と雇用者視点の差異が色濃く出すぎている気がします。現実的に、SEなりプログラマなりが個人として損害賠償請求される可能性って、どれぐらいあるんでしょうかね。悪くて依願退職を迫られるぐらいではないでしょうか。個人を対象に損害賠償請求するのはかなり難しいと思いますが。技術者としての能力が低いという理由では、まず起訴までいかないのでは。刑事裁判の場合、立証責任が検察側にあるので、「プロの技術者としての適格性を欠いていた」という立証なんてまず無理ですから。民事裁判にしても、この場合、原告側に同様の証明が求められると思うので、そんな裁判するぐらいなら、適当なところで和解するでしょう。個人から取れる損害賠償金額なんてたかがしれてるから。どれぐらいあるんでしょうかね。悪くて依願退職を迫られるぐらいではないでしょうか。技術者としての能力が低いという理由では、まず起訴までいかないのでは。10:16横からですがちょっと補足を。>もんもんさん>枝葉末節に食いついて反論される方もおられる様ですが、>反論がブレているとしか思えません。"論破"というと表現が少々キツイですが。ビガーさんあたりが的確に反論していると思いますよ。『自動発行SQLによる効率悪化は認めるとしても、そのほかの寄与分で悪化分を十分回収可能。トータルで見ればお釣りがくるかもしれない』という別の道(の可能性)を提示しているわけで。実際、どちらが優位かといわれると、私なんかも、ケースバイケースじゃないかと思いますね。>flatlineさん、ronさん使用者→被用者の求償、という事例は結構ありますよ。最終的に求償するかどうかは、使用者側の裁量です。運送業界なんかでは結構あるみたいです。過失責任で刑法犯に問われることも多いです(業過とか)。過失責任で検察のお世話にはならないと思います(故意犯は別)。こんばんは>枝葉末節に食いついて反論される方もおられる様ですが、>反論がブレているとしか思えません。すればよいかと思います。主張がはっきりしていて、論点がわかりやすいのであればそれに対して反論できます。論点がわからないので反論とか論破といった種類のことをするものではないですね・・・。少なくとも、文面どおりSQLとか効率とかそういったことに主張がある訳ではないということは、過去のエントリーを読んでいただければわかると思います。「内野竜馬」と「福山竜馬」って、別人が演じているとは思えませんね。それだけ完璧な演技ということなんでしょうけど。じく未踏で日本語プログラミング言語「なでしこ」を開発した酒徳氏らは、「(IT)技術者」には当らないわけですね。彼らは「効率」ではなく、「楽しさ」や「安全」や「教育」の為にITを駆使しているので。彼らは全員「技術」のレベルにおいて生島氏より上だと思いますが、それでも生島氏の定義では、彼らは「(IT)技術者」ではないということになります。生島氏は、記事を読む限り、「効率」という言葉を定義せず、恣意的に使っているように見えます。ビガー氏が書かれているように、世の中には「開発効率」や「保守効率」という「効率」もあるのに、「SQLを使え」という生島氏の主張は基本的には「実行効率」のみを追求したものになっています。そもそも「実行効率」だけを追求するのであれば、汎用RDBMSなど使わず、アプリケーション毎にそれに特化したストレージとアクセス・メソッドをゼロから作ったほうが絶対性能は向上します。実際昔はそうやって開発が行われていて、RDBが考案された頃は、「RDBMSなどという汎用基盤を使ったら実行速度が落ちる」という理由でなかなか普及しませんでした。今そうした開発をやらないのは、RDBMSとSQLという汎用基盤を使ったほうが、「開発効率」が上がるからでしょう。したがって、「効率にこだわっているからSQL」という主張はそもそも変です。この「効率」が「実行効率」を意味しているのであれば、SQLではなく自前のストレージとアクセス・メソッドに行き着くはず(もっと言うと「SQLなんぞ使わず全部機械語で書け」という話になるはず)だし、「開発効率」を意味しているのであれば、SQLを自前で書く以外の手法(例えばSQL自動生成ツール)なども受け入れるはずだからです。結局生島氏は、「効率」という言葉を恣意的に使って、「SQLを高度に使いこなすことが"技術者"にとっては必須」=「SQLを高度に使いこなせる自分こそが技術者として正しい」という主張を正当化したいだけでしょう。07:59>rtさん顧客とその人たちの目的を定義しないと根本的にずれたままですよ。顧客は何が求められているのかを定義する。(ヒューマンスキルがメイン)それをどう提供するかを決める。(技術とヒューマンスキル)そして、それを開発する(技術メイン)生島さんは業務系のシステムがメインです。業務系の人が求めているのは業務の効率化のために依頼するという考え方はそんなにずれていないと思いますが。初期のRDBは使えないと言う話は純粋にスペックの話になってくると思います。少なくともここ十数年のスペックの伸び率はかなりのものですから。安定性は言うまでもなくいまのRDBMSは高いです(昔のは知りませんが)。汎用システムを使うと言うことは、そいつを使える人間がわりと会社の外にも居るわけで。外部からつれてきた人間を自社のオリジナルのシステムの教育などから始めるよりも遥かに早く起用できるわけです。安定性と重なりますがトラブルが起きないように作るのは当然ですが、発生した際に事例が多い分調べれば何とかなることもあります。いまはいろんなソフトがRDBMSに連動しています。それらとの互換性の問題を考えると現実的ではありません。それに顧客がRDBMSに変更したいと言うときに速やかに移行できるのか、という問題もありますし。これらの理由を超えて効率が求められるのか言われると個人的には現実的じゃないなぁと。これをRDBMSを使わずに作れるんだったら汎用的にして商品化することさえ出来るような......(本末転倒)そして、RDBMSを使うんだったらSQLってことなのでは?O/Rマッパーは触ったことがないのでよくわかりません。SQLは変な文を書くと確かに処理が遅いと言うのはあるので、それを修正できるSQLの知識がある人が前提だったらありなような気も。触ったことがないので最後のは聞き流してくださいな。13:21"RDBMSと付き合って開発やっていかなきゃならんそんなSIerのIT技術者"がSQLわからんってアホか氏ね。それだけの話でここまで盛り上がれることにちょっと感動。同じ感想抱えて悶々としている人たちが居るんだなぁとちょっと勇気付けられたりするのです。現実はまぁ、「赤信号みんなで渡れば怖くない」業界ですやね。それはもうイロんな意味で。SQLを十分に扱える人すら自社に居ませんので。そんなバケモノが出来上がったりするんじゃないかなぁと思ってみたり。顧客とその人たちの目的を定義しないと根本的にずれたままですよ。その定義もなくこの記事を書き飛ばしているのは生島氏です。ここでいう「技術者」が業務系のシステムの技術者限定であるという定義があるのならば、最初っからちゃんと書けばいい。それが「コミュニケーション能力」というものです。今だって、「効率」という言葉の定義は曖昧なままです。初期のRDBは使えないと言う話は純粋にスペックの話になってくると思います。「かつての専用ストレージ」が「汎用RDBMS」に敗れたように、「今のRDBMS上に凝ったSQLを作り込んだシステム」が、「5割くらいしか性能は出ないけれど、開発/保守効率が2倍になる(数字は適当)SQL自動生成ツール」に敗れるという想定もまた成り立つわけです。ハードウェアの性能が上がれば、実行効率よりも開発/保守効率が重視されるようになる、というのは、この世界では普遍的なトレンドだと思います。#ご存知の通り、今実は大規模分散処理の分野では実行効率を求めてストレージ/アクセス系を自前で作る動きが盛んになっているのですが、それは業務系の話とは関係ないのでここでは無視します。私は実行効率以外の効率を否定しているわけではありません。上にも書いたように、むしろそういうものの方が今は重要になってきているという立場です。業務系システムを求めている顧客企業にとって非常に重要なのは投資効率だと思います。先ほどの例に戻ると、100万円のマシンで100万円/月の優れたSQLプログラマー1人月を使って開発し、保守もそのプログラマーが担当しなければならないシステムと、性能が2倍で200万円のマシンが必要だけど、(生島氏が口を極めて罵っているレベルの)今の標準的なRDBMSプログラマー(沢山いるので50万円/月)が1人月でSQL自動生成ツールを使って開発し、保守も同程度のレベルのプログラマーが行うシステムと、どっちが顧客にとって投資効率がいいかは、ちょっと考えれば分かる話だと思います。高度なSQLを使えるプログラマーが不要だと言っているわけではありません。今でも機械語でのプログラミングが求められるシステムもあるのと同様に、1000万円のマシンを使った上にさらに高度なSQLを駆使しなければならないシステムもあるでしょう。技術者個人がSQLの勉強をすることを否定しているわけでもありません。技術者が勉強することで、業界全体のレベルが向上するのはいいことです。全てのプログラマーが実行効率を求めて機械語をマスターする必要がないのと同様、全てのRDBMSプログラマーが実行効率を求めてSQLをマスターしていなければならないということもまたないと思います。長くなったので分けます。03:35何を習得するべきか、について、続きです。だいたい、実行効率のために_SQL_を勉強するというのは、SQLが宣言型の言語だということを理解していれば、変な話であることはすぐにわかります。生島氏は別記事で「アルゴリズムをSQLで表現する」と書いていますが、宣言型言語であるSQLの文面にはアルゴリズムは(ほとんど)表現されません(*注)。2:従ってアルゴリズムとその計算量の関係を理解することが重要であり、それができていれば、本来宣言型の言語であるSQLを手続き的に使うよりも、もとから手続き的に処理を記述する一般的なプログラミング言語(C,Java,Ruby等)を使う方が素直で間違いも少ない、でしょう。)宣言的に記述された処理を実際の処理手順(≒アルゴリズム)に変換するのは、RDBMSのプランナーです。最終的な実行効率はプランナーによって決まるわけです。上の注に述べた生島氏の「アルゴリズムを表現した」SQLも、実際にはプランナーによって解釈され、プランナーによっては生島氏が思い描いたのとは異なる処理手順で実行される可能性があります。「プランナーによっては」です。SQLは標準ですが、プランナーは各DBMSによって異なります。AというDBMSにとっては良いSQLでも、BというDBMSではマズいという可能性も、理論上はあります。すると実行効率を求めて勉強するのは、SQLよりも、個々のDBMSのプランナーについて、ということになります。それはもはや学習というよりは細かいノウハウの蒐集になってしまうでしょう。述べられているような理論(ここでは集合論)を体系立てて学ぶ方がはるかに役立つと思います。いう理論的な知識こそ本質的な知識であり、それは(先に述べたアルゴリズムや計算量の知識同様)言語やプラットフォームを超えて応用できる、価値ある知識だと思います。コメント欄で、集合理論や関係理論を重視しないという旨の発言をされていましたが、そういう理論軽視の態度が、日本のIT産業をいつまでもKKD(経験,勘,度胸)に依存する「土方」たらしめているという意味でも、私は生島氏の主張に賛同できません。08:20皆様、おはようございます。興味深いコメントも多いのですが、ちょっと時間がないので個別に返すことが出来ません。本当に申し訳ございません。代わりに続きを書かせて頂きました。14:06チームAさん、こんにちは。なんかリクエストがあったので(笑)医療関連のことなんて一般論のたとえ話ですから、普通の人が理解できたら良いのです。少なくとも、注射器の使い回しが現在も行われてたとして、知っていたらその病院を選ぶ人はないし、一人でも感染症を出せば傷害罪で訴えられるでしょう。医者が足りなくってどうしても命の選択をせざるを得ないのも不可抗力の特殊な例です。別に医療問題について書いている文章ではないので、その辺は普通の人は文脈で理解していると思います。不快であるかも知れません。「出来なくても良い」という主張は自分の利益を守りたいだけなのです。「どうせ人はいつかは死ぬんだから」っていいながら注射器を使いまわしている医者と同じ。本文にもあるとおり、高校生以下のレベルになっていてもOKと考える人は、倫理的に許せるレベルは超えている。理解してやっている以上、犯罪の域です。理解してないなら、今すぐ直せ、理解してやっているなら許せない!それだけの話です。やりたいことは、先進国で飛び抜けて低い(事務)生産性を上げたいのです。IT技術者はそれに大幅に貢献できる立場にあります。いうか、それを実現せねばならない立場です。普通の人は文脈で理解しているようですけどね。20:18お返事いただきありがとうございます。正直なところ、意図的になのか理解されていないのか、的外れもいいところです。・個々の事情は関係ないというところだと思います。・個々の事情は関係ないとなるでしょうか。その上で、注射器の使い回しを例にあげています。前にも書いたとおり注射器の使い回しをする/しないは、知識の有無ではなく倫理観の有無によるものです。ここが大きくずれています。医者が足りなくってどうしても命の選択をせざるを得ないのも不可抗力の特殊な例です。ご自分に都合のいい部分だけ適当に切り出していますが、私が言いたいのはそういうことではないとよく読めばわかるはずです。発言の一部を切り取ったらどうとでもなりますな。ご理解されていないようなので簡単に言うと、医療の世界において患者の命は最優先ではない、ということです。病院や医師個人の医学的・経済的な都合が優先されることの方が多いのです。「不可抗力の特殊な例」なんかではない。ドラマのように大量患者が押し寄せることだって、現在の病院経営と医師不足の実態からして現実的にありえない話ではないのです。「出来なくても良い」という主張は自分の利益を守りたいだけなのです。いうことではないのです。「やむをえず」そうなっているだけなのです。患者の命より医師側の都合を優先するとき、彼らが理解してやっていないと思われますか?事情を理解しつつ「やむをえず」やっているのですよ。医療の現場では「できなくてもよい」という場合が多々ありますが、それは「自分の利益を守りたいだけ」などではないのです。生島さんはこう言うでしょう。理解してやっている以上、犯罪の域です日本の医療従事者の大半は犯罪者ということですね。過酷な連続勤務に追われ、論文を書く暇もなく、医療ミス訴訟のリスクにおびえながら、自分のできる範囲で懸命に人の命を救おうと奮闘している人々に聞かせてあげたいものです。理解してないなら、今すぐ直せ、理解してやっているなら許せない!たいていの人間は、生島さんが思っているより善の心を持つものです。医療従事者のほとんどの人が患者を切り捨てるようなことをやめたいと心から思っているのです。悲しいかな、現実は理想では動かないのです。いう例は世の中にたくさんあります。いやむしろそういう例の方が多いでしょう。制限速度40キロの道を時速50キロで走行する。厳密に言えば道路交通法違反だと理解している。周囲の車の流れに乗るためとか急いでいるからとか様々な理由で、現実に40キロで走行している車はほとんどありませんね。生島さんのご意見は、視野が狭く現実を見ていないと思わざるを得ません。それともご自分の主張を叫ぶために、わざと無視しているのでしょうか。生島さんはIT業界では切れ者の方なのでしょう。頭のよい人にありがちな過ちを犯しています。自分の考えが間違っているのかもしれない、とは考えようともしないことです。いう人は都合の悪い反対意見に対して、口汚く攻撃するか、巧妙にはぐらかすか、無視するかどれかを行うものです。生島さんがまさにやっていることです。普通の人は文脈で理解しているようですけどね。何人かが理解しているかのようなコメントを書いたところで「普通の人」が理解しているということにはならないでしょう。要するに「理解できないお前がカスなんだよ」とでも言いたいのでしょうか。エンドレスなので止めたいのですけれど、プロを名乗るなら負けたイカンでしょう。答えていますが、「なぜ」に答えていないですな。これは私も知りたいので、はっきりと理由を書いていただけるとうれしいです。くどいぐらいに「高校生に負けたら恥」「私なら腹を切る」などと言っていますが、そういえば「なぜか」を書かれていないと思われます。「考えればわかるでしょう。わからなければ説明してもムダ」などと逃げずに書いていただきたいです。私が考えるプロは、自分のスキルはどうだろうと、会社から与えられた業務を逃げずに完遂することですね。その過程で高校生に負けようと関係ない。いう考えは非常にすっきりと頭に入りますが、生島さんの「SQLで書けばパフォーマンスは出ますが...」は、お得意のはぐらかしであって、理由になっていないと思います。「負けたら恥ずかしい」というだけの面子でしかないと思いますので。余談ですが、事業仕分けのスパコン問題で「世界一になる理由は何があるのか?2位ではダメなのか?」という、すっかり有名になったセリフを想起させますね。さんはそれを意図されたのでしょうか。20:30分からないですかね。例ですし、注射器を使いまわせば感染症になる。いうのが、分かってなかったら知識の問題、分かった上でやるのは倫理的な問題で犯罪にもなり得る。高校生レベルの技術がなく、遅くて高いモノを売ってる。いうのは分かってなかったら知識の問題、分かった上でやるのは倫理的な問題で犯罪にもなり得る。医師が足りないから命の選択をしなければならないというのは、一人の医師ではどうにもできない構造的な問題。そんな主題から外れたことを言われてもな~。ごめん、なぜ負けても良いかは分かりません。コの業界を志す高校生というのは、新人にすらなってない卵です。その卵にいっぱしの給料を取っているプロが負けてはならないというのは、私の中では、極当たり前の話。時給750円ならギリギリ許せるけど。常識のレベルが違いすぎますわ。14:50皆さんこんにちは。私が考えるプロは、自分のスキルはどうだろうと、会社から与えられた業務を逃げずに完遂することですね。その過程で高校生に負けようと関係ない。いや、結果を出さなければだめでしょう。結果を出すためには、高校生に負けていたらだめでしょう。カンベンシテクダサイ。読んでいて痛々しくなってきました。ワンシステムの代表取締役。新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。