ServiceNowAdvent Calendar 2024

うまくいくServiceNow、うまくいかないServiceNow

ServiceNow

Last updated at 2024-12-10Posted at 2024-12-10

導入

みなさん。DXしてますか？

Who are you？

わたしは、新卒ではiPhoneアプリ開発者だったのですが、Python、Rails、DelphiとIT業界をたゆたいながら、2019年3月よりServiceNowにかかわりはじめたエンジニア (＆コンサルタント＆プリセールス＆アーキテクト＆ Part of Service Desk) です。

本稿の目的

自身の経験から「こういう案件うまくいったな、いやぁだめだったな」という切り口でServiceNowを論じてみたく思いました。なお切り口（観点）はプリセールス、導入コンサル、ユーザ目線です。
技術記事を書いてもいいのですが、漠然としたところを語りながら総括したくなったので、少しだけお付き合いください。
Disclaimer：※本投稿は個人の見解であり、所属集団を代表するものではありません。

ServiceNow導入ＰＪにおける役割定義

上記に述べましたエンジニア、コンサル、プリセールスなどの役割について、いったん言葉の認識合わせをします。

プリセールス(技術営業)

ServiceNowの導入前段階で、顧客の業務課題を分析し、最適なソリューション提案を行う営業専門職。技術的知識と提案力を駆使し、顧客のデジタル変革ニーズを的確に捉え、ServiceNowの導入メリットを説明する役割を担う。

導入コンサル(≒コンサル、アーキテクト、エンジニア、ＰＧ)

ServiceNowの実装を支援する専門家。顧客の業務プロセスを深く理解し、プラットフォームのカスタマイズ、システム統合、ワークフロー設計を行う。技術的専門性と業務知識を活かし、顧客の具体的な要件に最適化されたソリューションを構築する。

ユーザー(Service Desk)

ServiceNowを日常的に利用する実際の業務担当者。企業内の各部門で働く従業員で、プラットフォームを通じて業務タスク、申請、承認、情報共有などを行う。システムの使いやすさ、効率性が彼らの生産性に直接影響する。大企業の情シスやＤＸ部門の担当者やその配下にある運用者を指す。

ServiceNow導入の成功と失敗

以下は具体的な成功PJと失敗PJを振り返りながら、何がよかったか、よくなかったかの要素を考えていきます。 ※わたしは、ご提案自体は10本ぐらい書き、そのうち3本は受注したぐらいのペーペープリセールスです。あくまで本業はデリバリーであり、デリバリーは15件ぐらいはかかわっているような気がしています。　
※プリセールスの場合は、ロードマップ、スコープ、体制、工数算出といった基本的なことはすでに実施していることを前提とします。
※導入コンサルの場合は、Now Createが提案する標準的な製品導入アプローチに準拠することを前提とします。

視点	うまくいく例	うまくいかない例
プリセールス	1. 予算範囲のご提案 2. 初手Demo。Demo≒具体仮説 3. 広がった風呂敷を正しくたたむ	1. 予算超過のご提案 2. できます！の理屈が見えない 3. Value訴求ばかり多い
導入コンサル	1.同じ方向を向くProduct開発 2. 要件は抽象から段階的に解像度をあげること 3. 結局データベースだからER図と項目とマスタきめること 4.むりなものはむりだとわりきること（OOTBの限界をしる）	1. 「私考える人、あなたつくる人」 2. 要件をいきなり具体にすること。問題解決思考に走りがち 3. 結局データベースなのにERと項目とマスタと処理を考えない 4.むりなものがむりと判別できない（Platformの理解度）
ユーザー	1. 業務プロセスの効率化・自動化 2. 使いやすいUIUX 3. 権限管理がシンプル 4.一緒に仕事した人を成功させる	1. 手書き作業が多い 2. どこ操作すればいいかわからない 3. 権限管理が複雑 4.「できた」で終わる

詳細

表形式にまとめましたが、以下に思うところを書いていきます。

プリセールス

(1)予算

まず予算超過の提案は中々通らないです。そんな提案もってくるなよって相手も思っているのだろうなと思いますが、大人の都合でそういうお値段になるときもあります。ロードマップとスコープを適切に割ってから、実現可能性を高めて、お手頃価格としたいものですね。全体が見えない中での適切な工数算出は、まさにIT：Pre-salesの腕の見せ所ともいえますね。

(2)初手、Demo：プロダクト中心主義

実施内容

・依頼内容を受けて、最初の打ち合わせにデモを持っていく
・デモで実現できたこと・実現できそうなことをベースに相手のイメージを詳細していく
すべての案件ではないですが、なるべく早い段階で動くものは持っていきます。デモの内容があっている、あっていないは曲論どうでもいいのですが、デモに対して相手から反応が得られます。それに対して「ここがイメージに合うね、あわないね」という会話が具体的に進めていきます。その反応をもとに提案を精緻化していきます。

狙い・メリット

・最初から最後まで動くプロダクトをベースに進める
・コミュニケーションが空中戦になりにくい
・インクリメントに集中することができる
・とんでもないものが出来上がるリスク低下

(3)広がった風呂敷を正しくたたむ

導入会社に話が及んでくる場合というのは、おおむねServiceNowのAEさんによる初回商談(1st call Deck)は実施済みの場合が多いです。AEさんがやるのは「ServiceNowってこういうことができます、いいでしょ！！」という価値訴求・ServiceNowの世界観を伝えることだと認識しています。つまりServiceNowすごい！と「風呂敷が広がった状態」になります。
これはこれでいいのですが、やはり「でも実際の導入時はどうなの？難しいんじゃないの？」とお客様は具体には半信半疑の状態です。そこで技術ができることは「広がった風呂敷を正しくたたむこと」です。CSDMという概念モデルだったり、ITSMとCMDBの結合、プロセスとWFの統合、データドリブンといったVisionに対する実際の当て込み、価値実現ロードマップ、実現可否（PoC含む）をすることによって、理想と現実の折り合いをつけることです。このたたみ方がコンサル・SI各社の腕の見せ所なのかな、と最近思いました。

導入コンサル

(1)「私考える人、あなたつくる人」問題

・プロダクトオーナー（発注側）も答えを知らない
・仕事を進めるために、わからないけどとりあえず決める
・繰り返すことで慣れていく
・「私考える人、あなたつくる人」問題が出来上がる

こういう関係（主従関係）が出来上がると、PJはうまくいきにくいです。わたしたちはパートナーとしてふるまうべきです。パートナー関係とは、「顧客とともに問題解決をしていく関係性」です。パートナーとして適格か、その内容は正しいかはさほど重要ではないです。重要なのはそのようにふるまうことです。

AS-IS

ここからはじまる物語

↓やがてこうなる（とてもつらい）

↓

To-Be：同じ方向を見るパートナーであろう

引用：「私考える人、あなた作業する人」の関係をつくっているのはあなたかもしれない

(2)要件のストーリー化

個人の経験談ですが、要件を収集してストーリー化しますね。その時はいきなりソリューションに行くと、ちょっとちぐはぐ感がでるのかなーと思っています。だからこそ、
要件収集->一覧化->順序並べ->分類->業務要件->技術要件->受け入れ基準
PoCやデモでみせたように「具体！具体！具体！」というアプローチではなく、抽象→具体のアプローチ（あるいは行き来）をとるほうがMECEで手戻りのない、全員に納得感ある要件定義になるのかなぁと最近思ってます。上記の順序に沿うと体感いい感じなのかなと。本項にかんしては自分の最終結論はいまだ出ていないのですが、暫定解として書いておきます。

引用：抽象と具体を行き来する

(3)結局データベースなのか？

ServiceNowは基本データベースっぽいなと感じています。
全てはRecord、Formという形にこめて業務プロセスを表現しています。
なので、データベースを定義するって感じですね。（DBスペシャリストは非保有なので素人意見ですが、、）
データベースを定義する、とは既存のテーブル（Incident/Task...）を使いましょうだったり、既存機能では適用できないので新規のテーブルを作りましょう、これマスターですねという議論だったりを指します。ここで下手にCSDMに入り込むと沼に落ちるので深入りはしませんが、「このデータはどこに入るの？」「データはどう流れるの？」 が中心的な議題であり、そこを固めることが大枠の整理かな、という気持ちがあります。もちろんユーザーインターフェースや外部連携や通知といった話題もあるんですけどね。

(4)むりなもんはむり！という勇気(->OOTBの限界)

そもそも日本を代表する大企業の業務プロセスやフロー、その要件はOOTBでカバーできる領域ではありません。非常に複雑です。だからこそ、ITIL、TOGAF、COBIT、IT4IT、PMBOK、DBOK、TBM(IT)といった標準系に即したServiceNowに乗せる過程で業務変革（≒業務をもっとシンプルに！）しようというのがServiceNowの目的のはずです。OOTBと要件を照らして、できる・できない、やる・やらないの判断を毎日されているコンサルさんお疲れ様です。お気持ちよくわかります。「なるべく現行踏襲した移行」だと制約条件が厳しくなるのは理解しますが、そのうえでもOOTBvsカスタムの判断基準を定めて、やるかやらないかの決定をしていくことは大切だよなと思っています。

参考：OOTBとカスタムという問いそれ自体がナンセンスだby Chuck tomashi
↑上の記事がOOTBvsカスタムという対立軸に対する一番の回答と思います。この記事の判断に照らすのが一番現実解かな（つまりすべてカスタムは悪だという考えは違うんではない？という思い）と考えています。ご参考ください。

ユーザー

(1)これで仕事は楽になったのか？

自動化されたのか、効率的になったのか

顧客との期待値が違うんじゃないかなと最近思うことです。
例えば導入の最初って「ここは自動化されたけど、ここは手動で。いったんAPIじゃなくてデータインポートで」みたいな半分やって半分やらないみたいな感じだと思います。ここの期待値の調整、あるいはロードマップの引き方や見せ方を違えると、 「なんか結局手入力多くね？」 みたいな不満につながる（≒満足度低下）ために、今はここまで、次はここまで自動化！というBefore→Afterやそのロードマップを正しく示すことで一緒に仕事を楽にしていこうという期待感が醸成されるのかなと思います。

ユーザー体験はどうなのか？

これは次のTopicにもつながることですが、OOTBまんまのPlatform画面に対する顧客の声をきくと、「入力項目多いよ」「色味がグレーって。」「結局何すればいいか作業導線がわからん」みたいなことをたまにききます。別に他と比べてそうとまでは個人的には思わないですが。（みんなbacklogとかkintoneとかpagerdutyそういうのと比較するからかな？）
さて、業務効率化・自動化されたプロセスはいいのですが、そういったユーザー体験にまで踏み込むとよりよいプロダクト開発なのかなと思っています。
アプローチ（具体的な手段）としては、
１．入力項目（やボタン）おおい -> 項目少なくする
２．色味がグレーって -> Theme Builderでエクスペリエンスを改善する
３．作業導線わからん -> Annotationや動的にポップを出す、ボタンは色を変える
など小さな改善の積み上げはしてもいいのかなと思ったりします。

ただしPlatform側のUIUX改善はそれでいいですが、一方でService Portalは好きに手を加えすぎると、もしグローバル統合プロジェクトなどが走る会社の場合には、オリジナルのポータル画面と統合ポータルの機能マージに非常に大変なので、ポータル画面に関してはなるべく標準形ので使用されることを推奨します。

(2)誰にとっての使いやすさなのか？

ServiceNow、SAPといった大規模エンプラ製品でよくあるユーザーの声って「いいの？これ」だったりしますよね？宿命みたいなものです。でも使われる理由も当然あったりします。むしろ合理的意思決定のもとでは当然そうなるみたいな感じです。

引用：Xユーザーの和田敦史さんの投稿

コチラの投稿記事に詳細がありますが、誰にとって使いやすさか、という点を念頭に作る（あるいは選ぶ）というのは大事です。記事はSPM・PPMツール比較ですが、単純にUIUXがいいやつがいい！だったらAsanaやWrikeですし、気軽に使える本格派エンプラ製品だったらMS Projectがいいです。一方でグローバルのエンプラ製品で、厳格な要件（業務要件それ自体、グローバル対応、セキュリティ、コンプライアンス、データ連携、先行事例）を考慮するとServiceNowが選択肢に上がってくるのが製品選定における実際のところかなと思います。
厳格な要件をクリアしたうえで、誰にとっても使いやすさを追求していくこと・両立することは大切ですね。

(3)権限管理はわかりやすく

導入後の運用保守の話ですが、問い合わせで結構多いのが、
「このやり方わからない」だったり「（ServiceNow）の記事やページ・情報がみれない」だったりします。
権限管理を適切に設定するのはセキュリティにおける「最小権限の原則」のアクセス権付与として適切ですが、見れない、わからないといった問いに対する良い頃合いとはなんだろうはよく悩むところではあります。見れない系の問い合わせに対する原因調査って手間かかりますしね。Security Centerに期待です。

(4)「できた！」で終わらせない

・一緒に仕事したパートナーを成功させる
・そして偉くなっていただく
・「できてよかった」で終わらず、エンドユーザーや周りの人たちからの評価までをつくりに行く
対面で対応する担当者は、中計・3か年計画の途中からの必然性としての攻めのIT投資として導入検討だったり上層部の決定だったりといった外部環境からの導入意思といった形で「とりあえず入れてって言われたけどServiceNow正直わからないよ」という状況による不安な気持ちだったりすることが多いのかな、と個人的に見て思います。その中で、不安を取り除き、正しく導入して、PJを成功裏に終わらせることで、対面のパートナーにも成功してもらって、出世してもらうことも目的の一つではあります。3方よしの関係性を作りたいものです。

それでも、世界はServiceNowでうまくいく

ServiceNow Japanの社員さんなのか、営業サイドなのか、コンサル・SIといった導入側なのか、ユーザーなのか、誰が読むかもわからない投稿ですが、現場感は少し伝わるかなと思いました。理念や目標が大きくも、現実にはなかなかうまくいかないものです。果たしてうまくいったとして、Go-Liveからの運用開始が本番です。そこでのユーザー様の声を拾っていく活動こそ大事です。そんな一山ふた山をこえてきて、しかしあえてこういいたいです。
世界はServiceNowでうまくいく。

引用：

同じ投稿者のほかに読まれている記事はコチラ！

PS:
本当は12/12,13に記事公開予定ですが、両日とも忙しいため、本日に公開させていただきます。ご了承ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up