アプリケーション間の対話といえば、真っ先に思いつくのはマッシュアップ。今では当たり前のように行われているけれど、初めて見た時は衝撃的だった。

マッシュアップとは今更説明するまでもなく、複数の Web サービスの API を組み合わせ、あたかも一つの Web サービスのようにする機能のこと

これまでたくさんのマッシュアップが行われているし、それを促進するためのアワードも開かれたりしている。

実際ぼくもそういったものに応募したこともあるし、応募しようと思ってやめたこともある。

応募しようと思ってやめたのは、何も面倒だったというわけじゃない。ただ、ぼくの求めている機能が提供されていなかったから。

その制限の中で行うのがマッシュアップだといわれれば元も子もないけれど、計画しかけていたものをつくるのが無理とわかった時点で、気持ちが萎えてしまったのだから仕方がない。

けれど、もしこれが API を提供する開発側と協議の上、どんなリソースをどんな語彙で受け取るのかを決めることができればどうだろう。そうすれば汎用性を考慮してつくられた API よりも、もっと強力なアプリケーションをつくることができるかもしれない。

この API の相互作用を事前に計画することを、仮にコンプリヘンシブプランニング(総合計画)と呼んでみることにする。

けれどそれはあまり意味がないとも考えられる。個々のアプリケーションは部分であるよりも全体であるべきで、マッシュアップの成果物は別として、個々の API の依存関係は緩く、汎用性の高い、自己完結的なものでなければ利用者はかえって不便かもしれないし、他の API ありきで設計された API は相対的にリスクが高くなる。

しかし、もし仮に全てのアプリケーションを同一の組織が開発し、そもそも始めからそういった大きな目的のための部分として設計される API であれば、それはただの杞憂となる。

もちろん、別に一社でつくる事にこだわる必要はない。複数の企業が協同しても変わらないが、それは今は未だ現実的ではないような気がする。

ではコンプリヘンシブプランニングとマッシュアップは何がどう違うのだろう。

マッシュアップはオープンだけれど制限は厳しい。望むものではなく、提供される範囲内でデザインする必要がある。開発者は語源の通り DJ のように思考する。

一方コンプリヘンシブプランニングはクローズドだけれど事前の協議によって欲しい機能が手に入る。個々のアプリケーションとしての独立性は担保しながら、同時にひとつのアプリケーションを構成する API をデザインする必要がある。こちらの開発者は DJ ではなくオーケストラに近い。リミックスではなく、緻密に設計された交響曲と呼ぶのが相応しい。

そんなわけで Web にも高度に連携するアプリケーションスイートが現れる日は近い。将来的には複数のリソースから複合アプリケーションを設計する Web アプリケーションコーディネータみたいな職能も必要とされる時代がくるのかもしれない。

じゃあ、人間の側はどう変化しているのだろうか。