勘定系システム開発のフルスクラッチ・オーダーメイド開発について

勘定系システムとは、銀行・信用金庫・証券会社などの金融機関において、預金・為替・融資といった中核業務を処理する基幹システムです。かつての金融機関では、自前のシステム部門とベンダーが協力し、自行の業務に合わせてゼロからシステムを構築する「フルスクラッチ開発（オーダーメイド開発）」が主流でした。しかし現在、特に地方銀行においては、その約8割が勘定系を「共同化」、すなわち他行と共通の基盤を使う共同利用型パッケージへと移行しています。「なぜ勘定系はフルスクラッチから共同化・パッケージへと大きく舵を切ったのか」「フルスクラッチとパッケージ導入では、コストやリスクがどう違うのか」「今もフルスクラッチが選ばれるのはどんなケースなのか」といった問いは、勘定系の刷新方針を検討する金融機関にとって、避けて通れない論点になっています。

本記事では、勘定系システムのフルスクラッチ・オーダーメイド開発について、フルスクラッチからパッケージ・共同化へ移行した背景、両者のコスト・リスク比較、主要な勘定系パッケージと共同化システムの全体像、クラウドネイティブな次世代勘定系の登場、そして今なおフルスクラッチが選ばれる稀なケースまで、具体的な製品名や金融機関の事例を交えて体系的に解説します。勘定系の刷新方針を検討している金融機関の経営層・システム部門の方が、自行にとって最適な開発方式を見極めるための判断軸として活用できる内容です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・勘定系システム開発の完全ガイド

なぜ勘定系はフルスクラッチからパッケージ・共同化へ移行したのか

かつては各行がオーダーメイドで作り上げていた勘定系が、なぜ共通の基盤を共同利用する方向へと大きく変わったのか。その背景には、金融機関を取り巻く技術・コスト・規制の三つの環境変化があります。地方銀行の約8割が共同化を選んでいるという事実は、この変化の大きさを象徴しています。

フルスクラッチから共同化へ移行した最大の要因が、技術者の枯渇です。勘定系システムの多くはCOBOLやPL/Iといった古い言語で構築されていますが、これらの言語を扱える技術者は「2007年問題」に象徴されるように高齢化・減少が進んでいます。フルスクラッチでシステムをゼロから構築し、その後も長期にわたって自前で維持し続けるには、これらの言語と自行独自の複雑な業務ロジックの両方を理解した技術者を常に確保しなければなりません。しかし、その人材の確保が年々困難になっているのが実情です。自行だけで勘定系を作り、支え続けることのリスクとコストが高まるなかで、専門ベンダーが提供するパッケージや、複数行で技術者を共有できる共同化へと軸足を移すことは、人材面から見て合理的な選択となりました。技術を支える人がいなくなれば、どれほど自行に最適化されたシステムであっても維持できなくなる、という現実が、フルスクラッチ離れを後押ししています。

コストと規制対応の負荷も、共同化への流れを決定づけました。複雑な金融ロジックを各行が単独でゼロから開発し、維持し続けるには、膨大な固定費がかかります。これに対して、複数行でシステムを共同利用し、ベンダーに使用料を支払う形にすれば、開発・保守コストを分かち合うことで、各行の負担を大幅に削減できます。さらに、外部環境の変化への対応負荷も無視できません。個人情報保護法や日本版SOX法といったコンプライアンス対応、新しい決済制度への接続など、勘定系に求められるシステム改修は年々増加しています。これらの改修を各行が自前で対応し続けるのは大きな負担ですが、共同化センターやパッケージベンダーに任せれば、業界共通の対応をまとめて行ってもらえるため、対応スピードを上げつつコストも抑えられます。技術者の枯渇、開発・保守コストの重さ、そして法規制対応の負荷という三つの圧力が重なった結果、勘定系はフルスクラッチという「各行が自前で作る時代」から、パッケージ・共同化という「共通基盤を分かち合う時代」へと移行したのです。

フルスクラッチとパッケージ・共同化のコスト・リスク比較

フルスクラッチとパッケージ・共同化は、単に費用の多寡だけでなく、リスクの性質や自行の裁量の大きさという点で大きく異なります。それぞれの特徴を正しく理解することが、自行に合った方式を選ぶ前提となります。

勘定系のフルスクラッチ開発は、一般的な大規模業務システムとは費用の次元が異なります。一般的な大規模業務システムの開発費用が「数千万円から1億円以上」とされるのに対し、ミッションクリティカルな勘定系のフルスクラッチ開発では、みずほ銀行の「MINORI」のようにメガバンクが全面刷新を行った事例では、4,000億円を超える巨額の費用が投じられました。金額の大きさもさることながら、リスクの性質も特殊です。開発期間が数年から10年単位に及ぶため、その途中で法制度や経営環境が変化し、仕様変更が発生すると、それが致命的な遅延を招くリスクがあります。また、金融特有の複雑な処理をすべて自前で作り込むため、テストや外部システムとの接続検証に莫大な工数がかかります。フルスクラッチは、自行の業務に完全に適合したシステムを手に入れられる反面、その代償として巨額の費用と長期の開発リスクを引き受けることになるという点を、まず押さえておく必要があります。

一方、パッケージや共同化システムの導入は、自行の業務をパッケージの標準機能に合わせる「Fit to Standard」のアプローチを基本とします。標準機能に業務を寄せることで、独自の作り込み（カスタマイズ）を減らし、開発期間とコストを大幅に抑えられるのが最大のメリットです。ただし、良いことばかりではありません。パッケージ化やアウトソーシングを進めると、自行の都合に合わせた「仕様変更の柔軟性が低下する」というデメリットが生じます。標準機能から外れた独自の要件を実現しにくくなるため、業務のやり方をシステムに合わせて変える覚悟が必要になります。さらに、システムの企画・開発をベンダーや共同化センターに委ねることで、金融機関自身のシステム企画・開発力が徐々に低下し、ベンダーに依存してしまう「ベンダーロックイン」のリスクも指摘されています。コスト削減と引き換えに、自行の裁量と技術力が失われていく可能性がある点は、パッケージ・共同化を選ぶ際に十分に認識しておくべき論点です。

主要な勘定系パッケージと共同化システムの全体像

勘定系のパッケージ・共同化を検討するうえで、現在どのような製品や共同化システムが稼働しているのかを把握しておくことは重要です。主要ベンダーがそれぞれ特色あるパッケージを展開しており、多くの金融機関がこれらを共同利用する形で採用しています。

現在、日本の金融機関で稼働している主要な勘定系パッケージやフレームワークは多岐にわたります。NTTデータは、マルチプラットフォーム対応の勘定系アプリケーション「BeSTA」と、オープン基盤（Linux等）への移行を支援するミドルウェア「PITON」を展開し、横浜銀行など5行が参加する「MEJAR」や「地銀共同センター」「STELLA CUBE」といった共同化システムで広く採用されています。BIPROGY（旧日本ユニシス）の「BankVision」は、百五銀行などで採用された世界初のWindowsベースのフルバンキングシステムであり、無店舗型のネット銀行向けには「BANKSTAR」がセブン銀行やauじぶん銀行などに提供されています。日本IBMは、三菱UFJ銀行主導の地銀共同化システム「Chance」や、Javaベースの「NEFSS」（住信SBIネット銀行などで稼働）を展開しています。日立製作所はパッケージ「NEXTBASE」に加え、静岡銀行のシステムをベースにしたLinux稼働の次世代勘定系「OpenStage」を、富士通は「PROBANK」を、NECは「BankingWeb21」をそれぞれ展開しており、金融機関は自行の規模や方針に応じてこれらから選択します。

これらのパッケージの多くは、単に一行に導入されるのではなく、複数の金融機関が同じ基盤を共同利用する「共同化システム」として展開されている点が、勘定系ならではの特徴です。前述のMEJARや地銀共同センター、Chanceなどは、いずれも複数の地方銀行が参加し、共通のパッケージを土台に運用コストと改修負荷を分かち合う仕組みになっています。これは、パッケージ導入と共同化という二つの流れが融合した「共同利用型パッケージ」ともいえる形態であり、フルスクラッチが減った勘定系開発の受け皿として定着しています。参加行は、単独では負担しきれない高度なシステムを、他行と費用を持ち寄ることで利用でき、法改正対応なども共同で進められます。一方で、共同利用である以上、参加行間で標準的な業務プロセスに揃える調整が必要になり、自行独自の要件を反映しにくくなる面もあります。どの共同化システムに参加するかは、単なるシステム選定にとどまらず、業務のやり方や他行との協調のあり方まで含めた、経営レベルの意思決定となります。

クラウドネイティブな次世代勘定系の登場

近年、フルスクラッチとパッケージという従来の二分法に、新たな選択肢が加わりつつあります。それが、最初からパブリッククラウド上で稼働することを前提に設計された「次世代勘定系」です。クラウドの柔軟性とスケーラビリティを活かしたこれらのシステムは、勘定系開発の新しい潮流を形づくっています。

パブリッククラウド上で稼働する次世代勘定系は、大手クラウド3社それぞれで実際に稼働事例が生まれています。AWS上では、SBI地方創生バンキングシステムとフューチャーアーキテクトがゼロベースで共同開発した「次世代バンキングシステム」があり、AWSを全面採用し、フルオープンAPIとマイクロサービスアーキテクチャを特徴としています。福島銀行や島根銀行で稼働しており、SBI新生銀行もこれを用いてシステムを刷新する予定です。Google Cloud（GCP）上では、アクセンチュアが開発し、みんなの銀行が採用した「MAINRI」や、UI銀行が採用した「AiTHER」などが稼働しています。Microsoft Azure上では、北國銀行が国内初のフルクラウド勘定系として「BankVision on Azure」を本番稼働させています。これらは、従来のメインフレームやオンプレミスのオープン基盤とは一線を画す、クラウドを前提とした新しい勘定系の形であり、特に新規参入のデジタルバンクや、思い切った刷新を志向する銀行が採用を進めています。

次世代勘定系が従来のフルスクラッチと決定的に異なるのは、その設計思想です。従来のメインフレーム勘定系が、巨大な一枚岩（モノリシック）の構造で、内部を一体的に作り込んでいたのに対し、次世代勘定系はマイクロサービスアーキテクチャを採用し、機能を小さな独立したサービスの集合体として構成します。これにより、一部の機能だけを個別に改修・拡張しやすくなり、変化への対応スピードが向上します。また、フルオープンAPIを前提とすることで、外部のフィンテックサービスや非金融事業者との連携が容易になり、組込型金融のような新しいビジネスモデルにも展開しやすくなります。興味深いのは、こうした次世代勘定系が「ゼロから作る」という点ではフルスクラッチ的でありながら、実際にはクラウド基盤やパッケージ的な共通部品を活用して構築されている点です。つまり、完全な自前開発でも既製品の導入でもない、その中間に位置する新しい開発スタイルが生まれつつあります。近年は、新設のデジタルバンクであっても、API連携を前提としたクラウドパッケージを採用する流れが強まっており、勘定系開発の選択肢は着実に多様化しています。

フルスクラッチ・オーダーメイドが選ばれる稀なケース

大半の中小金融機関やネット銀行がパッケージやクラウド基盤の共同利用を選ぶなか、それでも自社主導のフルスクラッチ開発（またはそれに近い大規模な自社専用開発）が選ばれるケースが存在します。どのような場合にフルスクラッチが合理的な選択となるのかを理解しておくことは、自行の方針を考えるうえで役立ちます。

フルスクラッチが選ばれる代表的なケースが、メガバンク（都市銀行）です。三菱UFJ、三井住友、みずほといったメガバンクは、その事業規模が巨大すぎるため、地方銀行向けに設計された既存のパッケージには収まりきりません。膨大な取引量や口座数、複雑な業務体系に対応するには、地銀向けパッケージでは能力が足りないのです。そのため、メガバンクは1980年代から続く第三次オンラインシステムをベースに独自の拡張を続けたり、合併時には一方の行のシステムに寄せる「片寄せ統合」を行ったり、あるいはみずほ銀行の「MINORI」のように数千億円をかけて実質的なフルスクラッチで新規開発を行ったりするケースがほとんどです。規模の経済が働くパッケージ・共同化のメリットは、そもそも規模が大きすぎる金融機関には当てはまりにくく、自前で作り込むしかないという事情が、メガバンクのフルスクラッチを支えています。裏を返せば、それだけの費用とリスクを引き受けられる体力があるからこそ、フルスクラッチという選択が可能になるともいえます。

もう一つのケースが、自社の業務ロジックそのものに、他行にはない「競争優位性」を持たせたい場合です。既存の金融機関とは全く異なる金融ビジネスモデルを描き、特殊なデジタルバンクを一から設計しようとする場合には、標準的なパッケージでは実現できない独自の仕組みが必要になり、自社主導での開発が選択肢に上がります。システムのあり方そのものが競争力の源泉になるようなビジネスでは、他行と共通のパッケージを使っていては差別化ができないためです。ただし、この領域でも近年は状況が変わりつつあります。前章で見たように、新設のデジタルバンクであっても、API連携を前提としたクラウドパッケージや次世代勘定系基盤を採用する流れが強まっているのです。ゼロから完全に作り込むのではなく、クラウド基盤の上に自社の独自性を乗せるという、フルスクラッチとパッケージの中間的なアプローチが現実的な選択肢として広がっています。純粋なフルスクラッチが選ばれる場面は着実に狭まっており、「どこまでを自前で作り、どこから共通基盤に乗せるか」という配分の設計こそが、これからの勘定系開発の中心的な論点になっていくといえます。

まとめ

勘定系システムの開発は、かつてのフルスクラッチ・オーダーメイド中心から、パッケージ・共同化中心へと大きく変化しました。地方銀行の約8割が共同化を選んでいる背景には、COBOL技術者の枯渇（2007年問題）、複雑な金融ロジックを自前で開発・維持する固定費の重さ、そして法規制対応の負荷増大という三つの圧力があります。フルスクラッチはみずほMINORIの4,000億円超に象徴されるように巨額の費用と長期の開発リスクを伴う一方、パッケージ・共同化はFit to Standardでコストを抑えられる反面、柔軟性の低下やベンダーロックインのリスクを抱えます。BeSTA/PITON、BankVision、Chance、OpenStageといった主要パッケージが共同利用型として広く使われるなか、AWS・GCP・Azure上のクラウドネイティブな次世代勘定系が新たな潮流となり、マイクロサービスやフルオープンAPIといった新しい設計思想を持ち込んでいます。純粋なフルスクラッチが選ばれるのはメガバンクや独自ビジネスモデルを描く場合など限られたケースとなり、「どこまで自前で作り、どこから共通基盤に乗せるか」の配分設計が、これからの勘定系開発の鍵となります。本記事が、勘定系システムの開発方式を見極める一助となれば幸いです。

▼全体ガイドの記事
・勘定系システム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。