Group items tagged

インドのHindustan Timesの記事によると、GoogleはGmailのオフライン版を準備中ということだ。この記事は、Googleはすでにオフライン・クライアントのデザインを済ませており、現在（意外ではないが）Google Gearsの上でテスト中だとしている。GoogleはGoogleReadeのオフライン版を Gearsのプラグインですでに提供している。他社でGearsをプラットフォームに採用した例としてはZohoなどがある。

前回を参照していただければ、だいたいの使い方は分かると思う。すでにGmailを使っている方なら、画面左上に表示される「カレンダー」という文字をクリックするだけで自分のカレンダー画面にジャンプすることができる。Gmailアカウントを取得した辞典で環境は用意されているのだ。 　あとは予定を携帯電話で確認できるようにするとか、iGoogleのガジェットを使ってカレンダー画面に行かなくても予定がわかるようにするといった工夫をすれば、紙の手帳並の使いやすさが実現する。 　今週は、紙を超えてしまおう。 　紙の手帳の長所は携帯性で、短所は共有性だ。手帳は良くも悪くも自分だけのもの。予定のほとんどは他人との関係性のなかで生まれるから、電話やメールといったツールを使って、自分でコツコツと作り上げていくほかない。 　自分の都合はわかっても、他人の都合まで勝手に決めるわけにはいかないからだ。 　Googleカレンダーには共有という強力な武器がある。

自分を複数の存在に分解できるという話から始めよう。

メールアドレスのリンク（mailto:で始まるURL）をクリックしたときに、デスクトップのメールソフトではなくWebメールサービスを利用できるようになった。オプションの「プログラム」タブで「mailto」の右をクリックすると、メールソフトを使うかWebメールを使うかを選択できる。メール以外にも、RSS（Webフィード）やカレンダーのためのWebアプリケーションも選択できるようになっている。 　「mailto」は、デフォルトでは「Yahoo!メール」しか選択できないが、JavaScriptを使って好きなWebメールを利用する方法もある。たとえばGmailなら、Gmailのページを開いた状態でロケーションバーに「javascript:window.navigator.registerProtocolHandler("mailto", "https://mail.google.com/mail/?extsrc=mailto&url=%s","GMail")」と入力する。

Firefox 3では、Webアプリケーションに必要なデータファイルを保存し、オフラインの状態でも利用できる仕組みを取り入れた。これは、WHATWG（Web Hypertext Application Technology Working Group）によるHTML 5の草案にある「Offline Web applications」に基づいたもの。将来この仕組みを利用したWebメールが作られれば、オフラインで未読メールをじっくり読む、といったことが可能になる。

HTML、CSS、JavaScriptの新機能について、細かい点をいくつか挙げておこう。 JavaScriptがバージョンアップして「1.8」となった。関数オブジェクトを作るのに「function(x) x * x」のような構文が使える。 IEの独自機能contenteditable属性に対応し、HTMLの要素をブラウザ上で編集可能に変えられる。ワープロふうにWYSIWYGで記事を編集するブログなどで利用できるだろう。 CSSのime-modeプロパティに対応。これもIEの独自機能だったもの。フォームの入力欄を選択したときに、自動的に日本語入力のオン・オフができる。 長いURLをテキストとして表示すると、自動的に折り返されるようになった。URLを紹介するページでレイアウトが崩れることがなくなる。

私にとってGoogleカレンダーのいいところは、私はメール環境を完全にGmailに依存しているので毎日確実にログインすること。最初にも述べたように、メール画面からすぐに移動できること。この2つが大きい。 　そして、もう1つ。iGoogleの存在である。 　私はこのページをブラウザーのスタートページに設定しているのでいやでも目にする。 　で、Googleカレンダーと連動するiGoogleガジェットを見つけたというわけだ。 　「Google カレンダー」を追加しておくと、自動的に直近の予定が表示される。これで移動の手間さえ省けた。

今回は、一人で「Googleカレンダー」を使う場合について述べた。 　ただし、Googleカレンダーのホントの便利さは、家族で共有したり、他人を予定に招待したり、ローカルのカレンダーソフトと同期をとれる点にある。そのあたりの魅力についてはまた次回。

Synkiはユーザーごとに細かく権限を設定でき、複数のWikiサイトを開設できる点が特徴だ。ワークスペースと呼ばれる作業スペースごとに権限を設定できる。もちろんオフラインでも使用でき、オンラインになった時点で最新の情報に同期される。 　「Synkiは『Sync（同期）するWiki』という意味。Wikiは次世代CMSとして着目している。非常に生産性の高いツールで、仕事で利用するのに向いている。特に他人と共同作業をする場合に有効だ。社内ブログは、将来Wikiに置き換わっていくかもしれない。いずれはSynkiとGmailだけあれば仕事が完結するような環境を提供したい」 　Wiki記法を知らない人でも利用しやすいように、リンクタグなどを自動的に埋め込むボタンを用意する。今後はタグを不要にするWYSIWYGに対応するほか、スプレッドシートの共有などができるようにする。また、企業が使いやすいテンプレートも用意する。

ほかの企業システムと連携しやすいよう、APIの公開も考えている。「Synkiはプラットフォームに過ぎないと考えている。ユーザーの権限設定ができるので社外の人とも利用できるし、社内のデータを外部に出さないようにもできる。組織がフラットな構造で、社外とのコミュニケーションが多い司法書士や弁護士、PR業などが最も向いているだろう。ただ、それぞれの企業が独自の使い方を追加できるようにしていきたい」

ここまで苦労してでもGoogle Gearsを採用した、その最大の魅力は何だったのか。朴氏は将来的に標準になるという可能性に賭けたと話す。また、開発したサービスをオープンソースとして公開することも視野に入れていたことから、Google Gearsがオープンソースであることは大きな後押しになったようだ。 　「きちんとした製品を作り、ユーザーの支持を得てからオープンソース化しようと考えていた。Googleが専門部隊を持ち、オフライン機能に特化したモジュールを開発するのであればそちらを採用したほうがいいと思った」（朴氏） 　自社でモジュールを開発したほうが楽だったのではないか、という意地悪な質問をしてみた。すると朴氏は、「自社でやったらもっと時間がかかったかもしれない」とした上で、「でもコードのリファレンスがなくて苦労したので、最終的には同じくらいかな」と笑った。

SLAとは、SaaSプロバイダーに、ユーザー企業と合意したサービスの提供を保証させるものである。具体的にはアプリケーションのアップタイム、パフォーマンスの保証をはじめ、データ・セキュリティ、データ・バックアップ／リストアといったサービスのレベルも網羅する。もちろん、これらのサービスが契約内容に満たなかった場合のペナルティ条項（大抵は利用料金の減額）もSLAに含まれる。 　なぜSaaSを導入するうえでSLAは重要なのか。それは、ユーザー企業がソフトウェアの運用管理をSaaSプロバイダーに一任するため、プロバイダー側で発生した問題に対して、ユーザー企業はほとんど（あるいはまったく）手を出せないからだ。 　米国Burton Groupでアナリストを務めるエリック・メイウォルド（Eric Maiwald）氏は、SaaSプロバイダーと契約する前に、次の点を明確にしておくべきだと指摘する。 　「ビジネス・マネジャーは、SaaSプロバイダー側で発生した問題が、自社の業務にどれだけ支障を来すのかを把握しておく必要がある。どれくらいのダウンタイムなら許容できるのか、そしてそれはSaaSプロバイダーが提示している内容と一致しているのかを調査することが大切だ」 　いったん契約を締結し、ホステッド・アプリケーションが実装されると、途中から他のSaaSプロバイダーに乗り換えることは、コスト的にも時間的にも困難になる。

残念なことに、今日、ユーザー本位のSLAがSaaSプロバイダー間に浸透しているとは言えない。たとえSaaSプロバイダー側からSLAが提示されたとしても、その内容は限定的で中身のないものがほとんどである。これはプロバイダーの規模と関係なく、どこも似たり寄ったりだ。米国THINKstrategiesでアナリストを務めるジェフ・カップラン（Jeff Kaplan）氏は、「現時点では、ホステッド・サービス・スイートを幅広く網羅するSLAが確立されていない」と指摘する。 　例えば、米国Googleが提供している企業向けホステッド型アプリケーション・スイートの「Google Apps Premier Edition」（以下、Google Apps）も、SLAは電子メールの「Gmail」に限定されており（稼働率99.9％を保証）、オフィス・スイートの「Google Docs」やWebページ作成ツールの「Google Page Creator」などは対象外だ（画面1）。

ただ残念ながら、この“クラウド”も、現時点ではまだ実用的ではない。グリッド・コンピューティングやSaaS（Software as a Service）、アプリケーション・デリバリの管理、グローバル規模でのアクセスなど、ほとんどの技術がまだ幼年期にあるからだ。シン・クライアント型アプリケーションも、初期のWebがそうであったように、まだ先行き不透明な荒削りの欠陥製品にすぎない。 　ただ、そうした限界はあっても、Googleはサーバや特殊なインフラを導入することなく、データを簡単に共有できるホステッド・モデルの強みを生かして全力を尽くさなければならない。Microsoftはすでに（パスワードでプロテクトをかけたSharePointのワークスペースにすぎないとはいえ）Web経由でドキュメントを共有できる「Office Live Workspace」（画面1）のベータ版をリリースし、クラウド・コンピューティングのトレンドセッターのポジションを奪い取る姿勢を見せているからだ。（もちろん、Office Liveという名称にもかかわらず、Officeの全機能を提供しているわけではないので、今のところそれほど脅威ではない）。

おそらくGoogleの究極の競合は、ユーザーが長年慣れ親しむWindowsとOfficeを組み合わせた環境の快適さと、ホスティング型アプリケーションのアドバンテージを融合したハイブリッド・モデルになるだろう。それこそがまさにMicrosoftの目指す方向なのだが、皮肉なことに、Windows Vistaと「2007 Microsoft Office system（Office 2007）」の大幅なインタフェース刷新、ならびにOffice 2007の不安定性に対する不満が、IT部門のMicrosoft製品離れを引き起こしており、Googleに絶好のチャンスをもたらしている。

しかしGoogleは今、大きなプレッシャーに直面している。企業向けホスティング型アプリケーション・スイートの「Google Apps」をはじめ、オフライン対応のWebアプリケーション開発／実行環境「Google Gears」（画面2）への期待は大きいものの、実際のところ、どれをとっても不十分なものばかりであるからだ。唯一「Gmail」だけは例外と言えるが、全体的に見れば、現行のデスクトップ・アプリケーションと比較して遜色がないと言い切れるものはない。実際、まちがってF5キーを打ってしまっただけで、時間をかけた労作がいとも簡単に消えてしまうなど、ビジネスで本格的に利用できるレベルにはまだ達していない（こうした欠陥は改善されつつあるが、Google Appsの未成熟さがいかんともし難いのは事実だ）。