【５年経験して考えた】ServiceNow OOTBを実例も交えて考える

本記事は、Qiita ServiceNow アドベントカレンダー2024の参加記事4日目です。

ServiceNowを構築するために大切なことって？

大切なのはServiceNowが想定する世界観、業務プロセス、フレームワークから大きく外れることなく、ビジネス価値を最大化するためにカスタマイズとコンフィグレーションのバランスを考えること。

　　
皆さんこんにちは、にわと(𝕏：@niwaniwa2wato)です。

ここ１年で「ServiceNowの導入にはOOTBが重要だ！」
という言葉を多く見るようになりました。

先日のServiceNow World Form Tokyo 2024でもOOTBの重要性を話す人が増えてきたという印象です。

日本でこれだけ言われているのでグローバルではどうでしょうか？

そう。実は、ServiceNowの利用が先行しているグローバルではカスタイマイズしたServiceNowインスタンスをOOTBへ回帰する動きは数年前からあります。

やはり、ある程度OOTBでないとServiceNowを最大限活用できず、頭打ちになってしまっていることが伺えます。

ServiceNow World Form Tokyo 2024に参加した際のレポートも書いてあります。
興味がある方は読んでいただけると嬉しいです。

今後は、いかにServiceNowをOOTBで導入し、メンテナンスコストを下げながらエージェントの効率化やユーザーエクスペリエンスの向上を図り、利用を拡大していくかを追求する必要があると考えています。

　　
ServiceNowを扱う上で「OOTBの考え方」は切っても切れないものです。
ServiceNowだからこそ描ける世界観はいくつもあり、それらは「OOTB」がベースです。
つまり「OOTBを理解し、ServiceNowが提供する価値を理解し、カスタマイズによる技術負債のバランスをとる技術」はServiceNowコンサルタントやエンジニアには必要なスキルとなってくるのです。
　　
今回はServiceNowを扱う上で、「そもそもServiceNowの理想的な活用とは何か」、「重要だと思うOOTBの考え方」や、「どのようなポイントを気を付けるべきなのか）、５年間ServiceNowにフルコミットした私の経験と考えをまとめます。

筆者の紹介

• ServiceNow開発経験５年
• １０件以上のServiceNowプロジェクトを経験
• OOTBベース～カスタマイズ重視の開発を経験
• 経験領域はITSM, ITOM, CMDB, ITAM

OOTB(Out of The Box)とは

一般的にOut of The Boxとは箱から出した状態を意味します。
つまり製品を購入してすぐ状態であり、デフォルト設定のことを指します。
ServiceNowに限らず、IT製品の一般的な用語として用いられることがありますが、ServiceNowでは特に使用されることが多いワードです。

しかしこの記事で説明せずとも、

• ServiceNow – OOTB（Out-of-the-Box）とは何か、なぜカスタマイズを避け標準を尊重すべきか
• 箱から出してそのまま使え！ServiceNow導入で学ぶ「OOTB」の重要性　日経XTECH
• OOTBベースのプロジェクトにおけるメリットと気をつけるポイント

といった記事がすでに存在しているため、ここではOOTB自体の解説は割愛しております。

もし、まだ「OOTB」とは何か知らない方は、上の記事を読むことをお勧めします。

「OOTBに合わせる」って難しい

「OOTBでの実装が重要だ」というフレーズを言うのは簡単で、実際のところ「OOTBのみで開発」ということは日本の文化的に難しい側面があります。

「そもそも日本のIT文化的に『OOTBでの実装』は難易度が高いものとなっています。ServiceNowに限らず業務パッケージを利用する際に 『パッケージが提供する機能に合わせて業務を変更する』 あるいは 『業務に合わせてパッケージをカスタマイズする』 という議論が頻発します。日本では特に後者の文化が根強いです。

実際に『OOTBに合わせて開発する』『OOTBを使い倒す』なんて標語を掲げてプロジェクトを進めているはずなのに、カスタマイズが尽きないプロジェクトなんて結構あるのではないでしょうか？

日本では『業務に合わせてパッケージをカスタマイズする』文化が根強いため、機能としてのOOTBを守るだけでは残念ながらServiceNowの価値は最大限発揮できないと考えます。後述しますが、ServiceNowのOOTBは業務プロセスの意味合いも含まれており、ここに合わせることが重要だと考えています。。

そもそも「OOTBってなに？」「何がどこまでOOTBなの？」と改めて考えて、調べてみても、実際のところ経験してみないことには分かりません。どれだけ注意しても失敗ポイントは隠れていますし、振り返ればあれは失敗だったなんてことはよくあります。

こうしたポイントは上記の記事では深く語られていないため、この記事では失敗ポイントや 「こうしておくべき」というポイント も話していこうと思います。

「OOTBに合わせる」が重要視される理由

OOTBに合わせた実装が重要視されるのは、それだけカスタマイズしたことによる技術負債の結果、メンテナンスやアップグレードの負荷が高いわりに、新機能の利用ができず、既存機能との整合性が合わず、本来の享受できるメリットを得られず、業務レベルも上がらないのが理由だと思えます。

多くのServiceNowエンジニアはServiceNowが標準で設定しているステータスやライフサイクル、アクセス制御とロールの関係性、フローの内容、果てには細かなスクリプトの動きを把握、理解し、どこを設定すれば目的の変更を達成できるか、変更に支障が起きないかを考えます。このような標準設定は経験ともに積み重なり、共通認識として理解されていきます。

つまり、ServiceNowのOOTBというのは"ServiceNowエンジニアの"共通言語"です。

この共通言語はNowLearningやNowCreate、現場経験を積むことで理解が形成されていき、一定レベルのServiceNowエンジニアとしての育成をすることができます。

ServiceNowをOOTBで実装していくと、たとえ開発リソースの入れ替えがあったとしても、キャッチアップが速く、すぐに開発・運用・保守に入れることでしょう。

しかし、カスタマイズをするというのは、この共通言語は失われていくリスクがあるということです。組織独自のカスタマイズを知るエンジニアは属人化し依存度が増加してしまいます。

これに関してはこちらの記事の解説が素晴らしいので引用させていただきます。

引用記事
ServiceNow – OOTB（Out-of-the-Box）とは何か、なぜカスタマイズを避け標準を尊重すべきか

OOTBを尊重して活用することで、特定メンバへの属人化や特定ベンダへの依存を減らすことができるためです。
　　
カスタマイズが複雑になればなるほど必要な専門知識・技術レベルが上がっていきます。しかし、ServiceNowのカスタマイズを行えるエンジニアは現状まだまだ少ないですし、ITスキルは細分化が進んでいるため、ある程度増えたとしても”ServiceNow人材”が十分に市場に供給される未来はまず来ないでしょう。その上で、自社業務に合わせて行ったカスタマイズの内容を知っている人は、世界で一人だけになる可能性が高く、そのメンバへの属人化は必至です。一方、OOTBを尊重していれば、ServiceNowのOOTBを知っている人であれば運用・保守が可能になります。
　　
外部に導入・運用・保守を委託する場合も同様で、ServiceNowのSI・インプリができるベンダはあまり多くないため、特定ベンダに依存し、システムの仕様はブラックボックス化し、高額な運用・保守費用を払い続けることになります。
　　
ServiceNowは”DX”の文脈で導入されることも多いと思いますが、これは完全に経産省のDXレポートで示されている、典型的な破滅パターンです。

私が考えるServiceNowのOOTB

「OOTBを理解し、ServiceNowが提供する価値を理解し、カスタマイズによる技術負債のバランスをとる技術」

と書きましたが、どのようにすればServiceNowの導入/利用拡大は持続的に上手くいくのか。
それはOOTBをベースにすることが正解なのでしょうか？
だとしたら、「OOTB」とは結局どこまでを指しているのでしょうか？
最近の私はこのように考えています。

OOTB = 標準機能 ＋ 業界標準の業務プロセス ＋ ServiceNowが想定する使い方

※この記事ではOOTBにフォーカスしてますが、もちろんOOTBにすれば全てが上手くいくわけではありません。OOTBには想定するペルソナやチームがありますし、ServiceNowの運用設計が考えられていることや、ステークホルダーがきちんと機能しているといった様々な要素が必要です。

標準機能

「OOTB」と言うと、特に "機能" を軸に語られることが多いです。
標準機能に対して追加の条件やルールを追加することがカスタマイズと言われていますが、
カスタマイズ＝「OOTBから外れる」という解釈は不十分だと思います。

私も１～２年目の時は「この"カスタマイズ"は良くないもの」 と考えていました。

しかし、ServiceNow界隈で著名なCHUCK TOMASI氏が以下のように述べています。

引用記事
Configuration vs. Customization? - wrong question!

「カスタイマイズという言葉を自分が経験した悪い過去をもとに、
この言葉を"ヴォルデモート"のように考えるのはやめましょう。」

「OOTBに対して変更を行う時には、変更を行うことによる影響・リスク、変更によって得られる価値、変更による将来的な技術的負債を考えて行うことが重要であり、変更を求める人たちとよく話合うことが重要です。」

つまり、カスタイマイズによる変更で高いビジネス価値を生み出せることと、メンテナンスのデメリットのバランスを考えるべきであり、なんでもカスタイマイズNGにするべきではないということです。

非常に的を得た考え方だと思います。ServiceNowは高い拡張性とカスタマイズ性を持ち合わせているため、それらを活用せずに、ビジネス価値を創出できないのであれば、それこそメリットがありません。

　　
しかし私の経験上、ビジネス価値やバランス関係なく、
そもそもよろしくないカスタイマイズだよねと思うポイントがありますので、
このあたりを解説していきます。

個人的にカスタイマイズがよくないポイント

1. システムプロパティや設定項目で変更できるのにポイント直接変更すること
2. 既存のステータスやライフサイクルを変更すること
3. OOTBで存在するフィールドやテーブルを利用せず、同じものを作成すること
4. 既存のACLを直接変更すること

1. システムプロパティや設定項目で変更できるのにポイント直接変更すること

ポータルのウィジェット系に多いのですが、OOTBのウィジェット内で不要なものがあるから、直接ウィジェットを編集して削除、もしくは表示されないように修正している、ということが度々起きています。これは古くからServiceNowを利用されているユーザーに多く、当時はOOTBの概念や日本語の情報がなかったことから、修正方法がわからず直接編集してしまったのだと推測しています。

• よくあるミス１ カタログのポータル設定を定義せずにウィジェットで消してしまうこと
  

数量や配送日時は使用しないから、ウィジェット側で消していた
ということはよくあります。

これらはコンフィグレーションで変更可能なので、そちらで設定しましょう。

　　

• よくあるミス２ ナレッジフィードバックをシステムプロパティで制御せずにウィジェットで消してしまうこと
  
  

ポータルでナレッジフィードバックを削りたいという要望の結果システムプロパティやナレッジベースで設定できることを知らずに、直接ウィジェットを変更してしまっている
ことがあります。

　　
これらはOOTBで用意された設定を知らずに直接編集してしまうことが多いので、OOTBで何ができるかは幅広く知る必要があり、各システムプロパティや設定項目がどこにあるのか、日頃から意識しておくポイントです。
これらのミスはビジネス価値もなければ、後々の技術負債に直結してしまうので避けるべきポイントだと考えています。

2. 既存のステータスやライフサイクルを変更すること

ServiceNow製品のほとんどにチケットや資産を管理するためのステータスやライフサイクルが存在します。これらのステータスはその製品が持つ機能と深く依存する点が多く、ステータスやライフサイクルの変更はかなり影響範囲が変更です。

もし、今のプロジェクトで「OOTBに合わせる」というテーマにも関わらず、ステータスやライフサイクルがビジネスと合わずに変更しようとしているなら止めるべきであり、ここは「OOTBで合わせる」べきポイントだと考えています。

3. OOTBで存在するフィールドやテーブルを利用せず、同じものを作成すること

こちらもありがちなパターンですね。
おそらく、存在していることを気づかずに作成してしまった。

あるいはフィールドであれば、参照フィールドで存在していることは理解しているけど、
そのマスタを整理する時間がないのでフリーテキストで入力できるようにしよう思い、
作成してしまったと推測しています。

前者であれば仕方がないのですが、後者は技術負債を残しがちなので、注意が必要です。

マスタを整理する時間がないので後回した分、フリー入力されたデータを次のマスタ整備にどう扱うか、これまでフリー入力でやってきて問題なかったのだから、そのままにしたい。整理したくないといった理由が出てくる可能性が高いです。

ServiceNowのOOTBのマスタテーブルの多くは、様々なServiceNow製品にも利用されるものなので、キチンと定義しておくべきでしょう。

ServiceNowを導入するにあたり、OOTBのフィールドとテーブルはどのようなものが存在していて、それは何に使われるのかきちんと検証しながら把握する必要があります。

余談ですが...。　【CSDMのFoundation Dataについて】
ServiceNowにはCSDMと呼ばれるデータを管理するためのフレームワークが存在します。会社、部門、ロケーション、コストセンターといったServiceNowの基本になるマスターテーブルをFoundation Dataと位置付けています。これらはキチンと整備せずに放置されていることが多いですが、これらのデータはServiceNowを使い初めるにあたり、最初に定義すべき重要なデータです。

4. 既存のACLを直接変更すること

「OOTBはServiceNowエンジニアの"共通言語"」と書きましたが、
OOTBのロールには決められた定義のもとACLが設定されています。

ユーザーがレコードに対してアクセスできるかどうかはライセンスにも影響するポイントになるため、過度な変更はもちろんよくありません。

また、「あのロールを付与するとコレができる」という共通言語が崩れてしまうと、過去に何故この変更がなされたのか、ドキュメント化していないと非常にメンテナンス性が悪くなるため、基本的にACLの変更非推奨だと考えています。

ACLを実装する場合、既存のACLは変更せず、新規でACLを定義しながら目的の制御を達成できるように設計すべきです。

業界標準の業務プロセス

ServiceNow製品は多くの業界標準のフレームワークを採用して構築しています。
個人的にはServiceNowのOOTBは、機能よりも業務プロセスやフレームワークの意味合いが強いと考えています。
やはり、ServiceNowが用意する機能やルール、ポリシーは業界標準のプロセスを加味したうえで、用意されてますので、ServiceNowを導入する際にOOTBのプロセスと現行とのGAPがどれだけ離れているか、それをどこまでFITさせられるように現行を変えることができるかが、ServiceNow導入成功の第一歩だと思います。

以下の記事にServiceNowのOOTBは業界プロセスでもあるということが説明されています。
私も同意見なので引用させていただきます。

引用記事
【ServiceNow – OOTB（Out-of-the-Box）とは何か、なぜカスタマイズを避け標準を尊重すべきか】

ServiceNowにおいて”OOTB”というときは、単にシステム的にカスタマイズをしていない状態を指しているのではなく、業務的な意味合いも含まれている場合が多いです。

例えば、ServiceNowのITSM（IT Service Managemento）の機能は、ITサービスマネジメントのベストプラクティス集であるITILに準拠して作られています。このように、ServiceNowの機能は基本的に業界標準の業務プロセスやフレームワークに従って業務ができるように作られているため、ServiceNowにおけるOOTBとは、「ServiceNowを購入して箱から出したばかりの、業界標準の業務プロセスに従った業務ができる状態のシステム」と定義するのがより適切だと考えます。

加えて、私は【そこから生まれるデータがServiceNowの他製品との整合性もとれる】ことがメリットになると考えています。

ServiceNowをITSMツールとして導入するだけでは費用に対する価値は僅かしかありません。ServiceNowの価値は、既存システムとの連携や、他のServiceNow製品も導入することで、ヒト・プロセス・データがServiceNowへ集約し、IT サービスと IT 運用をシングルプラットフォームで統合してサービス運用を行うと、誰もが同じ情報を同じ場所で見ることができようになる、サイロ化の打破、部分最適から全体最適へ変革することに価値があります。

ServiceNowを導入することで、おのずと他のServiceNow製品も利用することが考えられてくるので、業務プロセスはOOTBに合わせることの重要性が増します。

このプロセスやフレームワーク、具体的に言うと、

「ステータスやライフサイクルに合わせた情報を取り扱っている」

「想定されたペルソナに合わせてユーザーの役割を決め、フィールドに入力している」

「カテゴリーやサブカテゴリーなどレポート用にデータをキチンと入力している」

「インシデントをトリアージするために影響度と緊急度から重要度を割り出している」

「過去のやりとりを参照する、Now Assistが利用できるように作業メモに記録を残す」

「KPIに基づくSLAを記録している」

など上げていけばキリがありませんが、分かり易い基準を言えばNow learningやNow Createで紹介されているような部分をきちんと定義して運用できているかが「OOTBに合わせる」だと考えています。

また、上記はITSMを例にとりましたが、ITOMやITAM、SecOpsのような話になると決まった世界観とプロセスが確立されていて、それらに沿って行かなければ、中途半端な使い方になってしまうことが往々にしてあります。

実例のお話... 【それってサービス停止の危険性の可視化できなくない？】

昔ITOMのアラート管理を使用せずに、イベント管理のみで監視からインシデント作成を実現しようとしていたプロジェクトにいましたが、大量に来るイベントからインシデントになりうるものを作成するために監視サーバ側の調整やServiceNow側のカスタマイズを頑張っていました。イベント→アラート→インシデントの流れが従来と違う考え方なので、イベント→インシデントを採用したらしいですが、将来的に上のようなサービスCIにアラートが紐づかないので、アラートの可視化ができません。
こういった面からもOOTBのプロセスやフレームワークを利用しないとどこから機能で致命的に利用できなくなる可能性があります。

ServiceNowが想定する使い方

「って何ですか!? どこかに書いてあるのですか!?」
と思われている方、申し訳ございません。どこにもソースはありません...。

これは私の経験上の肌感覚なのですが、ServiceNowが想定する使い方をしていないと一部機能で効果を発揮してこないなと思う点があり、そもそも前提になる使い方があり、それを基に設計されているのではないかと最近考えています。今回は２点を解説していきます。

ServiceNowが想定する使い方をしないと危険なのでは?なポイント

1. Predicitive Intelligenceを活用するためにはレコードのShort descriptionとDescriptionにプレフィックスやテンプレートを入れてはいけない

2. リクエスト管理はREQ→RITMの概念を使用する

1.Predicitive Intelligenceを活用するためにレコードのShort descriptionとDescriptionにプレフィックスやテンプレートを入れてはいけない

「Predicitive Intelligenceって何ですか？」という方のためにちょっとだけ説明しますと、

ServiceNowが提供する機械学習ソリューションです。
過去のレコード情報の傾向を分析し、現在レコードに役立てるイメージです。
現在は分類(Classification)、類似性(Similarity)、クラスタリング(Clustering)の3つのフレームワークを提供します。

分類フレームワーク
過去のレコード処理経験に基づいて作業を自動的に分類してルーティングする機能を作成できます。例えばレコードの作成時にカテゴリフィールド値を自動で設定したい場合、簡単な説明に基づいてインシデントカテゴリを設定するように機械学習を行い、予測モデルを作成することができます。

類似性フレームワーク
類似のレコードの情報に基づいて解決策を推奨する機能を作成できます。例えば、新規インシデントをすぐ解決したい時に過去のインシデント情報を基に機械学習を行うことで、現在のインシデントに類似するインシデントを提供できるようになり、エージェントは最適な解決策を迅速にユーザーに提供できます。

クラスタリングフレームワーク
、データをグループに分割し、パターンの識別に使用できます。その後、レコードをまとめて処理したり、既存のデータのギャップを見つけたりできます。例えば、類似した新しいインシデントをグループ化して、重大な機能停止を特定できます。

回帰性フレームワーク(Regresion)は、 Washington リリースで削除されました。
既存ソリューションのトレーニング、編集はできますが、新規作成はできません。

　　
さて、一般的に利用されるケースはインシデント管理になるのですが、インシデントの書き方によってはPredicitive Intelligenceの結果がうまくいかない可能性があります。
それは、

【Short descriptionにプレフィックス文字列を入れて管理する、あるいはDescriptionに記入テンプレートを入れていることです】

※イメージ　緑色でマスキングしている部分のことを指しています。

具体的に説明していきます。

ServiceNowが想定するPredictive Intellligenceの使い方

Predicitive Intelligenceの本質は集計できない情報を基に傾向分析するソリューションです。
学習対象になるフィールドはフリーテキストであるShort descriptionやDescriptionです。

使い方イメージは
「このインシデントはメールに関するレコードだから、カテゴリーは"Email"だね。」、
「ハードウエアの故障について書かれているから、過去に同じハードウェアが壊れた時に対応したインシデントはこれだよ」 ということをしてくれるわけですね。

インシデントの作成方法やチャネルはいくつかありますが、基本的に人が手入力したものになります。

運用上分かり易くする工夫をしたために生まれた躓きポイント

しかし、あくまで傾向を分析するために参照するのは文字列なので、この文字列に上のようなソリューションに関係ない情報がある、かつ必ずすべてのレコードに含まれているようになるとそれはノイズになり学習結果に悪影響を及ぼす可能性があります。

そのノイズが"傾向"の判断ポイントだ！ということになってしまうということですね。

運用上、インシデントの件名や本文にこういったメタ情報を付加しがちなのですが、
本来こういった情報は、別のフィールドで記録すべきであり、このShort descriptionやDescriptionにはプレーンな情報を入れておくことを想定しているんだと思います。

そのすみ分けが面倒なのでなるべく集約化したいというユーザー側の思いもわかりますが、Predicitive Intelligenceがそのすみ分けをしたレコードを学習して自動化をするソリューションなんですよね。

つまりITSM導入時点で、Predictive Intelligenceを将来的に導入することを見越して、その効果を最大限発揮するために、フリーテキストの入力はテンプレートを使用せず、文章化するようにしなければいけません。ServiceNowはフリーテキストに文章テンプレートを入れることを想定していないというわけです。

インシデントをPredictive Intelligenceで分析する際に、基本的に文章が入力されてる件名や本文を使うんだけど、ここを機械的な定型分のみで記載して運用的効率化すると、大雑把に何が起きてるかは分かるけど、”何故それが起きるか”がまで分析できず、結局１つ１つ見ることになって詰む。

— にわと🐓@ServiceNowな人 (@niwaniwa2wato) October 21, 2024

ノイズ対策

ノイズは特にクラスタリングフレームワークだと顕著に表れてしまい、
クラスターの結果の文字がほぼノイズだらけになってしまうこともあります。

Predicitive Intelligenceはこういったノイズを除去するために、"ストップワード"という機能が存在します。
(,)カンマ区切りでワードを登録することで、そのワードは学習されなくなります。
ワードがある程度特定できる場合に有効であるのですが、半角記号+連番とかになると、日本語言語で処理を行う際に、上手く形態素が分けられず、ノイズ除去が上手くいかないことが多いです。

あと件名の最初にプレフィックスをつけるとノイズになる「IT-〇〇」とか「[営業0001]-〇〇」みたいな。ストップワードで排除できるけど日本言語処理の形態素は半角を理解してないから、カッコ、ハイフンなんかで繋げられると別単語扱いになる。連番なんて入れたら番号ごと別単語扱いになり詰む。

— にわと🐓@ServiceNowな人 (@niwaniwa2wato) October 21, 2024

Predictive Intelligenceで分析するために

• Short descriptionやDescriptionにはプレーンな情報のみを入力するように検討すること。
• プレフィックスに使用する"番号"や"どこの部門から来たか"、といった情報や、
  本文のテンプレート内の情報は、別のフィールドに保存しておくこと。
• 初期時点で付加されていたとしても、エージェントがそのあと整理すること。

と書いてみましたが、インシデント管理運用を開始するタイミングからPredicitive Intelligenceを始めるまでにかなり時が経っているはずので、多くのServiceNowで既に潜在的に発生している問題かもしれません。

機能からみてServiceNowが想定する使い方を考えたうえで、運用に適用する必要がありそうです。

2.リクエスト管理はREQ→RITMのアーキテクチャはそのまま使用する

ServiceNowのリクエスト管理には
「ショッピングカート」の役割のREQ(要求) レコード

「カート内のアイテム」の役割のRITM(要求アイテム) レコード

「アイテムを申請者に届けるためのタスク」の役割のSCTASK(カタログタスク) レコード

というアーキテクチャで作られています。

たまに以下のような運用をしているインスタンスを目にします。

• サービスリクエストしか想定しないので、1リクエスト１アイテムになります。
• REQ→RITMだとエージェントやユーザーが混乱するので、RITMだけ見せるようにポータルの作りをカスタマイズ

この作りだとNow Mobileを利用するときに躓きポイントが発生します。

　　
Now Mobileでカタログをリクエストすると、画像のようにREQ番号が表示されます。

　　
残念ながらNow Mobileは細かなカスタマイズを行うことができない機能であり、この画面も同様にカスタマイズができないため、この画面の表示をREQ→RITMに変更することができません。また、この画面を飛ばすこともできません。

　　
「ユーザーにREQ番号は表示してないので、MobileでREQ番号が表示されるのは困る」
とのことでしたが、Now Mobile側では変更できません。

　　
リクエスト管理はそのアーキテクチャをベースにポータルやモバイル、カタログの標準が作られているので、OOTBの流れを変更すると、Now Mobileとの整合性が取れない可能性あります。

まとめ

ServiceNowの導入と運用において、OOTB（Out-of-the-Box）の活用は非常に重要です。
改めてになりますが、他記事にもある通りOOTBを尊重することのメリットは以下になります。

• 特定のメンバーへの依存を減らし、メンテナンスコストを抑えられること
• バージョンアップの検証工数を削減できること
• 業界標準プロセスに合わせることで、すぐに利用を開始でき、検討の時間を削減できること
• 躓きポイントを減らし、他機能との整合性を合わせられること

一方で、カスタマイズは絶対的に避けるものではなく、ビジネス価値を最大化するために必要な変更をバランス良く行うことが重要です。

しかし、以下のような極力避けるべきカスタマイズも存在します。

避けるべきカスタマイズ

• システムプロパティや設定項目で変更できるのにポイント直接変更すること
• 既存のステータスやライフサイクルを変更すること
• OOTBで存在するフィールドやテーブルを利用せず、同じものを作成すること
• 既存のACLを直接変更すること

また、OOTBのプロセスやアーキテクチャに従わないと、製品や機能のどこかで整合性が取れなくなる可能性があります。

ServiceNowが想定する使い方

• OOTBには「業界標準のプロセス」の意味合いが含まれており、ServiceNow製品同士の整合性が取れるようにできている
• Short DescriptionやDescriptionにはフリーテキストを入力し、メタ情報は別のフィールドに分ける
• リクエスト管理のアーキテクチャはそのまま使用する

ここで紹介する想定する使い方ほんの一部です。

　　
今後、ServiceNowを活用する上で、OOTBに基づく開発の重要性はますます高まると考えられます。正しいOOTBの理解によってServiceNowのメンテナンスや運用、利用拡大の成果は大きく異なります。

　　
大切なのはOOTBの理解とカスタマイズのバランスを取るスキルを磨くことであり、
ServiceNowが持つ本来の価値を最大限に引き出しユーザーへ還元することです。

　　

---

最後まで読んでいただき本当にありがとうございました!!

ここまで読んでいただけた方はいいねとストックよろしくお願いします。
𝕏：@niwaniwa2watoをフォローいただけると嬉しく思います。