LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

金融の案件なので、銀行の業務が分かる人に来てほしい。でも、金融業の経験を条件にすると候補者が見つからない——。銀行や保険会社のシステム開発に外部エンジニア（業務委託などで社外から開発に加わるエンジニア）を迎える現場では、こうした迷いが起こりがちです。ここでいう金融業の業界知識とは、預金や送金、融資といった業務の流れと、金融機関に課される法令や監督の決まり、それを踏まえた社内のルールを知っていることを指します。

業界知識があれば、業務部門との打ち合わせや、障害が起きたときの影響の見極めは進めやすくなります。ただし万能ではなく、頼む作業によって要る知識の深さは変わります。本記事では、金融機関のシステム開発に外部エンジニアを加えるマネージャーに向けて、業界知識の中身、金融業で知識が問われる理由、監督指針が委託先に求めること、作業ごとの切り分け方、そして外部に頼むときに確認したい点を整理します。

金融業の業界知識とは

業界知識は、業務の知識と決まりの知識の2つに分けると整理しやすくなります。業務の知識は、預金の入出金、振込や送金、融資の審査や返済といった仕事がどんな順で進み、そのときどのデータが動くのかを知っていることです。決まりの知識は、銀行法などの法令、金融庁が検査や監督に使う監督指針、そしてそれを踏まえて金融機関ごとに定めた社内のルールを知っていることです。

業務の知識がシステムの管理にそのまま関わる例は、大手銀行などを対象にした金融庁の「主要行等向けの総合的な監督指針」にも出てきます。システムリスクの着眼点（金融庁が検査や監督で確かめる点）の1つに、「1口座当たりの未記帳取引明細の保有可能件数などのシステムの制限値」を把握・管理し、超えた場合の対応策を検討しているか、という項目があります。^*1 未記帳の取引明細とは、通帳にまだ印字されていない入出金の記録のことです。通帳に記帳するという業務の仕組みを知らないと、この上限がなぜ問題になるのかが分かりにくいでしょう。

なお、本記事では、プログラミング言語やクラウドといった技術の知識は業界知識に含めません。技術の知識はどの業界の開発でも要るもので、金融業に特有のものではないからです。

なぜ金融業で知識が問われるのか

監督指針は、システムリスクを、システムのダウンや誤作動などに伴い顧客や銀行が損失を被るリスクなどとしています。そのうえで、主要行等でシステム障害などが起きた場合、その影響は一銀行の問題にとどまらず「金融システム全体に及びかねない」と述べています。^*1 金融機関のシステムの障害は、自社の業務が止まるだけでは済まない、という前提です。

障害を当局へ報告する決まりにも、業務の知識が関わります。監督指針は、報告すべきシステム障害として、預金の払戻しや振込・送金などの決済機能に遅延や停止が生じているもの、またはそのおそれがあるものなどを挙げています。^*1 障害が起きたとき、止まった機能が入出金や振込のどこに関わるのかを業務の言葉で説明できる人がいれば、銀行の担当者は報告が要るかどうかを判断しやすくなります。

一方で、監督指針が「十分な知識・経験」を求めている相手は、外部エンジニアではなく、システムを統括管理する銀行の役員です。取締役会がそうした知識・経験を持つ者をこの役員として定めているかを確かめる、という着眼点になっています。人材の育成についても、現行システムの仕組みと開発技術の継承、専門性を持った人材の育成のための具体的な計画を、銀行が策定して実施しているかを問うています。^*1 知識と経験を求める記述は、まず銀行自身の体制に向けられています。

監督指針が委託先に求めること

外部エンジニアに関わる記述は、外部委託管理の着眼点にあります。監督指針は、「外部委託先の役職員が遵守すべきルールやセキュリティ要件を外部委託先へ提示し、契約書等に明記しているか」を挙げ、システムに係る外部委託業務については「二段階以上の委託を含む」としています。^*1 委託先がさらに別の会社や個人に仕事を頼む場合も、管理の対象に入るということです。

教育と訓練の着眼点もあります。情報セキュリティ管理の項は、全役職員に対するセキュリティ教育を「外部委託先におけるセキュリティ教育を含む」として挙げています。^*1 緊急時への備えでは、コンティンジェンシープラン（緊急時の対応計画）に基づく訓練を共同センター（複数の金融機関が共同で使うシステムの運営拠点）などの外部委託先と合同で定期的に行っているか、障害時にノウハウ・経験を持つ人材を外部委託先などからも速やかに集められるよう事前に登録しているか、を問うています。^*1

銀行法の細かな決まりを定めた銀行法施行規則は、銀行が業務を第三者に委託するとき、その業務を「的確、公正かつ効率的に遂行することができる能力を有する者」に委託するための措置を、委託する業務の内容に応じて講じるよう定めています。^*2 どちらの決まりも、決まりの知識を本人の経験に任せず、銀行がルールを示し、委託先が教育して伝える形で確保するよう組み立てられています。外部エンジニア一人ひとりに求める業界知識の水準は、どちらにも示されていません。

業界知識が問われやすい作業

業務の知識がどこまで要るかは、頼む作業によって変わります。下の表は、金融機関のシステム開発でよく頼む作業ごとに、業務の知識と決まりの知識がどう関わるかを整理した例です。

テストについては、監督指針も、システム開発にあたってテスト計画を作り、業務部門も参加するなど適切かつ十分にテストを行っているかを問うています。^*1 業務部門の人がテストに加わるなら、外部エンジニアに求める業務の知識は、業務部門の説明を理解して確認の手順に直せる程度で足りる場合があります。

決まりの知識は、どの作業を頼む場合でも外せません。監督指針は、洗い出すべき顧客の重要情報の例として、障害解析のためにシステムから出力されたデータや、ATM（現金自動預払機）などに保存されている取引ログを挙げています。障害を調べる作業や基盤の作業でも、顧客の情報に触れることがあるということです。開発担当者と運用担当者の分離（開発する人と本番の運用をする人を分けること）も、不正アクセスや情報漏えいを防ぐ仕組みの例として挙げられています。^*1

どう切り分けるのか

切り分けは、頼む作業を書き出すところから始めます。「勘定系システム（預金や融資の取引を記録する中心のシステム）の改修」のような大まかな呼び方ではなく、「振込の受付時間を変える改修の設計とテストを、3か月で担当」のように、作業の中身と期間まで書きます。ここまで書けていれば、その作業でどの業務の知識が要るのかを具体的に考えられます。

次に、作業ごとに業務の知識を誰が補うかを決めます。外部エンジニア本人に求めるのか、銀行の業務部門やシステム部門の担当者が説明するのか、です。監督指針は、外部委託先任せにならないよう、例えば委託元として要員を配置するなどの措置を講じているかを問うています。^*1 銀行側に業務を説明できる担当者がいれば、外部エンジニアに求める業務の知識の水準を、その分だけ下げられます。

最後に、決まりの知識を契約と教育で伝える段取りを決めます。守るべきルールとセキュリティ要件を契約書などに書き、参画の初日までに説明の場を設けておくと進めやすくなります。面談で確かめるのは「金融業の経験があるか」だけでなく、「示されたルールのもとで作業した経験があるか」「決まりに沿わない指示を受けたとき、誰に確認するか」といった点です。

つまずきやすい点

一つ目は、「金融業の経験あり」だけを条件にすることです。金融業には銀行、保険、証券などがあり、金融庁の監督指針も、主要行等向け、中小・地域金融機関向け、保険会社向け、金融商品取引業者等向けなどに分かれています。^*3 保険会社のシステムでの経験が、銀行の送金の業務にそのまま当てはまるわけではありません。どの種類の金融機関の、どの業務の経験を求めるのかまで書くと、条件がはっきりします。

二つ目は、ルールを契約に書かず、本人の経験に任せることです。社内のルールは金融機関ごとに定めるものなので、前の現場で覚えたやり方をそのまま持ち込むと、その金融機関のルールと食い違うことがあります。金融業の経験が長い人ほど、以前のやり方を当然のものとして進めてしまうこともあるため、初日の説明は経験の有無にかかわらず同じ内容で行います。

三つ目は、再委託先から加わる人に説明が届かないことです。監督指針は、二段階以上の委託では、外部委託先が再委託先に十分な監督を行っているかを確かめ、必要に応じて銀行が直接監督しているかを問うています。^*1 委託先の社員には説明したのに、委託先がさらに仕事を頼んだ会社から来た人は同じ説明を受けていない、という抜けが起こりやすいところです。

外部に頼むときに確認しておきたい点

金融機関のシステム開発に外部エンジニアを加える前に、少なくとも次の点を決めておくと、候補者に求める条件を書きやすくなります。

• 頼む作業と期間、その作業で要る業務の知識の深さ
• 業務の知識を、銀行側の誰が説明して補うか
• 守るべきルールとセキュリティ要件が、契約書などに書かれているか
• 再委託で加わる人にも、同じルールの説明と教育が届くか
• 障害時の連絡の体制と、訓練に加わるかどうか

これらが決まっていれば、募集の条件も「どの業務の経験があるか」「どのようなルールのもとで作業した経験があるか」と具体的に書けます。業界知識の浅い人を迎える場合でも、補う方法が決まっていれば、受け入れるかどうかを判断しやすくなります。業界知識がどの工程で問われやすいかを調査の数値から見た話は「外部エンジニアの業界知識はどこで要るか」で、金融機関のシステムを受託する側が用意しておく資料は「金融のシステム委託で問われること」で扱っています。

まとめ：業界知識で確かめておきたい3つの点

金融機関のシステム開発に外部エンジニアを加えるうえで、確かめておきたい点は3つに整理できます。第一に、頼む作業を中身と期間まで書き出し、作業ごとに要る業務の知識の深さを決めること。第二に、業務の知識を本人に求めるのか、銀行側の担当者が補うのかを決めておくこと。第三に、守るべきルールとセキュリティ要件を契約書などに書き、再委託で加わる人まで同じ説明と教育を届けることです。この3点を踏まえておけば、「金融業の経験者に来てもらったのに、現場のルールと合わずに作業が止まった」という事態を避けやすくなります。業界知識をどこまで求めるかに迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：金融庁「主要行等向けの総合的な監督指針」（https://www.fsa.go.jp/common/law/guide/city/index.html）。出典：金融庁「主要行等向けの総合的な監督指針」。I-2(2)の注（主要行等と中小・地域金融機関の範囲）、III-3-7-1-1 システムリスクの意義、III-3-7-1-2 主な着眼点（(1)システムリスクに対する認識等、(3)システムリスク評価、(4)情報セキュリティ管理、(6)システム企画・開発・運用管理、(8)外部委託管理、(9)コンティンジェンシープラン、(10)障害発生時の対応）、III-3-7-1-3 監督手法・対応（報告すべきシステム障害等）、III-3-3-4-2 外部委託の主な着眼点（二段階以上の委託）を参照（2026年9月確認）
2. *2　参考：e-Gov法令検索「銀行法施行規則」（https://laws.e-gov.go.jp/law/357M50000040010）。出典：銀行法施行規則（昭和57年大蔵省令第10号）第13条の6の8第1項（委託業務の的確な遂行を確保するための措置）を参照（2026年9月確認）
3. *3　参考：金融庁「監督指針一覧」（https://www.fsa.go.jp/common/law/guide.html）。出典：金融庁「監督指針一覧」。業態ごとの総合的な監督指針（主要行等向け、中小・地域金融機関向け、保険会社向け、金融商品取引業者等向けなど）を参照（2026年9月確認）
4. *4　参考：金融庁「中小・地域金融機関向けの総合的な監督指針」（https://www.fsa.go.jp/common/law/guide/chusho/index.html）。出典：金融庁「中小・地域金融機関向けの総合的な監督指針」。II-3-4-1-2 システムリスクの主な着眼点（(4)情報セキュリティ管理、(8)外部委託管理）を参照（2026年9月確認）

Tweet