5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

COBOLの現状について教えてください

1 :仕様書無しさん:2006/07/13(木) 17:12:24
知り合いが大手金融会社などのシステム保守を請け負っているとこに内定したらしいんです。
正直COBOLって、昔の言語って感じであまりイメージがよくなかったんですけど

「大手の銀行とか重要機関は全部COBOLだし、COBOLから変更の予定もない。
 若手にはCOBOLは不人気だからCOBOLの担い手が減ってきている。
 COBOLは一番安定してて、需要もあるから、むしろやるならCOBOLだ」

って言われた。
なるほどと思うと同時にホントかな?とも思います。

皆さん、実際のところはどうなんでしょうか?
COBOLは安定優良なんでしょうか?ご意見よろしくお願いします。

2 :なぎさっち ◆Nagi/FmYMM :2006/07/13(木) 17:24:08
>1
言語に依存しない技術を身につければ無問題。



判ったら削除依頼出しとけ。単独質問スレ立てんな。

3 :仕様書無しさん:2006/07/13(木) 22:07:22
手に職つければ…でもオープン系は三十五歳であぼーん。知ってる会社は採用条件コボルのみ。
コボルやってりゃ一生安泰。
でも、俺やりたくない。
だから、今でもフリーター。

4 :仕様書無しさん:2006/07/13(木) 22:22:53
コボルとは、終身雇用を約束する魔法の言語。
やってて良かったーーーー。
コボルでなかったら、家のローンを頭金ナシで35年も
組めないもんね。

5 :仕様書無しさん:2006/07/13(木) 22:26:14
やっときゃよかったかもな

6 :仕様書無しさん:2006/07/13(木) 22:35:59
COBOLなんかやるのは、この業界じゃえたひにんみたいな連中だろ。

7 :仕様書無しさん:2006/07/13(木) 22:54:26
官庁や病院の汎用機のシステムは、ほとんど壊滅したから、
残るは金融のみだね。
でも、でかい会社に雇われていているなら、まだ持つかも。
ただ、客のシステムがリース契約になっているようなら、
リース切れの際にさっくり切られる可能性は高い。

8 :仕様書無しさん:2006/07/14(金) 00:20:22
確かにCOBOLは少ない。
年寄りじゃなくて、若手のね。

若手だったらそこそこ需要あるかもね。

9 :仕様書無しさん:2006/07/14(金) 00:43:09
大企業の社内COBOLerはお役所仕事でおいしい。
毎日定時上がりで、年休100%消化で、35歳年収850万。
やーめられまへんなーーーー!

10 :仕様書無しさん:2006/07/14(金) 01:17:09
くさいいきを得意とする植物系の怪物?










…それはモルボルか

11 :仕様書無しさん:2006/07/14(金) 01:24:49
オチュー

12 :仕様書無しさん:2006/07/15(土) 03:02:13
>>1
銀行同士がくっつくとどうなるか
単純に考えるとシステム維持に必要な要員が2分の1になる
これがどういう事か解ればよろしい

勝ち側に居れば引退後も変な事されると困るから厚遇受けるが
負け側のシステム担当だと厳しいよな年とって様が否応無しに弾き飛ばされる

13 :仕様書無しさん:2006/07/16(日) 03:01:14
>>1
COBOLが安定優良なのは事実。認めたくない香具師もいるみたいだが。

COBOLerが安定優良かどうかは、事情による。勝ち組金融機関の
社員COBOLerなら安定優良かもしれんが、なまじ出来ると人事異動で
慣れないところに飛ばされて壊れるかもしれん。出来ない香具師が
いつまでもぬくぬくできるかはその金融機関次第。

金融機関の外注先だと、金融機関という太い客を捕まえている分、
下手な所よりは安定するが、いつ切られるかは分からない。

14 :仕様書無しさん:2006/07/19(水) 10:30:50
NET COBOLのありさまが現状です。

15 :仕様書無しさん:2006/07/21(金) 00:28:14
なあに、
金融機関勘定系パッケージ全盛の時代は、もうすぐやってくる。

パッケージに乗り換えたとたん、おまえらの大半はクビです。

16 :仕様書無しさん:2006/07/21(金) 02:41:49
20年以上も前からんなふうに言われてるわけだが。


17 :仕様書無しさん:2006/07/22(土) 16:57:52
20年前にあったパッケージは、都銀のシステムをそのまま買ってくるパッケージだけだった。

今は、FlexCubeを筆頭に、システム屋が主となって開発したパッケージがたくさんある。
新規参入銀行は例外なくパッケージを購入している。

18 :仕様書無しさん:2006/07/23(日) 04:56:12
それなら現状働く連中はクビにならず安泰だな。

19 :仕様書無しさん:2006/07/24(月) 21:43:48
地銀でFlexCubeに移行中のところがあるから、動き出せばそれを拡販だ。
FlexCubeの開発部隊は3500人もいるから、正直なところ、太刀打ちできない。

古い勘定系に守られて成長することをやめた連中は、確実にクビになる。

20 :仕様書無しさん:2006/07/29(土) 02:26:16
NetCOBOL(゚∀゚)

21 :仕様書無しさん:2006/08/05(土) 19:19:09
結論

現状安定優良、ただしその安定状態に胡坐かいてると痛い目を見る可能性もあるぞ
ってことでOKなのか?

22 :仕様書無しさん:2006/08/05(土) 19:43:13
安定優良って技術的に枯れているから、システムとして悪いものではないって意味でしょう?
コボラーとしてずっと食っていけるかっていうのとは完全に別問題。
ハードのコストが高いから、リース切れなどの機会に槍玉に挙げられることが多いし、
新規での案件はまず無いし、市場としては確実に縮小しているよ。

社内である程度のポジションにいるおっさんなら
管理職としてダラダラやっていける可能性があるからいいけど、
いまどき若くしてコボラーは危険。

23 :仕様書無しさん:2006/08/06(日) 03:28:34
新生銀行のDBはSQLサーバーらしい。

言語も新しいやつだったような気がする

24 :仕様書無しさん:2006/08/06(日) 18:38:00
負け組みのコボラーになりそだ。(・・・ぐすっ)
吸収合併でなくても、大企業の子会社・下請けはそんなもんだ。
子会社・下請けの分際で汎用機専門ってのは、生き残れないと思われ。





25 :仕様書無しさん:2006/08/06(日) 18:57:45
金融系いけば分かるけどCOBOLはかなり多いよ。
都銀や大手・準大手証券、大手の損保や生保などかなりある。
パッケージはパッケージ側に業務をあわせないとならないから、
結局はなんだかんだトータルコストが嵩むし、自由度も減る。
費用減らなきゃ何の意味も無いので一度試して懲りる所が多い。
あとPL/1→COBOLのリプレースもある。
ただ発注先はまず中国。
日本人でCOBOL覚えておいて間違いなく損は無い。
でも実装とかはほぼやる機会は無い。

26 :仕様書無しさん:2006/08/06(日) 19:32:03
SAPとかってCobolわかんないとわかんないって噂。
たしかにOPEN系業界ではSAPの話ってあまり聞かない。

27 :仕様書無しさん:2006/08/06(日) 19:36:45
某公共料金の計算システムでは、COBOLは現役だぞ。
料金改訂とか単価の変更がある度にCOBOLのソースに手を入れるから、
需要は極めて安定して存在する。


28 :仕様書無しさん:2006/08/06(日) 20:31:38
つーか、それ
単価の変更くらいでソースいじらないといけないっていうのもどうよ

29 :仕様書無しさん:2006/08/06(日) 22:18:31
>>28
それがCOBOL案件が無くならない理由だよ

30 :仕様書無しさん:2006/08/07(月) 20:55:56
なあに、COBOLの仕事が来てから覚えても大丈夫。
「COBOL出来るか?」と聞かれたら、「まかせてください。」と答えてから覚えればよい。

COBOLなんてものは、ずぶの素人でも3ヶ月で猫の手くらいなら使えるようになる言語だ。
ましてや、すでに別の言語での実績があれば、ちょっとだけ文法覚えればいいだけだよ。
新しい概念なんて、全く出てこないから。

31 :仕様書無しさん:2006/08/07(月) 22:31:13
まぁ>>30のいうことには一理あるな。簡単で単純な言語だ。
メインフレームが絡むとちょいだりーけど。
仕事は一応安定して供給されるよ。税制改正、法改正があれば立派な大規模プロジェクトだよ。
古いソースで中身がぐちゃぐちゃだからちょっとした改修でも手間がかかる。
新規案件も一応あるんじゃないかなぁ。バッチはCOBOL以外で作ったことないな。

32 :仕様書無しさん:2006/08/07(月) 23:06:41
COBOLって桁数をいちいち決めなきゃいけないので
桁数増えた場合の修正がめんどくさい

33 :仕様書無しさん:2006/08/07(月) 23:33:48
桁数をちゃんと決められるのが、金の計算では有利になると思う。

> 桁数増えた場合の修正がめんどくさい
仕事が増えていい感じじゃねぇか。
ホームレスになるよりかはマシ。

34 :仕様書無しさん:2006/08/08(火) 01:43:15
外資系金融機関もCOBOLなの?
それともCとか使ってたりするん?

35 :仕様書無しさん:2006/08/08(火) 02:31:47
日本ほどCOBOL一色じゃない。
勘定系に限れば、PL/Iもあるし、Modula-2もある。
ただ、勘定系といっても日本ほど多機能じゃなくごく単純なものだ。

外資系のシステムは、日本人が情報系と考えている分野にほとんどの開発リソースを投入しており、
日本はまさにその分野で遅れている。

第3次オンラインで育った団塊世代が一掃されないと、
勘定系にしか目が向かない現状を打破することは不可能である。

36 :仕様書無しさん:2006/08/08(火) 23:38:43
>>35
それは無理だろ、役所がいろいろな事を複雑に難しくする事で自分達の仕事を減らさない様にしてる国だからな
企業の仕組みが簡単になると色々都合が悪いみたいだよ

37 :仕様書無しさん:2006/08/10(木) 00:09:23
>>36
金融行政はアメリカの方が難解である。
日本の金融行政でも力を入れているのは、情報系システムで対応すべき分野だ。

勘定系にインプリメントしなきゃならない制度や法令上の制約は、
ほとんどパラメータで対応できている内容であり、
根本的な変化など、あまりありません。

38 :仕様書無しさん:2006/08/10(木) 03:20:30
ぶっちゃけ帳票にあんなに凝らなきゃ
日本は遅れなかったとは思う。
その分ヨソに力使ってればなぁ

39 :仕様書無しさん:2006/08/10(木) 22:22:10
>>38
この上なく激しく首がちぎれるくらい同意

40 :仕様書無しさん:2006/08/11(金) 01:01:18
>>38
その言葉、俺の上司どもに言ってやってくれ。

41 :仕様書無しさん:2006/08/15(火) 23:39:19
製造系で多くのシステム構築をし、その経験を認められ
現在某大手で金融のパッケージの作成の上流工程からの業務を行っているものです。
金融系を相手にしている某大手は
「新しいシステム」「勘定系からの脱皮」「Windowsへの展開」
好き勝手言ってます。
「やっぱ最新の技術はJAVAだろう。どんなハードウェアでも動くし!」
ってことでJAVA採用(JAVAってどういう言語だと思ってるんだろ。。。)
「でもJAVAってバッチ処理できるの?」
「ぃゃ、バッチ処理はCOBOLだろう?」
ってアホな意見でCOBOLも採用(汗

で、わたくしの書いた設計見て技術責任者が
「ねぇ!これってファイル2回開かない?! 負荷どうなるのよ?!」

ちなみに製造業で古い技術をいつまでも使う事や技術的知識が無いまま
プログラミング設計をすると「欠陥品」を作り「リコール」発生の原因となります。
製造業界では上記で書いたような「おかしい」発言をする技術者には
ビシッっと言うのが正しい対応です。

で、

ビシッ と言うと

次の日から「しったか」と言われだもれ相手に(略


これがCOBOL金融業界の全て(w

でもこの逆境に勝てた人はかなりおいしい思いできまっせ

42 :仕様書無しさん:2006/08/15(火) 23:44:35
>>41
同じ事を東大卒の新入りが言うと、「さすがだ」に評価が変わります。
つまり、あなたが悪いのではなく、あなたの学歴が悪いのです。
それが、金融業界です。

43 :仕様書無しさん:2006/08/16(水) 00:06:49
金融業界って、天然記念物がいっぱいいるね


44 :仕様書無しさん:2006/08/16(水) 07:25:17
それが金融業界というもの

45 :仕様書無しさん:2006/08/16(水) 20:36:18
金融業界といえば、何故かフロントエンドPHP+バックエンドJavaという
摩訶不思議なシステムがあちこちにあるとか。。。

46 :仕様書無しさん:2006/08/16(水) 23:25:37
>>45
それ金融じゃなくてカードとか証券の方の話じゃないの?
金融とは名ばかりのバッタ物

47 :41:2006/08/16(水) 23:35:14
>>42
なんだかどこも同じ思考回路なんですね(w
すごく納得してしまう意見です。

本題のCOBOLという言語について…

COBOLは汎用機で帳票出力したりするのには最適な言語だと思う。
「Windowsで動く帳票出力システムを2日で作ってね〜」とCOBOLERに言われて作ったが
「これ、汎用機+COBOLで作った帳票プログラムより性能わるいじゃん!」
とCOBOLERに激怒されました。で、COBOLで出力した帳票を見て思いました。
帳票出力に関してはCOBOL様には勝てません。

金融業界とそれ取り巻く技術者は「帳票」に対してすごい思い入れがあります。
帳票出力は「処理結果のプリント出力」というごく一部の機能ではありますが
COBOLERは「帳票出力以外の処理は何か良い(便利な)パッケージで処理させればいいじゃん」
という思考なので結局COBOLで帳票を出力する技術=技術力
という書式が金融業界では成り立ちます。

つまり金融業界でがんばるにはCOBOLスキル必須です。

48 :41:2006/08/16(水) 23:41:57
ただ、
「いくらなんでも帳票(COBOL)ばかりに執着しててもねぇ」って考えを
都市銀と第一地銀では持っているようです。
都市銀や第一地銀と中の良いIT系大手数社にはCOBOLからの脱皮案は何かないか
というやりとりがぽつぽつとあるようですが
IT系大手にはCOBOLERが大量にいるのでそう簡単には動けないようです。
(理想と現実ってやつですね。)
それでもって銀行側が出す案が
新しい技術っていえばJAVAっしょ!!!JAVAにしましょ!!(なぜか都市銀も地銀もそういうw)
なのでCOBOL+JAVAというスキルが今の金融には喜ばれますよ。

49 :仕様書無しさん:2006/08/16(水) 23:44:06
ペーパーレス

50 :仕様書無しさん:2006/08/18(金) 00:54:22
>>47
同じプログラムのパラメータ変えるだけで、
PDF, Excel, web, プリンタと出力先が切り替わるところ見せれば、
60%の汎用機野郎はぐうの音も出なくなる。

そんでもって残り30%は、その意味するところが理解できず、

残りの10%は、「そんなもの、オーバーレイ切替ただけだろ」と勝手解釈した上で逆ギレ。

51 :仕様書無しさん:2006/08/18(金) 07:46:27
帳票ツールの時点でソート順の切り替えが出来るって事が理解できない汎用機野郎はいるな
ソートはツール使わなきゃダメって思想らしい

52 :47:2006/08/18(金) 23:07:07
>残りの10%は、「そんなもの、オーバーレイ切替ただけだろ」と勝手解釈した上で逆ギレ。
ん〜 私の職場では10%じゃなくて100%かな。

「これさ、エクセルじゃなくてPDFとかビットマップでも出力できるようにしておいて〜」
って言われて2日かけてコーディングしたら
「パラメータ変えるだけで2日使うの?!君本当にプログラマー?!」
って説教された(w

完全オリジナルなソフトウェアなのでそんな便利なパラメータはございません(汗


53 :47:2006/08/18(金) 23:10:08
そんなCOBOLERとしている仕事の内容は
「テキストファイルのデータをOracleに登録する」
という内容の仕事。
まだ実現はしていないけど今までにおよそ120人月くらい消費しました(w

「SQL*Loader使えば一日で終わりますよ〜」と言いたいが
言ったら100%追い出される(w

54 :仕様書無しさん:2006/08/19(土) 00:03:45
SQL Loderなぞ、子供のおもちゃ。
120人月も浪費するのなら、PowerCenter使え。
1000万円ぽっちであれだけの機能が使える。

55 :仕様書無しさん:2006/08/19(土) 02:52:49
COBOLage

56 :仕様書無しさん:2006/08/23(水) 11:35:00
>>1に言うとすれば(もういるかどうかわからんが)
COBOLERになれるならなっとけ、ただしCOBOLと平行してjava勉強しとけ、イザという時少し有利だ
ってことか

57 :仕様書無しさん:2006/08/23(水) 23:36:31
>>56
COBOLer達の聖地金融業では
COBOLは古い!Javaだ!
という流れが全銀協 第一地銀協でできているようなので
その意見は正しいかもしれません。

けど、古〜いCOBOLERが出世して技術責任者になっていて
自分の技術をいつまでも肯定したいがためにCOBOLを支持するのが現状。
実際はCOBOLじゃぁ無理な要求をCOBOLerと友好関係にある金融業界がしてきている。

VBやCOBOLのように「だれにでも簡単に取得できる技術」で食うのはつらい時代となりましたね。

ちなみにこのスレで意見している人のCOBOLERとそうでない人の見分け方は
全角英数っす(w

55 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)