ServiceNowについて調べるとよく出てくる、OOTB（Out-of-the-Box）という言葉について、その意味と、なぜOOTBが重要なのかを解説します。
OOTB（Out-of-theBox）とは何か
ServiceNowにおけるOOTBとは、ServiceNowを購入して箱から出したばかりの、業界標準の業務プロセスに従った業務ができる状態のシステムのことです。
OOTB（Out-of-theBox）= OOB = 標準 = ベースライン = バニラ
OOTBとはOut-of-the-Boxの略で、購入して箱から出したばかりのカスタマイズが加えられていない状態のことです。OOBと略されることもありますが、同じ意味です。より一般的な言い方だと、標準（機能）やベースライン（機能）と言われることもあります。頻度は低いですが、アイスクリームの標準的な味がバニラ味であることに例え、バニラと呼ぶこともあります。
なお、これらの表現は全てServiceNow固有の表現ではなく、SAPなどの他のッケージ製品でも使われることがあります。
開発を行った状態と比較してのOOTB
家電製品のように箱から出してそのまま使うのが当たり前の製品であれば、あえて”OOTB”という言葉を使う必要はありません。しかし、ServiceNowの場合は、標準機能に対して何らかのカスタマイズが加えられることが多いため、カスタマイズを行った状態と比較してOOTBという言葉がよく使われているのです。
なお、ServiveNowにおけるカスタマイズ = 開発とは何かについては下記の記事で解説していますので、ぜひご覧ください。
なお、デフォルトタイムゾーンを日本時間に設定するといった最低限の初期設定をカスタマイズと呼ぶのか、といったことを考え出すと、OOTBの定義は意外と難しいのですが、これは上述の記事でも述べているConfiguration（設定）Customization（カスタマイズ）を定義することと同じようにあまり意味がないため、ここでは深堀りしません。
OOTBには業務的な意味も含まれる
ServiceNowにおいて”OOTB”というときは、単にシステム的にカスタマイズをしていない状態を指しているのではなく、業務的な意味合いも含まれている場合が多いです。
例えば、ServiceNowのITSM（IT Service Managemento）の機能は、ITサービスマネジメントのベストプラクティス集であるITILに準拠して作られています。このように、ServiceNowの機能は基本的に業界標準の業務プロセスやフレームワークに従って業務ができるように作られているため、ServiceNowにおけるOOTBとは、「ServiceNowを購入して箱から出したばかりの、業界標準の業務プロセスに従った業務ができる状態のシステム」と定義するのがより適切だと考えます。
なぜカスタマイズを避けOOTBのまま使うことが重要か
ServiceNowでは、可能な限りOOTBを尊重して活用する、つまりカスタマイズを可能な限り避けることが推奨されています。この理由について説明します。
業界標準の業務プロセスに合わせられる
一つ目の理由は、OOTBを尊重して活用することで、自社の業務プロセスをグローバルスタンダードの業務プロセスに合わせることができるためです。
ServiceNowの決して安くはないライセンス費用を出せるような日本企業は大抵は大企業です。そして、その業務プロセスはグローバルスタンダードとはかけ離れた、継ぎ足し継ぎ足しの秘伝のタレ状態の複雑で冗長な業務プロセスになっていることが多いです。
担当者が継ぎ足し継ぎ足しで都合よく作ってきた業務プロセスと、頭のいい人たちが寄ってたかって考えた業務プロセスやフレームワーク、どちらが優れているかは明らかです。ServiceNowを選定したのであれば、業務プロセスを変革する（BPRの）いい機会と捉え、OOTBに自社業務を合わせることを検討すべきです。自分たちの業務プロセスを変える気がないのであれば、初めから日本企業の求める機能が存在する、日本のベンダの製品を使う方が幸せになれます。
また、日本と比べ欧米では人材流動性が高いことで有名ですが、この一因として、”標準化の意識が高い”ことが挙げられます。同じような業務がどこの会社でも同じようなプロセスで実現されていれば、前職のスキルがそのまま生かせますし、キャッチアップが容易になるため、人材の流動がスムーズになります。これは業界内でのノウハウや技術の共有・競争を生み、業界全体によい影響を及ぼすでしょう。なお、”独自性”はとても大事ですが、それはコア事業で大事なのであり、ServiceNowがカバーする”社内業務”の領域では必要ありません。
素早く導入の価値を出せる・価値にフォーカスできる
二つ目の理由は、OOTBを尊重して活用することで、素早く導入の価値を出せる、もしくは価値にフォーカスができるためです。
継ぎ足し継ぎ足しの秘伝のタレ状態の複雑で冗長な業務プロセスに合わせてServiceNowをカスタマイズしていると、導入だけで年単位の期間や、ライセンス費用数年分の開発コストがかかることも珍しくありません。
一方で、完全にOOTBに従う場合、導入1日目から使い始めることができます。私が最も上手にServiceNowを導入したなと思っているある日本企業は、導入1日目からITSM機能のOOTBに従い活用をはじめ、使いながら標準に合わせて自分たちの業務を改善していこうとしていました。彼らは既存業務や既存システムとServiceNow標準とのギャップをどう埋めるかという何の価値も生み出さない活動ではなく、常に電話対応に追われる現状から、チケットをセルフサービスで切ってもらう状態に変え、最終的にはナレッジを公開し自分たちで問題を解決してもらうためにどうしたらよいか、といったことを考える活動に多くの時間を割いていました。
運用・保守が必要になる、サポートが受けられない場合も
ServiceNowを始めとして、パッケージ製品を使うメリットとして、システムの保守をベンダー側に任せられるというのがあります。しかし、カスタマイズを行ってしまうと、その機能については自社で保守しなければならなくなります。そうなると、次のようなデメリットが発生します。
サポートが受けられない
OOTBをカスタマイズした場合、程度にもよりますが、コーディングを伴うビジネスロジックを変更するようなカスタマイズを行った場合、その部分はサポート対象外となります。
バージョンアップのたびにリグレッションテストが必要
ServiceNowは半年に一度新しいバージョンがリリースされ、2つ前のバージョンまでしかサポートしていないため、最低でも2バージョンおき=1年に1度のバージョンアップが必要です。バージョンアップの際には、カスタマイズした機能のリグレッションテストが必要になります。
バージョンアップについては次の記事も併せて参照ください。
ドキュメント管理が必要
ServiceNowのOOTBの仕様は公式のドキュメントで確認することができるため、わざわざ導入した企業側でドキュメントを起こす必要はありません。
しかし、カスタマイズを行った場合、その部分については何らかのドキュメントを残しておかないと運用・保守ができないので、（記載の粒度は現場によって大きく異なるが）設計書等のドキュメントを残すことが多いです。この作成やメンテナンスが必要になります。
特定メンバへの属人化や特定ベンダへの依存を減らすことができる
三つ目の理由は、OOTBを尊重して活用することで、特定メンバへの属人化や特定ベンダへの依存を減らすことができるためです。
カスタマイズが複雑になればなるほど必要な専門知識・技術レベルが上がっていきます。しかし、ServiceNowのカスタマイズを行えるエンジニアは現状まだまだ少ないですし、ITスキルは細分化が進んでいるため、ある程度増えたとしても”ServiceNow人材”が十分に市場に供給される未来はまず来ないでしょう。その上で、自社業務に合わせて行ったカスタマイズの内容を知っている人は、世界で一人だけになる可能性が高く、そのメンバへの属人化は必至です。一方、OOTBを尊重していれば、ServiceNowのOOTBを知っている人であれば運用・保守が可能になります。
外部に導入・運用・保守を委託する場合も同様で、ServiceNowのSI・インプリができるベンダはあまり多くないため、特定ベンダに依存し、システムの仕様はブラックボックス化し、高額な運用・保守費用を払い続けることになります。
ServiceNowは”DX”の文脈で導入されることも多いと思いますが、これは完全に経産省のDXレポートで示されている、典型的な破滅パターンです。
OOTBを尊重するためのマインドセット
最後に、OOTBを尊重するために、導入する企業や、導入担当者、エンジニアがどのようなマインドセットを持っているか・持つべきかを紹介します。
以上です。
コメント