レベル: 初級 Judith Myerson, Systems Engineer and Architect
2009年 10月 06日 皆さんは、リアルタイム動作が可能な対話型のコラボレーション Web サイトが必要ではありませんか。この記事では、developerWorks のおなじみの寄稿者 Judith Myerson が、オンライン・コラボレーションを必要とする人達のニーズや、さまざまな理由による変更が可能なコラボレーション・モデルへの開発者のニーズに対応する方法について説明します。著者はオンライン・コラボレーションのシナリオとして、サプライ・チェーン管理、プラント・エンジニアリング管理、そして科学研究論文の 3 つを挙げ、またモバイル機器に対する IPv6 の影響について説明します。
はじめに
多くの組織で、Web 2.0 のツールを使って Web ベースのコラボレーションが行われるようになっています。そうしたツールには、対話型のオンライン・ミーティング、ソーシャル・ネットワーク、ブログ、Twitter、ウィキ、ブックマーク、フォーラム、ポッドキャスト、その他新たに考え出されるあらゆるツールがあります。人々は、スマートフォンやデスクトップ・コンピューターのブラウザーから Web を使って対話動作を行うことができます。そこに参加する人達は、E メール、チャット、ディスカッション・フォーラム、Web 会議、共有ホワイトボード、そしてファイル共有といったオンラインのコラボレーション・ツールを使用して、コラボレーションを行います。チャットは音声ベースの場合もテキスト・ベースの場合もあり、またポイント・ツー・ポイントの場合もあれば会議環境で行われる場合もあります。会議は、誰もが発言でき、やり取りできるオープンな場合もあれば、モデレーターがいる場合もあります。
人々は対話型のオンライン・ミーティングを利用して、オンラインでセールス・プレゼンテーションを行い、アプリケーションのデモンストレーションを行い、そして契約書の内容を検討します。また人々はセカンドライフなどの環境を利用して、任意の場所で、顧客やパートナー、従業員に対してビデオ・トレーニングや仮想学習を提供します。また、ウェビナーやオンラインの記者会見も以前よりも頻繁に行われるようになっています。こうした傾向は、多数の人が同時に参加するアクティビティーに限られているわけではありません。これらの手法は、さまざまな場所に分散したユーザーに対して IT サポートを提供するためにも使われており、リモート制御されたデスクトップを使ってリアルタイムで問題を確認したり修正したりすることが行われています。
コラボレーション・モデル
このようにオンライン・コラボレーションの形式は多様なため、そうした作業への参加の形式も多様なものになります。開発者はさまざまなオンライン・コラボレーション・モデルを使用しますが、使用目的はモデルごとに異なります。彼らはオンライン・コラボレーションに参加を望む人達のニーズに対応するため、1 つのコラボレーション・モデルを選択する場合もあれば、いくつかのモデルを組み合わせる場合もあります。そうしたモデルのうち、最もよく使われるのは、利用量に応じて支払うモデルと、会員制のモデルです。
利用量に応じて支払うモデルでは、人々は必要に応じてサービスにアクセスしますが、継続的に会費を支払う必要はありません。また、1 回きりのセッションのサービスを利用することも、何回かのセッションのサービスを利用することもできますが、そのために特別な契約をする必要はありません。多くの E ミーティング・サイトでは利用量に応じて支払うモデルを採用しています。
ユーザーは、利用量に応じて支払うモデルの手軽さと実利的な面を好みます。ただし、この手軽さと柔軟性は多くの場合、とても高く付きます。ごくわずかなサービスのみを必要とするユーザーは通常、その高いコストを受け入れ、レンタカーやホテルの料金と同じようなものと見なします。
会員制のモデルでは、ユーザーは会員になることで、サービス・プロバイダーと長期の関係を結びます。その場合、個人の会員になるケースもあれば、グループ会員 (エンタープライズ・ライセンスなど) になるケースもあります。会員制のモデルのユーザーは一般に、定常的にサービスを利用しているユーザーであり、他の人よりも頻繁にサービスを必要としています。そして、より良いサービスを受けるために、あるいはコストを下げるために、進んで長期間の関係を結びます。
どのモデルを選択するかは、実際にはアプリケーションの性質や、そのモデルの利用者次第で変わってきます。商用のコラボレーション・アプリケーションの大部分は両方のモデルを提供しており、会員になると料金が下がるようになっています。ただし、ユーザーが料金を支払う必要がないコラボレーション・アプリケーションもたくさんあります (Google Calendar や Yahoo Chat など)。
利用者の役割
アプリケーションのエクスペリエンスと要件は、そのオンライン・コラボレーションの中でユーザーが果たす役割によって変わります。これは重要なことですが、それはなぜでしょう。役割が異なると、要求される環境も異なります。例えば一部のユーザーは、デスクトップ・コンピューターのブラウザーの機能とは大きく異なるスマートフォンを使って参加するかもしれません。こうした違いによって、それに対応するためにアプリケーションの設計が変更される可能性があり、あるいは利用量に応じて支払うモデルのユーザーに対して、異なる価格体系が適用される可能性もあります。以下は、役割の簡単な説明です。
ユーザー・ロール
私はユーザーとして、E メールまたはカレンダーによる招待を私のスマートフォンで受け、オンライン・コラボレーション (例えばウェブキャスト、セミナー、またはトレーニング・プログラムなど) に参加するよう勧められますが、そのためにメンバー料金を支払う必要はありません。私はその会社の E メール・リストに潜在的な顧客として載っており、特定の製品群に関して無料のニュースを受信するように、あるいは印刷物よりも速く情報を入手できる他の方法で通知を受けるように設定されています。
私は、開催予定のセミナーやトレーニング・プログラムへの招待を E メールやカレンダーで受信すると、メインの Web サイトへのリンクをクリックし、その招待を受け入れるか、あるいは断ります。その招待を受け入れた場合、私はそのセミナーまたはトレーニング・プログラムに参加します。実際に参加してみて、その Web サイトのモバイル版がスマートフォン向けのサイトとしてあまり適切なものでなかった場合には、そのセミナーまたはトレーニング・プログラムが終わる前に、私は早々にそのサイトから離れます。
モバイル向け Web サイトの表示に対する印象、あるいは、そのサイトに音声会議と Web 会議、そしてアクティブなプレゼンテーション・メディアが統合されているかどうかは、招待を受けた人達に長く残る印象を与えるものです。サイトを離れた後に私は、そのサイトの管理者に対し、彼らが今後のセミナーやトレーニング・プログラム用に持っているリストから私の名前を削除するように要求するでしょう。ただし私が新たな通知を受け、モバイル向け Web サイトの設計が変更中であり、小さな画面、少量のメモリー、その他スマートフォンの制約に対応中だと知らされた場合は別です。
管理者ロール
私は管理者として、ユーティリティーにアクセスしたり、コラボレーション・プロジェクトを管理したり、ユーザー・アカウントやグループ・アカウントを作成したりすることができます。複数の人やグループが同じプロジェクト・ファイルにアクセスできるように許可することや、各人または各グループがアクセスして変更を行える環境に共有ファイルを用意することもできます。一部のファイルは (特に音楽ファイルや研究論文のファイルは)、リミックスや共有、あるいは再利用ができるように、Creative Commons ライセンスで保護する必要があるかもしれません。
さらに、場所から場所へと移動するセールス・チームやカスタマー・サービス・チームの人達がスマートフォンからメインのオフィスとオンライン・コラボレーションを行えるように設定することもできます。そして彼らに対し、リアルタイムでメインのオフィスとオンライン・コラボレーションを行えるように、また情報を共有できるように許可することができます。また、顧客が製品デモやアプリケーションのテストをする際には、デモの操作と質問ができるように設定することもできます。
オンライン・コラボレーションのシナリオ
ここでは「参加した後に継続利用する」モデルの例として、サプライ・チェーン管理、プラント・エンジニアリング管理、そして物理学研究論文の利用許諾という 3 つのシナリオを説明します。この 3 つのシナリオではいずれの場合も、皆さんはスマートフォンを使用して、音声と Web 併用の会議形式で予定されているミーティングに参加します。ミーティングでは、プレゼンテーション、アプリケーション、そしてデスクトップをライブ注釈付きで見ることもできます。さらに、参加者リストとミーティング情報を入手することや、ミーティングから SMS によるリマインダーを受信することもできます。
これらの機能を利用するアプリケーションを設計する場合には、スマートフォンのメモリー量、そして小さな画面のためのデザイン、という 2 点を考慮する必要があります。皆さんのスマートフォンには、モバイル向けの Web サイトを起動してオンライン・コラボレーションを行うために十分なメモリーが内蔵されているはずです。さらにメモリーを増やすためには、スマートフォンにストレージ・メディアを接続する必要があるかもしれません。スマートフォンで使用可能な最大量までメモリーを追加しても十分ではない場合には、より多くのメモリーを持つ別のスマートフォンにアップグレードする必要があるかもしれません。
いかに多くのメモリーをスマートフォンに追加しても、その量はデスクトップ・コンピューターのメモリーに比べれば、ほんのわずかな量にすぎません。デスクトップ向けの Web サイトには、スマートフォンで適切に動作するものもありますが、うまく動作しないサイトもあります。モバイル・アプリケーションやモバイル向け Web サイトを設計する場合には、ごく単純なサイトにするようにとどめ、デスクトップ・アプリケーションに見られるような、大量のメモリーを使用する華やかな装飾機能はあきらめる必要があります。
サプライ・チェーン管理
オンライン・コラボレーションを利用すると、Web 2.0 ツールを利用して他の人達と対話形式で、アイデアを生み出したり、そのアイデアやプロジェクトを共有したりすることができます。内部や外部の潜在的な参加者を E メールやカレンダーによってミーティングに招待したり、必要に応じてミーティングを非公開でセキュアなものにしたり、また、誰が参加しているのか、誰が発言しているのか、誰がブログに書き込んでいるのか、誰が聞いているのか、誰がミーティングから退出しようとしているのかを確認したりすることができます。あるアイデアやプロジェクトに関するコメントを一般の人から求めたい場合には、オンライン・コラボレーションを特定の期間だけ非公開モードから公開モードに切り換えることができます。
使用できるコラボレーション・ツールの一例として Blueimp による Ajax Chat があります (「参考文献」を参照)。私が developerWorks に寄稿した記事、「Ajax によるチャット」 (「参考文献」を参照) には、メインのチャット・アプリケーション・ファイルをダウンロードして解凍する方法を説明してあります。Ajax Chat には PHP コミュニティーのファイルが統合されています。
サーバー・サイドのチャット・ファイルをアップロードしてインストールする前に、データベース、チャネル、ユーザーという 3 つの設定内容を編集する必要があります。ファイルをアップロードしたら、データベース・テーブルを作成し、次にインストール・スクリプトを削除します。サーバーには MySQL をインストールする必要があります。
プラント・エンジニアリング管理
経営幹部、開発者、品質管理担当者がオンラインでミーティングを開き、製造所要時間を短縮するため、そして商品の購入、販売、会計のトランザクションをセキュアにするために、プラント・エンジニアリングに利用できる成熟した SaaS (Software as a Service) を構築することについて話し合います。経営幹部は彼らのスマートフォンまたはデスクトップ・コンピューターを使って、チームの (内部または外部の) メンバーと、目標、戦略、戦術的プロジェクト・アクティビティーを共有し、またブログに書き込むことができます。こうすることによって、経営幹部はリアルタイムでフィードバックを得ることができ、また財務、プラント設計、製造所要時間、供給管理、人事資金計画に関して、重要な決定を下すことができます。
ストレスのたまる電話会議や E メールによる回覧に別れを告げ、Ajax (Asynchronous JavaScript and XML)、JSON、Flash などの Web 2.0 技術を統合したオンライン・ミーティングを利用することができます。その選択肢は、非常にスケーラブルな IBM の Lotus® Connections などの商用ソリューションから、最大 20 人までの参加者で共有できる、Dimdim の Open Source Community Edition v4.5、「Liberty」といった無料のオープンソース・ソリューションまであります (「参考文献」には、Liberty プロジェクトのサイトとダウンロードへのリンクを挙げてあります)。
科学分野の研究論文
物理学者、情報スペシャリスト、そして開発者がオンラインでミーティングを開き、Web 開発プロジェクトのブログに書き込み、あるいはこのプロジェクトにアクセスします。このプロジェクトでは、物理学の法則と原理を情報科学あるいは別の科学分野に再統合するための、革新的な方法の検討が行われています。このミーティングで取り上げられるトピックは、おなじみの物理学の内容、つまり熱力学、量子効果、そしてフォルト・トレランスなどです。
物理学者はスマートフォンまたはデスクトップ・コンピューターを使用して、彼らの研究論文を Creative Commons ライセンスによって保護したり、対話形式のオンライン・ミーティングにリアルタイムで参加したりすることができます。チームのメンバーはプロジェクトごとまたは組織ごとに、彼らの作業をいくつかのタスクに分類し、その予定をオンライン・カレンダーに記入することができます。また、調査のための投票を共有することや、ニュースやヘッドラインを公開することができます。さらに、誰が何のトピックに関してブログを書いているのか、誰が今までに Creative Commons ライセンスを使って文書にアクセスしたのかを見ることもできます。
モバイル・アプリケーション開発者のためのヒント
第 1 に、デスクトップ・コンピューター向けの Web サイトを画面の小さなスマートフォン向けにも使おうと設計してはなりません。繰り返しますが、モバイル機器のメモリーと CPU 処理能力はデスクトップ・コンピューターの何分の一かにすぎません。モバイル向けの Web サイトはデスクトップ・コンピューター向けの Web サイトほど高速に実行されることはありません。
スマートフォンの限られたキーボードでは、データを入力する際のテキストの扱いが少しばかり面倒であり、ミスを避けようとすると入力が遅くなります。Bluetooth を使った折りたたみ式のフルサイズのキーボードがすべてのスマートフォンで使えるわけではありません。この記事の執筆時点では、マウスを使えるスマートフォンはありません。一部のスマートフォンではトラックボールを使ってカーソルの移動や画面のスクロールをしますが、どちらかというとマウス・ポインターというよりはカーソル・キー機能と言った方が適切です。アプリケーションでマウス・オーバーやマウス・クリック機能を使う場合には、モバイル機器ユーザーのために別の方法を用意する必要があります。多くの点で、これらの問題は Web サイトのアクセシビリティーの問題と似ています。そのため、アクセシビリティーの問題に対するソリューションと同様のソリューションを使える可能性があります。
こうした、ポインターの接続方法とテキスト入力の制限を考慮し、モバイル向け Web サイトは単純で使いやすい設計にする必要があります。コンテンツは同じものを使用し、CSS スクリプトを単純なものにします。配置は必ず左揃えにし、基本的な HTML と単純な画像を使うようにします。また、当然の助言に思えるかもしれませんが、その Web サイトを必ず皆さんの携帯電話でテストし、そのルック･アンド･フィールを確認する必要があります。一例として、IBM のホームページをデスクトップ・コンピューターで表示し、次にスマートフォンで表示してみます。どちらも適切に表示されますが、デザインは異なっています。
モバイル・ネットワークには時として大きなネットワーク遅延が発生します。Web サイトが多くのリソース・ファイル (例えば画像、スタイル・シート、スクリプト・ファイルなど) で構成されていると、それらによる遅延が加算され、起動が遅くなります。遅延を少なく抑えるためには、一部のリソース・ファイルの統合を検討する必要があります (例えば JavaScript リソースを 1 つのファイルに統合する、など)。
また、Web サイトとのやり取りには必ず無線信号の送受信が伴い、それによってバッテリーが消耗します。これを最小限にとどめる必要があります。また、Web サイトにモバイル・ウィジェットや機器常駐のアプリケーションが含まれている場合には、そのサイトが攻撃を受ける可能性があるため、脆弱性にも注意してください。モバイル機器は、ローカルの E メール・ボックスなどのデバイス・サービスにアクセスできるようにするために、セキュリティー・ポリシーを緩める傾向があります。
モバイル・コラボレーションに対する Ipv6 の影響
IPv4 (Internet Protocol version 4) は、スマートフォン、IPTV、その他インターネットに接続される多様な機器の増加に対応することができません。IPv4 ではまもなくアドレス空間が足りなくなるため、必然的に IPv6 への移行が必要になります。IPv6 は IPv4 よりもはるかに広範囲の IP アドレスを提供できるだけではありません。IPv6 によって、より適切に PC 同士を統合することができ、特にオンラインのコラボレーション・プログラムが容易になります (例えば携帯電話やハンドヘルド機器、その他日常的な機器を使ったサプライ・チェーン管理、プラント・エンジニアリング管理など)。
IPv4 と IPv6 のどちらを利用しても、IPSec (Security Architecture for the Internet Protocol) として知られるデータ・パケットのセキュリティーを実現することができます。つまり IPv4 と IPv6 のどちらでも、インターネット上で 1 つまたは複数の転送元から 1 つまたは複数の転送先へデータを転送する際に、セキュリティーで保護されたサービスを利用して、ファイル共有やその他のオンライン・コラボレーション・アクティビティーを実現することができるのです。IPv4 と IPv6 のどちらの IPSec も、データの転送中にデータが閲覧、変更、ハッキングされないよう保護することを目的としていますが、IPv4 と IPv6 での違いは、IPv4 用の IPSec はプロトコルのオプションですが、IPv6 用の IPSec はプロトコルの必須要件である点です。
IPv4 用の IPSec がプロトコルのオプションであり、必須要件ではないことを利用している企業は、このオプションをスキップし、独自プロトコルのセキュリティー・ソリューションで置き換えることができます。この 1 つの欠点は、そうしたさまざまなソリューションが使われているため、Ajax アプリケーションの IPv4 実装がさまざまに異なり、相互運用性の問題が起きていることです。IPv6 では IPSec がプロトコルの必須要件であるため、異なる IPv6 実装の間で相互運用性を実現することができます。
まとめ
潜在的なユーザーが要求するリアルタイムで対話型のオンライン・コラボレーションは、開発者、ビジネス・アナリスト、システム管理者、その他プロジェクトのメンバーにとって困難な課題かもしれません。しかし、デスクトップ・コンピューター、スマートフォン、その他のモバイル機器を対象に Ajax によるオンライン・コラボレーション Web サイトを開発する上で、何が問題なのかを認識し、解決することで、皆さんのチームのエクスペリエンスを改善することができます。SourceForge.net にあるオープンソースのプロジェクトや、IBM から入手可能なさまざまな商用ツールを調べてみてください (「参考文献」に詳しい情報があります)。
参考文献 学ぶために
製品や技術を入手するために
著者について  | | | Judith M. Myerson はシステム・アーキテクト兼システム・エンジニアです。ミドルウェア・テクノロジー、エンタープライズ・ワイドのシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク管理、セキュリティー、そしてプロジェクト管理を含む数多くの分野に関心を持っています。 |
記事の評価
| 
