SaaS(ServiceNow)のPoCの進め方

ServiceNowの複数のPoC案件に携わった経験をもとに、SaaS・パッケージ製品のPoC案件の失敗パターンと、そこに陥らないためにどのように進めるべきかを書きます。

何のためにPoCを行うか

私はSaaS・パッケージ製品のPoCは「その製品をその会社に導入した場合にビジネス的な価値を創出できるか」を確認するために、出したい価値を明確にした上で、業務とのfit&gap、技術検証、運用性の確認、導入後の体制検討などを行うものだと考えています。

しかし、PoCは低予算で始められること、明確な成果を求められないこと（仮に失敗してもうまくいかないことが実証できましたという成果にできてしまうこと）から、目的が曖昧なまま開始してしまうことが多いように感じます。そんな目的が曖昧なまま始まったPoCにありがちな失敗パターンを紹介します。

PoC失敗パターン　製品の技術・仕様調査に終始してしまう

「〇〇の機能はあるの？」「〇〇はカスタマイズできるの？」という製品の技術・仕様調査だけを行って終わるパターンです。このパターンは、終わった直後は導入できそうだ、となりますが、実際に導入プロジェクトを立ち上げようとしたときに「何のためにやるんだっけ？」「ROI出るんだっけ？」といった問いに答えられないことに気が付きます。その結果、PoC第二フェーズという謎のプロジェクトが立ち上がったりします。

技術・仕様調査はPoCで実施しておくべき事項の一つですが、内容には注意が必要です。SaaS・パッケージ製品は標準仕様やカスタマイズの余地が製品側で決まっています。そのため、基本的な機能の確認はPoCの中ではなく、事前に製品ベンダに確認しておきましょう。PoCで行う技術・仕様調査は、実際の業務を想定したUXの確認や運用を回すためにどうしても必要になるカスタマイズの可否の確認などを行うべきです。

また、このパターンは運用部署を十分に巻き込めているかに注意すべきです。開発など導入を主導する部署だけが先走ってしまっていて、運用担当者の視点が足りていないと、「この画面にこの情報を表示させたい」「監査要件を満たすためにこの条件でフィルタをかけたい」など、導入時に思わぬ追加要件が出てきて、それに伴う技術的な障壁が明らかになることがあります。

PoC失敗パターン　レガシーシステムとの比較で終わってしまう

運用担当者の意見を重視しすぎた結果、運用中のレガシーシステムできることが新システムでもできるかを調査して終わってしまうパターンです。このパターンはなんかこのシステム使いづらいね、という結果になってしまうことが多いです。特にSaaS・パッケージ製品導入では、現行システムをベースに考えるのではなく、その製品の価値を最大限享受するためにはどのように活用すべきか、どのように現行業務を合わせていけばよいか、を考えるべきです。

導入を主導する部署に思いがなく、現場の担当者の意見を聞きすぎてしまうと、現場の担当者は現行業務をベースに考えるため、その製品の価値を享受するために新システムに合わせて合わせて業務を変えるとか、新システムによってそもそも自分がやっている業務が不要になるという可能性を考えることは難しいです。

次に、失敗パターンに陥らないためにPoCを成功させるために何をすればよいかを考えます。

PoCを成功させるために　出したい価値を明確にする

PoC、ひいては製品導入を成功させるためには、まずその製品の導入によって、コストを削減したいのか、従業員満足度を上げたいのか、ガバナンスを効かせたいのか、セキュリティリスクを減らしたいのか、といった最終的に出したい価値を明確にする必要があります。

この製品を使って何ができるかを試してみたい、などという場合は、PoCという名のもとで行うべきではないと思います。この場合は、社内での課題整理や、製品ベンダとの協議を行い、まずその製品を使ってどんな課題の解決に取り組むか、どんな価値を出すことを目指すかを明確にすべきです。

出したい価値が明確になっていれば、それを創出するために現時点であいまいな部分が検証項目になります。検証が完了すること=製品導入による価値が明確になること=投資を行うべきか否かの判定ができること、となっていれば、意味のあるPoCができます。