オブジェクトモデルのアプリケーションでは、コンポーネント単位に、追加、変更削除が可能です。
現在のアプリケーションは、システム全体を一から作り直すのではなく、このコンポーネント単位の開発が主流になっています。
例えば、銀行システムにおいても、その流れが顕著です。古くなったシステムを丸ごとラッピングして、業務間のコミュニケーションシステムであるハブシステムを介することで、全く新しく作り直した業務コンポーネントに入れ替える手法で、勘定系、情報系のシステムを刷新しているのです。
こう言った動きと、今回の「自己組織化するアプリケーション」と言うテーマと何が関係するのか、これから説明しますが、その前に、アプリケーションを操作して利用する人間も、このオブジェクトモデルで言うコンポーネントであることに注意する必要があります。
オブジェクトモデルでは、この人間も含むコンポーネントの群れが相互に干渉しあうことで、アプリケーションと言うものが動作していると考えるわけです。
アプリケーションに、新たな業務機能を追加する場合を考えましょう。
今までの考え方（モデル）では、システムエンジニアがこれを設計して実際のプログラムを書くことで実現すると言うのが、当たり前ですが普通のとらえ方です。ところがこれを、システムエンジニアではなく、アプリケーションの一部である人間というコンポーネントが、自分の近接して関係するコンポーネントを修正したり、新たに追加したりすると考えてみることはできないでしょうか、と言うことを、今お話ししているのです。
新しく追加されるコンポーネントは、それが全く独立して動作するわけではありません。近接するすべてのコンポーネントとコミュニケーションを取りながら動作するし、人間コンポーネントとのインターフェイスは、既存のインターフェイスを無視するわけにはいきません。コンポーネントが相互干渉しながらコンポーネントを産み出して行くと言うことこそ、自己組織化するアプリケーションの実態です。
この考え方を推し進めていくと、世の中のSNSの興隆や、BlogにおけるRSSの進化も、アプリケーションの自己組織化、進化と捉えることができるのではないかと考えられるわけです。
先の銀行システムの例は、アプリケーションの進化の例としては、最もプリミティブで原始形ですが、人間不在の旧システムから、人間と言うコンポーネントを含むアプリケーションへ進化させる唯一の方法ではないかと考えます。
さて、今回の一連のテーマの冒頭で、
なぜこんなことを議論するのかというと、アプリケーションの開発と言うことの本質を突き詰めていくと、実はこのアプリケーションの動作環境と開発環境の関係に行き着くのではないかと考え始めているからです。
と書きました。また、
CNETに載った「マイクロソフトの本当の姿」と言うコラム記事を読みながら、マイクロソフトの強さの秘密は、実は、このアプリケーションの自己組織化に成功しそのノウハウを蓄積していっているところにあるのではないか、逆に言えば余り成功していない分野ではこのアプリケーションの自己組織化に失敗しているからではないか、更に言えば、それは動作環境と開発環境が異なるアプリケーションの分野ではないのか等々、たちまち新たなる仮説を思い描くことができます。
とも書きました。
アプリケーションの開発環境と動作環境が同じと言うことは、すなわち開発者である人間と言うコンポーネントが、アプリケーションの中のコンポーネントとして機能している、と言うことです。逆に、二つの環境が分断された瞬間、アプリケーションの開発を担う担当者が、アプリケーションのコンポーネントとして機能しなくなると言うことでもあります。
これは開発者＝利用者と言う図式を主張しているのではありません。開発環境＝利用環境が最適アプリケーションを産み出すための成功方程式だと言う仮説です。以下次回。 KAI