——ServiceNow導入前に決め切るべきスコープと非機能要件

目次

• 1. 問題提起：RFPが失敗プロジェクトの“起点”になるとき
• 2. 現状の誤解・よくある状態：要件羅列・曖昧語・前提差が招く見積乖離
• 3. 原因分析：現場課題と非機能を結ぶ設計欠落、責任分界の不明確さ
• 4. 解決アプローチ：スコープと非機能を「運用仮説」で結ぶRFP設計
• 5. 実務への適用イメージ：評価指標・採点方法・チェックリストの実装
• 6. 導入・運用後の変化：PoC止まりを回避し、移行と定着を見据える
• 7. 結論：ベンダー選定ではなく「運用モデルの合意」を調達する
• 8. まず始めるチェックリスト

1. 問題提起：RFPが失敗プロジェクトの“起点”になるとき

「まずはRFPを出して、あとは提案を見て考えましょう。」
会議の終盤、時間が押してきた頃によく出る一言です。その場では合理的に聞こえます。ですが、この時点で多くの前提が棚上げされています。RFPは本来、選定のためだけの資料ではありません。導入後の運用を左右する、設計書の初版のような位置づけです。

ところが実際のRFPは、「この機能も欲しい」「それも入れておこう」という声を集めた結果、要件の置き場になりがちです。優先順位や非機能要件の水準が決まらないまま、ベンダー選定だけが先に進みます。

その結果、ServiceNowで何を、どの順で、どのレベルまで実現するのかが腹落ちしません。契約後にスコープの追加や見積調整が続き、「こんなはずじゃなかった」という会話が増えていきます。

もう一つ、静かに効いてくるのがデータの前提です。「今はExcelで管理しています」という一言で話を進めると、導入後に足元が揺れます。台帳は作った瞬間から古くなります。自己申告ベースでは、シャドーITが自然に増えるためです。

---

2. 現状の誤解・よくある状態：要件羅列・曖昧語・前提差が招く見積乖離

要件の羅列化——「積めば勝ち」という思い込み

調達の場では、「後から足りないより、最初に全部書いたほうがいい」という判断に陥りやすいです。その結果、RFPは“やりたいことリスト”になります。

最初にどこまでやるのかが決まっていません。最小実装単位が曖昧なまま進むため、工程もコストも読みにくくなります。あとからTCOが顕在化して問題になる典型パターンです。

曖昧語 —— 高可用・柔軟・迅速・セキュア

提案説明会で、こんな言葉を聞いたことはないでしょうか。
「高可用で、柔軟に拡張でき、迅速に対応できます。」

方向性としては正しそうです。ですが、そのままでは評価できません。月間稼働率、RPO、RTO、承認ステップ数や処理にかかる日数。ここまで落として初めて、「できる・できない」「どこまでか」が見えてきます。

抜け漏れ —— 見積に載らない“あとから重くなる項目”

キックオフ直後に「データ移行はどこまで実施する想定でしょうか」という問いが出てくることがよくあります。

クレンジング、既存フローの廃止、再教育。ダッシュボード整備や変更管理の定着も同様です。RFPに書かれていなければ、見積に含まれていないことがほとんどです。その差分が、後半フェーズで一気に重くのしかかります。

前提差 —— 現行の「現実」がそろっていない

「データはだいたい揃っています。」この表現は、立場によって意味が変わります。

重複や欠損、最新性、権限の数やその複雑さについて、顧客とベンダーで前提の捉え方が異なるケースが多く見られます。同じ物差しで測り、数値としてRFPに書くことが欠かせません。

---

3. 原因分析：現場課題と非機能を結ぶ設計欠落、責任分界の不明確さ

「困りごと → 運用KPI → 要件」のつながり不足

RFPを読むと機能は並んでいるのに、理由が見えないことがあります。現場では「結局、何が一番困っているんでしたっけ？」という話に戻りがちです。

たとえばMTTR（復旧までにかかる平均時間）短縮が目的なら、アサイン時間や一次解決率といったKPIが先に来るべきです。そこから、効く機能と非機能を選びます。順番が逆になると、議論が噛み合いません。

データ鮮度の未設計——CMDBの最小核と責任

CMDB（構成管理データベース）は、「とりあえず全部入れたい」と言われがちです。ですが、何を最初に入れるのかを決めないと、誰も更新しなくなります。更新頻度、担当、監査方法を導入前に決めないと、データはすぐ使えなくなります。

CTEMが要件に入っていない

可視化までは進んだものの、「で、このリスクは誰が直すんでしたっけ？」という状態で止まることがあります。CTEM（継続的な脅威エクスポージャー管理）は、検知して終わらせないための考え方です。この運用ループ自体を、非機能要件として書けていないケースが目立ちます。

---

4. 解決アプローチ：スコープと非機能を「運用仮説」で結ぶRFP設計

スコープ定義は、現場の一日から逆算する

誰が、どんな業務をしていて、どこで手が止まっているのか。まずは具体的な場面を言葉にします。そこから改善したいKPIを置きます。KPIが動く理由、つまり運用仮説を考えます。その仮説に必要な機能だけを選びます。

非機能要件は「判断できる表現」にする

可用性は「止まらない」ではなく数値で、拡張性は「増えても安心」ではなく上限で表現する。保守やセキュリティも同様です。運用時に判断できるレベルまで具体化します。

責任分界は、あと回しにしない

プロジェクトが進行した後に「そこはどちらの担当でしたか」という確認が生じないよう、RFPの段階であらかじめ決めておきます。RACI（役割分担表）を最小限でいいので書きます。期待値のずれを早めに潰せます。

---

5. 実務への適用イメージ：評価指標・採点方法・チェックリストの実装

評価指標は、迷わない数に絞る

評価指標は、できるだけ迷わない数に絞ることが重要です。指標が多すぎると、提案の良し悪しではなく、評価者の主観で結論が揺れます。実務では、要件適合、TCO、リスク、運用適合の4軸がそろえば、提案を比較するうえで大きく困ることはありません。どのベンダーが「安いか」ではなく、「続けられるか」を同じ物差しで見られるようになります。要件適合、TCO、リスク、運用適合。この4軸がそろえば、比較しやすくなります。

採点のルールを先に決める

採点のルールも先に決めておきます。「5点とは、どの状態を指すのか」という問いに答えられない採点は、後から必ず揉めます。点数は印象ではなく、条件で付ける前提にします。「5点って、どういう状態ですか？」この質問に答えられるようにします。主観ではなく、条件で点を付けます。

見積乖離は、よくある形から潰す

見積乖離についても、よくある形から先に潰します。「柔軟」「迅速」といった曖昧な表現は数値へ落とし、抜けやすい項目はRFPの固定章として明示します。あわせて、前提条件は検収条件とセットで書き、後出しで解釈が変わらないようにします。

---

6. 導入・運用後の変化：PoC止まりを回避し、移行と定着を見据える

RFPに「その後の姿」を書く

導入できたか、では終わらせません。使われているか、更新されているかを書きます。CMDBの鮮度やCTEMの回転を、運用仮説としてRFPに入れます。

受け入れ条件を数値で合意する

受け入れ条件は、定量的に合意します。KPIの改善兆候やデータの最新性を確認できる状態を成果条件として定義しておくことで、PoCで止まるリスクを抑えやすくなります。

静的台帳から戻らない設計にする

静的な台帳に戻らない前提で、運用を設計します。運用が忙しくなると、更新が止まりにくいExcelに戻りたくなりますが、その瞬間にデータの最新性は保てなくなります。だからこそ、人の手で更新する前提を捨て、自動検知と差分管理を前提にした設計にしておきます。

---

7. 結論：ベンダー選定ではなく「運用モデルの合意」を調達する

RFPは、要件を集めるための文書ではありません。導入後、誰がどの前提でデータを更新し、運用を回していくのかという、運用の流れを事前に合意するための道具です。

ServiceNow導入の価値は、機能がそろっているかでは決まりません。正しいデータが、役割と責任に基づいて更新され続けるかどうかで決まります。ここが曖昧なまま進むと、導入直後は動いていても、運用が忙しくなるにつれて形骸化しやすくなります。

だからこそRFPの段階で、CMDBにまず何を載せるのかという最小核、誰がどの頻度で更新するのかというルール、検知から是正までをどう回すのかというCTEMの考え方まで、言葉として明示しておきます。それは設計を細かく決めるためではありません。後工程で前提がずれ、追加調整に追われる状況を避けるためです。

RFPで運用モデルまで合意しておくことが、結果として最も遠回りの少ない進め方になります。

---

8. まず始めるチェックリスト

RFPを出す前に、以下の項目が言葉として整理できているかを確認します。すべてを完璧に書く必要はありません。ただし、「考えていない」状態のまま調達に進むと、後工程で必ず前提差が露出します。

このチェックリストに一つずつ答えられる状態を作ることが、RFPを「要件の羅列」ではなく、運用モデルの合意文書に変える第一歩になります。 

RFPは、ベンダーを選ぶためだけの資料ではありません。導入後に「前提が違った」という会話を減らすための、最初の合意点です。