ベンダーロックインとは

ベンダーロックインとは

特定の開発会社や製品、クラウドに依存した結果、他社へ移行する費用と手間が過大になった状態です。
移行できないため、同じ相手を使い続けるほかありません。

ベンダーはシステムや製品、クラウドを提供する事業者を指します。
公正取引委員会の官公庁における情報システム調達に関する実態調査報告書は、ベンダーロックインを次の状態と定義しています。
機能の改修やバージョンアップなどシステムを使い続けるのに必要な作業を導入した事業者以外が実施できず、特定のベンダーを利用し続けなくてはならない状態です。

他社へ移行するときに発生する費用を、乗り換えコストやスイッチングコストと呼びます。
依存には開発会社・保守会社に依存する系統と、製品・クラウドに依存する系統の2つがあります。

なぜ問題になるか

価格と品質について交渉する余地の喪失

ロックインの状態でもシステムは稼働し続けます。
問題は価格と品質について交渉する余地を喪失することです。
保守費の値上げや対応の遅延があっても、移行という選択肢がなければ許容するほかありません。

既存のベンダーと再契約する理由

公正取引委員会の実態調査報告書では、回答した官公庁の98.9%に、保守・改修・更改の際に既存のベンダーと再度契約した事例がありました。
官公庁を対象にした調査ですが、依存が生じる構造は民間の会社にも共通すると推測できます。
ロックインに関係する再契約の理由には、次のものがありました。

• 既存のベンダーしかシステムの機能の詳細を把握できなかった: 48.3%
• システムの機能に関する権利が既存のベンダーに帰属していた: 24.3%
• 既存のベンダーしか保存されているデータの内容を把握できなかった: 21.1%

3つの理由のうち最も多いのは、機能の詳細を把握している人が既存のベンダーにしかいないことです。
権利の帰属を理由とする回答の約2倍にあたり、再契約の主な要因は権利よりも、知識が既存のベンダーに集中していることです。

入札を実施しても、既存のベンダーとの再契約を回避できるとは限りません。
公正取引委員会の実態調査報告書の再契約の理由全体では、入札をしても既存のベンダーが落札したという理由が33.6%で2番目に多くなっています。
入札でも既存のベンダーが有利になる理由の1つは、システムの中身を把握していることだと推測できます。

同報告書は発注側にIT人材が不在でベンダーとの間で知識や経験に差がある場合、その情報の非対称性からロックインが発生しやすい状況になり得ると指摘しています。

開発会社と製品・クラウドへの依存を避ける手段

系統	依存の対象	ロックインを避ける主な手段	その手段のコスト
開発会社・保守会社	仕様書、ソースコード、著作権、運用の知識	権利の帰属と納品物の範囲を契約で定め、設計書を更新させる	開発費の上乗せ、文書を維持する工数、仕様を把握する社内担当者の人件費
製品・クラウド	独自の機能、データの形式、ライセンス、データの取り出し費用	データの取り出し方法と形式を契約前に確認し、業務の中核は標準的な技術で構築する	独自の機能を利用しない分の開発と運用の手間、製品の利点の一部を放棄すること

開発会社・保守会社への依存

開発会社への依存では著作権の帰属が出発点になります。
独立行政法人情報処理推進機構（IPA）の情報システム・モデル取引・契約書は、著作権の帰属について次の3つの案を示しています。

• すべて開発会社に帰属させる
• 汎用的なプログラムを除いて発注側へ移転する
• 汎用的なプログラムを除いて共有とする

どの案でも汎用的なプログラムの著作権は開発会社に帰属します。
案ごとの違いはそれ以外の部分の帰属先だけなので、発注側が契約で選択するのはこの部分の扱いです。

著作権が開発会社に帰属すると、別の会社にプログラムの改変を依頼するときに開発会社の許諾が必要になります。
譲渡する契約でも著作権法第61条第2項により改変に関する権利が明記されていなければ、その権利は開発会社に留保されたものと推定されます。

プログラムの改変を制限できる著作者人格権は、著作権法第59条により譲渡できません。
実行に必要な改変などの例外はありますが、発注側は譲渡の場合も利用の許諾の場合も、第三者に改変と保守を委託できることと、開発会社が著作者人格権を行使しないことの2点を契約に明記します。

保守会社を変更する具体的な手順は、ハンドブックの開発会社を変更したい。システムの移管は可能か、最初に何を確認すればよいかで解説しています。

製品・クラウドへの依存

製品やクラウドへの依存では、データを移行できるかが中心になります。
デジタル庁の政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針は、クラウドサービスを選択する条件を示しています。
データの移行性が担保されていることや、合理的な価格体系が公開されていることなどです。
そのうえで、ロックインを回避するよう求めています。
移行時のデータ転送料を条件付きで免除するクラウドもありますが、独自の機能に依存して実装した処理は再構築が必要です。

ロックインを許容する範囲と避ける範囲

ロックインをゼロにする必要はありません。
ロックインを避ける手段はどれもコストを伴うため、乗り換えコストが高額な箇所に限定して対策します。

新規開発の契約でソースコードと権利の引き渡しをどこまで求めるか

数年以上使い続けるシステムなら、ソースコードと設計書を納品物に含め、発注側が他社に改変を依頼できる権利を契約で確保するほうが安全です。
著作権そのものの譲渡は必須ではありません。
開発会社が他の案件と共通のプログラムを再利用している場合、譲渡を求めると見積もりが増額されるか、条件の交渉が長期化します。
著作権は開発会社に帰属させたまま利用の許諾を得る形でも、許諾の範囲に改変と他社への保守の委託が含まれていれば、移行の妨げになりにくいです。
権利よりも不足しやすいのは、設計書の最新化を開発会社に求める契約上の取り決めと、仕様を説明できる発注側の担当者です。

クラウドの独自の機能を利用してよいか

利用してかまいません。
独自の機能を避けて汎用の技術だけで構築すると、運用の手間と開発費が増加し、クラウドを利用する利点が減少します。
避けるべきなのはデータを特定の製品の形式でしか出力できない状態です。
データを一般的なデータベースやCSV（Comma-Separated Values）の形式で出力できるようにしておけば、処理の再構築は発生しても、事業の資産であるデータは喪失しません。

クラウドの業務サービスを導入するときに解約後のことまで確認するか

SaaS（Software as a Service）では、契約前に次の3点を確認します。

• 出力できるデータの範囲と形式。添付ファイル、変更の履歴、設定やワークフローまで含むか
• 解約後にデータが保持される期間
• 価格改定の通知期間

データのほかに、業務の手順も移行の費用になります。
製品の仕様に準拠して変更した業務の手順は、他の製品へ移行するときに再度の変更が必要になりますが、この費用は許容してかまいません。

ロックインの対策を厚くすべき目安

次のいずれかに該当するシステムは、契約と設計の両面で対策を厚くします。

• 5年以上の利用を予定している
• 保守費や利用料が年間で数百万円以上になる
• 独自の形式のデータや長期の履歴を蓄積し、移行するときに構造の変換が必要になる
• 他の複数のシステムとデータを連携し、業務の中核を担う

ロックインを気にしなくてよいシステム

次のいずれかに該当するシステムは、ロックインを気にせず利用できます。

• 会計、勤怠、チャットのような汎用のSaaSを、数十人までの規模かつ月額数万円程度の料金で利用している
• 試行や期間限定の施策のためのシステムで、1〜2年で運用を終了する
• データを標準的な形式で出力でき、他社の同等の製品も多く存在する

よくある誤解

著作権を自社に移転すればロックインは解消する

著作権を自社に移転しても、それだけではロックインは解消しません。
権利は他社への切り替えの前提にすぎません。
設計書が実物と一致せず、仕様を説明できる人が既存の保守会社にしかいなければ、権利があっても他社は短期間で引き継ぎを完了できません。

マルチクラウドにすればクラウドへの依存を避けられる

デジタル庁のクラウドサービスの基本方針は、1つのシステムの基盤を複数のクラウドで構成するマルチクラウドを避けるべきとしています。
構成の複雑化と費用の増大を招く傾向にあるためです。
依存を低減する手段としてはデータの移行性を確保するほうが費用対効果の点で有利です。

オープンソースで構築すればロックインしない

オープンソースのソフトウェアを利用すれば、製品のライセンスへの依存は避けられます。
その上に開発した独自の部分を把握している人が1社にしかいなければ、開発会社への依存は解消しません。