零細 IT パッケージメーカー経営視点での時雨堂のベンダーロックインについての考えをなんとなく書いておきたかったので書いてみます。特に目的はありません。雑な文章なので適当に読んでください。
ベンダーロックインとは
特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象のこと。Wikipedia から引用しました。自分の認識ともあってるので間違ってはいなさそうです。IT 企業で商用パッケージを採用するとほとんどの場合でベンダーロックインになるのは間違いないと思います。
むしろベンダーロックフリーな製品でビジネス的な競争力を作るのは難しいと思います。それができてる企業は本当にすごいです。
自社も間違いなくベンダーロックインさせる側です。ただ、できるだけベンダーロックインをさせないという手段もとっています。
ベンダーロックインさせつつ、逃げ道もつくる
時雨堂の製品である WebRTC SFU というリアルタイムな音声や映像、メッセージを配信するサーバー製品はオープンな規格である WebRTC を採用しつつも、規格として定義されていない部分についてはベンダーロックインになってしまいます。
この部分を自社では「ドキュメントで限りなく詳細に説明する」という手段をとっています。さらに、クライアント側の SDK はすべてオープンソースとして公開しています。つまり「時雨堂製品互換の製品を作る」と言うことが可能な状況を維持しています。
そんなこと言ったってやる企業いないでしょ？と思うかもしれません、私も思います。ただこれがいるんです。あるお客様で諸事情により特定の状況では弊社製品の採用が難しいと問題が発生しました。
ただ、お客様が開発していたシステムは時雨堂の製品にベンダーロックインしています。ここでお客様がとった判断は SDK はオープンソースだし、時雨堂製品の「開発しているシステムに必要な部分を実装したサーバーを開発する」といったものでした。私も SFU 開発アドバイザーとしてお手伝いに入り、お客様側で短期間で実際に動くものを作り上げました。
（この話を書く許可はいただいています）
これは仕様が不透明だったり SDK がオープンソースでなかったらとれない戦略だと思います。
ベンダーロックインを狙いつつも、仕様自体はオープンにしていくというのはありだと考えています。
お客様視点でのベンダーロックイン
実際、お客様からいろいろ話を聞いてみると「ベンダーロックイン」自体をネガティブに捉えているお客様はとても少ないように感じます。
技術がわかっている人ほど「ベンダーロックインされて長く付き合っていくべき」といった判断をされているようです。
むしろベンダーロックインフリーの製品（例えばオープンソース）を自分たちで維持するコストを天秤にかけてベンダーロックインされた方が良いとの意見が多いです。
そもそもオープンソース維持できるのであればベンダーを検討する必要もないわけですが。
ベンダーロックインする箇所を減らした製品
時雨堂の製品の場合は主にベンダーロックインする部分は認証の部分です。これは独自色が出やすいというのもあります。
それ以外の通信部分はそもそも「RFC のプロトコル仕様」にあわせなければいけないので、ベンダーロックはできません。できたとしたらただの独自プロトコルです。
時雨堂の製品で何か対応する場合でも可能な限りオープンな規格を採用しています。変なところで独自色がツヨイのは設定ファイルくらいでしょうか（INI 形式に近い key = value というシンプルな仕様にこだわっています)。
まとめ
顧客を逃がさないという点ではベンダーロックイン、つまり独自仕様、仕様非公開は最強です。一度導入してしまえば切り替えもかなり難しくなるでしょう。その機能に依存している製品であればなおさらです。
ただ「それで縛っている」というのが自分はかっこ悪く感じてしまうというのがあります。
それよりはできるだけオープンにしてそれでも使い続けてくれるお客様と仲良くしていきたいと思っています。
