沖縄銀行、オープン系システムの導入を凍結し現行システムの稼働を延長へ 54
ストーリー by hylom
どうしてこうなった 部門より
どうしてこうなった 部門より
あるAnonymous Coward 曰く、
沖縄銀行が3月28日、次世代システムの開発を凍結することを発表した（沖縄銀行の勘定系システム機器の更改に関するお知らせ［PDF］）。
もともとは開発コスト削減を視野に入れてオープン系が採用されたが（以前の「お知らせ」PDF）、当初平成26年とされていた稼働時期が平成27年にずれ込んだこともあって開発を凍結した上での現行システムの稼働延長に至ったようだ（昨年に発表されていた勘定系システム機器の更改に関するお知らせ［PDF］）
今どき.... (スコア:2)
HP-UX に Oracle って、もう15年ぐらい前のシステムの組み合わせのような気がします。
しかも、今の価格から考えると、ハードもソフトもすごく高価な部類に入りますよね....
いまさらこの構成でシステムを組まれても、10年先に保守する費用がバカにならないですよね。
日本の勘定系って、いまだにこんなシステムなんだろうか。
Re:今どき.... (スコア:2, すばらしい洞察)
15年前って言うとものすごく古そうだけど「Windows XP発売のたった2年前」だとあまりそんな感じがしない! ふしぎ!
Re:今どき.... (スコア:1)
7年くらい前に大企業のグループ用システムでは新規採用していましたけど銀行の勘定系ではないか。
15年くらいまえというとOCNへの更改提案で同業他社に勝利した前後(Oracle採用していたかどうかは不明)の晴れがましい時期を思い出すかも。
Re:今どき.... (スコア:1)
甘い。
ACOSのメインフレームのほうが更に一桁高い。
Re:今どき.... (スコア:1)
同じような感想です。
失礼ながら、沖縄銀行ぐらいの規模だからHP-UX＋Oracleでも行けるんだろうな
と思ってしまいました。
＃というか、行けてないのか。
Re: (スコア:0)
ですよね。
しかしBankingWeb21って、12,3年前からやってたはずですが、未だに開発がスケジュール通りに進まないんですね。
#10年近く前までそのN社で関連する仕事をしてたのでAC
#あの当時は相当"アレ"だったけど全然進歩してなさそう
Re:今どき.... (スコア:1)
昨日、金融系の現場から戻ってきたところだけど、そんなシステムばかりなんじゃないかなあ。
いろいろ想像を絶するソースと、想像を絶する作業と、それしか思いつかない想像を絶する人間が右往左往していた....。
ここには人間はいないよ....。予算に群がるダニしかいないよ...。
自分が口座をもっている銀行もあったので、解約を決めた。個人客には関係ない部分だけど、あんなもの野放しにしている銀行に金預けられるか。
#と、言っていると金を預けられる銀行は国内では無くなるんですけどね
Re:今どき.... (スコア:1)
Kindleの月替わりセールで値引きされてたんで、
「システム障害はなぜ二度起きたか みずほ、12年の教訓」
を今頃買って読んでるけど、
「システム設定を23年間見直さず」ってあるくらいで、設定さえ23年間変更してない。
＃この本で扱ってる二度目の大規模トラブルが2011年3月。それより23年前ってことだと。
ハードやソフトも最低でもそれと同じだけの間、同じ物を使ってるんでしょう。
15年前なんて、みずほに比べれば新型機なんでわ。
＃ちなみにjob descriptionで見た限りでは、金融系だとOracleとSybase（だっけ？）が多いんだっけかな。
＃自分は「OracleはまだしもSybaseなんて見たことねーよ」な人だったんだが、
＃金融では多いんですと言われて「へー」だった。
Re:今どき.... (スコア:2, すばらしい洞察)
NEC (スコア:1)
どこかと思えばNかよ。
二年ほど前に航空管制システムでやらかした [srad.jp]のは知っていたが、金融系でもやっちまった！
Re: (スコア:0)
Re: (スコア:0)
今日、4月1日だし。
Re: (スコア:0)
ちがう、ちがう、ディスプレイを90°回転させたんだよ。
Re: (スコア:0)
そうだ、これは夢なんだ
ぼくは今、夢を見ているんだ
目が覚めた時、ぼくはまだ12歳
起きたら出勤して、涼しいうちに次世代システムを片付けて
アフター5は思いっきり遊ぶんだ…
Re: (スコア:0)
つー事は、COBOLはCOBOLでもCOBOL/Sか！
HPLの可能性もあるな。
Re: (スコア:0)
NECの新機種に更改すると有るが (スコア:1)
新システム（「BankingWeb21」：ＮＥＣが平成12年10月に製品化したUNIXを全面的に採用したオープン勘定系システム）への移行を凍結して、同じNECの新機種に更改するとあるみたいだが、これを業界では現行システムの稼働延長と呼ぶのだろうか。
Re:NECの新機種に更改すると有るが (スコア:3, 参考になる)
BW21といえば失敗プロジェクトの代名詞で、数百億単位の赤字を出した伝説のプロジェクトですね。
「製品化」なんて口が裂けても言えるレベルの代物ではありません。
未だに採用を諦めていない人たちがいるとは驚きました。
Re:NECの新機種に更改すると有るが (スコア:4, 興味深い)
10年前に性能が出なくてチューニングに駆り出され, それが原因で逃げ出した俺が通りますよ.
内部的には業務ロジックデータからコードジェネレータで生成したCとCOBOLが使われていたのですが, 性能が出ずに手作業でコードチューンを行っていたため, 品質の低下とコーディング/テスト工数の増大を招いていました. とにかく規模が大きくて中国やインドでのオフショア開発も行っていましたが, 1日あたり1億が飛んでいくと言われていました. 24時間体制で開発を行っていたので拘束時間は長かったのですが, チューニングや運用などの技術サポート部隊は稼働率が低く, 士気はかなり低かったです.
その後どうなったかは知らないのですが, 構造的に並列処理で性能を上げるのが難しい, というか業務ロジックデータに並列可能性を判断する材料が無かったはずなので, 今日的な並列処理でトータルスループットを上げることが, 特にバッチ系で難しかったんじゃないかと思います.
Re:NECの新機種に更改すると有るが (スコア:3, 興味深い)
新卒で最初に関わったプロジェクトがBW21だったなあ（遠い目・・・)
自分はY銀行のカットオーバー後に抜けたけど、まだプロジェクト続いてたのね。
当時はDBとは何かもよくわからない状態で定期系の詳細設計(エクセル方眼紙)を書いてました。
日本語で書いた設計書をACCESS上の単語辞書で機械翻訳してインド人に投げるという
今考えるとすごいことしてたっけ。
--
元関係者なので当然AC
Re:NECの新機種に更改すると有るが (スコア:1)
Wikipediaの情報が事実なら、東京スター銀行が諦めてないようです。（2015年稼働予定）
こんな基幹パッケージで、稼働2行＋導入予定1行だけでは
どう考えても大赤字でしょうね…。
Re: (スコア:0)
「契約更改」って意味じゃね？
いつも思うのですが (スコア:1)
メインフレームからオープン系への移行で一番キモになるところってどこなんでしょう。計算結果が合わないとか、端数処理がとかそういうお話なんでしょうか。
話は違うと思いますが銀行系システムで COBOL から他の言語に移行できない理由って、メインフレーム用の COBOL 以外の言語がないからとかそういう理由なのかなーとか安易に妄想したり。教えてエロい人。
Hiroki (REO) Kashiwazaki
Re:いつも思うのですが (スコア:5, 参考になる)
実は言語的な問題やサーバの選定なんかはどうでも良い範囲です。
業務要件の確定とパッケージ化がどうにも上手く出来ずに、銀行案件はどこもかしこも炎上します。
詳しくはBW21に見る地銀システム開発の失敗(1) [srad.jp]をどうぞ
Re:いつも思うのですが (スコア:1)
・停止時間がほとんど許されない（年間で数時間からせいぜい48時間程度まで。緊急パッチあてるのも含めて）
・顧客が求めているのは既存のシステムの再実装＋α、でも既存のシステムの仕様を完全に把握しきれていないし、ソース以外に”正しい”ドキュメントが無い。
・他のソフトウェアやOS含め、発生した障害やバグ全て、発生原因を確実に突き止めないといけない。再起動したら直った、とかじゃ話にならない。
この状態で開発するってのがキモです。
Re: (スコア:0)
> 発生原因を確実に突き止めないといけない。再起動したら直った、とかじゃ話にならない。
これは確かに厳しい。
しかし、発注側が自分らのポカに対しても同じ態度で臨んでるところだと成功する。
自分にはぬるいくせに発注先にだけ超厳格な態度の所は失敗する。
いや失敗して欲しい。絶対に失敗しろ。
ということでBW21ざまー
Re: (スコア:0)
それのきついところは、自社製パッケージやプロジェクトで開発したソフトと、使用したミドルウェア以外に、他社製だったりオープンソースだったりする、OSに入ってるソフト全部が対象な点です。
メインフレームでも同じ条件な訳ですが、メインフレームはオープンプラットホームじゃないから、NならNでほぼ閉じていたんでそこまで厳しくないんです。
まぁ早い話、メインフレームでやっていたこと・できていたこと全て、システムの機能以外の部分も、オープンで実現しようとすることが問題なんでしょうね。
Re: (スコア:0)
エロくはあるかもしれないけど、エラくはないのですが、
おそらく、COBOLでできている処理をリプレースする予算と実行力と権限と視野と判断力がない事がほとんどでは。
自分が把握していない範疇の事で博打を打つよりは、金でメーカーに言うことを聞かせて延命するほうが楽ですから。自分の金でなし。
#いつまで続くかねえと思わんでもないけど、担当者レベルではもうちょっとだけつづくんじゃと言って、逃げられるまでもうちょっとだけ続けば問題はない
Re: (スコア:0)
言語という点ではPL/Iがありますが、やっぱCOBOLみたいっすね。
そもそも銀行で使うシステムではOSはカスタム版でコンパイラは独自の言語拡張されてたりします。
REDEFINESを使うような所でC言語で言う所の構造体へのポインタみたいな使い方でレコードアクセスできたりする機能があったり。
#聞いた話です
Re: (スコア:0)
長期的なメンテナンスコスト削減のために2年くらい並行稼働するぐらいのつもりじゃないと厳しいと思います。
移行できない理由は、COBOL以外の言語使う優秀な人はその現場に行きたがらない（安いし、周りのオープン系スキル低いし、処理内容もつまんないし）からだと思います。
オープン系に移行しなくてもお客さんはお金払ってくれるし、移行しちゃうとCOBOLしかできない人路頭に迷うし他の会社が参入してくるとうちの売り上げ減るしとか、そんな政治的な事情もあるような気はしますが。
Re: (スコア:0)
メインフレームはベンダーがおんぶに抱っこでサポート面倒見てくれるし、サポートが続くならオープン系に移行するの面倒だし
大規模な社会システムとかコアな組込系は慣性が大きく働くものだし、そういう方面から見たら最初から使い捨てのつもりで開発やってる方が異常
webアプリケーションとか作るわけでもなし、金勘定して帳票出力するのはCOBOLで必要にして十分だからCOBOLは死なない
＃規格化された言語仕様で十進演算をサポートしていない言語でどうやって金勘定する？
Re: (スコア:0)
http://www.pref.nagasaki.jp/shared/uploads/2013/06/1372208929.pdf [nagasaki.jp]
長崎県のこれもNでACOSだったと思うけど、結果どうなったんだろうね。
続報がない
空目 (スコア:0)
オープン系をオープンソース系と空目した。
平成12年に出したオープン系勘定系が (スコア:0)
平成26年になっても、今の業務にフィットさせることができないって意味？
富士通が、従来オフコンのアプリをそのままオープン系ハードでバイナリ互換のまま動かせるってものを見た時は「ナニソレ？」って思ったけど、移行のためのあれやこれやを考えると妥当な方法なんだろうか？
Re: (スコア:0)
逆じゃねぇの。
業務のほうが合せられないので、後段の今のハードでソフトを動かせる選択に変わったんじゃねぇの？
Re: (スコア:0)
勘定系の基幹部分なんて何十年経とうが変化なんかしないと思われ。
2000年問題を乗り切ってるんだったら、内国為替の仕組みががらっと変った
とかでもなければむしろ手をつけないほうが良いんじゃないかな。
メインフレームの安定感は、はんぱじゃないから。バッチ組むのは大変かもしれないけど。
むしろ変更なりリプレースが必要なのは窓口業務のシステムだったりATMだったりじゃなかろうか。
最近はいろいろサービスが増えてるだろうから、まんまメインフレーム端末だと操作が大変な気がする。
こんなザマじゃ (スコア:0)
24時間リアルタイム決済に地方銀行がついていくのは相当厳しそうだな。
銀行窓口は平日のみ・三時閉行なんて習慣、いつまで続くんだろう。
# もっとも、平日の三時までに普通に私用をこなせる社会のほうがずっとありがたい
営業時間 (スコア:3, 興味深い)
一応、下記条文に営業時間の根拠があるようです。
この条文を変更してくれれば営業時間は変わると思います。
営業の都合では変更してくれないみたいですし。
銀行法第１５条
２ 銀行の営業時間は、金融取引の状況等を勘案して内閣府令で定める。
銀行法施行規則（内閣府令）第１６条
銀行の営業時間は、午前九時から午後三時までとする。
２ 前項の営業時間は、営業の都合により延長することができる。
Re:営業時間 (スコア:1)
この条文は、「銀行は社会インフラの一部でもあるわけだから、「支店長が宿酔なのでお休み」というわけにはいかないよね。
平日9時から15時まではきちんと窓口営業をしなさい」という趣旨であって、フレックス勤務のコアタイムみたいなものだから、
営業時間を長くする分にはなんの問題もないんじゃないですか？
Re: (スコア:0)
営業の都合というはきっと、”客が居ても3時になったらバタンと窓口を閉めなければいけない”というわけではない
という意味かと
Re: (スコア:0)
その条文があるから「仕方なく」3時まで窓口開けてるんだよ。
小口の預金者なんてぶっちゃけ客じゃないんだから規制がなかったらとっとと窓口全廃して(今は3時過ぎからやらざるを得ない)金持ちへの営業しかしなくなるよ。
Re: (スコア:0)
> 平日の三時までに普通に私用をこなせる社会
社会じゃなくて、そういう会社であなたが働けばいいだけのこと。
私は決まった勤務時間中は私用厳禁で、時間外に働くことが
一切ないって仕事の方が好きだけど、残念ながらそういう仕事は
給料が安いんだよなぁ。
Re: (スコア:0)
平日銀行窓口がもうちょっと長く開いてればなーと思う人は普通にいると思うけど。
そこをそういう会社で働けって返すのはねぇ。。
ちなみに地元の信金で働いていた親によると３時に締めたあとはその日の処理と現金残高がきっちり合ってるか確認するためにお金を数えているらしい。
１円違うと大事になって伝票やらを見直しだすんだと。
カネを勘定するだけのシステム構築になぜこうも苦しむのか (スコア:0)
口座数が多かろうがATMの台数が多かろうが
根本のプログラムは相当にシンプルなもののはず。
そうじゃないなら設計したヤツが相当にアホなのか。
Re: (スコア:0)
勘定系の根本はトランザクションシステムですが、
これをシンプルというのはどうかと。
Re: (スコア:0)
いやぁ、これがなかなかシンプルじゃないですよ。
なんでこれをやるのにこんな複雑な書き方ができるんだろうという。
こないだまで、金融系のJavaのソースを触ってたけど、
代入毎、演算式の中でにDecimal→String→Decimal→String....と延々変換しつづけていて、一体何を考えているのかよくわからなかった。
#誰か教えてください
>設計したヤツが相当にアホなのか。
アホなんでしょう
ものがシンプルだろうが、そこに賭けられる掛金が大きくなれば、話は面倒になるものです。
Re: (スコア:0)
>>代入毎、演算式の中でにDecimal→String→Decimal→String....と延々変換しつづけていて、一体何を考えているのかよくわからなかった。
ひじょうに興味があります。中の人いますか
Re: (スコア:0)
行数が増えると開発実績が増えるじゃないですかｗ
Re: (スコア:0)
この手のシステムの何が嫌かって、書いたコードをテストするのに猛烈に時間がかかるから、脳内デバッグがメインだと言うところ。
実は沢山あるんじゃないかと想像してみる (スコア:0)
システムのリプレースはこれからもどんどん難しくなって行くんだろうなあ。
ウォーターフォールにこだわり続ける（というかそれしかできない）人たちが多いととくに。
結果的にリプレースに失敗して使い続けてるところは、実は結構あるんじゃないかと考えてしまう。
諸外国ではどうなんだろ。
自分は銀行というと10年くらい前にWeb（COBOLの新規案件）をやったくらいなんだけど。
勘定系ではなかったけど、それでもあの体たらくは…。