金融システム開発の成否は上流工程で決まります。要件定義の抜け漏れやアーキテクチャの選択ミスが、数億円規模の手戻りや大規模障害につながった事例は枚挙にいとまがありません。2021年に8回ものシステム障害を引き起こしたみずほフィナンシャルグループの事案、2023年の全銀ネット障害—いずれも根本原因を辿ると、上流工程における設計判断の問題に行き着きます。本記事では、金融情報システム開発に20年以上携わってきたテンファイブの知見をもとに、要件定義から基本設計、アーキテクチャ設計までの上流工程の実務プロセスを、具体的なチェックポイントとともに解説します。
金融システムにおける上流工程の全体像
上流工程の4フェーズ—企画・要件定義・基本設計・アーキテクチャ設計
金融システム開発の上流工程は、大きく4つのフェーズに分かれます。各フェーズの目的と成果物を正確に理解することが、プロジェクト成功の第一歩です。
フェーズ1: システム企画。経営戦略に基づき、投資対効果の試算、概算スケジュール、体制計画を策定するフェーズです。テンファイブの経験上、このフェーズでの検討不足が後続フェーズでのスコープクリープを引き起こすケースが非常に多く見られます。
フェーズ2: 要件定義。機能要件と非機能要件を洗い出し文書化するフェーズです。金融システムでは法規制要件やセキュリティ要件が膨大なため、他業界の2〜3倍の工期を要することも珍しくありません。
フェーズ3: 基本設計（外部設計）。要件をシステムの「外から見た振る舞い」として具体化します。金融システムでは特に帳票設計と外部インターフェース設計の比重が大きく、全銀フォーマット、SWIFT MT/MXメッセージなどの連携仕様の正確な設計が求められます。
フェーズ4: アーキテクチャ設計。技術スタック選定、システム構成図の作成、非機能要件を実現するためのインフラ設計を行います。このフェーズでの選択がシステムの保守性・拡張性を10年以上にわたって規定するため、最も慎重な判断が求められます。
これらのフェーズの基礎的な概要については、以前の記事「金融システム開発の上流工程とは？」で解説しています。本記事ではさらに踏み込んで、各フェーズの実務プロセスを具体的に紹介します。
金融業界の上流工程が他業界と決定的に異なる3つの理由
金融システムの上流工程は、ECサイトや業務系SaaSの開発とは根本的に異なります。その違いを生む3つの要因を整理します。
第一: 法規制への準拠が設計を制約する。銀行法、犯罪収益移転防止法、FISC安全対策基準など、金融システムの設計は常に規制の枠内で行わなければなりません。FISC安全対策基準第13版（2025年3月公表）では全体の約3割が改訂され、AI利用やオペレーショナル・レジリエンスに関する新基準が追加されています。
第二: 「止められない」制約がある。勘定系は24時間365日の稼働が求められ、メンテナンスウィンドウは極めて限定的です。リリース戦略、データ移行計画、切り替え手順のすべてが上流工程で検討されます。
第三: ステークホルダーが多層的かつ多数存在する。IT企画部門、業務部門、リスク管理部門、コンプライアンス部門、内部監査部門、さらに金融庁や日銀への届出も発生します。各部門の要件は時に相反し、その調整が上流工程の最大の工数を占めます。
上流工程の品質がプロジェクト全体のコストを左右するメカニズム
「1:10:100の法則」として知られるように、要件定義で修正すればコスト1の問題が、テスト段階では100倍のコストになります。金融システムではこの倍率がさらに大きくなります。テンファイブが参画したプロジェクトでも、要件定義で見落とされた規制要件が結合テスト段階で発覚し、数千万円規模の追加コストと半年以上のスケジュール遅延が発生したケースがあります。金融庁の分析レポートでも、システム障害の原因として「ソフトウェア障害」と「管理面・人的要因」が約7割を占めており、上流工程の品質向上は金融サービスの安定稼働に直結します。
金融システムの要件定義—現場で使える実務プロセス
業務要件の整理—勘定系・情報系・チャネル系で異なるアプローチ
金融システムは大きく「勘定系」「情報系」「チャネル系」の3つに分類され、それぞれ要件定義のアプローチが異なります。
勘定系システムは、口座管理・元帳・決済処理など、金融機関の根幹をなすシステムです。要件定義ではトランザクションの整合性が最優先事項となります。「この口座振替が途中で失敗した場合、残高はどうなるか」「日次バッチの途中でシステムが停止した場合、どこからリランするか」といった異常系の要件を徹底的に洗い出す必要があります。勘定系の要件定義では、業務部門へのヒアリングだけでなく、現行システムの処理フローを実際のジョブネットレベルで解析することが不可欠です。
情報系システムは、CRM、データウェアハウス、リスク管理システム、レポーティングなど、分析・管理用途のシステムです。要件定義ではデータの鮮度と集計ロジックが焦点となります。「このレポートの数値は何時時点のデータに基づくか」「月次と日次で集計ロジックが異なる場合の整合性をどう担保するか」といった問いに答える必要があります。情報系では、利用部門が「欲しい情報」を言語化できないケースも多く、プロトタイプやモックアップを活用した反復的な要件確認が有効です。
チャネル系システムは、インターネットバンキング、モバイルアプリ、ATMなど、顧客接点のシステムです。要件定義ではUX（ユーザー体験）とセキュリティのバランスが核となります。「振込時の認証ステップを何回にするか」「ワンタイムパスワードの入力をスマホアプリの生体認証に置き換えられるか」といった要件は、利便性とセキュリティのトレードオフの中で決定されます。金融システム開発の基礎知識については「未経験からでも分かる！金融システム開発の基礎と実務」で詳しく解説していますので、併せてご参照ください。
機能要件定義のフレームワークと成果物一覧
金融システムの機能要件定義で作成する成果物は多岐にわたります。テンファイブが実際のプロジェクトで使用しているフレームワークをベースに、主要な成果物を整理します。
- 業務フロー図（As-Is / To-Be）: 現行業務と新システム導入後の業務を対比する形で作成します。金融機関ではアナログな業務フローが残っていることも多く、システム化の判断基準を明示することが重要です
- 機能一覧: 大機能・中機能・小機能の3階層で分類し、各機能のCRUD区分と優先度を明記します。金融システムでは機能数が500〜1,000を超えることも珍しくありません
- 画面遷移図: 金融機関の画面設計では、セッションタイムアウト時の遷移先や二重送信防止など、異常系の画面遷移が通常のWebアプリケーションよりも格段に多い点が特徴です
- ER図: 勘定系では口座・取引・顧客のエンティティ間の関係が複雑になるため、ER図の設計品質がシステム全体のパフォーマンスと保守性を左右します
- 外部インターフェース定義書: 全銀システム、日銀ネット、SWIFT、CAFISなど多数の外部システムとの連携仕様を正確に定義します。現場の経験上、この定義の不備が結合テスト段階での手戻りの最大の原因となっています
ステークホルダー管理—銀行IT企画・業務部門・コンプライアンス・規制当局との調整術
金融システムの要件定義で最も工数がかかるのは、技術的な検討ではなくステークホルダー間の合意形成です。テンファイブが20年以上の現場経験で培ったステークホルダー管理のポイントを共有します。
IT企画部門との調整。IT企画部門はプロジェクトのオーナーであり、予算・スケジュール・スコープの最終決定権を持っています。要件定義フェーズでの最も重要な調整事項は「スコープの確定」です。業務部門からの要望は際限なく膨らむ傾向があるため、IT企画部門と「何をやり、何をやらないか」の線引きを早期に合意することが不可欠です。テンファイブでは、要件を「Must（必須）」「Should（推奨）」「Could（あれば便利）」「Won’t（今回は対象外）」のMoSCoW法で分類し、IT企画部門と業務部門の間でプライオリティを可視化する手法を多用しています。
業務部門との調整。業務部門は「現行の業務が滞りなく回ること」を最優先に考えます。新システムへの移行に対する不安が強く、「現行踏襲」を要望するケースが多々あります。しかし、現行踏襲をそのまま受け入れると、老朽化した業務プロセスがそのまま新システムに移植されてしまいます。ヒアリングの際は「なぜその業務手順が必要なのか」「その手順がなくなった場合の影響は何か」を丁寧に掘り下げ、業務改善の提案と要件定義を同時に進めることが重要です。
コンプライアンス部門との調整。AML（アンチマネーロンダリング）、KYC（本人確認）、個人情報保護に関する要件は綿密な協議が必要です。コンプライアンス部門は「法規制違反のリスクをゼロにしたい」立場のため、業務部門の利便性要件と相反することがあります。規制当局への対応も重要です。勘定系の全面刷新やクラウド移行では、プロジェクト計画段階で金融庁への事前相談が推奨されます。金融庁「2025事務年度 金融行政方針」ではシステムリスク管理の強化が打ち出されており、当局の関心は高まっています。
要件定義フェーズで陥りがちな3つの失敗パターン
金融システムの要件定義で繰り返し見られる失敗パターンを3つ紹介します。
失敗パターン1: 非機能要件の後回し。「まず機能を固めてから、非機能は後で」という進め方は、金融システムでは致命的です。可用性99.99%の要件と、週1回のバッチウィンドウ確保の要件を同時に満たすには、アーキテクチャレベルでの設計判断が必要です。これを基本設計フェーズで初めて検討した場合、要件定義からの手戻りが確実に発生します。テンファイブでは、機能要件のヒアリングと並行して非機能要件を定義する「ツイントラック」方式を採用しています。
失敗パターン2: 「現行踏襲」の罠。業務部門は「現行踏襲」を強く要望しますが、「現行」の仕様が正確にドキュメント化されていないケースが大半です。10年前の設計書しかなく改修が反映されていないため、仕様解析に膨大な工数がかかります。リバースエンジニアリングの工数をプロジェクト計画段階で適切に見積もることが重要です。
失敗パターン3: 要件のトレーサビリティ欠如。「この要件は誰が、なぜ要望したのか」が追跡できない状態は、後続フェーズでの設計判断を困難にします。要件管理ツールを用いて、起案者・承認者・関連法規制・優先度を紐づけて管理することが不可欠です。
金融特有の非機能要件を定義する
可用性—99.99%稼働を実現するための設計判断
金融システムの可用性要件は、業界の中でも最も厳格です。「99.99%の可用性」とは、年間のダウンタイムがわずか約52分以内であることを意味します。この数値を実現するには、以下の設計判断が要件定義段階で必要です。
冗長構成の方針。Active-Active構成かActive-Standby構成か。Active-Active構成はフェイルオーバー時のダウンタイムをゼロに近づけますが、データの同期メカニズムが複雑になります。勘定系のようなトランザクション整合性が最優先のシステムでは、同期レプリケーションによるActive-Standby構成が選択されることが多い一方、チャネル系ではActive-Active構成が主流です。
DR（ディザスタリカバリ）設計。プライマリサイトとDRサイトの構成、データ同期方式を定義します。RTO（目標復旧時間）とRPO（目標復旧時点）は業務部門と協議して決定しますが、勘定系ではRPO=0（データ損失ゼロ）が求められることが一般的です。計画停止の扱い（メンテナンスウィンドウの確保、無停止デプロイメントの可否）もアーキテクチャ選択に直結する要件として定義します。
セキュリティ—FISC安全対策基準とPCI DSSの要件を設計に落とし込む
金融システムのセキュリティ要件は、主にFISC安全対策基準とPCI DSS（クレジットカード情報を扱う場合）に基づいて定義されます。セキュリティ設計の詳細については「銀行システムのセキュリティ設計手法と最新ベストプラクティス」で解説していますが、ここでは要件定義段階で確定すべき主要ポイントを整理します。
認証・認可方式。利用者の認証方式（ID/パスワード、多要素認証、生体認証）と、認可の粒度（機能単位、データ単位、取引金額単位）を定義します。FISC安全対策基準第13版では、特権アカウント管理の強化が改訂ポイントのひとつであり、システム管理者のアクセス制御についても要件として明確化する必要があります。
暗号化方針。通信の暗号化（TLS 1.3）、保存データの暗号化（AES-256）、鍵管理の方式を定義します。鍵管理は金融システムのセキュリティの根幹であり、HSM（Hardware Security Module）の利用可否、鍵のローテーション間隔、鍵の世代管理方式を要件定義段階で確定させます。
監査証跡（ログ）の要件。「誰が、いつ、どのデータに、どのような操作を行ったか」を記録する監査ログの要件は、金融庁検査やFISC監査への対応として必須です。ログの記録粒度、保存期間（金融機関では最低7年が一般的）、改ざん防止の仕組み（WORM storageなど）を定義します。
性能・拡張性—ピーク時トランザクション処理の見積もり方
金融システムの性能要件は、「平常時」と「ピーク時」の2つの軸で定義します。銀行の勘定系であれば給与振込日（毎月25日前後）、年金支給日（偶数月15日）、年末年始がピーク日となります。これらのトランザクション量を過去データから分析し、将来の成長率を加味して性能要件を算出します。オンライン処理のレスポンスタイムは取引種類ごとに目標値を設定し（口座照会は3秒以内、振込は5秒以内など）、バッチ処理はバッチウィンドウ内での完了を保証する処理量の見積もりが必要です。スケーラビリティについても、スケールアップかスケールアウトか、オートスケーリングの可否を要件として定義します。
監査対応—ログ設計と証跡管理の要件定義
金融システムでは、内部監査、外部監査（監査法人）、当局検査（金融庁）の3つの監査に対応する必要があります。要件定義段階で以下の3点を組み込むことが重要です。
- 記録対象の定義: すべてのデータアクセス、権限変更、ログイン/ログアウト、異常検知イベントを対象とします。特に「特権アカウントの操作」と「顧客データへのアクセス」は記録粒度を上げることが推奨されます
- ログの保全性: WORM（Write Once Read Many）ストレージの利用や、ログの長期保存先を別アカウント・別リージョンに配置する設計が実務的なベストプラクティスです。保存期間は金融機関では最低7年が一般的です
- 証跡の追跡性: トランザクションIDによるログの紐づけにより、「この取引はどのような経緯で処理されたか」をエンドツーエンドで追跡できるようにします。マイクロサービスの場合は分散トレーシング（OpenTelemetryなど）の導入が必要です
アーキテクチャ設計—金融システムの選択肢と判断基準
モノリス vs マイクロサービス—金融システムにおける現実的な選択
金融システムのアーキテクチャ選択において、「モノリスかマイクロサービスか」は最も議論されるテーマのひとつです。結論から言えば、金融システムでは「どちらか一方」ではなく、領域ごとに使い分けるのが現実的です。
勘定系ではモノリス（またはモジュラーモノリス）が現実解です。分散トランザクションの複雑さがマイクロサービスの最大のネックであり、障害時のリカバリが極めて困難になります。ただし、モジュール間の境界を明確に定義した「モジュラーモノリス」であれば、将来的な段階的移行への道を残せます。情報系・チャネル系ではマイクロサービスの適用余地が大きく、結果整合性が許容される領域では、独立デプロイや技術スタックの最適化によって開発速度を向上できます。
クラウドネイティブ化の最新動向—ソニー銀行・SBI新生銀行の事例に学ぶ
金融機関のクラウド移行は、もはや「検討段階」ではなく「実行段階」に入っています。2025年から2026年にかけて、象徴的な事例が相次いで登場しました。
ソニー銀行は2025年5月にAWS上で新勘定系システムの稼働を開始し、マイクロサービス化により資産規模を従来の40%に削減しました。勘定系のクラウド移行は「理論上は可能だが現実には困難」と見られてきましたが、この事例はその認識を大きく変えています。
SBI新生銀行は2026年1月に、AWS上でクラウドネイティブな次世代バンキングシステムへの刷新を発表しました（2029年度下期〜2030年度上期稼働予定）。勘定系を含むフルスタックでのクラウドネイティブ化を目指す業界のマイルストーンとなるプロジェクトです。
これらの事例は、クラウドネイティブな設計を金融の規制要件に適合させるための上流工程の重要性を改めて浮き彫りにしています。
API設計とシステム間連携—金融基盤としてのAPI管理
銀行APIのオープン化やBaaS（Banking as a Service）の広がりにより、APIの設計品質が事業競争力に直結する時代になっています。金融システムのAPI設計で特に重要なポイントは3つあります。
API Gatewayの設計。すべてのAPI呼び出しをAPI Gateway経由で管理し、認証・認可（OAuth 2.0 / OpenID Connect）、レート制限、ログ記録を一元的に実施します。APIバージョニングでは、一度公開したAPIは簡単に変更できないため、バージョニング戦略と旧バージョンの廃止ロードマップを設計段階で策定します。そして冪等性の設計。金融取引のAPIでは、リトライ時に同じ取引が二重処理されないよう冪等性（idempotency）を保証する設計が不可欠です。
技術的負債を生まないアーキテクチャ判断の記録方法（ADR）
金融機関のシステムは10年以上にわたって運用されるため、「なぜこの技術を選んだのか」の判断理由を記録しておくことが極めて重要です。この目的に有効な手法がADR（Architecture Decision Records）です。ADRは各判断について、タイトル、ステータス（提案中/承認済み/廃止）、背景・制約条件、決定内容、検討したが採用しなかった代替案、この判断によるメリットとリスクをフォーマットに沿って記録します。
テンファイブのプロジェクトでは、ADRをGitリポジトリ内にMarkdownファイルとして保存し、バージョン管理しています。数年後のシステム改修時に「当時なぜこの設計にしたのか」を正確に把握でき、技術的負債の抑制に効果があります。
上流工程を成功に導くプロジェクト運営のポイント
ウォーターフォールとアジャイルのハイブリッド—金融での現実解
金融システム開発の上流工程では、純粋なウォーターフォールでも純粋なアジャイルでもない、ハイブリッド型のアプローチが現実解となっています。規制対応の要件は網羅的に定義する必要があるため、「イテレーションの中で発見していく」アプローチではリスクがあります。一方、チャネル系のUI/UXはプロトタイプベースの反復的アプローチが有効です。テンファイブでは、「全体のマイルストーンと承認プロセスはウォーターフォール、個別セクションの詳細化はアジャイル」という二層構造を推奨しています。
レビュー体制の設計—品質を担保する多段レビューの仕組み
金融システムの上流工程では、成果物の品質を担保するための多段レビュー体制が特に重要です。テンファイブでは以下の3段階を推奨しています。第1段階のピアレビューでは、同等のスキルを持つメンバーが技術的な正確性と内部整合性を確認します。第2段階のクロスファンクショナルレビューでは、異なる専門性を持つメンバーが領域横断でチェックします（インフラ担当がアプリ設計を、セキュリティ担当が業務フローを確認するなど）。第3段階のステークホルダーレビューでは、IT企画部門・業務部門・コンプライアンス部門による公式承認を得ます。金融庁検査では「この要件は誰が承認したか」の証跡が求められるため、レビュー結果の記録は実質的な意味を持ちます。
PoC（概念実証）の活用—リスクを早期に潰す技術検証の進め方
アーキテクチャ設計で「理論上は可能だが、実際に動くかどうかは検証が必要」という判断が出てくることは珍しくありません。特に、新技術の採用やクラウドサービスの活用において、PoCの実施は上流工程のリスク低減に不可欠です。
PoCの設計ポイント。金融システムのPoCでは、以下の3点を明確にしてから実施することが重要です。
- 検証する仮説: 「AWS上でFISC基準に準拠した勘定系を構築できるか」のように、Yes/Noで判定できる仮説を設定します
- 成功基準: 「レスポンスタイム3秒以内」「同時接続1,000ユーザーでの安定稼働」のように、数値で判定できる基準を設定します
- PoCの範囲とスケジュール: PoCが際限なく拡大しないよう、検証範囲とタイムボックス（2〜4週間が一般的）を事前に確定します
テンファイブの経験では、PoCの結果が「不可」となった場合でも、その判断材料として大きな価値があります。「この技術は採用しない」という判断を上流工程で下せることで、本格開発フェーズでの手戻りを防ぐことができるためです。
テンファイブの上流工程支援—20年の金融開発で培った実務力
金融SES専門企業として上流工程を支援できる理由
テンファイブ株式会社は、金融情報システム開発に20年以上にわたって特化してきたSES企業です。上流工程の支援において、以下の3つの強みを持っています。
- 金融ドメイン知識の蓄積: 銀行、証券、保険など各サブドメインの業務知識とシステム知識を組織として蓄積しています。要件定義で業務部門と対等に会話でき、「この業務フローはなぜこうなっているのか」を理解した上でシステム設計に反映できるエンジニアが在籍しています
- 規制対応の実践知: FISC安全対策基準、金融庁監督指針、銀行法など、法規制への対応実績を豊富に持っています。「基準書に書かれていること」と「実際の監査で問われること」のギャップを埋められるのは、現場経験があるからこそです
- 上流から下流までの一貫した対応力: 要件定義・基本設計と実装・テストの双方のスキルを備えたエンジニアを擁しており、上流工程の設計判断に実装の視点を反映できます
金融SEとしてのキャリアパス—上流工程エンジニアの市場価値
金融システム開発の上流工程を担えるエンジニアは、市場での希少性が極めて高い人材です。金融ドメイン知識、技術的な設計力、ステークホルダーとのコミュニケーション力の3つを兼ね備えたエンジニアの需要は、金融DXの加速に伴って今後さらに拡大することが見込まれます。
テンファイブでは、実装フェーズからキャリアをスタートし、段階的に上流工程へステップアップしていくキャリアパスを用意しています。現場のOJTを通じて金融ドメイン知識を習得しながら、要件定義や基本設計のスキルを磨くことができます。金融SEのキャリアに興味をお持ちの方は、ぜひテンファイブの採用情報をご確認ください。
まとめ
金融システムの上流工程は、業務知識・技術力・規制対応力の3つが揃って初めて成功します。本記事で解説したポイントを改めて整理します。
- 要件定義では機能要件と非機能要件を並行して定義することが重要です。非機能要件を後回しにすると、アーキテクチャレベルでの手戻りが発生します
- 金融特有の非機能要件（可用性99.99%、FISC安全対策基準への準拠、監査証跡の設計）は、要件定義段階で具体的な設計判断と紐づけて定義する必要があります
- アーキテクチャ設計では、ソニー銀行やSBI新生銀行の事例に見られるクラウドネイティブ化のトレンドを踏まえつつ、勘定系・情報系・チャネル系の領域ごとに最適な構成を選択することが求められます
- ステークホルダー管理は上流工程の最大の工数要因であり、MoSCoW法による優先度の可視化や多段レビュー体制の設計が品質と合意形成の両立に有効です
- ADR（Architecture Decision Records）による設計判断の記録は、10年以上にわたって運用されるシステムの技術的負債を抑制するために不可欠です
テンファイブは金融情報システム開発に20年以上特化してきたSES企業として、要件定義からアーキテクチャ設計まで上流工程の全フェーズを支援できる体制を整えています。金融システムの上流工程に課題をお持ちの方、金融SEとしてのキャリアアップに興味をお持ちのエンジニアの方は、ぜひお気軽にご相談ください。
