金融系メインフレームはなぜCOBOLをつかうのか

x86でBCD命令つかってるのみたことないですね……
179
分散処理に詳しいオタク @kumagi

「COBOLじゃないとお金の計算は狂うからCOBOLにしか金融系は任せれない」というの、例えばPythonで金融の計算をすると具体的にどういう狂い方するんでしょう?

2014-12-19 19:29:59
Miura Hideki @miura1729

@kumagi 1円以下を扱うと、普通は浮動小数点数になるからそこで誤差が生じるけど、COBOLは10進演算で行うことと言語仕様で決まっているから大丈夫という話だと思います。固定小数点とかでライブラリ書けばいいんでしょうが、それも手間だし。

2014-12-19 19:32:53
分散処理に詳しいオタク @kumagi

@miura1729 Python含む他の言語には信頼できる固定小数点ライブラリが無いと言う事ですかね?

2014-12-19 19:50:49
SODA Noriyuki @n_soda

@kumagi @miura1729 やればできるけど、COBOLみたいに言語のデフォルトになってるのに比べて記述が面倒くさいし遅いって話です。汎用機とかエンタープライズ向けサーバCPUには10進演算命令もあって、COBOLコンパイラならそういう命令を使ってくれるんじゃないかな。

2014-12-19 19:55:25
Miura Hideki @miura1729

@kumagi すみません、間違えました。10進演算ライブラリです。遅くていいならできるでしょうが、COBOLみたいに専用命令用意して徹底的に高速化したものはなかなか無いんじゃないのではないでしょうか?

2014-12-19 19:57:06
Miura Hideki @miura1729

@n_soda @kumagi ですね。10進演算命令はマイコンにもありますね。6809にはDAAという命令があります。86系にもありそうな気がしますが、良くわからないです。

2014-12-19 19:58:59
SODA Noriyuki @n_soda

@miura1729 @kumagi マイコン系やx86の場合はBCD命令群ですね。x86 の例: en.wikipedia.org/wiki/Intel_BCD… エンタープライズ向けCPUが持つ命令は、BCDより遥かに頑張ってる感じなんだと思います。

2014-12-19 20:03:23
数ヶ月間貧乏だけど心は萌え @kokorohamoe

@n_soda @kumagi @miura1729 いやBCDライブラリもありますし数百万桁のPIEの演算とかもCでやるわけで 数百万桁の精度のPIEが計算できるのになんだろうな。 早い遅いはCPUの速さもあるのでなんとも あたりまえですが高精度の科学技術計算もしてますので

2014-12-19 20:04:36
数ヶ月間貧乏だけど心は萌え @kokorohamoe

@n_soda @kumagi @miura1729 というか 演算精度が要求されるときにCPU組み込みのdoubleは まず使いません。 そもそも 0.01あたりですでにご差が出るので

2014-12-19 20:05:27
Miura Hideki @miura1729

@n_soda @kumagi なるほど、任意桁数をサポートしているとかでしょうか。今はネットとかでお金の動きが激しいし、ドル円レートとか必ず小数点数以下の精度が必要になるので昔よりもっとこの手の計算が重要なんでしょうね。

2014-12-19 20:05:34
SODA Noriyuki @n_soda

@kokorohamoe @kumagi @miura1729 geocities.jp/andosprocinfo/… に書いてあるようなハードウェアアシストは、x86にはなかったと思います。(それとも最近はあるの?

2014-12-19 20:06:31
SODA Noriyuki @n_soda

@miura1729 @kumagi こういうCPUが生き残ってるのは、銀行とかそういうところなので、そっちのニーズに合わせた機能があるんでしょうね。

2014-12-19 20:07:49
分散処理に詳しいオタク @kumagi

@n_soda @kokorohamoe @miura1729 スピードが必要なのってシングルスレッドで朝までにバッチが突き抜けないように書く必要があるからじゃないかと思ってるのですが、並列化みたいな非決定的な演算は信用できないからとかでしょうか。それとも本質的に並列化不可能?

2014-12-19 20:08:50
Miura Hideki @miura1729

@n_soda @kumagi こういう話は地味だけどお金になるから表に出ないところですごく極めているんでしょうね。個人的には関わりたくないところですが。

2014-12-19 20:10:39
SODA Noriyuki @n_soda

@kumagi @kokorohamoe @miura1729 大量にあるレガシーなアプリを、再コンパイルだけで速くしたいからでしょう。たぶんあまりに一杯あって、いろんなしがらみの塊なので、書き換え自体が困難かと。

2014-12-19 20:11:27
SODA Noriyuki @n_soda

@miura1729 @kumagi デスヨネー>関わりたくない。ほんのちょっと変更しただけでも、尋常じゃないテスト工程の作業量とか要求されそうです。

2014-12-19 20:12:40
分散処理に詳しいオタク @kumagi

@n_soda @kokorohamoe @miura1729 技術的負債でいつか死ぬか、途方もないコストを払ってスクラッチするかという話ですか…。関わりたくないですね…。

2014-12-19 20:13:12
Miura Hideki @miura1729

@n_soda @kumagi 変更するコード行数と提出する書類の枚数が大体同じとかそんな感じでしょうかね。変更文字数と書類の枚数が大体同じだったりして (震え声

2014-12-19 20:15:18
Miura Hideki @miura1729

@kokorohamoe @n_soda @kumagi FORTRAN使いのナンバークランチャー達は誤差が出るのが前提で不思議な職人技で誤差を抑え込んでいる(または誤差の上限を把握している)というイメージがあるのですが、そうでもないものなのでしょうか?

2014-12-19 20:22:14
SODA Noriyuki @n_soda

@miura1729 @kokorohamoe @kumagi その認識で合ってます。 amazon.co.jp/dp/4320013433/ とかに、わりとまとまっていたと思います>職人芸。(斜め読みしかしてません…

2014-12-19 20:26:08
中村 実 @nminoru_jp

@n_soda IA-32時代には二進化十進数補正命令がありましたよ。AMD64がlong modeを導入した時に無効にしましたが。

2014-12-19 20:27:02
Miura Hideki @miura1729

@n_soda @kokorohamoe @kumagi 良書っぽいですね。紹介ありがとうございます。ご存じだとは思いますが、個人的にはこれですかね docs.oracle.com/cd/E19957-01/8…

2014-12-19 20:29:54
中村 実 @nminoru_jp

@n_soda ただある時期のIntel CPUにはこの命令の一部にエラッタが出て、しかもマイナーな命令だったためかリコールされることもなく、市場に間違った結果を返すx86 CPUが溢れて、この命令使ったソフトが作れなくなったとか。 datasheetarchive.com/files/intel/de…

2014-12-19 20:30:23
残りを読む(10)

コメント

Rogue Monk @Rogue_Monk 2014年12月24日
まだCOBOL使ってるのか・・・
0
はいん・まいやー @reisacker 2014年12月24日
レガシーな資産が多すぎて、COBOLから移行できないというのが現状でしょうな。
24
やまさ @yamasa 2014年12月24日
10進小数の演算の重要性については同意なんですが、今更BCDは無いでしょう。10進浮動小数の形式はIEEE 754-2008で標準化されており、これはもはやBCDではありません。今から10進演算命令を追加するなら当然IEEE 754-2008になるでしょう。
4
kartis56 @kartis56 2014年12月24日
え、メインフレームでPython使うの?
1
trycatch777 @trycatch777 2014年12月25日
レガシーな資産大杉な上に、既存コードのメンテナンスが出来る人間(つまりCOBOLプログラマー)は新しく出てこない。若いソフトウェアエンジニアなCOBOLなんてやりたがらない。で、現50代後半〜60代の方々が継続してメンテする。彼らはCOBOLさえ書ければ他の技能は必要ない。賃金も上げなくて良い。こんなとこでしょうか。
3
くわたろ @kuwataro 2014年12月25日
自分の経験上、演算精度の問題になったことは無くて、単純にバッチの速さの問題。1000万件単位の伝票とか口座引落処理を100並列3時間でやりきるのにお手軽な言語処理系は何かっていうと今でもCOBOL。Javaでも不可能ではないけど考えなしには出来ないでしょ。
12
nao1970 @gappai_Z 2014年12月25日
人間がもっともレガシーな資産なんだけどね
3
くわたろ @kuwataro 2014年12月25日
固定長ファイルの単純な編集、だけどそれを1000万件とかそれ以上の桁で処理しなきゃいけなくて許される夜間ダウンタイムが3、4時間くらい。四半期の締が重なるともっときつい。
11
んぱんぱ @crayonmarch 2014年12月25日
日本の銀行(というかインフラ関連全てにおいて)のプログラマーは凄まじくド素人と指摘されているが、その理由がよくわかる気がする。サボる努力をしないナマケモノだな。
0
kartis56 @kartis56 2014年12月25日
まずメインフレームでないと困る仕事があって、その後にその上で何が使えるかがある。
8
V層もどき @desuga_NlkL5EiN 2014年12月25日
COBOLコードを人が書いているわけではない、というケースもあるんで。COBOLコードを中間コードとして吐き出す言語(いわゆる4GLの部類とか)があって、実際のコーディングはそっちの言語でされてると。
3
V層もどき @desuga_NlkL5EiN 2014年12月25日
その場合、COBOLが中間コードとして選択されてるのはマシンアーキテクチャ独立かつ標準化されてて、汎用機含むターゲット群のマシンに大概実装されてるから、という理由かな。
3
秋葉原エリカちゃん @At_Zamasu_Zansu 2014年12月25日
COBOLから他のシステムに置き換えた場合に掛かるコストを置き換えた時に回収出来るスキームやプロフィットが無いと置き換える必要がないからでは無いだろうか。技術的な問題や仕様の問題ではなく。
13
SAKURA87@多摩丙丁督 @Sakura87_net 2014年12月25日
日本の場合は誰かが最初にそれを導入して、それがいいものだった場合そのまま右習えで他も導入して。メーカーが倒れてその規格がなくなったとかでない限りずっとそれを使い続けると言う変な習性があるので以外と何も考えてないだけだったりするかも。
1
ばしにぃ @hiro_orso_viola 2014年12月25日
経験上ですがメインの処理でCOBOL入ってるのはもう所謂ホスト系だけだと思うけど。今は処理速度を求めるとしてもベタなCで十分。あと老朽化での更改やマイグレでなるべく既存のコードを変えたくないという事情から数年ごとにコボラーの需要が出てくるのだけど、そういうのは金融・証券というよりはむしろ保険業界のほうが多いと思うよ。
3
nekosencho @Neko_Sencho 2014年12月25日
ちなみに伊賀地方で「こぼる」といえば壊すことを言います。「あの家こぼってしもて」(あの家壊してしまって)みたいな感じで使います
3
tomo @tomo_091519 2014年12月25日
ありゃ、IBMのエンタープライズ向けサーバは、CPUが十進演算をサポートしてますがね。 お金の計算には、見えるロジックが必要なんですよ。 継承って何?隠蔽って、そう不味いものです。
3
さかなさかな @yuiyui999 2014年12月25日
すでに存在するものがCOBOLで書かれていたからってくらいじゃないのかな?
0
齊藤明紀 @a_saitoh 2014年12月25日
コメントを入力してください。精度の問題ではなくて、算盤で計算して少数以下○位で四捨五入(なのか切り捨てなのか知りませんが)するのと 全く同じ でなければいけないってのが金融計算の要請なのでは?もともと浮動小数点ではなく固定小数点計算の世界。兆単位のお金の利息を計算することを考えると、64bitdoubleでも精度は不足しますし。
2
undo(時は来た。それだけだ) @tolucky774 2014年12月25日
不具合出した時に誰が責任取るの?というあれ
1
VRAM01K @VRAM01K 2014年12月25日
この業界、動いてるものには手を入れないという経験則があるので、ハード更改でもない限りは別の言語に乗り換えることはしたがらないでしょう。そもそも移行にかかるコストをどうするのかという問題もありますし。新システムならばCOBOL以外の選択もあるでしょうが。
11
んぱんぱ @crayonmarch 2014年12月25日
kartis56 現実問題として銀行のシステムそのものが時代遅れでしょう、短いパスワードで認証システムも不完全。ハッキングされないのが不思議だわ。
0
んぱんぱ @crayonmarch 2014年12月25日
kartis56 アメリカではCOBOLのプログラマーが転職できないって書いてあったよ、古い技術しか使えないからノウハウがないとのこと。その時点で駄目じゃないか。他のプログラマーだったら転職する上で大きな弊害はない。
1
んぱんぱ @crayonmarch 2014年12月25日
コストの話も出ているけど、技術の発展のためのコストを惜しむなら、やる気が無いとしか言いようが無いんだよね。提灯記事で技術は進化していますって書いてあっても全く説得力がありませんよ。IT系は値段が高いだけのゴミ技術が乱立しているし。
1
nao1970 @gappai_Z 2014年12月25日
金融内のシステム屋(コボラー)さんもいるわけで、 新システム開発で言語が変わったとして、その結果検証はできるかもしれないが、 その中味が評価できない。それが怖いから(言語は)変えないってのもあると思う
3
nao1970 @gappai_Z 2014年12月25日
また、同じ理由で金融機関独自のカスタマイズしたい時、中の人だけでは対応できない状況に 金融業務知っていて、COBOL以外の言語で開発経験ある人が多数になれば、あるいは...
2
黒川 @kurokawa92 2014年12月25日
10年ぐらい前保険屋で仕事させてもらった時消える消える言われた代物がバリバリ使われているのをみて驚いたが、やはりまだまだ頑張っているのか
0
くみかおるの冒険 @ElementaryGard 2014年12月25日
実父が地方銀行のオンラインシステム開発のリーダーでした。ちなみにSEではなく生粋の行員です。数学と物理に強く英語も得意だったため抜擢された(というか押し付けられた)そうです。
1
のま @nis_ktnm 2014年12月25日
他の言語に書き換えたとしてリスクやコストに見合ったメリットがあるかって話なんだよな。フロント部分ならともかく今どきCOBOLで書かれた部分なんて数字が合ってる事が重要で技術の発展なんてわりとどうでも良いんですよ。
9
きゃっつ(Kats)⊿ @grayengineer 2014年12月25日
さすがに10進演算はほとんどの言語とDBでDecimal型が用意されている現在、理由にはならないな、と思った
4
Hide Yamauchi @MC6809EOS9 2014年12月25日
crayonmarch 元々のMFの認証は確かに古く制限もありますが、RACF、ACF2やTop Secretを使うことによって変わっています。また、MFの認可の仕組みは分散型のシステムに引けを取ることはないでしょう。
4
VRAM01K @VRAM01K 2014年12月25日
ベンダーの方は機会があれば提案なりしてると思いますが、リスクやコスト考慮してやるメリットに見合わないと判断してるのは金融機関の方でしょうし。
5
Hide Yamauchi @MC6809EOS9 2014年12月25日
.crayonmarch 確かに言語の面でCOBOLの人達が他の言語に移行するのは難しいかもしれません。その理由はCOBOLが提供するシステムの抽象化が他の言語とは違うからです。ただ、特定分野の業務を理解する能力はそれとは違います。それは技術が新しいとか古いとかにはあまり関係がありません。特定の業務の実装がCOBOLを使っているのです。
6
Hide Yamauchi @MC6809EOS9 2014年12月25日
.crayonmarch 大企業のビジネスはかけたコストで、どれだけの利益が得られるが重要視されます。新しい技術が会社や顧客に利益をもたらさないのであれば意味はありません。多くの会社の業務は技術の発展のためではないのです。
14
丸九 @ma_ru_q 2014年12月26日
二十年来手加え続けてるプログラムとか普通にあって完璧凍ったスパゲティ状態です。別言語に移行するなんて怖くてできない。 それやる気概があるような人は転職を選ぶね。
0
ばしにぃ @hiro_orso_viola 2014年12月26日
技術を発展させるのは実務としての実装じゃないからねぇ。むしろ実績も証左もない最新技術をおいそれと基幹系に適用できるわけがない。
12
んぱんぱ @crayonmarch 2014年12月26日
MC6809EOS9 どのような言い訳を述べようにも、事務系のプログラマーが転職できないという現実は変わりませんし、それは技術的な孤立を意味することで、人権的にもいろいろな意味でも問題だと思うけど、目的さえ果たせば未来永劫それで良いとは思えませんが。やる気がなかったら他の企業も技術の提供に消極的になるのでは?
0
んぱんぱ @crayonmarch 2014年12月26日
新しい技術がスパゲティという愚か者は評価の高いオープンソースを見たらどうよ?悪いものしか見ていないからだろう。リスクを犯したくない気持ちはわかるが、永遠にこのままで良いのか?技術の格差はいずれ大問題につながるぞ。
0
んぱんぱ @crayonmarch 2014年12月26日
ところで、他人のソースをすスパゲティと批判するからには、自分達の金融系のソースコードに胸を張って公開できるって人はいるんだろうか?まあ特性上公開するのは無理があると思うけど、公開しても恥はないかどうかって事だけを聞きたい。
0
しろがねさん @whitebellsweet 2014年12月26日
いや、その導入コストは客に跳ね返るんですが(´・ω・`)企業はボランティアではありません。
14
fukus @fukus 2014年12月26日
ビジネスロジック書く担当プログラマが、ビジネスロジック以外の事を考えないで済むからじゃね?
2
んぱんぱ @crayonmarch 2014年12月26日
ボランティアじゃないってそんな言い訳通じないだろ、他の業務やってる企業も同じだろwだったらオープンソースで有名なGoogleもボランティアなのか。
0
むささび屋(,, -`x´-) @Josui_Do 2014年12月26日
銀行は誤差とミスが出せない企業。基幹に障害が起きたら莫大な損害が銀行だけでなく融資を受けてる人や企業にも。企業が倒産して路頭に迷ったり自殺する人が出る。そのリスクが取れるならシステム移行もいいのでは?
15
んぱんぱ @crayonmarch 2014年12月26日
現実問題として、事務系の低スキルのプログラマーが勝手に市民権を得たおかげで、高スキルまたは高スキルを目指すプログラマーが仕事を奪われる結果の責任はとってくれるのだろうか?本当に頭にきているのはそこだけど。
0
んぱんぱ @crayonmarch 2014年12月26日
君たちのお陰で路頭に迷ってもおかしくはないし、何度も自殺を考えた。結果を出す努力をした人がこうやってバカを見る現実を創りだしたのは貴様らだ(怒)
0
Hide Yamauchi @MC6809EOS9 2014年12月26日
.crayonmarch 今、COBOLをMFのために書いている人が転職する必要はないでしょう。なぜなら、現状のシステムを維持する需要は十分にあり、定年を迎える人たちの穴を埋めるため人員を確保するのは経営者にとって必要な検討事項です。真新しい技術を追いかけるだけが職業を選ぶ上での全てではありません。
10
んぱんぱ @crayonmarch 2014年12月26日
MC6809EOS9 それは企業側の都合であって、労働者側の都合ではないだろう。転職の自由がなければ、労働者の人権が脅かされるリスクが極めて高いですが、待遇を保証できる組合体制は万全なのですか?そもそも組合ありますか?
0
Hide Yamauchi @MC6809EOS9 2014年12月26日
.crayonmarch Googleがどのようにして利益を上げているかを考えれば、OSSに協力している理由もわかるでしょう。それは決してボランティアではなく、彼らの経営戦略の一部です。また、Googleが使っているのはOSSだけではありません。たくさんのクローズドなものもあります。
11
んぱんぱ @crayonmarch 2014年12月26日
MC6809EOS9 そもそも日本の場合は逆の問題も存在する。高スキルのプログラミングの給与が低く、低スキルのプログラミングの給与が高くなる危険性。これは市場原理を破壊する重大な問題だ。金融系が市場を破壊するなど言語道断ですよ。
0
んぱんぱ @crayonmarch 2014年12月26日
MC6809EOS9 私が言いたいのは、オープンソース自体がボランティアであると批判されることに対する皮肉です。当たり前だけどオープンソース自体もボランティアではない。
2
Hide Yamauchi @MC6809EOS9 2014年12月26日
.crayonmarch 転職の自由は誰にでもあります。米国の雇用契約の多くはそうなっています。それをどのように行使するかは状況を判断して本人が決めることです。もちろん、レイオフなどもあるので、その時に備えるかどうかは本人の意識にかかっているでしょう。誰かが助けてくれるなどといった甘い話はありません。
8
んぱんぱ @crayonmarch 2014年12月26日
MC6809EOS9 スキルの低い現場の人に甘えと言われる筋合いはないわ、喧嘩売ってるのか?それにアメリカのプログラマーの給与は平均的に二倍以上だ、日本とは全く違う。
0
Hide Yamauchi @MC6809EOS9 2014年12月26日
.crayonmarch 米国では組合の力はどんどん弱まっています。なぜなら、組合によってもたらされる不利益の方が大きいからです。そもそも、ソフトウェア業界で組合があるところはほとんどないでしょう。
8
Hide Yamauchi @MC6809EOS9 2014年12月26日
.crayonmarch スキルは誰かに与えられるものではありません。また、必要とされるスキルは様々な要因によって違っています。MFのCOBOLのスキルも業種によっては必要とされるものです。スキルの高い、低いといった議論はコンテキストが必要です。
9
んぱんぱ @crayonmarch 2014年12月26日
MC6809EOS9 誰もスキルが与えられるとは申していないし、君らは勘違いしているようだけど、他の分野の人が言いたいことは、オブジェクト指向が高スキルと言いたいわけでもないよ。オブジェクト指向も設計思想の一つに過ぎず、問題はそこじゃない。そもそも他分野は言語が複数扱えて当たり前です。
0
Hide Yamauchi @MC6809EOS9 2014年12月26日
.crayonmarch 米国の給与は確かに高いかもしれませんが、社会保障などを考えればそれほどべらぼうな金額ではないでしょう。また、職を失う可能性は日本よりも高いかもしれません。米国で働くことはきちんとした技術があれば不可能ではないでしょう。
7
Hide Yamauchi @MC6809EOS9 2014年12月26日
.crayonmarch 他分野がどの分野かはよくわかりませんが、DBAなどは基本的に単一言語とか処理系ですよね。しかし、能力の高いDBAの人は必要とされます。ですから、複数言語が扱えて当たり前ではなく、分野によるのではないでしょうか。そして、職があるかどうかは需要と供給に大きく左右されるでしょう。
8
んぱんぱ @crayonmarch 2014年12月26日
MC6809EOS9 誰もアメリカの給与がべらぼうとは申していません。低すぎる日本の方が異常です。日本の金融系は電子マネーに仕事を一部奪われる可能性があると思うけど、絶対に行政支援の規制に頼ったりしませんよね?市場原理に逆らって規制に寄与したら甘えだと批判するよ。日本では貧困が原因でクレジットカードが嫌われている。
0
んぱんぱ @crayonmarch 2014年12月26日
MC6809EOS9 ちなみに、日本では職を失う前に、過労死で死ぬのが先ですよ。過労死のほうがはるかに悲惨だよ。
0
んぱんぱ @crayonmarch 2014年12月26日
MC6809EOS9 その需要と供給をぶち壊しているのはどこのどいつだって話をしているのだが?労働力の過剰供給で市場原理が崩壊し、人が育つ環境も破壊されたんだよ。だから日本のソフトウェア産業は壊滅状態だよ。もう二度とアメリカには勝てないよ。勝てる理由が皆無だ。
0
Hide Yamauchi @MC6809EOS9 2014年12月26日
.crayonmarch そうですか?世界規模でみればソフトウェアの技術者は不足しています。http://ow.ly/Gr6OB http://ow.ly/Gr6Wo そして、西海岸で仕事をしている人は以前より増えたはずです。日本が負けたとか、米国が勝ったとかいう話にはあまり意味を感じません。
8
んぱんぱ @crayonmarch 2014年12月26日
MC6809EOS9 私は日本の話をしているんですよ、アメリカのソフトは強くて当たり前。日本は強いどころか、途上国同然にまで叩き落とされた。加害者には罪の自覚がなくて当たり前だろうけどね。その証拠に世界に流通した日本のソフトウェアって存在するのか?全部ハードウェアだぞ。
0
VRAM01K @VRAM01K 2014年12月26日
技術者個人の話であれば、向上心持ってスキルアップする人も当然いますが、それは担当できるプロジェクトの幅を広げるためですね。金融系がレガシーシステム使い続けることとは関連ないと思います。
8
Hide Yamauchi @MC6809EOS9 2014年12月26日
.crayonmarch 最初に米国のCOBOLの技術者の転職の話をされたのは?別にどの国が強いかなどはあまり意味がないように感じますが。たとえば、米国のソフトウェアの企業はインドやヨーロッパなどでも開発をしていますから、どこからのソフトウェアという議論は意味がないでしょう。もし、日本発祥であるとすればRubyなどはそうですね。ハードウェアは世界的に見れば日本製って少ないですよね。
11
Hide Yamauchi @MC6809EOS9 2014年12月26日
.VRAM01K そうですよね。いい加減、まとめの本筋からは離れすぎたと思っています。
7
んぱんぱ @crayonmarch 2014年12月26日
MC6809EOS9 どこまでも頭が硬い人だな…なんで最初から最後までアメリカの話になるんだよ、日本語圏で日本の話をするのは当たり前だろう?貴方がどこにいるか知りませんが、日本語圏で話すなら、中心は日本だろう。ちなみにアメリカのソフト企業は本社はアメリカ以外ですか?違いますよね。日本製ハードで言えば、日本車がアメリカ経済の脅威ですよ、昔から。家電もソニー製だらけ。
0
んぱんぱ @crayonmarch 2014年12月26日
極論を言えば、世界に流通する日本のソフトウェアはゲームしか存在しない。世界に認められた日本のプログラム言語はRubyしか存在しない。たったこれだけじゃないか…
0
kartis56 @kartis56 2014年12月26日
メインフレームでruby使えってのかすげぇなおい
2
裏技君 @urawazakun 2014年12月26日
COBOLの使える技術者と意識してdecimalを使い始めた技術者なら後者の方が多く用意出来るだろうし精度的にも後者のが圧倒的に高い(最悪doubleをdefineしてdecimal、long decimalに置き換える荒業もある)。多分問題になってるの移行する為のフルスタックエンジニアが足りないってだけだと思うし、さっさとガンガン死人出してでもシステム移行した方が良いと思う
0
しろがねさん @whitebellsweet 2014年12月26日
なんだ、出羽の守か(´・ω・`)解散。
0
@sbayasi 2014年12月26日
門外漢が口を挟むのもおこがましいのだけれども、銀行のシステムがダウンし入出金振込ができなくなった場面に出くわしててヒヤヒヤした経験を持つ身としては、余程のメリットがない限りは新しかろうが遅れていようがどっちでもいいから実績があり安定したもので運用してくれってのが利用者としての本音。無論、言語やソフトに限った話ではないんだけどね。
10
んぱんぱ @crayonmarch 2014年12月26日
kartis56 Ruby使えとは一言も言っていない。金融系のプログラマは被害妄想する人しかいないのですか?
0
ばしにぃ @hiro_orso_viola 2014年12月26日
補償のないオープンソースのLinuxより有償でもサポートと責任の所在が明確なRedHatが選ばれる。…っていうか、ホストはともかく今や銀行の基幹システムでも本番環境をVMWareの仮想サーバで構築してるし。そもそも基盤の話に「プログラマ」が出てくるとか(ry
0
angel as ㌵㌤の猫 @angel_p_57 2014年12月27日
基幹系のために、ハードやOSの信頼性を重視してメインフレームを使うという話と、業務プログラムをCOBOLで書くという話がごっちゃになっている気がするけど。コンパイラを含めた処理系は枯れて信頼性がある(対してrubyなんかは論外)のかも知れないけど、COBOLという言語自体の優位性とは関係ないよねえ。
6
angel as ㌵㌤の猫 @angel_p_57 2014年12月27日
COBOLの優位性って何だろう…。メインフレームOS独自のファイル(ファイル自体がプチDBのようなもの)に即したデータ構造を記述できるところだろうか。別に十分な抽象化がされたライブラリが用意できていれば、COBOLである必然性はなさそうだけど。
2
angel as ㌵㌤の猫 @angel_p_57 2014年12月27日
逆に表現力や生産性から見ると、COBOLって大きく見劣りするので、「COBOLだから良い」というよりは「COBOLでもなんとかなる」というだけなんではなかろうか。全体最適化を考えるとCOBOLを捨てるのがベストだと思うけど、あまりにインパクトが大きいだろうから、局所的な解として「技術者を細々と確保する」が選ばれるのかな。単なる問題の先送りにも見えるけど、まあ、COBOLに限った話でもないし…
6
Hide Yamauchi @MC6809EOS9 2014年12月27日
まとめには関係ありませんが、ここから派生したことなので一応書いておきます。@crayonmarch 氏から以下のような脅迫と殺害予告をいただきました。 http://bit.ly/1zFDd01 http://bit.ly/1H2G8Rp http://bit.ly/1tlTmGq http://bit.ly/1BcEysq http://bit.ly/1vxn1Yi Twitterには通報済みです。
10
きゃっつ(Kats)⊿ @grayengineer 2014年12月27日
「銀行は誤差とミスが出せない企業」これはおかしいな。医療系とか航空管制とか、財産どころか人の命に関わるようなシステムもあるが、それらのシステムは別にメインフレームでもCOBOLでもない。単に金融系はそれでスタートしたからリプレイスできずに今まで残っているにすぎない
2
きゃっつ(Kats)⊿ @grayengineer 2014年12月27日
しかも記憶に新しい、みずほ銀行の統合時のシステム障害みたいなこともあるわけで。ミスを出すのは言語や環境ではなくてそれを扱う人や組織でしょう
2
高千穂 伊織 @t_iori 2014年12月27日
技術(言語仕様)的問題以上に、政治とか金とかの問題が巨大なんじゃないかな……c⌒っ´・ω・)っ
0
Lyiase @lyiase 2014年12月27日
…えっとCOBOLってぶっちゃけ絶滅危惧種なような。 最近はメインフレームも含めて徐々にJavaに移行しているからなあ。BigDecimalで出来るからねえ。 って言うか、x87は拡張倍精度使えるから精度の問題は他のCPUに比べると少しマシなんだけどね。
0
くわたろ @kuwataro 2014年12月27日
他言語の人、COBOLが簡単だというならCOBOL「も」勉強してください。実際、固定長データっていう意識に慣れれば簡単だよ。COBOL「も」できるそれだけで金融系から仕事くから。
8
まーねこ @marnekochan 2014年12月27日
コード書くことしか出来ませんっていう人は本当にダメなんだけど、COBOLできますっていう人、だいたい業務に長けてる人が多いから要件定義、基本設計から入れるんよ。いわゆる「頭から入れて手も動きます」っていうやつ。だから飯の食いっぱぐれは無いの。コードしか書けないって人は、そんなスキルは大陸にゴマンと居るので、とっととスキルアップか転職にはげんだほうがいい。
4
頭文字爺 @initial_g3 2014年12月27日
しがらみだとかの「コンピュータの外」の「システム」にも目を向けるべき案件。金の使い方に関して厳しい監査の下に置かれてる銀行は、そうすべき確固たる理由が無ければ置換のコストを払わない。COBOLからの置換で余計なコストが一切かからないor置換しなければならない理由が必要。
4
大石陽@聖マルク @stmark_309 2014年12月27日
置き換えるのが望ましいのはそりゃそうだが、規模も大きいし、業務もシステムに合わせて組織化されているし、今動作に問題が生じているわけでもないから、何千万、何億とかけて完全にシステムを一新するとなると他の投資先と比べて優先度が下がる。よっていつまでもCOBOLに継ぎ足し継ぎ足しで運用されることになる。
3
脳内がエロで埋まっている白痴のネトウヨ @dokuman3 2014年12月27日
COBOLから他言語に置き換えるメリットって何なの?って話じゃないの?趣味でやってるならともかく仕事でやってるならメリットも無しに置き換えたりはしないだろ。他言語に変えるってのは手段であって目的じゃないんだから。
10
Yoshiteru Kawai @yoshikun2009 2014年12月28日
日本にかぎらず世界的にCOBOL残存ということは世界共通の理由があると考えたほうがいい。
7
ITDOREIKUN @ItDoreikun 2014年12月28日
枯れた技術で維持できる分野に対し更新をかける。コンサルのチャンス!!
0
ITDOREIKUN @ItDoreikun 2014年12月28日
障害発生率と原因究明コストと予防保全対応と開発コストあたりが優れているげんごかんきょうを提示するだけのかんたんな案件じゃないですかー
0
ITDOREIKUN @ItDoreikun 2014年12月28日
枯れたASMで技術者不足からの高騰->開発コスト下げるためc言語での提案->遅すぎてわろす->そうだアセンブリ言語があるじゃないか!! というPJ経験がありますが、まぁなんとなく思い出しただけです
1
ubunrar @ubunrar 2014年12月28日
やっぱ言語仕様だろ。COBOLで普通に計算してりゃ1円の誤差も出ない。CやJavaの言語仕様ではマヌケなプログラマが一人でも居たら町工場のオヤジの首が飛ぶ。
1
ubunrar @ubunrar 2014年12月28日
C,Javaでも適切な計算ライブラリを使うよう徹底できりゃいいんだが、必ずミスは発生する。「コーダー一人一人が気をつければいい」「コードレビューで検出すればいい」とか言い出すSEは信用しない。
4
まーねこ @marnekochan 2014年12月28日
あのー、保険でも営貸でもリースでもなんでもいいんですが、計算仕様が機能要件としてあって、それの基本設計書いて、詳細設計書いて、コード書いて(自動かもしれんが)、PTやってITやってSTやって、おうちに帰って初めて遠足なんじゃないですかね。これだけのコストをCOBOLと多言語で比較するまでも無いと思うんですが。(ビジネスロジックをそのまま設計(コード)に倒せる言語のほうがお金がかからないってことですよ)最初からオープン+COBOLで作った金融システムだってゴマンとありますよ。
1
angel as ㌵㌤の猫 @angel_p_57 2014年12月28日
えーと…。いやあの、COBOLにはCOBOLなりのウリがあるだろうことを否定する気はないのだけど、それをライブラリレベルでなく、言語のネイティブ機能として取り入れる必然性があるのかなあ、と。そういう話だと思う。そのためにニッチ化して技術者不足が~とか言うのであれば、何か間違えているよなあ、と。
2
angel as ㌵㌤の猫 @angel_p_57 2014年12月28日
私は若い頃Pascalの次にCOBOLを勉強していたんだけど、ゴテゴテ書く割に処理できる内容が薄すぎて、続ける気を無くしたんだよね…。情処試験が終わったら捨てた。対照的に Fortran、科学技術計算という土俵では、ちゃんと言語として選ばれるだけのワケがある ( 勿論、C/C++あたりでも書けるにしても ) し、今でも使ってる。
2
かえでこ @KaedekoSakura 2014年12月29日
COBOLのプログラムでやったレベルの完全なテストを行って、完全な置換を行う(そのコストを誰が負担するかはおく)のならば、別段COBOLに拘る理由はないと思うよ。金融系で、車輪の再発明が行われるのは、「テスト(認証・認証)の影響範囲を小さくするため」だからね。
1
かえでこ @KaedekoSakura 2014年12月29日
馬鹿なと思う御仁もいるだろうが、オブジェクト指向のようなモジュールを作ったとして、その影響を受ける処理が多数存在するなら、「その全てで試験を行う」のが金融系だからね。モジュールとしての単体テストが成立してれば他もOKなんてIT屋の理屈は、上層部には通じないし。
1
こぎつね @KogituneJPN 2014年12月29日
コボルで書かれてるのはソロバン勘定を電子化したような部分なので、数字があってることが大事でパフォーマンはそんなに求められてないと思う
0
こぎつね @KogituneJPN 2014年12月29日
よく言うように銀行は一円の誤差も許さない。一般企業のように多少の誤差は許容した方が効率があがるという考え方は取らない。銀行が15時に閉まるのはお金の帳尻をきっちり合わせるのに時間が掛かるからなんだよ・・・
2
angel as ㌵㌤の猫 @angel_p_57 2014年12月30日
え? 銀行以外の一般企業って、効率のためなら多少の誤差を許容するの? KogituneJPN 一般企業のように多少の誤差は許容した方が効率があがるという考え方
0
かえでこ @KaedekoSakura 2014年12月30日
angel_p_57 帳簿にExcelを使っていると、「多少の誤差」が出るかもしれません。でも、そこまでピリピリと演算結果に目を尖らせて、Excel使った人を叱責するオフィスって、ほとんど見ませんね。金融系でも現場の人には普通にいそうですが。/基幹システムが多少使い辛くてもそれを使うのは、「入力が正しければ結果が正しい」をシステムに求めるからです。そして、軽々と変更できないのは、その結果責任を負うから。
0
大石陽@聖マルク @stmark_309 2014年12月30日
KaedekoSakura 帳簿程度ならExcelでもいいけど、実際の会計上の計算まで全部Excel上でやってるオフィス自体がまずほとんどないんだから、それで怒られる事例はそれよりさらに少ないのは当然ではないだろうか。
0
こぎつね @KogituneJPN 2014年12月30日
angel_p_57 一円あわなかったとき、銀行みたいに合うまで支店全員で残業するなんてことは一般企業はしないんじゃないでしょうかね。
0
angel as ㌵㌤の猫 @angel_p_57 2014年12月30日
KaedekoSakura 「入力が正しければ結果が正しい」って銀行に限らずアタリマエだと思っていたのだけど違うのか…。求められないシステムが、銀行以外でそこそこあると? KogituneJPN それはボケているのか、素で寝言を言っているのか判断し辛いので、反応に困る…。
0
angel as ㌵㌤の猫 @angel_p_57 2014年12月30日
うーん。アレかなあ。「誤差」に対するイメージの問題なのか。「何か知らんけど計算結果が不正確なんだよ」とか。英語なら…“error”か。言い換えても余り変わらないね。ひょっとして科学技術系の計算をやってないと、意識することがないのかなあ?
0
こぎつね @KogituneJPN 2014年12月30日
angel_p_57 バグは必ず発生するし、実機上では計算誤差も起きるってのは現実だとおもうんですよ。バグを起こさない、という考えがどれだけ強固に持っているか考えたら銀行ほど偏執狂的な業界はないかと
0
こぎつね @KogituneJPN 2014年12月30日
angel_p_57 合っててアタリマエみたいな生易しい感覚じゃなくて、間違いを外に出しては絶対にいけないんです。心構えとかの話ではなく文字通り出してはいけないんです
0
エセ賢者 @MulticolorWorld 2014年12月30日
COBOLと同等の精度でCOBOLと同等の計算速度が出せるDecimal型持ってる言語ってあるの?銀行のレガシー環境を批判する人でそれ以外への移行先示せてる人が殆どいない気がするんだけど。
2
こぎつね @KogituneJPN 2014年12月30日
angel_p_57 angel_p_57 バカにされてることに気づかずに真面目に答えてしまいましたけど、フツー1円ごときのために人件費を何万円も使うかって話ですよ。現金化不足の勘定(使途不明金)はなんのためにあるんですかね
1
s_doi @s_do_i 2014年12月31日
外の人から今の金融・公共システムのCOBOLによるシステム開発がどう見えるか、という点勉強になるまとめでした。
0
んぱんぱ @crayonmarch 2014年12月31日
粘着行為やらかして被害妄想垂れるアホがいるわ、何が通報だ、だから粘着する屑は嫌いなんだよ。二度とつら出すなボケ。
0
NiKe @fnord_jp 2014年12月31日
『COBOLでなくても十進演算は普通にできるのに』ということみたいですが、デフォルトの演算が十進になってる言語は珍しいんじゃないでしょうか。
1
Hide Yamauchi @MC6809EOS9 2014年12月31日
アホで屑でボケですが、本題の方の話で言えば銀行が60、70年代あたりでRASを考慮したら汎用機で、その上で事務屋さんが固定長のデータや帳票などを含んだ業務のソフトを割と楽に書くにはCOBOLが適していたってこと。気がついたら膨大な量の資産ができていて、書き直すためのコストよりも維持するコストの方が安いから使っているのではないかな。
5
Hide Yamauchi @MC6809EOS9 2014年12月31日
もちろん、今から、別の環境でスクラッチから書くのであればもっと別の選択肢はあるだろうけど、それにしたって銀行の場合には行政の規制や指導などの外部要因もあるから結構大変のはず。実際に使えるかどうかはわからないけど、.NET系の言語とLINQの組み合わせなんてのは割といけるかもしれないと思ったりする
1
Hide Yamauchi @MC6809EOS9 2014年12月31日
一番の問題は要求を満たす性能が出て、なおかつ信頼性が高くなければいけないことかと思ったりする。
1
Hide Yamauchi @MC6809EOS9 2014年12月31日
ちなみに金融系といっても業務が違えば、使う言語や環境は随分違う。金融系の一部でNeXTSTEPが使われていたのは割と有名な話。また、関数型の言語を使っている金融系の人も結構な数はいると思う。
1
こぎつね @KogituneJPN 2014年12月31日
MC6809EOS9 私は関係者じゃないので全くの想像なんですけど、ちょっと書き間違えたら金融庁さんや日銀さんらお叱りが文章でできて、いろいろお返事書かかないといけないらしいことをネットとかで見ると大変だなぁあと思います
0
Hide Yamauchi @MC6809EOS9 2014年12月31日
KogituneJPN 私も直接の関係者じゃないのですが、聞いた話だとソフトウェアのパッチやバージョンの変更は大変な作業だというのは聞いています。おかげで古いソフトウェアをできるだけ使い続けることになってサポートの方が大変だとか。
0
angel as ㌵㌤の猫 @angel_p_57 2015年1月1日
MulticolorWorld 演算性能は「現在は」気にする所ではないからだろうね。フツーに。
0
エセ賢者 @MulticolorWorld 2015年1月1日
angel_p_57 それを気にしなければいけない時代に出来たものなので現在COBOLで動いているのでしょう。そして、現在ちゃんと動いているものを別の言語やフレームワークに置換するだけのメリットがあるか?という話になります。
2
angel as ㌵㌤の猫 @angel_p_57 2015年1月1日
KogituneJPN 「バカにされている」と言うより、ピントがずれている事を言ってたらそのように評価されるということだけかと…。「実機上では計算誤差も起きるってのは現実だとおもう」って…。メインフレーム/COBOLは誤差を起こさないハード/言語で、それ以外は違うって、そういう印象で語られても…ねえ。
0
angel as ㌵㌤の猫 @angel_p_57 2015年1月1日
KogituneJPN 取り敢えず、ちょろっと書いたけど、おそらく「誤差」に対する認識が不適当だろうし、その、業界としての会計処理の厳格さと、システムを構築するための言語の特徴の話をごっちゃにしているのがねえ。それともソフトウェア品質の話として、COBOLが群を抜いて高品質にできる言語だと主張するのなら話は別だけど。( それはそれで感覚を疑う所としても )
0
angel as ㌵㌤の猫 @angel_p_57 2015年1月1日
御意。メリット云々は業界の判断次第でしょうが、上で意見は出尽くしているかと。MulticolorWorld それを気にしなければいけない時代に出来た
0
angel as ㌵㌤の猫 @angel_p_57 2015年1月1日
何となく思うのだけど、「誤差」のことを「バグ」の一種だと思っている人がいるのかな。だとしたら違うからね、と。( 「誤差」の取り扱いが不適切だとバグになるけど )
0
MJ @jaguarsan_jp 2015年1月2日
COBOLならバカがコーディングしても誤差は起きない。とか胸を張られても、そりゃ誤差は出ないけどバグは出すんだから開発に関わらせるなよ...
1
かえでこ @KaedekoSakura 2015年1月3日
これさ、みんな「問題にしてる事象」を意見によって切り替えているから、はなし絶対噛み合わないよね(突っ込むために状況を再定義するから)
4
かえでこ @KaedekoSakura 2015年1月3日
そりゃ、基幹システムはどこもちゃんとテストするだろうよ。その「ちゃんとテスト」を、既存のCOBOLシステムレベルで行って、金融絡みのオンラインシステムを置き換えるかって言ったら、やらんだろ普通。よほどのメリットが無けりゃ。
3
しろくろきつね @skn9x 2015年1月17日
COBOLを銀行系のDSLとして再定義する時代が来たんだと思っている
0
cocoon @cocoonP 2015年3月5日
なんか「事務系の低スキルのプログラマーが勝手に市民権を得たおかげで、高スキルまたは高スキルを目指すプログラマーが仕事を奪われる」とかおっしゃっているお脳の残念な方がお沸きになっている様だけど、その「低スキルのプログラマーに仕事を奪われる」程度の人は高スキルではないのでは? 低スキルでなければならない職場なんて無いんだし。
4
cocoon @cocoonP 2015年3月5日
で、ぼくは「ある銀行がもうCOBOLの時代じゃないと言ってシステムのフルスクラッチに踏み切ったけどやっぱり想定外のトラブルはおきて1ヶ月間自分の預金が引き落とせなくなったどころか決済も失敗して実害が出た」とかだったら間違いなく怒るので、たんじゅんな好みとかポリシーの問題で冒険してほしくないです。
6
シエル @ciel_mess 2015年10月14日
メインフレーム+COBOLの何がすごいかって、OSやコンパイラの不具合がほぼないことだと思う。わざわざトリッキーなことをする人も少ないし。
0
五号館大教室の海賊 @bd089p 2016年7月16日
数千万件オーダーのデータをチューンナップしなくても高速に処理できるって言っても世の中その程度のユーザー数のサービスはいくらでもあってそれらはCOBOL以外でも動いてるじゃん?あまり強力な理由づけにはならない気がするけど……。
0
りおりおすと@CANYON乗り @rioriost 2018年11月30日
IBMの10進演算ユニットがやはり挙げられる話題だよな、と思ったw
0