リモートワークとグループウェア研究 2/2

（「リモートワークとグループウェア研究 1/2」からのつづき）

3. マルチメディア会議システム

しかし研究者たちは盛りあがっていた。その後、ビデオ会議システムの発展形として、マルチメディア会議システムが開発されるようになり、AT&TのRapport (1988)やNECのMERMAID (1989)、NTTのPMTC (1990)や図3のTeamWorkStation (1990)などが発表された。そこではシームレスな協同作業空間を構築することが目標とされ、たとえばTeamWorkStationでは、画像情報(たとえばシステム構成図)に対して、一方が図形を描いていると、他方ではそれを赤字で修正する、というようなことを実現させている。

もちろん、このシステムのデモは確かに面白い。面白いけれど、どれほど必要性のあるものなのだろう。業務場面における重要性や必要性についての調査や分析が不十分なまま、技術開発だけが突出してしまっていた、といえないだろうか。

4. シームレスな協同描画システム

TeamWorkStationを開発した石井らは、さらにシームレスな協同描画メディアとしてのClearBoard (1992)の開発に進んだ。これは「大きなガラス板をはさんで互いの顔を見ながら会話をし，ガラス板の両側から描画を行う」という遠隔通信のシステムである。ガラス板の向こう側には遠隔地にいる相手の画像が透けて見え、相手はガラスの向こう側に、こちらはガラスのこちら側に画像を描いていく、という仕組みである。相手の描く図形は反転されてこちらの描いたものとオーバーレイしてガラス面に表示される。

これも面白い発想である。しかし、改めて振り返ってみると、果たしてこういうシステムが必要となる場面がどれだけあるのか、しかもガラス板越しに相手が見えてしまう状況で、ガラス板に描かれた図形の視認性が高いものになるのかも心配である。結果的に、このシステムは学会(ACM SIGCHI)において世界的な発明として話題になったものの、残念ながら、実用化には至らなかった。

5. 文書協同レビュー支援システム

画像情報でなく、テキスト情報をベースにしたグループウェアも登場した。Access TechnologyのForComment (1987)や、BellcoreのQuilt (1988)などの文書協同レビュー支援システムである。

ハイパーメディア機能などを導入したシステムは機能的には優れた点もあったが、現在、我々はWordやAcrobatの編集履歴機能を使って、レビューが終わった書類を送りあいながら相互レビューをしており、それで十分に満足してはいないかもしれないが、大きな不満は感じていない。もちろん、委員会としてひとつの文書をまとめるISOなどの規格編成の場合のように、参加者が5,6人以上になると履歴管理が面倒にはなるが、たいていの場合、担当と上司やとりまとめ者との間でレビューのやりとりが行われるので、それほどの問題にはなっていない。

6. グループワーク調整システム

グループワークを有効に進捗させるために、WinogradのSpeech Act Theory (1986)をベースにして、メールのそれぞれに、要求、提案、逆提案、約束、拒否、取り消しなどというタグをつけて位置づけを明確にし、コミュニケーションを完了宣言に集約させるようなシステムとしてAction TechnologyのCoordinatorが開発された。

しかし、このシステムでは、何気ない発言とか、特に反応せずにいる賛同といったいささか曖昧な参加形態を許容しておらず、いいかえればシステムの枠組みが強すぎるという理由から、幾つか実際の場面に適用が試みられたものの、結局普及せずに終わってしまった。

同様に、ハイパーメディアを利用して、任意の問題に対する賛否やコメントをリンクしていくMCCのgIBIS (1988)も、システムの制約の厳しさから普及することなく終わった。

グループウェアやCSCWシステムの開発から学ぶこと

厳しすぎるかもしれないが、筆者としては、グループウェアやCSCWシステムで成功したものはない、と考えている。実のところ凝ったシステムは必要なく、まず、ネット環境があり、メールとファイル転送と文書作成や表計算のソフトとがあり、機器環境として、パソコン、プロジェクタ、それにマイクとスピーカ、カメラとスクリーン(それらは基本的にノートパソコンには常備されている)があればいいのだ。なによりも約束事が少なく、自由にそれらのツールを使いこなせることがリモートワークにおいては必要なことなのだ。それは、リモートワークの業務内容の多様性とも関係するが、それ以上にユーザに自由を与えること、いいかえればユーザを信頼することの重要性を示している。

グループウェアやCSCW研究の失敗の大きな原因は、システム設計者がCW (協同作業)を分析して、そこから要件を抽出してCS (システム構築)に至るのだ、という気構えで取り組んできたにもかかわらず、その調査分析において思い込みが強すぎたり、そもそもの協同作業の分析がある特定の業務に偏っていたり、あるいは共同作業におけるロジカルな構造に気を取られすぎたりしたからである。そして、アカデミアの人間の陥りやすい罠として、「研究として注目されること」にこだわってしまったからでもある。

リモートワークを成功させるために

リモートワークを成功させるためには、グループウェアやCSCWシステムの機能ではなく、まず業務そのものの分析と理解が重要である。CSCWではCWとして、その部分を目指していたが、工学系の視点ではなく、社会科学的ないし経営学的な視点から問題に取り組む必要があった。たとえば、大きな仕事をそのまま担当に渡すのではなく、適切に構造化して細分化し、それぞれを適当な担当者(達)にまかせ、適切なタイミングでチェックを行うというような、従来の業務管理に関する知見を活用すること(PERTなどの在来ツールは使うにしても)が重要である。

もちろん、遠隔地に分散しているスタッフによる業務は、同じオフィスにおける業務の遂行とは異なる面がある。その異なる側面を、メールや音声、動画像といった古典的メディアによって水平に、かつ垂直に柔軟に管理してゆくノウハウを、業務内容ごとに蓄積してゆくことが必要だといえるだろう。

残念ながら、そうしたノウハウはまだ十分に蓄積されておらず、現在使われているICT機器の組み合わせが最適なものだとは言えないかもしれない。そして、仕事の種類によっては新たな技術開発が必要になるかもしれない。ただし、「まずシステムを作りましょう」という工学的な取り組みに入ってしまう前に、「どのような点が問題か」、「それを解決するにはどのようなやり方をすべきか」という社会科学的な取り組みをすることが必要だろう。

COVID-19 (新型コロナウイルス感染症)は、われわれの業務遂行について考え直す機会を与えてくれた。これを一時的な不便益ととらえるのではなく、感染が収束した後も活用できるように、業務システムの在り方そのものを考え直していこうではないか。少なくとも、満員電車に長時間詰め込まれている状況から解放されることは良いことではないか。リモートワークには当然短所もあるだろうが、業務全体をトータルとして考えた時、対面とリモートをどのように組み合わせた業務形態を目指すべきかを考える良い機会が与えられたと考えていきたい。