スキップされたすべてのレコードの手動レビューはもう不要です: 自動スキップ解決がアップグレードプロセスをどう変えるか

[JunshuO]

ServiceNow のアップグレードには常に何らかの負担が伴います。ライセンスやダウンタイムではなく、インスタンスが完全にクリーンになる前に解決・調整が必要となる、ベースシステムの変更と競合するカスタマイズされたレコード (すなわちスキップされたレコード) をレビューする、アップグレード後の作業労力です。成熟した、高度に構成されたインスタンスを持つ組織の場合、その負担はリリースサイクル全体で数百時間かかる可能性があります。自動スキップ解決は、その負担を大幅に軽減するために設計された ServiceNow の機能です。

Vancouver リリースで導入され、Xanadu で大幅に拡張された自動スキップ解決では、構成可能なルールを使用して、アップグレード、パッチ、またはホットフィックスの直後にスキップされたレコードを評価し、基準を満たすレコードに対して事前定義されたアクションを実行します。かつてはチームがスプレッドシートで作業する必要がありましたが、今では、場合によっては、真に人間の判断を必要とする少数のレコードにまで減らすことができます。

スキップされたレコードとは何ですか？

自動スキップ解決を理解するには、まずそれが解決する問題を理解することが役立ちます。ServiceNow はプラットフォームをアップグレードするときに、すぐに利用可能なレコードに変更を適用しようとします。チームがこれらのレコードの 1 つをカスタマイズしていて、ベースシステムでそれを変更しようとすると、競合が発生します。ServiceNow の解決策は、作業を上書きするのではなくレコードを「スキップ」することであり、そのスキップを、チームがレビューできるように `sys_upgrade_history_log` テーブルに記録します。

スキップされた各レコードには、P1 から P5 までの優先度が付けられます。P1 レコード (赤で表示) は最も影響度の高い競合を表し、通常はコアプラットフォーム機能が関係し、P5 レコード (緑で表示) は最もリスクが低くなります。実際には、P4 および P5 レコードはベースシステムからの軽微な追加またはメタデータの変更を表すことが多く、特定のアップグレードサイクルにおけるスキップボリュームの大部分を占める可能性があります。歴史的に、これらのレコードはすべて、人間が開いて差分を評価し、決定を下す必要がありました。

Vancouver リリース以前は、このプロセスはすべて手動でした。スキップされたレコード全体にロジックを一括で適用する体系的な方法はありませんでした。自動スキップ解決によって、この状況は一変しました。

自動スキップ解決の仕組み

自動スキップ解決は、`sys_upgrade_skipped_record_rule` テーブルに格納されている、スキップされたレコードルールと呼ばれるフレームワークを介して動作します。各ルールは条件セットとアクションを組み合わせ、アップグレードが完了するとすぐに、新しく作成されたスキップされたレコードに対してルールが自動的に実行されます。

評価フローは次のようになります。アップグレードが終了すると、アクティブな各スキップされたレコードルールが、スキップされた新しいレコードに順番に適用されます。ルールは、ノーコードクエリビルダー (最も一般的なシナリオに適しています) を使用するか、より複雑な要件のスクリプトベースのロジックを使用して条件を評価します。レコードがルールの条件に一致する場合、指定されたアクションが適用されます。このアクションは、次の 4 つのタイプのいずれかになります。

• 自分の変更を保持 ：カスタマイズを保持し、ベースシステムの変更を拒否済みとしてマークします。
• 元に戻して非アクティブのままにする ：カスタマイズをベースシステムバージョンに戻しますが、レコードは非アクティブなままにします。
• ユーザーにアサイン ：手動レビューのためにレコードを特定のユーザーまたはグループにルーティングします。
• タグを適用 ：後でフィルタリングとバッチ処理を行うためにレコードにラベルを付けます。

ルールが実行されるたびに、監査のためにスキップされたレコードにコメントが追加され、その履歴は `sys_skipped_record_rule_history` で個別に追跡されます。一致するルールがないレコードは、手動での対応が必要な「未レビュー」ステータスのままになります。ルールは [今すぐ実行] オプションを介してオンデマンドでトリガーすることもできます。これは、以前のアップグレードのレコードを遡及的に処理したり、既存のデータに対して新しいルールをテストしたりする場合に便利です。

ServiceNow には、標準のスキップされたレコードルールがプラットフォームに付属しています。Vancouver には 5 つのルールが含まれていましたが、すべてテンプレートとして非アクティブな状態で出荷されました。Xanadu は 10 件の新しいルールを追加しました。そのうち 9 件はデフォルトでアクティブになっています。これは、より有意義で成熟した自動トリアージのアプローチを反映しています。

優先フレームワーク: 自動化する対象とレビューする対象

スキップされたすべてのレコードが等しく重要になるわけではなく、P1 から P5 の優先度システムは、自動化戦略を設計するためのレンズです。P1 レコードと P2 レコードは重大な競合を表し、多くの場合、ITSM プロセス、統合、またはセキュリティ関連の構成の中心となる機能が関係しています。これらのレコードは、周囲のレコードセットがどのように処理されるかに関係なく、人間による慎重なレビューが必要です。

P3 レコードは中間点を占めます。これには意味のあるカスタマイズが含まれる場合がありますが、通常、コアプラットフォームの動作に関連付けられていません。P3 処理を自動化するかどうかは、カスタマイズの性質と関連する特定のレコードタイプによって異なります。

自動化のメリットが最も大きいP4およびP5レコードには、意味のあるカスタムロジックと競合しない新しいフィールド、更新された UI ポリシー、更新されたカタログコンテンツなどのベースシステムの追加が含まれる傾向があります。これらの優先度を対象とする、適切に練られたスキップされたレコードルールは、スキップボリュームの大部分を安全に処理できます。1 つの例では、パッチによって生成された 136 件のスキップされたレコードのうち 132 件がルールによって自動的に処理され、手動でレビューする必要があるのは 4 件のみでした。

ルールを有効にする前の重要な考慮事項

自動スキップ解決は強力なツールですが、見落とされがちなリスクが伴います。最も重要な懸念は、スキップされたレコードを「レビュー済みかつ保持済み」としてマークし、人間の注意を引くことなく事実上処理を終了させてしまう、標準ルールです。ベースシステムのアップグレードによって本当に新しい重要な機能が導入された場合、それらのレコードを自動解決するルールによって、チームが変更を完全に見逃す可能性があります。

注意点: Xanadu では、ベースシステム改善の一環として、ServiceNow がサービスカタログレコードに新しいフィールドを追加しました。これらのレコードを「レビュー済みかつ保持済み」として自動マークする OOB スキップレコードルールにより、チームはこれらの追加を完全に見逃す可能性があります。標準ルールをアクティブ化する前に、ルールが何をターゲットにし、どのようなアクションを実行するかを正確に確認してください。評価せずに無条件に有効化しても安全であるとは限りません。

さらに 2 つの誤解に直接取り組む価値があります。まず、スキップされたレコードの [解決ステータス] フィールドは追跡およびレポートフィールドです。これを変更しても、自動化されたシステムアクションはトリガーされません。情報提供のみを目的としています。次に、自動スキップ解決の「元に戻す」アクションが更新セットにキャプチャされません。開発インスタンスでカスタマイズを元に戻す場合は、その元に戻す操作を他のインスタンスで手動で繰り返す必要があります。自動的に他のインスタンスに反映されることはありません。

現在、プラットフォームに自動マージアクションが存在しないことにも注意してください。レコードがベースシステムの変更とカスタマイズを実際にマージする必要がある場合、その作業には人間の判断が必要です。プラットフォームはレコードをルーティングしてフラグを付けることができますが、マージ作業自体は手動で行う必要があります。

はじめに: 実践的なガイダンス

自動スキップ解決に初めて取り組む場合でも、既存のプラクティスを成熟させようとしている場合でも、次のガイダンスは、プラットフォームのベストプラクティスと、複数のアップグレードサイクルを経験してきた組織が苦労して得た経験の両方を反映しています。

1. 準本番環境から開始します。 最初の自動解決パスを非本番インスタンスで実行します。本番環境に昇格する前に、ルールの動作を検証し、エッジケースを観察し、更新セットで意思決定をキャプチャします。
2. 解決を開始する前に更新セットを選択します。 ServiceNow には、解決の決定をキャプチャできるビジネスルール (「解決変更時に更新セットに追加」) が含まれています。更新セットがアクティブで選択されていることを確認して、これらの決定が展開に反映されるようにします。
3. OOB ルールをアクティブ化する前にレビューしてください。 `sys_upgrade_skipped_record_rule` にある標準ルールをそれぞれ確認し、そのターゲットを理解し、アクションが環境に適切であることを確認します。ルールを全面的にではなく意図的にアクティブ化します。
4. P1 から P3 に手作業を集中させます。 実際に必要となるレコードの人間によるレビュー時間を予約します。適切に設計されたルールで P4 と P5 のボリュームを処理できるようにすることで、チームの注意が有意義な意思決定に集中します。
5. アップグレードするたびにスキップを確認します。 スキップされたレコードがリリースサイクル全体で累積されないようにします。未解決のまま放置される期間が長くなるほど、カスタマイズの本来の意図を理解することが難しくなり、解決の決定が複雑になります。
6. 環境のパターンに合わせたカスタムルールをビルドします。 OOB ルールは開始点です。時間の経過とともに、インスタンス構成に固有の低リスクスキップのカテゴリが繰り返し発生する場合は、それらを自動的に処理するルールを作成します。組織のノウハウとして、各ルールのコメントに理由を文書化してください。
7. スキップの量を経時的に追跡します。 アップグレードごとにスキップされたレコードの数が増加している場合、それはシグナルです。これはおそらく、ベースシステムで活発に進化している領域でカスタマイズが蓄積されていることを意味し、長期的な解決策は、可能な限りコードではなく構成による対応であることを意味します。

目標はすべてを自動化することではありません。それは、明白な決定を一貫して自信を持って自動化し、チームの判断が真に違いを生むところに適用することです。

これがより広範なアップグレードワークフローに適合する場所

自動スキップ解決は、プラットフォームのアップグレードを管理するための ServiceNow のエンドツーエンドフレームワークであるガイド付きアップグレードコンソール内の 1 つのフェーズです。ワークフロー全体は、計画、実行、自動解決、手動解決、追跡の 5 つのステージを経て進みます。自動スキップ解決は自動解決フェーズにあり、実行完了直後、チームが手動レビューを行う前に機能します。

その位置付けを理解することは、アップグレードサイクル全体へのアプローチ方法を形作るため、重要です。計画フェーズでは、カスタマイズよりも構成を優先することで、将来のスキップの量を事前に最小限に抑えます。実行フェーズでは、アップグレード自体が実行されます。自動解決は、低リスクのトリアージの多くを自動で処理します。手作業による解決は、真に複雑な競合に限定されるようになりましたが、不要なものが排除されたため、より速く進みます。また、トラッキングにより、ルールを改善し、将来のサイクルでスキップの量を減らすための長期的な視点が得られます。

この機能が適切に活用されることで、アップグレードプロセスはより一貫性があり、監査しやすくなり、個々のチームメンバーが大量のレコードキューを処理できるかどうかに左右されないものとなります。これまで特定の個人に属していた組織のノウハウは、ルールにエンコードされ、自動的に実行され、サイクルごとに改善されます。

これを実践する準備はできていますか？

まず、準本番インスタンスでスキップされたレコードルールを確認し、環境に適した標準ルールを評価します。アップグレードライフサイクル全体に関する詳細なガイダンスについては、 ServiceNow アップグレードセンターのドキュメント 、および Now Learning で利用可能なアップグレード管理コースをご確認ください。ご質問、またはカスタムルールパターンを以下のコメントで共有してください。

---

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/servicenow-ai-platform-blog/stop-reviewing-every-skipped-record...

免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。

This article was machine translated and replicated from the original source: https://www.servicenow.com/community/servicenow-ai-platform-blog/stop-reviewing-every-skipped-record...

[JunshuO]

ServiceNow のアップグレードには常に何らかの負担が伴います。ライセンスやダウンタイムではなく、インスタンスが完全にクリーンになる前に解決・調整が必要となる、ベースシステムの変更と競合するカスタマイズされたレコード (すなわちスキップされたレコード) をレビューする、アップグレード後の作業労力です。成熟した、高度に構成されたインスタンスを持つ組織の場合、その負担はリリースサイクル全体で数百時間かかる可能性があります。自動スキップ解決は、その負担を大幅に軽減するために設計された ServiceNow の機能です。

Vancouver リリースで導入され、Xanadu で大幅に拡張された自動スキップ解決では、構成可能なルールを使用して、アップグレード、パッチ、またはホットフィックスの直後にスキップされたレコードを評価し、基準を満たすレコードに対して事前定義されたアクションを実行します。かつてはチームがスプレッドシートで作業する必要がありましたが、今では、場合によっては、真に人間の判断を必要とする少数のレコードにまで減らすことができます。

スキップされたレコードとは何ですか？

自動スキップ解決を理解するには、まずそれが解決する問題を理解することが役立ちます。ServiceNow はプラットフォームをアップグレードするときに、すぐに利用可能なレコードに変更を適用しようとします。チームがこれらのレコードの 1 つをカスタマイズしていて、ベースシステムでそれを変更しようとすると、競合が発生します。ServiceNow の解決策は、作業を上書きするのではなくレコードを「スキップ」することであり、そのスキップを、チームがレビューできるように `sys_upgrade_history_log` テーブルに記録します。

スキップされた各レコードには、P1 から P5 までの優先度が付けられます。P1 レコード (赤で表示) は最も影響度の高い競合を表し、通常はコアプラットフォーム機能が関係し、P5 レコード (緑で表示) は最もリスクが低くなります。実際には、P4 および P5 レコードはベースシステムからの軽微な追加またはメタデータの変更を表すことが多く、特定のアップグレードサイクルにおけるスキップボリュームの大部分を占める可能性があります。歴史的に、これらのレコードはすべて、人間が開いて差分を評価し、決定を下す必要がありました。

Vancouver リリース以前は、このプロセスはすべて手動でした。スキップされたレコード全体にロジックを一括で適用する体系的な方法はありませんでした。自動スキップ解決によって、この状況は一変しました。

自動スキップ解決の仕組み

自動スキップ解決は、`sys_upgrade_skipped_record_rule` テーブルに格納されている、スキップされたレコードルールと呼ばれるフレームワークを介して動作します。各ルールは条件セットとアクションを組み合わせ、アップグレードが完了するとすぐに、新しく作成されたスキップされたレコードに対してルールが自動的に実行されます。

評価フローは次のようになります。アップグレードが終了すると、アクティブな各スキップされたレコードルールが、スキップされた新しいレコードに順番に適用されます。ルールは、ノーコードクエリビルダー (最も一般的なシナリオに適しています) を使用するか、より複雑な要件のスクリプトベースのロジックを使用して条件を評価します。レコードがルールの条件に一致する場合、指定されたアクションが適用されます。このアクションは、次の 4 つのタイプのいずれかになります。

• 自分の変更を保持 ：カスタマイズを保持し、ベースシステムの変更を拒否済みとしてマークします。
• 元に戻して非アクティブのままにする ：カスタマイズをベースシステムバージョンに戻しますが、レコードは非アクティブなままにします。
• ユーザーにアサイン ：手動レビューのためにレコードを特定のユーザーまたはグループにルーティングします。
• タグを適用 ：後でフィルタリングとバッチ処理を行うためにレコードにラベルを付けます。

ルールが実行されるたびに、監査のためにスキップされたレコードにコメントが追加され、その履歴は `sys_skipped_record_rule_history` で個別に追跡されます。一致するルールがないレコードは、手動での対応が必要な「未レビュー」ステータスのままになります。ルールは [今すぐ実行] オプションを介してオンデマンドでトリガーすることもできます。これは、以前のアップグレードのレコードを遡及的に処理したり、既存のデータに対して新しいルールをテストしたりする場合に便利です。

ServiceNow には、標準のスキップされたレコードルールがプラットフォームに付属しています。Vancouver には 5 つのルールが含まれていましたが、すべてテンプレートとして非アクティブな状態で出荷されました。Xanadu は 10 件の新しいルールを追加しました。そのうち 9 件はデフォルトでアクティブになっています。これは、より有意義で成熟した自動トリアージのアプローチを反映しています。

優先フレームワーク: 自動化する対象とレビューする対象

スキップされたすべてのレコードが等しく重要になるわけではなく、P1 から P5 の優先度システムは、自動化戦略を設計するためのレンズです。P1 レコードと P2 レコードは重大な競合を表し、多くの場合、ITSM プロセス、統合、またはセキュリティ関連の構成の中心となる機能が関係しています。これらのレコードは、周囲のレコードセットがどのように処理されるかに関係なく、人間による慎重なレビューが必要です。

P3 レコードは中間点を占めます。これには意味のあるカスタマイズが含まれる場合がありますが、通常、コアプラットフォームの動作に関連付けられていません。P3 処理を自動化するかどうかは、カスタマイズの性質と関連する特定のレコードタイプによって異なります。

自動化のメリットが最も大きいP4およびP5レコードには、意味のあるカスタムロジックと競合しない新しいフィールド、更新された UI ポリシー、更新されたカタログコンテンツなどのベースシステムの追加が含まれる傾向があります。これらの優先度を対象とする、適切に練られたスキップされたレコードルールは、スキップボリュームの大部分を安全に処理できます。1 つの例では、パッチによって生成された 136 件のスキップされたレコードのうち 132 件がルールによって自動的に処理され、手動でレビューする必要があるのは 4 件のみでした。

ルールを有効にする前の重要な考慮事項

自動スキップ解決は強力なツールですが、見落とされがちなリスクが伴います。最も重要な懸念は、スキップされたレコードを「レビュー済みかつ保持済み」としてマークし、人間の注意を引くことなく事実上処理を終了させてしまう、標準ルールです。ベースシステムのアップグレードによって本当に新しい重要な機能が導入された場合、それらのレコードを自動解決するルールによって、チームが変更を完全に見逃す可能性があります。

注意点: Xanadu では、ベースシステム改善の一環として、ServiceNow がサービスカタログレコードに新しいフィールドを追加しました。これらのレコードを「レビュー済みかつ保持済み」として自動マークする OOB スキップレコードルールにより、チームはこれらの追加を完全に見逃す可能性があります。標準ルールをアクティブ化する前に、ルールが何をターゲットにし、どのようなアクションを実行するかを正確に確認してください。評価せずに無条件に有効化しても安全であるとは限りません。

さらに 2 つの誤解に直接取り組む価値があります。まず、スキップされたレコードの [解決ステータス] フィールドは追跡およびレポートフィールドです。これを変更しても、自動化されたシステムアクションはトリガーされません。情報提供のみを目的としています。次に、自動スキップ解決の「元に戻す」アクションが更新セットにキャプチャされません。開発インスタンスでカスタマイズを元に戻す場合は、その元に戻す操作を他のインスタンスで手動で繰り返す必要があります。自動的に他のインスタンスに反映されることはありません。

現在、プラットフォームに自動マージアクションが存在しないことにも注意してください。レコードがベースシステムの変更とカスタマイズを実際にマージする必要がある場合、その作業には人間の判断が必要です。プラットフォームはレコードをルーティングしてフラグを付けることができますが、マージ作業自体は手動で行う必要があります。

はじめに: 実践的なガイダンス

自動スキップ解決に初めて取り組む場合でも、既存のプラクティスを成熟させようとしている場合でも、次のガイダンスは、プラットフォームのベストプラクティスと、複数のアップグレードサイクルを経験してきた組織が苦労して得た経験の両方を反映しています。

1. 準本番環境から開始します。 最初の自動解決パスを非本番インスタンスで実行します。本番環境に昇格する前に、ルールの動作を検証し、エッジケースを観察し、更新セットで意思決定をキャプチャします。
2. 解決を開始する前に更新セットを選択します。 ServiceNow には、解決の決定をキャプチャできるビジネスルール (「解決変更時に更新セットに追加」) が含まれています。更新セットがアクティブで選択されていることを確認して、これらの決定が展開に反映されるようにします。
3. OOB ルールをアクティブ化する前にレビューしてください。 `sys_upgrade_skipped_record_rule` にある標準ルールをそれぞれ確認し、そのターゲットを理解し、アクションが環境に適切であることを確認します。ルールを全面的にではなく意図的にアクティブ化します。
4. P1 から P3 に手作業を集中させます。 実際に必要となるレコードの人間によるレビュー時間を予約します。適切に設計されたルールで P4 と P5 のボリュームを処理できるようにすることで、チームの注意が有意義な意思決定に集中します。
5. アップグレードするたびにスキップを確認します。 スキップされたレコードがリリースサイクル全体で累積されないようにします。未解決のまま放置される期間が長くなるほど、カスタマイズの本来の意図を理解することが難しくなり、解決の決定が複雑になります。
6. 環境のパターンに合わせたカスタムルールをビルドします。 OOB ルールは開始点です。時間の経過とともに、インスタンス構成に固有の低リスクスキップのカテゴリが繰り返し発生する場合は、それらを自動的に処理するルールを作成します。組織のノウハウとして、各ルールのコメントに理由を文書化してください。
7. スキップの量を経時的に追跡します。 アップグレードごとにスキップされたレコードの数が増加している場合、それはシグナルです。これはおそらく、ベースシステムで活発に進化している領域でカスタマイズが蓄積されていることを意味し、長期的な解決策は、可能な限りコードではなく構成による対応であることを意味します。

目標はすべてを自動化することではありません。それは、明白な決定を一貫して自信を持って自動化し、チームの判断が真に違いを生むところに適用することです。

これがより広範なアップグレードワークフローに適合する場所

自動スキップ解決は、プラットフォームのアップグレードを管理するための ServiceNow のエンドツーエンドフレームワークであるガイド付きアップグレードコンソール内の 1 つのフェーズです。ワークフロー全体は、計画、実行、自動解決、手動解決、追跡の 5 つのステージを経て進みます。自動スキップ解決は自動解決フェーズにあり、実行完了直後、チームが手動レビューを行う前に機能します。

その位置付けを理解することは、アップグレードサイクル全体へのアプローチ方法を形作るため、重要です。計画フェーズでは、カスタマイズよりも構成を優先することで、将来のスキップの量を事前に最小限に抑えます。実行フェーズでは、アップグレード自体が実行されます。自動解決は、低リスクのトリアージの多くを自動で処理します。手作業による解決は、真に複雑な競合に限定されるようになりましたが、不要なものが排除されたため、より速く進みます。また、トラッキングにより、ルールを改善し、将来のサイクルでスキップの量を減らすための長期的な視点が得られます。

この機能が適切に活用されることで、アップグレードプロセスはより一貫性があり、監査しやすくなり、個々のチームメンバーが大量のレコードキューを処理できるかどうかに左右されないものとなります。これまで特定の個人に属していた組織のノウハウは、ルールにエンコードされ、自動的に実行され、サイクルごとに改善されます。

これを実践する準備はできていますか？

まず、準本番インスタンスでスキップされたレコードルールを確認し、環境に適した標準ルールを評価します。アップグレードライフサイクル全体に関する詳細なガイダンスについては、 ServiceNow アップグレードセンターのドキュメント 、および Now Learning で利用可能なアップグレード管理コースをご確認ください。ご質問、またはカスタムルールパターンを以下のコメントで共有してください。