SaaSベンダーの提案、翌月には導入決定
ある日、ビジネス部門の部長がこう言う。「SaaS企業から提案を受けた。うちの業務課題にぴったりだ。来月から導入したい」。
デモは華やかだった。営業担当のプレゼンテーションは課題を的確に言い当て、導入事例は輝かしく、費用もフルスクラッチ開発に比べれば格段に安い。部長は経営会議で導入を提案し、「現場が必要だと言っている」の一言で承認が下りる。システム部門への相談は、導入決定の後だった。
「このSaaS、既存システムとどう連携するんですか」「データの持ち方は既存のマスタと整合しますか」「セキュリティ要件は満たしていますか」。システム部門が問いを投げる頃には、すでにベンダーとの契約は済んでいる。問いは「意見」ではなく「抵抗」として受け取られる。
こうして導入されたSaaSが、半年後にはこうなる。既存システムとのデータ連携ができず、二重入力が発生する。マスタデータの定義が既存と食い違い、レポートの数字が合わない。現場は「前より手間が増えた」と不満を募らせ、結局Excelでの運用に戻っていく。投じたコストと時間は回収できないまま、SaaSのライセンス料だけが毎月引き落とされ続ける。
これは特殊な事例ではない。多くの企業で、程度の差こそあれ、同じ構造が繰り返されている。
なぜビジネス部門だけで導入が決まるのか
SaaSが変えた「導入の敷居」
かつてシステム導入には、大規模な開発予算と長い開発期間が必要だった。だからこそ、システム部門が関与しない導入はあり得なかった。しかしSaaSがこの前提を変えた。初期費用は小さく、月額課金で始められ、トライアルも容易。導入の意思決定にシステム部門を経由する「必然性」が、構造的に薄れたのだ。
SaaSベンダーもこの力学を理解している。提案先はシステム部門ではなく、予算権限を持つビジネス部門だ。デモでは業務課題の解決を前面に出し、技術的な制約やインテグレーションの複雑さは背景に退く。意思決定者にとって「すぐに導入できる」ことは魅力であり、その裏にある技術的な検討事項は見えにくい。
「ビジネス部門が強い」組織のジレンマ
多くの日本企業で、システム部門はビジネス部門の「支援者」として位置づけられている。予算の源泉はビジネス部門にあり、システム部門は求められたものを「作る側」「対応する側」だ。この力学の中で、ビジネス部門が持ち込んだSaaS導入の提案に対して「本当にそれが最適ですか」と問い返すことは、「仕事を断っている」「変革に抵抗している」と見なされるリスクを伴う。
結果として、システム部門は意見を飲み込む。あるいは、形式的なセキュリティチェックだけを通して「関与した」体裁を整える。本来なら導入前に行うべき、既存システムとの整合性の検証、データアーキテクチャへの影響評価、業務プロセス全体への波及分析が省略されたまま、導入が進む。
DXレポート2.1が指摘した、ユーザー企業とベンダー企業の「低位安定」の構造 (経済産業省, 2021) は、社外だけの話ではない。ビジネス部門が決め、システム部門が従うという社内の「低位安定」もまた、導入後の泥沼を構造的に生み出している。
問題は、SaaSが悪いことでも、ビジネス部門が積極的なことでもない。導入の意思決定プロセスから、技術的な検討と業務全体への影響評価が抜け落ちることが問題なのだ。
もう一つの落とし穴 ── 「一部の声」で全体を決めること
SaaS導入が泥沼化するケースには、もう一つの共通パターンがある。ビジネス部門の中の特定の領域、特定の担当者の声だけを聞いて、導入が決まっているという構造だ。
ある部署の業務課題にはフィットするSaaSが、隣の部署の業務フローとは致命的に噛み合わない。営業部門の要望で導入したツールが、その後工程である経理部門やオペレーション部門に想定外の負荷を生む。一つの工程の最適化が、商流全体のバリューチェーンで見るとむしろ非効率を生んでいる。
こうした事態が起きるのは、導入の意思決定がバリューチェーン全体を俯瞰する視点を欠いているときだ。SaaSは特定の業務領域に特化した製品が多い。だからこそ、「その製品が解決する範囲」だけを見て導入を判断すると、前後の工程やデータの流れとの不整合が後から噴出する。
特に注意が必要なのが、自社のビジネスモデルとSaaSの設計思想が合致しているかどうかの判断だ。たとえば、顧客ごとに柔軟なサービス提供（テーラリング）を重視するビジネスモデルの企業が、標準化・効率化を前提としたSaaSを導入したらどうなるか。ツールの標準機能と自社業務のギャップを埋めるためにカスタマイズ要件が膨らみ、要件定義に半年、一年と時間を費やす。SaaSの最大の利点である「すぐに使える」が完全に失われ、コストはフルスクラッチ開発に近づき、しかもSaaSの制約の中で無理やり作り込むため中途半端な仕上がりになる。これはもはやSaaSを選んだ意味がない。
一部の声だけを聞かない。バリューチェーン全体で判断する。自社のビジネスモデルとの相性を見極める。 この三つの視点が導入前の意思決定に組み込まれていれば、避けられる泥沼は多い。
「あの時、何をすべきだったのか」
ベンダーの提案を受けてからGo Liveまでの間に、立ち止まるべきポイントはいくつもあった。
提案を受けた瞬間 ── 「課題の再定義」
SaaSベンダーの提案は、ベンダーが定義した課題に対するベンダーのソリューションだ。しかし、ベンダーが見ているのはビジネス部門から聞いた課題の一面であり、組織全体の業務プロセスやデータの流れを俯瞰した上での課題定義ではない。
本来、提案を受けた時点で問うべきだったのはこうだ。「この課題は、本当にこのSaaSで解くべき課題なのか。既存システムの設定変更や業務プロセスの見直しで解決できないか。解くとして、そのSaaSは既存のデータ基盤とどう共存するのか。そして、この導入はバリューチェーンの前後にどんな影響を及ぼすのか」。
この問いは、ビジネス部門だけでは答えられない。システム部門だけでも答えられない。両者が対等に、課題の全体像を共有した上で初めて答えが出る問いだ。この対話の場を設けないまま導入を決定したこと ── それが最初の分岐点だった。
導入決定の前 ── フェーズと領域を分ける
仮にSaaS導入が正しい判断だとしても、「全業務を一度に載せ替える」必要はない。導入のフェーズを分ける（まず一つの業務プロセスで成果を確認してから次へ展開する）、あるいは対象の領域を分ける（まず一部門で導入し、安定したら横展開する）── この設計判断が、導入決定の前に行われるべきだった。
ここで忘れてはならないのは、ツールの導入スピードと、現場の受容スピードは別物だという事実だ。SaaSは明日から使える状態にできるかもしれない。しかし、昨日までExcelで管理していた業務が、今日からまったく異なるインターフェースに置き換わるとき、現場には確実に混乱が生じる。データの入力場所が変わり、承認フローが変わり、レポートの見方が変わる。一つひとつは小さな変化でも、それが同時に押し寄せると、業務のパフォーマンスは一時的に大きく落ちる。
Prosci の調査は、効果的なチェンジマネジメントを行ったプロジェクトは、そうでないプロジェクトに比べて目標達成率が7倍高いことを示している (Prosci, 2023)。裏を返せば、「現場はついていけるか」という問いを省略した導入は、7分の1の確率で戦っているということだ。
最初のフェーズ、最初の領域での導入は、Quick Winだ。小さな範囲で「確かに楽になった」という成功体験を作り、現場の信頼を得てから展開を広げる。Kotterが変革の成功要因として短期的な成果の創出を重視したのも (Kotter, 1996)、この力学を捉えている。各フェーズの間にはバッファ ── 現場が新しいやり方に慣れるための助走期間 ── を設け、旧プロセスへのフォールバック手段も準備する。急いで全面導入して使われないシステムと、段階的に広げて確実に定着するシステム。長期的にどちらが早いかは明らかだ。
ビジネス部門が果たすべき責任
ここまでシステム部門の視点を中心に述べてきたが、乖離の解消はシステム部門だけの責任ではない。ビジネス部門にこそ、果たすべき責任がある。
第一に、「何を解決したいのか」をベンダーの言葉ではなく自分の言葉で定義する責任。 SaaSベンダーの提案は魅力的だ。しかし、その提案はベンダーの製品が解決できる範囲に最適化されている。自部門の業務課題を、ベンダーの提案を聞く前に構造的に整理し、「何が解決されれば成功なのか」を自ら定義する。この作業をせずにベンダーの言葉をそのまま採用すると、ベンダーの課題定義に自社の業務を合わせにいくという本末転倒が起きる。
第二に、自部門の最適化だけで判断しない責任。 自分の部署にとって便利なツールが、前後の工程にどんな影響を与えるか。データの入出力は商流全体で整合するか。「自部門の効率化」を超えた視野で導入の妥当性を考える責任がある。これは、システム部門に聞けばわかることだ。聞く場を設けるか否か ── その判断自体が、ビジネス部門の責任範囲にある。
第三に、導入後の「定着」に当事者として関わる責任。 「入れたのに使いにくい」と後から言うのではなく、早い段階から試作品に触れ、具体的なフィードバックを返す。Quick Winの成果を自部門の中で共有し、次のフェーズに向けた要望を建設的に伝える。ビジネス部門は変革の「発注者」ではなく「当事者」だ。この自覚が、システム部門との対話を本質的なものに変える。
システム部門が「意見できる」ために
一方で、システム部門にも変わるべきことがある。意見できない構造の中で、ただ耐えているだけでは何も変わらない。
第一に、「なぜ事前に関与すべきか」をデータで語れるようにする。 過去に安易に導入されたツールの利用率、二重入力によって発生した工数、データ不整合がもたらした意思決定の遅延。これらを定量的に可視化できれば、「導入前にシステム部門を関与させるべき理由」は感情論ではなく事実として提示できる。
第二に、SaaSを含むIT関連投資に、技術レビューのチェックポイントを意思決定プロセスに提案する。 承認のハードルを上げるためではない。「既存システムとの整合性」「データ移行の実現性」「バリューチェーンへの影響範囲」を短期間で評価し、導入の進め方について選択肢を提示する場を作る。
第三に、「どう作るか」の前に「本当にシステムで解くべきか」を問う姿勢を持つ。 業務プロセスの見直しや運用ルールの変更で解決できる課題を切り分け、システム化が真に必要な領域を特定する。この「問い返す力」こそが、システム部門の価値の再定義になる。
なお、こうしたビジネスとITの橋渡しを組織としてどう制度化するか ── ビジネスアナリスト的なポジションの設計という論点は、別のInsightで改めて掘り下げたい。
まとめ ── 導入の前に、対話を
SaaSは業務課題を解決する強力な手段だ。問題は、その導入プロセスから「本当にこれで解くべきか」という問いと、「バリューチェーン全体で見てどうか」という視点と、「現場はついていけるか」という配慮が抜け落ちることにある。
ビジネス部門の推進力は組織の変革に不可欠だ。しかし、その推進力が一部の声だけに基づき、システム部門の知見を迂回し、現場の受容力を無視して走るとき、組織は泥沼に向かう。必要なのは、どちらかがどちらかに従う関係ではない。課題を共に定義し、フェーズと領域を分け、Quick Winで信頼を築き、現場が追いつける速度で変えていく ── この対話と設計の回路を組織に埋め込むことだ。
テクノロジーだけでは、組織は変わらない。変わるのはシステムではなく、それを使う「人」だ。その認識が、すべてのDX推進の土台になる。
関連テーマ（今後のInsight予定）: