• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • PR

  • PR

  • PR

  • PR

  • PR

みずほ、復活への再挑戦

みずほ、復活への再挑戦

中田 敦、岡部 一詩 2012/07/30 日経コンピュータ
出典:日経コンピュータ 2012年8月2日号pp.56-67
(記事は執筆時の情報に基づいており、現在では異なる場合があります)
目次一覧

 システム全面刷新・統合をなんとしても成功させ、信頼回復に努めたい─。2度の大規模システム障害を引き起こしたみずほフィナンシャルグループのシステム関係者が、重い口を開き始めた。みずほがシステム関連の個別取材に応じるのは、2011年3月のトラブル以後、初めてのことだ。

 みずほは1年間がかりで再発防止策を講じ、現在は大手銀初となる勘定系システムの全面刷新・統合を進める。

 大規模障害の再発は本当に防げるのか。世界最大規模となることが確実な刷新・統合プロジェクトを、やり抜けるのか。そして長年の課題である、ITガバナンスを強化できるのか。みずほ復活に向けた再挑戦を追う。

1年かけてシステムを総点検

 分担の誤謬――。2011年3月の大規模システム障害でみずほ銀行(BK)が陥ったのは、勘定系という巨大システムを維持する上で避けて通れない、人や組織の役割分担がもたらす落とし穴だった。

 大手銀行の勘定系は、5000万ステップを超えるプログラムや、数十のサブシステムが複雑に絡み合う超巨大システムだ。みずほはサブシステム単位で担当者を置き、システムの開発や運用にあたってきた。さらに、情報システム部門は要件定義、システム子会社のみずほ情報総研はシステム設計、ITベンダーはコーディング、といった具合に実務作業を分担していた。

 作業の分担化が進むにつれ、システムの全体像を把握できる人がいなくなった。その結果が2011年3月のシステム障害だ。夜間バッチ処理の異常終了がもたらす影響や2次障害を想定できず、障害の大規模化と長期化を招いた。

 「個別のシステムには担当者がいて、それぞれのシステムの詳細を把握していた。しかし銀行業務は何十というシステムを連携させる必要がある。その全体を俯瞰する責任者がいなかった」。みずほフィナンシャルグループ(FG)IT・システム企画部でシステムリスク管理室に所属する田中伸一参事役はこう振り返る。

 システムの全体像を把握するのはITガバナンスの基本である。ITガバナンスの不全こそが、大規模障害の真因であった。

システムの全体像を可視化

 ITガバナンスを立て直すため、みずほは2011年3月のトラブル以降、1年間にわたり再発防止策に取り組んできた。

 その象徴が、図1に示す「データフロー図」を作成したことだ。「振り込み」「預金」「支払い」「税金」など15種類の決済業務を対象に、システム内をデータがどのように流れるのかを可視化した図である。

図1●みずほが作成した「データフロー図」
システムの全体像を把握するために、「振り込み」「預金」「支払い」「税金」などの15の決済業務を対象に、データの流れを可視化する資料を新規に作成した
[画像のクリックで拡大表示]

 BKのサブシステムを網羅し、それぞれがどう連携しているのかがつかめるようにした。外部システムから受け取ったデータをどんな流れで処理して、その結果をどの外部システムにいつ送るのかが一目で分かるようにもしてある。

 データフロー図は、FGやBKのシステム部門を中心に、利用部門やみずほ情報総研が総出で作成した。システム部門がたたき台を作り、利用部門やみずほ情報総研の担当者が参加する「ウォークスルー」を通じて内容をブラッシュアップした。

 15種類のデータフロー図を作るのに、およそ3カ月かかった。最初のバージョンは2011年秋に完成させた。その後、3カ月かけて内容を見直し、2度目のウォークスルーを経て最終的に2012年3月に改訂版を仕上げた。

 今までもシステム単位の仕様書は整備していた。業務の流れを示す資料もあった。だが、データの流れに注目して、システム全体を貫くデータフロー図を作成したのは、これが初めてだった。「一部の人間の頭の中にだけ存在したデータの流れを可視化することで“組織知”とすることができた」。FGの高取亮IT・システム企画部企画チーム次長はこう語る。

リミット値を洗い出し

 BKの勘定系システム「STEPS」は、第一勧業銀行(当時)が24年前に開発したシステムだ。当時のシステム構築に携わった担当者が引退するに従って、システムのどこに超えてはならない「リミット値」が存在するのか、あるシステムのエラーがシステム全体あるいは外部システム、顧客サービスにどのような影響を与えるのかが、すぐには分からない状態になっていた。データフロー図を作ることではじめて、みずほはシステム障害で顕在化した問題点を修正できるようになった(図2)。

図2●みずほが取り組んだ再発防止策のポイント
2011年3月のシステム障害で顕在化した問題点を改善した
[画像のクリックで拡大表示]

 例えば、システム全体を対象にリミット値を洗い出した。リミット値には、1口座当たり1日に最大何件処理できるかといった処理件数を示すものと、一連の処理を何時までに終わらせなければならないかという時間上の制限(時限)の二つがある。みずほは処理件数と時限の両面から、データフロー図を基にリミット値を見直した。さらに、リミット値に関するエラーが発生した時、その後の処理にどんな影響を及ぼすかを確認した。

 リミット値は勘定系やインターネットバンキングといったシステム単位で把握するだけでは不十分だ。例えば2011年3月のシステム障害で問題となった大量振り込みは、インターネットバンキングではリミット値の範囲内だったが、その後の夜間バッチ処理でリミット値をオーバーした。

 「商品やサービスを強化するたびに、様々なシステムや機能を追加しており、システムの全体像が分かりにくくなっていた。データフロー図を作ることで、ようやく全体像を把握できるようになった」(IT・システム企画部の高橋達浩副部長)。

エラー処理を強化

 あるシステムで異常が発生した場合に、後続のシステムに影響を及ぼさないようにするエラー処理についても、データフロー図に基づき見直した。例えば、「処理件数が口座のリミット値を超えた場合、その口座への処理を迂回して後回しにすることで、ほかの口座の処理に影響が及ばないようにした」(高橋副部長)。

 2011年3月のシステム障害では、特定の口座の処理がリミット値を超えたことで、預金元帳を一括更新するセンター集中記帳処理全体が異常終了した。このようなことが起きないよう、異常が発生した部分の迂回処理を強化した。

 「TARGET」と呼ぶ夜間バッチの自動運行システムを改修し、エラー処理におけるデータ修正などの復旧処理を、人手を介さずにできるようにした。2011年3月のシステム障害では、エラーデータを手動で取り除き、手動で正しいデータを再作成してから、処理を再実行していた。夜間バッチを中断した後の自動運用手順が無かったからだ。

 エラー処理の際に実行する自動運行ジョブのパターンや数を大幅に増やした結果、センター集中記帳処理で異常が発生してから復旧するまでの時間を1時間に短縮した。2011年3月のシステム障害では5時間かかっていた。

 夜間バッチ処理に限らず、自動化していないジョブフローについては、可能な限り自動化した。

情報伝達体制を見直し

 2011年3月のシステム障害では情報伝達体制の不備も浮き彫りになった。これについては「情報発信高度化部会」を設けて、改善に取り組んだ。

 特に重視したのは、情報伝達のスピードだ。障害発生から1時間以内に、CIO(最高情報責任者)に報告を入れる体制を整えた。システム障害の原因や顧客に与える影響が全て判明しない状態であっても、障害の概要について経営陣に報告するように改めたからだ。

 今までは必要な情報を不足なく用意しなければとの考えで、原因を突き止めてから報告していた。「報告の際のポリシーを変えることで、情報を伝達するスピードを向上できた」(IT・システム企画部の高取次長)。2011年3月のシステム障害では、担当役員が障害発生を知るまで、最初のトラブルから17時間かかっていた。

 システム部門から関連部門にも迅速に情報を伝達できるよう体制を整えた。システム障害が発生した場合は緊急対策本部を設けて、開発会社とテレビ会議を開けるようにした。対策本部から対外的な広報活動を展開すると共に、コールセンターや支店窓口からも顧客に適切な情報を発信できるようにもした。

 ここでもデータフロー図が役立った。システム障害の影響がどの業務に波及するのか、データフロー図から割り出せるようになったからだ。

 2011年3月の障害では、システム部門から対策本部に情報を上げる過程、対策本部から社内外に情報を発信する過程の両方に、情報伝達のボトルネックがあった。振り込み件数なども、各部門が個別の情報しか把握しておらず、全体で何件の振り込み遅れが発生するのか把握できなかった。そのため、外部に発表する数字にも誤りが生じた。

緊急対応の有効性を検証

 データフロー図を活用することで、リスク管理体制の整備や、緊急時の体制整備も進んだ。

 「システムリスク管理体制を総点検したところ、緊急対応マニュアルの不備や、作業フローが定型化されていない部分が見つかった」(高橋副部長)。そこで、マニュアルを大幅に修正した。修正した項目数は数千件に及ぶ。

 マニュアルはデータフロー図を基に、異なるシステムに横串を刺す形で整備した。従来のマニュアルはシステム単位で整備していた。業務視点で整備したデータフロー図を基にすることで、業務視点のマニュアルを整備できるようになったわけだ。

 新しいマニュアルでは、誰がどんなタイミングで何をやるのか、マニュアルの中に担当者名を入れて、役割を明確化した。従来は、緊急対応マニュアルを読むだけですぐに行動に移せるところまで明確に記載してはいなかった。

 作成したマニュアルの内容をレビューするのはもちろん、実際の訓練を通じて実効性を検証した。

IT人材育成の仕組みを刷新

 人事・組織体制も抜本的に改めた(図3)。みずほ情報総研から、必要な人材をFGやBKへ出向させるなどして、システム部門にノウハウを蓄える体制を整えた。みずほ情報総研の銀行システムグループ長は、FGのIT・システム企画部との兼任とした。

図3●みずほの企画・管理部門の人事・組織体制(2012年6月以降)
FGのCIOを務める安部大作氏が6月26日付でFGの常務取締役に就任。これに先立ち、2012年4月からFGとBK、CBの組織を統合している
[画像のクリックで拡大表示]

 今後は、システム部門が要件定義などの開発の各フェーズに対して関与を強め、中身の正確性をシステム部門自身がチェックできるようにする。

 2011年のシステム障害では、BKとみずほ情報総研の連携がうまくいっていなかった。みずほ情報総研側には、システムに詳しいスタッフもいたが、BKのシステム部門がそれを把握していなかった。そのため適切な人材を障害対応に充てられなかった。

 これまでは、個別システムや個別工程のプロはいたが、その周辺システムや前後工程まで分かる担当者がいなかった。「全体を俯瞰できるITのマネジメント層を育成するための枠組みを、人事部と協力して作り始めている」(高取次長)。

 現在はシステム部門と人事部が毎月定例のミーティングを設けている。今後はシステム統合を通じて、マネジメント人材を育成する考えだ。

 一連のIT人材強化策は、この6月にFGの常務取締役に就任した安部大作IT・システムグループ長(CIO)が推進する。安部CIOはFGのほかBK、みずほコーポレート銀行(CB)、みずほ信託銀行(TB)のシステム担当役員を兼ねる。

 従来はFG、BK、CBを兼ねるシステム担当役員がいなかったため、一元的な人事施策を実現しにくかった。

 表1のように、みずほが実施したシステム障害再発防止策は多岐にわたる。その中心には、常にデータフロー図がある。

表1●みずほが実施した主な再発防止策
[画像のクリックで拡大表示]

 みずほは業務の流れが変わる都度、データフロー図を修整する。それにより、システムの実態とデータフロー図の内容が常に一致するように努めていく。

史上最大級のシステム統合に挑む

 2013年7月のBK・CB合併に先駆け、みずほは2012年4月にFGとBK、CBの組織を統合し、新生みずほとしてスタートを切っている。そのみずほは2016年3月末をメドに、BKとCB、TBの勘定系システムを統合する。

 「システム統合は新生みずほを象徴するプロジェクトだ」。FGの高取次長は力を込める。本誌の取材で、システム統合の概要が明らかになった。

 システム統合における最大のポイントは、勘定系システムを全面刷新することだ。既存の業務にとらわれず、銀行業務のあるべき姿を描き、それを実現するシステムを構築する。

機能単位でコンポーネント化

 BK、CB、TBのいずれかのシステムに片寄せはしない。「不動産信託」など独自商品を持つTBのシステムは一部残す可能性があるものの、BKやCBのシステムは廃棄する。1988年から24年間にわたって使い続けているBKの勘定系システム「STEPS」を、ついに刷新するわけだ。

 新システムはどう作るのか。みずほは勘定系システムのハードウエアだけでなく、アーキテクチャーそのものを全体最適の観点で刷新する考えだ。注目は業務アプリケーションの「コンポーネント化」である。預金、融資、為替といった機能ごとにアプリケーションを切り分け、業務コンポーネントとしてまとめる(図4)。

図4●みずほにおける銀行勘定系システムの統合方式
新システムを構築し現在のシステムは廃棄する。新システムは共通機能をまとめた「共通基盤」と機能別の「業務コンポーネント」からなる
[画像のクリックで拡大表示]

 各コンポーネントは「共通基盤」と呼ぶプラットフォームを通じて連携する。共通基盤にはCIF(カスタマー・インフォメーション・ファイル)や処理フローの制御など、各コンポーネントが共通して必要とする機能を実装する。

 みずほは日本IBM製メインフレームをベースに、共通基盤を先行して構築し始めた。2013年3月までに、完成した部分から稼働させる予定だ。

スピード速め、リスク減らす

 コンポーネント化の利点は、アプリケーションの肥大化に歯止めをかけられることだ。

 長年にわたり機能追加を続けてきた勘定系システムは、アプリケーション同士が密接に結合していて、明確に分離することができない。商品を追加・変更する場合、影響範囲は多岐にわたり、時間がかかる。みずほに限らず、大規模システムを抱える多くの企業にとって、ここが泣き所だった。

 銀行の勘定系システムの規模は、大手銀のものであれば5000万ステップを超える。周辺システムも含めると3億~4億ステップにまで達し、その規模は膨らむ一方だ。コンポーネント化によって、そうした肥大化に歯止めをかけるのが、みずほの狙いだ。

 コンポーネント化はビジネスの「攻守」両面において効果を発揮する。「攻め」に関しては、新商品を素早く投入できるようになる。アプリケーションの追加・変更にかかる期間を短縮できるからだ。既存の商品を改定する際にも、システム対応を速められる。

 「守り」については、システム障害リスクの軽減につながる。アプリケーションの肥大化を防ぐことで、バグを減らせるからだ。

 たとえシステム障害が発生したとしても、システム全体に波及しにくく、影響範囲の極小化や早期復旧につながる。過去に引き起こしたような大規模トラブルを防ぐ効果が期待できる。

 開発・保守コストの削減にも寄与する。アプリケーションに手を加える場合、影響調査や修正箇所の範囲を狭くできるからだ。

開発要員はピーク時8000人

 みずほが2012年3月にまとめた基本計画によると、2012年4月から2013年3月までを要件定義に充て、2013年4月から設計・コーディングに順次取り掛かる。

 先に述べたように、大手銀の勘定系システムは5000万ステップを超える規模だ。みずほの場合、CBやTBのシステムも合わせると、勘定系だけで1億ステップを超えるとみられる。

 これだけの規模の巨大システムを全面刷新するのは前例がない。銀行合併などで勘定系システムを統合する際は、1行のシステムに「片寄せ」することが多いからだ(表2)。

表2●大手銀行におけるシステム統合プロジェクトの比較
[画像のクリックで拡大表示]

 だが、みずほはあえて全面刷新に挑む。その理由について、FGの高取次長は「理想的なアーキテクチャーを実現する絶好の機会だからだ」と強調する。一方で、工数削減とリスク低減のため、「プログラムの書き換えが不要な部分については、現行のプログラムを流用する」(FGの高橋副部長)。

 とはいえ、片寄せ方式と比較すると開発量は増す。みずほは現在、新システムの要件定義を進めている。FGの「次期システム推進室」を中心に、各行のシステム部門やみずほ情報総研のメンバーを含め、総勢150~200人で取り組む。

 要件定義こそ、この規模で収まっているが、実装フェーズでは最大8000人の開発要員が必要になる見込みだ。これはピーク時に6000人を投じた三菱東京UFJ銀行のシステム統合プロジェクト「Day2」を上回る。

 開発期間についても、設計から稼働まで2年間を費やした三菱東京UFJ銀行のDay2を超える見込みだ。机上の計算ではあるが、体制がDay2の1.3倍、期間もDay2より長くなることを考えると、Day2が2500億円かかったのに対し、みずほの投資額は4000億円を超える可能性がある。間違いなく、世界最大のプロジェクトだ。

直面する三つの課題

 みずほが新システムを構築する覚悟を決めたことは、大規模刷新に踏み切れなかった過去に比べると大きな進歩だ。だが果たして挑戦はうまくいくのか。課題は三つある(図5)。

図5●みずほの勘定系システム統合における三つの課題
[画像のクリックで拡大表示]

 一つめはコンポーネント設計だ。機能/商品単位でコンポーネント化していくという大方針は決まっているものの、中身の議論はこれから。アプリケーションをうまく切り分けないと、コンポーネントの独立性を確保できない。預金と融資という二つの機能を例に取っても、「完全に分離させるのは難しい」(高橋副部長)。

 コンポーネント化の前提として、BKとCB、TBで重複する機能の統一も必要だ。FGの加藤朝史システム推進部次期システム推進室室長は、「要件定義の中で最適解を見つけていく」と述べる。ただ、機能を統一する過程で利用部門から不満が出る可能性は十分にある。

経営陣は腕の見せ所

 体制作りが二つめの課題だ。ピーク時8000人という体制になると、情報共有や意思疎通には大変な困難が伴う。プロジェクト全体を統括するPMO(プロジェクト・マネジメント・オフィス)を設置するなど、みずほ情報総研やITベンダーも含めた厳格な管理が必要になってくる。開発作業は複数のチームに分けて並行することになるだけに、各チームの進捗やリスクの状況をプロジェクト全体で共有できる仕組みづくりが欠かせない。

 体制面では利用部門の協力を得ることも重要だ。利用部門が機能やオペレーションの変更に抵抗するようなことになれば、プロジェクトは進まない。

 ここはFGの安部CIOをはじめとする経営陣の出番だ。経営陣はシステム統合に向けて各部門を一致団結させる努力が欠かせない。みずほのシステム担当者によれば、昨年春の大規模障害以後、みずほ経営陣のITに対する理解は深まり、意識も高まったという。

 だとすれば、ITに強くなった経営陣にとって、腕の見せ所だ。必要な予算を確保する、利用部門にガバナンスを効かせる、全行一丸となる体制を構築する、といったリーダーシップを期待したい。

 部門間だけでなく、BK、CB、TBの垣根も取り払い、3行の関係者が文字通り一体となれるか。ここも成否を左右する。

 3行それぞれの思惑が対立するようでは成功は望めない。10年前のみずほ発足時、旧行間の主導権争いがプロジェクトの遅れを招いた。その教訓を生かせるかが鍵になる。

システム移行が重荷に

 三つめの課題はシステム移行だ。みずほの場合、3行のシステムからそれぞれ、口座データを新システムに移行する必要がある。店舗システムを新システムにつなぎ替える作業も、3行の全店で発生する。

 片寄せ方式の場合、廃棄する勘定系システムの口座データを移行するだけで済む。店舗システムの移行も、廃棄する勘定系につながった店舗だけが対象だ。2行による片寄せの場合、口座データの移行プログラムは廃棄元から移行先への1種類を作成すればよい。

 みずほの場合、BKから新システムへ、CBから新システムへ、TBから新システムへといった具合に、移行プログラムを3種類そろえなければならない。店舗システムの移行手順も3種類必要だ。リハーサルやテストを含め、移行にかかわる多くの作業について、2行による片寄せの3倍になる。世界最大規模のアプリケーション開発に追われる開発現場に、システム移行関連の作業負荷が重くのしかかる。

     ◇         ◇         ◇     

 「信頼を取り戻すため、グループ一丸となって努力を継続していきたい」。FGの佐藤康博社長は2012年6月26日の株主総会で、こう強調した。3度目の大規模障害を起こすわけにはいかないことを承知の上で、みずほはシステム全面刷新の覚悟を決めた。信頼回復には抜本的な改革が不可欠という経営判断だ。

 世界でも類を見ない大規模プロジェクトを完遂し、新生みずほをアピールできるか。復活に向けた再挑戦は始まったばかりだ。

2011年3月のシステム障害を振り返る

 みずほ銀行(BK)で2011年3月に発生した大規模システム障害は、東日本大震災の義援金の振り込みがきっかけだった。テレビ局が設けていた義援金の振り込み口座に対して、システム上の設定を上回る1日当たり6万件の振り込みが集中した結果、預金元帳に対する夜間バッチのセンター集中記帳処理が異常終了した。処理件数がリミット値を超えた際のエラー処理に問題があり、バッチ処理全体を終了できなくなったのだ。その結果、振り込みだけでなく為替の送信などもできなくなり、大規模なシステム障害へとつながった。

 集中記帳処理の問題点は、大きく分けて二つあった。一つはシステム上のリミット値の問題であり、もう一つはリミット値を上回る異常が発生した際の、エラー処理の問題である。

 BKはインターネットバンキングなど新サービスを追加する際にもリミット値を見直さなかった。さらに異常が発生した際の対策を十分に用意していなかった。

 「2002年4月の3行統合時におけるシステム障害では、新しく作ったシステムに障害の原因があった。それ以来、新規開発における品質管理に力を入れ、開発管理やリリース前の確認を厳格化してきた。しかし、勘定系のような長期にわたって安定稼働していたシステムに関しては注意が足りなかった」。みずほフィナンシャルグループの高橋達浩IT・システム企画部副部長はこう振り返る。

みずほの障害受け、金融庁が検査マニュアルを改正

 みずほ銀行(BK)のシステム障害が、他の金融機関に影響を与えている。金融庁がBKでの教訓を基に、全金融機関に対して従来よりも厳格なシステムリスク対策を求め始めたからだ。

 金融庁は2012年6月末に、金融機関に対する監督指針や金融検査マニュアルを改正した。新しい指針では、システムリスクに対する認識や障害発生時の対応などを従来よりも厳しく指摘している。

 例えば「主要行等向けの総合的な監督指針」には、「システムリスク管理部門は、例えば1口座当たりの未記帳取引明細の保有可能件数などのシステムの制限値を把握・管理し、制限値を超えた場合のシステム面・事務面の対応策を検討しているか」という文言が加わった。BKのシステム障害が、システム上のリミット値を超えたのをきっかけに発生したことを受けてのものだ。

 新しい監督指針では、情報システムに対するシステム監査人などによる外部監査も求めている。従来は「システム監査に精通した要員を確保しているか」とされていた項目が、「システム関係に精通した要員による内部監査や、システム監査人等による外部監査の活用を行っているか」と変わった。BKのシステム障害では、安定稼働してきた勘定系システムがダウンした。外部の力を借りて、より厳しい姿勢でシステムリスクを洗い出すことを金融庁は求めている。

 金融庁がBKのシステム障害に起因してシステム検査を厳格化するのは、2002年4月の障害に続いて、今回が2度目である。

最後の大型商談巡るベンダー争奪戦の行方

 かつての都市銀行13行は、合併などによって今や4グループに集約している(図A)。再編の都度、大手ITベンダーが勘定系システムの争奪戦を繰り広げてきた。みずほ銀行(BK)の新システムは、果たしてどこが受注するのか。

図A●大手銀行の勘定系システムの変遷(年月はシステム統合完了時期)
[画像のクリックで拡大表示]

 BKは「共通基盤」については日本IBM製メインフレームを利用する。ただしメインの「業務コンポーネント」についてはベンダー選定の最中だ。

 BKを長年担当してきた富士通と、みずほコーポレート銀行(CB)を手掛ける日立製作所は、この商談を逃すと大手銀の勘定系ビジネスを失う。両社とも、みずほが次期システム構想を描いた2004年頃から8年近くにわたり「何度も提案書を出してきた」(幹部)だけに必死だ。共通基盤を受注した日本IBMは、その勢いでコンポーネントの受注も目論む。

 ダークホースはNTTデータだ。BKの周辺システムを手掛けた経験があり、りそな銀行の勘定系システムを一括受託する実績も備える。ITベンダーによる過度な争奪戦がシステム統合の混乱につながった過去の経緯を踏まえ、NTTデータが「富士通や日立、日本IBMの上に立ちコントロールします」と提案すれば、争奪戦はさらに激化する。

証券・カードのシステム統合も正念場

 みずほフィナンシャルグループ(FG)では銀行のシステム統合と並行して、二つの大規模システム統合が進む。証券子会社の合併に伴う統合と、クレジットカード会社のシステム統合だ。

 FG傘下のみずほ証券とみずほインベスターズ証券は2013年1月の合併に伴い、基幹系システムを統合する。みずほ証券側に片寄せする方針に基づき開発やテストなどを進めている。CRM(顧客関係管理)など一部システムについては当面並存させるが、それでも100億円を超える案件だ。

 カード会社については、ユーシーカード、オリエントコーポレーション、クレディセゾンによるシステム統合が難航している。2011年からの段階稼働を目指し3年以上前から進めてきたが、現時点では稼働に至っていない。「貸金業法や割賦販売法の改正に伴い、業務プロセスや要件の見直しが発生した」(セゾン広報)ことが原因というが、「各社の要件調整に手こずっている」(関係者)との声もある。総投資額は当初500億円規模とみられていたが、大幅に増加するとの見方がある。システム開発は日本IBMが担っている。

 いずれも証券会社やカード会社が主体的に進めており、FGは第三者の立場で監査・チェックしている。ただし問題が起きれば何らかの責任を問われる可能性がある。銀行のシステム統合を含め、FGは実質的に三つの大規模統合プロジェクトを抱える状況にあり、正念場が続く。

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

  • 【グルメサイトRettyのAI舞台裏】

    Rettyが50万円で作った儲かるAI

     AI(人工知能)が人から仕事を奪う。これは遠い未来のことではありません。私がCTO(最高技術責任者)を務めるグルメ情報サービスRettyでは、深層学習などの技術を使って、従来は人がしていた仕事を自動化するAIを開発し、運用しています。

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

クラウド

設計/開発

サーバー/ストレージ

クライアント/OA機器

ネットワーク/通信サービス

セキュリティ

もっと見る