ServiceNowエンジニアの参画初月にやること｜現場で信頼される進め方

ServiceNowエンジニアの参画初月は、対象の環境（インスタンス）の状態と、変更の移し方・承認の決まりをつかみ、小さな変更を記録つきで手順どおりに届け、月末に「環境の見立て」と「改善の候補」を出すところまでを目標にします。最初の1か月で求められるのは、多くの画面を作ることより、この人に環境を触らせて大丈夫だと発注側が判断できる材料を示すことです。

参画前の契約・環境の準備は参画が決まってから開始日までにやること、職種を問わない最初の1週間の進め方は参画初日から最初の1週間でやることで解説しています。この記事では、ServiceNowならではの初月の動き方に絞ります。

初月のゴールを3つに分ける

この3つを、1週目、2週目、3〜4週目の順に重心を移しながら進めます。

1週目：環境と決まりを読む

最初に確かめること

ServiceNowは、同じ製品でも環境ごとに過去の経緯がまったく違います。次の順で確かめると、全体像をつかみやすくなります。

1. 使っている領域とバージョン：ITSMだけか、ITOMや人事・顧客対応の領域もあるか。今のファミリーリリースと、次のバージョンアップの予定
2. 自分が触る範囲のテーブルと処理：担当するプロセスのテーブルに、どんなビジネスルール、クライアントスクリプト、フローが載っているか
3. 標準を書き換えた箇所：標準の処理を直接変えた箇所の一覧や、設計の記録が残っているか
4. 外部との連携：監視ツール、人事システム、認証の仕組みなど、何とどうつながっているか
5. 変更の移し方：開発用・検証用・本番の環境の間で、変更をどの単位で、誰の承認で移すか

読みながら、「作り込みが多そう」「経緯が分からない」という点を書き留めておきます。この段階では直さず、仮説としてためておきます。

関係者と短く話す

資料だけでは分からないのが、使う人の見方です。発注側の窓口、プロセスの担当者（変更管理やサービスカタログの持ち主など）、運用担当、主な利用部門の代表と、短い時間で話す機会をもらいます。聞くことは次の3つに絞ると、相手の負担になりません。

• 今の仕組みで一番困っていること
• うまく回っていること
• 自分に期待すること

同じ質問を全員にすると、IT部門と利用部門の見方の違いがはっきりします。この違いが、改善の候補の手がかりになります。

2週目：小さな変更を決まりどおりに届ける

最初の変更は小さく選ぶ

2週目には、影響の小さい依頼や設定の変更を一つ引き受け、現場の決まりどおりに開発用の環境で作り、検証用で確かめ、承認を経て本番へ移すところまでを通します。中身の大きさより、手順を一度も外さずに通したことが信頼の材料になります。

記録と共有の型を見せる

変更ごとに、何を・なぜ・どの環境に・いつ反映したかを、チケットや変更の記録に残します。利用者に影響が及ぶ変更は、反映の前に窓口へ短く伝えます。リモート中心の案件での記録の残し方はServiceNowのリモートの記事でも触れています。

本番作業の手順と連絡先を一枚にまとめる

本番への反映の時間帯、承認者、障害時の連絡先、切り戻しの方法を一枚にまとめ、窓口と確かめます。ここがあいまいなままだと、2か月目以降に初めての本番作業で迷うことになります。

3〜4週目：見立てを出し、改善の候補を示す

環境の見立てをまとめる

1〜2週目で集めた情報と、実際に変更して分かったことをもとに、担当範囲の見立てをまとめます。中身は次のとおりです。

• 標準を書き換えた箇所や、似た処理の重複
• バージョンアップのときに確認が膨らみそうな箇所
• 権限やデータの持ち方で、気になる点
• 利用部門の困りごとと、仕組みの側の原因の見立て

改善の候補は選択肢で出す

改善が必要な箇所がある場合、一つの案だけを出すと、「前の担当者の作りを否定された」と受け取られやすくなります。標準の機能に戻す、フローに置き換える、今は触らない、といった選択肢を並べ、それぞれの手間と影響を示したうえで、発注側に選んでもらう形にします。

次の1〜2か月の進め方を合わせる

合意した内容をもとに、次の1〜2か月で手を付ける順番を窓口と合わせます。ここまでできれば、初月の役割は十分に果たせています。

案件の型によって初月の重心は変わる

同じServiceNowの案件でも、型によって初月に力を入れる場所が違います。

新規導入の案件

まだ環境がない、または初期の構築中の段階では、既存の環境を読むより、業務の聞き取りと、標準のプロセスとの違いを洗い出すことが初月の中心になります。月末には、標準で対応できること、作る必要がありそうなこと、決めきれていない論点の一覧を出せることを目指します。

既存環境の改修・整理の案件

長く使われた環境では、1週目の「読む」比重がさらに大きくなります。触る前に、同じテーブルに関わる処理を洗い出し、どれがいつ動くかを書き出しておくと、思わぬ影響を避けられます。整理の方針は、初月のうちは決めずに、見立てとして出すにとどめます。

運用保守の案件

依頼が初日から届く案件では、依頼の受け方、優先順位の決め方、月の稼働の上限を超えそうなときの扱いを、最初の週に窓口と合わせることが大切です。依頼と対応の記録を月末にまとめて共有すると、2か月目以降の量の相談がしやすくなります。

バージョンアップの案件

時期が決まっている案件では、初月から影響確認の計画づくりが始まります。標準を書き換えた箇所と、テストで確かめる業務の範囲を早めに洗い出し、どこまでを自動テストで確かめるかを窓口と合わせます。

初月に避けたい動き

範囲外の依頼が増えてきたときの扱いは作業範囲が広がったときの記事、つまずきやすい場面はServiceNowエンジニアのフリーランスがつまずきやすい点と対策で整理しています。

1か月の終わりに振り返ること

1か月が過ぎたら、次の点を自分で振り返ります。

• 担当範囲の環境の見立てと、改善の候補を窓口に伝えられたか
• 変更の移し方と承認の流れを、手順どおりに通せたか
• 変更の記録が、後から誰が見ても追える形で残っているか
• 契約で決めた業務の範囲と、実際に担っている仕事がずれていないか
• 稼働時間の記録が残っているか

ずれている点があれば、2か月目の早い段階で窓口と話しておきます。記録の残し方は設計書・手順書を残す習慣も参考になります。

よくある質問

前任者からの引き継ぎがほとんどありません。何から始めればよいですか？

自分が担当するテーブルに載っている処理の一覧と、直近の変更の記録から読み始めるのが近道です。そのうえで、運用担当と主な利用部門に、今一番困っていることを聞いてください。設計の記録がない状態そのものも、環境の見立ての一部として報告に含めておくとよいでしょう。

初月から大きな開発を求められたら、どうすればよいですか？

急ぐ必要がある場合でも、まずは同じテーブルに関わる既存の処理と、標準の機能で足りないかを確かめてから着手します。分かっていない点を明らかにしたうえで、作り方の選択肢と影響を示し、発注側に選んでもらう形をとると、後で見立てが変わったときにも説明しやすくなります。

1か月たっても環境の全体像がつかめません。どうすればよいですか？

多くの領域を載せた環境や、長く使われた環境では、1か月で全体をつかみきれないこともあります。その場合は、分かっていることと分かっていないことを分けて報告し、残りをいつまでに確かめるかの予定を示してください。担当範囲を区切って見立てを出すほうが信頼されます。