狠狠撸
Submit Search
50歳まて?に达成したいこと(国内银行勘定系システムの近代化)
?
0 likes
?
559 views
Hirofumi Nakata
Follow
滨叠惭メインフレームでの国内银行勘定系システムの近代化
Read less
Read more
1 of 2
Download now
Download to read offline
More Related Content
50歳まて?に达成したいこと(国内银行勘定系システムの近代化)
1.
50 歳までに達成したいこと(国内銀行勘定系システムの近代化) 仕事面で50歳までに達成して終わらせたいことを書こうと思います。 前にも狠狠撸share にも掲載しておりますが、IBM
メインフレームで稼働している国内銀行勘定系システムの近代化です。 確かに決済系は儲からないといってあえてやっていない銀行さんもあります 。 でもないと困る社会インフラですし。24時間全銀ネット稼働となると国内での現金の流動性が上がり、どの程度の効果は わかりませんが多少なりとも経済効果あるとは考えています。 国際的な話では日本銀行などの中央銀行オンラインの稼働 時間が拡大すれば、多国間通貨同時決済(SWIFT CLS 同日決済)こちらのメリットを補完できるものと考えます。 すで に海外から日本へくる観光客が日本の決済インフラの不便性がかなり指摘をされていて、かなり従来の勘定系システムのス ピード感のあるサービス追加が必要になってきています。 これを実現するための決済インフラはすでに24 時間対応を盛り込んだと言われている新日銀ネットに接続をして、24時 間稼働対応の全銀システムに接続するにも改修が必要になります。 とにかくスピードが命になると思ってます。 これを期待して、Java+IBM メインフレームで構築しようとした例があり、失敗した例があります。 私の考えもJava で構築するという考えですが、UML などで部品や処理を明確にしたいという思いがあり、そのような考 えを持っています。 今のところ、IBM メインフレームで稼働するシステムは開発言語は PL/I が主に使われており、DB/DC については IMS FP DEDB と IMS の使い方の中でもかなり特殊な部類で確かに早いのはいいのですが、メンテナンスがバカにならない仕 組みです。 まだ余裕のある、メガバンクさんはこの辺の要員についての心配はまだ先ですが、今のIT 業界の構造から言ってあまり良 いとは思えません。 現に地銀さんではアウトソーシングをしていますが、あれは個人的には新しい商品を出す際にどうしても遅れが発生するこ とと、完全にブラックボックスになるのは良いとは思えません。 では、アメリカのようにほとんど内製化というのはある意味今の日本では現実味がありません。ただ、開発、構築主体は昔 のように銀行に戻すべきです。 銀行内にも実際に手を動かしている人間がいないと、なにか起こった時のインパクトや原因を詳細に把握することは難しい うえに、このような障害が連発してしまうと、その他の手数料ビジネスやそういった部分にもなんらか悪いイメージがつく のではないかと考えます。 じゃ、どうしますか?ということで私の意見を書きたいと思います。 実は細々に書いていた部分はありますが、全てこれにつながります。 1つ目はホワイトカラーの生産性の向上です。 私も銀行勤務経験から、紙がとにかく多いうえにりん議プロセスが長いうえに、余計なことをたくさん説明しないといけな い状況になっています。 私から言わせれば、いきなりなくすという考えは毛頭ありませんが、実行部隊と切り離して銀行の社内文化に対応するチー ムと実行部隊の連携しながらというほうがいいような気がします。実行部隊が一緒になるとこの処理に追われすぎて実際、 目的はなんでしたっけ?という状態になります。最終的な目的は全員で共有し、ここのミッションを明確にイメージするこ とでモチベーションを高めようと考えなので、極力分業化して自分のミッションをできるだけ狭くしつつ、全体ではこの部 分をやっているというイメージを持ってもらうのはとても重要です。
2.
2つ目は内製化により、自行の業務を伝承する 銀行が過剰なほどのリスク対策を行う理由の一つにプロパーが自行のシステムを把握していないというのがあります。知ら ないものにはよくわからないのでリスク対策をしすぎてしまい、どうも過剰と言えるテストが多いと思います。 やらないよりやったほうがいいですが、この部分で時間がかかり過ぎています。 3つ目はプロバーだけで要件定義を行う、生産性向上のための開発手法の工夫 システム開発の一番失敗する原因は要件定義の部分での不十分さにあります。 もっとも多いのが突然の要件定義変更により手戻りですが、こちらもプロジェクト体制設計において、緻密なルール作りが 必要と考えます。 手戻り対策しては、ステアリングコミッティーを必ず定期的に開催して、そこで変更のインパクト、変更の必要性をある一 定の役職者で審議する仕組みを作ることがいいと考えます。ヘルプでベンダーさんに入ってもらう必要はありますが、あく まで主体は銀行です。 ベンダーさんにRFP を書いてもらっているレベルではお話にならないと思います。 あとは開発手法ですが、ウォーターフォールかアジャイルか? 個人的にはハイブリッドがよいと思います。システム基盤に近くなる部分はウォーターフォールになるとは思いますが、業 務レイヤーでは併用してもよいと考えます。 今の大規模開発は要員数が多すぎます。 質が悪いといってしまえばそれまでですが、お金を出しても来るかどうかという状況で、出したら出したで中抜きさんの利 益になるだけでこちらとしてはお金の出し損です。 今時は偽装業務請負も横行して、そもそもそれだけ中抜きされた人にモチベーションがあるかも謎です。かと言って、再委 託禁止としても、また今度は偽装契約社員と。エンジニアのモチベーションアップに金銭というのは重要なモチベーション であり、品質に大いに関係する部分であります。 なるべく少ない人数、少数精鋭でやれたほうがマネージメントも効率はいいです。 多分これを実現するなら、プロジェクト設計、体制検討、要件定義にかなり時間がかかります。 私はここまでいろいろ細かいキーワードを出して、今回はこれを全部くっつけて最終的に何がしたいのかを書きましたが、 これを50歳までに完成して達成させたいのですが、自分の性格的には木を見て森を見ずではなくて、森をみて木をみると いうのが性格に合っているので、これをやらせてもらえる舞台はあれば是非参加させていただきたいです。
Download