株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。

COBOLerを最前線の現役戦士に!

»

 わたしはアラフォーで、この業界のデビューが遅かったため、COBOLの経験はありませんが、気持ちはCOBOLerです。

 年々、同世代の現役戦士がいなくなっていくことをさびしく思っています。

 わたしにとって、現状に問題を感じ、変わっていきたいと思っているCOBOLerは同志ですが、現状を維持したい、既得権を守りたいと思っているCOBOLerは敵ですから、徹底的に対決します。

 わたしは歳を取っても現役でいたい。

 「現役でいたい」と考えている(いた)COBOLerも多くいるのでしょう。ですから、現状ではわたしの敵は多いけれど、彼らの本心はそうじゃないと思っています。

 しかし、望んだこととは思わないのですが、COBOL時代から「上流/下流に分ける」「設計をする上流が偉い」「実装なんか安いところに出せばいい、海外に出せばいい」という単純な戦略と子供じみたヒエラルキーを作って、それを既得権として守ろうとしてきたから、全体的に長い目で見れば、結果的に自分達の首を締めることになっている。

 つまり、歳をとっても現役でいるというキャリアパスを、自分達の手で極めて細くして、さらに技術を流出させ、空洞化させてしまうという大問題を引き起こしてしまった。

 しかし、アラフォー以上のCOBOLerは、プロジェクトを、会社を、業界を変える能力をすでに持っているのです。

 逆に、結果的にデスマーチに追い込んでしまっているのも、残念ながら現状ではアラフォー以上のCOBOLerだったりします(もちろん、全員ではないけれど)。

 わたしは、これを本当にもったいないと思っていますし、最終的に何とかしたいと思っています。

 例えば、消費税の誤差配賦(はいふ:割り当てること)について、もう一度考えてみましょう。

情シス 「経理システムに連動することになったけど、向こうのシステムは明細単位に消費税が必要だから誤差配賦して欲しい」

SE 「じゃあ、明細の小計が大きい順に1円ずつ配賦する形でよいですか?」

情シス 「それでいいよ。いつできる? 見積もりよろしく!」

 情シスは丸めの単位がどのように保存されているかは知ったことではない(知ってるかもしれないけれど)ですし、「消費税は顧客に合わせて計算して請求している」ことは情シスと担当SEにとって共通認識ですから、多分、省略されます。これぐらいの会話で打ち合わせが終わってしまいます。

 さらに、SEは話しながら難易度を測っていますから、難しいと感じる人は、「『消費税調整』という商品名の明細を1行作ってもいいですか?」と、余計にややこしくなることを言い出したりしますね(他に影響するからフラグでコントロール。結局、そのフラグを漏らすバグを作る)。

 「明細を足す」の是非は置いておいて、とにかく、このぐらいの会話ができる人は、瞬間的に顧客の要望と業務を理解して、自分なりのやり方で難易度まで測っているわけです。

 SQL文というものは、8割は業務知識から作るもので、瞬間的に顧客の要望と業務を理解できるアラフォー以上のCOBOLerのためにある言語と言っても過言ではないのです。

 アラフォー以上のCOBOLerが持っている業務知識の量はものすごいです。その能力を十分に使って、下の世代に歳を取っても現役でできるということを見せてやることで、業界が変わってくるのではないでしょうか。

 我々世代は、もっとできるのです。

 手前味噌ですけれど、エクセルを使ってSQLを習得しましょう。もともと、顧客の要望や業務を瞬間的に理解できるCOBOLerは、実はイメージを持っているのですから、コツをつかんで1週間も練習すれば、ほとんどの機能をSQLでできるようになるはずです。

 業務理解が十分でない人にSQLを教えるのは間違ったイメージを与えかねないので、わたしはあまりお勧めできない。

 そう考えると、SQLが理解しやすい人は

  • COBOLer
  • 上流SE
  • テスト技術者
  • ユーザーの情報システム部

など、とにかく、業務に近い人ほど向いています。もちろん、いわゆる下流にも業務が詳しい人はいて、そんな人には向いているし、下流で業務が詳しければ、すでにできているような気がします。

 「できるわけない」と自分を過小評価する必要もないし、コーディングを下流と見なして、「いまさら、言語なんて」と低く見ることもおかしいですよ。

 そういう従来のこだわりを捨てて、業務経験が豊富なCOBOLerが、会話のペースで実装をイメージできるようになれば、もう一度、最前線で現役最強の戦士になれるのです!

 もちろん、全員がなる必要はないけれど、それを実践することで業界として多様なキャリアパスがあることを証明できるでしょう。

 ぶっちゃけていうと、アラフォー以上のCOBOLerが能力に見合わない権力を持ちすぎで、「いまさら言語なんて、実装なんて」と考えて足を引っ張っているのです。そんなふうに業界の老害として存在することと、いま、ほんの少し変わることで最前線の最強の戦士になるのと、どちらがいいでしょう?

 いま、ほんの少しの努力でSQLを覚えれば、あなたは自分で実装した方が、あなた自身の負担も、プロジェクトの負担も軽くなることが分かります(多くの人は直感的に信じられないかもしれませんが、本当に変わります)。

 あなたが変わればプロジェクトのあり方を根底から変えることになる。そしてそれができれば、あなたの会社だけではなく業界を変えれるかもしれません。

 皆さんがSQLを覚えることは、ほんのちょっとしたきっかけに過ぎませんが、業界を変える第一歩につながる可能性があるわけです。

 前の記事の問題(消費税の誤差配賦)は、現状で半日の見積もりを出すところはほとんどないでしょう。その差はオフショアで得られる利益と比べてどうでしょう。同等か、むしろオフショアより安いかもしれません。

 この不況を乗り越えるためにも、業界をよくするためにも「Change!」です。

 我々世代は、もっともっとできるのです。

 Yes we can!

 「エクセルを使ってSQLを会話のスピードで」の出張セミナーもやりますよ。

 ぜひ、お問い合わせください。

 info@g1sys.co.jp

Comment(19)

コメント

インドリ

若輩者の私から見て、アラフォー以上の現役戦士は非常に魅力的です。
是非本気になって、我々若輩者に真の技術者というものを見せて欲しいです。

ちゃんと、定年まで技術者という人が一定数居る業界になったらと考えています。
もちろん、途中でマネージメントに行っても良いけど、そういうキャリアパスが見えないから、若い連中が最短で上流に行こうとするわけですからね。

上から正していかないとね。

SQLはどちらでも良いのですけれど、今の業界を見れば、「COBOLerはJAVAをすべき!」って言っても現実にあってない。

COBOLerはそれなりのマネージャクラスになっていてプロジェクトの人件費も計算しているわけで、いろんな意味で効果は絶対に出るのですけどね。

saki1208

saki1208です。

私が今居る職場では、いろんな仕事がまわってきます。
もちろん、プログラミングである場合も多い訳ですが
それだけではなく、上から下までいろんな工程です。
(構築時の作業だけでなく、名前も聞いたことのない
お客様のシステム障害のトラブルシュートなんかもあ
りますよ。)
自分自身の担当しているお客様では、要件定義もあり
ますし、手があいてればプログラムも作ります。
そんな合間に障害の切り分け(H/Sも含めて)をやったり
もする訳です。
(さすがにマネージャーはないですけど)

私的には、システムの構築に関わるポジショニングは
単なる役割分担であり、その時の適材適所でポジショ
ンは変化するものであると思っています。

saki1208 さん

一括で請けている中小企業や、フリーランサーなら何でもやらないといけませんから、一通りのことができるようになりますよね。

オフショアが当たり前になっていますから、大手の方がつぶしが効かずに危険なんじゃないかと思う。
上流がえらいって考え方がなくなればいいのですけれど、弊社の場合は、さすがに私がコーディングしている現状はよくないのですけど・・・・・・

インドリ

生島さん

>上流がえらいって考え方がなくなればいいのですけれど、弊社の場合は、さすがに私がコーディングしている現状はよくないのですけど・・・・・・

逆にそれがいいと思います。
自分が知らないものを売るという行為は詐欺としか思えません。
その点生島さんはちゃんと知っていて売るわけですから、商売人として当然の事をしているのだと思います。

saki1208さんの職場環境は理想的ですね。
それをマネージャや社長に広げるのが本来の開発だと思います。
私の場合5・6社勤めた事ありますけど、全てブラック会社でまともな扱いをされませんでした。
なので、その様な仕事を求めてフリーになったのです。
それにも関わらず現状の「知らない人が指揮をする」方が異常であり、本来は社長がちゃんと品質を判定できて、社長も経費や将来の展望を考えて当たり前だと思います。
どうやって知らないものをマネージメントしたり、それでまともな商売ができるのでしょうか?
もしそれが可能ならばエンドユーザーがすればいいことであり自己否定に他なりません。
同じ無知ならば業務に詳しい方がいいはずですし、IT会社を名乗るだけで無知でも作れるという理屈は非理論的過ぎます。

oumi

>結果的にデスマーチに追い込んでしまっているのも、残念ながら現状ではアラフォー以上のCOBOLerだったりします(もちろん、全員ではないけれど)。
もともともCOBOLerですらない人が、システム開発の経験もマネージメントの経験もない人が、なおかつ責任者不所在(もしくは役目を果たさない責任者)という体制のせいで、デスマーチになるのでは?
アーキテクチャの選択ミスでデスマーチになった、的な報道などもありますが、これも原因は、責任者不所在という事が原因であることがほとんどではないでしょうか。つまり、アーキテクチャや言語には全く罪は無い・・・ましてやCOBOLerのせいではない。

>ぶっちゃけていうと、アラフォー以上のCOBOLerが能力に見合わない権力を持ちす
>ぎで、「いまさら言語なんて、実装なんて」と考えて足を引っ張っているのです。
そんな現実は無いでしょう?本当にありますか?能力に見合わない権限を持つことは、会社の体制上頻繁にあり得ますが、だからといって、COBOLerがということはないでしょう?
なんとなく、COBOLerっていう単語をキャッチィに使っているだけですよね?

COBOLerとSQLって関係ないのではないでしょうか?
SQL自体を理解したほうが良いってのはわかりますが、それでデスマーチが軽減されるとか、少し違うのではないかな。COBOLerとSQLの結びつきは疎に感じています。もっと言うと、設計者のセンス(スキル)の問題であって、SQLを知っているかどうかではないと思う。設計やテストは楽になる面が多いかな。品質もあがるね。

>しかし、望んだこととは思わないのですが、COBOL時代から「上流/下流に分け
>る」「設計をする上流が偉い」「実装なんか安いところに出せばいい、海外に出せ
>ばいい」という単純な戦略と子供じみたヒエラルキーを作って、それを既得権とし
>て守ろうとしてきたから、全体的に長い目で見れば、結果的に自分達の首を締める
>ことになっている。

「上流/下流に分ける」:これはフリーフォール型開発での設計フェーズと実装フェーズという違いでしかありませんね。この切れ目は明確である場合もあれば、必然的に連続したベクトルである場合もあります。
盲目的に、例えばWBSのなんたるかもしらずに、線を引いて開発するという事が問題であって、COBOLer云々は関係ないですね。
そもそも、当該時代にやみくもに業界に入り、これといった教育も受けず、方向性の指導も受けず育った人達、を総称するために、そしてまた技術者だけではなく、「ダメな人達を括って言うために」、当時もっとも全盛だったCOBOLという言語と合わせて、COBOLer という造語を使う・・・この造語を積極的に使う連中の品性のなさを疑っちゃいますね。

そもそも、何かを変えたいという場合に、人を物を貶めて別の何かを持ち上げようとするのは非常によろしくない、最も下作。どうするとどうよくなるって事をいかにして伝えるかに気を配ればよろしい。

「設計をする上流が偉い」:これは何かそういったネガティブな経験からの話なのかなと?このようなプロジェクトは体験した事がありませんね。もっとも、会話の上で「設計に従ってくれないとこまるじゃないか」的な場面はあるでしょうけど。上流が偉いなんていうSIerも人も、今どき淘汰されているような気がしますけど・・・そうでもない?

「実装なんか安いところに出せばいい、海外に出せばいい」:なんてSIerは存在していないのではないでしょうか?すくなくとも大手といわれるSIerにはいないと思われます。必要なお金は出すしか無い!ってとこが多いと思いますけどねぇ・・

saki1208さんのような職場は理想的というより、普通なのではないかと思うのですが・・・ですので、逆に、生島さんやインドリさんの話される雰囲気が、歪んで見えてしまうというか、「そんな本みたいな世界本当にあるのか!」というか・・・
盛り上げるために作為的に?いやそれはないよなさすがに・・・とか・・・
事実私も、マネージメント、R&D,R&C,アーキテクチャ検討・研究、プログラミング、デバッグ、バグ調査、マシンセットアップ、セミナーなど、必要に応じて全部やります。
やっぱり自分のかかわる世界が狭いだけなのかなぁとか思うこともあります。
なんだか、作り手が非常に虐待されてるようなイメージに感じるんですね・・・
世の中本当にそんなにひどいのだろうか・・・

全般的に、何か煽りたいのだろうとは思いますが、COBOLerという単語を出す時点で、そのCOBOLerからそっぽ向かれちゃいますね。
「SQLを会話のスピードで」は、現状、技術者の素養として当然あってしかるべきものと思います。
せっかくの良いネタなのに、やたらと抽象的な何かに挑戦的で良いネタが見てもらえなくなるのは残念。

(私も今回で最後にしときます)

oumi さん、ども。

SIerにおいて、40歳を超えてCOBOLerでない人は現実的に非常に稀です。
キャッチーに使って気を悪くされたのなら申し訳ない。
私もCOBOLは使ったことはないけれど、COBOLerなのです。

>>結果的にデスマーチに追い込んでしまっているのも、残念ながら現状では
>アラフォー以上のCOBOLerだったりします(もちろん、全員ではないけれど)。
>もともともCOBOLerですらない人が、システム開発の経験もマネージメントの
>経験もない人が、なおかつ責任者不所在(もしくは役目を果たさない責任者)と
>いう体制のせいで、デスマーチになるのでは?
>アーキテクチャの選択ミスでデスマーチになった、的な報道などもありますが、
>これも原因は、責任者不所在という事が原因であることがほとんどではないで
>しょうか。つまり、アーキテクチャや言語には全く罪は無い・・・ましてや
>COBOLerのせいではない。

言語に問題があるとは言ってませんし、おっしゃるような問題を分かっているなら、そういう現場があるということも分かってらっしゃるのではないですか?

理想道理に行くなら、デスマなどという言葉は一般に通用するわけがないですし、この業界が3Kだのいわれることもないはずです。

>(私も今回で最後にしときます)

そう言わず、またいらしてください。

saki1208

saki1208です。

oumiさん>
普通ですか...

私のいる職場でそれができるメンツはごく限られているのですが、
やっぱり異常なんですかねぇ。

どこかの工程を専業的にできる人、もしくはどの工程もダメなひ
とが多すぎて、結局何でもできる人に仕事が集中します。

インドリ

>逆に、生島さんやインドリさんの話される雰囲気が、歪んで見えてしまうというか、「そんな本みたいな世界本当にあるのか!」というか・・・

そんなこと言われても、私の人生において逃げられない現実なのですから他に言いようがありません。
それにしても、oumiさんが言うような職場環境ってあるんですね:・・
私には望む事の出来ない天国です。
もし仮にoumiさんが言う方が一般的ならば、この業界の離職率の高さも説明できませんし、3Kと呼ばれる事もないはずです。

oumi

最後の最後?(ぇ

おそらく、みなさん、非常にまじめに取り組んでいらっしゃる。
どうあるべきだ、これは知っているべきだ、技術者としての心構えはこうだ、とかかなりまじめなのだと思います。私は、いい加減なので、そんなものは持ち合わせていません。

私は、「かれらは、悪くない、かれらは、そこで生きようとしているだけだ」と基本的に思っています。技術者がどうあるべきかは自分なりに矜持としてはありますが、人は別物だと思っています。そのひとなりの、価値観とルールのなかで生きているだけなのだと思います。

当然「ここまでやってくれよー」と思うことも多々ありますが、それは自分の価値観の押し付けでしかないと思います。ですので何か、ズルイ方法を考えるしかありません。

SQLを高度に知ってほしい。生産性も上がる!品質も上がる!性能も!工数はヘル!確かにそうですが、知れ!では何も通じなく、うまくどうやると高度に知ってもらえるかを考えるしかないかなと。

そういった意味で、EXCELから~っていうのは非常に良かった。
彼らの事を引き合いに出さずに、進めていけたらよかったのにと思う。

デスマ:別にデスマなプロジェクトが無いっていってるわけではなくて、デスマしか無いみたいな?誤解を与えるのが良くないとおもっているだけです。なにかにつけて、デスマ、デスマ!って連発すると、それがほとんど?みたいに思われますよね(^^;いやもうほんとにそうだとしたら、うーん、ナムです・・・

3K?こんなのは一時的にマスコミが騒いでるだけでどの業界も同じ。離職率しかり。別に、今の業界人口が半分になったとして全く問題ない。(と思っている)
最も、遣り甲斐・達成感 と仕事の大変さが見合わないってことはあるかもしれない。でもそれって人の方が軟弱になっただけなんでない?草創期の業界の人たちなんですごいですよ・・人の方が軟弱になったのならほっときましょうかね。
残ったやる気のある人だけでおいしい思いをする仕組みを作っていきましょう。とか思っちゃいます(^^;
そもそも、3Kとかいっちゃうマスコミ・・・、程度が知れる。
(まぁ人もそうだなぁ。)
3K云々じゃなくて、遣り甲斐があるか?とかどんな仕事なのか?とかリサーチしろよなって思う。まぁほっときましょう。つてがないとか、ネットで調べられないとか、企業の情報発信がとか言いだす人、程度が知れる、まぁどうでもいいや。

集中:これはどこの業界でも同じでしょう。人は、その人ができるからではなく、頼めばやってくれるから、自分の注文に応えてくれるから、というこれは生理(本能)ですね。それでもって集中してしまう。そして働きかけてる彼らは何らかの免罪符を取得する。周りが考えるか責任者が手当てするか、何かをしないとどうしようもないですね。この集中のせいでとんでもないことになることも多々ありますから・・・というか集中するとだいたいは問題になりますから・・

デスマ:やればやるだけドつぼにはまっていくプロジェクト。いや、そんなにないでしょー。そうだったら、もう大手SIerなんてとっくにつぶれてますって・・
最も、完全なるデスマになりかけたけど、なんとか回避できたっていうのはいっぱいありますね。そのーさまざまな手法で・・・これがダメか!?
いや、SIerも学んでいますよっ!ほんとにほんとですからっ!

この業界はまだ新興の業界で、他の業界のように何百年もの歴史があるわけではありません。ですので、余計にいろいろ問題もでるのでしょう。常識やセオリーもあるようでありません。だからと言って、「彼ら」を否定したりはしない。否定から入っては手を握り合う事ができない。できないから何をしろ、という言い方はマズイ。

デスマになりかけたり、稼働が300時間(@@)とかって社員もいますが、ちょっとまて!君、自分でその状況変だと思わないか?変だと思っているのに何もアクションとらないのか?
これが理解できない・・・しかし、解決できない理由を沢山言う事はプロだ・・
環境が、立場が、そのたもろもろが・・・周りか、上が手を差し伸べるしかない。
たぶん経験豊富な上司が定着していないという問題もあるのでしょう。
開発にとらわれずに、マネージメントのみをできる環境を整えてあげる必要もあるかな。システム開発もできてマネージメントもできて・・・ってスーパーSEを求めるとかどうかしてますよね。これも問題だ。

日本の場合、社会インフラを支える人の地位を高めるという学校教育が足りない気がします。今業界にいる人がもっと誇りを持つってのもありますか。

EUは神様じゃない!?ただの素人だ!と思いますから何でもできます(笑)
(何でもっていってもやさ~しく、機嫌を損ねないように、周りに迷惑かからないように工夫して)そしてダメなものはダメって言います。これは躾です。
できるEUは?褒める・・


まぁこんな、デスマだの3Kの話はどうでもよくて、
>とにかく、業務に近い人ほど向いています

これは超同感なので、こっちのほうを推進するうまい方法を考えたいものですね。
とある業務処理っていうのは、だいたいはパターン化できて、例えば金融系の元帳にかかわるバッチ処理なんていうのも、16パタン前後くらいにパタン化することができます。会計系も若干のブレはあるものの、大筋パターン化できます。決算しかり。
こいったパターンからSQLですと基本的なパターンはこうでっていうスタンダードを作れるとか、アルトオモイマス!(自分にはそんな頭はないですけど・・)
そのようなSQLパターンのデファクトスタンダード?があると、世の中かなり良くなる気がします。
そんなコミュニティがあってもいいと思うなぁ・・
では、みなさま、それぞれの立場と境遇でがんばりまっしょい m(_ _)m

oumi さん、ありがとうございます。

まぁ、イロイロとアクセス解析しても煽った方がアクセス集まりやすいのでね。

私の立場では、本当にユーザより……と思えるふんぞり返って、取り返しのつかないテーブル設計をして居なくなる人から、仕事にあぶれて困っているけど、自分からは変われない上の世代が居るのです。

「威張ってるけどアンタがデスマに」と「困っているなら変われよ!」と二つの思いがないまぜになっています。

現状で本当に困っている人が私にはダイヤに見えるのです。
弊社が求人を出しても(めちゃ安い)30、40人は来るという異常事態で、やはり即戦力の30前後に決まる確立が高い。

しかし、本当は「酸いも甘いも」の40代以降を取りたいのです。
同じ金額(以下も)で来てくれると言うのですから。
それでも、現状でJAVAなどを中心に考えると取れない。
SQL中心のプロジェクト運営でそれを受け入れてくれれば取れるし、次のプロジェクトでは昔の単価に戻せるのじゃないかな。

って後で記事にかこうかな。

金融系は…。
浅くはイロイロとやりましたが、深くやったのは外為でこれは16では足りなかったような……SQLは使わなくて苦労しました。

商社の外為もやったのですけど、こちらの方がある意味難しかった。
銀行は基本毎日決算やっているようなものですが、商社は決算で差損益を出すので期跨ぎしてキャンセルとかあると、もう滅茶苦茶に仕分けが大変なんですよ。

差損益の仕訳科目が十種前後あったっけ?もう忘れてしまった。
これはストアドでグルグルだったんですけど、SQLが浮かんでしまったら、それを潰してグルグルは精神的に堪えるのです。

としろう

COBOLerが、って言われるのは結局
・昔のCOBOLにしがみついたまま時が止まったかのようにそれしか見ない
という意味で揶揄してるのであって、かつてCOBOLを使っていた人でも
今でも使っている人でも、
今の開発の潮流を理解しており、新しい他の言語や開発手法も使える人間は
COBOLerと呼ばないと思います。
COBOLしか使えない人、他の言語などでもCOBOL流で作る人をCOBOLerと言う

個人的には生島さんの意見のSQLを理解しやすい人に
COBOLerは入らないと思います。
上記したように何でもCOBOL流、無駄にループでグルグル、行レベルで判定の悪弊がCOBOLerと呼ばせている原因だと考えているからです。
SQLで出来ることを考えず、取り合えず自分の理解できる取得してからの処理を書く。
周りの知らない所に出来るだけ踏み込まない変に保守的な所が悪いのですかね。

Excelの件でもそうだけど、COBOLerは逐次処理での考えには近いと思うので
サーバーサイドで行グルグルのストアドを覚えれば・・とは思いますがね。

SQLは集合概念である事が根本ですので、
そこのところの数学的センスの有る無しのほうが重要です。
やりたい事と手元に有るものから手法を逆算する上での論理力も必要です。
COBOLerと呼ばれる時点で他に適性が無いからCOBOLerであり続けているだけだと思います。
酷な言い方ですけど、結果論でよばれているだけかと。

としろうさん、はじめまして。

私も基本COBOLerだと思ってるので、あまり揶揄しているつもりはなかったのですけどね……。

> Excelの件でもそうだけど、COBOLerは逐次処理での考えには近いと思うので
> サーバーサイドで行グルグルのストアドを覚えれば・・とは思いますがね。

最悪、それでも良いので外部(UI)から始めてくれれば、というのもなかなか通らないのです。

Excelでは一目で見渡せるから、ほとんどの人が集合理論とか意識することなくできています。そのイメージを脳内に作れれば、後は翻訳方法を身につければ良い。

時が止まっている人に、絶対にオブジェクト指向言語の仕様書(要件定義も)は書いて欲しくないけど、SQLなら切り替える努力ができれば可能なはずです。

そうすれば、業務知識という眠れる財産をフルに活用できる。

野良猫

世間ではCOBOLの時代は思ったとの感覚があるようですが、実際にはそうでもないです。大手の企業ではまだまだCOBOL資産が多く現役で運用されています。

 自分もCOBOLerと言えばそうかも知れないのですが、自分は主に業務よりではなく基盤系を担当しているのでCOBOLよりもASMでのプログラムが多いです。

 しかし、生涯現役で居たいものです。

としろう

>生島さん
以前貴方の他の話題の所に書いたのですがw はじめまして

>Excelでは一目で見渡せるから、ほとんどの人が集合理論とか意識することなくできています。

そうでもないと思います
データがなまじ有るとデータに依存した解法で考え、
有り得るデータの組合せでのマズイケースの抜けが発生する可能性がある。
潜在バグみたいな厄介な爆弾を抱える可能性が有る。
ここで集合概念と数学センスが要求されると思っていますので。
そんな物関係ないという程単純な関係なら逆に誰でも出来るということです。

確かにオブジェクト指向のほうがハードル高く、SQLベースへの移行は楽でしょう
そして守備範囲が広がるのは良い事です。
しかし、根本の問題は自分の苦手とする部分について、他人に制限を付けてしまう事に尽きる。
駄目なら駄目で、その部分を人に委任する、又は双方の最適バランスを弱点を補うように補完するのが理想的。
生島さんだって本音で業務知識に価値の重きを置いてる事ばらしてるじゃないか

データストレージがSQLベースのDBならSQLの流儀に従うべきだし
昔のCOBOL向きのソレだとCOBOLが良いというだけでしかない。

野良猫 さん、こんにちは。

もちろん、COBOLがなくなったとは思ってないですよ。
弊社では関連するぐらいですけれど、Micro Focus COBOL の案件とかもありますし、ホスト連動で情報系だけということも多いですからね。

ただ、現役のCOBOL技術者数は昔の10分の1ぐらいになっているような気がします。
生涯現役という人の数は、本当に少なくなっていますからそこは正したいですね。

インドリ

それにしてもこの業界のお偉いさん方は何をしようとしているんだろう?
技術者なのに技術を学ばない人を優遇し、本物の技術者を無理やり現場から遠ざけ無力化する。
おまけに教育も考えずに、やれ技術者の数が足りない、やれ業界離れが進んでいるなどとのたまう。
私には何ちぐはぐな事言っているんだ!と思えてなりません。
能力が低下と比例して収入が高くなるようにすればこうなるのは当たり前です。
お偉いさん方は何を考えているんでしょうか・・・
生島さんはどう思われますか?

としろう さん、こんにちは。

前も頂いてたのですね。失礼しました。

私は業務(のみ)を専門とする人はちょっといただけません。
営業でも、ハードの選定(概要)とか、外したイメージで言ったことは覆せなくなりますから。

数学的なセンスは必要なのでしょうね。
ただ、COBOLも集合じゃないけど、それなりに数学的センスは必要です。

個人的にはそこに大きな差は感じないのです。

COBOLerが揶揄される原因は、「SQL+オブジェクト指向言語」ならCOBOLチックに処理できるから、これまでの経験が邪魔をするだけだと思います。

しかし、SQLだけなら、COBOLチックに処理しようありませんから、一つ階段を上ればクリアーできると私は考えています。
COBOLerに「SQL+VB」を与えてしまったのが、多分、最悪の組合せだったと思う。

「できないのか?」と言われればできますからね。

私は偉いさんじゃないので経営者の考えることは分からないのですけれど、はっきり言えることは経営層は金のことしか考えてないです。
うちの社長(私のことですけど)もそうです。

今は株主から短期の利回りで追い回されるし、中小企業の社長も命がけですから、悠長なことは、(大事と思っても)言ってられないのです。

ですから、私も社長(私のことですけど)と協議した結果、1プロジェクトで回収できる教育方法を確立する。という目標を最近作りました。
皆さんのおかげです。

ただ、SQLがバリバリできても、本当に最上流が潰してくるから……。
何万ステップをばっさりコメントアウトして書き直すとかはあるけど、私はSQLを使い切ったなってプロジェクトをまだやってないから(笑)

金があったら辣腕社長をヘッドハンティングして、私は開発部長か技術部長になって、プロジェクトをやりたいのですけどね。

二人の人格がいると精神がおかしくなる。

コメントを投稿する