Hatena::ブログ(Diary)

novtan別館 このページをアンテナに追加 RSSフィード

2012-11-15

銀行SEの現在

もう2007年といえば5年前のことになってしまう。時のたつのは早いものです。

当時の増田のエントリが何故か今頃盛り上がっていて、その結果それに言及した僕のエントリも盛り上がっているようなのですが、5年前の状況というのはさすがに古かろう、ということでちょっとアップデートしてみたいと思います。

参考:

IT業界で無事にいたいなら銀行に関わるな

銀行SE…かわいそうです… - novtan別館

ここ最近の銀行システムの大きなトピックというのは三菱統合UFJ銀行のDAY2(システム完全統合)と、みずほ銀行の3.11後の大障害とそれに伴う銀行の統合・システム刷新でしょう。

特に後者は銀行システムの停止が社会に与える影響が如何に大きいものかということを体現してくれました。

なんどかリークもされているからここだけの話をすると、みずほ銀行はいわゆる第三次オンラインをちゃんとやらなかった建て増しシステムであるSTEPS(旧第一勧銀)を使い続けていくことは限界ということで、勘定系刷新のプロジェクトを行なっています。多分、これから店舗統廃合のお知らせが届く人もいると思いますがそれ関連。それを作ってる最中にアレが起きちゃったので、非常に混乱しましたが、今は落ち着いているようです。

テスト

まあ、そういう社会性のあるシステムです。多分、別の業界の人が見たらアホかと思うようなテストの山、紙の山です。銀行システムのテスト工数が削減されない一番大きい理由はエビデンスの検証作業を決しておざなりにしないこと、その結果としてペーパーが増えてしまうことです。

しかし、それは高コスト体質の原因だということはわかっているので、改善をしようという努力はされています。リファクタリングが銀行システムでほぼ有名無実なのは、変更したモジュールのロジックが本当に使われているすべての機能に影響を及ぼさないかを必ず検証しなければならないということにあります。つまり、大量のリグレッションテストが必要な変更はできるだけ避けるということです。

しかし、それでは例えばSOAやらなんやらのコンセプトを導入してシステムを疎にした成果が得られたとはいえません。なので、テストの自動化については真剣に取り組んでいます。結果として、死んだ目をしながら端末を叩くテストフェーズというのは削減されつつあります。

また、テストの内容についても、リスクベースでのテストケース作成の考え方を取り入れつつあります。つまり、「全てを完璧」というのは費用対効果が悪すぎるため、問題が発生する可能性がある箇所を重点的にやりましょうということですね。そんなの常識じゃない?と思う人もいると思いますが、常識ではありませんwww自動化の目的だって、「自動なら全量テストするの簡単だもんね(2回目以降はな!)」ですからね。これ、本当はシステム開発のあり方としては他のほうがおかしいって言っちゃえるかもよ。

言語とアーキテクチャ

もうホストでCOBOLって時代でもありません。基幹系にもJavaやらなにやらが入り始めています。重要なのは大量のトランザクションに耐えうるかどうかですから、もはやホストの優位性はプリンターがアホみたいに速い…じゃなかった、ことOLTPにおいては高効率を誇る階層型DBとの組み合わせにおいてくらいしかなくなりつつあります。でも、もう業務も階層型使うのヤだからホストであってもRDBMS使うケースが増えてきています。

ただ、ここには問題があります。どうしても、ホスト脳が抜けないので、設計が…

Javaでもなんでもよいのですが、アーキテクチャなりの設計が必要なので、まず基本設計の時点でホストしかやったことがないのでオープン系アーキテクチャの実装をわかっていない人が設計をするという恐ろしい事態。これを乗り越えられないと単に使う言語が変わっただけになってしまいます。

言語にアダプトするのではなく、設計者に言語をアダプトさせるという恐ろしい世界です。ほら、某富士通の某BUGLESだっけ?あれとかホスト技術者のためのJavaフレームワークにしか見えません…

運用とか、障害対応とか、リリースとか、そういうあたりが全く違う世界なので、ITフェーズあたりになって問題が顕在化することが多くて困ります。

勤務の実態

これはもうどのポジションに居るかによりますね。

銀行及び銀行のシステム子会社は労組もうるさいので、最近はアホみたいな残業を許容しなくなっています。それにともなって現場に居残れなくなったりする場合はわりかし「上が帰らないから帰れない」みたいなものはなくなってきています。

一方で、ベンダーの配下で別拠点開発とかだと最悪です。ベンダーは完全に一括委託で仕事を受けてたりするので、工数が膨らんでも追加のお金が出ず、責任のなすりつけ合いになったりします。銀行のシステム子会社ときちんとした関係を築けている会社の配下でやっていれば、工数もそれなりに妥当になってきますし、無理難題について一蓮托生なのでお金がちゃんと出たりします。

僕の現場なんかは定時になるとするすると人がいなくなっていく状況です。

もちろん、ヤバイ時はヤバイです。でもそれって銀行だからどうこうではないでしょ。銀行システムは先に述べた通り、どうしてもエビデンスの検証とか、テストケースがアホみたいに多いとかがあるため、他のところから来た人がいつもの感覚で見積もってWBS引いたら後で全然足りないことがわかって青ざめる、みたいなトラブルになったりしますけどね。ヤバイの大半は見積の失敗や値引きやユーザの動きが悪くて結果としてみたいな原因がちゃんとあります。ぶっちゃけ自分たちのせいじゃね?

技術者のレベル

これはな…どこにいってもそうだと思いたいけど、ちょっと寂しい限りです。

やっぱり知らなくていいことが多すぎる→業務とプログラムのことしか知らない→アーキテクチャレベルの設計ができないというスパイラルにハマっている人が多すぎます。

日常業務の中で学べることは限られていますし、開発フェーズの後に続く長い長い長い長い長いテスト期間(18ヶ月くらいテストしてるよ今…)のせいでどうしても事務作業が中心になってしまうことが問題でしょう。

しかも、中身を押さえていればいるほど「この人は現場においておいてね」ということになってジョブのローテーションにも支障が出てしまうという…

結果として、自分で学ばないと新しいことは何一つわからない、という状況になります。

新しい技術

銀行システムってのは、言ってしまえば単なる事務システムです。ただ、その事務量が半端ないため、システム化をすることが非常に効果的なわけですね。お客さんよりのフロントシステムはわりと新しい技術を使うことも多いです。特にセキュリティー周り。セキュリティー周りについては一般の企業より厳しい基準があるため、わりと面白い…かも…

反面、新しいデータを使って何をやろうかとか、新しい技術を使ったサービスをやろうということはあまりないですね。とはいっても、iPadを使った店舗や営業のシステム、仮想デスクトップを使った海外拠点端末の構築と管理、ビッグデータ基盤を使ったマーケティング分析なんてのには手を付け始めていますよね。

決して技術を無視しているのではないですが、開発現場が事なかれ主義に陥りがちなので及び腰の場合も結構あります。ものの性質上、情報系システム側ではわりと新しい仕組みが試されることが多いですね。一方で情報系システムは勘定系ほど重要視されなくて予算が少なかったりします(ただしデータを貯めこむための予算は潤沢)。

単価

ここ最近の単価低減は正直厳しいです。その値段だとその値段なりの人間しか集まらないけどよいですか?といいたいわけです。購買はアホではないかとたまに思います。なぜなら「平均単価を下げろ」というからですね。そうじゃないでしょ?これだけのボリュームの仕事をいくらでやる。そのために単価の高いプロフェッショナルを入れる代わりに頭数を減らしたいのです。一括委託契約なのになぜかその金額は単価換算されるとか頭おかしいです。

という現状を打破するための工夫を日夜しなければならないのですよね。そういう無駄な努力がシステムのクオリティーを下げているというのは経営問題だと思うんですけどね。ホントこれだけは馬鹿馬鹿しいです。

清水鉄平清水鉄平 2012/11/15 17:55 「大きなトピック」の片方の現場にいましたけど、ソース1行変更するだけでも
厚さ30cmくらいエビデンス印刷とかやらされてましたわ。
あんなもん後で確認なんかするわけ(出来るわけ)ねーだろって皆言ってました。
しかもそんな面倒な手順を踏んでるのにバグが見逃されてたりとかありましたね。
もうアホですね。

NOV1975NOV1975 2012/11/15 18:03 それは酷いwww
ただ、本当に問題が起こった時に金融監督庁に「テストはちゃんとやった」と言うためだけでも必要なんですよね。
もう一昔前はもうちょっといい加減でした。

abcabc 2012/11/16 02:55 そして数百数千枚のエビデンスに1枚当たり目視・赤ボールペンでレ点チェックを百個以上入れるとかありました。

NOV1975NOV1975 2012/11/16 07:17 そうやって、目が見えないグリッドを見れるようになりますw

IGIG 2012/11/17 00:33 マルサの人は大量のエビデンス読んで突っ込みを入れてくるみたいですけどね.
「ここの数字がおかしい」といった.=> 実はバグだったというオチ.
大手製造業の話ですが.
税務調査というのは凄いものだなと.
金融庁の監査はどんなもんなんでしょうね.

>ホスト技術者のためのJavaフレームワーク

これはよく遭遇しますねw
しかし,JVM で動く COBOL があってもよさそうですけどね.
「COBOL 風」に Java で書くくらいなら,COBOL で書いて,
Java バイトコードにコンパイルした方が良いと思うのですが.
(.NET の CLR 向けには某富士通の NetCOBOL というのがあったりする)

NOV1975NOV1975 2012/11/17 00:48 金融庁は中身そのものと言うよりはきちんとテストをされているか、ルールはちゃんとしているかなどを調べる感じですね。実際に立ち会ったことないからわからないけど…

あと、NetCOBOL使ったところで、オブジェクト指向無視してたら結局頓珍漢なコードができるだけじゃないかと思いますw

IG IG 2012/11/17 13:39 > あと、NetCOBOL使ったところで、オブジェクト指向無視してたら結局頓珍漢なコードができるだけじゃないかと思いますw

バッチ系はオブジェクト指向でなくても良いのではないかと思います.スループットの勝負ですから,オブジェクトの生成・回収コストも惜しみたいところ..NET はスタック上にオブジェクトを生成できるので,Java よりはマシでしょうけど.

Java の場合,10 進数演算の言語組込み型がないですから,COBOL を使いたくなる気持ちもわからなくもないのですよね..NET は 10 進浮動小数点数は言語組込み型にありますが,事務系で一般に使われる 10 進固定小数点がない.Java の BigDecimal は固定小数点もサポートしているわけですが,演算子オーバーロードがない.

汎用機は 10 進数演算のハードウエア実装まであるので,事務計算では,COBOL+汎用機というのは,かなりパフォーマンスは良いです.Java や .NET に移行すると,大抵問題になるのが,バッチ処理なのですよね.ホストと同等のパフォーマンスは,どうやっても出ないですから.

そこで Hadoop を使って,という話もありますが,ハードの増設は高くつく(メーカ・サポート費用,お守りをする人の人件費,土地代,電気代)ので,それなら,汎用機の方が... となりそうです.

NOV1975NOV1975 2012/11/17 15:04 IBMはPOWER6あたりでJVM用の10進演算コプロを実装してますね。
バッチはどっちかというとI/Oのスループットの差かなあ。それもだいぶ差が縮まりつつありますね。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/NOV1975/20121115/p1