ベンダーの都合でゆらぐメンテナンス性

先日、理想どおりにかっこよくいかない再利用の現実のについて考えていくと書きました。今日は、それと関連してメンテナンス性について、ちょっと書いてみようと思います。

コンポーネントフレームワークなどを導入して、再利用性を高めようという試みで、そのフレームワークの設計がどうだとか、プロセスがどうしたというような上モノの話しとは別に、いきなり土台を揺さぶってくるのが、ベースとなるプラットフォームベンダーの都合です。

例えば、オルタナでも川上さんが指摘されているように、IEが新しくなってユーザー環境が変わっちゃうから、っていうような要素は、コンポーネントの再利用性とは別次元の話しとして沸いてきます。しかし、現実には、こういった事象を引き金にして、リリース済みのアプリケーションを再構築しなければならない、一部変更しなければならない、ということが頻発し、そのときに、芋づる式に修正箇所が出てきてどうにもならないというのが最も避けたいところなのだと思います。

さて、私自身もベンダーに身を置く立場として、こうした方々に影響を与えるベンダーの都合による変更をいうものを何度も経験しています。この場で、それを擁護したり、あるいは立場を捨てて批判することは容易なのですが、そうではなく、なぜそういう事態になるのかを今一度考えてみたいと思います。

いうまでもなくソフトウェアベンダーは、ソフトウェアを販売して利益をあげていますから、新しくソフトウェアを買ってもらうための努力をします。新しく買う人の多くは、その時点で必要としているもの、いわば新しいものを求めています。新たにシステムを構築するときには、「超」最新でなないにしても、新しいOS、データベース、アプリケーションサーバーなどを採用し、それなりに長い期間メンテナンスしてもらえるように考えます。最新を追っかけないベンダーは、言ってみればこの市場を捨てているも同然です。とはいえ、ユーザーの立場からすれば、一度作成してしまえば、その環境を長くメンテしてもらいたいというのが普通の気持ちですから、ベンダーとしては、新規と既存の両方を見てビジネスをしなければならないのです。

しかし、ソフトウェアというのは複雑な構造物で、ベンダーもユーザーと同じような立場に立たされています。例えばコンポーネントベンダーは、それがサポートする開発環境のバージョンアップに影響を受けますし、さらにそのベースにあるOSなどの影響も受けます。Javaであれば、JDKのバージョンアップや関連するフレームワークの仕様にも影響を受けます。こういった、さまざまな依存関係の中で、はじめはよかれと思って作ったものが、周辺の状況変化に対してその内部で処理しきれずに、仕様変更として表に出てきてしまうことがあります（もちろん、そんな不可避な仕様変更だけでなく、あんまり考えてないもの、確信犯的なものもありますけど）。

とにかく、成長するソフトウェア技術を各社が複雑な依存関係を持って追っかけていますから、その上に構築するフレームワークも、独立した再利用性の理想郷にはおれないわけです。

さて、ここまで書いて、ユーザーとしてもベンダーとしても、この前提に対して何ができるかを考えるべきだと感じています。特にベンダーとしては、ユーザーがずっと抱えつづけているこの問題を無視して、新技術だけを追っかけているのは、技術的な面だけでなく、経営的にも利口な判断とは思えません。振り返って我々がそれをできているかといえば、正直ノーなのですが、これから開発者フォーカスを掲げていく限り、この問題に正面から取り組むべきだと考えています。