デスクトップの争いは今から20年前以上に戻ります。今の若い技術者にとって、記憶の外あるいは生命の外のお話ですが、きわめて重要な技術史です。
当時汎用機でTSSと言われたリアルタイムの技術は、後にパソコンと言われる技術の中でコマンド指向言語によるインターフェイスの教師となりました。
その世界を決定的に変えたのがWindows95のデスクトップです。決して95がパイオニアであると言っているのではありませんが、今ある世の中のパソコンのUIの標準のきっかけになった製品であることには間違いありません。
以来、私たちはデスクトップメタファーがまるで当たり前として、アプリケーションのUIと考えてきた（と言うより無意識に）のです。技術論的に言えば、UIとは、OS（オペレーティングシステム）の操作言語のことです。
それがここにきて、ブラウザがここで言う従来からのOSとしての機能を分担し始めたと言うことを理解する必要があります。今回はここまで。 KAI
どうもアルコールが入って書くBlogは断定的口調でいけません。主旨そのものは間違ってはいないのですが、後から読むと、もう少し補足した方が良いようです。
前回の話しのポイントは、ブラウザを一つのアプリケーションと見なすのではなくブラウザをデスクトップと見なしてその上で動くアプリケーションこそ本来の意味のアプリケーションだと言うことです。ここで言うアプリケーションとは、単純にHTMLで書かれたホームページの内容がブラウザで表示されているものとは明確に区別されるもので、クライアントにインストールされたアプリケーションパッケージと同じ操作性で利用できるものである必要があります。
Webベースのアプリケーションが色々と開発されていますが、JAVAアプレットベースでは遅くてミッションクリティカルな業務システムには使えないと言うのは周知の事実です。これを解決するのがアクシスソフトのビズブラウザと言う製品です。これを使用することで従来のクライアントサーバー型のアプリケーションと同じ感覚の操作性を実現することができます。
このビズブラウザをブラウザの一種と見なすと、IEでは具体性に乏しかった、ブラウザというデスクトップ上で動作する様々なアプリケーションパッケージの流通が実現します。アクセスキーさえ手に入れればその場で利用できるようになる仕掛けは言うまでもありません。
しかも、このアプリケーションパッケージの特徴は、クライアントインストール型のパッケージと違って最初からネットの中のアプリケーションですから、サーチエンジンを初めとしたWebサービスを内包しています。これを明示的、埋め込みいずれの方法でも利用できますから、実現できる業務範囲は限りなく拡大します。
更に、このアプリケーションは、従来のHTMLベースのASPサービスと違って、ネットワーク上のアプリケーションサーバーへのインストール型ですから、ストレージサービスと一体化した、企業の業務システムのASPサービスとしても十分使えるものです。もちろんB2Cとしてのメーラーやオフィス製品としての機能も容易に実現できます。
こういったアプリケーションを、従来のそれと明確に区別する意味で、新しいアプリケーション・カテゴリーの誕生と表現しています。
さて、今回のエントリーからしばらくの間、この「ブラウザとは一体何か」について、あらためて考察してみたいと思います。以下次回です。 KAI
期せずして同じ問題意識の記事が幾つか上がっています。
デスクトップが123やワードに進化したごとく、ブラウザから新しいアプリケーション・カテゴリーが誕生しようとしています。あたかも種の爆発を予感させるがごとき出来事が、これから起ころうとしています。
いままで私たちは大きな誤解をしていました。ブラウザは単なるデスクトップであってメインの機能はその先にあるにもかかわらず、いつの間にかあたかもブラウザがアプリケーション・カテゴリーであるかのごとく観念でITを理解しようとしていたのです。
記事の一つ目は、いつもの渡辺聡さんのBlog「A9とは何か：John Battelleの見立て（2）」から。
さて、最後の最後にAmazonにとってA9とは何になるのか。予言的になってしまうが、結論を先に書いてしまうと、彼らはAmazonのUI自体を考えているのだろう。もし、サーチが世の主流なトラフィックとなり、Amazonに来て商品を探すという行為がレアになるのなら、サーチそのものの中でどのようなポジションを得ていくのかがAmazonにとっての勝負どころとなる。
ユーザーはAmazonに来て商品を探すのではなく、情報を探した結果必然的にAmazonに辿りつき、ついでに「ふんふん、なるほど」で終わらずに商品購入と決済も出来てしまうという流れに変わる。
そういう世の中になる、もしくはなっても大丈夫なように手を打っているというのがAmazon全体からみてのA9だと解するのが綺麗である。完全に統合される方向で動くのか、別個で動きつつAmazon字体はWebAPI、Webサービスの塊として機能しつつフロントのみA9が取るような形になるのかはもちろん分からないが（おそらく後者だろう）、最適なポイントを探してバランスを見ていくことは間違いない。
A9を含めたAmazon全体を一つの大きなアプリケーションと見なすと、以前のソフトセクターの議論の中のKAIモデルで言うところの、＜業界＞＜業務＞＜業務機能＞＜機能＞を縦方向に一気通貫で実現するアプリケーションシステムと言うことになります。つまり単なるブラウザのUIレベルの問題ではないと言うのは明らかです。
次に梅田さんのBlog。タイトルの「データの重要性を指摘するO'Reilly」と、実際の内容ではずいぶんかけ離れているのですが、要はアプリケーションに最適化したUIが渇望されていると言う事実です。
eメールやIMも「ソーシャルソフトウェア」ととらえなおして、もっと面白いものをどう作れるか考えるべきだと、Timは主張する。結局、Googleという会社はそういう諸々を統合することをずっと考えてきたのだろうな、とあとになって気づくわけであるが、eメール、IMといった旧来からのコミュニケーション・アプリケーションに、ソーシャルネットワーキング(SNS)、サーチ、Blog、RSSといった新事象を融合させてどんな新しい価値を生みだせるのか、というあたりが、いま最もホットなバトルフィールドになりつつある。
これらをブラウザ（デスクトップ）ではなく各アプリケーション機能と認識すると、要は、求められているのがデスクトップ上の具体的なアプリケーションであると言うのは明白な事実です。
Firefox、5日間で100万回のダウンロード--予想をしのぐスピードで目標達成
ここにあげたような話は、世間ではブラウザ戦争と誰もが思うでしょうが、実態は、ブラウザ機能を内包したアプリケーション戦争以外の何者でもありません。 KAI
ここんところ考えないといけない案件が山のようにあって、Blogでの論考に時間が割けなくなっていますが、気になるエントリーがありましたのでコメントします。
いつもの渡辺聡さんのBlog「検索を再定義する」からの引用です。
一言で書くと、サーチの利用履歴から導き出したページのお勧め、Amazonサイトでいつも経験している本のお勧めのサイト版となる。Bloglinesに実装されているBlogのお勧めやAmazonのレコメンドにしても、いつもいつもホームランとは行かずとも、そこそこ使えるリストを提供してくれている。サイトについてもある程度熟成が進めばそこそこなものは提供されるに違いない。A9が伝えたいメッセージの一つが、「ボックスに何か単語を入れたら情報のリストが出てくる、検索とはただそういうもので良いのか」というものではないかと考えている。
このエントリーに対して、磯崎さんがトラックバックしていて、このサーチエンジン周りの時代の背景を「知恵の晴れ上がり」と言うすばらしい言葉で説明しています。
この考え方は、私がサーチエンジンに関する一連の論考の中で「サーチエンジンの大航海時代の幕開け」と表現していることと相通ずるものです。
問題は、一デスクトップのパーソナライズにあるのではなく、その検索者たる人間のシソーラスそのものの記憶と補完、および、サーチエンジンによるシソーラスを使った編集の中にあると言うことですが、時間ができ次第詳細をエントリーしたいと思います。 KAI
サービスを誰が提供するのか
再びCNETの渡辺聡さんのエントリー「IT投資の質的変化(２)：ソフトウェアビジネス編」を取り上げます。
さて、ここまで来たところで、改めて問いたいことがある。仮にWebサービス的な実装方法が順調に普及し、サービスレベルまで分解された機能を組み合わせてシステムを組み上げるような仕組みになっていったとして、そのサービスを誰が提供するのか。まず普通にあるのが、社内部門。アプリは外から買って構築を外部パートナーに依頼したとしても、資産としては自分達のものをするこれまでと基本変わらない方法。次に、ASPサービスがWebサービス化していくパターン。このパターンだとベンダーが提供する標準的なサービスをベースに組んでいくこととなる。eBay、Amazonなどが標準的に準備しているAPIもここに含んでしまって良い。最後に、大規模アウトソースのように、ユーザー企業とテクノロジーベンダーが一緒になって、ベンダー側に構築から運用までを任せきるパターン。IBMやEDSが代表事例となる。
それぞれ、
・個別個別のサービスを提供する
・サービスを取りまとめて、統一的なプロセスを設計管理する
・そもそもどういうサービスが必要かを考える
の三つを誰が担うかが変わってくる。上に行けば行くほどベンダー側の仕事となり、下に行けば行くほどユーザー企業側の仕事となる。インフラを誰が提供するのか、というポイントもあるが、中間領域を誰がどのように分担するのかが当面の間模索の続く領域となる。個別管理を可能とし、柔軟性を高めたところで、最後何らかまとめないといけないことには変わりない。
ソフトアセットとしてのWebサービスの位置づけについてはまた別に議論するとして、この「サービスを誰が提供するのか」は確かに重要なテーマです。しかし、このテーマの本質は、今までの私の議論を読んで頂ければ一目瞭然ですが、ソフトアセットである業務ノウハウを誰が持っているのか、という問いでもあるのです。
簡単に考えると業務ノウハウはユーザー企業側にあって、その実装ノウハウがベンダー側と思いがちですがこれは必ずしも正しくありません。ユーザー企業が押さえていると思っている業務ノウハウは、前回の私のエントリーで例示した業界の4800の機能の内せいぜい3割、1600です。それではこれを3社集めれば4800になるかと言えばせいぜい1800かそこらしかなりません。つまり4800にするには少なくとも百社以上、場合によって数百社のユーザー企業の業務ノウハウを集める必要があると言うことです。
これに対して、1企業にとって4800の機能はすべて必要ではなく、自社で必要となる機能で十分だとの反論があります。しかしそうはうまく問屋が卸しません。既に保有している業務ノウハウは問題ないにしろ、これも前回のエントリーに書いた通り、企業の必要とする機能は時間軸とともに次々と変化していきます。そのノウハウを自社の経験と言う形で時間を掛けて獲得していくか、ベンダーを含む他社（あるいは人材）が所有するノウハウをお金で買うかいずれかになります。
どちらが効率的かは考えるまでもありませんが、通常ユーザー企業（特に日本では）がとる方法は前者であり、結果的に業務ノウハウを持っているのはユーザー企業側となっているのです。
しかし、これも既に議論してきた通り、ソフトセクターの流れはこの業界全体の業務ノウハウの獲得と実装と言う次元に移っており、これは1ユーザー企業にできるものではないのです。もちろん相も変わらず多大なるコストを負担する自社開発、自社メンテナンスを選択する企業は残りますが、これは4800に含まれない機能の業務ノウハウを持つユーザー企業に限られてくると思います。
物流サービスが物流専門会社による全国ネットワークに集約されていったように、ネット社会では、ユーザー企業＝業務ノウハウと言う図式ではなく、ネット社会の専門企業＝業務ノウハウと言う構造に収斂していくというのがKAIの推論です。 KAI
ソフトセクターの競争戦略（４）KAIモデル
このところDoSアタックが凄まじいです。外部から自分のBlogが見れなくなったと思ったら、10数ヶ所のIPアドレスからアタックを受けていました。RSSフィーダの不具合を利用したアタックだと思いますが、完全にルーターがビジー状態でした。この春からBlogを始めましたが、このせいでアタックを受けると言うのは痛し痒しです。
さて、前回のエントリーを書き直すつもりでしたが、追加で書いていきます。
KAIモデルのパラメタである「業界」、「業務」、「業務機能」、「機能」とはどう言ったものか理解するために、簡単な目安を示します。それは私たちのASPサービスの対象である通販業界を例に説明すると、この業界の約半数の企業が、60の業務、600の業務機能、4800の機能でカバーできると言うものです。これは1企業が4800の機能全てを必要とすると言う意味ではなく、1企業で必要となるのはこのうちせいぜい約3割の機能です。
1機能は約300から500ステップですから、業界システムとしては、全体で約200万ステップになります。このシステムの規模について、以前のエントリー「「システム」と「ツール」続き」の中で、
100万行、業界用語？で1000K。（20年以上前のことでかなり記憶が不確かですが、銀行のオンラインシステムが3000K程度だったと思います。これを大体300人位の体制で開発していたと思いますので、石黒さん達の体制を45人と仮定すると丁度生産性が2倍程度向上していることになります。）今まともなアプリケーションシステムを作ろうと思えば、この100万行程度のコードが必要です。
と書いたのはこう言う裏付けを持っているからです。
更に上で、「1企業で必要となるのはこのうちせいぜい約3割」と書きましたが、KAIモデルでは、企業毎の3割の組み合わせに一定のパターンがあるわけではなく、その企業一社毎の、業務内容に合わせて幾つかの機能が必要となり、しかもこれは時間とともに変化していきます。
このことから色々な仮説を導くことができます。
■既存の業界用アプリケーションが通用しないのは、圧倒的に機能が不足しているからではないか。
■不足している分をカスタマイズしても、その機能が、既存機能と連携していないのではないか。
■カバーするのが一部の限られた業務になっているのではないか。
■不足する業務を、まるで設計思想が異なる他のアプリケーションと、データレベルで連携できると考えているのではないか。
これらについての検証は次回以降に譲るとして、更に論を進めます。
さて、本題のソフトセクターの競争戦略としての、ソフトアセットである業務ノウハウは、4800の機能一つ一つの中にあるのではなく、4800の機能の組み合わせの総体の中にあると言うのは明かです。別の言い方をすると、ソフトアセットは4800の機能が全てそろってこそソフトアセットとしての価値を持つと言うことです。
メッセージ型ソフトセクターを選別する基準とは何か、ソフトセクターの競争戦略とは何か、この事実から容易に導くことができます。
それは、ソフトセクターの競争が、数千規模の「機能」をいかにコントロールするかの戦いの次元まで上がってきたと言うことです。これは、今までの、限られた数の機能の中でいかに品質の高いアプリケーションを供給するかという戦いのステージとは、量も質も異なる全く別次元の世界の競争です。
小手先でWebサービスを設計するようなアプリケーション開発では今や通用しない時代にシフトしてきていると言うことでもあります。以下次回。 KAI