遊撃部長F/S&RWAs
- いいね数 159,898/179,002
- フォロー 857 フォロワー 17,781 ツイート 123,666
- 現在地 桐咲フィナンシャルグループ 第拾壱電算室
- Web https://querie.me/user/fstora
- 自己紹介 財務会計とALMとBIS規制の不幸な隙間より生まれいでたる名前を消された管理職
2016年07月09日(土)
@ALPHA_GEEK 一部は想像。特にSTEPSの構成は昔の図を元にしてるからかなり変わってるかも。次期死すの構成図もかなり脳内補完
itpro.nikkeibp.co.jp/atcl/column/14...
itpro.nikkeibp.co.jp/article/COLUMN...
itpro.nikkeibp.co.jp/members/NC/ITA...
タグ：
posted at 17:50:54
非公開
タグ：
posted at xx:xx:xx
現行システムと次期システムの図さすがに雑なので作りなおした(しかし相変わらず雑)
色は担当ベンダー
黒 日立
赤 富士通
青 IBM
緑 NTTデータ
(配色に他意はありません) pic.twitter.com/OKowqivCrC
タグ：
posted at 16:48:41
非公開
タグ：
posted at xx:xx:xx
非公開
タグ：
posted at xx:xx:xx
非公開
タグ：
posted at xx:xx:xx
デスマーチとは、撤退のふんぎりがつかないままダラダラと開発が長期化することを言うが、課初の序盤から要件定義に問題があって開発期間が延長されるなど、みずほ次期死すはかなり異様な感じでプロジェクトが推移しているように思える。
タグ：
posted at 13:13:20
さらに遅延が長くなってしまい構築中の新システムが目指していた目標が達成できないことがわかると、プロジェクトはカタルシスに達する。そうすると、完成している一部のシステムを部分的に稼動させ(現行システムと接続するために追加の開発が必要)るなど、完全には無駄にはならんものの大損害になる
タグ：
posted at 13:10:00
開発がさらに遅延すると、今度は現行システムの維持が困難になる。システムの処理能力が不足することになるし、金さえかければ一般的な保守期間を延長することができたとしても、かなりの費用がかかるようになるし、それにも限界がある(20年前のHWを動かした例はあるけどさすがに無理み)。
タグ：
posted at 13:05:02
そうすると、現行システムにも新システムにも同じ機能追加を行わなければならないし、必須ではない機能追加は稼動後しばらくしてから追加という形になるので、プロジェクトの遅延は営業上かなりの問題を生じさせる可能性が高い。24時間振込対応の遅れとかが典型的かもしれない
タグ：
posted at 12:51:41
プロジェクトが長期化してしまうと、時間軸の問題が出てくる。新システムの開発に大量の資金と人材を投入する一方で、現行のシステムも維持しなければならない。新システム開発中は現行システムへの機能追加や改良は原則的に行わないことが多いが、法令対応など最低限の改良は必要になる
タグ：
posted at 12:49:25
また、片寄せ統合の場合、総合テスト段階で問題が発覚しても手戻りは追加で開発したギャップ部分に限定されるので、手戻りは軽度で済む。ところが、統合と刷新を同時に行うと、プロジェクトのかなり初期の段階で入った問題になる可能性があり、手戻りは大きい
タグ：
posted at 12:44:03
これがうまくできないと、仕様どおりにシステムができたのだけど、既存システム(たとえばAシステムとBシステム)どちらのシステムともギャップができてしまって、使えないシステムになってしまう。だからこそ、要件仕様の段階でもパワーが必要だけど総合テストとユーザーテスト段階でもパワーがいる
タグ：
posted at 12:39:29
片寄せ統合の場合、基本的に差分となるギャップ部分の開発を行って、後は処理能力を上げるだけなので、比較的リスクは低いのだけど、統合と刷新を同時に行おうとすると、要件定義にかなり時間をかけて統合後のシステムが現行システムと同じ動作ができるような確実な保障を行わなければならない
タグ：
posted at 12:35:44
こうして、システム統合とシステムの刷新を同時に行うという壮大なプロジェクトになってしまったわけだけど、そうするとプロジェクト管理をよほどうまくこなさないと、大きな問題につながってしまう。(セゾンの基幹系統合の失敗みたいに)
タグ：
posted at 12:29:21
一方で、サービスのそれぞれを統合するHUB部分と、銀行業務の中核となる為替・融資システムの構築は日立が請け負い、HW部分も日立製のAIXサーバとLinux/IAサーバが使われる(日立はIBM製CPUを使ってAIXマシンを売ってる)。TBの信託系システムはHW、構築ともにIBM
タグ：
posted at 12:18:48
一方で、定期預金系のシステムはやはり現在STEPSで担当している富士通が、営業店系システム(勘定系や情報系と並んで巨額のシステム投資が必要になる)も富士通が担当している。こちらは、富士通製のLinuxマシンとJavaで構築されて、システムから見ればサービス化されている
タグ：
posted at 12:14:51
それから、金融トランザクションシステムでは標準的なミドルウェアになっているSAIL/IMSが動くという点も大きかったのではないかと思う。System/z上で走るSAILでCIFを管理して、流動預金系の個別アプリケーションを富士通がCOBOLで実装するという形。
タグ：
posted at 12:09:08
System/zは情報系システム(主に旧富士銀の流れを持つIRの情報系システム事業部が担当)に先行して採用されていて、07年以降にチャネル系システムの統合(100台以上のメインフレーム・UNIXマシンを2台の仮想化メインフレームに統合)などにも使われてて、みずほでは実績が高い
タグ：
posted at 12:06:33
この後どういう経緯をたどったのは定かではないのだけど、少なくとも東日本大震災時の大規模システム障害後までにはHWとSW調達の分離方針が決まり、勘定系の中核となる流動預金サービスの開発担当は富士通に、HWはIBMのSystem/zとz/OSが採用されることになった。
タグ：
posted at 11:57:24
ただし、これは結果的には採用されなかった。STEPSの規模が大きいので、C-Baseのスケールアップには限界があったかもしれないし、同じ投資を行うなら新規に開発した方がいいという判断もあったかもしれない。そうすると、STEPSホスト(富士通)を使ってSOA化すると言う折衷案が出る
タグ：
posted at 10:42:49
NEXTCAPは、既存勘定系をそのまま活用して、勘定系から融資や為替機能を取り出してサービス化することで短期間に低リスクでシステム刷新ができることを謳っていた。これをそのまま適用すると、日立製ホストで動いている既存C-Base勘定系をSOA化して解体・再編するという提案ではないか
タグ：
posted at 10:40:20
この中でも、日立のNEXTCAP-SOAが現在の次期システムの姿に一番近いように思える。NEXTCAPは、その後Banks wareと名称を変えて大規模地銀向けにもセールスしている基盤で、勘定系コアをLinux/HIRDB化したのが現在静岡銀行で構築中のシステムに近いと思う。
タグ：
posted at 10:34:02
当然のように、富士通はSTEPSの近代化を、日立はC-Baseの近代化によって次期システムを狙おうとしていた。どちらも一長一短があるのだが、この段階で片寄せ後に近代化、または近代化した上で片寄せという手法を取っていれば、今のような状況にはなっていなかったのではと思う。
タグ：
posted at 10:27:15
さすがに、STEPSとC-Baseへの投資が一段落した06年頃から、みずほでは次期システムの検討が行われていたようだ。BKとCBのシステムを統合して、単一基盤上で二つの銀行がシステムを利用するという形態なのだが、そうすると既存ベンダーの富士通と日立どちらかは都銀での勘定系を失う
タグ：
posted at 10:25:16
予算が極度に限定された状態で投資を行おうとすると、必然的にローンや運用性商品といった稼ぐ力を補うシステム投資や、競合上インターネットバンキングやATM投資などのチャネル系の投資に力をいれ、勘定系の再構築にパワーが向かわなかったことがあるのではないかと思う(まぁ他行も同じなのだが)
タグ：
posted at 10:23:01
これに対して、BKはマスリテールが中心ということもあってCBと比べて格段にシステム規模が大きい。2400万口座を処理する巨大な基幹系システムを維持するには、それなりの収益力が必要になるのだが、CBと比べて収益力は低く、IT投資予算は限られたものになる。
タグ：
posted at 10:17:05
なお、このHUB導入に際しては、一般的にHUBの設計を多く請け負っていたIBMではなく、勘定系本体を請け負っていた日立が受注している。日立は、C-BaseでのHUB構築でメガ規模の金融機関でのSOAアーキテクチャによるシステム構築にかなり経験と自信をもったのではないかと思う。
タグ：
posted at 10:12:36
C-Baseは、STEPSよりもはるかに勘定系規模は小さいが、他のメガバンクと同じようにH&Sアーキテクチャを取り入れている。勘定系ホスト中心ではなく、周辺系システムのデータ連携にHUBを介してやり取りするため、プレSOAとも言える程度に整理されている。
タグ：
posted at 10:10:34
また、ホールセールが主体というCBの業務の性質上、基幹系システムの刷新は急務で、特にベースとしていた旧興銀のITISは、統合三行のホールセールとのギャップが大きかった。したがって、CBシステムは優先的に刷新され、C-Baseという名称になっている。
タグ：
posted at 10:05:45
これはこれで仕方がない側面もあり、過渡期の問題であるならその後に影響はなかったかもしれないのだが、STEPSはその後大きなシステム投資を経ずに、東日本大震災を迎えてしまう。理由は二つあって、一つはBKとCBの収益力の違い。CBは、ホールセール中心ということもあって「稼ぐ力」がある
タグ：
posted at 09:59:53
実際にわしも、システム統合後のBKのサービスでも、システムは統合されたはずなのに、口座を作った元銀行ごとに微妙にサービスが違うということがあった。しかも、どちらの口座がベースなのか、末端の銀行員でもよくわからないという混乱した場面によく出くわした。
タグ：
posted at 09:48:43
リスクが低いリレー統合で障害を起こしてしまい、社会的にも大きな批判を呼んだので、TOPS(旧富士)とSTEPS(旧DKB)のシステム統合は、機能の整理統合よりも、確実に現在ある機能をSTEPSが実装することがかなり優先されたように感じられる。
タグ：
posted at 09:46:29
BKのSTEPSの不幸は、合併直後の大規模システム障害に起因している。合併直後には、システムは統合されておらず、旧システムを相互接続しただけの、所謂リレー統合(片寄せ統合前に暫定的によく行われる手法)の状態で大規模障害を起こしてしまった。リレー統合は暫定対応だが元々リスクは低い
タグ：
posted at 09:44:29
みずほがこれにができなかった理由は、その統合形態に問題がある。リテール中心のBKと、ホールセール中心のCBに銀行自体を分割した上に、システムもそれぞれ個別に持つことになった。持株会社傘下に子銀行をいくつも抱えてるがシステムはひとつにまとめてるりそなとは対照的
タグ：
posted at 09:24:02
日本の都銀が、80年代の第三次オンライン移行(住銀の四オンを除いて)基本的に全面的な刷新を行わなくなったのは、システム規模が大きくなり業務への影響が極めて大きくなったからでもあり、時間をかけて勘定系ホスト中心だったシステムをSOA的なシステムに解体・再編していったからに他ならない
タグ：
posted at 09:17:46
MUFJやSMBCなんかは、貯蓄預金や国際キャッシュカードを早々に廃止してしまったりしてるのが典型的やね。こうして、追加開発部分をなるべく少なくした状態で、それでいて現実の業務が確実に統合できることを前提に統合作業が行われる。そして、システムの統合後に、全体的な刷新を図る
タグ：
posted at 09:12:08
しかし、この機能の重要性が低かったら廃止対象になるだろうし、Aシステムに似た機能があるのでそっちに移ってもらう(サービスの内容は変わってしまう)というのもある。そもそも、AB双方であまり使われてないから両方とも廃止という形もありえる。
タグ：
posted at 09:09:12
どちらかのシステムにあわせて統合するという手法を片寄せ統合と呼ぶのだが、片寄せ統合の場合でも統合前に事前の機能の整理が行われる。たとえば、Aシステムを採用するとしてBシステムにはあるがAシステムにはない機能は基本的には追加開発になる。
タグ：
posted at 09:06:23
みずほの場合も、規模の大きいBKではなくCBが存続会社としてBKを吸収合併した形になっているし、ホールセール業務など収益の根源はCBにある。ただしCBにはリテール業務がないので、CB側にあわせるとBTMUと比較にならないほど膨大な追加開発が必要になる
タグ：
posted at 09:03:25
たとえば、BTMUの基幹系統合の際は、システムのキャパシティとしては(2年前に統合したばかりなので新しかった)UFJ側のシステムではなく、BTM側のシステムが選ばれた。BTMは規模は大きいのだが、BOTとの統合から時間が経っていて、相対的にキャパシティが低かったにもかかわらずだ
タグ：
posted at 08:59:22
そういうわけで、基幹系の統合を行う場合には、たとえばAとBという異なるシステムを統合する場合には、AとBのシステムを比較してどちらのシステムに統合した方が工数が少なくなるかを分析する(F&G分析)。F&Gだけでなくそもそも企業の事業戦略にどちらのシステムが適しているかが加味される
タグ：
posted at 08:57:05
たとえば、前者の場合今までキー一つで印刷されてた帳票を、遊撃が4本のテーブルからクエリ引っ張って来る手間を増やすだけで済む話だけど、後者の場合いったん着陸した飛行機に機能が集約化されたからもう一度着陸やりなおせ、とは言えない。
タグ：
posted at 08:15:16
しかも、前者が業務を単純化してシステムの複雑化・個別化を防ぎやすい(業務は煩雑になるかもしれないが)のに対して、後者は現場の手順を変えることになるから、なかなか単純化がしにくい
タグ：
posted at 08:13:38
もう一つあるのが、基幹系の中でも財務会計みたいなシステムは重要なことには違いないのだけど、「まぁちょっとくらい止まっても決算業務に支障がなけりゃいい(遊撃がチャレンジすればいい)」んだけど、銀行勘定系とか航空管制とかネットショップの販売システムとか、止まると業務が止まって客が困る
タグ：
posted at 07:48:28
そらWeb系みたいな、新しい領域で新しくサービスを立ち上げる場合なら当てはまると思うのだけど、伝統的な企業が昔から使ってる基幹系を置き換える場合だと違うだろうよ、と(Amazon自体、クラウドで企業基幹系は領域違うで、といっとるしな)
タグ：
posted at 07:42:54
基幹系システムの刷新が難しいのは、技術的な問題というよりも影響範囲が大きいのでリスクのある刷新がやりにくいという点で、「欧米のシステムは新しいテクノロジーを使って費用安い！」なんてのは本当海外のシステム知ってるのか、と思う。
タグ：
posted at 07:41:35
@fstora @Matsukaze_Taka 問題はそこで、「時間をかければ＝追加の工数を入れれば直る問題」なのか「そもそも要件段階でのアプローチがダメだったのでかなり後戻りが必要な問題」なのかどっちなのか、ってところ。部外猫なので、まったく分からないのだけど、後者の可能性大
タグ：
posted at 07:38:43
