SE関のノーツ/ドミノ徒然草: 第26回 情報の流れと蓄積の設計者

ノーツを入れて一、二年。ユーザーもノーツに十分慣れて使いこなしてくると、必ず起こってくる問題の一つが個人のメールデータベースの急激な増加です。最初10MBを目安にしていたものが、20MB、30MBと爆発的な勢いで増えつづけ、ひどいユーザーでは100MBや200MBという人も見うけられます。いったいこれはどうしてでしょう。大量の情報がユーザー間で流れるようになったのはたいへん喜ばしいことなのかもしれません。しかしその大量の情報がユーザーごとのメールデータベースにごみのように蓄積される様子はどうも問題がありそうです。今回はこのメールデータベースのサイズの問題を通して見える、実は情報の流れと蓄積の設計という課題について考えてみることにします。

Lotus クライアント テクニカル プロフェッショナルズ, ソフトウェア事業, 日本アイ・ビー・エム株式会社

Lotus クライアント テクニカル プロフェッショナルズ, ソフトウェア事業, 日本アイ・ビー・エム株式会社



2006年 12月 11日

まずはメールデータベースの中身の問題です。いったい何十、何百MBのメールデータベースには何が入っているのでしょうか。中身をみてみましょう。上司が、またその上の管理職が、自分のメッセージを伝えるために自分の部下に発するメッセージメールの山。また本社のある部門が全社員に新しいルールや手続きを徹底させるために送る通知メールの山。あとはグループで仕事をしているときにプレゼンテーション資料や表計算資料を、更新するたびにグループ全員に繰り返し送る添付メールの山。こんなばら撒きメールが各ユーザーのメールデータベースを占領しているようです。で、どんなふうに使われているかというと、自分のメールデータベースをこまめに整理している人は稀ですから、実際はごく最近のメールだけが時々参照されているだけのようです。そのうちどれが大事でどれがいらないかなどはわからなくなり結局消せないままでメールデータベースは膨れていきます。そうそうこんな人もいました。自分の作った資料を添付して自分に送ってためている人。まさにメールデータベースをファイルサーバーとして使っているようです。これだとメールデータベースはいくらあっても足りないのは当然のことです。

こうなってくるとシステムは危機的状況に陥ります。システム管理者は仕方なく、『皆さん、メールデータベースの文書を整理して消してください。』と繰り返し繰り返し言いつづけなければなりません。しかしユーザー側からすれば、『どれもそれなりに重要なものなので、なかなか消せない』という声も聞かれます。たしかに飲み会の通知のようなメールや会議の通知のメールはすぐに整理できるかもしれません。しかし飲み会と会議通知などは文書だけの小さなメールで消しても大したサイズの減少にはつながらないでしょう。いったい何が問題なのでしょうか。

考えてみればこのような使い方はノーツをメールだけの使い方に限定していないでしょうか。全ての情報のやりとりをメールに頼り、その蓄積は個人のメールデータベースとしている。そんな情報の流れと蓄積の様子が見えてきます。ノーツは元々はデータベースを中心とした情報共有の仕組みです。情報の流れと蓄積という視点にたって、この仕組みをメールでの情報の流れとからめて使っていくことはできないでしょうか。

こんな例があります。部門で頻繁に上司が部下全員にメッセージやお知らせなどのメールを送っていることから、部下のメールデータベースには上司のメールが山ほど蓄積されてしまいました。そこである人のアイデアでその部門のデータベースを作り、メールが部下同様にそのデータベースを宛先にして送れるようにメール受信データベースとして定義しました。そしてその部門のグループにそのデータベースの宛先の名前を入れました。こうすることによって上司はまったく意識せずに部下全員とともにそのデータベースにも文書を入れることとなりました。部下は皆そのデータベースの存在を知っていますので、上司からのメールはそれ以降あっさり読んで消すようになりました。あとは必要なときに昔のメールを探すときはその部門のデータベースに見に行くそうです。

このようにノーツのメール受信データベースという昔ながらの仕組みを作ることで、上司から四方八方に川のように流れていた情報、かつ至るところに蓄積だけされて山積みで使われなくなったごみが、すぐに処置されて消えるだけでなく、きちんと別の湖のようなデータベースに蓄えられて、必要に応じてそこにユーザーが集まるような、そんな仕組みができたわけです。ほとんど開発もいらない簡単な仕組みです。これは部門掲示板という形での部門共有のデータベースという考え方に似ていますが、メールという使い慣れた道具を使う点で若干敷居が低いやり方かもしれません。

またこのようなやり方の他のバリエーションとしては、部門共有の掲示板データベースを作り、そこに文書が登録されると自動的に部門ユーザー全員にメールが文書リンク、またはそのままの形で飛ばされるというような仕組みも考えられます。これは湖からそれぞれのユーザーに川を通って水を流すような仕組みと言えるでしょう。

この川と湖のような情報の流れの考え方は、このような簡単な掲示板とメール的なアイデアにとどまらず、いろいろなアプリケーションに応用できるでしょう。グループや部門で共有する文書データベース。共有ファイルサーバーの代わりにデータベースを置いて、そこに添付ファイルの文書を送付すれば、そのタイトルと文書リンクだけメールで特定の人に通知するようなことも考えられます。

もちろんユーザーの意識が高かったり、リテラシーが高く、必ず必要な湖であるデータベースのそばにきてくれるのであれば、流れの川であるメールを利用しないということも考えられます。そのときは互いの意見交換までその湖でやってしまう、つまりディスカッションのデータベースとなる訳です。こうなると情報は流れるものではなく溜まっているものを使うという新しい段階に入ります。

このように考えてくると、ノーツのデータベースの設計とは実はこのように情報の流れや蓄積を設計することがその大きな一面ではないかと思えます。流れと蓄積を設計するにはノーツはうまい仕組みを用意しています。流れから公の蓄積場所を作れるメール受信データベース、蓄積したものを知らせるために便利な文書リンク、蓄積したものでも一部セキュリティーをかけるための読者フィールド、メールで流れているときと蓄積したときにその形式を簡単に変えられるフォームと文書の分離。どれもうまく組み合わせることで実におもしろそうな情報の川と湖を作れそうです。

紙で実現されていた情報の流れは、紙という性格上、コピーや送付やファイリングに実に手間がかかっていました。またその手間ゆえの回覧という逃げや、コピーなしのファイルリングという手間の省きがたくさんありました。ノーツという情報のコピー、送付、ファイリングがいとも簡単にできる仕組みは、それらの手間ゆえに決められていた情報の流れを大きく変える可能性を持っていると言えるでしょう。今まで流れだけしかなかった情報が湖に溜まる。溜まった情報もまた必要なところに流れていく。湖には人が集って新しい会話が始まる。つまりノーツのアプリケーションの設計とは実は情報の流れと蓄積を、再構築することそのものであるような気がしています。今までの紙の制約を取り払って原点から情報の流通を考え直す。これがノーツアプリケーションの設計者に課せられた大きな課題であると思えてきます。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=339114
ArticleTitle=SE関のノーツ/ドミノ徒然草: 第26回 情報の流れと蓄積の設計者
publish-date=12112006