システム開発会社を変えたい……途中でベンダー変更はできる？

「今の開発会社との関係を断ちたい。途中から別の会社に変えられるか？」

すでにプロジェクトが進行中で、ベンダー変更を検討している——これはかなり深刻な状況だ。品質、納期、コミュニケーション、追加費用——どれかが限界を超えている。

結論から言う。変更は可能だが、条件次第でコストとリスクが大きく変わる。 新しいベンダー選びの前に、何が問題かを構造化することが先だ。

結論：変更可否を決める判断表

条件	変更しやすい	変更しにくい／高い
成果物の権利	発注者に帰属	ベンダー側に残る
進捗と品質	低進捗でも品質が追跡可能	高進捗だが品質が不透明
残り期間	6ヶ月以上ある	リリースまで短い
現状の可視化	棚卸しができる	何ができたか分からない

ベンダー変更が必要になる典型理由

• 品質が基準を満たさない
• 納期遅延が改善されない
• コミュニケーションが機能しない
• 追加費用が際限なく膨らむ
• 担当者が次々と変わる

いずれも、早期に兆候があったケースがほとんどだ。変更は最後の手段だが、改善要求が効かないなら遅らせるほど高くなる。

現場で見た、引き継ぎと作り直しの分岐

匿名化した一例だ。進捗表示は「70%完了」だったが、受け入れ可能な品質ではなかった。新ベンダー候補にコード監査を依頼したところ、テストがほぼなく、主要モジュールの責務が混線していた。

選択肢は2つあった。

1. 引き継ぎ＋大規模修正（当初残予算の約40%相当の追加）
2. コアだけ残して周辺を作り直し（見た目は高いが、期間は短い見込み）

発注側は感情的には「せっかく70%」と思ったが、監査結果を見て作り直し側を選んだ。結果として、引き継ぎ地獄を避け、3ヶ月で安定リリースに届いた。進捗率の数字より、品質と権利の実態が判断を決める。

途中変更の可否を決める3つの条件

1. 成果物の権利関係

契約書で、ソースコード・設計書・ドキュメントの権利が誰に帰属するか確認する。発注者に帰属していなければ、持ち出せない。

2. 現在の進捗と品質

完成度30%のプロジェクトと80%では、変更の意味がまったく違う。中間成果物の品質が低い場合、引き継ぎより作り直しの方が早いこともある。

3. 残り期間と事業インパクト

リリースまで3ヶ月なら、変更の判断は急がなければならない。6ヶ月以上あれば、段階的な引き継ぎが可能。

ベンダー変更の手順

1. 現状の棚卸し — 完成した機能、未完了の機能、品質状態を可視化
2. 成果物の確保 — ソースコード、DB、設計書、インフラ情報を発注者側に移管
3. 新ベンダーの技術評価 — 既存コードを引き継げるか、技術監査を実施
4. 引き継ぎ計画 — 新旧ベンダーの並行期間、知識移転の設計
5. 再見積もり — 残スコープに対する現実的な工数と期間

費用感の目安

状況	追加コストの目安
進捗30%以下、品質良好	引き継ぎ費用: 全体の10〜20%
進捗50%、品質に問題	引き継ぎ＋修正: 全体の20〜40%
進捗70%以上、品質問題大	作り直し検討: 当初予算の50%以上

判断軸：今すぐ変える／まだ改善要求する

状況	推奨
体制・品質の改善要求に応じない	変更検討を開始する
権利が取れず成果物が手元にない	まず成果物移管を優先交渉
進捗は高いが品質監査が壊滅的	作り直し前提で再見積もり
問題はコミュニケーションのみ	PM交代など契約内改善を先に試す

変更を避けるために

ベンダー変更は最後の手段だ。以下を早期に実施すれば、多くの場合は回避できる。

• 月次の品質・進捗レビュー
• 問題の早期エスカレーション
• 契約上の改善要求（体制変更、PM交代等）

次に確認すること

1. 契約上の成果物権利は発注者側か
2. 現状の棚卸し（機能・品質）はできたか
3. 改善要求は文書で出し、期限を切ったか
4. 新ベンダー候補の技術監査は入れたか
5. 引き継ぎと作り直しの費用比較はあるか
6. 事業側のリリース制約は明確か

よくある質問

Q. 現ベンダーに知られずに次を探せますか？

探索自体は可能だが、成果物の正式移管や並行引き継ぎでは開示が必要になる。隠したまま進めると、権利とアクセスで詰まりやすい。

Q. 変更すると必ず作り直しになりますか？

ならない。品質とドキュメントが追えるなら引き継ぎで足りる。監査なしで「続ければ安い」と判断するのが危険なだけだ。

まとめ

途中変更は可能だが、最初から防ぐ方が圧倒的に安い。

すでに困っている場合は、現状の棚卸しから始める。新しいベンダー選びの前に、何が問題かを構造化することが先だ。

---

ベンダー変更・引き継ぎ支援の相談は、お問い合わせフォーム からどうぞ。