開発会社を変えたいのに変えられない理由。ロックインの構造を分解する

「そろそろ、うちも他の開発会社に変えたほうがいいのかもしれない」。そう思いながら、結局今日も同じ開発会社に連絡している。保守費用は毎年じわじわ上がっている。ちょっとした改修を頼むたびに見積もりの高さに驚く。それでも、いざ「他社に切り替える」という具体的な一歩を考え始めると、頭の中には次々と「でも」が浮かんでくる。他社に頼んでシステムが止まったらどうするのか。今のデータは移行できるのか。そもそも、どこに何を聞けばいいのかすら分からない。

この「変えたいのに変えられない」という感覚は、担当者の決断力の問題ではありません。多くの場合、それは開発会社との関係の中に、乗り換えを構造的に妨げる要因がいくつも積み重なっているために起きています。この記事では、その要因を一つひとつ分解し、どこが自社にとっての本当の障害なのかを見極める方法を解説します。

• 「変えたい」と「変えられない」の間にあるもの: 決断が進まない本当の理由
• 乗り換えを妨げる5つの構造要因: 技術・データ・契約・費用感・心理のそれぞれで何が起きているか
• 障害を要因別に切り分けるチェック方法: どこから手をつければいいか
• 契約を切る前にできる準備: リスクを下げながら選択肢を確保する進め方
• 実際に乗り換えを決めた後の進め方: 移行を安全に進めるための順序

似たテーマとして、当メディアでは以前ベンダーロックインの典型パターンを6つに整理した記事を公開しています。あの記事は「なぜ自社が特定の開発会社に依存する状態に陥るのか」という構造そのものを扱ったものでした。この記事はその続きにあたる内容で、「すでに変えたいという意思がある担当者が、実際に行動しようとしたときに何が壁になるのか」という、より実践に近い一歩を掘り下げます。ロックインの全体像をまだ把握できていない方は、先にそちらを読んでから戻ってきていただくと理解が深まります。

なお、この記事の運営元である株式会社ゼットリンカーはシステムの受託開発を事業としており、開発会社を乗り換える際の受け皿になり得る立場です。ただし、ここで書く内容は特定の乗り換えを煽るものではなく、乗り換えるかどうかの判断はあくまで自社の状況次第だという前提で、中立的に構造を整理します。乗り換えないという判断が正しいケースも当然あります。

この記事で分かること

この記事では、「今の開発会社に不満があり変えたいと考えているが、実際に動こうとすると何が障害になるのか整理できていない」という状態のシステム担当者を対象に、乗り換えを妨げている要因を技術・データ・契約・費用感・心理の5つに分解して説明します。それぞれの要因について、自社がどの程度当てはまるかを確認する具体的な観点と、契約を今すぐ切らなくても始められる準備を示します。

すでに他社への相談を始めている方だけでなく、「変えたいと思っているが、何から手をつければいいか分からない」という初期段階の方にも読んでいただきたい内容です。障害の正体が分からないまま漠然と不安を抱えている状態が、最も動きにくい状態だからです。

「変えたい」のに動けない。それは意思の問題ではない

まず確認しておきたいのは、開発会社を変えたいのに変えられないという状況は、担当者の優柔不断さや行動力の欠如が原因ではないという点です。むしろ、長年同じ開発会社と付き合ってきた企業ほど、乗り換えを妨げる要因が構造的に積み重なっている傾向があります。

これは考えてみれば当然のことです。長く付き合うほど、システムはその開発会社の担当者にしか分からない仕様で作り込まれ、データはその会社の独自形式に最適化され、契約は当初の条件のまま更新され続けます。関係が長いこと自体が、悪い意味での「相性の良さ」を生み、乗り換えのハードルを積み上げていくのです。

• 見積もりを他社に依頼しようにも、何を伝えればいいのか整理できていない
• 今のシステムを止めずに移行できるのか、技術的な見通しが立たない
• 過去のデータがどこまで引き継げるのか分からない
• 保守契約を解約した場合に何が起きるのか、契約書を読んでも判断できない
• 長年の担当者との関係を切ることへの心理的な抵抗がある

これらは一つひとつが独立した障害ではなく、多くの場合、複数が同時に絡み合って「動けない」という状態を作り出しています。次の章から、これらを技術・データ・契約・費用感・心理の5つの軸に整理して見ていきます。

障害の正体を5つに分解する

「開発会社を変えられない理由」とひとくくりに考えてしまうと、何から手をつければいいか分からず思考が止まってしまいます。まずは障害の種類を分解し、自社にとって何が最大のボトルネックになっているのかを特定することが、次の一歩を決める近道です。

この5つは、どれか一つだけを解消すれば乗り換えられるというものではありません。ただし、どこが自社にとって一番重い障害かを特定できれば、次にやるべき行動が具体的に見えてきます。それぞれの軸を順番に見ていきましょう。

障害1: 技術面。中身を理解できる会社が他にいない

最初の障害は、システムの中身を他社が理解できるかどうかという技術的な問題です。長年同じ開発会社に発注し続けてきたシステムほど、仕様書や設計書が整備されないまま、担当者の頭の中にしか仕様が存在しない状態に陥りがちです。

他社に相談しても、「仕様書がないなら、現状のコードを一から読み解く作業から始めなければならず、その分の費用がかかる」と言われて見積もりが跳ね上がることがあります。あるいは、そもそも「中身が分からないものは責任を持って引き受けられない」と断られてしまうケースもあります。これは他社が不親切なのではなく、権利関係や品質保証の観点から、慎重な開発会社ほどそうした案件を避ける傾向があるためです。

• 仕様書・設計書が最新の状態で存在するか
• コード内にコメントや説明が残されているか
• 「なぜこの仕様になっているか」を説明できる人が社内にいるか
• 使われている技術が一般的に広く使われているものか、特定の担当者しか扱えない独自技術か

これらのうち、いくつが「分からない」「存在しない」に該当するでしょうか。該当する項目が多いほど、乗り換え先の開発会社に提示できる材料が乏しく、見積もり自体が取りにくい状態にあると考えられます。この状態は、当メディアの別記事で扱った属人化がそのまま乗り換えの障害に転化したものと言えます。

技術面の障害が大きい場合、いきなり全面的な乗り換えを目指すのではなく、まずは現状のシステムを解読・可視化する作業から始める必要があります。この作業自体は、今の開発会社との契約を解除しなくても、社内で、あるいは第三者に依頼して進めることができます。

障害2: データ面。過去の蓄積を持ち出せるかどうか

2つ目の障害は、データの持ち出しやすさに関するものです。データポータビリティが低いシステムほど、乗り換えの際に「システムは変えられても、過去のデータは失われる」という状況に陥りやすくなります。

これは特に、顧客対応履歴や取引実績など、時間をかけて積み上げてきたデータほど深刻な問題になります。新しいシステムを導入しても、過去のデータが引き継げなければ、実質的に業務の記録が途切れてしまうことになりかねません。

データが引き継げるかどうかは、契約を切った後に慌てて確認するものではありません。契約を続けている間に、一度試しにエクスポートしてみることができます。

• 標準的なCSVやExcel形式でデータを出力する機能があるか
• 実際に出力を試したことがあるか(機能の存在と、実用に耐える品質は別問題です)
• 出力したデータに、業務上必要な項目がすべて含まれているか
• 文字コードや形式が特殊で、他のソフトで開けないということはないか

エクスポート機能自体が存在しない、あるいは存在していても実際に試したことがないという場合は、契約を続けている今のうちに、一度試してみることを強くおすすめします。エクスポートを試すこと自体は、通常は開発会社に断る必要のない社内作業です。もし機能自体が存在しない場合は、開発会社に「標準形式でのデータ出力に対応してもらえないか」と相談してみる価値があります。多くの場合、この相談自体が関係を悪化させることはありません。

障害3: 契約面。解除の条件が契約書に書かれていない

3つ目の障害は、契約そのものの構造です。長年更新され続けてきた保守契約の中には、そもそも「解除するときにどうなるか」という条件が明記されていないケースが少なくありません。

契約を解除したい場合、法律上、開発会社側に無条件でソースコードやドキュメントを引き渡す義務があるわけではありません。契約書に円滑な引き継ぎのための取り決め(解除時のデータ・ソースコードの引き渡し、移行期間の協力義務など)が明記されていて初めて、開発会社側にそれを行う契約上の根拠が生まれます。

• 契約書に解除の予告期間(何ヶ月前に通知するか)が明記されているか
• 解除時のソースコード・ドキュメントの引き渡し条件が定められているか
• 移行期間中、旧システムと新システムを並行稼働させる際の協力義務があるか
• 途中解約の場合の違約金や精算方法が明記されているか

これらが契約書に一切書かれていない場合、開発会社が協力的であれば大きな問題にはなりませんが、関係がこじれた場合や、開発会社自体の経営状況が厳しい場合には、引き継ぎ協力を得られないリスクが残ります。多くの保守契約は準委任契約という形態で結ばれており、成果物の完成を約束する契約ではなく業務の遂行そのものを目的とするため、「どこまでやってもらえるか」が契約書の記載に強く依存します。

契約書を今すぐ変更する必要はありませんが、まずは今の契約書を読み返し、解除条件がどう書かれているかを確認しておくことが、乗り換えの現実的な難易度を把握する第一歩になります。

障害4: 費用感。乗り換えにいくらかかるか見えない

4つ目の障害は、乗り換えにかかる費用の見通しが立たないことです。「今の保守費用は高いと感じるが、他社に変えたらいくらになるのか」「移行作業自体にどれくらいの費用がかかるのか」が分からないまま、漠然とした不安だけが先行してしまう状態です。

費用感が見えない最大の理由は、相見積もりを取っていないことにあります。同じ会社に発注し続けてきた企業ほど、他社の価格水準や見積もりの内訳を知る機会がありません。結果として、「今の費用が高いのか妥当なのか」を判断する基準そのものを持てない状態に陥ります。

• ここ数年で、他社から見積もりを取ったことがあるか
• 今の保守費用の内訳(対応範囲・対応時間・作業単価)を具体的に説明できるか
• 移行作業にかかる費用(データ移行・並行稼働期間・研修等)を見積もったことがあるか
• 「今のまま」と「乗り換えた場合」を比較する材料を持っているか

相見積もりを取ること自体は、今の開発会社との関係を壊す行為ではありません。実際に発注先を変えるかどうかは、見積もりを取った後で判断すればよいことです。まずは市場の相場観を知ることが、費用感の障害を解消する最初の一歩になります。

相見積もりを取るときに、何を伝えればいいのか

いざ相見積もりを取ろうとすると、次に浮かぶ疑問は「何を伝えれば見積もりを出してもらえるのか」です。現行システムの詳細な仕様書がない状態でも、次のような情報を整理しておけば、概算の見積もりを依頼することは可能です。

• 今のシステムで何ができるか(業務のどの部分をカバーしているか)を、機能の一覧としてまとめる
• 利用しているユーザー数や、扱っているデータの量感(件数・容量)をおおまかに伝える
• 今困っていること・変えたい理由を具体的に伝える(単に「変えたい」ではなく、何が不満なのかを言語化する)
• 今の保守費用がどの程度か(金額を出すことに抵抗があれば、レンジだけでも)を伝える

厳密な要件定義書を用意する必要はありません。多くの開発会社は、初回の相談ではこの程度の情報からでも概算の見積もりや、乗り換えの現実的な難易度についての所感を示してくれます。逆に、情報がほとんどない状態で相談しても、「まずは現状調査から」という前提の見積もりになりやすく、比較検討がしづらくなります。可能な範囲で、システムの現状を言葉にしてから相談することをおすすめします。

相見積もりを依頼する際は、1社だけでなく、可能であれば2〜3社に同じ情報を伝えて依頼すると、金額や提案内容の比較がしやすくなります。ただし、あまり多くの会社に同時に声をかけすぎると、対応の手間が増えて息切れしてしまうこともあるため、担当者一人で対応できる範囲に絞ることも大切です。

障害5: 心理面。長年の関係を切ることへの抵抗

最後の障害は、技術やデータ、契約といった実務的な問題とは別の、心理的な抵抗です。長年付き合ってきた担当者との関係、「今までお世話になった」という義理、あるいは「変えて何かトラブルが起きたら自分の責任になる」という不安。これらは実務上の障害と同じくらい、あるいはそれ以上に、担当者の行動を止める力を持っています。

この心理的な抵抗は、決して非合理なものではありません。むしろ、担当者が一人でシステムの全体像を把握し、周囲に相談できる相手が社内に少ない環境では、極めて自然な反応です。失敗したときに支えてくれる体制がない状態で、大きな決断を下すことへの不安は正当なものです。

• 「変える」という決断自体を、自分一人で背負おうとしていないか
• 上司や経営層に、今の状況とリスクを共有できているか
• 「今のままでいる場合のリスク」と「変えた場合のリスク」を両方とも言語化できているか
• 相談できる第三者(他の開発会社、同業の情シス担当者、専門家)に話を聞いたことがあるか

心理的な障害への対処は、一人で抱え込まないことに尽きます。まず社内で状況を共有し、決断の責任を担当者一人に負わせない体制を作ること。そして、実際に他社に話を聞いてみることで、漠然とした不安を具体的な選択肢に変えていくことが有効です。話を聞くだけであれば、費用も発生せず、今の開発会社との関係にも影響しません。

5つの障害を自社に当てはめて優先順位をつける

ここまで見てきた5つの障害のうち、すべてが同じ重さで自社に当てはまっているとは限りません。次のように、自社にとって最も重い障害がどれかを見極めることが、次の一歩を決める上で重要です。

• 技術面が最大の障害の場合: 仕様の可視化・ドキュメント整備から着手する
• データ面が最大の障害の場合: エクスポート機能の実地確認を優先する
• 契約面が最大の障害の場合: 契約書の解除条件・引き継ぎ条項の確認を優先する
• 費用感が最大の障害の場合: まず1社でよいので相見積もりを取ってみる
• 心理面が最大の障害の場合: 社内での状況共有と第三者への相談を優先する

多くの場合、これらは単独では存在せず、複数が絡み合っています。たとえば「契約面の不安」から「心理面の抵抗」が生まれている、あるいは「技術面の不透明さ」が「費用感の見えなさ」に直結している、といった具合です。すべてを一度に解決しようとせず、自社にとって最も動かしやすい一つから着手することをおすすめします。

契約を切る前にできる準備

乗り換えを検討する際、多くの担当者が「まず今の契約を切ってから次を探す」という順序を想像しがちですが、これは避けるべき進め方です。契約を切ってから次の開発会社を探し始めると、システムが宙に浮いた状態で交渉することになり、足元を見られたり、十分な比較検討ができないまま焦って決めてしまったりするリスクが高まります。

安全な進め方は、今の契約を維持したまま、並行して準備を進めることです。

1. 契約書を読み返し、解除条件・引き継ぎ条項の有無を確認する
2. データのエクスポートを実際に試し、持ち出せる状態かを確認する
3. システムの仕様・使用技術・契約内容を一覧化したシステム管理台帳を作る
4. 1〜2社に、今のシステムの概要を伝えた上で相見積もりを依頼してみる
5. 見積もりと自社の状況を照らし合わせ、乗り換えの現実的な難易度とコストを把握する

この5つのステップは、いずれも今の開発会社との契約を継続したまま進められます。相見積もりを取ることも、多くの場合は問題になりません。「市場価格や技術的な選択肢を把握しておきたい」という目的を伝えれば、良好な関係を維持している開発会社であれば、むしろ健全な確認作業として理解を示すことが多いはずです。

準備の結果、「今の開発会社を続けたほうがよい」という結論に至ることも十分にあり得ます。乗り換えは目的ではなく、選択肢を持つことそのものが目的です。準備を進めた結果、今の関係を続ける決断をしたとしても、その準備が無駄になることはありません。次に同じような不安が生じたときに、同じ確認作業を一からやり直す必要がなくなるためです。

実際に乗り換えを決めた場合の進め方

準備の結果、実際に開発会社を乗り換えると決めた場合、進め方の順序を誤ると、システムが止まる、データが失われるといった実害につながりかねません。ここでは、安全に移行を進めるための大まかな順序を示します。

まず重要なのは、新しい開発会社への切り替えを、一気に行わないことです。可能であれば、旧システムと新システムを一定期間並行稼働させ、新システムの動作を業務に影響が出ない範囲で検証してから、完全に切り替える方法が安全です。並行稼働が難しい規模のシステムであれば、影響範囲の小さい機能から段階的に移行する方法もあります。

• 新しい開発会社に、今のシステムの現状(仕様・データ・契約内容)を正確に伝える
• 移行のスケジュールと、旧システムとの並行稼働期間を具体的に決める
• 今の開発会社に契約解除の意思を伝えるタイミングは、新しい開発会社との合意ができてからにする
• データ移行の検証を、本番データで行う前に一部のテストデータで試す
• 社内の関係者(利用部門)に、移行スケジュールと影響を事前に共有する

契約解除の意思を今の開発会社に伝えるタイミングについては、特に慎重な判断が必要です。早すぎると、残りの保守期間中の対応が消極的になるリスクがあり、遅すぎると、引き継ぎに必要な期間が確保できなくなります。新しい開発会社とある程度の合意ができ、移行の見通しが立った段階で伝えるのが、実務上はバランスの取れた進め方です。乗り換え先の選択肢として、内製化を見据えつつ受託開発会社が伴走するという関わり方もあり、TypeScriptフルスクラッチで内製化を支える受託の関わり方で解説されています。

乗り換え検討でよくある3つの失敗パターン

障害を整理して準備を進めても、進め方を誤ると乗り換え自体が失敗に終わることがあります。ここでは、実際によく見られる失敗のパターンを3つ紹介します。準備段階でこれらを意識しておくだけで、避けられる失敗が多くあります。

1つ目は、契約解除を先に伝えてしまう失敗です。 新しい開発会社との合意ができる前に、今の開発会社に「契約を切りたい」と伝えてしまうと、残りの保守期間中の対応が消極的になったり、最悪の場合、必要な引き継ぎ協力を得られなくなったりするリスクがあります。前述の通り、契約解除の意思表示は、新しい開発会社との移行の見通しが立ってから行うのが安全です。

2つ目は、移行を一気に行おうとする失敗です。 「せっかく変えるなら一気に全部新しくしたい」という気持ちは理解できますが、業務で使われているシステムを一度に全面切り替えすると、予期しない不具合が起きたときの影響範囲が大きくなりすぎます。可能な範囲で、機能ごと・部署ごとに段階的に移行する、あるいは一定期間の並行稼働を挟むことで、リスクを分散できます。

3つ目は、価格だけで乗り換え先を決めてしまう失敗です。 相見積もりを取った結果、最も安い会社に飛びつきたくなる気持ちは自然ですが、価格の安さだけで判断すると、今回解説した5つの障害(特に技術面・データ面)への対応力が不足している会社を選んでしまうことがあります。見積もりの金額だけでなく、現行システムの調査・移行にどこまで丁寧に向き合ってくれそうかという提案内容も、あわせて比較することをおすすめします。

• 契約解除の意思表示は、新しい開発会社との合意が固まってから行う
• 移行は一気にではなく、段階的に、または並行稼働期間を設けて進める
• 乗り換え先は価格だけでなく、移行への対応力も含めて比較する

よくある誤解: 「変えられない」と「変えるべきではない」は違う

ここまで乗り換えを妨げる障害について解説してきましたが、一つ強調しておきたいことがあります。それは、「変えられない」という状態と、「変えるべきではない」という判断は、まったく別のものだということです。

今回挙げた5つの障害のいずれも、「乗り換え自体が不可能」であることを意味するものではありません。障害の正体を特定し、順を追って準備すれば、多くの場合は乗り換えの選択肢を現実的なものにできます。一方で、準備を進めた結果、「今の開発会社との関係を続けたほうが、自社にとって合理的だ」という結論に至ることもまったく問題ありません。

避けたいのは、障害の正体を分解しないまま、「なんとなく不安だから」という理由だけで現状維持を選び続けてしまうことです。それは選択ではなく、思考停止に近い状態です。逆に、障害を十分に検討しないまま「とにかく変えたい」という感情だけで動いてしまうことも、システムが止まる、データを失うといった実害のリスクを高めます。この記事で紹介した5つの軸で自社の状況を分解し、根拠を持った上で判断することが、どちらの結論に至るとしても重要です。

この記事のまとめ

開発会社を変えたいのに変えられないという感覚は、担当者の決断力の問題ではなく、技術・データ・契約・費用感・心理という5つの要因が構造的に積み重なった結果です。自社にとってどの障害が最も重いのかを特定できれば、次にやるべき行動は自然と具体的になります。

大切なのは、これらの障害の存在に気づいたからといって、今すぐ契約を切る必要はないということです。契約書を読み返す、データのエクスポートを試す、システム管理台帳を作る、1社だけでも相見積もりを取ってみる。これらはいずれも、今の開発会社との関係を壊さずに、今日から始められる準備です。

準備を進めた結果としてどちらの結論に至るとしても、「障害の正体が分からないまま漠然と不安を抱えている」状態から抜け出すこと自体に価値があります。まずは自社がどの障害に最も強く当てはまるかを、この記事のチェック項目で確認するところから始めてみてください。

より具体的な個別の状況、たとえば開発会社と実際に連絡が取れなくなってしまった場合の対処法や、保守契約が切れたまま動いているシステムのリスクについては、当メディアの他の記事で詳しく扱っています。自社の状況に近いものがあれば、あわせて読んでみてください。