SIerの力を最大化する"発注前の設計"という考え方

大手SIerに頼むこと自体が間違いなのではない。頼み方の構造に問題がある

「大手SIerに数千万円かけてシステムを作ったが、期待した効果が出なかった」——私たちのもとに相談に来る中堅企業の経営者から、この言葉を何度も聞いてきた。

先に断っておく。大手SIerの技術力や組織力は、多くの場合、申し分ない。数百人規模のプロジェクトを回し、複雑な業務要件を仕様に落とし込み、期日通りに納品する能力において、大手SIerは優れている。

問題は、SIerの力量ではない。発注する側と受注する側の間にある「構造的なズレ」が、プロジェクトの成果を食い潰している。

ズレ1: 「何を作るか」は決まっているが、「なぜ作るか」が共有されていない

従業員280名規模の専門商社が、基幹システムの刷新を大手SIerに依頼した。RFPは100ページ超。機能要件、画面仕様、データベース設計まで詳細に記載されていた。

SIerは仕様通りに作った。テストも通った。予定通りに納品された。しかし、半年後に経営層が抱いた感想は「思っていたのと違う」だった。

なぜか。RFPに書かれていたのは「何を作るか」だった。「なぜ作るのか」「どんな価値を出したいのか」は、発注側の暗黙の前提として存在していたが、RFPには明示されていなかった。

経営層は「意思決定を速くするためのデータ基盤」が欲しかった。IT部門は「既存システムの機能改善」としてRFPを書いた。SIerはRFPに書かれた機能を忠実に実装した。三者とも自分の仕事をしたのに、全体としては的を外した。

これはSIerの落ち度ではない。「なぜ作るのか」を明示的に言語化し、発注側と受注側で合意するプロセスが、プロジェクトの設計に組み込まれていなかった——これが構造の問題だ。

対症療法: 「RFPをもっと丁寧に書こう」
構造的な問い: 「RFPに書くべき"価値の定義"は、誰がどうやって設計しているのか」

ズレ2: 成功の基準が「納品」であって「価値の実現」ではない

従業員450名規模のEC企業が、CRM導入を大手SIerに委託した。プロジェクトは予定通り、予算内で完了した。検収も通った。

しかし、導入から1年後、CRMの活用率は低いままだった。営業チームは「入力が面倒」と言い、管理者は「欲しいレポートが出ない」と言う。

原因を掘り下げると、プロジェクトのKPIが「CRMの稼働開始日」で設定されていた。「CRMを使った結果、営業の意思決定が速くなったか」「顧客対応の品質が上がったか」は計測対象に入っていなかった。

これは契約構造の帰結だ。大手SIerのビジネスモデルは「要件通りに作って納品する」ことで成立している。健全な事業構造であり、その範囲内では「成功」だ。しかし、発注側が求めているのは「納品」ではなく「価値の実現」であり、その間にギャップがある。価値の定義と計測は、本来、発注する側の仕事だ。ただし、多くの中堅企業には、それを設計する方法論もリソースもない。

対症療法: 「KPIをちゃんと設定しよう」
構造的な問い: 「"機能のKPI"ではなく"価値のKPI"を、プロジェクト開始前に設計しているか」

ズレ3: 「仕様変更は追加費用」の壁が、本質的な改善を阻む

従業員320名規模のB2B SaaS企業が、データ基盤の構築を大手SIerに依頼した。開発が進む中で、経営企画部門から「この切り口でもデータを見たい」という要望が出た。

SIerの回答は「仕様変更になるため、追加の見積もりが必要です」だった。契約上、完全に正しい対応だ。

しかし、経営企画の要望は「現場で使い始めて初めて分かったニーズ」だった。プロジェクト開始前にはこの要望は存在しなかった。使ってみて初めて「ここが足りない」と気づいた。

ここにも同じ構造がある。固定スコープの契約構造と、探索的な性質を持つDXプロジェクトの間に、構造的な不整合がある。固定スコープ契約はリスクを管理する合理的な仕組みだ。問題は、DXプロジェクトにその仕組みが合っていないケースがあるにもかかわらず、他の選択肢が見えていないことにある。

対症療法: 「変更管理プロセスを整備しよう」
構造的な問い: 「そもそも固定スコープ前提の契約構造は、このプロジェクトの性質に合っているか」

大手SIerが「構造的に苦手」なこと

これらは「能力」の問題ではなく「ビジネスモデル」の問題だ。最適化された能力を、想定外の用途で使おうとしている——映画館にレストランの料理を期待するようなものだ。

では、大手SIerに頼むべきではないのか

そうは言っていない。

仕様が明確で、関係部門の合意が取れていて、成功基準が定義されていて、スコープが安定しているプロジェクトであれば、大手SIerは最も信頼できるパートナーだ。大規模な基幹システムの構築、ERPの導入、既存システムのマイグレーション——これらは大手SIerの独壇場だ。

問題が起きるのは、「仕様の手前」が設計されていないまま、大手SIerにプロジェクトを丸投げするケースだ。

発注する前に確認してほしいこと

RFPを書く前に3つだけ確認してほしい。

1. 「なぜ作るのか」が、経営層・事業部門・IT部門の間で同じ言葉で語れるか。
2. プロジェクトの成功基準が「納品日」以外に設定されているか。
3. データの定義が部門間で統一されているか。

3つとも「はい」と答えられるなら、大手SIerへの発注は合理的な選択だ。1つでも「いいえ」があるなら、発注の前に設計すべきレイヤーが丸ごと欠けている。

なぜこの空白が生まれるのか——DXプロジェクトの構造問題の全体像は「中堅企業のDXが失敗する3つの構造的問題」で整理した。この空白を埋める設計思想はSemantic SI完全ガイドにまとめている。

SIerの問題ではない。仕様を書く前に、前提を設計する工程が丸ごと欠けていること——それが構造の問題だ。