ikasamt回答ポイント 100pt

プログラミング言語や環境について詳しい方に質問です。

これほど多種多様な言語があり進化しているにもかかわらず「銀行などの大規模システムの仕組みは日本においてはcobol等で
為されている」という話を時々聞きます。でも大抵頻繁にメンテナンスをし夜中に止まる全く枯れてないシステムでもあると思うのです。しかも予算がベラボーに高い。100億とかって言いますよねよく。理由を聞いてみると以下の４つを良く聞きます。

１．高負荷のトランザクション処理が出来る =>コボルの性能と言うよりも動作させているマシンの性能では？またアルゴリズムさえ同じであれば言語は関係あるのか？
２. 言語が英語に似ていて分かり易い => 可読性が高いとは思えない
３．デファクトだからライブラリなどの資産がある => 少しずつ書き換えられないほど密結合なのか？
４. 複数人での大規模開発に向いている => 数百人とかのプロジェクトは問題のスコープの範囲を間違えているのでは？数人×100プロジェクトとかに切り分けるべきなのでは？

各々の=>以降は僕の感想です。
些細なことでもかまわないので、回答よろしくお願いします。

※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

ログインして回答する

ベストアンサー

takano322009/07/27 11:21:24
満足20pt

結論から言えば書き換えたほうがよい、です。書き換えられない理由がいろいろあります。先に述べられている回答もそれぞれがそのひとつです。

要点をまとめると、書き換えるコストとハードウェアをリプレイスするコストを秤にかけ、サービスとソフトウェアとハードウェアの寿命を考えた上でも書き換えたほうがよいと結論を出したところはすでに書き換えています。

ソフトウェアの費用が高く、ハードウェアのリプレイスで延命でき、サービスの拡張も大幅にすることがないようなシステムではCOBOLのまま多少高価でもハードウェアをリプレイスすることになります。

スター
- ikasamt 2009/07/27 20:38:54
  
  回答ありがとうございます。
  
  参考になります。
  
  想像になってしまい申し訳ないんですがソフトウェアは人件費や電気代と同じ費用なのに会計上、
  
  資産に計上出来てしまうことも関係しているような気がします。
  
  例えば、
  
  ・リプレースにかかる費用：１０億
  
  ・リプレース後の保守費用：１億/年
  
  ・既存のシステムの累積制作費：1000億
  
  ・既存の保守費用：10億/年
  
  という状況があったときに、既存のシステムを捨ててしまう方が純粋なコストでも生産効率でも最良の選択肢だったとしても、リプレースすると資産計上している1000億の項目が一気にゼロ円になってしまい、会計上(対株式市場上)悪いからという判断がなされてしまいそうです。

その他の回答

yofukaci2009/07/24 20:46:38
満足20pt

こんばんは、ikasamtさん。

最近は銀行のそういう大型システムでも、Javaに移行しつつあります。

＞１．またアルゴリズムさえ同じであれば言語は関係あるのか？

言語的な制限で、CobolとかJavaはアルゴリズムも制限されて誰が書いてもほぼ同じになるので、管理する側は都合がよいのです。

＞３．デファクトだからライブラリなどの資産がある => 少しずつ書き換えられないほど密結合なのか？

アマゾンの奥地と同じぐらいなので、障りたい人なんていません。触ったら、どんなにがんばっててテストしても、本番で障害がでます。

＞４. 複数人での大規模開発に向いている => 数百人とかのプロジェクトは問題のスコープの範囲を間違えているのでは？数人×100プロジェクトとかに切り分けるべきなのでは？

1と同じです。

スター
- ikasamt 2009/07/25 00:20:53
  
  ＞(1)言語的な制限、(4)大人数
  
  トリッキーなことが出来ない＝誰が書いても大差ない、は重要ですね。ただ他の言語でも開発者間の意思疎通がとれていれば書き方や設計思想の違い等が乖離することもないと思っちゃいます。誰が書いても同じだけど冗長なcobol/javaを選ぶか、コンパクトだけど書き手のテクニックを必要とするpythonやrubyやscalaなどのモダンな言語を選ぶかは、判断が分かれそうですね。
  
  ＞(３)ライブラリがジャングル
  
  ムムムー。単体テストやちょっとした結合テスト程度で判明しないってことは、もしかしてグローバル変数とかポインタ参照とかやりまくってるんですかね。それだとリファクタリング不可能ですね。でも、機能別にアプリケーションが分かれていれば、I/Oさえ同じだったら可能ですよね？
  
  具体的な仕様やソースを観たことが「皆無」なので「銀行系システム」ってのがどういう仕事をするどんな仕組みの物なのかほとんど分かってないのが口惜しいです。
  
  大変ありがとうございました。
  
  参考になりました。
  
  ほかにも全体の仕様や構成を詳しく説明できる人がいれば回答お願いします。

jccrh12009/07/24 22:12:32
満足20pt

COBOLはレガシーな言語ですが、なかなか良い言語だと思います。

なぜ、未だに使われているかについては単純に過去の資産を継承しているからだと思います。

COBOLが使われる理由は以下の通りだと思っています。
　
・本来プログラム仕様書があってプログラムが正しく動作しているはずです。
　しかし、プログラムをメンテナンスしていくと仕様書が古くなり齟齬がおきていることが多いと思われます。
　よって、他言語への移行は難しいし、仕様書を作り直すことも費用的に不可能に近いと思われます。
・他言語への移行ができてもテストも入れると開発期間・費用がかかるし、稼働しても問題が起きる可能性
　がかなり高いと思われます。
・処理はオンライン系よりバッチ系が多いので、COBOL言語が最適と思われます。
・命令がかなりシンプルで誰が作成しても、見やすいプログラムになります。
・COBOLはCOBOL85等、言語仕様が明確で、他言語のようにローカルな仕様はほとんどないです。
・まだかなりのコボラーがいるので、開発要員を多く集めることができます。

確かに凄い費用を掛けて対応しますが、バグが出ると社会的に問題があるので、十分テストをするので費用が掛かるのはやむを得ないと思います。

４つの理由とのことですが…
　
１．高負荷のトランザクション処理が出来る …
　　それはないと思います。C言語とか他言語の方が処理効率も高いと思います。
　　単純にメインフレームであるハードウェアの性能で問題ない稼働を実現していると思います。
２．言語が英語に似ていて分かり易い…
　　英語というより、命令や言語がシンプルなので可読性は高いと思います。
３．デファクトだからライブラリなどの資産がある …
　　レガシー言語なので過去のモジュールは品質が高く整理されています。
　　ただ過去の資産というだけで、ライブラリの作り良さ…は感じられないですね。
４．複数人での大規模開発に向いている …
　　特にそういうことはないです。今は大規模開発のために開発環境管理（VisualSourceSafe,CVS)
　　やプログラム共同開発ツールは進んでいると思います。

以上、私の経験からの勝手な意見です。

スター

ikasamt 2009/07/25 00:22:28

ありがとうございます。

大変参考になります！

知らない事ばかりでうれしいです。

・オンラインよりもバッチ処理が多い（知らなかった！）

・可読性は高いのは事実。シンプルで見やすい。

・ライブラリ設計や処理速度が優秀ではなく、資産だから（惰性）

・仕様が枯れている

などの理由ということでしょうか。

＞コストの問題

お金をかける前にたとえ遠回りでもゼロから再構築してユニットテストが通ればOKの状態にすればいいのに、と思ってしまいます。１０億あれば隠れ仕様も含めて書き出せないでしょうかね。

ほかにも、ざっくりとした仕様（例えば銀行間、支店間の口座のお金の動きはこういう処理で、ACIDはこうやって維持されている）みたいなのご存知でしたらお願いします。

ksh2009/07/25 03:07:15
満足20pt

＞１．高負荷のトランザクション処理が出来る

COBOLでは他にはない実績のあるフレームワークがあるということですよね。

「高負荷のトランザクション処理が出来る」けど実績がない、ではクリティカルなシステムでは使えません。

＞２. 言語が英語に似ていて分かり易い => 可読性が高いとは思えない

慣れの問題ですよね。どれだけ精通しているか。

新しい可読性の高い言語が生まれても、言語をとりまく開発環境が充実していなければ使えません。

環境はあるけど実績がなくて「作ってみたけどだめでした」は大規模システムでは使えません。

＞３．デファクトだからライブラリなどの資産がある => 少しずつ書き換えられないほど密結合なのか？

正直、言語そのものよりライブラリが充実しているかどうか、のほうが重要ですね。

実績というのは得難い資産です。

＞４. 複数人での大規模開発に向いている

これは単純に Java とかのほうがよくなってきているかもしれません。

一度できあがった大規模システムを変えるには時間がかかります。

今でも部分的には（例えば一部のサブシステムはJavaとか）変わってきている部分もあると思います。

あと、コメントに書いてあった部分について

＞WEB屋だと同じかそれ以上のことが１００分の１の予算で出来るんだぞということを証明してみたいという夢があり

いわゆるLAMPなシステムで同じようなシステムを作るのは低価格で可能と思います。

が、いろんな意味で信頼性を保証するのが難しいと思います。

仕様書に載ってない仕様をどうやって見つけて新システムで再実装するのか、とか

Linux で Kernel Panic が起こったら原因解析して再発防止の修正パッチ作れるか、とか

個人的には古いものは古いものにまかせて、新しい技術で新しいものを作るのが

よいのではないかと思ったりします。

スター

ikasamt 2009/07/26 01:01:34

回答ありがとうございます。

大変参考に成ります。

＞古いものは古いものにまかせて、新しい技術で新しいものを作るのがよいのでは

大抵の場合賛成ですが、現状の銀行システムの場合コストのかかり方が１００倍〜１０００倍近いので、古いままで維持させることに疑問があります。

＞信頼性

机上の話のレベルになってしまいますが、それほど問題あるんでしょうか？仕様がないなら振る舞いを書き出せばいいし（それでも書き出せない仕様があったとして果たして必要なのか疑問です）、linuxに問題があるなら原因解析すれば良い。それって結局オープンな環境で仕事をするか、ベンダー内だけで仕事をするかの違いですよね。

けいの2009/07/25 11:18:02
満足20pt

私が今日未明に見た時点でikasamtさんが疑問に感じているであろういろいろなことについて回答しようと思いましたが、書いてみたら物凄い長文になり、自分で読み返しても訳が判らなくらい整理がつけられなかったので、私の観点で重要だと思うことについて絞って書き直してみました。

トランザクションの処理能力が重要視される
- COBOLは言語の記述に自由度が少ないため、他の言語に比べてコンパイラを設計しやすいです。歴史も古いのでコンパイラのチューニングにより、生成される機械語の質はかなり高いです。
- 実行時にランタイムライブラリやダイナミックリンクを使用する言語は、処理要求があってから、まずCPUに処理可能なコードを生成して、それから本来必要な動作を始めるのでオーバーヘッドが大きいです。
本運用に入った場合に問題が発生した場合の影響・損害が極めて大きい
- リスクが高いために、予め高額の費用をかけても、問題が発生する可能性を下げておく必要があります。
- 人間は間違える可能性があります。バグが混入したり、テストでバグの検出漏れがおきる可能性を下げる必要があります。
  - うまく動いている部分はなるべくそのまま使用する。
  - 最利用可能なサブルーチンをライブラリとしてまとめる。
  - ソースコード(場合によってはバイナリも)の変更を最小限に抑え
  - 複数の人で同じものを再チェックしたり、いろんな観点から検証する必要がある。

まだ、いろいろあるとは思いますが、とりあえずここまでにしておきます。

スター

ikasamt 2009/07/26 01:01:26

回答ありがとうございます。

大変参考に成ります。

＞１

なるほど。枯れてる環境の良さを感じます。ただ、他の言語でも同じレベルに到達できませんかね？

またムーアの法則でカバーできると思うので近年ではアプリケーション単体の速度が本当に必要とされる部分は全体の１割(感覚値ですが)以下だと思います。

＞２

たしかに本番での安定は現状維持が一番でしょうね。

でも思うんですが、テストで再現できないような状態は結合が密すぎたり、参照で副作用が発生していたりなど、それこそ言語そのもの欠点を露呈しているように思えます。

勉強不足で間違えたことを書いてしまっているかもしれませんが、少しでも疑問をそのままにして置きたくないので、思った感想をそのまま書きました。

その他の回答を読む

この質問へのコメント

dev_zer02009/07/24 21:39:23

COBOL単体だけだと大して意味はありません
・固定長レコード
・JCL
・大手ベンダーの保守(ハード＆ソフト)
のセットになると強力になるのです
　
さらに
・歴史や経緯を知らないと訳がわからない混沌とした仕様
・うっかりシステムを止めてしまうと莫大な違約金を払うという責任
があったりすると誰も手出しができなくなります
ikasamt2009/07/24 23:47:45

dev_zero0さん。コメントありがとうございます！
参考になりました。

＞固定長レコード
どのような点でこれが有利に成るのでしょうか？また他言語等で実装しにくい理由は？固定長なら別にどんな言語でも高速に処理する手段を持っていると思うので、差別化しづらいと思いました。

＞JCL
http://ja.wikipedia.org/wiki/Job_Control_Language
メインフレームでの開発経験が全くないので（Linuxばっかりです）、イメージがわかないのですが、参考になるURL等ありましたら教えて下さい。

＞大手ベンダーの保守
確かに自前でSIするのはコストなので大手ベンダーにべったりは管理が楽ですね。反面ブラックボックスになりますよね。
ikasamt2009/07/25 00:28:29

銀行ってトランザクションのACIDを維持する代わりに、すべてをバッチ処理にしてしまって、重複やキャンセルクエリを省いてるんですかね。だとしたらびっくりするくらい単純だし不便だなー。株とか外貨とかの場合はどうしてるんだろう。詳しく歴史や仕様が書かれた本があればいいのですが。

今回質問したのはcobolの優れた点を自分が全く知らないという好奇心と、SIerの本丸はここら辺だと思うのでWEB屋だと同じかそれ以上のことが１００分の１の予算で出来るんだぞということを証明してみたいという夢があり、そのための下調べです。

もし「WEB屋には無理だ」という意見のかたがいたら迷わず懸念点を教えてください。
khazad-Lefty2009/07/25 09:21:53

ここには書いてないですが、銀行系なら丸め誤差の話は無視できないんじゃないでしょうか？
COBOLがデフォルトで10進をサポートしているというのは結構大きいとおもいます。

http://ronspace.cocolog-nifty.com/blog/2008/10/fortran-cobol-2.html
http://ronspace.cocolog-nifty.com/blog/2008/10/post-2512.html
とはいえ、上記のようにJAVAでも多少冗長な記述は必要だとはいえ(実はそうでもない？)、
上記のように対応しているわけで、日本でもフロントエンドから少しずつ置き換えられているのは事実ですし、アメリカあたりだともう少し置き換えは進んでいるという話を聞きます。
ikasamt2009/07/26 01:14:08

＞khazad-Lefty

ありがとうございます。
具体的な事象についての資料で参考に成ります。

参考に調べてみたら面白い書き込み見つけました。
http://pc12.2ch.net/test/read.cgi/tech/1158154668/560

他の方がおっしゃっている「明文化されてない仕様」ってこういう演算精度まわりでのこととかも含みそうですね。確かにこれは暗黒だなぁ。
standard_one2009/07/26 10:53:03

少し論点がずれるけど、PHPに移行なんてなったら質の悪い自称技術者がいっぱい集まってきちゃいそうだなぁって思った。
「コードだけ納品すればいいッスか？」
いいわけねーだろｗ
ikasamt2009/07/26 13:49:09

standard_one さん

コメントありがとうございます。

php周りのWEB業界も決して美しいもんじゃないですからね。コードを読まずに設計を理解せずに既存のソースをちょこちょこ書き換えて納品する技術者も多いと思います。

皆さんの回答やコメントを読ませていただきながら思ったのは、僕のcobol銀行業界に対する疑問不満ってphp/java/rubyも含む疑問不満で、「なぜ問題を切り分けで小予算／少人数で実装＋検証が可能な最小単位でサービスを作らないのか」「なぜ大プロジェクトの名の下に巨大な人月単価での仕事を発注／受注するのか」という所のようです。乱暴な言い換えをすると、「クラスがどーだとかテーブル設計がどーだとか、言わずに、特定のビジネスロジックを体現する1k行程度のhttpデーモンいくつも作って、疎結合させた方が、大規模開発に向いてるんじゃないのか？」という感じですね。

もしまだこの質問を見て回答やコメントを書いていただける方がいらっしゃたら、是非その辺りについても意見を伺いたいです。
けいの2009/07/26 22:56:05

人間は理屈じゃなく感覚で動きたかったり、面倒くさいことは回避しようとするもんだからね。
世の中はその欲求を満たすように自動化できることは、自動化してきた。
だけど誰かが自動化するための仕組みを考えて実現させているわけで、その仕組みを作っているのはやっぱり人間なんだよね。

自動化する部分が多くなるほど、仕組みは複雑なるのでシステムが大規模になる。複雑なプログラムを作るのは大変なので、またその作業を自動化しようとしていろんな言語が開発された。でもその言語で書かれたことを装置に判るように書き換える作業も複雑になっている。

無限ループですね。
walkingreed2009/07/27 10:33:07

>お金をかける前にたとえ遠回りでもゼロから再構築してユニットテストが通ればOKの状態にすればいいのに、と思ってしまいます。
単体テスト通ればOKで済むならいいですが、実際問題その程度のテストじゃまともに動かないでしょう。

>特定のビジネスロジックを体現する1k行程度のhttpデーモンいくつも作って、疎結合させた方が、大規模開発に向いてるんじゃないのか？
勘定系での大規模開発は経験ないですが、自分の経験から考えてその程度の考えでまともに動くものができるとは思えません。
それ単体でそれっぽく動くのを作るのは確かに簡単でしょうけどね。

銀行ほど大規模なシステムじゃないですし内容が全く違いますが仕事でFortranとかアセンブラとかからCへの移植は経験ありますけど、仕様書は一応ありましたけど結局はソース読まないと話になりませんでしたね。
あとプラットフォームが違ってくるから、OSレベルの違いにも対応が必要だったりします。
アセンブラの時はbit数の違いも、バイトオーダーの違いもでてきたりで。
dev_zer02009/07/27 20:18:05

> １．高負荷のトランザクション処理が出来る
という意味で他の言語(というより環境)が真似できないことで
　
固定長レコード「のみ」を扱うことにより、作成したプログラムがメモリをどれぐらい使うのかを予め予測できる。
JCLでメモリ制限やCPU制限を設けることにより全てのプログラムを止めずに
ほぼ100%のCPU、メモリを使いきることができます。
　
これが他の環境だとプログラムが占有するメモリ量を予め見積もれず、
また、そのプロセスに割り当てられるメモリ量も制限できないので
あるプロセスが暴走してしまうと、他のプロセスが仮想メモリに追いやられたりして
そのマシン上にあるほかのプロセスも遅くなりがちです。
しかも、マルチスレッドなんかで作っていたりするとそのプロセスが死んでしまうと
そのプロセス上で動作しているスレッド全てがお亡くなりになります。
　
まぁ、そこら辺は基幹系になってくれば監視する人間がいる筈なんで
異常を検知すればすぐにオペレータが飛んでいくでしょう
けいの2009/07/27 22:34:41

回答5へのコメントより
＞資産計上している1000億の項目が一気にゼロ円になってしまい、会計上悪い

減価償却という言葉を知りませんか？
いままで1000億の費用がかかっていても評価額はそれよりずっと小さいです。

この話題はなかなか興味深いのですが、ikasamtさんは想像や経験則などあまり正確でない(裏付のない)ものを根拠に話を進めようとしていると感じます。そういうことでは、お金を扱うシステムや大規模で複雑なシステムに関わるのは無理だと思います。
ikasamt2009/07/27 23:18:30

keinoさん

＞減価償却

たしかに減価償却で評価額は年々下がっていますね。
一気にゼロは誤解を招く表現でした。

＞想像や経験則などあまり正確でない(裏付のない)ものを根拠に話を進めようとしていると感じます

すみません。議論を進めているという意識は薄かったです。「個人の質問」として話を進めているつもりだったので、丁寧な議論をすることに注意が向いてませんでした！ご気分を害したことをお詫びします。

>そういうことでは、お金を扱うシステムや大規模で複雑なシステムに関わるのは無理だと思います。

申し訳ございません！出直してきます！
けいの2009/07/28 00:28:06

人力検索なので個人の質問として話を進めるのは構わないのですが、今何を知りたいのかがイメージしずらいんで、回答として書き難いと私は感じるんですよ。
逆提案をするのではなく、もうちょっと何について知りたいのか明確になるようコメントを書いて欲しいです。
chuken_kenkou2009/07/28 20:41:06

COBOLの特性や背景については、他の方から良い回答もあるようなので、少し違う観点から。

数年前（2000年以降）のIT業界の調査で、「現在、世界で稼動中のシステムのうち、過半数はCOBOLで構築されている。」という調査結果があります。

こういったサイトで、「COBOLが現在も使われているのは、金融系くらい」と発言する人がいますが、ライフラインを支える多くのシステムは、現在でもCOBOLで構築されているものが多く、完全に脱メインフレーム、脱COBOL化された例は、世界的にも殆どありません。

ライフラインを支えるようなシステムでは、時代のニーズに合わせてDB/DC製品を中心に高性能、高信頼性に加え、いろいろな機能を実装しています。
DB/DC製品には、トランザクションを高速化するため、COBOLをターゲットにした機能を実装しているものもあります。
階層型DB、ネットワーク型DBに加え、1980年代後半にはリレーショナルDBも実用化され、埋め込みSQLも、主要メーカーから最もニーズのあったCOBOLコンパイラでいち早く提供されました。

既にあるCOBOLの資産を、すべて他の言語で書き換えるというのは容易でなく、COBOLのソースをそのままUNIXやWindowsで動かせるCOBOLが、主要メーカーから出揃っており、そういったハードの移行を行う例もあります。
また、標準COBOLの改訂も盛んに行われ、それを実装したCOBOLも主要メーカーから出揃っており、アドレス操作、オブジェクト思考、オープン化などにも対応しています。

プログラミング言語や環境について詳しい方に質問です。

ベストアンサー

takano322009/07/27 11:21:24
満足20pt

ikasamt 2009/07/27 20:38:54

その他の回答