開発が思ったように進まない。報告は毎週もらっているのに、稼働の目処が見えない。社内からは「あの会社に任せて大丈夫なのか」と聞かれている。そういう状況でベンダー変更を調べ始める方が多いと思います。
先に結論をお伝えします。開発途中でのベンダー変更は可能ですが、稼働後の保守移管に比べて難易度が段違いに上がります。作りかけのものを引き継ぐ必要があり、引き継ぎ期間と調査費が別に発生し、しかも遅れの原因が自社側にあった場合は会社を替えても同じことが起きます。この記事では、替えても解決しない場合の見分け方から、判断の基準、契約と権利の確認点、引き継ぎで受け取るものと費用の目安までを、発注側の目線で整理します。
この記事のポイント
- 遅れの原因が自社側にあるなら会社を替えても再発する
- 開発途中の変更は稼働後の移管より難易度が高い
- 動く前にソースコードの引き渡しと著作権の帰属を確認する
- 替えない選択肢として体制交代と範囲縮小も検討に入れる
目次
ベンダー変更を判断する前に確かめること
気持ちとしては一刻も早く替えたい、というのはよく分かります。ただ、次の会社を探し始める前に確かめておくべきことがあります。
替えても解決しない場合がある
最初に向き合っておきたいのは、うまくいっていない原因が本当に開発会社側にあるのか、という問いです。厳しい言い方になりますが、遅れの原因が発注側にある場合、会社を替えても同じことが起きます。しかも引き継ぎのコストを払った分だけ、状況は悪化します。
原因は次の3つに切り分けられます。
| 原因の所在 | 典型的な症状 | 会社を替えて改善するか |
|---|---|---|
| 開発会社側 | 約束した成果物が期日に出てこない。品質が上がらない。担当者が頻繁に交代する | 改善する見込みが高い |
| 発注側 | 質問への回答が遅い。要件が固まらず追加が続く。決裁者が打ち合わせに出てこない | 改善しない。替えても再発する |
| 相性・体制 | 言葉が通じない。報告の粒度が合わない。窓口が機能していない | 体制交代で改善する場合がある |
見分け方のひとつは、課題管理表を一緒に読むことです。未解決のまま残っている項目が「弊社確認中」で埋まっているなら、原因は自社側にあります。逆に「開発会社確認中」が長期間動いていないなら、相手側の問題です。どちらが多いかを数えるだけで、かなり見えてきます。開発が崩れる原因の型については、システム開発の失敗事例と原因で整理しています。
替えるべきかを判断する5つの基準
原因の切り分けをしたうえで、次の基準で判断します。私の感覚では、3つ以上に当てはまるなら変更を本格的に検討する段階です。
| 基準 | 確認すること |
|---|---|
| 改善要求への反応 | 問題を伝えたあと、具体的な改善計画が出てきたか。口頭の謝罪だけで終わっていないか |
| 約束の履行 | 再設定した期日を、続けて2回以上守れなかったか |
| 体制の実態 | 提案時の体制表と実際の担当者が違っていないか。主要メンバーが抜けていないか |
| 技術的な行き詰まり | 実現できない理由の説明が変わり続けていないか。代替案が出てこないか |
| 残りの工程量 | 残作業が全体の半分以上あるか。終盤なら替えるほうが高くつく |
基準を当てはめるときは、感覚ではなく記録で判断してください。議事録と課題管理表を並べて、いつ何を依頼し、いつ回答が返ってきたかを時系列に並べるだけで、印象と実態のずれが見えてきます。社内で変更を提案する場面でも、この時系列があるかないかで説得力がまったく違います。
最後の基準は見落とされがちです。残りが2割の状態で替えると、引き継ぎと再調査に時間を使ったうえで、結局その2割を新しい会社が作ることになります。金額も期間も、そのまま完走したほうが安く済むケースが少なくありません。逆に残りが半分以上あるなら、早く決断したほうが傷は浅くなります。
開発途中と稼働後で難易度が違う
ここは整理しておく価値があります。ベンダー変更を扱う記事の多くは、稼働後の保守運用を別の会社へ移す話を前提にしています。すでに動いているシステムがあり、仕様も固まっているため、引き継ぐ対象がはっきりしています。
ところが開発途中の変更はまったく別物です。作りかけのソースコードがあり、設計書は未完成で、どこまでが完成しているのかも当事者しか分かりません。新しい会社は、他社が書いた未完成のコードを読み解いてから作業を始めることになります。ここに調査期間が必要になり、しかも「読んでみたら想定より悪かった」という理由で見積もりが後から上がることもあります。
目安として、稼働後の保守移管なら引き継ぎに1〜2か月、開発途中の変更なら調査だけで1か月前後、そこから再見積もりという流れになります。あくまで一般的な目安なので、実際の判断は個別の状況で確認してください。
もうひとつ、開発途中ならではの難しさがあります。伝える順番です。稼働後の移管であれば、契約の更新時期に合わせて淡々と切り替えられます。ところが開発途中の場合、旧ベンダーに解約の意思を伝えた時点から、相手の協力度は確実に下がります。作業が止まり、質問への回答も遅くなる。にもかかわらず、こちらはまだ引き継ぎ資料を受け取っていない状態です。
ですから順番としては、次の会社の目処が立ち、契約条項の確認も済んでから伝えるのが基本になります。逆に、先に解約を伝えてから次を探し始めると、宙ぶらりんの期間が長引きます。私が現場で見てきた限り、この順番を守れたかどうかで、引き継ぎの質はかなり変わります。
替えない場合の打ち手
変更は最後の手段です。その手前に、コストの小さい選択肢が3つあります。
- 担当者の交代を申し入れる。会社は替えず、プロジェクトマネージャーや主要メンバーの入れ替えを求める
- 稼働範囲を分ける。今回は業務が回る最小限だけ完成させ、残りを次期に回す
- 報告のルールを変える。週次の報告項目を数字で定義し、完了した画面数などで進捗を測る
特に1つ目は、相性や体制が原因の場合に効きます。会社としての技術力に問題がないなら、人を替えるだけで動き出すことは実際にあります。言い出しにくいと感じるかもしれませんが、契約を切られるより体制を替えるほうが相手にとっても軽い話です。伝え方としては、個人を責めるのではなく「この体制では進まないので変えてほしい」と事実で伝えるのが穏当です。
ベンダー変更の進め方と引き継ぎの実務
変更を決めた場合の実務に入ります。順番を間違えると、交渉の材料を失ったまま話を進めることになります。
契約と権利を先に確認する
新しい会社を探し始める前に、今の契約書を開いてください。ここを確認せずに解約を伝えると、手元に何も残らない状態になりかねません。
| 確認する条項 | なぜ重要か |
|---|---|
| 著作権の帰属 | 開発会社に残っている場合、他社が改変できない。原則は作った側に残る |
| ソースコードの引き渡し | 納品物に明記されていないと、渡してもらえない可能性がある |
| 中途解約の条件 | 予告期間や違約金の定めがあるか。請負か準委任かで扱いが変わる |
| 検収済みの範囲 | どこまでが支払い済みで、どこからが未完成なのかの線引き |
| 再委託の有無 | 下請けが入っている場合、引き継ぎ先が複数になる |
著作権が開発会社に残っているケースは珍しくありません。この状態で他社に改変を頼むと権利侵害になる可能性があるため、譲渡か利用許諾の交渉が必要になります。ロックインを避ける契約の作り方は、ベンダーロックインの対策と脱却の方法で詳しく整理しています。
引き継ぎで受け取るもの
引き継ぎは、受け取るものを先に一覧にしてから動きます。口頭で「一式ください」と伝えると、たいてい足りません。
- ソースコード一式と、バージョン管理の履歴
- 要件定義書、基本設計書、詳細設計書。未完成でも現状のまま
- データベースの定義と、投入済みデータ
- 開発環境と検証環境の構成情報、必要なライセンス
- 各種アカウントと権限。クラウドの管理者権限を含む
- 課題管理表と議事録。判断の経緯が分かるもの
- テストの計画と実施結果
このうち抜けやすいのがバージョン管理の履歴とアカウント類です。ソースコードのファイルだけもらっても、どういう経緯でその実装になったのかが分かりません。クラウドの管理者権限が旧ベンダー名義のまま残っていると、後から連絡が取れなくなったときに詰みます。新しい会社を選び直す段階では、同じ基準で比べられるようにベンダー選定比較表テンプレートを使うと社内説明もしやすくなります。会社選びの観点そのものはベンダー選定の進め方と選定基準にまとめています。
費用と期間はどれだけ増えるか
変更には追加費用がかかります。どこにお金が出るのかを把握しておくと、社内の説明が通りやすくなります。
| 発生する費用 | 内容 |
|---|---|
| 調査・現状把握 | 新しい会社が既存のコードと設計を読み解く作業 |
| 引き継ぎ対応 | 旧ベンダーの説明対応。契約に定めがなければ有償になる |
| 手戻りの作り直し | 引き継げない部分を作り直す分 |
| 二重契約の期間 | 旧ベンダーの保守を止められない間の重複 |
期間については、調査に1か月前後、そこから再見積もりと契約で1か月、実作業の再開までに合計2か月ほど見ておくと現実的です。もちろん規模と状態によって大きく変わるので、これも目安として扱ってください。旧ベンダーの協力が得られるかどうかで、この期間は倍近く変わります。だからこそ、解約を伝える前に契約条項を確認しておくことが効いてきます。
ベンダー変更に関するよくある質問
- Q. 開発途中で解約すると、払ったお金は返ってきますか？
- A. 契約の形態によって扱いが変わります。請負契約で検収が済んでいない範囲については、完成していない以上、どこまで支払い義務があるのかが争点になります。準委任契約の場合は作業した時間に対して支払う形なので、実施済みの分は原則として戻りません。いずれにしても、契約書の中途解約条項と検収の記録が判断の材料になります。金額が大きい場合は、自己判断で解約を通知する前に専門家へ相談することをおすすめします。
- Q. 旧ベンダーが引き継ぎに協力してくれない場合はどうすればいいですか？
- A. まず契約書に引き継ぎ義務の定めがあるかを確認します。定めがなければ、旧ベンダーには協力する義務がないため、有償での対応を依頼する形になります。感情的な対立になると協力を得にくくなるので、解約の意思を伝える段階から、引き継ぎ範囲と費用を条件として提示しておくと話が進みやすくなります。契約終了後に依頼するより、終了前に合意しておくほうが確実です。
- Q. 新しい会社には、前の会社との経緯をどこまで話すべきですか？
- A. 事実は隠さず伝えたほうが結果的に得です。何がどこまで完成しているのか、なぜ替えることになったのかを共有しないと、新しい会社は正確な見積もりを出せません。ただし、前の会社への不満を中心に話すと、新しい会社は「この発注者は要求が厳しい」と受け取ることがあります。起きた事象と残っている成果物を、事実として淡々と伝えるのが無難です。
