ServiceNowエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのServiceNowエンジニアがつまずきやすいのは、業務範囲と本番環境への権限があいまいなまま動くこと、業務側の要望をそのまま作り込むこと、既存のカスタマイズを読み違えること、バージョンアップの前後に稼働が膨らむことです。どれも、ServiceNowが社内の多くの部門が日々使う窓口であり、一つの変更が思わぬところに響く仕組みであることから起きます。

対策の基本は、つまずきの種を契約と参画初期の取り決めで小さくしておき、現場では変更の記録と事前の共有で守ることです。この記事では、契約・現場・技術・お金の順に、ServiceNowならではの場面と対策を整理します。契約前に確かめる項目の一覧はServiceNowの案件の選び方で扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

「ServiceNowの導入支援」の中身が人によって違う

契約書には「ServiceNow導入支援業務」とだけ書かれ、現場では要件定義の資料づくりから、設定、スクリプトの開発、テスト、利用部門への説明まで期待されていた、という食い違いはよく起きます。ServiceNowは管理・開発・導入コンサルの役割の境目があいまいになりやすく、少人数の体制ほど、引き受けた範囲が少しずつ広がりがちです。

対策：参画前に、担う成果物（設計書、設定、スクリプト、テストの記録など）と、担わないもの（利用者向けの研修、他システム側の改修など）を言葉で確かめておきます。範囲の外の依頼が来たときの扱いは作業範囲が広がったときの記事と追加の依頼の断り方をご覧ください。

本番環境の権限と責任の線が決まっていない

本番環境の管理者権限を渡されたまま、誰が変更を承認するかが決まっていない案件があります。この状態で障害が起きると、「反映した人の責任」とされやすくなります。

対策：本番への反映の手順、承認者、障害時の連絡先を、参画の初期に書き出して窓口と確かめます。権限を渡されても、承認の記録を残してから反映する形を自分の側で守ると、後で経緯を説明できます。

指揮命令の形が社員と変わらなくなる

情報システム部門の一員のように扱われ、勤務時間や作業の手順まで細かく指示されるようになると、準委任の契約と実態がずれてきます。運用保守の案件では、チャットで随時依頼を受ける形が続くうちに、この状態に気づきにくくなります。考え方は偽装請負の記事で解説しています。

現場でのつまずき

業務側の要望をそのまま作り込む

「今の申請書と同じ項目にしてほしい」「この部門だけ別の承認の流れにしてほしい」といった要望を、そのまま画面やスクリプトで作り込むと、その場は喜ばれても、バージョンアップのたびに確認と修正の手間が増えます。後から入った人に「なぜこんな作りにしたのか」と問われるのは、作った人です。

対策：作る前に、標準のプロセスやサービスカタログの仕組みで足りないかを確かめ、足りない場合は「作った場合に将来かかる手間」とあわせて業務側と発注側に示します。決めるのは発注側ですが、判断の材料を出したことを記録に残しておきます。

変更の影響を利用部門が後から知る

通知の条件や権限、割り当てのルールを変えたとき、利用部門への共有が後回しになり、問い合わせで初めて変更が知られることがあります。ServiceNowは多くの人が毎日使う窓口のため、小さな変更でも混乱が起きやすくなります。

対策：影響が利用者に及ぶ変更は、反映の前に、何が・いつ・なぜ変わるかを短くまとめて窓口に渡します。変更の記録には、業務側にも伝わる言葉で理由を書きます。

部門ごとの言い分の間に挟まれる

IT部門と人事、総務など、同じ基盤を使う部門の要望がぶつかることがあります。外部のエンジニアがどちらかの言い分に沿って作ると、もう一方の部門から信頼を失います。

対策：部門をまたぐ論点は、自分で決めずに一覧にし、発注側の決裁者に判断を仰ぎます。選択肢ごとの影響（権限、データの見え方、運用の負担）を並べて出すと、決めてもらいやすくなります。

技術でのつまずき

既存のカスタマイズを読み違える

長く使われた環境では、標準の処理を直接書き換えた箇所や、似た処理を行うスクリプトの重複が積み重なっていることがあります。一つを直したつもりが、別のビジネスルールやフローと重なって、思わぬ動きを起こすことがあります。

対策：触る前に、同じテーブルに関わる処理を洗い出し、どれがいつ動くかを書き出します。分からない処理は消さずに、持ち主や経緯を窓口に確かめてから扱いを決めます。

環境の間での変更の移し漏れ

開発用の環境で作った変更を、検証用、本番へと移すとき、移す単位の切り方や順番を誤ると、本番だけ動かない、他の人の変更を巻き込む、といった事態が起きます。

対策：現場の移し方の決まりを参画初期に確かめ、自分の変更がどの単位に入っているかを毎回確認します。移した後の確認の手順も、変更ごとに決めておきます。

権限とデータの見え方の確認が漏れる

人事の窓口（HRSD）など機微な情報を扱う領域では、権限の設定の誤りが情報の見え過ぎにつながります。画面の動きだけ確かめて、別の立場の利用者から何が見えるかを確かめないまま反映すると、後で大きな問題になります。

対策：権限に関わる変更は、立場の違う利用者の目線で、見える・見えないを確かめてから反映します。業務で個人情報を扱うときの考え方は個人情報を扱うときの契約と注意点をご覧ください。

お金でのつまずき

バージョンアップと本番作業で稼働が膨らむ

バージョンアップの前の影響確認とテスト、本番の切り替えの夜間作業が重なると、精算幅を大きく超えることがあります。超えた分の扱いを決めていないと、報酬に反映されないまま負担だけが増えます。

対策：稼働を日々記録し、精算幅を超えそうな段階で窓口に伝えます。夜間・休日の作業の扱いも、参画前に確かめておきます。精算の仕組みは精算幅の記事で解説しています。

運用保守の依頼が際限なく増える

運用保守の案件では、チャットでの随時の依頼が積み重なり、月の稼働の上限を超えても依頼が止まらないことがあります。

対策：依頼の受け方（チケットかチャットか）と、上限を超えそうなときの優先順位の決め方を窓口と合わせておきます。依頼と対応の記録を月ごとにまとめて共有すると、量の相談がしやすくなります。

導入の区切りで契約が終わる

要件定義の終わりや本番の立ち上げなどの節目で、契約が更新されないことがあります。フリーランス法では、6か月以上の業務委託をしている発注側が契約を解除したり更新しなかったりする場合、少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の案内による）。

対策：契約期間と導入のフェーズの区切りを並べて見ておき、更新の見込みを早めに確かめます。契約期間の考え方は契約期間の記事をご覧ください。

よくある質問

参画してから、聞いていた役割と違うと気づきました。どうすればよいですか？

まずは、何が違うのかを具体的に書き出し、契約で決めた業務範囲と照らし合わせます。そのうえで、紹介を受けたエージェントや発注側の窓口に早めに伝えてください。我慢して続けると、範囲外の作業が当たり前になり、後から戻しにくくなります。

自分の反映した変更で障害が起きたら、損害賠償を求められますか？

準委任契約では、成果そのものを約束しているわけではありません。ただし、契約の内容や、作業の進め方に落ち度があったかどうかで判断が変わることがあります。承認の記録や確認の手順を残しておくと、経緯を説明しやすくなります。不安がある場合は、契約書の損害賠償の条項を読み、弁護士などの専門家にご相談ください。

前任者の作ったカスタマイズが多く、手を付けるのが怖いです。

一度にすべてを理解しようとせず、自分が触るテーブルに関わる処理から書き出していくのが近道です。分からない処理は消さずに残し、経緯を窓口に確かめます。整理の方針そのものを提案する場合は、残す・置き換える・やめるの案と影響を並べて、発注側に決めてもらう形をおすすめします。