クレジットカード・決済業界の経験をスキルシートで伝える書き方｜立場・処理・カード情報との距離

カード・決済業界の経験をスキルシートで伝えるときは、発注元の立場、担当した処理、取引の種類、カード情報との距離の4点をそろえて書くのが基本です。「決済システムの開発」だけでは、カード会社の基幹系なのか、ECサイト向けの決済画面なのかが分かりません。「決済代行業者の、EC加盟店向け決済APIで、EMV 3-Dセキュアの組み込みを担当」まで書くと、合う案件がすぐに見えます。

同時に、カード・決済の経歴は、不正対策やセキュリティの仕組みに触れやすい分野です。書き方によっては、発注元の守りの手の内を明かすことになりかねません。この記事では、4点のそろえ方、書かない情報の線引き、記入例を紹介します。スキルシート全体の構成はスキルシートの基本、守秘義務の一般的な考え方はスキルシートに書いてよいこと・いけないことで扱っているので、ここではカード・決済の経験に固有の書き方に絞ります。

要約の1行目で「立場」と「処理」を示す

カード・決済の案件は、発注元の立場で扱うシステムが大きく違います。冒頭の要約では、どの立場の事業者の、どの処理を軸にしてきたかを1行で示します。立場の分け方はカード・決済のIT案件の記事で説明しています。

• 軸の立場と処理（例：カード発行会社の承認・請求系の保守と更改）
• 立場と工程（例：基本設計から総合テストまで、後半はチームリーダー）
• ほかに対応できる領域（例：決済代行業者のAPI開発、不正検知の改善の経験あり）

立場を表す言葉は、イシュアー、アクワイアラー、決済代行業者、コード決済事業者など、日本クレジット協会やガイドラインでも使われる一般的な言葉にそろえると、読み手との認識がずれにくくなります。

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

処理の欄は、承認・売上・加盟店への支払い・会員への請求のどこに関わったかを入口にすると書きやすくなります。各処理の押さえどころはカード・決済の業務知識の記事で整理しています。

「カード情報との距離」は経験の価値になる

カード情報を扱う環境での作業は、権限の管理や作業の記録、場所の制限に従った経験があることを示します。反対に、トークンに置き換えた後の情報だけを扱う設計に関わった経験は、カード情報を自社の環境に通さない作りを知っていることを示します。どちらも、発注側が案件の条件と照らし合わせるうえで役立つ情報です。

書き方は「カード情報を扱う環境での開発・運用（作業場所・端末の指定あり）」「カード情報を通さない非通過型の決済画面の組み込み」程度で十分です。どのサーバーが範囲に入っていたか、どう区切っていたかは書きません。

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

カード・決済の案件では、例外の扱いを確かめる作業の比重が大きくなります。承認の後の取消し、売上の訂正、返品、二重の送信への対応などのテストや、社外の相手と行う接続テストは、書き忘れやすいのに評価されやすい経験です。

• 承認・取消し・売上訂正の組み合わせを洗い出し、テストケースに落とし込んだ
• 国際ブランドや外部の接続先とのテストの日程と手順を調整した
• 新旧のシステムで請求金額を突き合わせ、差の原因を分類した

カード・決済の経歴で書かない情報

カード・決済の分野では、守りの仕組みを具体的に書くこと自体が、発注元の弱点を示すことになりかねない点に気をつけます。

特に、不正検知の条件や環境の構成は、具体的に書くほど悪用されやすい情報です。どんな対策に関わったかは「不正利用対策の改善」程度にとどめ、詳しくは面談で、話してよい範囲で口頭で説明します。

もう一つ、カード番号そのものの扱いには法律の定めがあります。割賦販売法第49条の2は、カード番号を取り扱う事業者やその委託を受けた事業者の役員・職員などが、業務で知ったカード番号を不正な利益を図る目的で提供したり盗用したりする行為に罰則を定めています。スキルシートに番号を書くことはそもそもありませんが、業務で見た情報をどこにも残さない意識は持っておきます。守るルールの全体はカード・決済の規制の記事で扱っています。

基準になるのは、契約で秘密とされた範囲を書かないことです。業務委託契約や秘密保持契約で経歴への記載について定めがある場合は、その定めに従ってください。

プロジェクト欄の記入例

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

例1：カード発行会社の承認系の更改

期間：20XX年〜20XX年（1年6か月）
案件概要：大手のカード発行会社の承認（オーソリ）系システムの基盤更改
規模・立場：大規模な更改プロジェクトのうち、承認処理のチーム7名（自分は設計とテストの担当、後半はサブリーダー）
対象の処理・取引：承認と取消し、対面（IC取引）とECの両方
カード情報との距離：カード情報を扱う環境での開発（作業場所・端末の指定あり）
担当した工程：現行調査、基本設計、結合テスト、外部接続先とのテストの調整
使用技術：Java、COBOL（現行の読解）、SQL
工夫・成果：承認・取消し・再送の組み合わせを表にまとめ、テストケースの漏れを減らした

例2：決済代行業者のEC向け決済画面

期間：20XX年〜20XX年（10か月）
案件概要：EC向けの決済代行業者の決済画面と決済APIの機能追加
規模・立場：開発チーム5名（自分はフロントエンドとAPIの担当）
対象の処理・取引：EC取引の承認と売上、EMV 3-Dセキュアによる本人認証の組み込み
カード情報との距離：カード情報を加盟店側に通さない非通過型の画面の開発
担当した工程：詳細設計、実装、結合テスト
使用技術：TypeScript、Go、REST API、クラウド
工夫・成果：本人認証の追加の確認が出た場合と出ない場合の画面の流れを整理し、離脱しにくい表示に見直した

どちらの例も、社名、件数、環境の構成、不正検知の条件は書いていません。それでも、立場、処理、取引の種類、カード情報との距離が書かれていれば、どの案件に合うかは伝わります。

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

面談全般の準備は面談でよく聞かれる質問の記事で扱っています。カード・決済の案件で聞かれやすいのは、次のような点です。

1. 承認の後の取消し、売上の訂正、二重の送信など、例外の処理にどう対応したか
2. 社外の接続先や国際ブランドの仕様変更に、どう合わせたか
3. カード情報を扱う環境で、権限や作業の記録の決まりにどう従って進めたか
4. 障害が起きたとき、どの順で誰に伝え、どう切り分けたか

3つ目と4つ目は、技術よりも働き方の確認です。決められた手順の中で作業した経験は、カード・決済の案件では大事な安心材料になります。

よくある質問

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

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

不正対策の経験は、どこまで具体的に書いてよいですか？

関わった対策の種類（不正検知の改善、本人認証の導入、不正ログイン対策など）と、自分の役割までにとどめます。判定の条件やしきい値、検知の仕組みの細部は書きません。成果を示したい場合も、「誤検知の見直しに取り組んだ」のような表現にして、数値の詳細は面談で話してよい範囲を確かめてから伝えます。

ECサイト側で決済を組み込んだ経験も、カード・決済の経験として書けますか？

書けます。その場合の立場は「EC加盟店」で、決済代行業者の仕組みをどう組み込んだか、カード情報を通さない作りにしたかなどが伝える中心になります。EC事業者側の経験の書き方はEC・通販業界のスキルシートの記事も参考になります。