オブジェクトモデルのアプリケーションでは、コンポーネント単位に、追加、変更削除が可能です。
現在のアプリケーションは、システム全体を一から作り直すのではなく、このコンポーネント単位の開発が主流になっています。
例えば、銀行システムにおいても、その流れが顕著です。古くなったシステムを丸ごとラッピングして、業務間のコミュニケーションシステムであるハブシステムを介することで、全く新しく作り直した業務コンポーネントに入れ替える手法で、勘定系、情報系のシステムを刷新しているのです。
こう言った動きと、今回の「自己組織化するアプリケーション」と言うテーマと何が関係するのか、これから説明しますが、その前に、アプリケーションを操作して利用する人間も、このオブジェクトモデルで言うコンポーネントであることに注意する必要があります。
オブジェクトモデルでは、この人間も含むコンポーネントの群れが相互に干渉しあうことで、アプリケーションと言うものが動作していると考えるわけです。
アプリケーションに、新たな業務機能を追加する場合を考えましょう。
今までの考え方（モデル）では、システムエンジニアがこれを設計して実際のプログラムを書くことで実現すると言うのが、当たり前ですが普通のとらえ方です。ところがこれを、システムエンジニアではなく、アプリケーションの一部である人間というコンポーネントが、自分の近接して関係するコンポーネントを修正したり、新たに追加したりすると考えてみることはできないでしょうか、と言うことを、今お話ししているのです。
新しく追加されるコンポーネントは、それが全く独立して動作するわけではありません。近接するすべてのコンポーネントとコミュニケーションを取りながら動作するし、人間コンポーネントとのインターフェイスは、既存のインターフェイスを無視するわけにはいきません。コンポーネントが相互干渉しながらコンポーネントを産み出して行くと言うことこそ、自己組織化するアプリケーションの実態です。
この考え方を推し進めていくと、世の中のSNSの興隆や、BlogにおけるRSSの進化も、アプリケーションの自己組織化、進化と捉えることができるのではないかと考えられるわけです。
先の銀行システムの例は、アプリケーションの進化の例としては、最もプリミティブで原始形ですが、人間不在の旧システムから、人間と言うコンポーネントを含むアプリケーションへ進化させる唯一の方法ではないかと考えます。
さて、今回の一連のテーマの冒頭で、
なぜこんなことを議論するのかというと、アプリケーションの開発と言うことの本質を突き詰めていくと、実はこのアプリケーションの動作環境と開発環境の関係に行き着くのではないかと考え始めているからです。
と書きました。また、
CNETに載った「マイクロソフトの本当の姿」と言うコラム記事を読みながら、マイクロソフトの強さの秘密は、実は、このアプリケーションの自己組織化に成功しそのノウハウを蓄積していっているところにあるのではないか、逆に言えば余り成功していない分野ではこのアプリケーションの自己組織化に失敗しているからではないか、更に言えば、それは動作環境と開発環境が異なるアプリケーションの分野ではないのか等々、たちまち新たなる仮説を思い描くことができます。
とも書きました。
アプリケーションの開発環境と動作環境が同じと言うことは、すなわち開発者である人間と言うコンポーネントが、アプリケーションの中のコンポーネントとして機能している、と言うことです。逆に、二つの環境が分断された瞬間、アプリケーションの開発を担う担当者が、アプリケーションのコンポーネントとして機能しなくなると言うことでもあります。
これは開発者＝利用者と言う図式を主張しているのではありません。開発環境＝利用環境が最適アプリケーションを産み出すための成功方程式だと言う仮説です。以下次回。 KAI
マイクロソフトの伝説のプログラマー、デビッド・カトラー率いるWindowsNT開発物語「闘うプログラマー」の中に興味深い記述（[上]p.209,213）があります。
プロジェクトがはじまってから二年半になるが、コーディングにはOS/2を使っていた。そろそろ、NTを使って書くべきだ。複雑なプログラムの場合、早く各部を組み合わせるほど、バグを早く発見できる。複雑なソフトウェアを開発するときに、自分でつくったドッグフード（引用者注：プログラムのこと）を食べるのはめずらしいことではない。そうしなければ、オペレーティング・システムの各部を組み合わせたときに発生するバグは、発見できない。（中略）
ドッグフードへの切り替えは、三段階で実施された。第一段階ではグラフィック機能のないNTを使い、つぎにグラフィック機能をつけ、最後にネットワーク機能をくわえる。
この話は、新しいOSを、今開発しているOS自身を使用して開発することが、バグを消す一番の方法であることを示していますが、この方法のメリットはバグの発見だけにとどまりません。自分で実際に使ってみることで、使い勝手の悪さや、仕様自体の不備を、自分の目で確認することができます。
更に言えば、何もOSの開発に限ったことではありません。アプリケーション自体の開発にも同様の考え方が適用できます。アプリケーションの場合、開発そのものにアプリケーションを使用するわけではありませんが、開発する機能の検証に、開発しているアプリケーション自体を使用すると言うことになります。
アプリケーションの不連続性
こう言った開発の考え方の意味を、もう少し踏み込んで理解するために、アプリケーションの不連続性と言う概念を説明します。
全く新規に一からアプリケーションを開発する場合ではなく、既に動作しているアプリケーションに、新たに機能を追加する場合を考えます。通常、追加する機能にもよりますが、アプリケーションの一部の機能の追加であっても、その影響範囲を調べ、関係する箇所のコードの変更作業が発生します。この作業が、関連する全ての箇所で完了して初めて、アプリケーションを使用した確認作業が可能になります。
つまり、アプリケーションと言うものは、それに機能を追加したり変更したりする場合に、動作確認できる一定の範囲と言うものがあり、その範囲の中を細分化して動作させることはできません。別の表現をすると、アプリケーションの中身を、ある「状態」からある「状態」へ遷移させた場合、それらの中間の「状態」は存在しないと言う意味で、両者の状態は不連続であったと言うことになります。これをアプリケーションの不連続性と呼んでいます。
先のNTの例で言えば、『ドッグフードへの切り替え』における三段階が、それぞれ不連続であるのは一目瞭然です。
さて、次に、このある「状態」のアプリケーションと言うものが、アプリケーション自体の進化に決定的な影響を与えると言う話をします。以下次回。 KAI
ニンテンドーDSのようなゲーム機の上で動作するプログラムを、誰も、同じゲーム機で開発しているとは思っていないと思いますが、パソコン上で動作するアプリケーションは、同じパソコン上の仕掛けを使って開発されていることを不思議に思う人はいません。
しかし、よく考えてみると、ケータイ向けソフトにしろ、そのプログラムが動作する環境とそれを開発する環境は大概の場合において、全く別の環境であって、これが同じというほうが普通ではないのです。
なぜこんなことを議論するのかというと、アプリケーションの開発と言うことの本質を突き詰めていくと、実はこのアプリケーションの動作環境と開発環境の関係に行き着くのではないかと考え始めているからです。
今では当たり前すぎて誰も考えなくなっていますが、プログラムを作るためにはコンパイラーと言うプログラムが必要です。そのコンパイラーを作るためにもコンパイラーが必要ですが、そのコンパイラーを、世の中で初めて作った人は、当然コンパイラーを持っていませんでしたから、自分で治具と言われるプログラムを作って、そのプログラムでコンパイラーを作りました。
何を言いたいかというと、プログラムというものは、プログラムをプログラムの上に次々と積み上げて行くことで開発ができると言う事実です。これは、構造化におけるモジュールの集合がプログラムであるという概念とは全く別の概念であることに注意する必要があります。同じモジュールと言う用語を使うと、いわば、時間軸上のモジュールの集合体がプログラムと定義できるとも言えます。
この概念を生物学で言うところの自己組織化ととらえて、あらためてアプリケーションの開発とは一体どういうことか考えてみると言うのが、今回のテーマです。
CNETに載った「マイクロソフトの本当の姿」と言うコラム記事を読みながら、マイクロソフトの強さの秘密は、実は、このアプリケーションの自己組織化に成功しそのノウハウを蓄積していっているところにあるのではないか、逆に言えば余り成功していない分野ではこのアプリケーションの自己組織化に失敗しているからではないか、更に言えば、それは動作環境と開発環境が異なるアプリケーションの分野ではないのか等々、たちまち新たなる仮説を思い描くことができます。
アプリケーションの自己組織化とは、今あるアプリケーションを、今そこに存在するアプリケーション単体の存在と捉えないで、今のアプリケーションに至る以前のすべてのバージョンのプログラムを含めてアプリケーションと認識するという考え方です。もう少し具体的に言うと、例えばあるアプリケーションの画面に新しくボタンが追加されたとします。このボタンを押すことで、新しい機能を実行することができるようになるのですが、これは以前のバージョンのプログラムが存在しなければ実現できません。
通常、新しいバージョンのプログラムを一から作り直すと言うことはなく、従来のバージョンの画面の様式の上に新しい様式を適用していくのが一般的ですが、画面は変わらなくてもその性能が格段に進歩するというのは良くある話しです。この場合でも、以前のバージョンがあるからその性能の進歩を実感できるのです。
次回以降、このあたりの話しをもう少し詰めていきたいと思います。 KAI
CNETで、ケータイ用フルブラウザであるjigブラウザの好調振りが報じられています。
すわ、jigブラウザが、前回議論したケータイの「デスクトップ」標準を獲る存在になるのか、と一瞬思いましたがそうではなさそうです。
ITmediaに、jig.jpの福野社長へのインタビュー記事があるので、そちらを引用します。
ITmedia 組込フルブラウザとして有名なOperaとの違いは、どこにあるのか。「Operaとjigブラウザの大きな違いは、アプリとサーバのシステムを合わせて初めてブラウザとして機能するところにある。jigブラウザでは、サーバである程度の処理──HTMLのレイアウト解析を行って、アプリ側で扱いやすいデータ方式に変換して送っている。また、サーバ側で情報を圧縮するので、転送量が少なくなる。効果は、パケット料金というよりも速度向上に現れている」
つまり、jigブラウザは、ブラウザ単独の機能と言うよりASPサービスとの組み合わせでフルブラウザ機能を実現していると言うことになります。これはなかなか良いアイデアですが、恐らくどこかがこの方式のビジネス特許を申請しているのではないでしょうか。もしどこも申請していないなら今すぐやるべきです。こう言ったサービスは、ユーザーが増えれば増えるだけ体力勝負になって、最後は資本を持っている企業が勝つのは目に見えているからです。
ITmedia 例えば、PC上のWebメールサービスを利用するにはJavaScriptへの対応が必須だが。「JavaScriptの仕様があまりに多いので、普通には対応できない。メールを使いたいという要望は多いと思うので、ブラウザにメールを組み合わせたjigのメールソフトを考えている。これでPOPでアクセスできるアカウントには対応できる。オフィス系ファイルの添付ファイルも対応予定だ。ExcelやWordなどのファイルはHTMLに変換できるので、フルブラウザならそのまま表示できる」
ただし、ここに書かれているような方式（ケータイアプリ）でメール機能やRSS機能をサービスしても、先が見えていると言わざるを得ません。そうではなく、このアイデアを活かして、ケータイ用のフルブラウザ機能のASPサービスに特化するのが得策ではないかと考えます。
仕掛けはこうです。
アプリケーションサーバー上に、Firefox等のブラウザを用意して、自動マウント型で動作するようにセットアップします。ケータイ側のブラウザ機能には、このアプリケーションサーバー側のブラウザの画面をエミュレーションする機能をサポートします（一緒に、アプリケーションサーバー側のブラウザにもエミュレーションのためのEMプラグインをインストールしておく必要があります）。たったこれだけで全てが解決します。
このエミュレーションの中身を、もう少し具体的に説明します。
まず、ケータイブラウザを起動すると、自動的にASPセンターに接続され、ユーザーIDの認証を受けた後、アプリケーションサーバー側のASPブラウザが起動されサービスを開始します。起動されたASPブラウザの画面情報が、各種表示モードに従ってEMプラグインによって加工され、ケータイブラウザに転送されます。以降タイムラインに従って、差分情報のみの転送となります。
一方、端末を操作した昇りの情報をテキストモードのパラメタにして、EMプラグインに割り込みを掛けることで、ASPブラウザのキー操作をエミュレーションすることが可能になります。
この方式のメリットは数限りなくあります。
・ケータイ機種が変わっても全く影響を受けない
・各種ウェブアプリの実行の制限を受けにくい
・クライアントのディスク容量制限を受けにくい
等々
将来、ケータイの性能が向上し、かつ回線スピードが今の有線並みになったとしても、ウェブアプリをそのまま利用できるメリットは変わりません。
残る問題は、ASPサービスのためのサーバー環境です。
ここでも出てくるのがGoogle技術の優位性です。オンラインゲーム業界を支える技術−Googleの掌中に？（その４）で見たように、こう言ったASPサービスのサーバー技術としてGoogleのサーバーはうってつけです。いえ、技術だけでなく、ひょっとしてGoogleはこのサービス自体を準備中かも知れません（笑）。 KAI
CNETに興味深い記事「ノキア、スマートフォンの新製品を発表--手書き文字認識機能などを搭載」が掲載されています。
Nokiaはこのところ市場シェアを失いつつあり、第3四半期決算では減益を発表している。同社は新製品で、製品ラインの拡充および市場シェア奪還を目指す。Nokiaのマルチメディア担当ゼネラルマネージャーAnssi Vanjokiは、「スマートフォンはもはや、業界の中心となった」と声明の中で述べる。「モビリティは力強い原動力だ。スマートフォンは、世間の主流製品になっただけではない。業界の枠を超えた技術を結集して、さらなる革新を起こしている」（Vanjoki）
Nokia 7710にはこのほか、電子メール機能やVPN（仮想プライベートネットワーク）ソフトウェア、最大128Mバイトのメモリ、自分のBLogに接続できるアプリションも搭載されている。オペレーティングシステムはSymbian OSが採用された。
i-modeもこのスマートフォンに含めれば、「スマートフォンはもはや、業界の中心となった」とは正にその通りで、見方を変えればケータイの「デスクトップ」標準の争いです。
そのSymbian OSのライバル、WindowsCEのPocket PC陣営にも動きがあるようで、同じくCNETの記事「パームソース、株価急落--きっかけはTreoにマイクロソフトOS搭載の憶測」でPalmOneがWindowsCEを採用するのではないかとの観測が流れています。
投資銀行Needham & Coのリサーチノートによると、PalmOneは同社の人気スマートフォンであるTreoシリーズでMicrosoft製のハンドヘルドOSを利用できるようにする取り組みを進めていることを「暗に認めた」という。
PalmOneのTreoとFOMAやAUのWIN等と見比べても、アルファベットのキーの違いだけで、お互いほとんど違いがないように見えます。PDAから進化してきたケータイと、電話から進化してきたケータイが、今や同じ土俵に上がったと言って間違いありません。
今年の6月のエントリー「携帯もマイクロソフトが支配する？！」の中で、
恐らくMSは、今年の11月を目処に、携帯用IEを発表するはずです。携帯用IEはあらゆる携帯端末でそのままパソコン用ホームページが見れるようになる。なぜなら今の携帯のハードウェアの能力はMSが目指しているパソコンの能力に限りなく近づいていて、一方、ハードウェアのメーカーも開発競争の激化で、OSも含めてオープン化に向かわざるを得ない状況に追い込まれているからです。これが来年になれば雌雄を決する状況になってしまいますので、MSにとって今年が参入のリミットだと見ています。
と書いていましたが、事態はどんどん進んでいるようです。ブラウザ再考で検討した通りLonghornがらみでIE自体のリリースは見込めそうにないものの、Operaブラウザを初めとしてOSも含めて、ケータイのデスクトップを最終的に誰が獲るか目が離せません。 KAI
最終回
一連の議論を通して、私がブラウザを設計、開発する場合の要件を列挙します。
■ポイントは第二OSであると言うこと
■各種標準（動画を含む）をパーフェクトにカバーできるAPIを持つこと
■UIは、ブラウザUIを標準とし、AP独自は認めない
■AP独自UIをサポートするために、ターミナルサービス用API（サービス）を標準サポートする
■プラグインには、独自のAPIを認めない
■DBエンジン、メールエンジン、RSSエンジンを含むエンジンをプラグインできること
■以下諸々
恐らく、これらの雌雄はFirefoxが決めるんだろうと言う予感がします。
ますます目が離せない状況になりつつあります。 KAI