この記事は ServiceNow アドベントカレンダー 2025 の12月9日分の記事として執筆しています
はじめに
私は2023年から ServiceNow に関するプロジェクトに、プロダクトオーナーとして携わっています。それ以前はパートナー企業側で、さまざまな企業のServiceNow導入支援を行うデベロッパー／プロジェクトマネージャーとして活動していました。
立場が変わったことで “Fit to Standard” を捉える視点も大きく変化し、その中で得た気づきを本記事では整理していきます。
1. 問題：Fit to Standard が進まない理由は何か
SaaS導入において、ほぼすべての企業が直面する共通の悩みがあります。
- Fit to Standard の重要性は理解している
- しかし実際にはカスタマイズ要求が止まらない
- 標準プロセスに業務を寄せると必ず現場から反発される
- 結果として “カスタマイズもりもり” あるいは “結局 Excel でやる” というオチに
Fit to Standard の議論は往々にして「業務を変えたくない現場 vs 標準機能に寄せたいIT部門」という対立構造で語られます。しかし、この単純な構図では本質を捉えられません。
Fit to Standard が進まない背景には、もっと深いレベルでの価値観の衝突があります。
2. 原因：価値観の衝突と、プロダクトマネジメント外部委託への理解不足
■ SaaS導入とは、プロダクトマネジメントの外部委託である
SaaSを導入するとは、単にインフラ運用や開発を外注することではありません。
根本的には プロダクトマネジメントを外部に委ねる行為 です。
プロダクト側ではすでに以下が決定済みです。
- プロダクトのビジョン（誰にどのような価値を提供するのか）・価値観
- プロセスやデータモデル
- どのロールがどの責務を持つか
- どの業務モデルを標準とするか
- UI/UX の前提となるワークスタイル
- 投資領域・非投資領域（ロードマップ方針）
製品のコンセプトや主要機能のレベルではドキュメントとして公開されるものの、ドキュメントには表されない内容が数多く存在する。
したがって、“プロダクトがどの価値観を前提としているか” を読み解けない企業が多い。
■ ServiceNowに内包される「暗黙の価値観」の具体例
ServiceNowを例に取ると、次のような具体的前提が組み込まれています。
- エージェントとマネージャーはそれぞれ異なる役割
- サービスデスクは Tier モデル（レベル分解）を前提にしている
- GBS的な統合運用の世界観
- チケットは“担当者が責任を持つ”モデルを前提としている
- マネジメントを前提とした自動化
これらは明文化されていないため、読み解きがなければ組織内で誤解が生まれます。
- なぜそのUIなのか理解されない
- なぜそのデータモデルなのか説明されない
- なぜそのプロセスが標準とされているのか共有されない
その結果、
現場はプロダクトが前提にしている価値観と異なる判断基準のまま業務を続けようとし、Fit to Standard が進まなくなります。
▼業務プロセスや機能は価値観を軸に設計・開発される
▼価値観を変革せずに業務を変えることは、現場の反発につながる
3. 原則：Fit to Standard とは、価値観をプロダクトに寄せるプロセスである
ここまでの議論を整理すると、次の原則が導かれます。
Fit to Standard の本質は、プロダクトが採用している価値観を理解し、自社の価値観をそこへ寄せていくことである。
プロダクトはビジョンに基づき、
- プロセス
- データモデル
- ロールと責任分担
- UI/UX
- 運用モデル
を体系的に設計しています。
これらを理解しないまま表面的に「標準に合わせる」だけでは、現場は必ず元の価値観にもとづく行動へ戻ります。
4. 実践：Fit to Standard を成立させるためにプロダクトオーナーとして行うべきこと
プロダクトオーナーという役割が明確でないプロジェクトも多いのが現実かと思います。
そのような場合は適宜読み替えて読み進めてください
Fit to Standard が失敗する原因は、
「価値観を読み解き、可視化し、トップにインプットし、現場に翻訳する」という機能が不十分であること
に直結します。
Fit to Standard の実行フェーズは、プロダクトオーナーが製品の価値を最大化するために、導入する製品の価値観を読み解き、トップや現場とその価値観を共有することで成立します。
① トップ：価値観の「方向性」を明確に示す
トップが宣言すべきことは、抽象的スローガンではなく、具体的な価値観レベルの指針です。
例：
- 「マネージャーはダッシュボードで状況を把握する」
- 「Tier モデルを業務の前提に置く」
- 「チケットは担当者責任モデルで運用する」
- 「Excel 管理は廃止し、ServiceNow を唯一のデータ源とする」
そして、その材料を提供するのがプロダクトオーナーです。
② プロダクトオーナー：Fit to Standard 成否を左右する中核
プロダクトオーナーは次の役割を担います。
1. プロダクトが内包する価値観を読み解く
ドキュメントに書かれていない設計思想・前提を抽出する。
2. 自社の現行価値観と比較しギャップを特定する
どこが衝突し、どこが許容できるのかを整理する。
3. トップに判断材料としてインプットする
プロダクトオーナーは、価値観ギャップの構造をトップが理解できるよう提示する。
これによりトップは「何を捨て、何を採用するのか」を正しく判断できる。
4. トップの方針を現場に翻訳し、行動レベルに落とす
抽象的な価値観を、現場が毎日の業務でどう振る舞うべきかまでブレイクダウンする。
プロダクトオーナーの機能が弱いと、Fit to Standard は確実に破綻します。
なぜなら価値観の読み解きも翻訳も誰もやらなくなるからです。
③ 現場：支援を受けながら新しい価値観に基づく行動へ移行する
現場は、プロダクトオーナーの翻訳を受けて初めて行動を変えられます。
- 標準プロセスに基づいた運用ガイド
- UI/データモデルの背景説明
- 手放すべき行動の明確化
- 新しい判断基準への移行支援
これらがない状態では、現場は旧来の価値観に引き戻されます。
5. 警鐘：カスタマイズとは、委託したプロダクトマネジメントを自社で巻き取る行為である
Fit to Standard を議論する際、多くの企業が見落としている重要な事実があります。
カスタマイズとは、外部委託したはずのプロダクトマネジメントを自社で巻き取るという決断である。
ServiceNowのようなSaaS製品は、プロダクトビジョンにもとづき、市場調査・要件抽出・機能選定・設計思想・優先順位付け・UX設計・バージョンアップ戦略といった、膨大なプロダクトマネジメント活動を継続的に実施しています。
このプロセスは単発の意思決定ではなく、高度で継続的なアクティビティの集合体です。
- ユーザー課題の解像度を上げるリサーチ
- 世界観に整合するプロセス・データモデルの設計
- 実装可能性・価値・リスクを総合的に判断する優先順位付け
- UI/UXの検証
- 継続的な改善とバージョンアップ
- 技術負債の管理
- プロダクトとしての一貫性の維持
これは専門職としてのプロダクトマネージャーが担う領域であり、容易に真似できるものではありません。
■ カスタマイズを選択するとは、これらを自社が背負うという覚悟を意味する
SaaSをカスタマイズすることは、
- 標準のロードマップに乗れなくなるリスク
- 一貫性のない機能追加により、運用・保守が複雑化するリスク
- 将来的なバージョンアップの負債
- 自社独自仕様の“ミニ・プロダクト”を持つ構造的リスク
など、プロダクトマネジメントに伴う負荷と責務を自社で抱えるという決断になります。
カスタマイズの可否は「作れるか／作れないか」ではなく、
「プロダクトマネジメントを内製する覚悟があるか」という問いで判断されるべきである。
だからこそ、
カスタマイズには覚悟が必要であり、軽い気持ちで選択すべきではない。
これが私の経験から鳴らしたい警鐘です。
すべてのカスタマイズを否定するものではありません
企業の競争力を向上させるためのカスタマイズは、上記の覚悟を持って行うのであれば良いと考えています
■ まとめ：Fit to Standard を成功させる鍵は、「価値観の翻訳」と「覚悟」である
- Fit to Standard が進まない最大原因は 価値観の衝突
- SaaS導入とは、プロダクトマネジメント（価値観）の外部委託
- SaaS製品には 明文化されない“価値観” が存在する
- プロダクトオーナーがそれを読み解き、可視化し、トップにインプットし、現場に翻訳する
- カスタマイズとは、外部委託したプロダクトマネジメントを自社が巻き取る行為
- 覚悟なきカスタマイズは、組織を長期的な負債へ導く
- だからこそ、「価値観をプロダクトへ寄せる」Fit to Standard が重要となる
Fit to Standard は、単なるプロセス適用ではなく、組織の価値観・判断基準・責務をプロダクトに合わせて再設計する取り組みです。
この本質を理解し、プロダクトオーナーの機能を整え、カスタマイズの重さを正しく認識することが、SaaS導入成功への道筋だと考えます。