監修者
リメディ株式会社 ヘッドハンター
緒方 隆恭 | OGATA Takayuki
東京大学を卒業後、三菱UFJ銀行に新卒入社。国内支店でMUFGの各種金融ソリューションの法人営業に従事し、銀行表彰を受賞。入社3年目で海外拠点に異動・駐在し、現地進出日系企業への融資・預金・為替デリバティブ商品等の法人営業を担当。
その後、三菱UFJモルガン・スタンレー証券に出向し、投資銀行本部にてカバレッジ業務に従事。上場企業のM&A（TOB・経営統合等）やエクイティファイナンス（IPO・PO等）のオリジネーション（案件獲得活動）・エグゼキューション（案件執行）を経験。現在はハイキャリア層や金融プロフェッショナルを中心とした採用・転職支援を行う。
金融ITでは、金融機関のIT企画、SIerの開発・PM、決済サービスの自社開発などが転職先になります。金融業務に詳しい人は要件の整理や導入推進、IT経験者は設計・開発・運用の実務を生かせます。希望する仕事を選ぶには、勤務先の種類に加え、自分がどの工程を担いたいかを考える必要があります。
銀行・SIer・決済事業者・コンサルの担当範囲
「銀行かSIerか」は勤務先の分類で、「企画か開発か」は担当工程の分類です。銀行のIT部門で開発会社と要件を詰める人もいれば、SIerで銀行の業務担当者と課題を整理する人もいます。銀行の社内SEも金融ITの仕事の一つです。勤務先と担当工程を分けると、希望する役割を絞り込めます。
| 勤務先 | 主な仕事 | 成果物の例 |
|---|---|---|
| 金融機関のIT部門 | 自社業務のシステム企画、開発・運用 | 業務要件、企画書、決定記録 |
| 金融向けSIer | 顧客向けシステムの設計・開発・PM | 設計書、試験結果、プロジェクト計画 |
| 決済事業者 | 自社決済の設計・実装、稼働後の改善 | 実装、試験、障害の分析 |
| 金融向けコンサルティング会社 | 構想・要件・計画の策定、開発の推進 | 提案書、要件、体制・進行計画 |
NRIの金融IT事業案内は、証券、資産運用、銀行、保険を別のサービス領域として紹介しています。金融ITという呼び方だけでは、扱う顧客業務もシステムも一つに決まりません。たとえば保険契約のシステムと資産運用のリスク管理では、確認する業務知識が異なります。
銀行を転職先として考える方は、先に預金・融資・為替と部門の違いを銀行業界の概要記事で押さえると、どの業務をシステムで支えるのかを考えやすくなります。
金融経験・IT経験から選ぶ応募先
金融業務に詳しい人は、現場の手続をシステムの要件に変える仕事に接点があります。IT経験者は、これまで担当した開発や運用を金融システムへ広げる道があります。転職準備の出発点は、業務知識とIT実務のどちらを経験してきたかです。
| 現在の経験 | 接点のある仕事 | 応募に向けて示す実務 |
|---|---|---|
| 金融の業務担当 | IT企画、業務要件の整理 | システム化で決めた条件、導入の調整 |
| 他業界の開発・PM | 金融向け開発、PM、決済開発 | 設計・実装・進行管理の担当範囲 |
| 他業界の運用・基盤 | 金融システムの運用・基盤 | 運用設計、顧客対応、障害改善 |
| 金融・ITとも未経験 | 開発・運用等で実務を得て金融領域へ | 設計・導入・障害対応などの担当経験 |
金融機関での勤務経験がある人は、業務知識とシステム導入への関与を分けて書きます。使いにくい画面を報告した経験と、利用部門の代表として要件を決めた経験では、担当範囲が異なります。新しい手続を決め、開発側との調整や導入判断を担ったなら、IT企画に関連する実務として説明できます。
金融以外のIT担当も、担当工程が合えば銀行IT企画、金融向けPM、決済開発を候補にできます。業務要件をまとめた経験、チームを管理した経験、設計・実装の経験など、希望する仕事に直接つながる実務を経歴書の中心に置きます。対象となる金融業務の知識は、そのシステムがどの取引や手続を支えるかから補います。
金融とITの両方が未経験なら、一般のIT開発・運用や業務改善の実務を経て、金融領域へ進む経路が考えられます。設計書の作成、システム導入、障害対応などを担当すると、次の応募で説明できる実務経験が得られます。
金融ITの年収を左右する役割と報酬制度
金融ITの給与は、勤務先と職位、任される役割によって変わります。実装を担うエンジニア、案件全体を管理するPM、システム投資を企画する担当者では、評価される責任の範囲が異なります。金融業界という括りだけで年収を比べると、この差が見えなくなります。
提示条件では、固定給、賞与、時間外手当の内訳を分けます。年俸制でも賞与を別に支給するか、年俸を何回に分けるかは制度によります。
金融ITの働き方とキャリアの広げ方
働く時間に影響するのは、担当システムの稼働と変更の予定です。開発ではリリース前の試験や修正、運用では当番や障害時の復旧が負担になり得ます。顧客先で働くか、在宅勤務を利用できるかも、契約やチームの体制によって変わります。
金融ITのキャリアには、銀行で業務部門とシステムの間をつなぐ道、SIerで開発からPMへ広げる道、決済事業者でサービス基盤の設計を深める道があります。今後も設計・実装を続けたい人と、顧客への提案やチーム管理を担いたい人では、次の職場に求める役割が変わります。
金融ITの求人を探す際は、担当したい工程と、銀行・保険・証券・決済などの対象業務を組み合わせると、希望する仕事を絞れます。
決済機能の改修に必要な企画・開発・運用
オンライン決済で同じ取引が二度処理されるおそれが見つかり、改修を進める場面を考えます。この場面で事業部門、開発担当、運用担当が決める条件はそれぞれ別です。
| 工程 | 決めること | 経歴書に示せる担当範囲 |
|---|---|---|
| 業務要件・企画 | 重複取引の扱い、画面表示、照会窓口 | 業務側と決めた条件、判断資料 |
| 設計・開発 | 取引の識別、同時処理、再送時の試験 | 設計・実装・試験の担当部分 |
| 運用受入・改善 | 監視、連絡、復旧、再発防止 | 運用条件、障害分析、改修後の検証 |
事業部門とIT企画の担当は、操作を繰り返した場合に何を一つの取引として扱うか、通信が切れたとき画面に何を表示するかを決めます。返金や照会を受ける窓口も業務の要件です。画面の文言だけを直しても、重複を防ぐ条件が曖昧なら問題は残ります。
開発担当は、取引を識別する値とデータの保存方法、同時に複数の要求が届いた場合の処理を設計します。正常終了に加え、途中で失敗した場合、再送された場合、別サービスへ結果を渡す場合も試験します。
運用担当は、決済結果と記録のずれを検知する監視、発生時の連絡先、サービスを元に戻す手順を準備します。改修後の受入条件や監視項目を定め、障害が起きたら原因と対策を開発担当と検討します。
金融業務・開発・運用の職務経歴書の記載例
職務経歴書には、案件の概要と、自分が決めた条件・作成したものを記載します。以下は、業務要件、開発、運用それぞれの担当経験を伝える記載例です。
金融業務から銀行のIT企画を考える人
「法人向けオンライン手続の見直しで、顧客への確認項目と支店の承認順を洗い出しました。現場から集めた例外処理を業務要件にまとめ、IT担当との会議で必須と後続対応を分けました。試験で見つかった手戻りは利用部門へ説明し、導入時の手順書を更新しました」。この人が説明できるのは、業務要件と導入調整に関する本人の判断です。
IT企画では、業務部門との検討で本人が何を決め、関係者をどう調整したかを示します。実際の担当が改善要望の提出までであった場合は、その範囲を正確に書きます。要望を出す際に調べた課題や、実現した変更も具体的な実績になります。
金融以外の開発から決済システムを考える人
「ECの注文APIで、同じ要求が再送された場合の重複登録を防ぐ処理を担当しました。識別値とデータ更新の条件を設計し、通信断・同時アクセス・再送を含む試験を作成しました。稼働後はエラーの記録を調べ、原因となる経路を改修しました」。設計、試験、稼働後の修正に本人が関わった範囲が伝わります。
バックエンド職では、使った言語、データの保存方法、並行処理への対応なども事実に即して補います。金融知識をこれから学ぶ場合は、経験済みの技術と学習中の業務を別々に書きます。
運用・基盤から金融のサービス管理を考える人
「複数システムの監視項目を見直し、利用部門と連絡手順を確認しました。障害時はログと構成情報を照合して影響範囲を共有し、復旧後に検知条件と手順を修正しました。新機能の受入では、運用へ渡す情報と未解決事項を一覧にしました」。監視の実行だけでなく、運用要件、顧客説明、改善の関与を示す例です。
運用・基盤の仕事では、顧客への説明を担うかどうかも担当範囲の違いになります。社内システムだけを担当した人は、社内調整と顧客対応を分けて書きます。資格名に加え、その知識を使って何を設計・改善したかが伝わる記述にします。
業務要件・技術・運用を分けた面接準備
システム企画では、「業務側が求めたこと」と「システムで実現できる範囲」が食い違った場面で、自分は何を決めたかが説明の中心です。開発や運用でも、チーム全体の対応と本人の判断を分け、開示できる範囲で職務経歴に要約します。
- IT企画：どの要件を優先し、業務部門とどう合意したか。
- 開発・PM：設計・試験の担当範囲と、品質・納期の課題への対応。
- 決済開発：再送や同時処理をどう設計し、稼働後に何を改善したか。
- 運用・基盤：受入条件、障害復旧、再発防止をどう決めたか。
「金融システムに関わりました」だけでは、業務要件を決めたのか、設計書を書いたのか、障害の復旧を担当したのかが伝わりません。面接では、チームの仕事を最初に説明した後、自分がした判断を一つ選び、判断材料、調整した相手、結果の順に話します。結果を数値で示す場合は、測定方法と、本人の対応が成果につながった過程を添えます。
管理職の募集を受ける場合は、個人の設計能力に加えて、計画、役割分担、対立する要件への判断も説明の対象になります。チームの成果と自分の管理責任を切り分け、任されていた範囲を示します。
金融ITへの転職に関するよくある質問
金融業界の経験がなくても、開発経験があれば応募できますか？
金融以外の開発経験を対象に含む募集があります。応募時は使った言語だけでなく、データの整合性、再送、障害対応など、担当したサービスの品質をどう保ったかが説明材料です。決済・取引の業務知識は、応募するシステムに合わせて補います。
銀行の営業職からIT企画へ移るには、プログラミングが必要ですか？
開発経験を一律に必須としないIT企画の募集もあります。業務部門で要件を定義し、システムの導入を進めた経験を生かせる仕事もあります。営業から応募するなら、プログラミングの学習歴より先に、システム導入で何を要件として決め、開発側とどう調整したかが応募書類の材料になります。画面への要望を伝えただけの経験と、要件をまとめて導入を進めた経験は区別します。
金融ITは、どの会社でも夜間や休日の対応が多いのでしょうか？
担当するシステムと業務で変わります。保守・運用、リリース、障害対応を担う仕事と、企画・開発を中心とする仕事では、勤務の条件が異なります。銀行、SIer、決済事業者という会社の種類だけでは頻度を決められません。時間帯を重視する場合は、応募職種に当番や緊急対応が含まれるか、その担当範囲から働き方を検討できます。
銀行のIT部門に入ると、自分で開発する機会はなくなりますか？
銀行のIT部門という名称だけでは、コードを書く仕事かどうかは分かりません。企画・案件推進が中心の仕事もあれば、設計・開発を担う仕事もあります。実装を続けたい人にとっては、自社の社員と開発委託先のどちらがコードを書くかも、仕事内容を捉える材料です。
関連記事
銀行の事業を理解したうえで応募書類や面接を準備したい人に向け、業界概要・職務経歴書・技術選考の記事をまとめました。