COBOLエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方
公開 2026-10-29 監修：株式会社エージェントベスト
COBOLエンジニアのスキルシートは、実行環境（メインフレームかオープン系か、どの系統か）、バッチかオンラインか、対象の業務、担当した工程の4つをプロジェクトごとにそろえて書き、長い保守の経歴は、制度対応や更改などの単位で区切って書くのが基本です。読み手は「この人を、どの環境の、どの工程に入れられるか」を短い時間で判断しようとします。
案件で問われるスキルの中身はCOBOLの案件で求められるスキル、独立までの準備はCOBOLエンジニアがフリーランスになるにはで扱っています。この記事では、それをシートの上でどう見せるかに絞って解説します。
スキル一覧は「環境」と「使い方」をセットで書く
COBOLのスキル一覧で「COBOL 20年」とだけ書くと、どの環境で、何をしてきたのかが伝わりません。言語に加えて、環境、ジョブ、オンライン、データの行を分け、使い方を括弧で添えます。
記入例（架空）：
| 区分 | 書き方 |
|---|---|
| 言語 | COBOL（メインフレーム15年・オープン系3年。バッチとオンラインの両方）、JCL（15年）、シェル（3年） |
| 実行環境 | メインフレーム（○○系のOS。保守と更改）、Linux（オープン系COBOLの実行環境） |
| オンライン | トランザクションモニター上のオンラインの改修（5年） |
| データ | 順編成・索引編成のファイル、階層型DB（保守）、リレーショナルDB（SQLの作成と調整） |
| ツール | ジョブ管理ツール、ソースの差分比較、ファイルの比較ツール |
| 移行先の技術 | Java（リライト後のコードのレビュー、1年）、Linux（リホストの検証） |
メインフレームの系統は、製品名で書くと読み手が環境を判断しやすくなります。社内の呼び名や略称は、社外の読み手には伝わらないため、一般的な名前に置き換えます。
バッチとオンラインは分けて書く
COBOLの案件では、バッチとオンラインのどちらの経験があるかが条件になることがあります。両方の経験がある人は、スキル一覧とプロジェクト欄の両方で分けて書くと、条件との突き合わせがしやすくなります。
長い保守の経歴は区切って書く
COBOLの経歴で多いのが、同じシステムの保守を10年以上続けてきたという形です。これを一つの期間にまとめて「保守・運用を担当」と書くと、その間に何を担ってきたかが伝わりません。
- 区切りの単位：大きな制度対応、システムの更改、機能の追加、移行など、まとまった仕事ごとに区切る
- 各区切りに書くこと：期間、対象の業務、担当工程、役割、自分が判断したこと
- 日常の保守：小さな改修や障害対応は、まとめて「日常の保守」として、件数ではなく担った範囲で書く
区切って書くと、同じ現場の中で、製造から影響調査、リードへと役割が広がってきたことが伝わります。
工程と役割は表記をそろえる
工程の名前はシート全体で一つに決め、プロジェクトごとに担当した工程に印をつけます。COBOLの案件では影響調査が重く見られるため、工程の列に入れておくと、経験が一目で伝わります。
| 影響調査 | 基本設計 | 詳細設計 | 製造 | 単体テスト | 結合テスト | 総合テスト | 移行・リリース |
|---|---|---|---|---|---|---|---|
| ◯ | ◯ | ◯ | ◯ | ◯ | ◯ | ◯ |
規模は、プロジェクト全体のおおまかな人数と、自分のチームの人数、自分の立場（メンバー、サブリーダー、リーダー）を分けて書きます。全体の人数だけを書くと、その全体をまとめていたように読めてしまいます。
移行の経験は「方式」と「担当範囲」を書く
移行の経験は、COBOLのシートで評価されやすい部分です。ただ「マイグレーションを担当」とだけ書くと、どの段階のどの作業を担ったかが分かりません。次の点を書きます。
- 移行の方式：リホスト（基盤の載せ替え）、リライト（言語の書き換え）、リビルド（作り直し）など
- 移行元と移行先：メインフレームからLinux、COBOLからJavaなど
- 自分の担当範囲：現行分析、変換ツールの結果の確認、データの移行、現新比較のテスト、切り替えの作業など
- 判断したこと：差分の原因の切り分け、変換できない部分の対応方針など
移行先の側の作業を担っていない場合も、「現行の側から仕様を提供した」「現新比較の差分を現行の側から調べた」と書けば、移行での役割として伝わります。
担当内容には判断したことを書く
「〇〇機能の改修を担当」だけでは、どの深さで関わったかが伝わりません。自分が判断したことを一言添えます。
| 書き換え前 | 書き換え後（架空） |
|---|---|
| 制度対応の改修を担当 | 制度変更で項目の桁数が増える影響を調査。共通のレコード定義を使うプログラムとジョブを洗い出し、改修の要否を一覧にした |
| 障害対応を担当 | 夜間バッチの異常終了について、ログとダンプから数値項目の桁あふれを特定し、暫定の再実行手順と恒久の対策を作成した |
| 移行テストを担当 | 移行前後の出力ファイルを比較する手順を作り、差分を文字コードの変換と端数処理の違いに切り分けた |
| 設計書の整備を担当 | 設計書が残っていない計算処理をソースから読み解き、仕様を文書に起こした |
数字で書ける成果は書いてかまいませんが、取引の件数や利用者の数など、発注元の事業に関わる数字は書かないでください。書いてよい範囲はスキルシートと守秘義務の記事で扱っています。
記入例（架空）
次は、書き方の型を示すための例です。業種と規模はぼかしてあり、実在のプロジェクトではありません。
期間：20XX年4月〜翌々年3月（2年）
案件概要：金融機関向け 基幹系バッチのリホスト（メインフレームからLinux基盤への移行）
規模・立場：プロジェクト全体は数十名規模。自分は現行チーム4名のサブリーダー
担当工程：影響調査、現行分析、結合テスト、移行・リリース
使用技術：COBOL（メインフレーム・オープン系）、JCL、シェル、ジョブ管理ツール、リレーショナルDB
担当内容：現行のジョブの流れとファイルの入出力を調査し、移行先のジョブ定義との対応表を作成。現新比較のテストの手順を作成し、差分の原因を調査
工夫・成果：差分の原因を、文字コードの変換、並べ替えの順序の違い、数値の形式の違いに分類し、移行先のチームと対応方針を決めた
期間：20XX年4月〜20XX年3月（8年）
案件概要：保険業向け 契約管理システムの保守
規模・立場：保守チーム8名のメンバーからリーダー
担当工程：影響調査、基本設計、詳細設計、製造、テスト
使用技術：COBOL（メインフレーム）、JCL、オンラインのトランザクションモニター、階層型DB
担当内容：商品改定と制度対応の改修（年に数回）。後半は影響調査とレビュー、作業の割り振りを担当
工夫・成果：影響調査の観点を一覧にまとめ、チームの調査の手順をそろえた
実際に書くときは、ご自身の経験に置き換えてください。業界ごとの書き方は、銀行業界のスキルシート、保険業界のスキルシート、公共・官公庁のスキルシートも参考になります。
古い経歴のまとめ方
経歴が20年、30年と長い方は、すべてを同じ分量で書くと、直近の経験が埋もれます。
- 直近の10年前後：上の記入例の形でくわしく書く
- それより前：期間、業種、環境、立場を1〜2行にまとめる
- 移行や更改：古い経歴の中でも、移行や更改に関わったものは残す
要約の欄では、応募する案件に合わせて、どの経験を上に置くかを入れ替えます。保守の案件なら業務と環境の経験を、移行の案件なら移行の方式と担当範囲を先に書くと伝わります。
よくある質問
同じシステムの保守しか経験がありません。どう書けばよいですか？
保守の経験も、区切り方と書き方で伝わり方が変わります。大きな制度対応や機能追加ごとに区切り、それぞれで担った工程と判断したことを書きましょう。影響調査、障害の原因の特定、設計書の整備など、保守の中で担った役割を具体的に書くと、別の現場でも生かせる経験として読まれます。
メインフレームの製品名を書いてもよいですか？
使っていた環境の製品名や系統は、書いてかまいません。読み手が環境の近さを判断する材料になります。ただし、発注元の社名やシステムの固有の名前、構成の詳細など、特定につながる情報は書かないでください。迷う場合は、業種と規模をぼかして書く形にしておきましょう。
ステップ数や本数は書いたほうがよいですか？
改修したプログラムの本数やステップ数は、作業の規模を伝える材料になります。書く場合は、おおまかな規模にとどめ、自分が担った範囲の数字であることが分かるようにします。数字よりも、その中で何を判断したかのほうが面談では深く聞かれるため、担当内容とあわせて書きましょう。