金融系のシステム子会社で、銀行決済・クレジットカード・金融グループの国際規制対応といった領域を渡り歩いてきて約20年。同業以外の方からよく聞かれることがあります。「地味な裏方の仕事で飽きないの？」「プレッシャーがきつそう」——どちらも半分は当たっていて、半分は違います。
この記事では、技術的な深掘りではなく、金融SEという仕事の現場感覚を率直に書いてみます。私は業務部門のニーズを聞き取って、それをシステムにどう落とし込むかを設計する立場（いわゆる上流工程の業務SE）なので、コードを1行ずつ書くプロではありません。ただ、金融業務の中身とその裏で動いている仕組みの全体像を、現場で揉まれながら自分なりに積み上げてきたつもりです。
関連する技術的な話題として、勘定系のクラウド移行そのものの解説は銀行の勘定系システムのクラウド移行——進む理由と、まだ進まない理由を中の人が解説するにまとめています。本記事は、その「中の人視点のサイドB」として読んでいただけると嬉しいです。
1. 金融システムの「作り替え」はなぜこれほど難しいのか
私が直接担当してきたのは勘定系本体そのものではありませんが、決済系やカード系、規制対応系の大規模なシステム更改プロジェクトには、何度か当事者として関わってきました。そこで毎回痛感するのは、新規に一から作るよりも、既存システムを作り替えるほうが圧倒的に難しいということです。
理由は、求められるニーズが「現行システムの機能そのもの」になる点にあります。本来なら設計書や仕様書を頼りに作り直せばいいのですが、長年運用されてきたシステムではドキュメントが抜け落ちていたり、最新の挙動と一致していなかったりすることが少なくありません。ユーザー部門自身も自分たちが使っている機能の全容を把握しきれていないことが多く、現場では「プログラムが正しい（＝動いているコードが仕様）」という状態になっているのが実態です。
上流の業務SEとして一番時間を取られるのは、この「動いているものを言語化し直す」作業です。現行の挙動をヒアリングと過去資料とコードの突き合わせで再定義し、新システムの要件として書き起こす——この工程を雑にやると、後ろの設計・開発・テスト工程がすべて崩れていきます。
加えて、社会インフラとしての重みも制約になります。金額規模の大きい重要システムではトラブルゼロを目指す文化が根強く、万一トラブルが起きれば原因分析を深く掘り下げ、再発防止として必ず何かしらのアクションを打つことを常に求められます。
一般論として、「80点を取る」ところまでは費用対効果が高くできるのですが、そこから「100点に近づける」には莫大なコスト（働く人の視点でいうと手間と時間）がかかります。金融システムの現場は、この100点に近づけるコストを惜しまずかけ続けている世界です。移行テストの量も一般のシステム開発の比ではなく、金額計算の結果が旧システムと1円も違わないことを確認する突合テストを、大量データで何度も繰り返すことになります。
「ほぼ問題ないと思うけれど、100%の保証はない」という状態で本番切替を決断するプレッシャーは、相当なものです。
2. 本番を守る、というシステム屋の矜持
私自身の経験で、今でも一番の失敗だと思っていることがあります。新人の頃、上司不在のまま、開発環境での経験だけをもとに「できます」とユーザーに答えてしまったことです。緊急対応が必要で時限までの時間も限られているにもかかわらず、これまで本番環境で実施したことがないような異例的な作業でした。
本番環境で前例のない作業を行うときには、手順書の作成→テスト→実施という一連のプロセスが必要です。開発環境でうまくいった経験は、本番ではほとんどあてになりません。金融システムでトラブルを起こせば、顧客や社会へのインパクトは計り知れません。その状況で「できる」と言ってしまったのは、若さゆえの判断ミスでした。
その後、戻ってきた上司と状況を共有したときのことは今でも鮮明に覚えています。上司はユーザーに対して「絶対にやらない」と毅然と断り、怒られながらもその姿勢を崩しませんでした。印象的だったのは、感情的にではなく理路整然と理由を説明していたことです。曰く、「確実ではない作業をやって二次被害を起こすほうが、ユーザー業務への影響ははるかに大きい」——断ることで一時的に怒られたとしても、不確実な作業で本番トラブルを重ねるほうが、結果的にユーザーにとって最悪の展開になるというロジックでした。
この経験から学んだのは、ユーザーに「No」と言うことが、最終的にはユーザーのためになるという感覚です。本番システムを守ることは、エンジニアとしての矜持だと考えるようになりました。業務SEの立場では「ユーザーの要望をどう叶えるか」を考えるのが仕事ですが、同時に叶えない／先送りするという選択肢を理路整然と提示する勇気も、経験とともに身につけるべき仕事のひとつだと思っています。
3. 普段は「No」ではなく「こうやったらできる」を返す
一方で、同じ上司から教わったもう一つの姿勢があります。普段の仕事では、ユーザーのニーズに対して安易に「No」とは言わないということです。できない理由を並べるのではなく、「こうやったらできる」「こういう形なら実現できる」という代替案を提案する——これを徹底するように言われてきました。
これはその会社のカルチャーでもあるのですが、それ以上に大事な視点があります。ユーザーは敵でもお客様でもなく、良いサービスを世の中に届けるための仲間である、という捉え方です。無茶な要求が続くと、つい「敵」のように感じてしまう瞬間もあるのが正直なところですが、それでも「仲間」として見続けることが、金融会社のシステム系子会社として求められる視点なのだと考えています。
まとめると、普段は「こうやったらできる」を返し、本番を危険にさらす場面でだけ「No」を理路整然と言う——この両輪が、業務SEとしての立ち位置だと思っています。どちらか一方だけでは、ユーザーとの信頼も、本番システムの安全性も、守りきれません。
4. 準備と設計が結果を決める
もう一つの学びは、準備の重さです。「本番でうまくいくかどうかは、準備の質がそのまま返ってくる」——この実感は、金融システムに限らずあらゆる仕事に共通します。
なかでも、計画・要件定義・設計という初期工程の重要性は特別です。業務SEの仕事は実装工程ではなく、この初期工程に比重が寄っています。工程全体の5割以上の力をここに注ぐことで、後工程が格段に楽になります。逆に設計を雑にすると、後からのやり直しが何倍もの工数になって返ってきます。「急がば回れ」は、システム開発の現場では本当のことです。
これは開発スタイルとも密接に関係しています。近年はアジャイル開発が流行していますが、金融系の大規模システムでは設計→製造→テストという順序で進めるウォーターフォール開発がいまも主流です。ウォーターフォール型では、後工程のテストで「こうじゃなかった」が見つかると、最初の設計からやり直しになる構造を抱えています。後ろに進むほど、出戻りのコストは指数関数的に膨らみます。だからこそ、より上流の工程で「こうじゃなかった」を徹底的に潰しておくことが、結果としてプロジェクト全体の成否を分けることになります。
5. この仕事の充実感：ダイナミックさとニュースとのつながり
技術・プロセスの話が続きましたが、少し視点を変えます。
20年この仕事を続けてこられた理由のひとつが、スケールのダイナミックさです。関わってきたシステムは、決済系・カード系を含めて1件あたりの金額が数万〜数百万円規模、1日分を合計すると億〜兆円単位に積み上がるものばかりでした。件数や顧客数も、一般の業務システムとはケタが違います。最初に担当したシステムで、上司から「このシステムが止まると日本経済に影響が出る」と言われたのが今も記憶に残っています。今は代替手段や冗長構成が整備されているのでそこまでではありませんが、上司の意図はよく理解できる規模感でした。
もうひとつの充実感が、金融ニュースと自分の仕事が直接つながっていることです。銀行の新規制が発表される、クレジットカード会社の手数料や不正対策の仕組みが見直される、国際的な送金・マネロン規制が変わる——そういうニュースを見たとき、「これは自分が今関わっているシステムに関係してくる」と気づく瞬間があります。社会の変化が自分の仕事に直接影響し、自分の仕事が社会の一部を支えている。この実感が、技術的に地味な作業が続くときでも前に進む動機になっています。
金融システムの仕事は表に出にくい裏方ですが、社会インフラの一端としての責任の大きさと、その分のやりがいは本物だと感じています。
まとめ
- 既存金融システムの作り替えは新規開発より難しい。ドキュメントが追いつかず「動いているコードが仕様」の世界になりがち
- 金融システムはトラブルゼロを目指す文化が根強く、「80点→100点」に近づけるコストを惜しまない世界
- 本番では「できる」と軽く言わないこと。二次被害のほうが怖いので、不確実なら理路整然と「No」と言うこと
- ただし普段は「No」ではなく「こうやったらできる」を返す。ユーザーは敵でもお客様でもなく、良いサービスを届けるための仲間
- ウォーターフォール型の現場では、上流工程での「こうじゃなかった」潰しが命。計画・要件定義・設計に全工数の5割以上を注ぐのが結局いちばん早い
- 億〜兆円規模の金額を扱うダイナミックさと、金融ニュースが自分の仕事と直結する感覚は、裏方ならではのやりがい
勘定系のクラウド移行そのものの技術的な論点はこちらの記事にまとめています。本記事はその「中の人視点のサイドB」として読んでいただけると嬉しいです。
