ベンダーロックインを避ける：初日から自社でソフトウェアを所有する方法

多くのチームは契約書の所有権条項を確認して、そこで終わります。契約はもちろん重要ですが、ロックインの正体はライセンス条項ではないことがほとんどです。実際には、アクセスできないコード、誰も再構築できない環境、そして一人のベンダー担当者の頭の中にしかない知識です。

明日プロジェクトが終わるとして、貴社のチーム（または新しいベンダー）は誰にも電話せずにシステムを動かし、変更し、再デプロイできますか。正直な答えが「いいえ」なら、まだシステムを所有していません。所有しているのは請求書だけです。

ロックインが実際に潜む場所

リポジトリ。 コードがベンダーのGitHub組織にあり、最後にzipファイルを受け取るだけなら、手に入るのはスナップショットであってシステムではありません。履歴、課題、レビューの議論、CI設定は先方に残ります。

環境。 特定のエンジニアのPCからしかデプロイできないシステムは、コードを持っていてもロックインです。コンソールの手作業クリックでしか存在しないインフラは、他の誰にも再構築できません。

認証情報。 APIキー、DNS、クラウドアカウント、ベンダーのメールアドレスで登録された外部サービス。関係が終わるとき、実務上いちばん多いブロッカーです。

知識。 チャットで決まって文書化されなかった意思決定は、一人の記憶への依存です。その人が転職すれば、アーキテクチャの半分の「なぜ」が一緒に消えます。

所有を現実にするチェックリスト

1. 初日から貴社のリポジトリ。 ベンダーは最初のコミットから、貴社組織が所有し貴社が管理者権限を持つリポジトリで作業します。ミラーでも、最後の移管でもありません。
2. 書面での譲渡。 SOW（作業範囲記述書）に、最終支払い時にすべてのソースコード・インフラ設定・ドキュメントが貴社に帰属すると明記します。ライセンスバックなし、席課金なし。
3. 再現可能なセットアップの検証。 文書化された1コマンド（または短いスクリプト）で、ローカルでも新しいクラウドアカウントでもシステムが立ち上がること。プロジェクト後ではなく、進行中に検証します。
4. 貴社名義のアカウント。 クラウド、DNS、決済、監視、すべてのAPIキーを貴社組織で登録し、ベンダーは削除可能なメンバーとして追加します。
5. 意思決定の記録。 技術スタック、データモデル、トレードオフを選んだ理由を短い文書に残します。1決定につき1ページで十分です。
6. エスクローまたはバックアップ担当者。 長期の構築では、ソースコードエスクローか指名済みのバックアップ担当者を用意し、法務が聞く前にバスファクターの問いを消しておきます。

健全なプロジェクトでの実際の姿

これは敵対的な話ではありません。次の案件を獲得したいベンダーには、今の案件を人質に取る理由がないのです。Urbano DXではすべての案件がクライアントのリポジトリで始まり、引き継ぎドキュメントの納品をスコープに含め、「新しいエンジニアがREADMEから引き継げること」を厚意ではなく受入条件として扱います。

テストは簡単です。「来月取引をやめたらどうなりますか」とベンダーに聞いてください。具体的で自信のある答えなら良い兆候。曖昧な答えなら、それがロックインの始まりです。

これから構築のスコープを決める段階で、SOWに所有の保証を最初から入れたい場合は、パッケージの書き方をご覧ください。