search
LoginSignup
10

More than 1 year has passed since last update.

posted at

updated at

マンガでわかる砂上の楼閣(ベンダーロックイン)アンチパターン

C75CB432-50BB-4E4F-8ABF-FCBEABB47E62.png
http://wiki.c2.com/?VendorLockIn

いくら立派な機能を持ったソフトウェアに見えても、足元が頼りないと、驚くほど脆く壊れてしまうことを象徴して、アンチパターン本では、ベンダーロックインのことを、日本語で砂上の楼閣と翻訳されています。

「固い岩の醜い家が安全に建っている:それにひきかえ、わが輝く宮殿の砂の上に建つを見よ!」
—— Edna St. Vincent Millay

特定ベンダーに依存して無警戒に豪華な機能を使ってしまうと、依存が依存を招き、もとあった依存を超えて、ソフトウェア全体がベンダーの呪縛から逃れられなくなってしまいます。こうしてベンダーロックインが起こると、開発の主従関係が逆転してしまいます。開発者は、仕様変更の権限を握っているベンダーの一挙手一投足にビクビクしながら、砂上の楼閣を保守しなければなりません。

ベンダーは自社の利益と大多数のユーザーの満足を目的とします。また、ほとんどのユーザーにとって不利益でなければ、ベンダー内の複数のプロダクトで足並みが揃わず、一貫性を失った状態になるときもあります。もし自分の開発したものがこの「大多数」からあぶれたらどうなるでしょう。主導権がベンダー側にあると、それは死の宣告となり、大規模なデッドエンドを迎える可能性もあります。

これは、心理的な問題や政治的な問題ではなく、アーキテクチャの問題である点が重要です。アーキテクチャによって、主導権をつねに開発者側で握れるのだから、みすみすその機会を逃すのは開発者の責任、設計の失敗です。ビジネスロジックに近い箇所ほど、ベンダー中立なレイヤーを通すようにしておき、代替手段に置き換え可能にしておくのです。ベンダー固有の機能に依存するコードは、この中立レイヤーのインターフェースを実装するかたちにして依存を逆転させ、開放閉鎖原則 (書き換えには閉鎖的に、拡張には開放的に) を尊重しましょう。ちなみに、この中立レイヤーの機能セットがアプリケーションのドメインモデルに依存するのは問題ありません。なぜなら、ドメインモデルの権限は完全にこちら側にあるのですから。

繰り返しになりますが、ベンダーロックインは、それを見過ごすアーキテクチャを作った開発者の責任です。ベンダーがいつ 梯子外し をするかわからないのは、すでに知っているので。例えて言えば、セキュリティホールを放置していた箇所をクラックされたとして、クラッカーが悪いんだから私は悪くない、なんて言い訳してたらエンジニアの恥ですよね。ベンダーロックイン対策もそれと同じです。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
10