サグラダファミリア完成まで後15年とかゆうけど日本企業の手にかかれば1〜2年で完成するんじゃないの？とか思ってたけど実際見たらそうは思えなかった。 pic.twitter.com/Ut5kfF7vBz
— Reiko.K (@HACCI1984) 2014年2月25日
しかし、次期シスの話、ずいぶんと前から間に合うわけない、って言われてたのに、この時期になってリスケとか、根本的にIRのプロジェクト管理能力の欠如を示したものじゃないだろうか？ まったく、傘下してるベンダーはお気の毒である
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27みずほ銀、システム統合１年延期 １７年春に http://t.co/bHLmhR2UL6
— 47NEWS (@47news) 2014, 2月 27
日経の記事では「システム統合」とあるが、前から述べているように、次期シスとは旧BKの勘定系システムSTEPSと、CBの勘定系C-Baseを片寄せ統合するような一般的な統合ではなく、STEPSともC-Baseとも異なる別のシステムを新たに開発した上で統合するというリスクが高い計画
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27CB＝みずほコーポレート銀行（日立製作所製メインフレームC-base）
基本的には、STEPSとC-Baseに加えて、銀行に統合が予定されている信託のシステムを加えた三つのシステムを一つのシステム基盤に統合するという計画で、このような統合計画は、メガバンクと呼ばれる規模の銀行で考えても国内では例がほとんどない
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27次期システム、桜田ファミリアと名付けた方がいいんではないか
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27桜田ファミリアの機能美と芸術性 その1 「完全なる刷新」
では、次期シスがどういう点がハードルが高いのか、というと大きく分けて三つある(これは次期シスの優位性でもあるが)。一つは、完全な旧システムの刷新である。元々、STEPSは88年に稼動した老朽化システムであり、稼動当時でさえ、70年代の第二次オンラインシステムの改良程度だった
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27相対的に古いシステムを、継ぎ足して無理やり維持してきたというのが実態だが、一方のC-Baseも元々は長信銀で大量の銀行トランザクションには向いていなかった興銀のITISをベースに作られた。両者の後進性は、大手銀行では当たり前の、システム間連携ハブがない点が際立っている
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27C-baseには00年代半ばに、ハブが追加されて各システム間の連携が容易になったが、大量の顧客からのATM取引や振替処理を抱えるSTEPSにハブがないというのは、膨大な経費を垂れ流しているに等しい。
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27また、システム運用上も、バッチ運行システムが欠如していて、ABENDしたバッチのリカバリに失敗すると、手でバッチを動かさないと開局処理もまともにできない、といった運用上の問題もある。これが2011年3月のシステム障害の要因となった
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27このように、およそ先進国の主要銀行とは思えないほど退廃的なシステムをベースに、CBとBKの合併後の統合システムを作るくらいなら、いっそ統合と同時に作り直したほうがいい、と考えるのも経営側から見れば無理もない。ただ、実際できるかどうかは別の話になる
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27桜田ファミリアの機能美と芸術性 その2 「マルチベンダー」
二つ目の新しい点として、システム開発とハードウェア調達を分離した点である。STEPSは、富士通製大型メインフレームで、C-Baseは日立製大型メインフレームで、TBのシステムはIBMの大型メインフレームで稼動していて、ハード納入を行っているベンダーが、システム開発の主要パートナー
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27こういった、ハードウェア納入業者がソフトウェア開発も請け負う、というのはメインフレーム時代のシステム開発では一般的な手法なのだが、ハードとソフト両面で人質に取られて、システムを使い続けるうちは、巨額の保守コストを支払うという形になる
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27何しろ、メインフレームというのは、単体では販売されていない代物で、基本的にレンタルに近い販売方法を取る。ハードを使うだけで、月額いくらという基本料金があって、そこにさらにCPU使用率に応じてCPU料金、OS料金、ミドルウェア使用料金と、ワークロードに応じて課金される
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27なので、どうしてもハードの納入ベンダーとソフトの開発ベンダーが同一だと、システム丸ごとのコストがかかりやすいという側面が一面ではある。まぁ逆に言えば、そういった体制でもベンダー間の競争があれば、コストを削減しやすいのだけど
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27次期システムでは、特定のベンダーをプライマリとせず、システムの機能ごとにソフト納入ベンダーと、ハード納入ベンダーを入札で競わせて、別々に納入させるマルチベンダー体制をとった。これもあまり例がなく、SMBCのシステム統合のときくらいしかない
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27具体的に言えば、流動預金系のシステム構築は富士通が担当し、ハードと基盤納入はIBMが担当する。ハードはIBMのSysmtem/Zで、基盤システムはIBMのSAIL/IMSを使う。融資系と外為系システム担当は日立で、ハード納入は日立が行う。システムはAIXとLinuxを使う
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27信託系のシステムはIBMが担当し、ハードは日立が担当する。こちらもAIXとLinuxを使う。定期預金と営業系は富士通が開発を担当し、営業系のハード納入は富士通が、全銀接続はデータが開発を行うが、サーバ側は日立が担当する。こちらもAIXとLinux
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27言ってみれば、アプリケーション担当は現在のSTEPSとC-base、TBシステムを担当する富士通、日立、IBMがそのまま担当する。現行のシステムを移植するのだから、入札したとしてもこういう担当区分になるのは当然といえばそうだ。一方でハードは現行システムとは別のシステム基盤になる
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27ハード納入はマルチベンダーというよりも、納入は日立が圧倒的に抑えている印象がある。日立はIBMのAIXサーバを自社で作ってるので、IBMを外して金額的にはでかいところを抑えてる印象がある。一方で、流動預金系のハードと基盤納入はIBMが抑えている。ハブに相当するシステムで最も重要
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27SAILは、IBMメインフレーム上でしか動かないミドルウェアではあるが、金融トランザクションシステムでは世界標準のシステムで、定評の高いシステムである。これに、各システムとの連携を行うハブシステムにはおそらくWebsphia MQが使われるだろう。こちらも標準的なソフト
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27ハブと基盤を抑えているというのは、ベンダーとして優位に立てる。何しろ、他社が開発したシステムのインターフェースが全部ハブに集まるので、ハブを握っていれば他社のシステムの状況がわかる。だから、大規模基幹システムでは、ハブを握っているベンダーが営業上マルチベンダーのとき強い
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27一方で、流動預金、定期預金といった基本的な商品・アプリケーションは富士通が握る。すべてのシステムが、流動預金になんらかの連携を必要とするので、ここを握っている富士通もまた圧倒的な優位性を持つ
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27いいかえると、重要なところを三社がそれぞれ握っているわけで、この三社をうまく統率する、開発元(IR)のプロジェクトマネジメントが少しでも狂うと、全体が崩壊してしまう。まぁ最初から狂いっぱなしだったんじゃないか、と思ったりするのだが
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27桜田ファミリアの機能美と芸術性 その3 「サービス指向アーキテクチャ」
三番目には、サービス指向アーキテクチャ(SOA)でのシステムの再編である。元々、80年代に完成の域に達した邦銀の第三次オンラインシステムは、勘定系システムを中核として、CIFベースの共通情報をベースに、独立した周辺系システムがバッチベースでデータを共有するシステムである
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 2790年代には、緩やかに解体に向かい、その典型が勘定系を中心とした垂直的統合的なシステムから、ハブをベースに共通的なデータフォーマットで各システムが対等にデータを交換するハブ・アンド・スポークアーキテクチャに再編されてきたことである。先進的な三菱東京UFJやSMBCが典型的であろう
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27ところが、世代的には第三次オンラインでも、それに大きく乗り遅れたSTEPSとC-baseは、そういったゆるやかな三オン解体の流れに進めるのではなく、業態別の銀行自体を統合した上で、各システムが提供している機能をサービスとして再編するというドラスティックなシステム再編を目指している
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27この構想は、元々00年代にBK/CB/TB三行の合併がまだ検討段階に至っていないところで、合併を行わずにシステムコストを削減するために長年温められてきた考えでもあった。すでに、三行のシステム開発子会社はIRに統合されていた(運用子会社は別)ので、その延長ではあるが
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27例えば、子銀行に商銀と信託を抱える三菱UFJの場合でも、商業銀行のシステムと信託銀行のシステムは別であり、それぞれ勘定系システムを持っている。法人が違うので、預金勘定は別としても、要するに流動預金を扱うシステムは一つのシステムで提供し、ドメインを分ければいいという考え方もできる
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27つまり、信託銀行は共通の流動預金システムに移行することで、スケールメリットが生かせない勘定系の開発運用から開放され、信託系システムの開発運用に専念できる。ただ、実際には信託銀行と商業銀行の勘定系システムは、技術的にも内容的にも大きな差があるので、統合は非常に難しい
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27次期シスは、これを一歩進めて、システムだけでなく法人としても単一の組織として、それぞれの業態で分かれていたシステムの機能を集約化して、ある種のオブジェクトとして呼び出せるように再編するのが目的である。流動預金だと、相対的に規模が大きいSTEPSを担当する富士通が開発を行っているが
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27こういったSOA的なシステム統合になると、極めて重要なのはシステムが提供できるサービスと、実際に各銀行で動いているシステムに実装されている業務とのギャップである。ERPのような業態に共通する業務を抽出したパッケージに合わせてギャップを埋めていく、という方式は金法以外では普通だろう
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27しかし、そういった標準がない場合や、業態標準と自社の業務が乖離している場合にはどうなるのか？ 一つの考え方としては、規模の大きいシステムに他のシステムをあわせる、という考えもできる。しかし、これとて何を標準にするかで、大変もめる。
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27例えば、トランザクションの規模や顧客数の多さならばBKのシステムにあわせるほうが合理的である。一方で、原に収益を産んでいる部門で、大量の法人取引という点ではCBが勝る。別の視点でみると、周辺系システムの複雑さの点ではTBがたのシステムにあわせるのが難しい
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27既存のシステムベースに他のシステムをあわせる、ならまだ楽なのだが、共通の合理的なサービス基盤を作って、それにあわせるとなると事前のシステム企画や基盤技術の思想が重要になり、仕様策定が大きなボトルネックになる。
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27だから、単純にシステム構築となると、要件定義に膨大な工数がかかるし、単純に使うハードとか、ソフト基盤のコストなどというものは、要件定義段階のコストや、方向性によっては大したコスト要素にはならない。バッファがある分、レガシーなシステムを使ったほうがリカバリが効くという側面がある
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27見えない桜田ファミリアの完成
大規模プロジェクトにおいて、リスケしますといった場合に、「システムがもうできてるけど品質に問題があるから伸ばす」ってのと「要件定義が遅れてるので全体が遅延してます」ってのでは全然話が違う。というか、後者の場合だと話しにならない。そりゃ、1回遅延しました、って話じゃ終わらないのよね
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27結果としては、リスケして現行の体制で開発は継続、という決断になったといえるのだけど、決断としてはプロジェクトを一旦やめて、やり直すという方法もあったかもしれない。ただ、ここまで関係会社を巻き込み、国家プロジェクト並みの大規模な話になってるわけで、やり直すって選択はないだろう
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27だからこそ、このプロジェクトはヤバイ。ゴールが見えないし、なんか昨年の半ばから猛烈な勢いで人集めてるけど「リーダーが病気退職したために」とか、腐臭の漂うような話しか聞かないのである。しかも、何か予算も拡張すると同時に単価が下がってきて人も集まらないみたいだし、もうだめかもわからん
— 第十三営業部担当死刑執行役員つっちー (@tsuchie88) 2014, 2月 27
コメント
コメント一覧 (30)
あの時は、統合期日の1週間前に「もうダメぽ、間に合わない」って泣き言が入ったんだっけ。
年度末のきついスケジュール中に、「大丈夫、みずほよかマシ」と自分を慰める足しになったもんだ。
それに比べれば、2年も前に延期してる分だけ、進歩したんじゃね？ と思う元SE。
バグっていたら､どこが問題かわからないし｡
あとなんだかんだ言っても､会社またぎだと非協力的になる｡
みんな身内と他人を状況に応じて使い分けるwww
マザー2とか､WindowsVistaとか､スルガ銀行とか､特許庁のシステムとか｡
ただ全権を持つ人に､プロジェクトマネジメント経験と､システム開発経験がないと､完成しなくなるwww
後者の二つのように､ベンダー丸投げの場合は､失敗する傾向｡
あのまま現場で漂っていたらこのプロジェクトに流れ着いていたかもしれない。
ハードとソフトと機能でベンダーをシャッフルした様な体制図が
見事に狂気で絶対関わりたくないよなーって思ったからなあ。
http://itpro.nikkeibp.co.jp/article/COLUMN/20121116/437901/
風呂敷どうやって包むのかね
いまそんな状況なのか
独禁法のせいで富士通と日立入れてるんじゃないの
BTMUやSMBCみたいに吸収合併で旧BTM、旧住友に片寄統合したわけじゃないのが、完全に裏目に出てる。
システム開発だったら一から作り直し。
株だったら損切り。
山登りだったら撤退
戦争だったら講和か。
発想は無かったのかね？
ゼロから開発するより開発コストが抑えられた上に、安定したシステムになったと思うが。
UFJのシステム買った郵貯は賢い選択だったよね。
金融SEはいいぞ
残業三昧のうえ帰宅中は閉店後なので
お財布もりもりだよ
才能があればね。
業界を脱出したいわ
「仕様書を書ける日本人しか要らない」「プログラマは中国人の仕事」とか面と向かって派遣会社の面接で言われたので業界を脱出して正解やったわ。
2度の障害、統合後初統一
2017/5/3 00:05
https://this.kiji.is/232156120851988483?c=39550187727945729
やっと完成か