社内業務に関するシステムを一元化して運用・管理できるクラウドサービス「ServiceNow」。
株式会社ＫＹＯＳＯでは、これまでの豊富な運用経験をもとに、ServiceNowの企画立案から運用・保守、内製化までトータルでサポートしています。

はじめに

あなたのServiceNowインスタンス、”秘伝のタレ”化していませんか？

ServiceNowを導入して数年。ビジネス要件に応えるため、数々の機能追加やカスタマイズを繰り返してきた結果、こんな課題に直面していないでしょうか？

• 「特定の担当者しか仕様がわからず、改修に時間がかかる」
• 「些細な変更のはずが、思わぬ箇所に影響が出てしまう」
• 「プラットフォームのバージョンアップが、エラー多発で毎回一大イベントになっている」

もし一つでも当てはまるなら、お使いのインスタンスは「技術的負債」が蓄積し、属人化した”秘伝のタレ”状態に陥っているサインかもしれません。

この技術的負債を放置すると、将来的にシステムのパフォーマンス低下や保守コストの増大を招き、ServiceNowが持つ本来の価値を損ないかねません。

本記事では、こうした事態を防ぎ、持続可能で健全なServiceNow運用を実現するための「開発ガバナンス」の考え方と、その中核となる「開発標準策定の5つの勘所」を、具体的なルール例と共に徹底解説します。

第1章：なぜ今、ServiceNowに「開発ガバナンス」が必要なのか？

開発ガバナンスとは、簡単に言えば「ServiceNowを開発・運用していく上での共通ルール」です。このルールがない無法地帯では、以下のような問題が頻発します。

• パフォーマンスの低下: 各開発者が場当たり的に非効率なスクリプトを作成し、インスタンス全体の応答速度が低下する。
• 属人化・ブラックボックス化: 命名規則や設計思想がバラバラで、作成者以外には解読不能なカスタマイズが乱立する。
• 改修・保守コストの増大: 影響範囲の調査が困難になり、簡単な修正にも多大な時間とコストがかかるようになる。
• アップグレードの失敗: ServiceNowの標準から逸脱したカスタマイズ（特にGlobalスコープでの変更）が多すぎると、バージョンアップ時にスキップされたり、動作しなくなったりするリスクが高まります。

これらの問題はすべて「技術的負債」です。今すぐ対処しなければ、将来的に何倍もの利息（コスト）を支払うことになります。健全なガバナンスを効かせることは、未来のServiceNowへの投資なのです。

第2章：今すぐ始めるべき！開発標準策定 5つの勘所

では、具体的にどのようなルールを定めれば良いのでしょうか。ここでは、特に重要となる5つのポイントを解説します。

1. 命名規則 (Naming Conventions)：一目でわかる名前をつける

なぜ必要か？

一貫した命名規則は、設定やスクリプトの可読性を劇的に向上させ、目的のコンポーネントを素早く見つけ出すことを可能にします。これは、保守やデバッグの効率に直結します。

具体的なルール例:

• 接頭辞（Prefix）: 会社やプロジェクトを示す接頭辞（例: KYO）を必ず付け、自社で作成した要素だと明確にします。
• Business Rule: [接頭辞] [テーブル名] [処理内容] [実行タイミング]
  • 例: KYO Incident Set Caller’s Group After
• Script Include: [接頭辞] [目的や機能]
  • 例: KYO IncidentUtils, KYO UserDataHelper
• 更新セット (Update Set): [リリース名/PJ名]_[機能名]_[担当者]_[日付]
  • 例: 2025-R1_ApprovalEnhance_Suzuki_250623

2. 更新セット (Update Set) の運用ルール：安全なリリースを実現する

なぜ必要か？

開発環境から本番環境へ変更を適用する際のミスを防ぎ、安全で確実なリリースを実現するために不可欠です。誰が、何を、いつリリースしたのかを追跡可能にします。

具体的なルール例:

• Parent-Child構成の活用: 機能単位やリリース単位で親Update Setを作成し、作業者や詳細タスクごとに子Update Setを作成して管理を容易にします。
• 粒度の統一: 1つのUpdate Setには、関連性の高い変更のみを含めます。「インシデントの項目追加」と「ポータルのロゴ変更」を同じUpdate Setに入れないようにします。
• コミット（Complete）のルール:
  1. 子Update Setを開発完了後、Complete にする。
  2. 親Update Setの担当者が、すべての子Update Setをマージ（Merge）する。
  3. マージ後の親Update Setをテスト環境に移行し、テストを実施する。
  4. テスト完了後、親Update Setを Complete にし、本番移行の対象とする。

参考：

• システムアップデートセット (ServiceNow 公式ドキュメント)
• Update Set Technical Best Practices (ServiceNow Developer site)

3. Application Scopeの原則的な利用：Globalスコープを守る

なぜ必要か？

GlobalスコープはServiceNow全体の基盤です。ここを無秩序に変更すると、アプリケーション間の予期せぬ影響や、アップグレード時の問題を引き起こします。Application Scope（アプリケーションスコープ）を利用することで、開発した機能をカプセル化し、影響範囲を限定できます。

具体的なルール例:

• 新規開発はApplication Scopeで: 新しいテーブルやビジネスロジックを追加する場合は、原則として新規のApplication Scopeを作成します。
• Globalオブジェクト変更の制限: Globalスコープの既存オブジェクト（OOTBのScript Includeなど）を変更する場合は、代替手段がないか十分に検討し、変更理由をドキュメント化の上、クロスファンクショナルなチームでのレビューを必須とします。
• Cross-Scope Accessの管理: アプリケーション間のアクセス権（読み取り、書き込み、作成など）を必要最小限に設定します。

参考：

• アプリケーションスコープ (ServiceNow 公式ドキュメント)

4. スクリプティングのベストプラクティス：保守性と性能を両立させる

なぜ必要か？

非効率なスクリプトはパフォーマンス低下の最大の原因です。保守しやすく、再利用可能で、効率的なコードを書くためのルールを定めることが重要です。

具体的なルール例:

• ハードコーディングの禁止: sys_id、グループ名、選択肢の値などをスクリプトに直接記述せず、システムプロパティ (System Properties) を利用します。これにより、後から値を変更する際にスクリプトを修正する必要がなくなります。
• Script Includeへの集約: 複数の場所で利用するロジックはScript Includeにメソッドとして実装し、Business RuleやUI Actionからはそのメソッドを呼び出すだけにします。
• 効率的なクエリ: GlideRecord のループ処理の中で query() や update() を実行するのは極力避けてください。while (gr.next()) の前にクエリを完了させ、更新はループの外で updateMultiple() を使うなどの工夫をします。
• コメントの標準化: スクリプトの冒頭に、目的、機能、作成者、更新履歴などを記述するヘッダーコメントを必ず入れます。

例）Script Include

/**
 * Description: IncidentのCaller情報に基づき、関連情報を取得するユーティリティ
 * Author: Taro Suzuki (KYOSO)
 * Date: 2025-06-23
 */
var KYOincidentUtils = Class.create();
KYOincidentUtils.prototype = {
    initialize: function() {},
    
    getCallerLocation: function(callerId) {
        // ハードコーディングせず、引数で渡されたIDを利用
        var grUser = new GlideRecord('sys_user');
        if (grUser.get(callerId)) {
            return grUser.getDisplayValue('location');
        }
        return '';
    },
    
    type: 'KYOincidentUtils'
};

参考：

• Scripting Technical Best Practices (ServiceNow Developer site)

5. テストとレビューの標準化：品質はみんなで担保する

なぜ必要か？

「作って終わり」では品質は担保できません。バグやデグレード（既存機能の劣化）を防ぎ、安定したサービスを提供するために、テストとレビューのプロセスは不可欠です。

具体的なルール例:

• ピアレビューの義務化: すべての変更は、開発担当者以外の別のメンバーがレビューする「ピアレビュー」を必須とします。チェックリストを用意し、命名規則やベストプラクティスに準拠しているかを確認します。
• ATF (Automated Test Framework) の活用: 主要な業務プロセス（例: インシデントの起票からクローズまで）については、ATFでテストシナリオを作成し、自動リグレッションテストを実施します。これにより、変更による意図しない影響を早期に検知できます。
• テスト計画の作成: 新機能リリースや大規模な変更の際には、テストケースを洗い出し、正常系・異常系のテストを計画的に実施します。

参考：

• Automated Test Framework (ServiceNow Developer site)

第3章：開発標準を組織に浸透させるには？

素晴らしいルールを作っても、それが開発チームに浸透しなければ意味がありません。

1. ドキュメント化と共有: ルールはServiceNowのナレッジベースなどにまとめ、誰でもいつでも参照できるようにします。
2. 教育とトレーニング: なぜこのルールが必要なのか、その背景や目的を共有する勉強会を定期的に開催します。
3. レビュープロセスの徹底: 手間がかかってもレビューを形骸化させず、文化として根付かせることが重要です。
4. スモールスタート: 最初から完璧を目指さず、「今月は命名規則を徹底する」など、小さな成功体験を積み重ねていきましょう。

さいごに

開発ガバナンスの強化と標準策定は、短期的に見れば手間が増えるかもしれません。しかし、長期的に見れば、それは確実にServiceNowのTCO（総所有コスト）を削減し、プラットフォームの価値を最大化します。

秘伝のタレ化したインスタンスを、誰でも安心して使えるクリーンな状態に保ち、変化に強いServiceNow運用を目指しませんか？

最後まで閲覧いただき、ありがとうございました。
あなたにとって有益な情報を提供できたのであれば、大変嬉しく思います。

投稿者プロフィール

シロボシアカモエビ

2022年よりServiceNow業務に着任。案件のリードを担当しています。
以前はインフラ運用に従事していました。

保有資格
- ServiceNow Certified System Administrator
- ServiceNow Certified Application Developer
- ServiceNow Certified Implementation Specialist - Strategic Portfolio Management
- ServiceNow Certified Implementation Specialist - Application Portfolio Management
- ServiceNow Certified Implementation Specialist - Discovery

最新の投稿

• 2025-06-26技術【管理者必見】ServiceNowの技術的負債を防ぐ！ 開発ガバナンス強化と標準策定の5つの勘所
• 2023-03-06技術フォームを切り替えて、ユーザーがより使いやすい画面を提供する
• 2022-11-24技術フォーム画面を、Client Scriptで見やすくカスタマイズするには？