ベンダーロックインを診断する。開発会社を変える前の5点
開発会社の対応に大きな不満はありません。見積書も毎月届き、障害が起きれば担当者から返事が来ます。ところが、自社の担当者はリポジトリを開けず、クラウドの管理者も開発会社だけです。
ベンダーロックインは、関係が悪化してから初めて起きる問題ではありません。平時に別のエンジニアがソースコードを取得し、検証環境を作り、事業データを取り出せるかで診断できます。
僕なら、開発会社を替えるか検討する前に五つの場所を開きます。診断で欠けた物を次回の契約更新までに埋めれば、今の開発会社と取引を続ける場合でも、発注者が選択肢を持てます。
ベンダーロックインの診断は、別の会社が作業できるかで決めます
現在のシステムに詳しいエンジニアが開発会社へ偏っているだけでは、直ちに問題とは言えません。長く運用した担当者が速く直せるのは自然です。危険な状態は、別の会社へ頼もうとしても、必要な物や操作手段が発注者の手元にない状態です。
診断では「資料を受け取っていますか」と聞きません。「社内担当者が最新版を取得できますか」「開発会社へ連絡せず、管理者を追加できますか」「出力したデータを別の道具で読めますか」と動作で確かめます。保管の有無ではなく、利用できるかを見ます。
デジタル庁の標準ガイドライン実践ガイドブック第3編第6章は、政府情報システムの調達を対象に、専門的で大量の設計情報、発注者側の文書管理不足、特定事業者だけが権利を持つ独自技術などを発生原因として挙げています。民間企業の契約へ直接適用される規則ではありませんが、発注者が情報と成果物を管理する視点は診断にも使えます。
開発会社の能力や善意だけを問題にすると、担当者を替えても再発します。発注者側で保管場所を決め、社内の管理者を置き、更新の合格条件を決める必要があります。
ベンダーロックイン診断は、五つの保管場所を同じ日に開きます
ソースコードは、最新版を取得して再現します
最初にリポジトリのメンバー画面を開きます。自社のメールアドレスでログインし、稼働中の版を含む変更履歴を取得できるか確かめます。ファイルをダウンロードできるだけでは足りません。
安全な検証環境で、手順書に沿って依存部品を入れ、テストを実行します。環境設定のひな型やデータベース変更の手順が開発会社の端末にしかなければ、ソースコードを保有していても保守を移せません。
著作権とファイルの受領も分けます。2026年7月11日時点のe-Gov法令検索にある著作権法61条、63条は、著作権の譲渡と利用許諾を別に定め、許諾された利用方法と条件の範囲で利用できるとしています。個別案件で別会社による改変や公開が可能かは、納品時に受け取る成果物の確認も参照し、契約書と制作経緯を弁護士へ見せてください。
クラウド権限は、請求先より管理者を見ます
次にクラウドの組織、契約アカウント、プロジェクトの管理画面を開きます。請求書の宛名が自社でも、社内担当者が管理者を追加できなければ主導権は戻っていません。
社内の管理者が、多要素認証の復旧先を管理し、開発会社の担当者が退職したときに権限を外せるか確かめます。日常作業では最小限の権限を使い、最上位権限を共有アカウントやチャットで回さない運用も必要です。
クラウドだけでなく、ドメイン、アプリ配信、監視、メール送信、外部APIの管理者も確認します。一つの外部サービスが止まるだけで公開や復旧ができないなら、同じ診断表へ載せます。
ドキュメントは、現行画面との差分を探します
構成図、公開手順、バックアップと復元の手順、外部連携一覧、障害時の連絡先を自社の保管場所で開きます。最終更新日だけを見ず、直近の変更を一件選び、設計書と運用手順へ反映されているか照合します。
資料が古い場合は、分厚い設計書を一度に書き直しません。事業を止める可能性が高い経路から直します。注文から請求まで、予約から通知までなど、売上や顧客対応に直結する流れを一つ選びます。
決定理由も残します。採用した技術名だけでなく、選んだ条件、採用しなかった案、見直す時期が分かれば、別のエンジニアが同じ調査を繰り返さずに済みます。
データ出力は、件数と項目を照合します
管理画面に出力ボタンがあるだけでは合格にしません。安全な範囲でデータを出し、文字コード、日時、識別子、添付ファイル、削除済みデータ、操作履歴の扱いを確認します。出力元の件数と出力後の件数も照合します。
独自形式しか選べない場合は、項目定義と変換方法を確認します。標準的な形式でも、顧客と契約を結び付ける識別子が欠けていれば、別システムで業務を再開できません。個人情報を含む出力は、保存先、閲覧者、削除日を先に決めます。
復元試験も必要です。隔離した環境へ戻し、重要な業務を一件だけ通します。バックアップ成功の表示と、復元後に業務を再開できる状態は同じではありません。
契約は、終了日の翌日に残る物を読みます
基本契約書、個別契約書、見積書、仕様書、発注書を横に置きます。成果物、知的財産権、第三者による保守、管理アカウント、データの出力形式、終了時の支援、移管費用を探します。文書間で内容が違う場合の優先順位も確認します。
契約の表題だけで中途終了の条件を判断できません。2026年7月11日時点の民法641条、651条、656条には、請負の仕事が完成する前の解除と損害賠償、委任の解除、委任規定の準委任への準用に関する原則があります。締結済みの条項、実際の作業、終了理由によって確認事項が変わるため、更新や解約の通知前に受託開発のトラブルを防ぐ契約確認と資料一式を専門家へ渡してください。
ベンダーロックイン対策は、閲覧権限から実行試験へ進めます
棚卸しの結果は、開発会社への採点表にしません。五つの項目ごとに、自社の責任者、現在の保管場所、最後に試した日、次の試験日を記録します。担当者名が空欄なら、社内で引き取る人を先に決めます。
開発会社には「ロックインを解消してください」と抽象的に頼まず、実行してほしい作業を依頼します。自社名義のリポジトリへ履歴を移す、社内管理者を追加する、構成図を現行環境へ合わせる、指定した項目を出力する、終了支援を個別契約へ追加する、と分けます。
追加作業には時間と費用が掛かる場合があります。過去の契約に含まれる作業か、次回更新で追加する作業かを分け、期限と受入条件を合意します。無償の好意へ頼ると、担当者の交代で止まります。
受入条件は提出物の数では決めません。社内担当者がリポジトリを取得してテストを通せる、制限した検証環境へ公開できる、データを出力して件数を照合できる、と実行結果で決めます。試験に失敗した場所だけを次の定例で直します。
今の開発会社と良い関係が続いている時期ほど、依頼しやすいはずです。平時の引き継ぎ整備は、取引終了の予告ではありません。障害や担当者交代が起きても、両社で早く復旧するための運用です。
特定製品を使うだけでベンダーロックインになるのかを考えます
特定のクラウド機能やSaaSを使うだけで、直ちに避けるべき状態にはなりません。開発速度や運用品質を優先し、移行時の手間を理解した上で選ぶ判断もあります。全機能を自作したり、目的のないマルチクラウドへ進んだりすると、日常の管理負担が増えます。
確認したい点は、依存の有無ではなく、依存を誰が把握し、別の製品へ移る費用と作業を比較できるかです。代替候補、データの出力形式、設定の記録、廃止時に作り直す範囲を資料へ残します。独自機能を採用する場合も、事業上の利点が移行負担を上回る間は合理的です。
クラウドの設計変更まで急ぐ必要はありません。まず管理者を自社にも置き、利用中のサービス一覧を出し、バックアップからの復元を試します。診断結果を見てから、交換しにくい部分だけに移行手段を用意します。
次回更新までに、自社が五つの合否を決めます
診断の目的は、開発会社を替えることではありません。今の会社を継続する、新しい提案も比べる、内製へ移すという選択肢を、発注者自身が選べる状態に戻すことです。
契約更新日から逆算し、最初の定例で不足一覧を共有します。次の定例までに小さな実行試験を行い、失敗した作業の修正範囲と費用を見積もります。更新条件を決める前に再試験し、未完了の作業は担当者と期限を個別契約へ残します。
診断後に会社変更を選ぶ場合は、解約通知から始めず、開発会社を変更する移行手順へ進んでください。平時の診断と、旧会社と新会社を並走させる移行は別の仕事です。
明日は、次の五問へ自社の担当者だけで答えてみてください。
- 稼働中のソースコードを取得し、安全な環境でテストできますか。
- クラウドと外部サービスへ自社の管理者を追加できますか。
- 直近の変更が反映された構成図と復旧手順を開けますか。
- 事業データを出力し、件数と必要項目を照合できますか。
- 契約終了後も別のエンジニアが保守できる条件を、契約書で説明できますか。
一問でも答えられなければ、開けなかった画面か不足した資料を一つ選び、次の定例議題へ入れます。五問へ実行結果で答えられる状態が、次回更新で継続も変更も選べる出発点になります。
次に読む