(cache) 銀行SEの現在

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

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

参考：

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

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

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

テスト

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

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

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

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

言語とアーキテクチャ

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

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

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

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

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

勤務の実態

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

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

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

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

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

技術者のレベル

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

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

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

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

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

新しい技術

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

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

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

単価

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

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

Permalink | コメント(2) | トラックバック(0)

コメントを書く

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