SE関のノーツ/ドミノ徒然草

第26回 情報の流れと蓄積の設計者

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: SE関のノーツ/ドミノ徒然草

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:SE関のノーツ/ドミノ徒然草

このシリーズの続きに乞うご期待。

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

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

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

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

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

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

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

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

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

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


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

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