SAP Basisエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

SAP Basisエンジニアのスキルシートは、扱ってきたSAP製品・データベース・OS・基盤の組み合わせを一覧で示し、プロジェクトごとの作業は「どんな条件で」「計画と判断まで担ったか」を書き分けるのが基本です。Basisの案件は環境の組み合わせで募集されることが多く、作業の名前を並べるだけでは、読み手は自分の案件の環境で任せられるかを判断できません。

作業の種類による棚卸しはSAP Basisエンジニアがフリーランスになるには、層ごとに求められる技術はSAP Basisエンジニアのスキルの記事で扱っています。この記事では、それをシートの上でどう見せるかを解説します。

環境の組み合わせは一覧にして先頭に置く

Basisの読み手が最初に確かめるのは、案件の環境と同じ組み合わせを扱ったことがあるかです。プロジェクト欄にばらばらに書かれていると、読み手は全部を読んで組み合わせを拾い出さなければなりません。スキル一覧の中に、環境の組み合わせの表を作っておくと判断が早くなります。

記入例（架空）：

「経験」の列には、年数とあわせて、構築・運用・更新・移行のどれを担ったかを書きます。同じ組み合わせでも、運用だけの経験と、構築から担った経験では、任せられる範囲が違うためです。

要約は「得意な層」と「得意な局面」で書く

要約の欄は、環境の一覧とは別に、自分がどこで力を出せるかを3〜5行で書く場所です。Basisの場合は、得意な層（OS・データベースに強いのか、SAPのアプリケーション層に強いのか）と、得意な局面（構築、運用、更新、移行のどれか）を入れると、読み手は案件と結び付けやすくなります。

例（架空）：

• SAPの基盤の運用・更新に6年従事。直近2年はS/4HANAへの移行の基盤作業を担当
• SAP HANAのバックアップと監視の設計、移行のリハーサルと手順書の作成が得意
• Linuxとクラウドの基盤の構築経験があり、基盤ベンダーとの調整も担当

プロジェクト欄は「作業の条件」を書く

Basisの作業は、どのプロジェクトでも「インストール」「更新」「システムのコピー」など同じ名前になります。違いが出るのは、その作業をどんな条件の中で行ったかです。プロジェクト欄には、作業の名前に加えて次の条件を書きます。

特に大切なのが最後の「関わり方」です。手順書を自分で作り、所要時間を見積もり、切り戻しの条件を決めたのか、それとも決まった手順に沿って実施したのか。どちらも大事な経験ですが、読み手が任せる範囲は大きく変わります。

停止時間は「計画」と「実績」で書く

更新や移行の作業は、業務を止められる時間が決まっています。この時間をどう守ったかは、Basisの経験で最も伝えたい部分の一つです。

シートには、次の順に書くと伝わりやすくなります。

1. 停止時間の枠：業務側から与えられた時間の大きさ
2. リハーサル：検証環境で何回試し、何を変えたか
3. 本番の結果：枠の中で終わったか、想定外のことが起きたか、そのときどう判断したか

具体的な時刻や日付は書かなくてかまいません。「週末の停止枠の中で完了」「リハーサルで判明したデータ量の偏りに合わせて、作業の順番を入れ替えた」のように、判断が伝わる書き方を心がけます。

記入例（架空）

次は、書き方の型を示すための例です。業種と規模はぼかしてあり、実在のプロジェクトではありません。

期間：20XX年6月〜翌年9月（1年4か月）
環境：ECC（Oracle・Linux・自社のデータセンター）からS/4HANA（SAP HANA・Linux・パブリッククラウド）へ
業種・概要：流通業（中堅規模）の基幹システムの移行
立場：基盤チーム3名のうち、移行作業のリーダー
担当工程：移行方式の検討への参加、前提の版への更新、リハーサル、本番の移行、稼働後の監視
担当内容：移行のリハーサルを検証環境で複数回実施し、所要時間の見積もりと手順書を作成。大きなテーブルの移し方を見直し、停止時間の短縮案を作成。本番当日の進めるか戻すかの判断基準を、業務側と事前に合意
工夫・成果：本番の移行を週末の停止枠の中で完了。稼働後は性能の監視の項目を見直し、バッチの遅延を早めに見つけられるようにした

実際に書くときは、ご自身の経験に置き換えてください。

運用の経験を「成果」として書く

運用・保守の経験は、毎日の監視やジョブの管理が中心のため、成果の欄が空になりがちです。しかし、運用の中で自分が変えたことは、成果として書けます。

• 監視の見直し：見るべき項目を整理し、障害の兆しを早めに見つけられるようにした
• 手順書の整備：システムのコピーや更新の手順書を作り直し、担当者が変わっても同じ手順で進められるようにした
• 自動化：起動・停止や定期的な確認をスクリプトにして、手作業を減らした
• 障害の切り分け：性能の問題や障害の原因を、OS・データベース・SAPのどの層かまで絞り、再発を防ぐ対策をまとめた

障害の件数や時刻などの細かい数字は、守秘義務に触れることがあるため、「月末のバッチの遅延の原因を調べ、設定を見直した」のように、内容で伝える書き方が無難です。書いてよい範囲はスキルシートと守秘義務の記事をご覧ください。

担当範囲の境目を書いておく

Basisの仕事は、どこまでを担当するかがプロジェクトごとに違います。権限の設計、ネットワーク、クラウドの基盤、データベースの管理などは、別の担当やベンダーが持つこともあります。シートでは、自分の担当と、他の担当に任せていた部分の境目を書いておくと、読み手は参画後の役割を思い描けます。

例（架空）：「SAPの基盤の構築・運用を担当。クラウドのネットワークと仮想マシンの構築は基盤ベンダーが担当し、要件の取りまとめと受け入れの確認を担った」

クラウドの基盤まで自分で構築した経験がある場合は、使ったサービスの種類と構成を書くと、クラウドの案件にも広げやすくなります。クラウド側の書き方はAWSエンジニアのスキルシートの記事やAzureエンジニアのスキルシートの記事も参考になります。

基本情報に夜間・休日の対応を書く

Basisの案件では、更新や移行の当日、障害の対応などで、夜間や休日の作業が発生することがあります。基本情報の欄に、夜間・休日の作業やオンコールの対応をどこまで受けられるかを書いておくと、条件の合わない案件の提案を避けやすくなります。対応できる頻度や、事前の調整が必要かどうかも、あわせて書いておくとよいでしょう。

よくある質問

インフラエンジニアの経験が長く、SAPの経験は短いです。どう書けばよいですか？

環境の一覧では、SAPの経験とインフラの経験を分けて書きます。そのうえで、OS・データベース・クラウドの経験は、Basisの下の層の知識として強みになるため、スキル一覧にくわしく書いておきましょう。SAPの経験が短い場合は、担当した作業の範囲を正直に書くことが大切です。

英語の力はどう書けばよいですか？

「英語可」とだけ書くより、SAPの技術文書を読む、SAPのサポートへの問い合わせを書く、海外の担当者と会議をする、のように、使った場面で書くと伝わります。会議で話す経験がない場合は、読み書きまでと書いておくと、面談で食い違いが起きません。

権限の設計の経験は、Basisのシートに書いてよいですか？

書いてかまいません。ユーザーの管理や権限の付与、監査への対応に関わった場合は、Basisの作業とは別の行にして、どこまで担当したかを書きます。権限の設計を専門の担当が持っていたプロジェクトでは、自分が担った範囲（付与の作業のみ、設計まで、など）を書き分けておくと誤解を防げます。