「COBOLに罪はない」トップ自ら情報戦略を主導する必要がある

1: 2019/08/12(月) 17:28:11.27 _USER

日本の活力低下の一因はデジタル化の出遅れにある。まず手を着けるべきは、古びた情報システムの刷新だろう。改修できる人材の枯渇も迫っている。デジタル化による爆発的な変化に企業が適応するには、トップ自らが情報戦略を主導する必要がある。

「COBOL」というプログラミング言語がある。1959年に業務用に開発され、金融機関などの基幹システムでは依然として現役だ。統計不正で問題となった厚生労働省の毎月勤労統…
https://www.nikkei.com/article/DGXMZO48430390Z00C19A8TCR000/

引用元: ・【IT】COBOLに罪はない　トップ自ら情報戦略を

6: 2019/08/12(月) 17:39:40.11 ID:5bOf028c

ゆとり世代にそんなことできるのか？

7: 2019/08/12(月) 17:39:44.49 ID:5bOf028c

ゆとり世代にそんなことできるのか？

85: 2019/08/13(火) 05:20:34.67

>>6>>7
おまえみたいに同じ内容でステップ数稼ごうとするヤツには無理

8: 2019/08/12(月) 17:41:54.20

いまだに人月だのステップ数だので管理してんの？

23: 2019/08/12(月) 19:14:19.31

>>8

javaだろうがｃだろうが、最終的にはステップ数だして、人月換算。
原価という意味ではそれでも間違ってないとは思う。

売価まで人月でやるから、おかしな話になる。

33: 2019/08/12(月) 21:29:55.11

金融システムや公共システムなんて、ハッキングの自由度のない限定されたものの方が
良いよ

60: 2019/08/12(月) 23:36:26.77

AK47みてえな言語だな

https://ja.wikipedia.org/wiki/AK-47

64: 2019/08/12(月) 23:52:01.19

AWSでほんとうに動くのかな

66: 2019/08/13(火) 01:05:13.83

もうコボル禁止にしろよｗｗ

74: 2019/08/13(火) 01:52:54.12

Windows上で動くCOBOLはゴマンとある中小企業のシステムには
最適なんだけど気が付かないだけ

81: 2019/08/13(火) 02:42:43.50

金融のメンテはじゃまくさいｗ
担当者からメモもらい、ワープロ
書類書き、ソースコード変更
テスト、ソースに名前入れ
完了後担当者にメモ、口頭

なんじゃこりゃ

112: 2019/08/13(火) 09:19:47.86

>>81

金融系は、プログラムにかぎらず、ガチガチの手順です。

121: 2019/08/13(火) 10:25:19.85

>>81
他の言語に変えたところで同じだなｗ

155: 2019/08/13(火) 14:05:14.11

>>124
そんな雑な管理じゃ、億単位の誤魔化しやっても責任不明で、
最悪は金融庁から行政処分食らうな

96: 2019/08/13(火) 07:31:54.93

コボルは業務システムをパターン化したモデルに基づいて良く考えられている。
新しい言語はプログラミングし易くなっているが、この手の記述に向いている訳でもない。
問題があるとすれば、プログラミングが面白く無いんだよ。

107: 2019/08/13(火) 09:05:30.93

コボルのソースコードをPythonやJavaScriptに翻訳するソフトを作れば良い

108: 2019/08/13(火) 09:10:28.18

>>107

COBOLなら一行で済む命令文が、PythonやJavaScriptでは10行～になるのでは、可読性が落ちて、かえって保守に手間がかかるよ。

109: 2019/08/13(火) 09:12:05.26

>>108
COBOLには関数って無いんだっけ？

111: 2019/08/13(火) 09:18:17.46

>>109

組み込み関数は　COBOL85から
ユーザー定義関数は　COBOL2002から

それ以前は戻り値領域を定義して、PERFORMで処理を呼ぶとかする

113: 2019/08/13(火) 09:34:02.63

いや
COBOLがなぜ悪いのか書いてくれ

116: 2019/08/13(火) 09:43:48.02

>>113

事務処理計算を大量にこなすバッチ処理では、COBOL悪くないよ。
最も適している。
そのために設計された言語だし。

119: 2019/08/13(火) 09:57:16.74

>>116
60年前に設計されたものを「最も適している」と評価するあたりがCOBOL業界の問題なんでしょうねぇ

132: 2019/08/13(火) 12:22:05.21

>>119

帳票処理って、帳票１の項目Aを、帳票2の項目Bに転記する　とかの繰り返しだから、
COBOLでそいういうコーディング書くのとても楽。
COBOLは帳票ベースの会計処理とかに最適化されてて、戸籍台帳の台帳処理とか、銀行の台帳処理とか
はやり方がほとんど変わらない。
税法とかの法律が変更されるにつれ細かい条件判断は増えていくけど、帳票処理自体は変わらんし。

京都市みたいに住民数が120万人で、住民基本台帳のマスタ更新と、税計算と、各種公的保険の請求・控除処理を
一晩でやり遂げて翌日は新マスタで窓口処理を開始するような大規模バッチはCOBOLが一番いいよ。

164: 2019/08/13(火) 18:52:41.32

>>132
ようは使い道なんだよな

銀行のように大元の勘定系のような基幹部分周辺だけCOBOLで書いて
エンドユーザに送るデータはサーバへ送ってJAVAで書くとかした方が良い

120: 2019/08/13(火) 10:08:51.55

うちはUNIX-COBOLで継続や

127: 2019/08/13(火) 10:51:48.86

COBOL++ とか COBOL# とか作ればよくね？

130: 2019/08/13(火) 12:12:16.75

>>127

COBOL85で構造化とか、自由書式を取り入れている

COBOL2002 でオブジェクト指向も取り入れたので、今のCOBOL仕様は
かなり進化している。

129: 2019/08/13(火) 12:09:28.31

ソフトはテストがすべて

外観がないからわかりにくい
だからテストだけが唯一の手がかり

162: 2019/08/13(火) 17:48:49.62

仕様を決めたときに、言語は指定されるから、選択肢はないんだよ

167: 2019/08/13(火) 20:52:08.78

でも国家試験から外されたよなCOBOL
つまりそういうことだ

180: 2019/08/14(水) 02:57:26.96

ＣＯＢＯＬという伝統を守って行くことが大事