銀行業界の経験をスキルシートで伝える書き方｜層・業務・工程をそろえる

銀行業界の経験をスキルシートで伝えるときは、業態と規模、システムの層、対象の業務、担当した工程の4点をそろえて書くのが基本です。「銀行の勘定系システム開発」だけでは、発注側はどの案件に合うかを判断できません。「地方銀行の勘定系、預金の利息計算まわり、移行の検証を担当」まで書くと、経験の中身が伝わります。

同時に、銀行の経歴は少し書きすぎるだけで発注元が推測されやすい分野です。この記事では、4点のそろえ方、書かない情報の線引き、記入例を紹介します。スキルシート全体の構成はスキルシートの基本、守秘義務の一般的な考え方はスキルシートに書いてよいこと・いけないことで扱っているので、ここでは銀行の経験に固有の書き方に絞ります。

要約の1行目で「層」と「業務」を示す

スキルシートの冒頭の要約では、銀行の経験の軸を1行で示します。銀行の案件はシステムの層ごとに求められる経験が大きく違うため、層と業務を先に書くと、読み手がすぐに案件と照らし合わせられます。層の分け方は銀行のIT案件の記事で説明しています。

• 軸の層と業務（例：銀行の勘定系、預金と為替の保守・法制度対応）
• 立場と工程（例：基本設計から総合テストまで、後半は小規模チームのリーダー）
• ほかに対応できる層や技術（例：情報系へのデータ連携の設計、Javaでの開発経験あり）

複数の層を経験している場合は、年数の長い順ではなく、次に入りたい案件に近い順に並べると、読み手が判断しやすくなります。

プロジェクト欄は4点をそろえる

プロジェクトごとの欄では、使用技術に加えて次の4点を書きます。

業務の欄は、銀行法第10条第1項の3業務（預金・融資・為替）のどれに関わったかを入口にすると書きやすくなります。そのうえで「融資の中の返済予定の計算」のように、業務の単位を一段細かくすると、深さが伝わります。業務ごとの押さえどころは銀行の業務知識の記事で整理しています。

規模は「人数・期間・自分の範囲」で示す

銀行の大規模案件は、関わる人数が多く、自分の担当が全体のごく一部ということもよくあります。全体の規模だけを書くと、自分の範囲が分かりにくくなります。

• 全体の体制の目安（例：複数のベンダーが関わる大規模な更改）
• 自分のチームの人数と、自分の立場（例：6名のチームで、預金の移行検証を担当）
• 担当した範囲（例：普通預金と定期預金の利息計算の新旧比較）

予算や契約金額、口座数や取引件数の実数は書きません。規模は人数と期間、相対的な表現で十分に伝わります。

工程は「確かめた作業」も書く

銀行の案件は、作る作業より確かめる作業の比重が大きくなりがちです。現行調査、新旧比較、移行のリハーサル、受入テストの支援などは、書き忘れやすいのに評価されやすい経験です。「製造」「テスト」とまとめず、何をどう確かめたかを書きます。

• 現行のCOBOLの資産を読み、利息計算の仕様を設計書に起こした
• 新旧のシステムで同じデータを処理し、結果の差を分類して原因を調べた
• 本番切替のリハーサルで、手順書の作成と時間の計測を担当した

銀行の経歴で書かない情報

銀行の案件は、銀行の数が限られているうえ、大きな更改は報道や公表資料で知られていることがあります。そのため、一つひとつは問題なくても、組み合わせると発注元が特定できることに気をつけます。

特に、セキュリティの対策や不正の検知の方式は、書くこと自体が発注元の守りの弱点を示すことになりかねません。どんな対策に関わったかは「不正対策の要件に沿った改修」程度にとどめ、詳しくは面談で、話してよい範囲で口頭で説明します。

契約で秘密とされた範囲を書かないことが基準になります。参画した案件の業務委託契約や秘密保持契約で、経歴への記載について定めがある場合は、その定めに従ってください。不正競争防止法の営業秘密の考え方はスキルシートと守秘義務の記事で扱っています。銀行の案件で守るルールそのものは銀行の規制の記事をご覧ください。

プロジェクト欄の記入例

以下は書き方を示すための例で、実在の案件や実績ではありません。

例1：勘定系の更改（移行の検証）

期間：20XX年〜20XX年（1年9か月）
案件概要：地方銀行の勘定系システムの更改（メインフレームからオープン系の基盤への移行）
規模・立場：大規模な更改プロジェクトのうち、預金の移行チーム6名（自分は検証の担当、後半はサブリーダー）
対象の業務：普通預金・定期預金の残高と利息計算
担当した工程：現行調査、移行データの検証、新旧比較、本番切替のリハーサル
使用技術：COBOL（現行の読解）、Java、SQL
工夫・成果：新旧比較の差を「仕様の差」「移行の誤り」「現行の不具合」に分類する表を作り、業務部門との確認の手戻りを減らした

例2：インターネットバンキングの機能追加

期間：20XX年〜20XX年（1年）
案件概要：大手銀行の個人向けインターネットバンキングの機能追加
規模・立場：開発チーム8名（自分は振込機能の設計と実装の担当）
対象の業務：振込の受付と予約、振込先の登録
担当した工程：基本設計、詳細設計、実装、結合テスト
使用技術：Java、TypeScript、REST API
工夫・成果：振込の「受付」と「実行」の状態の違いを画面の表示に反映し、利用者からの問い合わせにつながりやすい表示を見直した

どちらの例も、銀行名、時期の詳細、件数、セキュリティの方式は書いていません。それでも、層、業務、工程、工夫が書かれていれば、どの案件に合うかは読み手に伝わります。

面談で深掘りされやすい点

スキルシートで書いた内容は、面談で深掘りされます。銀行の案件で聞かれやすいのは、次のような点です。面談全般の準備は面談でよく聞かれる質問の記事で扱っています。

1. 担当した業務で、例外の扱い（訂正、取消し、締め後の修正）にどう対応したか
2. テストや移行で、どんな差や不具合を見つけ、どう原因を切り分けたか
3. 業務部門や他のベンダーと、何をどう決めたか
4. 作業場所や端末の制限、承認の手順の多い環境で、どう進めたか

4つ目は見落とされがちですが、銀行の案件では大事な問いです。決められた手順の中で作業を進めた経験は、そのまま次の案件での安心材料になります。

よくある質問

銀行名を書かないと、経験の大きさが伝わらないのではありませんか？

業態と規模、自分のチームの人数と範囲、担当した工程を書けば、経験の大きさは十分に伝わります。発注側が知りたいのは銀行名より、どの層のどの業務を、どの立場で担ったかです。銀行名は契約で秘密とされていることが多いため、書かないのが基本です。

保守の経験しかありませんが、どう書けばよいですか？

保守の案件でも、制度の変更や商品の追加に合わせて、影響する箇所を調べて直した経験は評価されます。どの業務の、どんな変更に対して、影響の調査から改修、テストまでのどこを担ったかを書きます。業務の押さえどころは銀行の業務知識の記事が参考になります。

複数の銀行の案件を経験しています。まとめて書いてもよいですか？

業態と層が同じなら、似た案件をまとめて書くと読みやすくなることがあります。ただ、更改と保守、勘定系とチャネル系のように中身が違うものは分けて書くほうが、どの案件に合うかが伝わります。