1248725565**[情報整理]question:1248422316の一時コピー(作業用・回答編)

2009/10/28 03:57時点で参照できる情報を転記した。
自分なりの観点で編集予定

言語や環境について詳しい方に質問です。

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

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

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

質問者: ikasamt
状態: 回答受付中
回答数: 5/45件
回答ポイント: 100ポイント
登録: 2009-07-24 16:58:38
終了: --
カテゴリー: コンピュータ 経済・金融・保険

  1. 回答者：yofukaci 2009-07-24 20:46:38

こんばんは、ikasamtさん。

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

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

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

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

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

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

1と同じです。

質問者：ikasamt 2009-07-25 00:20:53
＞(1)言語的な制限、(4)大人数

トリッキーなことが出来ない＝誰が書いても大差ない、は重要ですね。ただ他の言語でも開発者間の意思疎通がとれていれば書き方や設計思想の違い等が乖離することもないと思っちゃいます。誰が書いても同じだけど冗長なcobol/javaを選ぶか、コンパクトだけど書き手のテクニックを必要とするpythonやrubyやscalaなどのモダンな言語を選ぶかは、判断が分かれそうですね。

＞(３)ライブラリがジャングル

ムムムー。単体テストやちょっとした結合テスト程度で判明しないってことは、もしかしてグローバル変数とかポインタ参照とかやりまくってるんですかね。それだとリファクタリング不可能ですね。でも、機能別にアプリケーションが分かれていれば、I/Oさえ同じだったら可能ですよね？

具体的な仕様やソースを観たことが「皆無」なので「銀行系システム」ってのがどういう仕事をするどんな仕組みの物なのかほとんど分かってないのが口惜しいです。

大変ありがとうございました。

参考になりました。

ほかにも全体の仕様や構成を詳しく説明できる人がいれば回答お願いします。

  1. 2 回答者：jccrh1 2009-07-24 22:12:32

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

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

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

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

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

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

質問者：ikasamt 2009-07-25 00:22:28
ありがとうございます。

大変参考になります！

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

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

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

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

・仕様が枯れている

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

＞コストの問題

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



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

  1. 回答者：ksh 2009-07-25 03:07:15

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

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

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




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

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

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

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




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

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

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




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

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




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

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




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

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

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

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

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

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




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

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

質問者：ikasamt 2009-07-26 01:01:34
回答ありがとうございます。

大変参考に成ります。



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

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

＞信頼性

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

  1. 4 回答者：keino 2009-07-25 11:18:02

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



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


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

質問者：ikasamt 2009-07-26 01:01:26
回答ありがとうございます。

大変参考に成ります。

＞１

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

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

＞２

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

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



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

  1. 5 回答者：takano32 2009-07-27 11:21:24

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

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

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

質問者：ikasamt 2009-07-27 20:38:54
回答ありがとうございます。

参考になります。

想像になってしまい申し訳ないんですがソフトウェアは人件費や電気代と同じ費用なのに会計上、

資産に計上出来てしまうことも関係しているような気がします。

例えば、

・リプレースにかかる費用：１０億

・リプレース後の保守費用：１億/年

・既存のシステムの累積制作費：1000億

・既存の保守費用：10億/年

という状況があったときに、既存のシステムを捨ててしまう方が純粋なコストでも生産効率でも最良の選択肢だったとしても、リプレースすると資産計上している1000億の項目が一気にゼロ円になってしまい、会計上(対株式市場上)悪いからという判断がなされてしまいそうです。


※はてな記法と一部のHTMLタグが使用出来ます。
※一人当たり3回まで回答出来ます