システム開発・運用の外注先は乗り換えられます。ただしその難易度は、ソースコード・設計書・データ・契約名義の4つが自社に帰属しているかどうかで大きく変わります。4つが揃っていれば他社への引き継ぎは現実的な選択肢になり、揃っていなければ実質的な「作り直し」に近づきます。
特定の外注先に依存して身動きが取れなくなる状態を「ベンダーロックイン」と呼びます。この記事では、いま外注を検討している方にも、すでに任せている外注先との関係を見直したい方にも使える確認ポイントと質問例を、専門知識を前提とせずに解説します。
「替えたいのに、替えられない」はなぜ起きるのか
まず押さえておきたいのは、ベンダーロックインの多くは業者の悪意で起きるのではなく、業界の商習慣と契約の初期設定で起きる、ということです。
- ソースコード（システムの本体にあたるプログラム一式）を納品せず、「使う権利」だけを提供する契約形態が珍しくない
- 設計書や仕様書が最初から作られていない、あるいは全体像と実態が合わなくなっている
- サーバーやドメインなどの契約が外注先の名義になっている
こうした状態が数年続くと、「システムの中身を知っているのは今の外注先だけ」という構造ができあがります。
今の業者に大きな不満があるわけではない。ただ、この1社に何かあったら、うちの業務は止まるのではないか。値上げの打診をされたら、断れる気がしない。そう感じているなら、それはロックインの入り口にいるサインです。
乗り換えの可否を分ける「4つの帰属」
1. ソースコードは納品され、所有権は自社にあるか
住宅で例えると、ソースコードとは、システムがどう動くかを記述したプログラムファイル一式のことで、システムの本体にあたります。これが自社の手元に納品されていて、所有権も自社にあれば、別の会社がシステムを引き継いで改修・運用することができます。
注意したいのは、「システムを使えている」ことと「ソースコードを所有している」ことは別だという点です。月額で「使う権利」だけを借りている契約（ライセンス提供型）の場合、解約するとシステム自体が使えなくなることがあります。
2. 設計書と、改修の記録は残っているか
ソースコードが建物だとすれば、設計書は図面です。図面がなくても建物は建っていますが、増改築を頼まれた工務店は、壁の中の配線を一つひとつ調べ直すことになります。設計書のないシステムの引き継ぎも同じで、引き継ぐ側の調査に時間と費用がかかります。
なお、全体の設計書が改修のたびに完全に更新され続けているケースは、実務ではそれほど多くありません。現実的に効くのは、システムの全体像を示す資料があることと、改修のたびに「何を・なぜ変えたか」が要件定義書や改修記録として残っていることの2点です。この2つをたどれる状態であれば、引き継ぐ側は経緯を追うことができます。
3. データを自社の判断で取り出せるか
システムの中に蓄積された顧客情報・受注履歴・商品データなどは、事業そのものの資産です。確認すべきは、これらを自社の判断でいつでも取り出せるか（エクスポートできるか）、そして取り出したデータがCSVなどの汎用的な形式か、です。
データが外注先のシステム内でしか読めない形式になっている場合、乗り換え時にはデータ移行そのものが大きな壁になります。
4. サーバーやドメインの契約は自社名義か
意外と見落とされやすいのが、サーバー、ドメイン（自社サイトのURL）、決済サービスなどの契約名義です。これらが外注先の名義になっていると、関係を解消した時点でサービスが止まる、あるいは名義変更の交渉が必要になるリスクがあります。原則は自社名義で契約し、管理を外注先に委託する形です。
契約前なら、この4つを質問する
これから契約する、あるいは契約を更新するタイミングであれば、次の質問をそのまま使ってください。
- 「ソースコードは納品されますか。所有権はどちらに帰属しますか」
- 「設計書・仕様書は納品物に含まれますか。改修の内容は記録として残りますか」
- 「解約する場合、データはどの形式で受け取れますか」
- 「サーバーやドメインの契約は、自社名義にできますか」
契約書では「権利帰属」「知的財産権」といった条項に答えが書かれています。読み解きが難しければ、見積もりの段階で上の4つを文面で確認しておくだけでも、後々の状況は大きく変わります。
契約形態によって変わる納品物の内容や領域
なお、契約の形にも軽く触れておくと、月額の支払いの中で開発まで進める形（準委任型と呼ばれます）では、仕事の「完成」への義務や納品物の定義が、そもそも契約に含まれていないことがあります。この形が一概に悪いわけではありませんが、納品物が定義されない契約ほど、上の4点を書面で確認する重要性は高まります。
参考: 準委任と請負はどう違う？システム開発の総額を着手前に確定させる方法
ひとつ補足すると、開発会社が「どの顧客にも共通して使える汎用的な部品」の権利を自社に留保するのは、業界の標準的な取り決めです。経済産業省が公表している契約のひな形「情報システム・モデル取引・契約書」でも、納入物の著作権を発注者に移転する案において、汎用的な利用が可能なプログラムの著作権は開発会社側に留保する構成が示されています（第45条）。
よって、留保そのものを警戒する必要はありません。確認すべきは、自社の業務に固有の部分（業務の流れを実現する処理、画面、データ）が自社に帰属するかどうか。あわせて、留保される「汎用的な部品」がどの範囲を指すのかを納品時までに確認しておくと、後々の解釈違いを防げます。
すでに依存状態にある場合の現実的な進め方
いまの時点で4つが揃っていなくても、打てる手はあります。順番が大切です。
まずはデータの確保から始めましょう。バックアップを自社でも保管する、定期的なエクスポートを依頼する。これは乗り換えるかどうかに関わらず、事業継続の観点でやっておくと安心です。
次に、ソースコードや設計書の開示・買い取りを打診します。交渉次第で応じてもらえることもあります。このとき、対立の構図を作らないことが重要です。「御社への不満ではなく、事業継続リスクの整理として」という伝え方であれば、外注先側も応じやすくなります。
開示が得られない場合、乗り換えは「引き継ぎ」ではなく「作り直し」に近い判断になります。それでも、次の発注先には本記事の4点を最初に確認しましょう。重要なのは同じ構造を繰り返さないことです。
外注先乗り換えに関するよくある質問
Q. ソースコードの納品を断られました。おかしいことでしょうか？
A. 珍しいことではありません。ソースコードを開発会社側が保有し、お客様は利用権のみを持つ契約形態は、商習慣として広く存在します。ただしその場合、乗り換えや内製化の自由度は下がります。月額費用が割安に見えるときは、この自由度と引き換えになっていないかを確認した上で、納得して契約するのが安心です。
Q. 外注先の乗り換えには、費用はどのくらいかかりますか？
A. 状況によって大きく変わるため、一律の相場は示せません。ソースコード・設計書・データが揃っていれば、現行システムの調査と引き継ぎから始められます。揃っていなければ、再構築に近い規模になることもあります。見積もりを取る際は、「引き継ぎ」と「作り直し」のどちらの前提かを最初に確認してください。
Q. 「外部IT部門」のような形態に切り替える場合も、同じ確認が必要ですか？
A. 必要です。どのような形態・呼び方であっても、確認すべき4点は変わりません。なおハイファイブクリエイトの外部IT部門サービスでは、納品物の帰属を契約時に明示しています。外部IT部門という選択肢そのものについては、解説記事「外部IT部門とは？」をご覧ください。
まとめ: 重要なのは自社の所有・管理下にあるかどうか
乗り換えの可否を分けるのは、ソースコード・設計書・データ・契約名義の4つが自社に帰属しているかです。判断の軸は2つで、「いま4つが揃っているか」と「揃っていないなら、どれから確保するか」。この2点を整理すると、いま取るべき現実的な一手が見えてきます。
ハイファイブクリエイトでは、「中小企業のための外部IT部門」として業務システムの設計・開発・運用を一貫してお引き受けしており、開発したシステムのソースコードと設計書は貴社に納品し、所有権は貴社に帰属します。将来、他社へ引き継ぐことも、内製化することも自由です。
弊社では、顧客業務とシステムへの理解を、担当者個人の頭の中ではなく設計書・運用記録・システムそのものに蓄積し続けることに置いています。契約で縛らなくても選ばれる状態を保ち続けることが、開発会社側の健全な緊張感になると考えています。
外部IT部門という選択肢そのものについては、解説記事「外部IT部門とは？社内採用・スポット外注と比べてわかる第三の選択肢」で詳しく整理しています。長期の伴走体制については外部IT部門サービスのページをご覧ください。いまの外注先との関係を整理したい、という段階のご相談も可能です。
コメントを残す