DXが失敗する最大の原因は、ベンダーの技術力不足ではありません。発注者が「システムに何を求め、どの業務課題を解決するか」を定義するRFP（提案依頼書）と要件定義の作成を放棄し、ベンダーの提案に丸投げしていることにあります。主導権を失えば、業務がシステムの標準仕様に合わせて変形させられ、改修費用が際限なく膨らみます。DXが失敗する構造的な要因の中でも、丸投げは特に対処の手順が明確な領域です。本記事では、丸投げが機能不全を招く構造と、RFP作成・要件定義を自社で内製化する手順を解説します。
丸投げがDXを失敗させる構造
RFP作成プロセスの放棄は、単なる業務の怠慢にとどまりません。発注者が調達機能を失うことで、業務プロセスのブラックボックス化と、際限のない改修コストという2つの問題が連鎖して発生します。
業務プロセスのブラックボックス化
ベンダーはシステム開発の専門家であり、発注者の業務の専門家ではありません。業務プロセスが属人化し、暗黙知に依存した状態で開発を依頼すると、ベンダーはヒアリングで表面的な業務フローをなぞるしかありません。結果として、既存の非効率な業務プロセスや例外処理がそのままシステム化され、複雑化と開発コストの増大を招きます。
発注者とベンダーのインセンティブの不一致
発注者とベンダーでは、目指すゴールとコスト構造が根本的に異なります。この非対称性を理解せずに丸投げすると、要件定義の曖昧さがベンダー側の収益源として利用されます。
| 項目 | 発注者（企業・CIO） | 受注者（外部ベンダー） |
|---|---|---|
| 目的 | 業務効率化・ビジネスモデルの変革 | 契約要件の充足と確実な納品 |
| コスト | 初期費用・保守費用を最小化したい | 追加開発・改修で利益を最大化したい |
| 要件定義 | 自社の複雑な業務要件をすべて満たしたい | 開発リスクを下げ、標準仕様に収めたい |
| 責任範囲 | システム導入による事業成果の創出 | 契約書に記載された機能の実装と稼働 |
ベンダーにとって、納品後のシステムの使い勝手や業務効率の低下は直接的な責任範囲外です。要件定義の曖昧さを突いた追加改修は、ベンダーにとって収益源になり得ます。要件定義を自社で主導しない限り、この構造は変わりません。
自社の調達体制を診断する
自社でシステム要件を定義せず、ベンダーに丸投げしている組織には共通する兆候があります。以下のチェックリストで、自社の現状を確認してください。
- 導入後に「自社の特殊な業務フローに対応していない」ことが本番稼働の直前に発覚する
- ベンダーの言いなりで、不要なオプション機能まで契約している
- 作成された要件定義書の内容を、自社のプロジェクトメンバーが説明できない
- システム障害や不具合が発生した際、原因の特定や一次対応をすべてベンダーに依存している
- 他システムとの連携や機能拡張の可否を、自社で判断できない
該当する項目が多いほど、調達プロセスを自社主導に切り替える必要性が高い状態です。導入目標が「ツールの稼働」自体になっている組織ほどこの傾向が強く、DXの目標がツール導入になっていないかも合わせて点検してください。自社RFPに基づく製品選定と、ベンダー仕様への業務の当てはめでは、主導権の所在からコストの妥当性まで結果が大きく異なります。
| 比較項目 | ベンダーの製品仕様に業務を合わせる | 自社RFPに基づき製品を選ぶ |
|---|---|---|
| 主導権 | ベンダー（製品ベンダー） | 自社（導入企業） |
| 業務プロセスの設計 | 製品の標準機能に業務を強制的に合わせる | あるべき業務の姿（To-Be）に合わせて製品を選ぶ |
| カスタマイズの発生 | 業務が合わないため追加開発が頻発する | 要件を満たす製品を選ぶため追加開発を最小化できる |
| 導入後の業務効率 | 現場の運用負荷が高まり、業務が非効率化する | 業務の最適化が実現し、生産性が向上する |
| ベンダーロックイン | 他システムへの移行が困難になる | システム構成の柔軟性が保たれ、依存を排除できる |
主導権を取り戻すRFP作成と要件定義の内製化
主導権を取り戻すには、要件定義とRFPの作成を自社で完結させる必要があります。RFPと要件定義書は役割が異なります。RFPは複数のベンダー候補から提案を引き出し、1社を選定するためにベンダー決定前に使う文書です。要件定義書は、ベンダー決定後に発注側の要望を技術的な観点も交えて整理し、開発の土台にする文書です。この順序を省略すると、比較検討のないまま1社に発注することになります。
現状業務の可視化とあるべき姿の定義
まず現場の業務フローを書き出し、ボトルネックを特定します。次に、システム導入によって達成したい具体的な目標を定義します。ここまでを自社で完結させることが、ベンダー主導のヒアリングに業務を委ねない条件になります。
システム要件の明文化とRFP作成
現状業務とあるべき姿が固まったら、必要な機能要件と非機能要件を整理し、RFPとしてまとめます。一般的なRFP作成の流れは、プロジェクトチームの編成、現状課題の洗い出し、導入目的の明確化、RFIによる候補ベンダーの情報収集（10社程度から3〜5社に絞り込む）、要求内容の具体化、評価基準の設定、RFPの提出、提案の比較評価、発注先の決定という順に進みます（コンピュータマネジメント「RFP（提案依頼書）とは？」）。
RFPに最低限含めるべき項目は次の3つです。
- 全体の概要：依頼目的、背景、現状の課題、目指すゴール
- 提案依頼内容：ベンダーに盛り込んでほしい提案の範囲
- 選定の進め方：スケジュール、提出期限、評価基準
実行時の落とし穴
RFPを作成しても、評価基準が曖昧なままだと、結局は提案の見栄えでベンダーを選ぶことになり、丸投げと同じ結果を招きます。評価基準は、あるべき業務の姿に対してどの程度応えているかを軸に、事前に数値化・言語化しておく必要があります。
もう一つの落とし穴は、要件定義を「必要な機能のリストアップ」と誤解することです。要件定義の本質は、自社の業務をどう再構築し、システム上でどう実現するかを定義するプロセスです。機能の羅列だけを渡すと、ベンダーは自社の標準パッケージ仕様に業務を合わせる提案をしてきます。要件定義書には、機能一覧の前に「あるべき業務フロー」を明記してください。なお、あるべき業務フローを現場に導入する段階では、評価指標のズレによる現場の反発が別の壁として現れることがあります。調達の主導権を握ることと、現場に定着させることは別の課題として扱う必要があります。
DXの失敗は、技術的な問題ではなく、組織の調達機能の欠落によるものです。RFPと要件定義の作成は、システム導入における発注者側の最低限の義務であり、このプロセスを外部に委ねることは、自社の経営基盤のコントロール権を他者に渡すことを意味します。
