-
日本の活力低下の一因はデジタル化の出遅れにある。まず手を着けるべきは、古びた情報システムの刷新だろう。改修できる人材の枯渇も迫っている。デジタル化による爆発的な変化に企業が適応するには、トップ自らが情報戦略を主導する必要がある。
「COBOL」というプログラミング言語がある。1959年に業務用に開発され、金融機関などの基幹システムでは依然として現役だ。統計不正で問題となった厚生労働省の毎月勤労統…
https://www.nikkei.com/article/DGXMZO48430390Z00C19A8TCR000/ -
新しい言語でイチから作った方が確実だよ。
みずぽ銀行見たら分かるだろ。 -
>>2
みずほ見てたらむしろ無理せずにCOBOL使ってた方がましだったと思う。 -
>>2
みずほの場合、新言語をどうするかで揉めて
さらに長引いただけだと思う -
>>2
みずぽとか反面教師以外の何者でもない。 -
>>2
みずほが一番作り直したって聞いたが -
IT技術者は引手あまたの人手不足で
え～愛ない雇用だと同業他社に転職 -
Javaもオワコンだから全部書き換えないと
-
悪く言ったり、よく言ったり
どっちや -
ゆとり世代にそんなことできるのか？
-
>>6-7
現場見てたらわかるけど、実際に開発するのはアゴで使われてる下請け氷河期中年だよ
ゆとり正社員はそいつらに適当に指示だけして働き方改革とやらで定時で帰ってる -
いまだに人月だのステップ数だので管理してんの？
-
>>8
上がそれしか理解できないから仕方がない -
>>11
他になにがあるの？教えてw -
>>125
ファンクションポイント法とかあるけど、最終的に予算化するときには、人月にしないと予算化できない。
-
>>8
javaだろうがｃだろうが、最終的にはステップ数だして、人月換算。
原価という意味ではそれでも間違ってないとは思う。売価まで人月でやるから、おかしな話になる。
-
>>8
公務員がこの考えを捨てないね -
>>8
売る奴、買う奴共に新しいビジネスモデルを提示できないでいる。
昔ながらの人月を変えたい奴はたくさんいるけど、どこかの会社がうまいやり方を発見するまでは待ち状態やな。 -
アメリカでもCOBOLはバリバリ現役だろ
人のせいにするな
ウイルスに強いだよ -
日経だろ
日経コンピューターも初っ端からずれたあさっての内容しか書いてなかった
読むだけ無駄だろう -
今、動いてるCOBOLを金掛けて他言語に置き換える意味不明
必要なのは言語のコンバートじゃなく、業務の整理・単純化なんだけどね
業務を放置して言語コンバートしても、結局、新しいグダグダ・システムができるだけ
しかも、金掛けてコンバートが上手くいく保証はない
単純コンバートだとグダグダが増すだけだし -
>>12
> 必要なのは言語のコンバートじゃなく、業務の整理・単純化なんだけどねこれだよね
-
月収手取りで13万交通費付き3万まで支給、携帯料金月15000円まで支給でくるかい？
-
にっけいコンプータのおじさんがみているスレ
-
ちなみに、残業代はみなし費としてすでに含まれてるよ
始業時間は9時30分
就業は6時予定だけど仕事が終わるまで何時間だろうが終わらないよ。
ちなみに寝るときは机の下で寝てね。
マットは貸すよ。保険代として1万ね。 -
トップなんてその場で動けば何でもいいのよ
-
こういうことをいうヒトの前提として
「仕事は全部コンピュータでする」そうでない仕事も沢山ある
-
メガ金融でさえクラウドの汎用システムを使う時代に、
こんなものをいまだダラダラ使っている企業そのものがオワコン 実際にボコボコ潰れているのは周知で心配御無用 -
時代はぴゅーたの日本語basic
-
COBOLをやめるんじゃなくて
構造化COBOL、オブジェクト指向COBOL、IT化COBOL
そういう方向に進化させれば、骨格は活かせるんじゃないか？
知らんが（笑） -
>>21
COBOL2002だとオブジェクト指向が取り込まれてる。
ただ使いこなせる人がいないし、上も導入に及び腰。 -
>>21
オブジェクト志向が壮大な失敗と言われているの知らないの
ポインターも分からないプログラマにCでアプリを書かせてメモリエラーの山になったりクラスが作れない設計者にC++で設計させてどこを修正して良いか分からない状態にして日本だけでもIT産業衰退要因になっている -
>>153
まず低能を排除しろ
話はそれからだ -
>>153
日本は終わってるな
オブジェクト指向も理解出来ないのか -
高校生の時習ったな。懐かしい
-
COBOL知らないでIT語るとか、ないわー
-
COBOちゃん
作・植田まさし
-
言語じゃなくてリファクタリングをサボりにサボったからだよ。
javaにしたってリファクタリングしない会社はCOBOLの時と同様に使い物にならないソースになってるぞ -
>>30
言うのが簡単だが、費用対効果がハッキリしないものに
大金を出す会社はまずない -
>>51
クソ高いメインフレームを捨てられるというだけで費用対効果は歴然。
ま、自分の金じゃないからいくらでも使っていいよってことだろうけど。 -
>>51
だからjavaでも同じだとコードを維持するコストを出さなければどんな言語でも同じだ
-
>>86
COBOLだと、リファクタリングがやりづらそう昔からの言語仕様で作られているソースが大半だろうし、コボラーが新しい言語仕様で作り直すととても思えない
-
>>87
JAVAのほうがやりづらいわいやりやすい前提が崩れたJAVAだよ？ぐちゃぐちゃになっててあっちこっちソースが分断されてて、、、最悪だ！COBOLのがマシ！
-
戦略的に使わなくてもいいからCOBOLなんです
いぶし銀 -
コボラーに罪はある
-
金融システムや公共システムなんて、ハッキングの自由度のない限定されたものの方が
良いよ -
>>33
そんなシステムこそ、本当はAIによる業務効率化とか求められてそう -
バカな会社がコボル使わないで金融システム組んだよ？
結果は金を盗まれまくりｗセブン銀行って言うんだけどね
-
COBOLという言語には何の問題もない
システムが開発されて何十年も経てば、その間に改訂が入りまくって
ツギハギだらけのプログラムの山になる
どんな言語でもそれは同じだわ
結局どこかで全面的に作り直すしかないけど、危険性や費用面を考えると
新規開発は断念して既存の改修にとどめるってのかお決まりのパターン -
>>35
敗退したアメリカ軍のCOBOL掃討戦は
その後どうなったんだろ -
み〇ほの場合、コボルというより
完成度の違う複数のシステムを統合することがむずかしいだけ。 -
事務処理には圧倒的にＣＯＢＯＬが便利だけどな
ＣＯＢＯＬ以上に使いやすい言語は思いつかんわユーザーインターフェイスに不向きなのは認める
-
>>40
世間のCOBOLシステムが増築を繰り返している現状を見ると、メンテナンスが属人的になりがちで良い言語ととても思えない覚えることは少ないけれど、人それぞれの実装を全て把握しないと保守できないイメージ
-
>>42
増築を繰り返している＝それ以上に良い方法が思いつかないまあ保守には困っているようだな
ＣＯＢＯＬで求人を検索するとメンテ要員で年齢問わず時給３０００円とか普通に出てくる -
>>45
俺はCOBOLシステムなどのレガシーをOSSのオープン系に置き換える仕事がメインだよ増築で生じている無駄な処理は徹底的にカット
-
コボル使って富士通系の仕事してたけど、自分の初めて組んだ帳票プログラム、無駄なルーチン多すぎたな〜
まだ動いてんのかな -
コボルだから稼げる状況。
-
コボちゃんは５０代のエンジニアに任せたよ。おっさんたちが責任もって絶滅させてよ
-
何十年もかけて増築したシステムって
人がいじれるものじゃないと思う -
何かの言語に乗り換えたとして、
それが ５年後７年後にサポートされているかどうかはわからない。COBOLなら７年後も現役。だから今回は COBOLのまま サーバー更新した。
NEC が ACOS を作ってくれている間は現役。 -
Windowsで動くCobolもあるだろう
-
>>53
新たに作るのは良いのだが既存システムを載せかえるのは困難を伴う。
文字コード体系の違いは大きい。 -
>>93
データをコンバートするだけ -
>>95
仕事やったことあるけど
そんなに簡単じゃない
MFCOBOLに移行してガワはJavaだったけど -
>>95
メインフレームは漢字コードの管理が大変。
データベースにはSI/SOが入って無くて、APP側で追加する（漢字コード領域の前後にあらかじめ初期値として入れておくので、処理としても書かれてないとか）とか普通にあるので、単にデータコンバートするだけでは、全然だめ。 -
なくなるどころかさらに複雑化しとるやんけ… どーすんのよこれ
-
Win上は不安があると思うけど
-
今時のPCでもオフコンやミニコン並みの性能はあると思うよ
-
性能はあっても電子部品が持続できない
-
PCサーバーならその様な堅牢さも持ってるし
保守部品調達も迅速だよ -
>>59
PCサーバは原則5年で保守打ち切り。
長くて7年。
しかも延長保守料が高くつく。 -
>>177
ミニコンの保守料ってPCの比じゃないでしょ -
AK47みてえな言語だな
-
レガシーな言語だからって、必ずしもレガシーな書き方しか出来ない訳でもないからな。
-
COBOLの罪は、仕様はコンソーシアムでオープンだが、
実装がベンダ依存で、結構違うとことか、
低級言語なのにポインタが無いから、
外注するとメモリが溢れたりするとこじゃね。
あとはオブジェクト指向でも関数型でもないから、excel関数と同じでコピペが当たり前のとことか -
>>62
OO-COBOLは大昔に規格化され、コンパイラも対応してるぞ
ただ、使いたい人間も使える人間もいないので、
外部のオブジェクトライブラリを使う時ぐらいしか出番がない -
レガシーだしCOBOLからPythonになっちゃったし
出来ることはすぐ覚えられるだろうが誰もやりたがらんだろうな
COBOLはVB6と同じような状態になるんだろう -
AWSでほんとうに動くのかな
-
ここだけの話、COBOL言語自体は（他のモダン言語に比べると周回遅れだが）それなりに進化してる。
問題はそれを使う輩の頭。まるでバージョンアップされない。
そして同じことが、特にVBとC++とJavaで顕著に起きてる。 -
>>65
そうですね。
言語開発者の意図をプログラマーが理解していないからねー。
算術演算だけの文系プログラマーは、論理が分かっていなよ。 -
もうコボル禁止にしろよｗｗ
-
将来は日本の水道管みたいになりそう。
高いかね払ってアフリカみたいに外資の奴隷になるパターン。 -
金融機関だけじゃない
そうとう残っている -
オブジェクト指向のCOBOLとか実際に使ってるとこあるの？
-
Windows上で動くCOBOLはゴマンとある中小企業のシステムには
最適なんだけど気が付かないだけ -
メンテ費用馬鹿にならんのだし、ほんとメインフレームごといい加減捨てろよ
第二地銀出来た時のCOBOL特需で大学の授業そっちのけでクッソ稼がせてもらったけどさ、
コボラー不足は当時より遥かに酷いんだろ？ -
>>75
言語変えてもメンテがなくなる訳じゃないｗ -
>>76
それは、メインフレームベンダーからもらってるキックバックがなくなると困るから？ -
>>76
ベンダー変えたらメンテ費用が10分の1以下になったって例もあるからこまっっちゃうよね -
人間コンピューターをいっぱい雇えば
-
徹底したスクラップ＆ビルドでシステム再構築しないと、
「問題点」を新システムに移植しちゃうんだよな -
少し触ったけど
俺はゲームブックを作りに来たんじゃないぞ
と思った -
コボちゃん
-
適材適所、COBOL や Java とかそれぞれの言語に向いてる処理がある。
COBOL で問題なく動いてる事務処理をわざわざ別の言語に書き換えるメリットなんかないだろうよ。
メンテなんて必要な時にはその言語を勉強してやればいいだけ。
特定の言語しか使えないやつがいるという前提がおかしい。 -
COBOLを捨てろって言う奴は何の言語に変えるべきだと思う？
-
>>88
別にCOBOLのままでもいいけど、オブジェクト指向を取り入れた新しい言語仕様で作れPHPだって、オブジェクト指向を取り入れて延命してるだろ
-
>>89
オブジェクト指向言語にオブジェクト指向じゃないコードが書いてあるのが現実だぞ -
>>91
それでも遥かにマシ -
>>92
そんなわけあるかい
めちゃくちゃなコードはどの言語だってめちゃくちゃだ
定期的にまずいコードを破棄してく保守がなけりゃどれだって最終地点はゴミクズさ -
>>97
めちゃくちゃなコードでも、オブジェクト指向にして、開発環境のミドルウェアを使いこなせば、保守効率は雲泥の差 -
>>98
オブジェクト指向じゃねぇコードがめちゃくちゃにパッチ当て的に書いてあるんだよ！
20年も同じコード修正し続けたらそうなるの -
COBOLに関わる人はみんな後ろ向き
そんなCOBOL界隈が大嫌いです -
コボルは業務システムをパターン化したモデルに基づいて良く考えられている。
新しい言語はプログラミングし易くなっているが、この手の記述に向いている訳でもない。
問題があるとすれば、プログラミングが面白く無いんだよ。 -
業務で使うからってCOBOLで基本情報受けようとしたら無くなってる
-
最近の言語は5年くらいで刷新されるから、COBOLよりも危険だろ。
アプリ開発やパッケージシフテムならそれでなもいいけど、勘定システムでそれだと無理。 -
言語の良しあしは別として
年寄りのＣＯＢＯＬ好きは異常w
ていうよりＣＯＢＯＬしか知らないと思う
オブジェクト指向言語とか言われたら
受け付けないんじゃないか？ -
汎用機の方がセキュリティは高い気がする
-
コボルのソースコードをPythonやJavaScriptに翻訳するソフトを作れば良い
-
>107
COBOLなら一行で済む命令文が、PythonやJavaScriptでは10行～になるのでは、可読性が落ちて、かえって保守に手間がかかるよ。
-
>>108
COBOLには関数って無いんだっけ？ -
>>108
組み込み関数は COBOL85から
ユーザー定義関数は COBOL2002からそれ以前は戻り値領域を定義して、PERFORMで処理を呼ぶとかする
-
いや
COBOLがなぜ悪いのか書いてくれ -
>>113
事務処理計算を大量にこなすバッチ処理では、COBOL悪くないよ。
最も適している。
そのために設計された言語だし。 -
>>116
60年前に設計されたものを「最も適している」と評価するあたりがCOBOL業界の問題なんでしょうねぇ -
うちはUNIX-COBOLで継続や
-
この際、ＦＯＲＴＲＡＮはどうでっか？
-
COBOL++ とか COBOL# とか作ればよくね？
-
>>127
COBOL85で構造化とか、自由書式を取り入れている
COBOL2002 でオブジェクト指向も取り入れたので、今のCOBOL仕様は
かなり進化している。 -
>>130 そうなんだ。
じゃあ、.NET で使えそうだな。 -
ソフトはテストがすべて
外観がないからわかりにくい
だからテストだけが唯一の手がかり -
Cobolではなかったけど
一行文字数の制限知ったときはぶったまげた -
>>131
パンチカードがまづ先にあって、機械式の会計機械で処理していたのを、電子的に処理するためにメインフレームが開発されたからね。
-
>>138
その程度なら、フレームワークによってはコーディングレスかもよ -
>>136
そのフレームワークが今から50年前にあったら、そうだろうけど。
今フレームワークを使おうとするのなら、現在のシステムを０から作り直すということになるから、
それは現実的ではないな。
西暦＜＞和暦 の変換をJavaならライブラリ使って簡単にできるけど、そのためにシステムを０から構築しなおすかという問題。 -
プログラマーがそういうの意識する言語のほうが稀では
-
マイクロソフトはVisualCOBOL.NETを出してくれや！(*ﾉω・*)ﾃﾍ
-
MS製はなかったけどMicroFocusが出してたような気がする
-
PythonやGoなどの新しい言語はバグやセキュリティに不安がある。だから基幹システムは枯れたCOBOLでやる、とかそういう理由なのかね。
保守的というか、システムを一度作ったらおしまいとか思ってるからそういう発想になるんじゃないか？
時代錯誤だよなあ。これだから日本のソフトウェア産業は未だに低レベルなんだな。 -
>>146
世界規模でみると、COBOLのソースは増えているよ。
PythonやGoは基幹システムの要件からすると、オーバースペックだし。 -
九か九龍だろうな
-
俺もCOBOLerだけど俺のポリシーはIF文は極力使わない
IF使うところはEVALUATE使ってた -
【IT】Flashに罪はない トップ自ら情報戦略を
-
EVALUATE って、多くの言語では、CASE文ね
-
>>160
どっちかって言うとswitch文じゃね？
caseってPascal系の言語とSQL位かと -
仕様を決めたときに、言語は指定されるから、選択肢はないんだよ
-
今のCOBOLは、言語仕様上はオブジェクト指向言語であり、
各コンパイラにも大昔に実装されている
（でも、使われていない）
↑
これを知らないカキコ多し -
>>163
オブジェクティブなcobolは知ってるが、それならjavaやc#でいいじゃんという -
印鑑だろバカタレめ！
-
でも国家試験から外されたよなCOBOL
つまりそういうことだ -
COBOLって帳票を転写するための言語でしょ？
ぶっちゃけawkとかで代用できるよね
そしたらあとは速度だろうけどその辺はどうなの？ -
>>168
awkはインタプリタだから遅いし、そもそもトランザクション処理できない。
-
>>171
トランザクションにしたければ裏でDB動かせばいいし
ファイル操作の速度で言えば、インタプリタだろうと関係無いと思う -
>>175
awkで120万人分の住民登録台帳を1晩で更新できる？
-
>>183
出来ると思うよ。やり方工夫すればね。Cobolでしか出来ない事なんて今はないだろう。
-
AWS LambdaでCOBOLいけるっぽいから、Lambdaじゃきついバッチだけ置き換えて、COBOLで組まれたシステム続行じゃないのか？
そもそも官公庁すらパッケージ入れたり、クラウド使ったり、SaaSサービス入れたりしてる時代で、COBOL使ったレガシーシステム排除したからって大きく変わるのか？某人事パッケージが市場寡占一歩手前になるようなユーザーの状態を先にどうにかしないといけないと思うが
-
ＣＯＢＯＬという伝統を守って行くことが大事
-
実際経理やＤＢには向いてるんだよね。
書いたやつが居なくなっても他人が容易に保守できる。 -
>>181
C言語やJavaで同じ処理を書いた場合より、わかりやすいと思う。
-
僕、頭悪いんです
まで読んだ。
-
アクセスの村上ってどうなった？
-
コボラーにとっては頑張って使うものなのかｗ
-
なんじゃそれ
-
Cobol以外使えないと潰しが効かないからな
-
10年後の今月今夜も、COBOLで徹夜だよ
-
バグもミスも許されない。
後から修正も許されない。
部品交換は許されない。一度組み入れたら20年は問題なく動き続けなければならない。
-
>>195
惑星探査機でも作ってるんか？ -
>>200
サポートが面倒
納品時にバグが存在しないもの以外ヤダ -
信頼性は言語の問題では無いわな
いかに検証するための環境を整備するのかで信頼性は担保される
しかしCOBOLの世界はそれが出来ているのかね？
人海戦術で金をつぎ込んでるから安心というなら息切れするぞ -
COBOLの人は何かと言うと１０進演算がーというけれど、
60年前と違って、今ならちゃんと仕様が定義されていれば精度や丸め方法やその他諸々含めて
COBOLと同じ動きをする型を作るのは簡単だし、速度もx86サーバでメインフレームと
同等かそれ以上の速度出るから、そこだけ覚えて帰って欲しい。 -
>>202
BCD演算ルーチン組んで性能評価してみれ
そこで激遅になるって分かるから -
>>202
建築の公差や金融の小数点問題は、技術の進歩でむしろ深刻化している -
うまく進めるチームはどの言語・ツールを使ってもうまく進めるし、
ダメなチームはどんな良いものを使っても失敗する。
つまり、言語がどうとか言ってること自体がもう分かってない。 -
今時性能による選択でCOBOL選ぶ企業は無いだろ
-
将来この言語でなく、他の言語もいわれるんだろうなｗ
-
ディープラーニングでソースから仕様を書き出すみたいなのできないの？
-
>>211
まず無理
コードからは「何をするか」は分かる
しかし「何がしたいか」は分からない
簡単に言えば1+1を計算するコードからどんな意図を読み取れるのかってこと -
30年以上も経ったCOBOLのソースには盲腸が一杯あって
考古学的に検証していかないと,何しているかが分からない -
みずほの新システムも半分はCOBOL
なんだが。。 -
こういうスレがあると必ずCOBOLについて書く、キチゲェさんがいるねｗ
-
ソース見ても、実際には通らないロジックがそのまま残っていたりする
業務に10年以上関わっている人でないと,それが必要なのか不要なのかも判断できない -
昔からのデータや業務を捨てる勇気があるだけで全然違う
-
勘定システムで一番の問題は、
COBOL云々より、現代的な金融システムを知らないが多すぎて、ソースかけないこと。
COBOLが良かったのは、金融業務に詳しい人なら簡単に使えた事。 -
COBOLって金融に特化したプログラム言語ってわけじゃないでしょ
-
そうですよ
金融以外でも使われている、稼動している -
交通系でも使われてるぞ。
人手足りなくてヘルプ頼まれて、COBOLウゼーって思いながら適当に組んでたしｗ -
>>222
制御じゃなく、事務の方で、だよね？ -
>>223
安心しろ、事務じゃないからｗ -
スペースシャトルの制御システムは、COBOLベースのオリジナル言語で、ラインプリンタの特定の桁が、アポジモータのスイッチだったり
-
>>225
スペースシャトルは2011年に引退したぞ -
何で作っても結局安全性がんじがらめのDSLで書くことになって
それがCOBOLと等価でした、なんてことになったりして -
何でオタクって
アポジモーターが好きなんだろう？ -
>>228
日頃あまり聞かないから専門用語っぽいってことじゃね？ -
老害パソコンってひどい表現だな
この記事書いた奴ネラーじゃないか？ -
日経新聞はCOBOLを古いと否定するが、Amazonのデータセンターは新たに複数の言語
をサポートし、COBOLもサポートしているよ。
日経だけが取り残されている。 -
主な所はしゃぶりつくしたから、
残飯を漁りだしただけだろう
元スレ：https://egg.5ch.net/test/read.cgi/bizplus/1565598491
コメント