アカウント名:
パスワード:
すでにそれ死屍累々ですから.
# 脱出して一命を取り留めたので, さすがにAC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
カスタマイズが大博打かはともかく (スコア:5, 興味深い)
このあたりってシステム開発しているところではごく日常的にぶち当たっているであろう問題でしょうね。いつもスムースにすんなり完了となる方が逆に珍しかったり。しかしほとんどの場合は、擦り合わせによってなんとか収めるとかまたは逆転の発想で問題点を利点に変えてしまうとか、なんにせよ収束に向かうわけですが今回は完全に破綻してしまったと。
そこで提訴の件なんですが、最初にIBM側から「Corebankをカスタマイズする事を提案」というのが大きいのではないかと思えます。つまりIBMはCorebankを使って「うまくいく」とスルガ銀行に持ちかけているはずですから。ところが実際には無理がありすぎて工数も大幅オーバー、なのに後になって「規模を縮小したい」だの言われて挙げ句の果てにオーバー分を銀行側に求めて来たという事で堪忍袋の緒が切れた…というところでしょうか。
もちろん「無理があった」の部分に銀行側の要求が無茶すぎたとかもあったかもしれません。しかしシステムを提案したのがIBM側だったというのが確かならば、そもそものシステム提案が間違っていたか見積もりが甘すぎたという事にはなりそうです。まあその前に銀行側が「どっかのパッケージ使って安くあげられない?」とかいうやりとりがあったやもしれませんけどね。あと、Corebankが「連動型商品を素早く開発できる」と謳っていても実際そうでもなかったとか。それにしても実現不可なパッケージを選んでしまった責任を問われるのは仕方ない気がします。
#この件がどうこうよりも、まず思った事。「同じ轍を踏まないようにしよう…。」
Re: (スコア:0)
Re:カスタマイズが大博打かはともかく (スコア:2, 興味深い)
すでにそれ死屍累々ですから.
# 脱出して一命を取り留めたので, さすがにAC
それには、「Σプロジェクト」と名付けましょう!! (スコア:1)
ただ、金融機関の強みというか差別化戦略として、独自でシステムを開発するという
選択もあるでしょうから、どこまで収斂されるかはわかりません。
Re:カスタマイズが大博打かはともかく (スコア:1, 参考になる)
財務会計、人事給与、国保に年金。文書管理に行政評価にGIS、等々。
どれもこれも「“国内”標準の業務マニュアル+パッケージでシステム導入」でなんら問題ないです。でも現在のトレンドは「自治体内でのシステム統合」。複数ベンダで構築され、仕様の調査だけで軽く1年すっとぶようなローカルシステム群を、今以上に解きにくい運用ルールで縛るのに躍起です。
お金の話も笑えません。乱暴に一本2,000万円と考えても、(基礎自治体+広域自治体)×各システム分の税金が投入されています。具体的な状況も調査されています [soumu.go.jp]が、一般向けには公表されません [nippon-net.ne.jp]。
そして桁の違う省庁側のシステムも「最適化計画」に基づき同時進行中。一体どれだけの公務員がそれに貼り付き、処理能力(=人件費)を消費しているのか。
将来にわたり使えるシステムができるのであればまだいいでしょう。
でも現実には運用開始直後から「あと何年の我慢」と怨嗟の声が現場から。
自治体のシステムは利益を生みませんから、導入にあたっては「瑕疵と労力を削減する効果=業務の見直し」が必須であるにもかかわらず、自治体側のシステムや企画担当者は部門の業務に踏み込めず現状合わせを強要するし、ベンダ側も怯えて業務の実態(本質からの乖離)を知りたがらない。
もちろん財源は税金です……。
#といいつつ問題の9割は組合(社保庁問題と同じ構造)としか思えないのでAC
↑参考になる:+1 (スコア:0)
Re: (スコア:0)
ここもシステムはIBMですが、主導権はユーザ側(というか八十二銀行)が握っているのが大きいんじゃないでしょうか。
現在の銀行のコアってのはITシステムそのものなので、そこをシステム屋まかせにする時点で間違ってますね。