カスタマイズ vs 構成 | FAQ とガイドラインIssue 以下の情報は、カスタマイズと構成の違いを概説し、それぞれに関する情報とガイドラインを提供します。ServiceNow のカスタマイズのベストプラクティスの詳細については、ページ下部の Now Create へのリンクを参照してください。 カスタマイズとは何か ? ServiceNow では、カスタマイズという用語は、あらゆる形式のカスタム機能に対するビジネスニーズを指すために使用されます。 構成とは? 構成とは、インスタンスのベースラインインストールの一部であるコードを変更せずに、要件を満たすように ServiceNow のベストプラクティスや API を使用してインスタンスを調整することを意味します。 構成には、フォームやテーブル拡張を変更するなどして、カスタムのビジネスニーズに安全かつサポート可能な方法で実現できる Now Platform の機能や特徴が含まれます。過剰なフォームや UI ポリシーを追加するなど、過剰な構成は避ける必要がありますが、ビジネスデマンドを満たすための最初のオプションまたは優先オプションとして構成を使用する必要があります。 カスタム開発とは? これには、ServiceNow アプリケーションと、ベースライン ビジネス ルールを変更して開発する新しいアプリケーション、またはテーブル拡張から新しいアプリケーションを開発する新しいアプリケーションの両方のカスタム開発が含まれます。カスタム開発は、構成が新しいビジネス ニーズに対応できない場合に推奨されます。カスタム開発では、一貫性のある推奨ツールと方法を採用し、明確で効果的なガバナンスによって監視する必要があります。 例:構成とカスタム開発 構成の例： インシデントを重大なインシデントに昇格させる前に、[Business impact] を必須フィールドにする必要があります。指定しない場合、レコードは更新されません。UI ポリシーは、特定の要件を満たすように特定の機能を調整するためのプラットフォーム内の多くのツールの 1 つであり、この要件を満たすために使用できます。 カスタム開発の例: サービスカタログの実装中に、カタログのチェックアウトページにデータ収集用のフィールドを追加する場合。カタログチェックアウトページは、インスタンスのベースラインインストールの一部であるサービスポータルウィジェットです。このコードへの変更は、カスタム開発と見なされます。誰かが新しい「カスタム」機能 (カスタムアプリケーション、サードパーティのウィジェットなど) を製品に組み込む場合。ServiceNow サポートはトラブルシューティングのガイダンスを提供するが、機能の管理と修復については顧客が責任を持つ。Factsベースラインインストールの一部であるコードをカスタマイズする場合 コードはベースラインインストールの一部であり、それがカスタマイズされると、以下が起こります。 今後そのコードを自身で維持(メンテナンス)する必要があります。アップグレード後も正常に機能することを自身で確認する必要があります。 カスタマイズに関するサポートは受けられますか？ はい、カスタマイズのサポートは引き続き受けられます。ただし、サポートコール中に、行われたカスタマイズが問題の原因であると判断された場合、サポート チームは、サポートチームがサポートできるように、ベースラインインストールの一部であったコードに戻すようにアドバイスします。 カスタマイズを実行するとどのような影響がありますか？ ServiceNow のプラットフォームは非常に柔軟で、幅広い要件を満たすことができます。ServiceNow のプラットフォームでは、さまざまなアプリケーションのタスクの処理、複数のブラウザーでのフォームのレンダリング、全体的なユーザーエクスペリエンスをサポートするフレームワークを使用しています。 ServiceNow は、一貫した方法で開発およびサポートを提供するために、フレームワークの完全性に依存しています。要件や機能拡張のアイデアがある場合は、拡張要求を ServiceNow 開発チームに送信できます。要求は個々に審査され、承認された場合は将来のリリースに組み込まれます。Release 全てのリリースResolution ガイドライン カスタマイズの実施を決定する前に、カスタマイズの内容とそれがどのような影響を与える可能性があるかを理解しておくことが重要です。 必要に応じてベースラインオブジェクトをカスタマイズして、更新時に問題解決や意思決定について適切に記録できるようにする必要があります。カスタマイズの内容を明確にしておかないと、将来のアセスメントで元に戻したり統合したりする必要が生じたときに、管理者が更新を見落とす可能性があります。 カスタマイズが必要な場合は、次のプロセスに従う必要があります。 ビジネスに配慮したカスタマイズアプローチ (以下のリンク) を確立して、カスタマイズが限定され、ビジネス価値に明確にリンクされるようにする。オブジェクトのコピーを避ける – 代わりに、Service Portal ウィジェットや再利用を目的として設計されたその他のアイテムを除くオブジェクトを、可能な限り更新します。デフォルトで編集前に追加する – たとえば、既存のフィールドのタイプを変更するのではなく、フォームにフィールドを追加する必要があります。追加するときは、OOTB のオブジェクト、メソッド、またはクラスと同じ名前を使用しないでください。追加するフィールドの数を最小限に抑えます。フォームのフィールド数が多くなると、ロードに時間がかかる場合があります。スコープ対象のアプリケーションを新しいカスタム開発のデフォルトとして使用します。何がどのような理由でカスタマイズされたのかを明確に文書化することで、将来のメンテナンスが大幅に容易になります。 管理者は、アップグレード後に、実施されたカスタマイズが機能することを確認し、カスタマイズの内容を追跡する責任を負います。Related LinksServiceNow カスタマイズのベストプラクティスに関する PDF ガイドは、Now Create にあります。 ビジネススパートなカスタマイズ このドキュメントでは、ServiceNow のビジネスに適したカスタマイズに焦点を当て、カスタマイズの価値をリスクと技術的負債に照らして評価することの重要性を強調しています。価値主導型の方法でカスタマイズを実装するための包括的なガイドを提供し、アップグレードとプラットフォームのパフォーマンスが悪影響を受けないようにします。