決済システムの案件情報を見ると、可用性99.999%や24時間365日稼働といった言葉が並び、金融未経験のエンジニアほど身構えてしまいます。日本銀行の決済システムレポートを読むと、決済の仕組みは一様に堅く作られているわけではなく、金額や時間帯によって処理の経路が分かれていることが分かります。止められない部分と、あとから技術を入れ替えていく部分を切り分ける設計こそが、この分野の核心です。可用性設計やレガシー移行の経験を積んできたエンジニアにとって、その切り分け方はすでに馴染みのある考え方のはずです。

1. 決済は「一様に堅い」わけではない

決済システムと聞くと、24時間止まらない一枚岩の巨大なシステムを想像しがちです。ところが日本銀行の決済システムレポートを見ると、処理の経路は金額によって分かれる、思ったより繊細な作りになっています。全体を一律に「止めてはならない基盤」として捉えると、要件定義の段階で過剰な設計に寄ってしまいます。堅さの中身を分解して見ると、案件で問われる技術の焦点も見えてきます。

案件の説明を読むときも、「決済システム」という括りだけで身構える必要はありません。どこが秒単位で止められず、どこが1日単位でまとめて処理されているのかを見分けることが、要件を正しく読み解く最初の一歩になります。参画前の話し合いでも、担当する領域がどちらの経路に近いのかを確認できると、求められる可用性の水準や、障害対応の初動にかけられる時間について、具体的に質問しやすくなります。

1億円以上は即時グロス決済で処理される

1件1億円以上の大口取引では、金融機関から送られた個々の指図が日銀ネット当预系に連携され、即時グロス決済（RTGS）によって処理されます¹。1件ごとにその場で完結させる仕組みで、後からまとめて調整する余地を残しません。取り消しや組み戻しを前提にした後工程を挟まず、1件の指図がそのまま最終的な結果として扱われる設計です。

大量の取引を後でならすバッチ処理よりも、1件ごとに即時に決着させる設計の方が、大口の資金移動には向いています。可用性設計やゼロダウンタイムの経験がある技術者にとって、この即時性を支える基盤は馴染みのある景色に近いはずです。冗長構成の設計や、障害時の切り替えにかかる時間を詰めてきた経験は、そのまま評価の対象になります。

1億円未満は集計してから処理される

一方、1件1億円未満の小口取引については、全銀システムが個々の指図を集計して処理しています²。1件ずつ即時に処理するのではなく、いったんまとめてから流す設計です。件数が多い領域だからこそ、集計処理の効率と正確さを両立させる設計が課題になりやすい部分でもあります。

大口と小口で処理の粒度が違うと知っておくと、案件で求められる可用性の水準も一律ではないと見えてきます。同じ「決済」という言葉でも、求められる応答速度と許容される遅延の幅は対象によって大きく変わります。次の章で扱う「即時と1日1度が同居する」仕組みは、この粒度の違いがそのまま制度として残っている例です。

出典：日本銀行「決済システムレポート」（2024年9月）をもとに作成

2. 即時と1日1度が同居している

大口と小口で処理の粒度が違うことは、ここまでで分かりました。ここで注目したいのは、即時に完結する仕組みと、1日に1度まとめる仕組みが、別々の制度ではなく同じ決済の枠組みの中に共存している点です。片方だけを思い浮かべていると、案件の要件定義を読み違えてしまいます。

設計を担当する範囲がどちらの時間軸に属するかによって、テストの組み方も、障害時に許容される復旧時間の長さも変わります。要件を読み違えたまま見積もりを立てると、実装が進んでからの手戻りにつながりやすくなります。最初にどちらの時間軸を扱う案件なのかを確認しておくことが、無用な手戻りを防ぐ最初の一手です。障害訓練や切り替えテストの頻度も、即時性を優先する領域と、集計の正確さを優先する領域とでは、想定する条件が変わってきます。

小口取引は差額を計算してから1日1度で決済する

小口取引は、全銀ネットと各金融機関の受払差額を計算したうえで、1日に1度、時点ネット決済で処理されています³。1件ごとに個別で決済するのではなく、差し引きした金額をまとめて動かす設計です。1件単位の即時性より、締め時刻に向けた集計の正確さが優先される仕組みといえます。

この仕組みは、即時性より効率を優先した設計です。バッチ処理を前提にした基盤の経験があるエンジニアにとって、集計と清算のタイミング設計は決して縁遠い領域ではありません。締め時刻の管理や、集計後に差異が見つかった場合の再計算の手順を整えてきた経験も、そのまま生かせる部分です。

即時と1日1度、2つの時間軸を1つの制度が抱えている

大口取引の即時グロス決済¹と、小口取引の時点ネット決済³は、別々のシステムではなく、同じ決済制度の中で役割分担しています。求められる応答速度も、障害時に許容できる遅延の幅も、この2つでは大きく違います。1つの案件の中に、性質の異なる2つの時間軸が同居していることも珍しくありません。

案件の技術要件を読むときは、「決済システム」とひとくくりにせず、担当する対象がどちらの時間軸に属するのかを最初に確認したい部分です。次の章では、この時間軸そのものが後からどのように広がってきたのかを見ていきます。

区分	対象金額	処理タイミング	処理方式
大口取引	1件1億円以上	都度・即時	即時グロス決済（RTGS）1
小口取引	1件1億円未満	1日に1度	全銀システムが集計2のうえ時点ネット決済3

3. 止まらない範囲は後から広がった

即時と1日1度が同居する制度は、最初から24時間365日動いていたわけではありません。止まらない範囲は、時間をかけて段階的に広げられてきました。ここを知っておくと、案件で「なぜ今、可用性の要件がここまで重いのか」という背景が見えてきます。

「止められない」という言葉だけを見ると身構えてしまいますが、対象時間が広がってきた経緯を追うと、優先順位をつけて段階的に手を入れてきた設計だと分かります。一気にすべてを変えるのではなく、範囲を区切って少しずつ広げていく進め方です。案件の現場でも、いきなり全域を対象にした改修を任されるのではなく、区切られた範囲から着手する進め方が一般的です。

モアタイムシステムが夜間・休日の空白を埋めた

2018年10月にモアタイムシステムが稼働を開始したことで、休日を含めた24/7で、他行あて振込の即時着金が可能になっています⁴。夜間や休日という、それまで空白だった時間帯に、即時性を持ち込んだ変化です。

24時間365日を最初から目指したわけではなく、平日日中の仕組みに、夜間・休日という範囲を後から足していった経緯です。段階的に対象時間を広げていく設計は、レガシー移行の現場で可用性要件を少しずつ積み増していく進め方と重なります。

止まらない範囲が広がるほど、委託先の管理も重くなる

止まらない時間帯が広がるほど、システムを支える委託先の管理や、障害時の業務継続体制の重みも増します。2023年10月には全銀システムで大規模なシステム障害が発生し、1973年の稼働開始以来初の大規模な障害となりました。この障害を通じて、ベンダー管理や業務継続体制の課題等が洗い出されています⁹。

止まらない範囲を広げることと、それを支える体制を整えることは、常にセットです。単体テストの範囲よりも、委託先を含めた運用体制の設計の方が、この分野で問われる比重が大きいと感じられるはずです。障害発生時にどこまでを自分の担当範囲として引き受けるのかを、参画前に確認しておきたい点でもあります。

出典：日本銀行「決済システムレポート」（2024年9月）をもとに作成

4. 金額と件数で主役が逆になる

決済の設計を評価するときは、金額で見るか、件数で見るかで、見える景色がまったく変わります。この逆転を知らずに要件を読むと、性能要件をどちらの基準に合わせて考えればよいのか、判断を誤ってしまいます。

取扱金額では大口取引が全体の7割を占めていますが、取扱件数でみると小口取引が全体の99%超を占めています⁵。金額でみたときの主役と、件数でみたときの主役が入れ替わる構造です。

金額は大口が中心、件数は小口が中心

金額ベースで見れば、大口取引が全体の7割を占め、決済の中心はこちらに見えます⁵。しかし件数ベースで見れば、日々の生活や事業活動を支える小口取引が全体の99%超を占め、処理件数の中心はむしろこちらです⁵。どちらの軸で語られているかを意識しないと、案件の説明を読み違えてしまいます。案件情報を読むときも、「金額規模」と「処理件数」のどちらを基準にした説明なのかを読み分ける視点が役立ちます。

金額の大きさだけを性能要件の基準にすると、件数として大量に処理される小口の負荷を見落とします。逆に件数だけを見ると、1件あたりの重みが大きい大口の即時性を軽視しかねません。両方の軸を同時に扱う視点が、この分野の性能設計では欠かせません。

2つの前提を両立させる設計が求められる

金額の重さと件数の多さ、この2つの前提は同時に満たす必要があります。片方に寄せて設計を単純化できない点が、決済システムの案件で経験の厚みが問われる理由です。負荷試験の観点でも、金額の大きい取引の再現と、件数の多い取引の再現は、それぞれ別の想定で組み立てる必要があります。

大量かつ頻繁なトランザクションを扱ってきた経験と、1件ごとの重みが大きい処理を止めずに支えてきた経験、この両方が評価される場面です。どちらか一方の経験しかない場合でも、もう一方の視点をどう補うかを話し合えることが、参画時の評価につながります。次の章では、この2つの前提を踏まえたうえで、新しい技術をどこに入れるかという次世代の設計方針を見ていきます。

軸	数値	主役
取扱金額	大口取引が全体の7割5	大口取引
取扱件数	小口取引が全体の99％超5	小口取引

5. 新しい技術を入れる場所を決める

次世代の全銀システムでは、全体を一様に作り変えるのではなく、変えてよい場所と、変えずに守る場所を、あらかじめ切り分ける方針が示されています。この切り分け方こそ、案件で問われる設計の核といえる部分です。

開発ベンダーを選びやすくすることなどを狙った「システムのオープン化」が、第8次全銀システムの基本方針として挙げられています⁶。汎用的な基盤やOSを使う方向に進むことで、特定の作り方に縛られない設計を目指しています。

止められない業務を担うミッションクリティカルエリア

システムの構成は、内国為替や資金清算などの主要業務を担う「ミッションクリティカルエリア」と、付加的な機能・サービスを提供するための「アジャイルエリア」に大きく分けることが決定されています⁷。

止められない業務をミッションクリティカルエリアに閉じ込め、それ以外を切り離すことで、変化のスピードが必要な部分と、安定を最優先にする部分を、同じ基準で扱わずに済む設計です。守る対象を絞り込むほど、変える側の技術選定の自由度は広がります。

アジャイルエリアで新しい技術を検討する

アジャイルエリアについては、クラウドの利用なども念頭に、安全性に配慮しつつもコスト見合いでの優位性等を前提に、新しい技術の導入が検討されています⁸。新しさを試す場所を先に決めてから、技術選定を進める発想です。

全体を同じ速度で作り変えるよりも、守る部分と変える部分を先に線引きしてから技術を選ぶ方が、止められないシステムでは合理的です。クラウドや新しい基盤の経験は、アジャイルエリアという入り口を通じて生かせる場面が広がっていきます。線引きの発想そのものを理解しているかどうかも、参画後の話し合いで問われる観点です。

エリア	対象業務	技術の方針
ミッションクリティカルエリア	内国為替・資金清算などの主要業務7	安定を最優先。基盤のオープン化6で汎用的な作りに
アジャイルエリア	付加的な機能・サービス7	クラウド活用など新しい技術の導入を検討8

出典：日本銀行「決済システムレポート」（2024年9月）をもとに作成

6. まとめ

決済システムの案件は、金額によって処理経路が分かれ、即時性と1日1度の処理が同居し、止まらない範囲は段階的に広がってきました。取扱金額と取扱件数で主役が入れ替わる構造もあり、次世代のシステムは、変えない部分と変えていく部分をあらかじめ切り分ける方針を取っています⁷。

可用性設計、レガシー移行、委託先を含めた運用体制づくりの経験は、この切り分けの両側で生きる経験です。守る部分では安定性の設計が、広げる部分ではクラウドなどの新しい技術の見極めが、それぞれ評価される場面になります。金融ドメインの経験そのものより、止められない部分と変えていく部分を見分ける視点の方が、案件選びでは重視される要素です。

止められない部分と、変えていく部分。この2つを切り分けて考える視点さえ持っていれば、金融ドメインの経験の有無は、参画そのものを妨げる壁ではありません。むしろ、可用性設計や委託先を含めた運用体制づくりで積み上げてきた経験の方が、話し合いの場では厚みとして伝わりやすい部分です。

場所を選ばずに専門性を発揮したいという希望と、決済のような社会基盤を支える経験を積みたいという希望は、両立できます。Remoguは案件の90%以上がフルリモート可能なリモートワーク案件特化のエンジニアマッチングです¹⁰。まずは登録して、自分の経験がどの領域で生きるのか、条件と合わせて確認してみましょう。

7. よくある質問

決済システムの案件についてよく聞かれる点をまとめました。自分の経験がどこで生きるのかを確認する材料にしてください。ここまでの内容と重なる部分もありますが、参画を検討する際にまず気になる順に並べています。

図の作成：Remogu編集部。経験が生きやすい領域を整理したもので、統計データではありません

決済システムの案件は金融業界の実務を知らなくても参画できますか

求められるのは金融の専門知識そのものより、止められない部分と変えていく部分を切り分けて考える設計力です⁷。可用性設計やレガシー移行で培った視点は、金融ドメインが未経験でも生かせる場面があります。担当領域がどちらのエリアに近いかを確認することから始めると、必要な知識の範囲も見えてきます。

決済システムの案件で技術的に難しいのはどこですか

金額によって即時グロス決済¹と時点ネット決済³という異なる時間軸が同居し、さらに取扱金額と取扱件数で主役が入れ替わる点です⁵。1つの基準だけで性能要件を語れない設計になっており、複数の前提を同時に満たす設計力が問われます。

可用性設計やレガシー移行の経験はどう活きますか

止まらない範囲を段階的に広げてきた経緯⁴や、変えない部分と変えていく部分を切り分ける次世代の方針⁷は、可用性要件を積み増しながら基盤を作り替えてきた経験と重なります。守る部分の設計と、広げる部分の技術選定、両方の視点が生きる場面です。

委託先の管理経験も評価されますか

2023年10月の大規模なシステム障害を通じて、ベンダー管理や業務継続体制の課題等が洗い出されています⁹。委託先を含めた運用体制の設計や、障害時の継続体制づくりの経験は、この分野で重視される要素です。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 日本銀行「決済システムレポート」全銀システムの仕組み（2024年9月）
＊2 日本銀行「決済システムレポート」全銀システムの仕組み（2024年9月）
＊3 日本銀行「決済システムレポート」全銀システムの仕組み（2024年9月）
＊4 日本銀行「決済システムレポート」モアタイムシステム（2024年9月）
＊5 日本銀行「決済システムレポート」図表5 取扱金額・件数（2024年9月）
＊6 日本銀行「決済システムレポート」第8次全銀システムの基本方針（2024年9月）
＊7 日本銀行「決済システムレポート」第8次全銀システムの構成（2024年9月）
＊8 日本銀行「決済システムレポート」第8次全銀システムの構成（2024年9月）
＊9 日本銀行「決済システムレポート」システム障害の教訓（2024年9月）
＊10 Remoguサイト公開情報（フルリモート可能案件の割合）