先代の社長が高齢を理由に会社をたたむと聞かされたのは、決算の打ち合わせが終わったあとの立ち話でした。20年近く自社の基幹システムを任せてきた開発会社です。担当者はいつも同じ顔ぶれで、電話一本で融通を利かせてくれる、家族のような付き合いでした。しかしその安心感が、いざという時の落とし穴になっていたことに、経営者は数週間後に気づくことになります。
ソースコードの所在を尋ねると、担当者は「たぶん先代のパソコンに」と言葉を濁しました。仕様書は最初の納品時に一度作られたきりで、その後10年分の改修履歴はどこにも残っていません。サーバーの契約者名義は開発会社のままで、ドメインの管理画面のパスワードも誰も把握していない。会社をたたむ日まで、あと3か月。新しい開発会社を探しながら、経営者は「これは自分たちの会社のシステムなのに、なぜ自分たちが何も持っていないのか」という感覚に襲われたといいます。
この記事は、そうした崖っぷちに立たされた経営者やシステム担当者のために書きました。乗り換えは怖い決断です。しかし長年の関係を断ち切る勇気を持った人だけが、自社のシステムを本当の意味で自分たちのものにできます。壁を越えて前に進もうとするあなたのために、実務の手順を一つひとつ整理します。
なぜ開発会社を乗り換えることになるのか
システム開発会社との関係が終わりを迎える理由は、想像以上にありふれています。冒頭の例のような後継者不在による廃業は、地方の中小規模な開発会社では珍しくありません。ある調査では、IT関連の中小企業の休廃業・解散件数はここ数年高止まりしており、特に社長の年齢が60代以上の会社では後継者不在率が半数を超えるというデータもあります。取引先が突然消えるリスクは、他人事ではないのです。
もう一つ多いのが、対応の質の低下です。担当者が変わるたびに引き継ぎが雑になり、簡単な修正依頼にも「確認します」を繰り返すだけで数週間が過ぎる。過去のいきさつを知らない新人担当者が、的外れな見積もりを出してくる。長年の付き合いだからと大目に見てきたことが、積み重なって限界を迎えます。
費用の高騰も見逃せない理由です。保守契約の更新のたびに料金が上がり、内訳を聞いても「技術者の人件費上昇のため」としか説明されない。相見積もりを取ってみると、同じ規模の保守業務が半額以下で受けられることに気づき、これまで払ってきた金額への疑問が一気に膨らむケースもよくあります。
理由が廃業であれ、不満の蓄積であれ、根っこにあるのは同じ問題です。長年の関係に依存しすぎて、自社のシステムがブラックボックス化していたということです。乗り換えを考え始めた今こそ、そのブラックボックスに光を当てるタイミングです。
乗り換え前に確認すべきこと
新しい開発会社を探し始める前に、まず手元にある情報を棚卸しする必要があります。ここを飛ばして先に進むと、あとで必ず痛い目にあいます。少なくとも次の3点は、現行ベンダーに連絡を取る前に社内で確認しておいてください。
ソースコードの所有権
契約書に「成果物の著作権は発注者に帰属する」という条項があるかどうかを確認します。この一文があれば、原則としてソースコードの提供を求める権利は発注者側にあります。逆に条項がない、あるいは著作権が受注者側に残る契約になっている場合、ソースコードの提供は開発会社の善意に頼らざるを得なくなります。契約書が見当たらない場合は、発注時のメールや発注書だけでも探し出してください。
ドキュメントの有無
仕様書、設計書、データベースの構成図、API仕様、これまでの改修履歴。どこまで残っているかを確認します。多くの中小企業では、初回納品時のドキュメントしか存在せず、その後の改修は口頭やチャットのやり取りだけで進んでいることがほとんどです。ドキュメントが乏しいと分かった時点で、それは新ベンダーへの引き継ぎ費用が上振れする要因になると心得ておいてください。
サーバーやドメインの管理権限の所在
サーバーの契約者名義、ドメインの登録者情報、管理画面のログイン情報。これらが開発会社名義になっていないかを確認します。名義が開発会社のままだと、廃業や関係悪化と同時にサービス自体が止まるリスクがあります。契約者名義を自社に変更する、あるいは自社で新規に契約し直して移設するという判断が早いほど、リスクは小さくなります。
この3点を確認する作業は、地味で骨が折れます。しかし、ここで手を抜かなかった担当者だけが、次の交渉を有利に進められます。自社のシステムの実態を正確に把握すること自体が、乗り換えの第一歩です。
引き継ぎを成功させる実務手順
確認作業が終わったら、いよいよ乗り換えの実務に入ります。ここで焦って現行ベンダーとの関係を一方的に断ち切ると、後述する失敗パターンにそのまま陥ります。円満な移行を目指しながら、着実に手順を踏んでいきましょう。
1. 現行ベンダーとの円満な移行交渉
まず現行ベンダーに、契約を終了する意向と時期を明確に伝えます。感情的な不満をぶつけるのではなく、事業判断として伝えることが肝心です。長年付き合ってきた相手であるほど、伝える側にも勇気が要ります。しかしその一言を切り出せた担当者が、次のステージに進めます。
その上で、成果物一式の引き渡しを正式に依頼します。ソースコード一式、データベースのバックアップ、ドキュメント、サーバーやドメインの管理権限、これらを書面で依頼し、いつまでに何を渡してもらうかのスケジュールを合意します。口頭でのやり取りだけで済ませず、メールなど記録に残る形でのやり取りに切り替えてください。
2. 新ベンダーへの引き継ぎ期間の設け方
新しい開発会社が決まったら、いきなり全業務を切り替えるのではなく、引き継ぎ期間を設けます。目安としては、システムの規模にもよりますが1か月から3か月程度です。この期間に新ベンダーはソースコードを読み解き、動作環境を再現し、疑問点を洗い出します。可能であれば、現行ベンダーに一時的な質問対応を依頼できると、引き継ぎの精度は格段に上がります。
3. 並走稼働でのリスク低減
特に基幹システムなど止まると業務に大きな影響が出るものは、旧環境と新環境をしばらく並走させることを検討してください。新環境で一定期間動かしてみて、想定通りの挙動を確認できてから、旧環境を停止する。この二段構えを取ることで、切り替え直後の障害リスクを大幅に減らせます。並走稼働にはサーバー費用が二重にかかる期間が生じますが、業務停止のリスクを考えれば必要な投資です。
ここまでの手順を丁寧に踏むことは、決して臆病な行為ではありません。むしろ、長年の関係を断ち切る決断をした上で、なお会社の業務を守り抜こうとする責任感の表れです。壁を壊すだけでなく、壊した先にきちんと橋を架ける。それができる担当者こそ、本当に信頼される存在になります。
引き継ぎ時に発生しがちな費用と、その相場感
乗り換えには相応の費用がかかります。あらかじめ想定しておくことで、いざという時の判断が速くなります。
- ソースコード解析・現状把握費用: システムの規模によりますが、中小企業向けの業務システムであれば30万円から100万円程度が目安です。ドキュメントがほとんど残っていない場合は、この費用がさらに上振れします。
- データ移行費用: データベースの構造を新環境に合わせて調整する作業が必要になることが多く、10万円から50万円程度が一般的な相場です。
- サーバー・ドメイン移設費用: 名義変更や新規契約の手続き自体は数万円程度で済むことが多いですが、動作環境の再構築を含めると別途費用が発生します。
- 並走稼働期間のインフラ費用: 旧環境と新環境を同時に維持する期間のサーバー費用が二重にかかります。1か月あたり数万円から十数万円が目安です。
- ドキュメント整備費用: 引き継ぎ後、新ベンダーが仕様書や設計書を新たに作成する場合、システムの規模に応じて20万円から80万円程度かかることがあります。
合計すると、規模の大きくないシステムでも数十万円から100万円を超える出費になることは珍しくありません。これを「無駄な出費」と捉えるか、「これまで見えていなかった自社システムの実態を、初めて正確に把握するための投資」と捉えるかで、乗り換えに向き合う姿勢は大きく変わります。
よくある失敗パターン
実務手順を踏まなかった場合、どのような事態が起こるのか。よくある失敗パターンを知っておくことも、リスクを避ける助けになります。
最も多いのが、現行ベンダーとの関係が悪化した勢いで契約を急に打ち切ってしまうケースです。感情的な対立のまま契約解除を通告すると、ソースコードやドキュメントの引き渡しが滞り、最悪の場合は連絡が取れなくなります。結果として新ベンダーはゼロからシステムを作り直すことになり、当初の見積もりの何倍もの費用と期間がかかってしまいます。
次に多いのが、引き継ぎ期間を設けずに一気に切り替えてしまうケースです。旧システムを止めた直後に新システムで不具合が発覚し、業務が数日間止まってしまう。並走稼働の重要性を軽視した結果、目先のコストを削ったつもりが、業務停止による損失でかえって高くつくというパターンです。
また、口約束だけで進めてしまい、成果物の引き渡し範囲があいまいなまま契約が終了してしまうケースもあります。ソースコードは受け取れたが、サーバーの管理権限だけが旧ベンダー名義に残ったままだった、というような部分的な取りこぼしは、後になって思わぬトラブルの火種になります。
これらの失敗に共通するのは、乗り換えを「感情的な決断」で終わらせてしまい、「実務のプロセス」として設計しきれなかったという点です。長年の関係を断ち切る決意そのものは正しくても、その決意を形にする手順が伴わなければ、望まない結果を招いてしまいます。
まとめ
長年付き合ってきた開発会社を乗り換えるという決断は、簡単なものではありません。慣れ親しんだ相手との関係を自ら断ち切り、まだ知らない新しい相手に自社の大切なシステムを託す。それは、これまで築いてきたものを手放す痛みを伴う選択です。しかし、その痛みの先にしか、自社のシステムを本当の意味で自分たちの手に取り戻す道はありません。
ソースコードの所有権を確認し、ドキュメントの有無を把握し、サーバーとドメインの管理権限の所在を洗い出す。現行ベンダーと円満に交渉し、新ベンダーとの引き継ぎ期間を確保し、並走稼働でリスクを抑える。地味で手間のかかる作業の一つひとつが、最終的に会社を守ります。
壁を越えて働くというのは、派手な決断だけを指す言葉ではありません。むしろ、こうした地道な実務を一つずつ積み上げる粘り強さこそが、壁を越える力そのものです。今まさに乗り換えを検討しているあなたも、その一歩を踏み出しているところです。焦らず、しかし着実に、手順を踏んで前に進んでください。