ServiceNowエンジニアのフリーランス案件の仕事内容｜案件の種類と働き方

ServiceNowエンジニアのフリーランス案件の仕事は、業務の受け付けの流れを、標準の機能を軸に組み立て、変更を安全に本番へ届け、使われ続ける状態に保つことです。ただし、新しく導入する案件か、長く使われている環境に手を入れる案件か、運用を引き受ける案件かで、1日の時間の使い方も、向き合う相手も、残る成果物も大きく変わります。

この記事では、ServiceNowの案件を5つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。必要なスキルはServiceNowのスキルの記事、報酬の決まり方はServiceNowの報酬の記事で扱っているので、ここでは「参画したら何をしているか」に絞ります。

仕事の中身は「工程」と「環境の状態」で決まる

ServiceNowの案件は、同じ「ITSMの案件」でも働き方がかなり違います。違いを生むのは、主に次の2つです。

• 工程：要件定義から本番の立ち上げまでの導入か、追加の開発か、日々の運用か、リリースへの追随か
• 環境の状態：まっさらな状態から作るのか、何年も前から複数の会社が手を入れてきた環境なのか

この2つを組み合わせると、フリーランスのServiceNow案件はおおむね次の5種類に分けられます。

以下は典型的な例です。時間の配分は現場ごとに違うため、目安として読んでください。

新規導入の案件

1日・1か月の流れ（例）

要件定義の時期は、午前に利用部門との打ち合わせがあり、今の受け付けの流れや例外の扱いを聞き取ります。午後は聞いた内容を、インシデント管理やサービスカタログなど標準のプロセスと見比べ、標準で受け止められる部分と、設定や開発が要る部分に分けて整理します。1か月の単位では、部門ごとの聞き取りを一巡させ、要件の一覧と、作り込みを抑える方針について業務側の合意を取ることが目標になります。

設定と開発の時期に入ると、開発用の環境で画面やフロー、通知を組み、週に一度ほど利用部門に画面を見せて確認してもらいます。立ち上げの前には、利用者向けの手順書や運用担当への引き継ぎの準備が加わります。

成果物

要件の一覧、標準との差の整理（標準で対応するもの・設定で対応するもの・開発するもの）、設計書、設定と開発の成果、テストの記録、利用者向けの手順書、運用への引き継ぎ資料などです。新規導入では、「なぜ作らなかったか」を残す資料が、後の運用やバージョンアップで効いてきます。

追加開発・改修の案件

1日・1か月の流れ（例）

朝はチケットやタスクの一覧で担当分を確かめ、午前中は対象の機能に関わる既存の設定やビジネスルール、スクリプトを読み解きます。長く使われてきた環境では、同じ処理が複数の場所に書かれていたり、標準の処理が直接書き換えられていたりするため、作る前に調べる時間が多くなります。午後は開発用の環境で実装し、影響のありそうな画面や通知を自分で確かめます。

1か月の単位では、開発・検証・本番の間で変更を移す決まった日程に合わせて、開発、レビュー、検証用環境でのテスト、本番への反映を回していきます。

成果物

改修の設計メモ、開発の成果、変更をまとめた単位の一覧、テストの記録、レビューの指摘への対応記録などです。既存の処理を整理した場合は、残したもの・置き換えたもの・やめたものの一覧も成果物になります。

運用保守・改善の案件

1日・1か月の流れ（例）

運用保守では、朝に新しく届いた依頼を確かめ、優先度をつけて対応の順番を決めます。依頼の中身は、サービスカタログの項目の追加、承認の流れの変更、通知の文面の修正、グループやロールの付け替え、レポートの作成などです。急ぎの問い合わせが入れば、利用部門に状況を聞き、設定の問題か使い方の問題かを切り分けます。

1か月の単位では、依頼の件数や対応状況を発注元に報告し、繰り返し出てくる問い合わせがあれば、ナレッジの記事を足したり、画面の分かりにくい部分を直したりする改善を提案します。

成果物

依頼ごとの対応記録、設定変更の記録、月次の報告、ナレッジの記事、権限やグループの一覧の更新などです。運用保守の案件は長く続きやすく、週数日の稼働の形もあります。稼働の幅を決めて精算する契約が多いため、依頼の量と稼働の関係は精算幅の記事をご覧ください。

バージョンアップ対応の案件

ServiceNowは大型のリリースに名前を付けて提供しています。2026年10月時点の公式の提供バージョンの一覧では、Brazilの早期提供（Feature Early Availability）が2026年9月24日に始まっていることが示されています。利用企業はこうしたリリースへの追随を続けるため、バージョンアップの作業は定期的に発生します。

1か月の流れ（例）

• 最初の週：対象のリリースのリリースノートを読み、自社の環境で影響を受けそうな機能を洗い出す
• 次の週：検証用の環境をアップグレードし、標準を書き換えた箇所や、更新で差分が出た箇所を確かめる
• その後：業務の担当者と主な操作を一通り試し、問題があれば修正する。自動テストの仕組みがあれば回帰テストを回す
• 最後：本番の切り替えの手順を決め、切り替え後の確認まで行う

成果物

影響の調査結果、差分の確認と対応方針の一覧、テストの計画と結果、本番切り替えの手順、切り替え後の確認の記録などです。どのリリースからどのリリースへ移ったかは、スキルシートに書くと目に留まりやすい経験になります。

CMDB・外部連携の整備の案件

ITOMの領域では、サーバーやネットワーク機器、アプリケーションなどの構成情報を構成管理データベース（CMDB）に持ちます。この種の案件では、どの粒度で何を登録し、誰がどう保つかを決め、構成情報を自動で集める仕組みや、監視ツール・人事システムなどとの連携を設定します。

1日の中では、インフラや運用の担当者と登録の範囲を詰める打ち合わせ、取り込んだデータの重複や欠損の確認、連携先の担当者との仕様の確認に時間を使います。社内のネットワークの中に置く仕組みを扱う場合は、作業の場所が限られることもあります。リモートとの相性はServiceNowのリモートの記事で解説しています。

成果物は、登録ルールの設計書、データの持ち方の一覧、連携の仕様書、取り込みの設定、データ品質の確認の記録などです。

どの案件にも共通する仕事

種類が違っても、次の仕事はほぼすべてのServiceNow案件にあります。

1. 変更の記録：何を、なぜ、どの環境に反映したかを残し、後から誰が見ても追えるようにする
2. 影響の確認：通知、権限、他のプロセスに影響しそうな変更は、反映の前に確かめて伝える
3. 画面での確認：業務側に実際の画面を見せて確認してもらってから次に進む
4. 環境の決まりを守る：開発・検証・本番の間で変更を移す手順と、本番への反映の承認の流れに沿う

フリーランスならではの仕事として、自分の稼働の記録と報告もあります。依頼の対応と打ち合わせの時間を日々つけておくと、月末の報告と精算がぶれにくくなります。

よくある質問

ServiceNowの案件では、コードを書く時間はどのくらいありますか？

案件の種類と役割によります。開発者として改修の案件に入ればスクリプトを書く時間が多くなりますが、新規導入の導入コンサルや運用保守の管理者の役割では、設定や打ち合わせ、記録の時間が中心です。どの役割の比重が大きいかは、面談で割合を確かめておくと稼働の見込みとのずれを防げます。

運用保守の案件は、毎日同じ作業の繰り返しになりますか？

依頼の対応は繰り返しの面がありますが、問い合わせの傾向を見てナレッジを足したり、承認の流れを見直したりする改善の提案まで任される案件もあります。改善まで含むかどうかで、経験として積めるものが変わります。

参画して最初の1か月は何をすることが多いですか？

環境の構成と開発・検証・本番の間の変更の移し方、本番への反映の承認の流れ、関わる部門と窓口の把握から始めるのが一般的です。初月の進め方はServiceNowの参画初月にやることで詳しく解説します。