これほど多種多様な言語があり進化しているにもかかわらず「銀行などの大規模システムの仕組みは日本においてはcobol等で
為されている」という話を時々聞きます。でも大抵頻繁にメンテナンスをし夜中に止まる全く枯れてないシステムでもあると思うのです。しかも予算がベラボーに高い。100億とかって言いますよねよく。理由を聞いてみると以下の4つを良く聞きます。
1.高負荷のトランザクション処理が出来る =>コボルの性能と言うよりも動作させているマシンの性能では?またアルゴリズムさえ同じであれば言語は関係あるのか?
2. 言語が英語に似ていて分かり易い => 可読性が高いとは思えない
3.デファクトだからライブラリなどの資産がある => 少しずつ書き換えられないほど密結合なのか?
4. 複数人での大規模開発に向いている => 数百人とかのプロジェクトは問題のスコープの範囲を間違えているのでは?数人×100プロジェクトとかに切り分けるべきなのでは?
各々の=>以降は僕の感想です。
些細なことでもかまわないので、回答よろしくお願いします。
結論から言えば書き換えたほうがよい、です。書き換えられない理由がいろいろあります。先に述べられている回答もそれぞれがそのひとつです。
要点をまとめると、書き換えるコストとハードウェアをリプレイスするコストを秤にかけ、サービスとソフトウェアとハードウェアの寿命を考えた上でも書き換えたほうがよいと結論を出したところはすでに書き換えています。
ソフトウェアの費用が高く、ハードウェアのリプレイスで延命でき、サービスの拡張も大幅にすることがないようなシステムではCOBOLのまま多少高価でもハードウェアをリプレイスすることになります。
こんばんは、ikasamtさん。
最近は銀行のそういう大型システムでも、Javaに移行しつつあります。
>1.またアルゴリズムさえ同じであれば言語は関係あるのか?
言語的な制限で、CobolとかJavaはアルゴリズムも制限されて誰が書いてもほぼ同じになるので、管理する側は都合がよいのです。
>3.デファクトだからライブラリなどの資産がある => 少しずつ書き換えられないほど密結合なのか?
アマゾンの奥地と同じぐらいなので、障りたい人なんていません。触ったら、どんなにがんばっててテストしても、本番で障害がでます。
>4. 複数人での大規模開発に向いている => 数百人とかのプロジェクトは問題のスコープの範囲を間違えているのでは?数人×100プロジェクトとかに切り分けるべきなのでは?
1と同じです。
>(1)言語的な制限、(4)大人数
トリッキーなことが出来ない=誰が書いても大差ない、は重要ですね。ただ他の言語でも開発者間の意思疎通がとれていれば書き方や設計思想の違い等が乖離することもないと思っちゃいます。誰が書いても同じだけど冗長なcobol/javaを選ぶか、コンパクトだけど書き手のテクニックを必要とするpythonやrubyやscalaなどのモダンな言語を選ぶかは、判断が分かれそうですね。
>(3)ライブラリがジャングル
ムムムー。単体テストやちょっとした結合テスト程度で判明しないってことは、もしかしてグローバル変数とかポインタ参照とかやりまくってるんですかね。それだとリファクタリング不可能ですね。でも、機能別にアプリケーションが分かれていれば、I/Oさえ同じだったら可能ですよね?
具体的な仕様やソースを観たことが「皆無」なので「銀行系システム」ってのがどういう仕事をするどんな仕組みの物なのかほとんど分かってないのが口惜しいです。
大変ありがとうございました。
参考になりました。
ほかにも全体の仕様や構成を詳しく説明できる人がいれば回答お願いします。
COBOLはレガシーな言語ですが、なかなか良い言語だと思います。
なぜ、未だに使われているかについては単純に過去の資産を継承しているからだと思います。
COBOLが使われる理由は以下の通りだと思っています。 ・本来プログラム仕様書があってプログラムが正しく動作しているはずです。 しかし、プログラムをメンテナンスしていくと仕様書が古くなり齟齬がおきていることが多いと思われます。 よって、他言語への移行は難しいし、仕様書を作り直すことも費用的に不可能に近いと思われます。 ・他言語への移行ができてもテストも入れると開発期間・費用がかかるし、稼働しても問題が起きる可能性 がかなり高いと思われます。 ・処理はオンライン系よりバッチ系が多いので、COBOL言語が最適と思われます。 ・命令がかなりシンプルで誰が作成しても、見やすいプログラムになります。 ・COBOLはCOBOL85等、言語仕様が明確で、他言語のようにローカルな仕様はほとんどないです。 ・まだかなりのコボラーがいるので、開発要員を多く集めることができます。
確かに凄い費用を掛けて対応しますが、バグが出ると社会的に問題があるので、十分テストをするので費用が掛かるのはやむを得ないと思います。
4つの理由とのことですが… 1.高負荷のトランザクション処理が出来る … それはないと思います。C言語とか他言語の方が処理効率も高いと思います。 単純にメインフレームであるハードウェアの性能で問題ない稼働を実現していると思います。 2.言語が英語に似ていて分かり易い… 英語というより、命令や言語がシンプルなので可読性は高いと思います。 3.デファクトだからライブラリなどの資産がある … レガシー言語なので過去のモジュールは品質が高く整理されています。 ただ過去の資産というだけで、ライブラリの作り良さ…は感じられないですね。 4.複数人での大規模開発に向いている … 特にそういうことはないです。今は大規模開発のために開発環境管理(VisualSourceSafe,CVS) やプログラム共同開発ツールは進んでいると思います。
以上、私の経験からの勝手な意見です。
ありがとうございます。
大変参考になります!
知らない事ばかりでうれしいです。
・オンラインよりもバッチ処理が多い(知らなかった!)
・可読性は高いのは事実。シンプルで見やすい。
・ライブラリ設計や処理速度が優秀ではなく、資産だから(惰性)
・仕様が枯れている
などの理由ということでしょうか。
>コストの問題
お金をかける前にたとえ遠回りでもゼロから再構築してユニットテストが通ればOKの状態にすればいいのに、と思ってしまいます。10億あれば隠れ仕様も含めて書き出せないでしょうかね。
ほかにも、ざっくりとした仕様(例えば銀行間、支店間の口座のお金の動きはこういう処理で、ACIDはこうやって維持されている)みたいなのご存知でしたらお願いします。
>1.高負荷のトランザクション処理が出来る
COBOLでは他にはない実績のあるフレームワークがあるということですよね。
「高負荷のトランザクション処理が出来る」けど実績がない、ではクリティカルなシステムでは使えません。
>2. 言語が英語に似ていて分かり易い => 可読性が高いとは思えない
慣れの問題ですよね。どれだけ精通しているか。
新しい可読性の高い言語が生まれても、言語をとりまく開発環境が充実していなければ使えません。
環境はあるけど実績がなくて「作ってみたけどだめでした」は大規模システムでは使えません。
>3.デファクトだからライブラリなどの資産がある => 少しずつ書き換えられないほど密結合なのか?
正直、言語そのものよりライブラリが充実しているかどうか、のほうが重要ですね。
実績というのは得難い資産です。
>4. 複数人での大規模開発に向いている
これは単純に Java とかのほうがよくなってきているかもしれません。
一度できあがった大規模システムを変えるには時間がかかります。
今でも部分的には(例えば一部のサブシステムはJavaとか)変わってきている部分もあると思います。
あと、コメントに書いてあった部分について
>WEB屋だと同じかそれ以上のことが100分の1の予算で出来るんだぞということを証明してみたいという夢があり
いわゆるLAMPなシステムで同じようなシステムを作るのは低価格で可能と思います。
が、いろんな意味で信頼性を保証するのが難しいと思います。
仕様書に載ってない仕様をどうやって見つけて新システムで再実装するのか、とか
Linux で Kernel Panic が起こったら原因解析して再発防止の修正パッチ作れるか、とか
個人的には古いものは古いものにまかせて、新しい技術で新しいものを作るのが
よいのではないかと思ったりします。
回答ありがとうございます。
大変参考に成ります。
>古いものは古いものにまかせて、新しい技術で新しいものを作るのがよいのでは
大抵の場合賛成ですが、現状の銀行システムの場合コストのかかり方が100倍〜1000倍近いので、古いままで維持させることに疑問があります。
>信頼性
机上の話のレベルになってしまいますが、それほど問題あるんでしょうか?仕様がないなら振る舞いを書き出せばいいし(それでも書き出せない仕様があったとして果たして必要なのか疑問です)、linuxに問題があるなら原因解析すれば良い。それって結局オープンな環境で仕事をするか、ベンダー内だけで仕事をするかの違いですよね。
私が今日未明に見た時点でikasamtさんが疑問に感じているであろういろいろなことについて回答しようと思いましたが、書いてみたら物凄い長文になり、自分で読み返しても訳が判らなくらい整理がつけられなかったので、私の観点で重要だと思うことについて絞って書き直してみました。
まだ、いろいろあるとは思いますが、とりあえずここまでにしておきます。
回答ありがとうございます。
大変参考に成ります。
>1
なるほど。枯れてる環境の良さを感じます。ただ、他の言語でも同じレベルに到達できませんかね?
またムーアの法則でカバーできると思うので近年ではアプリケーション単体の速度が本当に必要とされる部分は全体の1割(感覚値ですが)以下だと思います。
>2
たしかに本番での安定は現状維持が一番でしょうね。
でも思うんですが、テストで再現できないような状態は結合が密すぎたり、参照で副作用が発生していたりなど、それこそ言語そのもの欠点を露呈しているように思えます。
勉強不足で間違えたことを書いてしまっているかもしれませんが、少しでも疑問をそのままにして置きたくないので、思った感想をそのまま書きました。
結論から言えば書き換えたほうがよい、です。書き換えられない理由がいろいろあります。先に述べられている回答もそれぞれがそのひとつです。
要点をまとめると、書き換えるコストとハードウェアをリプレイスするコストを秤にかけ、サービスとソフトウェアとハードウェアの寿命を考えた上でも書き換えたほうがよいと結論を出したところはすでに書き換えています。
ソフトウェアの費用が高く、ハードウェアのリプレイスで延命でき、サービスの拡張も大幅にすることがないようなシステムではCOBOLのまま多少高価でもハードウェアをリプレイスすることになります。
回答ありがとうございます。
参考になります。
想像になってしまい申し訳ないんですがソフトウェアは人件費や電気代と同じ費用なのに会計上、
資産に計上出来てしまうことも関係しているような気がします。
例えば、
・リプレースにかかる費用:10億
・リプレース後の保守費用:1億/年
・既存のシステムの累積制作費:1000億
・既存の保守費用:10億/年
という状況があったときに、既存のシステムを捨ててしまう方が純粋なコストでも生産効率でも最良の選択肢だったとしても、リプレースすると資産計上している1000億の項目が一気にゼロ円になってしまい、会計上(対株式市場上)悪いからという判断がなされてしまいそうです。
回答ありがとうございます。
参考になります。
想像になってしまい申し訳ないんですがソフトウェアは人件費や電気代と同じ費用なのに会計上、
資産に計上出来てしまうことも関係しているような気がします。
例えば、
・リプレースにかかる費用:10億
・リプレース後の保守費用:1億/年
・既存のシステムの累積制作費:1000億
・既存の保守費用:10億/年
という状況があったときに、既存のシステムを捨ててしまう方が純粋なコストでも生産効率でも最良の選択肢だったとしても、リプレースすると資産計上している1000億の項目が一気にゼロ円になってしまい、会計上(対株式市場上)悪いからという判断がなされてしまいそうです。