SAP ABAPエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方
公開 2026-10-29 監修：株式会社エージェントベスト
SAP ABAPエンジニアのスキルシートは、扱ってきたSAPの版と環境、開発の種類ごとの本数、自分で担った工程を一覧で示し、移行の対応や性能の改善は「何を減らし、何を短くしたか」という結果で書くのが基本です。ABAPの経歴は「アドオン開発」の一言でまとめられがちですが、それでは読み手は、自分の案件の開発を任せられるかを判断できません。
経験の棚卸しの仕方はSAP ABAPエンジニアがフリーランスになるには、分野ごとに求められる技術はABAPのスキルの記事で扱っています。この記事では、それをシートの上でどう見せるかを解説します。スキルシート全般の考え方はスキルシートの基本にまとめています。
先頭に置く3つの一覧
読み手が最初に確かめるのは、案件の環境と開発の種類に合う経験があるかです。プロジェクト欄を全部読まなくても分かるように、先頭に3つの一覧を置きます。
版と環境の一覧
記入例（架空）：
| SAPの版 | 環境 | 主な領域 | 経験 |
|---|---|---|---|
| S/4HANA | プライベートクラウド | 会計・販売 | 導入の開発、移行のコード対応（2年） |
| ECC | 自社のデータセンター | 販売・購買 | 保守・改修（4年） |
| ECC | 自社のデータセンター | 生産 | 導入の開発（1年） |
旧環境とS/4HANAの両方の経験があるかは、移行の案件で特に見られます。版が分かる場合は、版の名前まで書いておくと、読み手が新しい開発の形を使える環境だったかを判断できます。
開発の種類ごとの本数
記入例（架空）：
| 開発の種類 | 本数の目安 | 担った工程 |
|---|---|---|
| レポート | 30本程度 | 詳細設計〜単体テスト |
| インターフェース | 15本程度 | 基本設計〜結合テスト |
| 拡張 | 20本程度 | 詳細設計〜単体テスト |
| 帳票 | 10本程度 | 製造〜単体テスト |
| データ変換 | 5本程度 | 詳細設計〜移行リハーサル |
| CDS・RAP | 3本程度 | 詳細設計〜単体テスト |
本数は正確でなくてかまいませんが、「程度」と書くなど、目安であることが分かるようにします。種類ごとに工程を書き分けると、得意な領域と、任せられる範囲が一目で伝わります。
開発の技術の一覧
言語の機能や開発の技術は、実務で使ったものと、学習中のものを分けて書きます。
- 実務で使用：オブジェクト指向での開発、拡張の仕組み、データベース側での集計、ATCでのチェック
- 実務で一部使用：CDSビュー、RAPの業務オブジェクト、ADTでの開発
- 学習中：ABAP Cloudに沿った開発（学習用の環境で演習）
新しい開発の形は、経験の深さの差が大きい分野です。実務と学習を混ぜて書くと、参画後に任される内容と合わなくなるおそれがあります。
プロジェクト欄は「作るか作らないか」の判断を書く
ABAPのプロジェクト欄は、作ったものの一覧になりがちです。読み手が知りたいのは、本数よりも、どの段階から関わり、何を自分で決めたかです。次の項目を入れると伝わりやすくなります。
| 項目 | 書き方の例 | 読み手が判断すること |
|---|---|---|
| 立場 | 開発チーム5名のうち、販売領域の担当 | チームの中での位置 |
| 受け取った物 | 機能の仕様書 | どの工程から担えるか |
| 自分で決めたこと | 標準の機能で済む部分を切り分け、アドオンの範囲を提案 | 設計を任せられるか |
| 工夫・成果 | 処理の遅いバッチを見直し、処理時間を短縮 | 性能や品質への配慮 |
| 他の人との関わり | 業務コンサルとの仕様の確認、オフショアへの仕様の説明 | 調整を任せられるか |
拡張は「標準を書き換えずに済ませたか」が分かるように書く
拡張の開発は、使った仕組みの種類に加えて、標準のプログラムを書き換えずに要件を満たしたかが分かるように書くと伝わります。やむを得ず標準に手を入れた経験がある場合は、その理由と、更新のときにどう扱ったかを添えます。SAPが拡張の作り方を、標準を守る方向へ寄せていることもあり、この点は新規の導入でも移行でも見られやすくなっています。
移行の対応は「減らした結果」で書く
S/4HANA移行のカスタムコード対応は、直した本数だけを書くと、作業の量しか伝わりません。次の順に書くと、判断の中身が伝わります。
- 対象の規模：調査したアドオンの数と、チェックの指摘の数
- 絞り込み：使われていないものとして廃止した数、自動の修正で片づけた数
- 手で直した数と内容：考え方を変えて直す必要があったものの数と、主な種類
- 確かめ方：業務のシナリオでの動作確認、照合の方法
移行プロジェクトの経験の見せ方全体はS/4HANA移行のスキルシートの記事で解説しています。ここでは、ABAPの担当として、プログラムの側から何を減らしたかを書くことが大切です。
性能の改善は「前と後」で書く
処理の遅いバッチやレポートを直した経験は、ABAPのスキルシートで伝えやすい成果の一つです。ただ「性能を改善」とだけ書くと、どの程度の問題を、どう直したかが伝わりません。次の3点をそろえて書きます。
- 問題の状態：夜間のバッチが翌朝の業務の開始に間に合わないことがあった、など業務への影響
- 原因と直し方：データの読み方を見直し、集計をデータベースの側で行うようにした、など
- 結果：処理時間がどう変わったか。割合や目安で書いてもかまいません
数字は、元の処理時間と改善後の処理時間の比で書くと、発注元の固有の情報に触れずに伝えられます。性能の改善は、HANAを前提にした書き方を理解していることの裏付けにもなります。
記入例（架空）
次は、書き方の型を示すための例です。業種と規模はぼかしてあり、実在のプロジェクトではありません。
期間：20XX年4月〜翌年9月（1年6か月）
環境：ECC（自社のデータセンター）からS/4HANA（プライベートクラウド）へ
業種・概要：製造業（中堅規模）の基幹システムの移行
立場：開発チーム6名のうち、移行のコード対応のサブリーダー
担当工程：アドオンの調査、指摘への対応の方針づくり、修正、単体テスト、結合テストの支援
担当内容：利用状況のデータをもとに、使われていないアドオンの廃止の候補を一覧にし、業務部門の確認を経て廃止。残すものはチェックの指摘を種類ごとに分け、自動の修正、手での修正、業務の確認が要るものに振り分けて工数を見積もった。一部の帳票の抽出処理をCDSビューで作り直した
工夫・成果：調査の対象のうち、廃止と自動の修正で全体の半分程度を片づけ、手での修正の対象を絞った。指摘の種類ごとの直し方の手引きを作り、チームの修正の仕方をそろえた
実際に書くときは、ご自身の経験に置き換えてください。数字は、発注元に確かめずに外へ出せる範囲にとどめます。
要約と資格の書き方
要約は「得意な工程」と「得意な領域」で書く
要約の欄は、3〜5行で、自分がどこで力を出せるかを書く場所です。ABAPの場合は、得意な工程、得意な業務の領域、得意な開発の種類を入れると、読み手は案件と結び付けやすくなります。
例（架空）：
- SAPのアドオン開発に7年従事。直近2年はS/4HANA移行のカスタムコード対応のサブリーダー
- 販売・購買の領域のインターフェースと拡張の詳細設計が得意
- CDSビューとRAPでの開発を実務で一部経験
資格は名前と取得時期を書く
SAPの認定資格を持っている場合は、正式な名前と取得の時期を書きます。認定には維持の手続きがあるものもあるため、最新の状態かどうかも確かめておきます。書き方はSAP認定コンサルタントの記事で解説しています。
よくある質問
保守の経験はどう書けばよいですか？
不具合の調査と改修の件数に加えて、原因を突き止めた例を種類で書くと伝わります。たとえば、処理の遅さ、データの不整合、連携のエラーなど、どの種類の問題を自分で切り分けたかを書きます。
開発の本数が少ないと不利になりますか？
本数だけで決まるわけではありません。少ない本数でも、基本設計から担った、性能の改善で成果を出した、といった中身があれば評価されます。工程と、自分で決めたことを具体的に書きましょう。
学習中の技術は書かないほうがよいですか？
書いてかまいません。ただし、実務の経験とは分けて「学習中」と明記します。どの環境で、どこまで作ったかを添えると、面談で話を広げやすくなります。