トップQs
タイムライン
チャット
視点

勘定系システム

ウィキペディアから

Remove ads

勘定系システム（かんじょうけいシステム、英語: core banking、コア・バンキング）とは、主に企業や行政機関において会計勘定処理を行うシステムのこと、特に銀行における基幹システムのこと。1960年代以降はコンピュータシステムが普及した。

銀行における定義

銀行における勘定系システムとは、狭義には預金勘定元帳を処理し、為替、ATM（Automated Teller's Machineの略称）ネットワーク、対外システムとの接続を制御するシステムであり、銀行における基幹系システムの中核である。しかし、しばしば勘定系以外の情報系・国際系や対外系、インターネットバンキングや営業店端末などチャネル系システムを含んだ、銀行におけるオンラインシステム全般（あるいは、単に基幹系システムと称されることもある）を指す言葉としても用いられ、しばしば混同して用いられることが多い。

勘定系システムは、その歴史的経緯と業務の重要性、規模の巨大さから、ほとんどの場合でメインフレームシステムによって構成される。近年では、UNIX系システムやPCサーバの劇的な信頼性向上と、性能の上昇、価格の低下によって、メインフレーム以外で構成される勘定系システムも登場しつつある（オープン勘定系）。しかし、メインフレーム自体の性能の向上や、オープン系システムでは太刀打ちできない高い信頼性のため、多くの金融機関は勘定系システムにメインフレームを採用している。

勘定系システムのような、巨大な処理能力と高い信頼性が要求される分野では、金融機関によるシステム投資額は巨額であり、システムベンダーにとって自社が製造するコンピュータやソフトウェアが勘定系システムに採用されることは、ベンダーの経営を左右するだけでなく、製品ラインの存亡を左右する大型案件となる。また、システムベンダーにとっては、主要な金融機関で自社のシステムが採用されている事実を、導入事例として積極的に一般企業に対して宣伝することが多い。また勘定系システムでは、コンピューターに対して高信頼性が求められるため、そこで培われた基盤技術やソフトウェアが、一般向けシステム用に販売されることも多く、ベンダーの技術開発や、技術レベルの維持に重要な役割を果たしている。

勘定系システム開発においては、現実にはシステムベンダーがコンピューター基盤を開発・提供し、アプリケーションは銀行のシステム子会社が主体となって開発を進める事例が多いにもかかわらず、しばしばシステムベンダーにより「社運をかけたプロジェクト」と宣伝され、一般にはシステムベンダーが主体となって銀行システム全体を開発しているかのような印象を与えることが多い。近年では、共同化システムを含め、ベンダーが開発したパッケージをそのままアプリケーションとして採用する事例もあるため、必ずしも間違いとは言えない。

Remove ads

歴史

要約
視点

銀行におけるコンピュータの利用は極めて早く、日本では1958年に三和銀行（現：三菱UFJ銀行）が導入したものが最初とされる。当初の利用目的は、手形小切手の自動処理や、会計などの分野でバッチ処理を主体としたもので、オンライン処理は想定されていなかった。その後、銀行におけるコンピュータの導入は急速に進み、銀行はコンピュータによって実現する目標を定め、段階的に現在のシステムへと発展していった。

勘定系システム開発史では、しばしば実現した機能や、構築時期によって「第x次オンラインシステム」と呼ぶことが多い。ただし、銀行によって実装された機能や、構築時期にはばらつきがあるため、同じ時期のシステムでも機能面では、業態や銀行間によって大きく異なることが多い。

また、銀行以外の証券会社や、手形交換所、全銀システム、日銀ネット、郵便貯金システムなどでも「第x次オンラインシステム」と呼称することがあるが、原則的には銀行におけるものとは、内容も構築時期も別である点に注意が必要である。

第一次オンラインシステム（ - 1960年代）

黎明期におけるシステム開発で、主に銀行本店における勘定処理の合理化のために導入された。採用されたコンピュータは、端末も含め輸入に頼っており、利用実態も開発も手探りの状態が続いた。また、運用に際しても銀行の本店にコンピュータが設置される場合も多く、システム部門も厳密には銀行本体から分離されていなかった。

第二次オンラインシステム （ - 1970年代）

本店から支店に対してオンラインが展開される時期で、勘定処理の本格的なオンライン化が進行した。1965年5月には、三井銀行（現：三井住友銀行）で日本初（世界初）のオンライン・バンキング・システムが稼働した（1964年の東京オリンピックのオンライン化技術が転用された) [1][2]。採用されるシステムも外国製から国産のものが採用され、国産コンピュータの開発に多大な寄与があった。しかしながら、ジョブ管理や、オンライン処理などソフトウェア面の未熟さが手伝って、実際の構築ではOS開発に銀行側が直接参加するなど苦労が多く、トランザクションモニターを中心とする独自のOS開発を行った銀行も多い。

全銀ネットなどの外部ネットワークとの接続の必要性や、勘定処理とは関係しない業務処理が多数発生したため、勘定系システムとは別に外部ネットワークとの接続制御を行う対外系システムや、情報系システムが勘定系とは別に構築された。また、業態別では都市銀行から地方銀行にオンラインシステムが展開され始めた時期にも当たる。

運用面では、手狭な本店に設置されていたコンピュータが、郊外のデータセンターでの運用に切り替わり、銀行本体からシステム部門が分離され、現在の運用開発体制の基礎となった。災害対策や故障対策を兼ねて、バックアップ系の整備が図られはじめたのもこの時代で、バックアップ機の有効活用を兼ねて、システム子会社が一般企業のデータ処理業務やシステム開発にも進出していった。

第三次オンラインシステム（ - 1980年代）

名寄せや、世帯把握のために、顧客情報ファイル (CIF : Customers' Information Files) をベースとした顧客属性管理などが強化され、オンラインシステムの展開が、単なる業務の合理化・省力化の方向から、営業支援システムとしての側面が強くなった。また、現金自動支払機 (CD) の普及が始まり、通帳の磁気テープ貼付、キャッシュカードの発行、店頭自動機の展開など、オンラインシステムが商品サービスの内容や展開に不可欠な存在になった。尚、名寄せに伴う“家族カード”の一部顧客層への普及ならびに、各種提携機関からのオフライン（磁気テープでの受け渡しが主流であった）データによる引き落とし、ATMによる他行からの振込処理の増大（ATM稼働時間の延長）、度重なる銀行合併に伴う勘定元帳の統合・移行の必要性、あるいは給与の口座振込化の増大（現金払いで支給する企業も当時は多かった）などの社会的な背景もあり、“元帳DBに対する排他制御の確実性ないしは例外的な排他運用（オフライン引落しをどのタイミングで与信し、元帳反映させるかなど）”がクローズアップされた。中には一部行にて、システムテスト項目の不足に起因すると思われるバグにより、口座残高に関わる運用不備が社会問題化した。

第三次オンラインシステムでは、それまでシステム化の進行が遅かった相互銀行（現在の第二地方銀行）や、信用金庫などの中小銀行にも波及した。都市銀行や地方銀行の多くは、独自にシステム開発を進めたが、中小銀行ではベンダーや他銀行との共同開発で展開したケースが多く、現在のアウトソーシング化への布石となった。

ポスト三オン時代（1990年代 - ）

10年ごとにシステムを全面的に刷新してきた銀行業界だが、第三次オンラインシステムの完成によって、オンラインシステムは一応の完成を見せ、バブル崩壊後の景気低迷もあって銀行業界は、大規模なシステム刷新に慎重となった。

第三次オンラインシステムの設計想定寿命が10年前後であったにもかかわらず、銀行は大規模投資を控え、既存システムの保守と改良を続けるのみだった。しかし、第三次オンラインシステム構築時においても、都銀の間でさえ実装された機能には差異があり、顧客サービスに差がつきはじめていた。1980年代のシステム構築で、プラットフォームの転換を行った住友銀行（現 : 三井住友銀行）や、合併対応のために1990年代からシステム刷新を行ったあさひ銀行（現 : りそな銀行・埼玉りそな銀行）などが代表的で、運用コストの削減を目的に北海道拓殖銀行（破綻）や大和銀行（現 : りそな銀行）なども積極的なシステム投資を行った。また、実質的に本店機能を大阪から東京に移転していた三和銀行（現：三菱UFJ銀行）は、首都圏での営業基盤強化のために、ATM稼働時間を延長させるために大規模なシステム投資を継続し、富士銀行（現 : みずほ銀行）や三菱銀行（現 : 三菱UFJ銀行）も、他銀行との競争上システム投資を強化していった。

一方で、合併対応のためにシステム更新が間に合わなかったさくら銀行（現 : 三井住友銀行）や、第一勧業銀行（現 : みずほ銀行）などの銀行では、ポスト三オン時代においてはシステムの改良が進まず、サービス面での競争力が低下していった。このように、ポスト三オン時代では、1980年代までほぼ横並びで構築されていたシステムが、銀行間において差が開く時代となり、システムの優劣が着実に銀行の経営に影響を与え始めていた。

金融再編時代（1990年代末 - ）

1996年の三菱銀行・東京銀行の合併（東京三菱銀行→現 : 三菱UFJ銀行）、1999年の第一勧銀・富士銀行・日本興業銀行の経営統合（みずほフィナンシャルグループ。現 : みずほ銀行）に続く金融界の大再編では、合併による量的規模拡大とともに、システムを統合・合理化することによるコスト削減と、投資効率の改善によるIT化の強化が、経営方針に謳われるなど、銀行界の再編はシステム部門の重要性を改めて認識させた。

合併期においては、優劣の開いたシステム間で統合が図られることとなったために、原則的に先進的なシステムか、規模の大きいシステムに片寄せされる片寄せ統合が多く行われた。旧三和銀行と旧東海銀行が合併したUFJ銀行（現 : 三菱UFJ銀行）のように、合併と同時にシステムが統合される場合もあったが、東京三菱銀行（現 : 三菱UFJ銀行）・（旧）三井住友銀行・（旧）みずほ銀行・（旧）三菱東京UFJ銀行（現 : 三菱UFJ銀行）のように合併が優先され、システム統合が間に合わない場合には、旧来のシステムを並行稼働させて、単一のシステムのように見せかける「リレー統合」がしばしば行われた（現・みずほ銀行や現・三井住友銀行は、この限りではない）。

しかし、どちらの手法を取ったとしても、今までに類をみない巨大で複雑なシステム統合であり、経済システムに銀行システムが与える重要性が高まった現代において、システム統合の過程によって発生したシステム障害が、銀行の経営に与える影響だけでなく、決済制度そのものの存続を危うくするシステミック・リスクに発展する危険性が増大した。それが現実化したのが、2002年1月のUFJ銀行、それに続く4月の（旧）みずほ銀行・みずほコーポレート銀行のシステム障害であり、システム開発・運用におけるリスク管理の重要性が再認識された事件であった。

また、合併対応後のシステム開発においては、もはや第三次オンラインシステム時代のような、アーキテクチャを含めシステムを全面的に刷新する動きは見られないものの、勘定系システムに依存したオンラインシステム全体を見直し、サービスごとにシステムを再構築したり、勘定系システムの実質的な解体に繋がるハブ・アンド・スポーク型アーキテクチャへの移行が進められている。

地方銀行とポスト三オン

地方銀行では都市銀行のように強力なシステム部門を持たないため、第三次オンラインシステムの運用コストの負担感、法令順守やウェブ対応を含む新規開発負担、更には国産ベンダーのメインフレームからの撤退基調などから、ベンダーや他銀行と提携し、共同センターなどで共同運用する、開発や運用をアウトソーシングする、共同開発したパッケージに移行する、クラウドコンピューティングを利用するなどの動きが強まっている。

これらの動きは、地方銀行が個別にシステム部門を抱えてエンジニアのレベルを維持するよりも、ベンダーの支援を受け、ベンダーに対しシステムの使用料金を支払う形にすることで固定費の実質的な削減と、外部の専門家集団による新技術導入や品質向上を目指したものである。しかしこれらのパッケージ化やアウトソーシング化は、地方銀行のシステム開発力や企画能力を減退させ経営の自由度を低下させる側面もあり、また提携銀行間の設計・運用の合意に失敗する、ベンダーのパッケージ開発の大幅な遅延や失敗により銀行が大きな損害を受けるケースも発生している。

Remove ads

主な銀行の勘定系システム

要約
視点

日本の主な銀行（ここでは都市銀行、地方銀行、信託銀行、ネット銀行を含む新たな形態の銀行など）の勘定系システムについて記述する。

メガバンク（都市銀行）は、1980年代に構築したメインフレームを使用した第三次オンラインシステムをベースに拡張や更改を続けており、合併時には通常「片寄せ統合」が行われているが、2013年に発足したみずほ銀行は新規開発したシステムに2019年迄に移行した。

都市銀行よりも規模の小さい地方銀行や店舗を持たないネット銀行などでは、「オープン系勘定系」を含めた各種パッケージやシステム共同化が進展し、またメガバンクも地銀や信託銀行を含めた共同化を進めている。

  • 注意点
    • プラットフォームは、あくまで勘定系の中核部分である。情報系、対外接続系、証券系、店舗システム、開発環境、あるいは勘定系の各種周辺サーバ群などは含めていない。
    • マスコミ同様に「片寄せ統合」「継続使用」などと便宜上表記するが、実際には各種の機能統合や基盤更改などを経て「統合システム」となっており、単純に片方がそのまま存続しているのではない。

系統図

都市銀行の勘定系システムの主要ベンダーは、1980年代の13行時代は4社だが、2000年代の4グループへの再編に伴い2社となった。

日本の都市銀行の勘定系システムの系統図（「行名（主なベンダー）」、「（行名）」は都銀以外、実線は存続システム）[3][4][5]
第一銀行(富士通)
 
第一勧業銀行(富士通)
 
(旧)みずほ銀行(富士通)
 
みずほ銀行(IBM/富士通[注釈 1])
 
 
 
 
 
 
日本勧業銀行(IBM)
 
 
 
 
 
 
 
富士銀行(IBM)
 
 
 
 
 
 
 
 
 
 
 
 
 
日本興業銀行(日立)
 
 
 
 
 
みずほコーポ銀行(日立)
 
 
 
 
 
 
 
 
(みずほ信託銀行(IBM))
 
 
 
三菱銀行(IBM)
 
東京三菱銀行(IBM)
 
三菱UFJ銀行(IBM)
 
 
 
 
東京銀行(富士通)
 
 
 
 
 
三和銀行(日立)
 
UFJ銀行(日立)
 
 
 
 
 
東海銀行(日立)
 
 
 
住友銀行(NEC)
 
 
 
 
 
三井住友銀行(NEC)
 
 
 
 
 
 
太陽神戸銀行(富士通)
 
さくら銀行(富士通)
 
 
 
 
 
三井銀行(IBM)
 
 
 
埼玉銀行(IBM)
 
あさひ銀行(IBM)
 
りそな銀行・埼玉りそな銀行(IBM)
 
 
 
 
協和銀行(IBM)
 
 
 
 
 
大和銀行(IBM)
 
 
 
 
 
 
 
 
 
 
 
北海道拓殖銀行(IBM)
 
(北洋銀行(IBM))
 
(北洋銀行(TSUBASAアライアンス/IBM))
 
 
 
(北洋銀行(日立))
 
 
 

一覧

日本の銀行の勘定系システムは下表の通り。

さらに見る 銀行コード, 名称 ...
Remove ads

パッケージ/共同化

要約
視点

都市銀行や大中規模の地方銀行などでは、システム子会社が独自に開発した勘定系システムを使用することが多い。これに対して、ポスト三オン時代以降では、システムベンダーが主体となって開発された勘定系パッケージソフトや、共同センターを利用する銀行が増えている。2008年10月時点で地方銀行では108行のうち約8割は勘定系を共同化したとされる[77]。

システムベンダが主体となって開発された勘定系パッケージには、富士通のPROBANKやFSPS、NECのBankingWeb21、NTTデータのNTTデータ地銀共同センター、日立製作所のNEXTSCOPEなどがあり、開発・運用などアウトソーシングを含めて提案されているものも多い。

これに対して日本IBMは、三菱UFJ銀行の地銀共同化システム（通称・Chanceプロジェクト）や、八十二銀行などのじゅうだん会のように、勘定系パッケージの開発主体は銀行であり、日本IBMは保守運用を担当する形態が多い。

また複数の銀行で、システム全体または部分の共同開発、センターや運用を含めた共同化などの動きも進んでいる（例えば、静岡銀行の次期システムのオープン系の勘定系部分に京葉銀行が相乗りする方針を明らかにするなど）。

このほか、自前で運用したシステムの保守管理を圧縮する目的で、システムベンダにアウトソースするケースも見られ、そのシステムの延命が難しくなった時点で、共同化されたシステムや都銀（あるいは、都銀が地銀向けにパッケージ提供するケースを含む）のシステムに加入するというケースもある。

加えて、ソフトウェアパッケージでの提供もあり、NTTデータのBeSTA（2016年時点では、NTTデータ地銀共同センターなどのハードウェア込みのパッケージによる提供のみだが、個別提供も将来的な検討を行っている）やBIPROGYのTRITON（ハードウェアを利用金融機関が別途用意する個別提供のケースやACROSS21・ACCECSS21のようなハードウェア込のパッケージによる提供とがある）などがある。

なお勘定系システムに限らないが、一般的にシステムを変更する場合は「更新」や「更改」、特に別システムへの変更を含む大幅な変更を「移行」（マイグレーション）や「置換」（リプレース）などとも呼ぶが、その用語の使い分けは明確ではない。

背景

勘定系パッケージやシステム共同化を、主に非基幹（中小）銀行等が受入れせざるを得ない理由は、正負ともにいくつか挙げられる。

  • 技術者の不足あるいは将来的な枯渇
    • いわゆる“2007年問題”とも呼ばれるが、こと勘定システムのコアとなるプログラム群は、COBOL、PL/I、機種依存アセンブラ言語また機種依存外字フォント（主に特殊な人名・地名用）などで構成されている場合が多い。
    • しかし現在のプログラミング環境での主流とは言い難く、スクラッチから構築する各種人材の確保が困難であり、共同化かつアウトソースする主な理由は、ここにある事が多い。
  • 全体スループットの向上
    • 現在の基幹勘定系の処理は、一般の想像を絶する複雑なロジック、ビジネス（会計科目仕訳、コンプライアンス処理）判断上の分岐点、データの保全・蓄積処理などを経て出力されている。
    • “基本的な会計処理”という観点では各行共通とも言えるが、“自行独自金融商品”という特異点を除外しても、本稼動当初の各行の担当設計者の“個性”が存在している（やや誤解を招く表現だが、例えば各行のATMに行って入出金や振込処理に要する時間を計測すると意外な“処理時間の差”がある。
    • 無論、曜日・時間帯・他行間取引など諸条件の違いを加味すると、イコール各行の“システム処理の性能”という短絡的な評価は出来ないが）。
    • これを、向上させる、若しくは平準化させる狙いがある。
  • 責任の所在の一元化による障害対処のスピードアップ
  • 運用・管理の一元化によるコストダウン
  • 上記による副次効果として、余剰リソースによる自行独自商品開発への集中
  • 銀行再編（合併、異業種を含む提携）、法令順守（日本版SOX法、個人情報保護法）などの進展による、開発・保守の範囲とスピードの向上（各金融機関で自前のシステムを構築し、何十年も保守を続ける事の負荷が向上）

一覧

銀行を中心とした金融機関の主な勘定系パッケージやシステム共同化には以下のものがある。（既に稼働を終了したものについては背景が灰色）

さらに見る 名称, 主要ベンダー（主要プラットフォーム） ...
Remove ads

脚注

関連項目

外部リンク

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads
Remove ads