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

ServiceNowのスキルシートは、プロジェクトごとに「どの領域で」「どの役割を」「どの工程で」担ったかをそろえ、標準の機能で済ませたか開発したかの判断と、扱ったリリースまで書くと伝わります。ServiceNowの案件は領域と役割の組み合わせで募集されることが多く、読み手はまずその組み合わせが合うかを確かめるからです。

この記事では、ServiceNowならではの書き方のポイントを、架空の記入例とあわせて紹介します。全体の構成はスキルシートの書き方の基本、案件で求められるスキルはServiceNowのスキルの記事で解説しています。

「ServiceNow経験◯年」だけでは伝わらない

ServiceNowの経験者のシートで多いのが、スキル一覧に「ServiceNow（4年）」とだけ書かれている形です。ServiceNowはITSM、ITOM、HR Service Delivery（HRSD）、Customer Service Management（CSM）など領域が広く、同じ4年でも、運用担当として設定を続けてきたのか、開発者としてスクリプトを書いてきたのか、要件定義から導入をまとめてきたのかで、まったく違う経験になります。

読み手が確かめたいのは、次の3つの組み合わせです。

• 領域：ITSM、ITOM、HRSD、CSMなど、どの領域を扱ったか
• 役割：管理（運用）、開発、導入コンサル（要件定義・設計）、アーキテクトのどれか
• 工程：新規導入、追加開発、運用保守、バージョンアップ対応のどこを担ったか

スキル一覧は、この組み合わせが見える形で書くと、読み手が案件の条件と照らし合わせやすくなります。

工程と「どの環境に手を入れたか」を書き分ける

ServiceNowの案件では、新しく導入するプロジェクトと、長く使われている環境に手を入れるプロジェクトとで、求められる力が違います。

• 新規導入：業務を聞き取り、標準のプロセスにどう合わせるかを提案する力
• 追加開発・改修：既存の設定やスクリプトを読み解き、影響の範囲を見極める力
• 運用保守：依頼を受けて設定を変え、権限やデータの品質を保つ力
• バージョンアップ対応：影響を受ける設定を洗い出し、テストし、問題を直す力

バージョンアップ対応は、他の製品の経歴にはない項目なので、独立した工程として書いておくと目に留まりやすくなります。プロジェクト欄の冒頭に、どの工程かを書いておくことをおすすめします。

使った機能は具体的な名前で書く

担当内容の欄に「カスタマイズを担当」「開発を担当」とだけ書くと、深さが伝わりません。ServiceNowのシートでは、扱った機能や仕組みを具体的な名前で書くのが基本です。

それぞれに、自分が設計から担当したのか、決められた設計どおりに作ったのかを添えると、任せられる範囲が伝わります。

扱ったリリースの名前を書く

ServiceNowは大型のリリース（ファミリーリリース）ごとに名前を付けています。公式の提供バージョンの一覧（2026年10月時点）には、Yokohama、Zurich、Australia、Brazilといった名前が並んでいます。以前は都市名でしたが、2026年に出たAustralia、Brazilは国名です。

プロジェクト欄に「対象リリース：Zurich」「Yokohamaから Australia へのバージョンアップ」のように書いておくと、どの時期の機能に触れていたかが読み手に伝わります。バージョンアップに関わった場合は、移行元と移行先のリリース名、確認した範囲を書きます。リリースの動きと今後についてはServiceNowの将来性の記事で解説しています。

「標準で済ませた判断」を書く

ServiceNowの案件では、何でも作り込むのではなく、標準のプロセスや機能で済むところは済ませる判断が評価されやすくなります。標準の処理を書き換えるほど、バージョンアップのたびに確認と修正の負担が増えるためです。

この判断は、シートの「工夫・成果」の欄に書くと目に留まりやすくなります。

記入例（架空）：判断が伝わる書き方

工程：新規導入（要件定義〜本番立ち上げ、約7か月）
案件概要：製造業のIT部門向け ITSMの導入。メールと表計算ソフトで受け付けていた障害の連絡と申請を移行
規模：利用者は数千名規模、IT部門の担当グループは十数個、監視ツールと連携
対象リリース：Zurich
役割：導入コンサル兼開発（チーム6名のうち、変更管理とサービスカタログの主担当）
担当内容：IT部門への聞き取りと要件定義。変更の区分と承認の流れの設計。申請の項目と承認をサービスカタログとFlow Designerで構成
判断した点：既存の申請書に合わせた専用の画面を作る案が出ていたが、標準のカタログの画面と変数で要件の大半を満たせることを示し、開発は他システムへの連携部分だけに絞った
成果：標準の処理を書き換えずに導入でき、導入後の申請の追加を社内の運用担当が行えるようになった

これは書き方を示すための架空の例です。業種、規模、リリース、判断の内容は、ご自身の経験に置き換えてください。

開発者の方も、スクリプトで作った部分について「なぜフローや標準の設定では足りなかったか」を一言書いておくと、面談での説明につながります。

規模は丸めた数で示す

ServiceNowの案件では、利用者や担当グループの数、連携の数によって設計の難しさが変わります。規模の欄には、次のような項目を丸めた数で書きます。

• 利用者の規模（数百名、数千名など）
• 担当グループや利用部門の数
• 連携している外部システムの数
• 月あたりの問い合わせや申請の件数（桁がわかる程度）

ライセンスの契約数や、社内の障害の件数などは、社外に出せない情報にあたることがあります。どこまで書いてよいかの考え方はスキルシートに書いてよいこと・いけないことをご覧ください。

認定資格とITILの書き方

資格欄には、正式な名称と取得年月を書き、ServiceNowの認定資格とITILなどの関連資格を分けて並べると読みやすくなります。取得後の維持の扱いは公式の案内で必ずご確認ください。そのうえで、現在も有効な状態かを正確に書いておきます。資格の数を増やすことより、資格と同じ領域の実務をプロジェクト欄で示すことが評価につながります。

他のシステムの経験の書き方

ServiceNow以外の経験がある方は、それを別のプロジェクトとして書きつつ、ServiceNowの案件に生きる要素を一行添えます。たとえば、ヘルプデスクや運用の経験は業務の聞き取りに、JavaScriptでの開発経験はスクリプトの開発に、他の運用管理ツールの導入経験はプロセスの設計に、それぞれ結び付けて書けます。

要約の欄では、ServiceNowの経験を上に置き、他の経験は補足の形で書くと、応募するときの軸がぶれません。

よくある質問

運用担当としての経験しかありません。どう書けばよいですか？

運用の経験も、扱った機能と依頼の種類を具体的に書けば十分な判断材料になります。カタログの追加、権限の見直し、通知やSLAの変更、レポートの作成など、自分で設計から行ったものを分けて書くと、運用保守の案件だけでなく、設計寄りの案件にも出しやすくなります。

古いリリースの経験は書かないほうがよいですか？

書いてかまいません。古いリリースで作った仕組みを、新しいリリースの機能に置き換えた経験は、既存の環境を整理する案件で評価されることがあります。担当した時期とリリース名、置き換えに関わったかを分けて書くと、今使えるスキルが伝わります。

準委任の案件と請負の案件で、書き方は変わりますか？

書き方の型は同じですが、請負の案件では、自分が担った成果物と品質への責任の範囲をはっきり書いておくと読み手に伝わりやすくなります。契約の形の違いは準委任と請負の違いの記事で解説しています。