システム外注が丸投げになるのはなぜか——発注側が握り続けるべき3つの決定

外注が「丸投げ」になる構造

システム開発を外注すると、進捗管理はベンダーが担い、仕様の細部もベンダーが判断するようになる。気づけば発注側の担当者は「報告を受ける人」になっている。これが丸投げの典型的な経路だ。

ベンダーの立場から見れば、依頼された仕様を実装することが仕事であり、発注側の業務判断を代替する権限も情報も持っていない。「お任せします」と返ってくるとき、ベンダーは自らの経験則で判断を埋めるしかない。その結果が、「動くが使いにくいシステム」になる。

見積の段階で前提条件と工程を確認することは最低限の入口だが（システム開発の外注見積を読む——内訳で確かめる工程と前提条件）、それ以上に開発が進んでからの意思決定の所在が、プロジェクトの成否を分ける。

社内に置き続けるべき3つの決定

丸投げを防ぐには、発注側がどの判断を手放してはいけないかを事前に明確にしておく必要がある。実務上、次の3つが特に重要だ。

1. 業務の優先順位 ——どの業務から手をつけるか、どの機能を先に作るかは発注側の経営判断だ。売上に直結するプロセスと後回しにできる作業を区別できるのは、日常業務を知る自社だけである。ベンダーにリストを渡すことはできても、順序を決める権限は渡せない。

1. データの正本 ——顧客データ・商品マスタ・在庫情報など、どのシステムの値が「正しい値」かを決めるのは発注側の仕事だ。複数システムが混在する環境では、正本の所在を宣言しない限り、整合性のとれない設計が選ばれることがある。データの正本は、開発が始まる前に文書で確定させる。

1. 受入基準 ——「できた」の定義は発注側が持つ。テスト仕様書をパスすることと、業務で実際に使えることは別問題だ。どういう状態になれば本番稼働を認めるかを、発注側が言葉にして書き出しておく必要がある。この基準が曖昧なまま検収を迎えると、ベンダー側の完成判断で納品が成立してしまう。

業務の優先順位・データの正本・受入基準の3つは、業務知識に根ざしているため、信頼できるベンダーでも代わりに決めることができない。

3つを社内に置き続けるための実務

これら3つを社内に維持するには、担当者と権限を開発開始前に割り当てておくことが前提になる。

• 業務優先順位の担当者: 現場責任者か経営者。開発の途中で仕様変更が生じたとき、優先順位を再判断できる人間を事前に決める。
• データ正本の管理者: データ種別ごとに「正本はどのシステム」かを一覧化し、プロジェクト開始時にベンダーへ渡す。
• 受入基準の起票者: 誰が何を確認するかを、開発開始前に文書で決めておく。QAフェーズに入ってから設計しても遅い。

基幹システム入れ替えの費用はなにで決まるかでも触れているように、外注コストが後半に膨らむ主因は手戻りだ。意思決定の所在を最初に固めることは、コスト管理とも直結する。

外注は実装を外に出すことであって、判断を外に出すことではない。3つの決定を発注側が握り続ける体制を設計段階で固めること——それがプロジェクト全体の品質を決める起点になる。こうした体制設計の伴走が必要な場合は、しぼるで対応している。