互換性と拡張性は両立するか
まず最初に断っておこう。ここで言う拡張性とはカスタマイゼーションのことだ。スケーラビリティのことではない。いや、ある種のスケーラビリティも含まれるが、いわゆるスケールアウトやスケールアップというコンテキストで語るときのスケーラビリティではない。
じゃあ、何の話かというと、ユーザーによるイノベーションの実現方法としての拡張の話だ。今日のユーザーと明日のユーザーでも紹介したヒッペルの「民主化するイノベーション」で、ユーザーによるイノベーションをそのまま製品に取り込めない場合は、ユーザーによるイノベーションを可能にするようなプラットフォームを開発すべきであるという話が出てくる。
IT業界において、この手法はごく一般的だ。OSやインターネットのサービス上でAPIを公開し、ユーザーやパートナーに機能を拡張する機会を与えることで、そのプラットフォームを提供する企業を中心としたエコシステムが形成される。このようにして、マイクロソフトやグーグルは他社との差別化を図ってきた。
しかし、このようなカスマイザビリティ（＝拡張性）も世代交代の際には負の遺産となる危険性を孕んでいる。カスタマイズされたシステムを無事次期バージョンへとアップグレードさせなければならないからだ。APIによりイノベーティブなカスタマイズがされればされるほど、アップグレード後にもその動作を保証することは難しくなる。
実は私はDEC時代に、カスタマイズを究極まで追求したような製品を担当した経験がある。ALL-IN-1という名前の、当時オフィス統合システムと呼ばれた、今で言うグループウェアのような製品が、私が営業とともに、日本のお客様に売りまくった製品だが、これはシステムの動作のほとんどが独自のスクリプトで構成されていた。実は、このALL-IN-1、米国本社により開発されたままの状態では、DECの端末（VT）しか対象としておらず、当時すでにオフィスにおいて一般化していたPCとの統合ができなかった。そこで、PC上で動作する端末エミュレータに独自エスケープシーケンスを実装し、ALL-IN-1からそれを制御することで、たとえば一太郎やロータス1-2-3といったPC上のアプリケーションを統合することを可能とした。このPC統合用のパッケージはスクリプトと端末エミュレータのエスケープシーケンスをトリッキーに駆使することで実現されていたが、さらに、われわれはこれをそのままの状態ではなく、お客様に合わせた形で提供していた。このようにスクリプトを用いて、短期間でお客様の独自のニーズに合わせたシステムとして提供できることがこの製品の売りだった。
さて、お客様がこのままのシステムを使い続けていてくれれば問題は起こらなかった。だが、当然、元の製品はいつかアップグレードされる。そうなってはじめて、お客様も、提供したわれわれも、システムを新しいバージョンに適用させるのがいかに大変かに気づいたのである。結果、お客様のアップグレードごとに専任のエンジニアが張り付きになるという事態が生じた。
今日も状況はそう変わらない。汎用ソフトウェア製品の場合、この互換性確保をユーザーに一方的に押し付けるのではなく、提供ベンダーができるだけ実現しようとしている。しかし、ユーザーに与えた自由が大きければ大きいほど、互換性確保を維持するためのコストは高くなる。問題は開発コストだけではない。ベンダーによるイノベーションさえも時として奪ってしまう。互換性とイノベーションのトレードオフを迫られるような事態にさえなりうるのだ。
互換性と拡張性。ベンダーによる謳い文句として良く並んで評される。だが、真のイノベーションを追求した場合、この２つは両立しうるものなのだろうか。
今、Web 2.0という流れの中、多くのWebサービスAPIが公開されている。ものによっては正式に公開されたインターフェイスではないものを使い、本来の使われ方と違う形にサービスを改良して使うものもある*1。これらがイノベーティブだともてはやされているようであるが、いつか互換性という負債が目の前にあることに気づくのかもしれない。
