SAP BTPエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方
公開 2026-10-29 監修：株式会社エージェントベスト
SAP BTPエンジニアのスキルシートは、プロジェクトごとに「何と何を、BTPのどのサービスでつないだか、または何を拡張したか」を1行で示し、そのうえで担当の深さを「設計した」「実装した」「運用した」などの動詞で書き分けるのが基本です。「SAP BTP開発担当」とだけ書くと、読み手は連携の人なのか、アプリの人なのか、設計から任せてよいのかを判断できません。
BTPの経験を領域と工程で棚卸しする方法はSAP BTPエンジニアがフリーランスになるには、分野ごとのスキルの中身はSAP BTPエンジニアのスキルの記事で扱っています。この記事では、棚卸しした経験をシートの上でどう見せるかに絞って解説します。
プロジェクト欄の冒頭に「構成」を1行で書く
BTPのプロジェクトは、つなぐ先と使うサービスの組み合わせで難しさが変わります。読み手は担当内容を読む前に、全体の構成を知りたいと考えています。プロジェクトの最初に、次の要素を1行にまとめておくと読みやすくなります。
| 要素 | 書き方の例 | 読み手が判断すること |
|---|---|---|
| つなぐ先・拡張する先 | S/4HANA（クラウド版／オンプレミス版）、旧来のSAP ERP、他社のSaaS | どのシステムのデータを扱えるか |
| 使った領域 | 拡張開発、連携、ローコード・自動化、AI | どの分野を任せられるか |
| 主なサービス・技術 | CAP（Node.js）、Fiori elements、Cloud Integration、API Management | 案件の技術と合うか |
| 実行の環境 | Cloud Foundry、Kyma など | 環境の構成に慣れているか |
| プロジェクトの種類 | 新規の拡張、連携基盤の移行、保守・改善 | どの局面で力を出せるか |
例（架空）：「S/4HANA（オンプレミス版）と他社の販売管理SaaSを連携／Integration Suite（Cloud Integration・API Management）／新規の連携構築」
社名や製品の型番、具体的な件数までは書かなくてかまいません。どこまで書いてよいかはスキルシートと守秘義務の記事をご覧ください。
サービス名は「何のために使ったか」と組で書く
BTPには多くのサービスがあり、名前を並べるだけのシートになりがちです。名前が多くても、何を実現したのかが伝わらなければ、読み手には触ったことがある程度にしか映りません。サービス名を書くときは、目的と組にします。
- 書き換え前：Cloud Integration、API Management、Event Mesh
- 書き換え後：受注データの連携をCloud Integrationで構築。外部の販売サイト向けのAPIをAPI Managementで公開し、利用の制限と監視を設定
BTPのサービスは名前が変わることがあります。古い名前で経験した場合は、当時の名前のまま書き、今の名前を括弧で添えておくと、読み手が混乱しません。
担当の深さは動詞で書き分ける
同じ連携やアプリでも、関わり方には深さの違いがあります。次のような動詞を決めて使い分けると、面談での説明と食い違いません。
| 動詞 | 意味 | 読み手の受け取り方 |
|---|---|---|
| 方式を決めた | 拡張の置き場所や連携方式を選び、理由を説明した | 全体の判断を任せられる |
| 設計した | データのモデル、APIの形、エラー処理を決めた | 設計から任せられる |
| 実装した | 設計に沿って作り、単体のテストをした | 手を動かして作れる |
| 移行した | 旧環境の連携やアプリを新しい環境に作り直した | 移行の案件に入れる |
| 運用した | 監視、エラーの再処理、問い合わせに対応した | 本番を任せられる |
| レビューした | 他の担当者の設計や実装を確かめた | リードを任せられる |
一つの行に「設計」「実装」「運用」が入っていると、本番まで担った人として伝わります。
記入例（架空）
次は、書き方の型を示すための例です。業種と規模はぼかしてあり、実在のプロジェクトではありません。
期間：20XX年4月〜翌年3月（1年）
構成：S/4HANA（クラウド版）の拡張／CAP（Node.js）・Fiori elements／Cloud Foundry／新規の拡張開発
業種・概要：卸売業（中堅規模）の受注の例外処理を扱う業務アプリの開発
立場：開発チーム4名のうち、バックエンドの設計担当
担当工程：設計、実装、テスト、本番稼働の支援
担当内容：CDSでデータのモデルを設計し、S/4HANAの標準のAPIから受注データを取得するサービスを実装。承認の画面はFiori elementsの標準の型で作り、作り込みは一覧の絞り込みだけにとどめた
工夫・成果：画面の作り込みを減らし、保守の担当が設定の変更だけで項目を追加できる形にした。稼働後は、APIの呼び出しの失敗を検知して担当者に知らせる仕組みを追加
期間：20XX年10月〜翌年9月（1年）
構成：旧来のSAP ERPと社外の物流システムの連携／旧来の連携基盤からIntegration Suiteへの移行
立場：連携チーム3名のリーダー
担当工程：移行の計画、方式の見直し、実装、切り替え
担当内容：既存の連携を一覧にし、そのまま移すもの、作り直すもの、廃止するものに分類。作り直す連携では、エラー時の再処理の手順を新たに設計した
工夫・成果：使われていない連携を洗い出して移行の対象を減らした。切り替えの手順を連携ごとに分け、業務を止めずに段階的に移した
実際に書くときは、ご自身の経験に置き換えてください。
連携の実績は「つなぎ方」で書く
連携の経験は、本数を書くだけでは中身が伝わりません。数を書く場合も、方式とエラー処理を添えます。
- つないだ相手と方向（S/4HANAから物流システムへ、外部のSaaSからS/4HANAへ など）
- 方式（APIで同期、ファイルで定時、イベントで通知）
- データの変換の難しさ（コードの読み替え、複数のデータの組み合わせ）
- エラー時の扱い（再処理の方法、誰が気づくか）
統合テストや本番で連携の不具合の原因を切り分けた経験があれば、「どちらの側の、何が原因だったか」まで一言添えると、運用まで任せられる人として伝わります。S/4HANAへの移行の中で連携を担った場合は、S/4HANA移行のスキルシートの記事の書き方も参考になります。
ローコード・AIの経験の書き方
SAP Buildでのアプリや自動化、AIの組み込みの経験は、作ったものの名前より、次の点を書くと伝わります。
- 誰が使うものか：利用部門の人数の規模、使う場面
- 誰が作り、誰が保守するか：自分が作ったのか、利用部門が作るのを支えたのか
- データと権限のルール：どのデータに触れてよいか、誰が承認するかを決めたか
- AIの結果の扱い：AIの出力を誰が確かめ、業務のどこで使うか
検証の段階で終わった経験も、何を確かめ、なぜ本番に進まなかったのかを書けば、判断の経験として読まれます。
よくある質問
検証やPoCの経験しかありません。どう書けばよいですか？
検証の経験も一つのプロジェクトとして書けます。何を確かめるための検証だったか、どんな結果が出て、本番に進んだか進まなかったか、その理由まで書くと、判断の経験として伝わります。本番の経験と区別できるよう、プロジェクトの種類の欄に「検証」と明記しておきましょう。
ABAPとBTPの両方の経験があります。どう書き分けますか？
プロジェクトごとの構成の行に、S/4HANAの中で作ったのか、BTPの上で作ったのかを書けば、読み手は区別できます。両方を組み合わせた案件では、どちらに何を置いたかと、その理由を担当内容に書くと、設計の判断の経験として伝わります。
SAPの認定資格はどこに書けばよいですか？
資格欄に、正式な名称と取得した年月を書きます。SAPの認定は名称が改定されることがあるため、取得時の名称のまま書いてかまいません。案件では実務の経験が先に見られるため、資格はプロジェクト欄の内容とあわせて読まれることが多くなります。