Zenn
😎

ServiceNow概論

2024/12/22に公開
ServiceNow
tech
この記事はServiceNow Advent Calendar 2024シリーズ 2 22日目の記事です

こんにちは。ServiceNowのデビューリリースがGenevaな老人会方面の者です。(関わり初めて8~9年目くらい？)

今回アドベンドカレンダー向けの記事は書く予定は無かったのですが、先日のSNUG(ServiceNow User Group)でServiceNowデザイン靴下をもらってしまったのでこの記事を書くことにしました。モチベーションって大切ですね。Manarobotさんありがとうございました。

さて、何を書くか悩んでいたのですがServiceNow Advent Calendar 2024のレギュレーションによると「ポエム」も許容されていたので老人会ならではのポエムを書いてみようと思います。

それでは主観100%のポエムになります。よろしくお願いします。

ServiceNowとは

ServiceNowとは何か

最近またこの話を聞くことが増えた気がします。
「ITSMのツールだ！」とか「社内のサービスを画一的なエクスペリエンスで提供してエンゲージを高められるものだ！」とか色々な尺度で色々なキーワードが出てきていると思います。
それだけ広範に使われているもので、関わり方によって見え方や位置付けが変わるものなんだという理解でいるので何ら違和感がないのです。

そもそもの成り立ち（歴史）

そもそも論になるのですが、ServiceNowの成り立ちの話になります。
ServiceNowの創始者はFred Luddy。
zdnetの記事 「自分とは違う世界を知る人」が会社を変える--49歳で起業、ServiceNowの創業者に記事がありました。

無料で読める範囲だけざっくりまとめると以下になると思います

  • 既存のITサービス管理ツールの複雑さと非効率性に不満を感じていた
  • クラウドベースで使いやすいソリューションを提供したいと考えた
  • ワークフローを構築するためのシンプルなPlaftormの「Now Platform」を作った
  • ITサポートにフォーカスすることで市場に受け入れられた

昔聞いた話と符合したので個人的に違和感はない話でした。昔聞いていた話は以下です

  • そもそもITSMのツールを作りたいのではなく、Plaftormを作りたかった
  • しかしいきなりPlaftormを作っても使い方がわからないし売れないよねと言われた
  • そこで経験のあるITSMのツールをPlaftormの上で実際に構築して販売を始めた

つまりそもそもServiceNowはPlaftormという理解です。
そのため前述した以下の話のときに「そもそもそういうものだ」という理解で違和感がなかったのです。

最近またこの話を聞くことが増えた気がします。
「ITSMのツールだ！」とか「社内のサービスを画一的なエクスペリエンスで提供してエンゲージを高められるものだ！」とか色々な尺度で色々なキーワードが出てきていると思います。
それだけ広範に使われているもので、関わり方によって見え方や位置付けが変わるものなんだという理解でいるので何ら違和感がないのです。

だってPlaftormなんだもん。その上で実装するアプリケーションによってどうとでも使えますよね。
それだけ汎用性の高いPlaftormであるといえるのだと思います。

ServiceNowが日本に入ってきた頃〜初期の少数で拡販していた頃を思い出してみる

記憶を頼りに書いてみました。
2013〜2016年くらいのお話だと思います。
ソースが無い部分や仮説も含まれますがご了承下さい。

  • 日本に入ってきたのは2012 ~ 2013年頃に日立ソリューションズさんが日本で販売を始めた記憶
    • IaaSですがAWSで東京リージョンが開設されたのが2011年なので日本ではまだまだクラウドやSaaS、PaaS、IaaSなどAs A Serviceの知名度はそこまで高くなかった印象
      • メールマガジン配信や予約システムなどASPサービスが使われていた時代
  • スクラッチでアプリケーションを開発することが一般的だった時代からSaaS/PaaS時代にちょうど変わるタイミングを捉えていた
    • LAMP環境だったり.netやJavaだったりでオープン化していた2000年代
    • As A Serviceが台頭してきた2010年代
      • 遅すぎず早すぎず絶妙に先行者利益を取れるタイミングだったのでは
  • ユースケースの訴求方法
    • Notesの移行先として拡販していた
      • 実際にNotesの移行先として導入されるケースも多かった
    • ITSMツールやITOM、GRCなど社内の生産性とガバナンスを高めるツール郡がメイン商材
      • 某営業支援SaaSのように特定業務やプロセスをユースケースとしてアピールできたことで受け入れられやすかったのでは
      • スクラッチ開発していたものが製品に置き換えられるチャンスとなっていた
  • プラットフォームとしての思想と拡張性と導入事例

今日の成功は入ってきたタイミングとユースケース、各社の事例など様々な要因が絶妙に噛み合っていた結果なんだと感じています

OOTBとの付き合い方

話はかわりますが、「OOTBのカスタマイズは極力避けて。」という話も最近改めて聞くようになりました。
折角なのでちょっと触れてみようと思います。

「OOTBのカスタマイズを極力避けて。」の考え方は正しいと思っています。

OOTBとはNow Platform上に提供される製品用フレームワークとでも言えば良いでしょうか。
例えばITSMを契約するとITSM用プラグインによってテーブルやUI、Scriptやプロセスがインストールされる。という具合です。
そのままでも動く状態で提供されますが、「業務へFitしない」や、「もっとこうしたい！」の気持ちによってカスタマイズ沼にハマって行きます。

カスタマイズについての考え方

なぜ避けるのか

なぜカスタマイズを避けるかと言うと、私は「バージョンアップのときに死ぬから」という見解です。
バージョンアップをすることなく、ずっと固定のバージョンで使い続けられるのでしたらどんなにカスタマイズを行っても良いとさえ考えます。
しかし現実はそうもいきません。毎月のマイナーバージョンアップと、半年に一回のメジャーバージョンアップがあります。残酷なものです。

どこからがカスタマイズなのか

実はこれを明確に定義して語っている方とお会いしたことはなかったように記憶しています。
私の定義だと「update setに記録されること」がカスタマイズです。

変更をしてもupdate setに記録されないこともあります。
それはカスタマイズではなく「設定変更」やという表現になって許容される認識です。
ブランディングやデザイン系に多く、例えば以下が思い当たります

  • 色の変更
  • ロゴの変更

なぜupdate setにのらない変更は許容されるのか

なぜカスタマイズを避けるかと言うと、私は「バージョンアップのときに死ぬから」という見解です。

ここに終始します。

極端な話としてServiceNowのバージョンアップもユーザの実施した変更もNow Platformの機能の一つであるupdate setが活用されます。

Gitの考え方に置き換えると以下になり、別ブランチでそれぞれ同じファイルに対して変更のcommitが発生するためコンフリクトするイメージです

  • ServiceNow社のブランチにあるcommitがmasterへ
    • バージョンアップ時に発生
  • ユーザのブランチにあるcommmitがmasterへ
    • 初期導入や日頃のメンテンナス/エンハンスで発生

つまりここのコンフリクトを避けることができるとバージョンアップ時に死なない。

なぜカスタマイズを避けるかと言うと、私は「バージョンアップのときに死ぬから」という見解です。

これがクリアされます。

バージョンアップ時に死なない範囲であればカスタマイズしても構わない。

バージョンアップをすることなく、ずっと固定のバージョンで使い続けられるのでしたらどんなにカスタマイズを行っても良いとさえ考えます。

ここの考え方にも近くなります。

Gitの考え方に置き換えると以下になり、別ブランチでそれぞれ同じファイルに対して変更のcommitが発生するためコンフリクトするイメージです

update setに残る変更はブランチでのcommitに近いものと考えると「ServiceNow社が変更する可能性があるファイルは変更しない」というのが今持ち合わせている一つの解です。

ServiceNow社が変更する可能性があるファイルは変更しないとは

OOTBで提供されているmoduleには手を入れない。ということです。
しかし業務にFitできるようにする必要はある。
ここで前述していたPlatformである。という話が活きてきます。

Now Platformの特性として前述していました以下が関わってきます

  • 拡張性も高く「なんでもやれる」と思われていた（銀の弾丸ではないがそう思われる傾向はあった）
    * データCRUDに応じてプロセスを起動できる
    * 1つのテーブルに対してn個のViewを定義できる
    * 完全オリジナルのページを定義して組み込むことができる

例えば以下が思い当たります

  • フォームに見せたい項目と見せたくない項目が混在している
    • 自社用のViewを定義して、そちらを目的の状態にカスタマイズするとOOTBは触らないで目的のViewを提供できる
  • データの処理でOOTBの処理に追加したい処理がある
    • Business Ruleを新規に追加して任意の処理に組み込むことで達成できるのでは

そうです。可能な限り「ServiceNow社が変更しない（知らない）」部分で任意に作り込んでいくことでバージョンアップで死ぬことが無いと考えています。
この範囲でしたらPlatformを活用しつつゴリゴリ業務Fitさせていくことに抵抗はないです。

しかし上記ではどうしても達成できない部分もあるかと思います。
考え方の順番として私は以下で考えています

  • それは本当に必要なことか
    • 本当に実現しないとだめなこと？（nice to haveの割に負債大きくないですか？含む）
    • ServiceNowでやるべきか（別のシステムや仕組みで実現したほうが筋が良くないですか？含む）
  • Platformの機能や仕組みを使って実現できないか
  • 最終手段としてOOTBのカスタマイズ

ここまで考えてもどうしても必要ならばやるで仕方ないと思います。
後々のメンテンナンスなど考えると最小限に留めておきたいものです。

まとめ

ServiceNowはとてもリッチなPlatformだと思います。
しかし実際の開発や運用など日々の業務では「各moduleの業務Fitと課題解決」という取り組みになり、「Platformの活用」という側面や「Platformの理解」を後周しにしてしまうことがあったりするのではないでしょうか。
それを理解するには機能として使える部分だけではなく、根底にある思想や想いの部分を少しでも知ることで理解が深まるのではと感じて「Service Now概論」として書いてみました。
当時の記憶など不確かな情報ソースも多々あります。冒頭にも書きました通り

それでは主観100%のポエムになります。よろしくお願いします。

ご了承ください。

そしてATFやデザインフレームワークなど、Plafrotmも進化を続けています。
急がば回れ。ではないですが、たまには手を休めて根本にあるServiceNowのPlatformに目をやりキャッチアップするというのも必要なのではと感じています。

Discussion