毎度どうも生島さん。
一つ疑問があります。
COBOLerはOOCOBOLは使用しないのでしょうか？
COBOLerがオブジェクト指向を理解していない事はよく分かりますが、COBOLにもオブジェクト指向COBOLがあるのにも関わらずオブジェクト指向を理解していない理由が分かりません。
この件についてどう思われますか？

OOCOBOLで若い人に指導できるなら良いのですけれど、できないならJavaでも同じで、情報の多いJavaの方を選ぶということじゃないですかね。

分かる範囲で指導しようと無理すると、勝手にCOBOL風オブジェクト指向言語が簡単に出来上がってしまう。
おなか一杯になるほど見ませんでした？

それは、誰も指摘できず新しい文化になるのです。

SQLができるようになってCOBOLerたちが自尊心を保ち、尊敬を集められるようになれば、無駄にされている業務知識も活きてくるし、無理に下手糞な指導をしてCOBOL風オブジェクト指向言語を生み出す必要もなくなると私は考えています。

お互いに良い方向に向かうはずです。

下流技術者ほど、UMLを学ぶべき！！
無駄？いえいえ・・・ISO/IECの規格くらい使えるようになりましょうって言っているだけです（笑）。

設計書作成は実装の後で！！
よく考えたら、今回の案件でもリバースエンジニアリング機能で設計書起こしてたなあ（笑）。

ビガーです。

ふとした疑問ですが、身近にCOBOLerがそんなにたくさんいるんですか？
それとも生島さん自身の話なのかな？
人は変えられないけど、文化は変えられるんですよね。(とっても難しいですけど。。)

ちょっと方向性が私と合わないけど生島さんの信念にはいつも感服しています。

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

そうですね。
UMLが書けなかったら読めないですからね。

リバースエンジニアリングでも、元の仕様書が悪かったら作らないと仕方ないこともあるけれど、どうなんでしょう。
仕様書と実装者が違うというのは本当に効率的なのでしょうか？
私は仕様書だけ求められても、必ずソースを書きながら試行錯誤します。

指が遅いのでペアプロは結構好きで、思った以上に効率は良いです。

ビガーさん、ども。

私はデビューしたのが金融なので、COBOLを経験していないけれど、COBOLerです。
「COBOLができないなんて」と肩身が狭かった。

精神的にはCOBOLerの方が合いますが、技術的には噛みあうポイントはないです。

COBOLerには、尊敬に値する人はたくさんいるけれど、変わる必要がない、変われない、変わりたくない。
という人が大勢いるわけです。

その人たち（上場企業の部長級）が、ほんの少し努力するだけで文化は変えれると思ってアタックしています。

期末であまり進んでないけど、何社かはいけるかな。
実際のプロジェクトで成功すれば、その人たちがよく読んでいる日経ストラテジーあたりに出ることも可能で、一気に形勢逆転を狙っています。

SQLにしても、アジャイルにしても、別に新しいことを言ってるわけじゃないのに、「頭からできるわけない」で終わるじゃないですか。
つまり、下ができても、部長級がウォータフォールで考えていると、改革の芽はまだまだ弱いので、少し不安になった「大丈夫か？」ぐらいの一言で簡単に潰れて、いびつな形になってしまう。

いびつになった結果で、やっぱりダメってなってしまうからね。

オブジェクト指向COBOLなんて有る意味間違った方向へ行ったものだから仕方がない。
構文が使えるかどうかとかデータ型がどうとか、そこの所を読み替えて
作成できないような人間ではオブジェクト指向に結局作れない。
どちらかというと、OOCOBOLは既存COBOL資産にあまり手を加えずに
最近のシステムに移植を容易にする為のものじゃないですかね？
COBOLer向けの言語ではなく、COBOLerでない人が移植を楽にする為の物だと思う。
金をかけたくないけど何ぼか延命したいようなシステム向けではないだろうか？

結局、そのくらいしかメリット思いつかない。
生島さんが言うように、最初から普及している別の言語で作るでしょう。
今後のサポート自身も問題になってくるし。

結局COBOLerって揶揄されてる人は、実質本人に柔軟性が無いのかやる気が無いのか姿勢そのものが問題であって
じゃあSQLならと言っても殆ど無駄ではないでしょうか？
それよりSQLの部分が効率に重要な影響を与える事を理解している生島さんが
それほど重視している部分こそ、出来る人間が必要と考えないのが不思議。
下手をするとビジネスロジックとべったりになりかねないSQL部分で
中途半端にSQLが使えるようになった元COBOLerとか怖くないのかな？

としろうさん、ども。

> COBOLer向けの言語ではなく、COBOLerでない人が移植を楽にする為の物だと思う。

なるほど、ごもっともです。
でも、私はおそらく使うことはないと思うけれど、専門でやっている会社も周りにあります。

> 中途半端にSQLが使えるようになった元COBOLerとか怖くないのかな？

そこまで、COBOLerを嫌わなくても…。
「SQLですべてしろ！」って思っています。
それはアルゴリズムを取り上げることですから、中途半端はないと思いますけどね。

オブジェクト指向はいくらでも中途半端にできますから困るのです。

今までそんな極端なことを言う人を私自身見たことがないので、なかなか想像はしてもらえないのかも知れませんが、私はユーザアクションに対して、基本的にSQLは1回と考えています。

それができない人はオブジェクト指向も、SQLも諦めてCOBOLで生きるべきだと思います。
COBOLの仕事もないことはないのですから。

できないのに、できることになってしまっている人が上流でトンデモないことをやらかすのを防ぎたいのです。

40代、元COBOLer、現上流SEでJavaが主言語という、まさにサンプルそのままな人がいます。
ためしに例題を見積もり依頼しましたが5人日あれば十分だけど3人日だとギリって回答でした。
その人の部下も大方同じくらい。
通りかかった生粋のJAVAerに聞いたら2人日あったら嬉しいですけどって答えでした。

なんとなく、なるほどねーとか思いました。

一度、COBOLERとか、見積もりとか、大手SIerとか、情シスだとか、オブジェクト指向だとか、というコンテキストを全部とりはずして議論を検証した方が良いのではないでしょうか。つまり、本当に、この消費税の要件をSQLのところで実装するというのが良いのかどうか。そのように実装することのメリットは何で、デメリットは何で、そのような実装にするのが適しているとみられる状況としてどのような場合が考えられるか、というような整理をまずしておくことが必要な気がしました。人間系、社会環境系のファクターを持ちだす前に、ソフトウェア的、設計理論的な整理ができてないと、議論がぐちゃぐちゃだし、主張に（いいところがあったとしても）説得力が出てこないような印象を持ちました。私は、Javaプログラマーで、世代的にはアラフォーで、よくCOBOL文化で育った方々と一緒に仕事をすることが多い者ですけれど、私のようなサイドにも、生島さんの議論というのは、この論理展開では、あまりアピールしていない、いいアイデアであるようには見えないように感じられています。

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

もしかして、trmd さんはエンドユーザさまでしょうか。

その生粋のJAVAerの方は中々の腕だと思います。
しかし、生粋のSQLerなら半日でできるけど1人日いただけると「えぇ仕事ししまっせ！」
って感じですかね。1人日もらえたら社長としてはウハウハです（笑）

技術者の人口比率で考えると「生粋のJAVAer」は神として君臨していて、「生粋のSQLer」は排除すべき異人なるわけです。

そんな「生粋のSQLer」が本来の力を発揮できるのは、本物のデスマで悪魔に魂を売ってもとにかく終わればいい。ってときだけなのです。
普段は忌み嫌われる存在ですから、どうしてもデスマ参加率が高くなってしまう。

生活のために「賽の河原で石積み」を繰り返すしかない。

業界が変わらない限り、お客様に良いものを安く提供することもできないのです。

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

それが難しいのですよ。
だって、COBOLerはCOBOLの基準で考えるから、彼らがオブジェクト指向を十分に理解するまで議論にならないし、COBOLで喰える間は、オブジェクト指向なんて見向きもせず、いろんな、誤解、偏見、決め付け、強弁、言い訳で来たじゃないですか。

「そんなことない」と言うなら、COBOLしか知らない人に「（多重）継承の是非」を議論すると、どれだけ噛み合わない不毛な時間なるか分かるはずです。

そんな議論イヤでしょう。
私は、それを何年も全方位に対してやってきましたけどね（苦笑）

例題が30分でできない人は、できない人が作った基準で議論に来るわけです。
ソフトウェア的、設計理論的な整理を、できない人の基準で行っても意味ない。

COBOLしかできない人に、オブジェクト指向のソフトウェア的、設計理論的な整理をお願いする人はないと思う。

つまり、みんなRDBMSは使っているのだから、もう少し水準を上げましょうよ。
ってところから始めるべきと私は考えているわけです。

誤解のないように。

例題はあくまで例題で、絶対にSQLだけでするのが正しいと言ってるわけではないのです。

しかし、多くのプロが例題を読んだ瞬間にSQLは選択肢から外しているはずです。
少なくとも、大阪で私の周りで例題の要件が出て、SQLを選択肢に加えることはないと断言できます。

絶対にSQLではなく、選択肢に加えれるようになりましょう。

選択肢に入れて外部（UI）から作ると、検討している間にもプロジェクトは進みますから、結果的にはストアドプロシージャでグルグルか、SQLで一発かしか選択肢はなくなりますけどね。

え～と。どういえばいいのでしょうね。ちょっと、話が長くなります。

たぶん生島さんのおっしゃっていることというのは、あるコンテキスト、ある条件下では有効で、説得力があって、局面を打開していくのに役に立つ主張であり、それには他の状況下でも参考になるエッセンスが含まれているのだというような気がするのです。ただ、それがどんなコンテキストで、どんな条件下なのか、というのを明確にしないと、議論が発展しないし、言葉尻に反応するような感じでしか、話が続かないような気がしたのです。要するに何が問題なのか、何が解決策の仮説なのか、その仮説が有効であるとする根拠は何なのか、ということを、もう１度、明文化した方がよい、ということですね。

生島さんのメソッド（主張されていること）には、一般化してしまおうとすると、どうも変にひびいてしまっているところがいくつかあります。

たとえば、なるべくGUIの部分のプロトタイプを先につくりこんでしまおう、というのは、私もウォーターフォールで、後にならないとコーディングに着手できないという制約が課されているのを緩和するためによくやる手ですが、必ずしも、いつも有効な手段というわけではないですよね。ただお客さんの話を聞いていけばシステムがつくれそうにはなっていない場合、お客さん自身にも、自分たちの業務の勘所が整理できてなさそうな感じの場合、そういうときには、画面を固めようとするのは、かえって逆効果で、それよりも先にやらなければならないことがあります。一番いいのは、さっさととにかく動くプログラムをつくっていくようなことなのでしょうけれど、それが許されない場合には、何か手（モデリング手法的なこと）を考えなければなりません。いずれにせよ画面だけ全部、先につくるというのは、所詮、やむにやまれずやるような苦肉の策でしかないのではないでしょうか。

それから、今、普通にプログラムをつくるのならば、画面の裏側に、すぐSQLがあるという感じにはならないと思うのです。消費材の計算ロジックがあるとして、それをどこにどのように配置するのか、というのは、メリット、デメリットを考慮して、ケースバイケースで考えていくようなことになると思うのです。ぱっと考えてSQLで実装、そうでなくても、どのみちSQLで実装という話の流れは、なにか押さえるべきものを逃してしまってはいないでしょうか。

それに、業務とCOBOLプログラミングを知っている人（業務SEと呼ぶことにしましょう）と、JavaプログラマーがいっしょにJavaのプログラムをつくるとして、Javaプログラマーが業務SEから、ここはこういう風にプログラムをつくれだとか、こういう風なSQLを使えだとかというようなことを言って欲しいかといえば、そんなことはむしろ言って欲しくはないというのが本音ではないでしょうか。むしろ業務知識は、純粋に業務知識だけとして提供して欲しいし、その方が、全然違う言語やパラダイムで考えている人間にとっては、業務を理解して、適正なプログラムを組んでいくための手助けになるのです。私の経験では、どうも業務知識を業務知識として自分の言葉で説明することができる方が少ないなぁ、というのがむしろ困るところなのです。ですから、どうかSQLなんか勉強しないでください、勉強してくださってもいいのですけれど、仕様をつめる話の中にはSQLを持ち出さないでください、という主張も、こちらのサイドからはできるような気がするのです。

まとめますと、私の眼に、生島さんの議論がどのように映っているかといいますと、話の出発点が、「現在、ソフトウェアの開発現場が抱えている何か構造的な問題がある」ということ。結論が、「だから、アラフォーのCOBOLERにはSQLの達人になることが重要だ」ということなのですが、なんだかあまりにも間の議論のステップが飛びすぎている感じだし、ひっぱり出される例題と、その扱い方も突飛な感じがするし、全体として、ちょっとついていけない感じがする。なんだか、すごく貴重なエッセンスも含まれている話であるようなてざわりも一方ではしているのに、惜しいことになっているなぁ。そのようなものが、こちら側の眼に映ったことだったのです。

ソフトウェアの開発現場が抱えている構造的な問題に四苦八苦しているのは、誰しも同じだと思うです。だからこそ、多くの人にひびくように、良く出来たプログラムのような丁寧すぎるぐらい丁寧な議論を、せめて、現実の現場を離れた、こういう議論の時ぐらいは、技術者らしく、積み重ねていくことはできないだろうか、というような気がしております。

yukiarai さん、こんばんは。

ご意見、ありがとうございます。

> Javaプログラマーが業務SEから、ここはこういう風にプログラムをつくれ
> だとか、こういう風なSQLを使えだとかというようなことを言って欲しい
> かといえば、そんなことはむしろ言って欲しくはないというのが本音では
> ないでしょうか。

JavaのSEはJavaだけ、言語（Java）とUIについての業務知識があれば良い。
SQLのSEはSQLだけ、DB（SQL）と内部についての業務知識があれば良い。

もちろん、お互いにインターフェースになる知識は必要ですけれど、画面の配置など業務SEが指示しても、全くセンスないことの方が多いし、SQLをJavaのSEが書く必要はないと考えています。

現在の開発現場で、JavaもSQLの両方がそこそこ出来ないと使えない。というのは大きな問題の一つだと考えています。

ですから、打ち合わせは両方の人が参加するのですけれど、SQLのSEは、「画面遷移の基準になったデータがDBに永続化されるべきなのかどうなのか？」といった視線で、JavaのSEと顧客の間でヒアリングをするべきだし、JavaのSEは、顧客の要望を満たせ、かつ、自分達のプログラムが楽になるように永続化したいデータをSQL側のSEに伝える。ということをするわけです。

UI専門の高い業務知識を持つ技術者と、内部（SQL）専門の高い業務知識を持つ技術者がいて、お互いにコラボレーションしながら高めあっていける環境を私は夢見ています。

上流／下流ではなく外部（UI）／内部の分け方で、それぞれに外部上流などではなく、外部上級・下級、内部上級・下級というイメージかな。

過渡的には無理な部分もあると思うけれど、SE・PGって分け方もなくて良いし、アラフォ以上がもう一度コードを書くようになれば良いと思っているのです。

もちろん、万能薬とは思っていません。
違和感は当然あるでしょう。

しかし、例題でも、デスマの中で頼まれたら私は2時間でテストまで終わらせますし、普通に見積もったら半人日です。

他では、2～5人日となるわけですけど、2人日と言う人はそこそこSQLもJavaもできる優秀な人でしょう。
それぞれ、単に手が遅いのではなく、全く違うものをイメージして話しているのです。

私は見積を聞いたら、「その工数ならこのパターンをイメージしてしゃべっているな」と分かりますけれど、2人日とイメージした人に、半人日という私の方針はイメージできないでしょう。

ところが、2人日のイメージで話している人は、ものすごく「できる人」なのです。
その「できる人」に、2人日のイメージで反論されると私は勝てないので反則技を一杯使います。

といっても、私が優秀すぎるのではないのです。
ただ、滅茶苦茶変わっているだけです（笑）

おそらく、ここでコメントしているレベルの人なら、SQLなんて本気でやったら私を追い抜くぐらいすぐでしょう。
できるようになった人が、同じことを言うかもしれないし、違うことを言うかもしれない。

しかし、少なくともできないうちは、違う景色を見て話しています。

まずは、同じ景色を見てもらわないと基準が違う議論でしかないのです。

少なくとも、工数も、パフォーマンスもドラスティックに変わります。
変わる部分をドラスティックに変えてから、合わないものは個別に考えたらいいじゃないですか。

2割の差なら合わない部分の検討は慎重に行うべきですが、工数もパフォーマンスも数倍以上の差が出るのですから、今の見積が通っているなら、合わない部分を個別対応したって、十分おつりがきます。

現在に問題があって、一部でも改善する可能性があるならやれば良い。
数倍以上の差が相殺されるほどのデメリットって、技術者の反発以外にないはずです。

それは技術者同士なら許されるかもしれませんが、対顧客、対経営者では許されない差だと私は考えています。

顧客や経営者が気づいたらの話ですけどね。

う～ん。なかなか話がかみあわないところがありますね。でも、いったんは、この辺で、この議論には区切りをつけた方がいいと思います。これを私の方での最後のポストにします。先の私の投稿など、おそらく私より年長で、経営者にまでなられている方への言葉づかいとしてはどうだったかなと、少し気にかかっていました。もし失礼になってしまっていた段があればおわび申し上げます。

さて、最後に言っておきたいことなのですけれど、やはり、生島さんの議論というのは、限られた前提を元に組みあがっているところがあるように思います。その前提というのは、例えば、
(1) とにかく、早く動くプログラムをあげることに意味がある。半日と２日の差は大きい。
(2) Javarerが画面、CobolerがDB処理を分担して、１つのシステムが組みあがるはずだ。
(3) いわゆるCobolerの考え方を素直に使っていけば、いいSQLが書ける。
というようなことです。こういう話の前提は、いずれもおそらく、ある場合には正しいし、ある場合には正しくないようなことだと思うのです。では、どういう場合に正しいのか、というところを詰めていくことが、大事なのではないでしょうか。

特に、(3)のところがまた別の機会に発展的な議論につながるかも知れないと思うので、ちょっとだけここで言及しておきたいのですが、いわゆるCobolerで、Cobolを書かなくなってからSQLやストアドを書くのに一生懸命になられた方というのは、たくさんいらっしゃると思うのです。それで、そういう方々がいい仕事をされていたかというと、どうもそうではないような気が私はします。私はCobol出身の方が書かれた遅くてスパゲッティなSQLやストアドを書き直すという仕事をたくさんしてきました。でも、生島さんの書かれるSQLは、これは、ちょっと違うなと思いました。SQL Hackとしてはすごくきれいな形になっていると思います。普通のCobol出身の方が書いてしまいそうになるSQLと、生島さんの書かれるSQLはどこが違うのか、というようなところが、ひとつ掘り下げるべきテーマになっているのではないでしょうか。

ただ、いずれにしても、Cobol出身の方が一生懸命書かれたSQLを、私のようなのが一生懸命直したり、DBをチューニングしたり、という時代ではなくなっているようにも思うのです。時代の流れとしては、SQLが担当するような部分の処理というのは、なるべく単純化して、抽象化された形にして、システムをつくっていくというのがトレンドになってきているでしょう。（つまり、O/Rマッピングのような手法にしていくということです。）私もSQL Hackのような世界からは、長らく遠ざかっています。

生島さんの消費税のSQLは、SQL Hackとしては見事なものですが、これを本当にシステムの中で使うべきかというと、一般的には多分そうではないと思うのです。おそらくSQLやDBの定石的には、データの入れ替えの激しい明細テーブルのようなものに対して、Sum ... Over(...) のような構文は使わない方が良いのではないでしょうか。（この点、それほど自信があって申し上げているわけではありません。）あのSQLを高速に実行するために、色々とDBをチューニングしなければならないとしたら、それと、DBにデータが増えてくると突如、いままで快調だったSQLが遅くなるということがあるので、そこまで考えて検証していくとするならば、かえって工数的には大きくなるようなこともあるのではないかと思います。そうであるならば、むしろ単純に明細テーブルからデータを取得した後に、コードロジックで集計するようなことにしてしまっていた方が良いのかもしれません。テストやチューニングに関しては、SQLよりもコードロジックの方が楽なのです。２日でコードロジックと、それをテストするプログラムをつくった人と、一発で処理が完了するSQLを２時間で仕上げた人と、どちらがよい仕事をしたのか、というのは、本当にケースバイケースだと思うのです。

だから、結局、技術者にできることというのは、自分がどういう考えで、どういう根拠で、そういうことをしたのかというようなことを、きちんと整理しておくようにして、少なくとも、自分自身では、後から検証できるようにする、というようなところではないか、という気が私はしております。

yukiarai さん、ども。

> Cobol出身の方が書かれた遅くてスパゲッティなSQLやストアドを書き直す
> という仕事をたくさんしてきました。

想像はつきますけれど、例えば、スパゲッティになっているものというのは話にならないし、COBOLerが書いたストアドというのはfetchしまくりでしょう。
そんなばっちいモノは最初から対象にしていません。

SQL側を担当する人は、COBOLerだろうとなかろうと、私ぐらいは書けてもらわないと困る。

合格ラインは、例題を聞いた瞬間にSQLでできると判断できること。
それを実際に採用するしないは、別問題で、まず、「SQLでする」ということまで選択肢に加えられるようになる必要があるでしょう。

ハードル上げているつもりじゃなくって、私ができることは誰でもできるから「がんばりましょう！」ってことです。

もちろん、オブジェクト指向派の人ができるようになっても何の問題もありません。

そういう人が5人いて、それなりのポジションを与えれば大概のシステムはとんでもない利益を出して終わるでしょう。

もっとも、もし、私が5人いたら……、核弾頭同士の派手なケンカになるから、まぁ、終わらんでしょうけれど（苦笑）

> Sum ... Over(...) のような構文は使わない方が良いのではないでしょうか。

これは、問題を作ったときに考慮不足で、答えを書いてみたら（脳内チューンですけど）3分割しないと無駄なアクセスパスを通るなと……。
もっとも、メモリー上に展開した後に Over(… Orede By …)の回数ソートが入るので、それが、DBサーバのメモリー容量から、可能な処理かどうかを個別に判断すればよいです。APサーバでやっても同じソートが必要になりますから、相当に重い処理になりますね。

これを分散すべきかは、技術者としての判断が必要です。

半人日掛けるというのは、要件から最高でも1ヶ月単位（締日でもさらに絞り込むかな）の処理になるけれど、3ヶ月分ぐらいを対象にした負荷テストをして、ディスクソートの発生状況などを調査して、どこまで負荷を掛けれるか検討する必要があるからです。

それでも、本当に誰もメンテできないから、現状で現場では余程のことがない限り使うことはないです。
これは悲しいけれど経営者の判断ですね。

おやおや

>> 中途半端にSQLが使えるようになった元COBOLerとか怖くないのかな？
>
>そこまで、COBOLerを嫌わなくても…。
>「SQLですべてしろ！」って思っています。
>それはアルゴリズムを取り上げることですから、中途半端はないと思いますけどね。
>オブジェクト指向はいくらでも中途半端にできますから困るのです。

といいつつ

>SQL側を担当する人は、COBOLerだろうとなかろうと、私ぐらいは書けてもらわないと困る。

これは無いじゃないｗ

それが出来ればCOBOLerって揶揄されずにきっと尊敬されてますって

あと気になったのは
「いくらでも中途半端にできる」のはオブジェクト指向では、よりも
その言語が持つ柔軟性で「スクリプト的・COBOL的作り方も許す」事に対し、
安易にその作り方で作る事のほうが大きいのではないか？

その「安易」に逃げるからこそ、「オブジェクト指向で駄目でもSQLなら」
という意見には賛成できない（安易に中途半端で作ると思う）わけで

yukiarai氏の言う
「悪いCOBOLerと生島さんのSQLの違い」は、その「安易に」という、
・裏ではDBサーバーはこう動くはずだからこのようにする方が良い
・データ件数が実際に想定しうる～では云々
・もっと良い方法とかは無いか？
などにまで考えが及び、裏付けが有るか、ある種の美意識があるか、辺りだろう

また、保守性との兼ね合いからか、ビジネスルールの記述を正規化のように一箇所にという考えからも何でもSQL側で出来ることはやってしまうのは必ずしも最善ではありません。
今回の例題では見事にビジネスルールが埋め込みになってしまいます。
このルールが他の箇所でも沢山あって、そのルール変更の時は全部洗い出して書き直しですか？
その辺がアプリサーバでのかみ合わない議論と同じ構造なんだと思います。
勿論、例題・力を計測する為だから、今回のは・・・というのはわかります。

小規模・保守の要らないようなシステムなら効率は大変良いのですがね。
複雑・大規模であると、バグが少なくなる工夫も重要なのであって
同一ビジネスルール記述が分散する事による厄介なバグは、
幾らかの性能を犠牲にしてでも避けたい物だと思います

金融出身だから、COBOLerって悪い言葉という印象はないです。
金融システム部では、COBOLerじゃない私はバッタもので、COBOLerはできる人の意味だった……。

>>SQL側を担当する人は、COBOLerだろうとなかろうと、私ぐらいは書けてもらわないと困る。
>
> これは無いじゃないｗ
>
> それが出来ればCOBOLerって揶揄されずにきっと尊敬されてますって

そんなこともないですよ。
うちの19歳のPGなんて3日私と徹夜しただけでできるようになりましたよ。
（業務知識はどうにもできないのですけれど）
やったらできますって。

SQLなんて1週間あれば私ぐらいはできるようになると思うけれど、それはもうコツとやる気だけの問題と思う。

おかしいなあ

19歳の新人でも（若く、まっさらだからこそ吸収力は大きくもある）
3日で出来る（という位だと取り合えず文法レベルで組めるといえる位では）

これ、「私ぐらいは書けてもらわないと困る。」と矛盾するでしょ

流石に新人3日で覚えるレベルも出来ない人間いないと思うよ
それで、業務で使えるか？使うかの意味でどうしようもない
まあ、でも1週間で貴方のレベルまでいける人間は稀だと思う
特にどう検証してテストが～から裏でどう動くからとか環境に近い所まで
文法的に正しいだけ、結果が正しいだけではまだ不十分だから。

迷惑かけてるのはその、やる気すらないか、自分の知っているやり方に固執しすぎる性質そのもののほうに大きな問題があると思っている

まぁ、うちのボクちゃんの場合は家で自分でやってたんでしょうけど。
OLAP関数まで1日で着いてきたのにはびっくりしました。

> 文法的に正しいだけ、結果が正しいだけではまだ不十分だから。
>
> 迷惑かけてるのはその、やる気すらないか、自分の知っているやり方に
> 固執しすぎる性質そのもののほうに大きな問題があると思っている

もちろんそうですけど、文法から教えるから問題が起きるのであって、裏の仕組みはCOBOLerは分かっていると思うのですけどね。
DBEngineはISAMファイルをC++で作ったプログラムが操作しているのと変わらない。
C++がCOBOLになったって同じことでしょう。

COBOLerは、ISAMファイルにどうアクセスすればいいかは、本当に直感的に分かっています。

その直感をSQL文にできないだけなんです。
業務も十分に分かっているので、SQLの内部的な処理も直感的に分かっているのですから、本当に翻訳能力をつけるだけでできるようになります。
（抵抗感を乗り越えるのは大変ですけどね）

COBOLerがインデックスを平気で外してくるということは、彼らのアイデンティティとしてあり得ないのに外してくるのは、
　　　　結果 → 処理 → SQL
になってなくって、
　　　　結果 → 文法 → SQL
という感覚で書いているからだけの話です。

彼らが変わったら、本当に業界が変わると思ってるのですけどね。