アーキテクチャのアンチパターン

Vendor Lock-In（ベンダーロックイン）

　アプリケーションを開発する際に、特定ベンダーの技術への依存性が高くなる場合があります。特定のベンダーの技術に依存性が高いと、ベンダー側製品のアップグレードが行われるたびに、従来通り機能するのか確認したり、場合によっては大幅な手直しをしたりする必要が生じます。

　こうした状況のことを、“ベンダーロックイン”と呼んでいます。

　以下のような症状があれば、ベンダーロックインアンチパターンにかかっている可能性があります。

・ベンダー製品のアップグレード時には、アプリケーションのメンテナンスを行う必要性が高い
・ベンダー製品側の機能リリースが遅れたりするとアプリケーション開発に大きな影響が生じる
・ほかのベンダーと相互互換性のない製品を使っている

　こうした症状を回避するためには、分離層（Isolation Layer）といって、OSやミドルウエアの実装に直接影響を受けないための層を設けることによって、ベンダー製品への依存性を低くすることができます。

　かつては、こうした分離層をプロジェクト毎に手作りしていた時代もあったのですが、現在では、一般的に提供されている製品や技術を使うことができます。

　例えば、OSへの依存性を低くしたいのであれば、アプリケーションをJava VMなどの仮想マシン上で稼働させることによって対応できます。また、ミドルウエアのAPIなどに依存性を低くしたいのであれば、SpringやS2などのフレームワークを用いることが有効です。

　こうした手段を用いて、ベンダーロックインからなるべく解放されるようにしないと、特定ベンダーからの呪縛に悩まされることになるのです。

Design by Committee（委員会設計）

　システムを構築する際には、経験が豊かで、優秀なアーキテクトが設計した、適切なアーキテクチャに基づいて開発を行うことが、本来のあるべき姿です。しかしながら、アーキテクトが不在のまま、実際に設計の妥当性を検証しないまま、複雑であいまいな仕様を作成しているプロジェクトも多く見受けられます。

　こうした場合、たくさんの設計者が仕様作成に参加し、ドキュメントの量は膨大になるにも関わらず、その設計は明確なコンセプトに欠けるのです。

　このようなケースを、“委員会設計”と呼びます。

　以下のような症状があれば、委員会設計アンチパターンにかかっている可能性があります。

・設計文書が複雑である反面、一貫性に欠ける
・設計文書に欠陥が多い
・設計文書が異様に分厚い
・多数の人が設計の会議に参加しているが、議論が散漫で一向に進展しない
・会議をしないと何事も決まらなくなっている

　こうした状況に陥ると、時間がたち、ドキュメントが分厚くなっても、システムが期待通り稼働できるかどうか、誰も自信を持てないことになるのです。

　委員会設計のアンチパターンから脱却する方法は2つあります。1つは、会議のやり方を変えることです。つまり、会議の目的を明確にして時間内に効率よく物事を決定する運営に変えることです。

　2つ目のポイントは、プロジェクト組織の見直しを行うことです。特に、システム全体のアーキテクチャを決定するアーキテクトは誰か、役割分担を明確にすることが重要なのです。