ScheduleLayer

20030706
石原靖雄
schedulelayer@yahoo.co.jp

English

WordFile

マサチューセッツ工科大学トーマス・マローン教授が"Inventing the Organizations of the 21st Century."で述べているのと同じように、「組織に"属した"個人の視点ではなく、個人が自分の自由意思で複数の組織に"参加"する視点」が大切な時代になりつつあります。

一方でインターネットを基盤とした情報システムは進化の一途を遂げています。しかし実際は、旧態依然とした単一の組織への帰属意識を前提とした利用のされ方から脱皮しているようには見えません。例えばブロードバンドをうたうプロバイダ各社はコンテンツやサービスを独占しようとし、そのサービスを使うためには自分の組織に属しなさい、という戦略が多く見受けられます。

また、例えば一般的なグループウェアはその組織内での共有はしやすく作られていますが、基本的に単一の組織内以外ではうまく機能しません。個人はその組織の"リソース"であるかのようでもあります。ASPタイプのグループウェアは複数グループ対応を考えているものも見かけますが、他のASPサービスとの連携はあまり考えられていない点では同様です。

経済状況がそれを助長している側面もありますが、"Webサービス"といわれるものも、企業を中心とした"業界"の情報共有を模索することがせいいっぱいで、"個人"を中心に置いた情報システムは現状でもあまり見かけることはできません。

我々の日常はスケジュールと共に動いています。そのスケジュールは仕事とプライベートのそれと同じ時間軸の上にあります。また、我々は仕事・プライベートにそれぞれさまざまなグループに属しています。私は今後、我々個人は自分自身が優先順位をつけるべき複数のグループの情報を横断的に確認するツールが必要になるのでは、特にそれらのスケジュールを横断的に重ねて、自分の時間軸を管理する方法が大変重要になってくるのでは、と考えています。

私はその方法を、特定の企業や団体が提供しているサービスに特別に属さないと受けられないということではいけないとも考えています。そいいう意味であらゆる意味で「オープン」であるというのも非常に重要な要件です。e-maiｌがそうであるように、その作法で情報をやり取りできるインターフェースを持っていれば、どこにいても、どんなデバイスでも、どんな企業の提供するサービスでも相互にやりとりできるというのも重要な要件です。

もう一方で、私は、これは最初からより多くの人たちに使用されることを想定して構築されるべきだと考えています。例えば、すでにYahoo!Calenderのタイムガイド、eGroups、Yahoo!USで実現されているOutlookとのシンクロナイズ機能のユーザー・インターフェースの部分と、ASP事業者間の連携を図ることが、実現の近道ではないかとも考えます。

以上を踏まえ、例えばメーリング・リストサービスのカレンダー機能を以下に述べるように拡張できればうれしいと思っています。

以下、私自身の技術的な知識が少ないので、幼稚な発想かもしれませんがご賛同いただければ幸いです。

Yahoo!BBのサービス開始を皮切りに、インターネットの本来の使い方である「つながりっぱなし」が一般家庭に急速に普及しています。インターネットにつながるために電話代を気にする必要がなくなりました。これは日常生活とインターネットがシームレスにつながる画期的なことです。また、PHSでの定額サービスやホットスポットの普及により、モバイルでも接続において通話費を気にしなくても良い環境ができつつあります。

最近のブロードバンドは、この通信費を気にしなくても良い、という重要な要件は大きく取り扱われず、プロバイダやコンテンツ事業者が大容量通信の側面である動画の配信等に力を入れており、一部、オンデマンドサービスも現れていますが、情報の流れや質が「放送」の時代とあまり変わりないものがサービスの前面に現れています。

しかし、インターネットが普及している理由の大きな要素としての"１対1"・"1対多"・"多対多"の柔軟な情報のやりとりの可能性についてあまり大きく取り上げられてはいません。実はネットオークション、掲示板サービス、メーリング・リスト...本来このようなサービスが広く普及することが、先のコンテンツ配信の市場を広げ、私たちの生活を根本から変えることにつながるような気もします。

そのような中、現在ひとつ忘れられていることがあると考えています。"自分を取り巻く全てのグループのスケジュール情報の統合"です。コミュニティ・病院・学校等や会社・クラブ活動・ショッピングセンターの会員...全てが自分を取り巻くグループです。

企業内ではグループウェアが浸透し、メールやスケジュール、掲示板等のアプリケーションが使われているのですが、一歩その外へ出るとそのようなニーズを満たすアプリケーションは存在しません。一部ASPでそのようなアプリケーションは存在するのですが、そのASPのサービス以外との連携は難しい点では同様です。

一方、現在、eGroups等のメーリング・リストで自由なグループの形成は可能です。 Yahoo! Calenderで自分のスケジュールを公開することも可能です。また、 iCalshare.comのようなサービスで様々なカレンダー情報を見ることも可能になってきました。しかし、それらのサービスはバラバラで、統合的にサポートするサービスはまだ見当たりません。

私たちは昔から日常を複数の組織やグループにまたがって属しながら生活しています。「家庭」「コミュニティ」「勤務先」「学校」「クラブ」「仕事の組織をまたいだチーム」「レンタルCD会員」...グループの数はアメーバのように増えたり減ったりします。それぞれのグループはお互いに関連がありません。関連付けているのは誰でもない自分自身です。

それぞれの組織間の調整事項は自分自身の優先順位で決定します。そしてその組織間の調整事項の大きなウエイトが「時間」の調整なのです。まず自分が所属したり、関心のあるものの予定を苦労せずに知りたいのです。そのときに本当は自分の予定なんか公開したくないはずです。しかし私が知る限りそのような調整を行える情報システムは見当たりません。

メーリング・リストのサービスである「個人が、グループの量と質を柔軟に変化させられる」ことに「個人が、自分の所属する複数のグループのスケジュールを横断的にみることができる」という機能が追加されれば、組織の枠を超えた連携を伴う情報の非常に使いやすいのではないかと考えています。この「グループ」は仕事のチームだけではなく、コミュニティや家族、趣味の仲間も同様に取り扱えます。

このアイデアを「ScheduleLayer」と呼びます。

• 「柔軟に数や規模・質が変化する、自分が属しているグループ」の予定が自分のカレンダーに重なって表示される。
• 自分の予定を公開するわけではないので、プライベートと仕事で入力や確認の画面を分ける必要がないし、プライバシーも守られる(自分のスケジュールを公開する必要のあるグループには公開できるようにする)。
• 自分のカレンダーに重ねられたスケジュールの中で自分の時間を拘束するものと拘束しないものを切り替えることが可能とする。

抱えているグループの数・予定の数、主に仕事で使うのかプライベートが主なのか、フリーランスの人なのか工場で働いている人なのか、経営者なのかサラリーマンなのか、学生なのか、主婦なのか...ユーザーの数だけユーザー・インターフェースの種類が考えられます。それぞれの利用環境で画面イメージや、重なった予定の表現方法が違います。ヘビー・ユーザー層とライト・ユーザー層と、ユーザー・インターフェースの種類や利用料の課金方法も違ってきます。ヘビー・ユーザーは必要ならば有料でも良いと考えています。現状のPDAユーザーや、プロジェクト管理ソフトを利用している人たちがそれに相当します。ライト・ユーザーはこのようなアプリケーションに利用料を支払おうとは考えないでしょう。

ここで述べている「ライト・ユーザー」は、現状ではこのようなカテゴリのアプリケーションを利用していないでしょう。「手帳」で十分だと考えていると思います。ライト・ユーザーはヘビー・ユーザーからの紹介でScheduleLayerを使い始めることになるでしょう。企業からの広告としてのスケジュールを受け入れたりすることで、無料でエントリすることになります。使い始めた中からヘビー・ユーザーへ移行する場合も、提供されるインターフェースやサービスを提供する会社を乗り換えたり使い分けることで、今まで使っていたScheduleLayerを使い続けることができます。

私はこの「手帳」こそ最高のリピート・コンテンツだと考えます。個人の「手帳」は、セグメントされたターゲットへ有効な広告媒体になると考えています。また、多くのエントリ層を受け入れるための「広告」の存在がScheduleLayerの普及にとって大変重要な要素であると考えています。

ユーザー・インターフェースの上で大切なことは、ユーザーごとそのグループのスケジュールの取り扱い方が異なる、という点です。ひとつのグループのスケジュールはユーザーによって優先順位の高さが違います。これをコントロールして表示できるものを「高機能」、これら表示のコントロールの幅が少ないものが「低機能」ということになります。過密なスケジュールを表現するため、ヘビー・ユーザーが使うサービス（インターフェース）には所属するグループをカテゴライズする機能を持ちます。スケジュールをグループのレイヤーとして表現するとともに、所属するグループでカテゴライズし、それもレイヤーで表現することでユーザーのそのときの状況に合わせたカレンダー・ビューを表現させることができます。 

付加機能やデザインはユーザーの選択にまかせても良い考えます。自分がどれだけ多くのグループスケジュールをやりとりしているか、その頻度・機密性・付加機能の重要性とかで最適なSceduleLayerサーバを選択できることも重要な要素です。

ScheduleLayerを使い始めるために、ユーザーが今使っているクライアントソフトや端末機器を乗り換えなくても良いことも重要です。例えば、AgendusのようなOutlookやPalmのパラサイト・ウェア(既存のソフトウェアに被せて使うソフトウェア。ユーザー・インターフェースの拡張等のために使用)が必要になるかもしれません。

•  サーバ間やデバイスとサーバ間でデータのやりとりは「メール」で行います。(PostPetもサイボウズもメールの添付ファイルをそのように使っているようです)

• ScheduleLayerを実装したアプリケーションやサービスは、所属するグループのメーリング・リスト・アドレスからのiCaenderフォーマットのメールを手元のスケジューラに表示させます。

• スケジュールの変更や削除も同様の方法で行います。その際の追加・変更・削除の権限はそのメーリング・リストの管理の設定によります。そのユーザーにスケジュールを追加・変更の権限がある場合は、その操作が行えます。

• そのグループのスケジュールを一括コピーや、一括削除の機能を備えます。

• 送信元ドメインの正当性のチェックをどこまで行うか、ということはAmoebaE UNIT(後述)のサービスとして、ユーザーが必要ならば選択します。

• サーバ間情報の再同期等の機能も必要になります。

• 繰り返し予定、タイムゾーンの取り扱いに関しては現行の各アプリケーションによって仕様が異なりますので、どこまでScheduleLayer内で実現するかが課題になります。

※実装に関しては具体的な仕様の策定を行う必要があります。
※iCaｌenderについての日本語の解説は野村真人さんのページを参照してください。 
※神崎正英さんの RDFカレンダー：イベント情報の公開と活用という情報が入りました。(iCalendar RDF RSS)で実装の仕様が整ってきたような気がします。 20040324

実装について

1. ユーザーはまず自分のScheduleLayerサーバをどこにするかを決めます。バックアップ用のScheduleLayerサーバがあれば、設定します。

2. 自分が所属するメーリング・リストのカレンダーがScheluleLayerの作法で情報をやりとりできるようになっている場合、そのメーリング・リストのカレンダーの情報を自分が決めたScheduleLayerサーバとやりとりできる設定にします。

3. 自分のScheduleLayerサーバはどこのメーリング・リストサービスのカレンダーとカレンダー情報のやりとりをするかを設定します。この中には会社のグループウェアも含んでいます(会社のプライバシーポリシーが許せば)。

4. ここまでで自分のメインのScheduleLayerサーバとバックアップサーバ、ならびに各種グループのカレンダーの連携が可能になります。 

5. そのScheduleLayerサーバが各種デバイスとカレンダー情報をシンクロできる設定ならば、PDAとも連携します。

6. ただ、これだと設定が少し面倒です。メーリング・リストサービスとカレンダーのサービスとScheduleLayerのサービスがワンパスワードでシームレスに繋がっていた方が、インターネットの技術的な初心者にとっては優しいので、複数のメーリング・リストサービスが連携するか、eGroupsのようなサービスがワンストップでサービスを提供できれば、エントリしやすいと考えています。

実装イメージ

現状のグループウェアとScheduleLayerを比較してみました。 

※ScheduleLayerは複数の人やグループ間のスケジュール集約のためのツールです。このため、Palmに代表されるPDAやOutlookに代表されるPIMについてはそれ単体では個人のスケジュールを表現する「手帳」というユーザー・インターフェースの延長線上にあると考えるため、この比較からは外しました。これについては後述のAmoebaE UNITで説明します。

ScheduleLayerはAmoebaE UNITコンセプトの１ユニットです。

AmoebaE UNIT 

• 複数の事業者がそれぞれ単機能をユーザーに提供し、ユーザー側はそれらを選択して利用できる。 

• グループウェアが持つ利点や新たな機能をメーリング・リストに融合することにより、法人の情報系のASPとしても稼動できるようなシステム構成にする。

• 上司の承認が伴う「ワークフロー」や「基幹システムとの連動」、「会社のリソース管理」を除くと、会社の情報系のシステムは複雑なものは必要ない。"コラボレーション"に特化させる。

• 業界標準業の技術をできるだけ使うことにより、オープンな環境を構築する。

インターネットでコミュニケーションを成立させるための機能は単一のものではなく、複数の機能を融合させることが重要です。例えばインターネット接続・メールサーバ・メーリング・リスト、WWWサーバ、掲示板、ストレージサーバ…そして、一般的な大手ISP・ASP事業者は現在、全ての機能を自社のサービスで賄おうとしています。しかし、複数の事業者のサービスを横断して使いたいと思ったことはないでしょうか？メーリング・リストはこっちがいいけど、ストレージサービスはこちらの事業者がいい…とか事業者側から見ると、良いアイデアを事業化するためのサービスそのもの以外の、例えば認証システムやディスク容量、料金回収等の付随したシステムに関しては別事業者のサービスに乗っかることでよりスピードのアップとコスト分散が可能になります。

多数のサービス提供者が単機能を”アメーバ”のように増やし競争する。ユーザーはそれらを選択してアメーバのようにさまざまなサービスに触手を伸ばし、試用し、良いサービスなら対価を支払う、ということが可能なサービス群を提案します。当然、・サービス間をスムーズに行き来するためのモジュール間インターフェースの規定、・セキュリティ、・それぞれのモジュールが満たすべき技術的要件、・サポート体制…等の技術的・契約的問題は多いとは思いますが、この文書で述べているような「メーリング・リスト」、「ScheduleLayer」程度の種類のサービスならば割り切って割愛できる要件も多いのではないでしょうか？また、サービス提供者が自由にユーザーに対して新サービスを訴求できるということは競争を通じてユーザーがより良いサービスを受ける可能性を開くことができます。

この「AmoebaE UNIT」の考え方で、インターネット上のコミュニケーションスタイルの進化がより高効率に行われることになると思います。

デバイス・PIM・PDA間シンクロナイズ 

多くの種類のデバイス間で「シンクロ」できることが理想的です。この場合、デバイス間相互のシンクロをスムーズに行うのは技術的に難しいと思われるため、ピボット的なセンターサーバを用意し、そのサーバを中心に情報のシンクロを行うようにします。常にそのセンターサーバが最新情報を蓄積しているScheduleLayerサーバになっています。例えばそのセンターサーバは各プロバイダが持っていて、自分の加入しているプロバイダのセンターサーバを使う方法です。 

「シンクロ」にこだわるのは、例えばオフラインでPDAに自分でスケジュールを入れている際に、同時にScheduleLayerサーバに外から新しいスケジュールが書き込まれる可能性があるためです。この2つのスケジュールを合わせるには「シンクロ」させるしかありません。PDAとのシンクロが得意なScheduleLayerサーバも存在しますし、PDAとはシンクロしないものもあるでしょう。

Contents Administration System 

管理システム：特定のドメイン(例：@sample.co.jp)のユーザーが作ったグループについて、

• 会社として稼動状況等を把握できる。

• 記録としてグループごとのログ(またはメーリング・リストのシステムイメージのまま)を会社内のサーバに転送できる。

•  「Contents Administration System」を契約した法人は独自ドメインでグループを作れないか。

•  グループの作成・削除を含め、管理者として機能できる。

• 100ユーザー管理で年間30万円？

Automatic Indexer 

契約の場合は特定のドメイン(例：@sample.co.jp)のユーザーが作ったグループについて、その構成員が横断的に検索できる機能の付加。

複数メールアドレス 

一人のユーザーがプライベート用と会社用というように数個のアドレスを持っている場合、会社のアドレス(その会社が「Contents Administration System」の契約をしている際)でグループを作った場合は会社の記録に残り、プライベートのアドレスで作った場合は純粋にプライベートとして会社に把握されないようにするが、スケジュールは「ScheduleLayer」機能では両方を一元的に確認したりすることができるようにする。

Secure Suit 

セキュリティをアカウントごとに設定。基本的に法人を対象にするが、必要ならば個人でも利用可能。現状のサービスをそのままに、セキュリティの鎧をかぶせるような感じのもの。

• １アカウント年間1000円？

•  SSL、メーリング・リストからのSMTPの暗号化

• 課題：ユーザーからのSMTP・POP３の暗号化、クライアントソフトの暗号化対応。

マーケティングシステム 

グループの種類によってはマーケティング的にセグメントされた人の集まりであることがあります。それらグループが承認すれば、調査を行うことが可能

動作保証 

動作保証そのものも”サービス”とする。

Webアプリケーション （2004/7/4追加情報） 

Blog Wiki CMS（XOOPSなど）のコミュニケーションツールも、限られたメンバーの中だけでの利用の場合には、また違った有用性があります。これらのツールもAmoebaE UNIT化してメールリングリストにプラグインできるようにしていきたいと考えています。

私は現在、広告会社に勤めております。業務内容は「基幹系システムの構築と運用」です。

この会社には勤続10年になるのですが、営業職、マーケティング、インターネット関連のシステム開発、社内情報システムの構築、そして現在のものと、さまざまな職種を経験してきました。

世の中ではここ2年くらい前から「コラボレーション」という言葉が一般的になってきています。しかし、昔から広告業界の仕事のやり方はまさに「コラボレーション」の手法で行ってきました。

広告主との対話を元にどのような手法を用いればその問題点が解決できるか検討し、実施してきました。必要ならば「催事」を、あるときは「TVCM」を、あるときは「新聞折込チラシ」を、またあるときは「駅前でのティッシュの手配り」を、さらにそれらを複合した手法を駆使したりして。時にはもっと根本的に「広告主のブランディング」に関して調査・提案・実施を行う必要が生じます。

このように目的によってその仕事を遂行するための方法がまちまちで、プロジェクトメンバーがまちまちで、なおかつそのメンバーが所属する会社がまちまち、プロジェクトの期間もまちまち、規模も(予算的にも)まちまち、というプロジェクトを一人の担当者が同時に複数抱えて仕事をしています。「コラボレーション」を同時進行で複数抱えていることになり、広告業界では昔からこのような仕事の進め方をしています。

…ただ、基本的に文科系の業界なのでコンピュータ化が遅れ、その方法論を加速するためコンピュータシステムを利用しようとは考えなかったのかもしれません。

世の中で「コラボレーション」が唱えられるようになってから、それをサポートするというお題目でさまざまな情報システムが登場してきました。私自身の業務の必要性からそれらをこれまでさまざまに検討してきましたが、私たちの業界の仕事を本当の意味でサポートしてくれそうなものはいままでありませんでした。

 ということは、プロジェクトによって流動的に進行する本来の「コラボレーション」を本当にサポートするツールは未だかつてないのではないか、と考えるようになりました。

そんな中、1年くらい前から個人的に大学時代の学生寮の友人を集めたグループを「eGroups(http://www.egroups.co.jp)」で作り利用するようになったのですが、まさにこのメーリング・リストはこの懸案だった「コラボレーション」を実現できるツールなのではないか、と考えるようになりました。

グループ中の個々の機能やグループを作ったり削除したりというのが勝手にできる自由度、規模の自由度、クライアント端末のプラットフォームが一般的なインターネットツールであること等、まさに僕が求めていた「コラボレーションツール」でした。

これに「複数のグループの、特にスケジュールを横断的・俯瞰的に見る機能の付加」が実現できれば一般的なビジネスユースにも十分に提案できるツールになるのではないか、と考えています。

2001年3月23日