Web 2.0:次世代ソフトウェアのデザインパターンとビジネスモデル(後編) - (page 4)

6. 単一デバイスの枠を超えたソフトウェア

 Web 2.0の特筆すべき特徴のひとつは、PCプラットフォームに限定されないということだ。Microsoftのベテラン開発者だったDave Stutzは、同社を離れる際にこう助言している。「今後は長きにわたって、実用性が高く、単一デバイスの枠を超えたソフトウェアが大きな利益をもたらすことになるだろう」

 もっとも、すべてのウェブアプリケーションは「単一デバイスの枠を超えたソフトウェア」と呼ぶことができる。ごく単純なウェブアプリケーションですら、少なくとも2台のコンピュータを必要とするからだ。ひとつはウェブサーバを格納しているコンピュータ、もうひとつはブラウザがインストールされているコンピュータである。すでに説明した通り、プラットフォームとしてのウェブが発展していけば、複数のコンピュータが提供するサービスをゆるやかに統合することによって、新しいアプリケーションを生み出すことが可能になる。

 しかし、「Web 2.0らしさ」とは単に新しいものを作ることではなく、ウェブプラットフォームの可能性を最大限に活用したものを生み出すことを意味する。Web 2.0の多くの原則と同じように、この原則も新しいプラットフォームに適したアプリケーションとサービスをデザインするための重要な洞察を示唆している。

 現時点で、この原則を最もよく体現しているのはiTunesだ。iTunesはユーザーが携帯端末を使って、ウェブ上の膨大な情報にシームレスにアクセスすることを可能にした。PCはローカルキャッシュかコントロールステーションとして機能する。ウェブ上の情報を携帯端末に配信する試みは、これまでにも数多く行われてきたが、iPodとiTunesの組み合わせは、複数の機器で利用されることを前提に設計された、最初のアプリケーションのひとつといえるだろう。TiVoもそのよい例だ。

 iTunesとTiVoは、Web 2.0のその他の重要な原則も体現している。たとえば、iTunesとTiVoはウェブアプリケーションではないが、どちらもウェブプラットフォームの力を利用して、そうと分からないほどシームレスにインフラと一体化している。ここではデータ管理がきわめて重要な役割を果たしている。また、どちらもサービスであって、パッケージアプリケーションではない(ただし、iTunesはユーザーのローカルデータを管理するためのパッケージアプリケーションとしても利用できる)。そればかりか、iTunesとTiVoは集合知も活用し始めている(その結果、どちらも知財分野のロビイストとの戦いを余儀なくされている)。iTunesの場合、参加のアーキテクチャは限られた形でしか実現されていないが、 podcastingの登場によって、状況は大きく変わりつつある。

 この分野はWeb 2.0の中でも、新しいプラットフォームに接続される機器が増えるにつれて、大きな変化が起きる可能性が高いと考えられている。電話や自動車がデータを受け取るだけでなく、発信するようになったら、どのようなアプリケーションが可能になるだろうか。リアルタイムのトラフィックモニタリング、フラッシュモブ(インターネットを利用して呼びかける集会)、市民ジャーナリズムなどは、新しいプラットフォームの可能性を示す最初の徴候にすぎない。

Web 2.0のデザインパターン

 Christopher Alexanderは著書「A Pattern Language」の中で、建築に関わる問題とその解法をまとめたフォーマットを定義した。Alexanderはこう書いている。「それぞれのパターンには、ある環境下で繰り返し起きる問題と、その問題に対する解法の核が記述されている。そうすることで、同じやり方を繰り返すことなく、この解法を何遍でも適用することができる」。これをWeb 2.0に適用したのが下記の8つのパターンである。

  1. ロングテール
    インターネットの過半数を占めているのは小規模なサイトだ。小さなニッチが、インターネットで実現可能なアプリケーションの大半を占めている。したがって:ユーザーセルフサービスとアルゴリズムによるデータ管理を導入し、ウェブ全体――中心部だけでなく周辺部、頭だけでなく長い尾(ロングテール)の先にもサービスを提供しよう。
  2. データは次世代の「インテル・インサイド」
    データ志向のアプリケーションが増えている。したがって:独自性が高く、同じものを作ることが難しいデータソースを所有することで、競争優位を獲得しよう。
  3. ユーザーによる付加価値創造
    競争力のあるインターネットアプリケーションを構築できるかどうかは、企業が提供するデータに、ユーザーがどの程度データを加えられるかによって決まる。したがって:「参加のアーキテクチャ」をソフトウェア開発に限定するのはやめよう。ユーザーが無意識に、または意識的にアプリケーションに価値を加えられるようにしよう。
  4. ネットワーク効果を促す初期設定
    自分の時間を割いてまで、企業のアプリケーションの価値を高めてやろうというユーザーは少ない。したがって:ユーザーがアプリケーションを使うことによって、副次的にユーザーのデータも集まるような仕組みを作ろう。
  5. 一部権利保有
    知的財産の保護は再利用を制限し、実験的な試みを妨げる。したがって:広範に採用されることでメリットが生じるものは、利用を制限せず、採用障壁を低くしよう。既存の標準に準拠し、制限事項を最小限に抑えたライセンスを提供しよう。「ハッキング可能」で「リミックス可能」な設計を心がけよう。
  6. 永久にベータ版
    デバイスとプログラムがインターネットに接続されている今日では、アプリケーションはもはやモノではなく、間断なく提供されるサービスである。したがって:新機能はリリースという形でまとめて提供するのではなく、通常のユーザー経験の一部として、日常的に提供していこう。サービスを提供する際は、ユーザーをリアルタイムのテスターと位置付け、新機能がどのように使われているかを観察しよう。
  7. コントロールではなく、協力
    Web 2.0アプリケーションは、複数のデータサービスの協同ネットワークによって実現される。したがって:ウェブサービスのインターフェースを提供し、コンテンツを配信し、他者のデータサービスを再利用しよう。軽量なプログラミングモデルを採用し、システムをゆるやかに統合できるようにしよう。
  8. 単一デバイスの枠を超えたソフトウェア
    インターネットアプリケーションにアクセスできるデバイスはPCだけではない。特定のデバイスでしか利用できないアプリケーションは、デバイスの枠を超えて利用できるアプリケーションよりも価値がない。したがって:アプリケーションを設計する際は、最初から携帯端末、PC、インターネットサーバを視野に入れ、統合的なサービスを提供しよう。

オライリー・ジャパン

CNET Japanの記事を毎朝メールでまとめ読み(無料)

-PR-企画特集

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]