FIT2010（第 9 回情報科学技術フォーラム）RO-005
情報共有を円滑にするための明示的な返信を不要とするコミュニケーションツール
A Communication Tool With No Need To Explicitly Reply For Smooth Information Sharing
矢田 久美子†Kumiko YADA†

白石 善明†
Yoshiaki SHIRAISHI†

１． まえがき
組織内の複数人が協調して作業を行う場合，通常，各メンバ間での情報のやり取りが頻繁に発生する．そのための手段としては，メールやメッセンジャーなどのツールを利用するのが一般的である．メールは，メッセージとしての文字情報やアプリケーションデータ／画像ファイルの伝達など，リアルタイム性は比較的低いが，記録性が要求されるような情報の伝達に適している．一方，メッセンジャー
は，会話をしているかのような即時性が要求されるメッセージを文字情報として伝達するのに適している．これらの特徴を利用者は暗黙のうちに理解して，情報の発信は記録性の高いフォーマルな手段（メール等）を使い，情報の入手は会話のような即時性の高いインフォーマルな手段（メッセンジャー等）を使う，といったように目的ごとにツールを上手く使い分けているのが現状である．
しかしながら，これらのツールは，いずれも受信者が暗黙的に返信を要求されているような感覚に囚われてストレスを感じていることが多く，社会的関係が対等でない送受信者の間では特にそれが顕著になる．たとえば，業務としての協調作業では，上司（送信者）が部下（受信者）にメッセージを送信し，部下がそれを読んだか否かの情報だけをすぐに知りたい，という場合であっても，部下は上司に丁寧なメッセージを送らなければ自身の評価が下がるかもしれないという心理的な側面から返信が遅れたり，内容を熟考する煩わしさから返信を先送りにしていることがある．
このように，すべての情報のやりとりが，熟考された内容を伴う返信を要求しているわけではなく，送信者が受領確認の応答だけを期待しているにも関わらず，先述のストレスによって円滑なコミュニケーションが阻害されているケースが少なくない．このような，コミュニケーションツールの利用に伴うストレスの弊害を取り除くためには，送信者が受領応答だけを必要とする場合は，１）受信者は，自ら返信する必要がないということを明示的に知らされることによって返信に対するストレスと，操作に伴う時間的な拘束から解放される，２）送信者は，受信者がメッセージを読んだという事実をシステムの自動応答によって知ることができる，という２つの要件を満たすシステムが必要となる．このことは，非同期分散環境[1]での明示的な返信を不要とするコミュニケーションにおいて，送受信者双方の負担をシステムが肩代わりすることによって円滑なコミュニケーションが促進されることを意味する．
例えば，同期対面環境のインフォーマルな会話の中で，単数あるいは複数の相手に渡したい電子化された資料の話題がでてきたとき，その場で手渡す場合は，確実に受け取ったことを双方が瞬時に確認できるため，先述の返信に対する無用なストレスが発生することはないが，資料が手元になく，自席に戻って PC から資料を送信する場合は，受† 名古屋工業大学‡ 岐阜大学

Nagoya Institute of Technology

Gifu University毛利 公美‡
Masami MOHRI‡

信者の多くは，丁寧な内容を添えた受領の返信をすることになる．このように同期対面から非同期分散に環境が移行しただけで，暗黙的に返信を要求されるような感覚を持つことになる．
オフィスで発生するコミュニケーションのうち 52%が相手を見かけたときに発生しているという推定結果[2]もあり，また，情報の入手はインフォーマルな会話によることが多いという報告[3]もある．つまり，情報の入手の機会は同期対面の環境下で発生するが，その具体的な情報を伝達するための環境は非同期分散環境に変化している場合が多く，情報の損失が生じないようにその伝達にストレスを感じさせないように考慮すべきである．
本稿では，受領確認をするだけでよいメッセージには自動的にそれに相当する情報を送信することで，送受信者間の円滑なコミュニケーションを支援するシステム Lubri を提案する．

２．非同期分散環境におけるストレスフリーなコミュニケーション
2.1 メッセージに対する返信の要否
組織内でメールやメッセンジャーで送信されるメッセー
ジには，スケジュールの確認や有用な資料の配布など，目的を持っていることが一般的である．このような目的を持ったメッセージの受信者は，そのメッセージに書かれている話題一つずつに対して返信を求められているように感じる．
受信者が返信する内容は大きく分けて次の 2 つである．
一つは，受信者が持っている何らかの情報を送信者に伝えるための返信，もう一つは，メッセージを受け取った確認，または情報の提供に対するお礼を述べるなどの受信者自身が新たに追加の情報を送るわけではない返信である．前者の返信は，受信者自身がメッセージを考え，返信しなければならないが，後者は必ずしも内容を熟考して返信しなければならないわけではない．返信をした方が送信者に安心感を与え，よりモラルのある行動として捉えられる程度である．このことは，受信者からの返信がなくとも，送信者はモラルのない行動だと感じることがなく，メッセージを読んだかどうかさえ確認できるならば，受信者は返信をする必要がなくなることを意味している．

2.2 明示的な返信が不要なメッセージ送受信メッセージが読まれたかどうかを送信者が確認できれば，非同期分散環境において返信がなくても安心感を得られる．
これには，受信メッセージに対して行った操作を取得して，未読／既読の判断をシステム側で自動化する必要がある．
メッセージをどの程度の期間表示していたのか，特にそのメッセージにフォーカスがあたっていた期間を取得する．
メッセージを受信してから操作があるたびにそれを取得し，未読／既読の判断と後から送信者が何らかの形でみられるように加工ができるように保存する．この保存した受信者

147（第4分冊）

FIT2010（第 9 回情報科学技術フォーラム）DB

Lubri ServerServer
Lubri

Lubri

Lubri

DBDBDB・・・

Lubri

DBClient
図 1 Lubri 全体構成の操作を“アクションログ”と呼ぶ．アクションログを用いて表示期間が一定の閾値を超えたときに受信者が読んだとシステムが判断し，受信者の明示的な返信に代わってシステムがそれを伝えることで送信者に安心感を与え，受信者はストレスから解放される．

３．提案システム：Lubri
2.2 で述べた既読確認の他にも，メッセージは送信してから短い時間内に読まれることが望ましい．メッセージの閲覧を促すために，メッセージへと受信者の意識を向かわせることを考える．読むことに意識を向かわせるためには，メッセージが自動的に画面上に出る，メッセージ画面の色を変更するといった手段が挙げられる．それをメッセージ送信の際に，送信者が設定することで，受信者に閲覧を促し，かつ重要度の高いものや頻繁に見るべきものに対して注目度が高くなるように設定できることも必要となる．
他にも，知っておくと良いがフォーマルな文章にするまでもないような知識などをメッセージとして送信する状況を想定すると，メールやメッセンジャーと同様に，過去のメッセージの閲覧，検索の機能も必要となる．過去に得たメッセージの記録のことを“メッセージログ”と呼ぶ．メ
ッセージログを知識とみなし，蓄積していくことも重要であり，またどのメッセージが頻繁に読まれているのか，つまりどのメッセージが有用であったのかの事後確認を行えるように，すべてのメッセージに対するアクションログも保存する．蓄積したメッセージログとアクションログから，有用であるメッセージを確認できれば組織内でのより高度な知識の共有が行える．
Lubri は以上のような（1）返信を強要しない，（2）送信者がメッセージの閲覧を促せる，（3）メッセージを知識として蓄積できること，さらに（4）簡便な操作で扱えることをコンセプトとしたシステムである．（1）と（4）に よ って 円滑 なコ ミュ ニ ケー シ ョン を生 み出 し， ま た（2）と（3）によって送受信されるメッセージが活用されなくなることを防ぐ．
複数人からなる組織での協同では，一対一，または一対多のメッセージ送信をすることが想定される．Lubri はそのような状況に適するように設計を行った．

3.1 全体構成
Lubri の全体構成を図 1 に示す．Lubri は ServerDB とLubriServer からなるサーバ部，LubriClient と ClientDB からなる Client 部によって構成されている．

[ServerDB]
Lubri 内のメンバおよびグループのプロフィールと，すべてのメッセージログとアクションログが格納される．
Lubri に よ っ て メ ッ セ ー ジ の 送 受 信 を 行 う た め に は ，ServerDB にメンバとして登録されている必要がある．このメンバ登録の権限は，すべてのユーザに対してあるわけではない．管理者に相当する人のみ登録が許されるクローズドなメンバ・グループである．
メッセージログ用のテーブルを表 1 に，アクションログ用のテーブルを表 2 に示す．メッセージログ用のテーブルには，受信者名とアクションログは含まれていない．メッ
セージに対して受信者は複数存在する場合があり，その一人ひとりの受信者に対してアクションログが存在するためである．アクションログ用のテーブルには，一つのメッセージ，一人の受信者に対して一連のアクションログが格納されている．
表 1 メッセージログ格納テーブル(ServerDB)
カラム名
説明
DATE
日時 (YYMMDDHHMMSS 形式)
SENDER
送信者名
MESSAGE
文字メッセージ
FILE
添付されたファイルの格納場所(ファイル名の頭に DATE を追加し保存)
表 2 アクションログ格納テーブル(ServerDB)
カラム名
説明
DATE
日時 (YYMMDDHHMMSS 形式)
RECEIVER
受信者名
ACTION
アクションログ(YYMMDDHHMMSS-○の形．○にはアクションの種類の記号が入る)
ServerDB は，膨大な量になるアクションログの記録が主な用途であるが，メッセージログのバックアップも目的としている．LubriClient からの操作によって DB 内のいかなる情報も削除・編集されることはない．
[LubriServer]
メ ッ セ ー ジ と 各 ロ グ の 送 受 信 ， ま た ServerDB とLubriClient との仲介を担う．LubriServer に対して何らかの送受信が行われたときは，ServerDB のユーザ・グループテーブルを参照しに行き，そのメンバでないユーザからの送受信は拒否をするアクセス制御の機能も持っている．
送信するメッセージとアクションログを区別するために，データの種類を表す記号を先頭につけることで，各データの選別をしている．メッセージでは，文字データとファイルデータを送信することができる．メッセージを送信する際に受信者がオフライン，つまり Lubri を起動していなかった場合は，ServerDB 内に一時保管され，オンラインになると同時に送信される．
[LubriClient]
メッセージの送受信やログの確認のための GUI 制御と，LubriServer と の 通 信 ， ClientDB と の 連 携 を 行 う ．
LubriClient が制御をする GUI であるメッセージ送受信画面を図 2 に，ログ閲覧画面を図 3 に示す．
LubriClient が立ち上がると，まず ServerDB からメンバとグループの取得を行う． メッセージを受信すると，図 4のようなメッセージ画面が PC のディスプレイ上に自動的

148（第4分冊）

FIT2010（第 9 回情報科学技術フォーラム）メッセージログリスト
メンバ・グループのリスト

メッセージログ
メッセージ入力欄

属性設定欄

① ②

①メッセージの閲覧状態

添付ファイル入力欄

既読
閲覧中
未読

②アクションログをグラフで表示

図 3 ログ閲覧画面

図 2 メッセージ送受信画面に表示される．この際，背景色の選択や前面表示にするか否かなどのメッセージに関して設定可能なものを属性と呼ぶ．これらはメッセージ送受信画面（図 2）の属性設定欄で設定できる．また，属性はあらかじめ設定しておくことで，時間とともに変化させることができる．
メッセージに添付されたファイルは，メッセージを受信したときに同時に送信されない．受信者の PC に表示されたメッセージの下部に添付ファイル一覧が表示される．ダウンロードしたいファイルをダブルクリックすることで，LubriServer へとファイルを要求し，ファイルが受信者へと送信される．
[ClientDB]
ClientDB には，LubriClient を使用しているユーザが送受信したメッセージログのみが格納されている．この DB は，各ユーザによってカスタマイズ，つまり編集や削除が可能である．メッセージログのテーブルを表 3 に示す．格納する項目は，ServerDB とほぼ同じであるが，既読・閲覧中・未読のユーザが把握できるように STATUS というカラムを設けている．STATUS には，RECEIVER と同じ順序でその受信者の閲覧状況をそれぞれ 0，1，2 で表し格納する．
表 3 メッセージログ格納テーブル(ClientDB)
カラム名
説明DATE
日時 (YYMMDDHHMMSS 形式)
SENDER
送信者
RECEIVER 受信者(複数人の場合は”，”で区切る)
MESSAGE 文字メッセージ
FILE
添付されたファイルのファイル名
STATUS
受信者の閲覧状況

3.2

図 4 メッセージを受信した際の PC 画面値を越えるまで，メッセージを表示またはフォーカスがあたっていたなら閲覧したと判断する．この閾値は，送信者側で設定が可能である．また，送信してからログ閲覧時までの，閲覧している期間／していない期間をグラフで表示する．これにより，どの期間により頻繁に読まれるメッセージであるかの傾向を知ることができ，その後のメッセージを送る際の参考にできると考えられる．
送信者が受信者の閲覧状況を知り，さらにログ閲覧時までの閲覧している／していない期間のグラフを表示させるまでのユーザとシステムの間の手順を以下に示す．
1.
2.
3.
4.
5.
6.

メッセージの既読・未読の確認

受信者がメッセージを読んだかどうかを判断するためにアクションログを用いる．２．で説明したように，ある閾7.

149（第4分冊）

ユーザがログ閲覧画面からメッセージを選択
LubriClient は ClientDB からそのメッセージに関する情報を取得し，メッセージログ表示欄に表示受信者（または送信者）名の横にある丸いアイコンで閲覧状況を確認
ユーザは丸いアイコンの横にあるグラフアイコンをクリック
LubriClient は LubriServer へ，選択した受信者のメッセージに対するアクションログの取得を要求
LubriDB から得たアクションログを LubriServer はLubriClient へと送信時刻とユーザのアクションを分析することにより，閲覧状態をグラフとして表示

FIT2010（第 9 回情報科学技術フォーラム）表 5 他のシステムとの比較
返信のリアルタ 返信時の堅必要性
イム性
苦しさ
Mail
中低高IM高高
低
Lubri
低高低

図 5 時間によるメッセージの変化

ServerDB のカラム ACTION に格納されるアクションの種類を表 4 に示す．これらの 4 種類のアクションを取得し，その期間の得点を計算することで，閲覧しているか，していないのかを判断している．得点とは，閾値と比較するものであり，送信されたときは 0 点，1 秒につき一回そのときのアクションの種類分の得点だけ加算される．
表 4 アクションの種類とその得点
アクションの種類
記号
得点
フォーカスがあたったF
3
フォーカスが外れたU
1
画面上に表示されたV
2
画面上から消去された
D
0

3.3

メッセージの閲覧を促す属性変化

メッセージの閲覧を促すために，メッセージの属性，つまり前面表示や背景色などを時間によって変更させることでウィンドウに変化をもたせ，受信者の注意を引く．このような変化を送信者側が設定することによって，メッセージの重要度を受信者に暗黙に知らせることができる．図 5に，図 4 のメッセージウィンドウの色が変化した様子を一例として示す．
また，この機能によって，自身にメッセージを送信し，属性変化を時間指定で設定することで，簡易アラーム機能のような使い方もできる．

3.4

実装

Lubri は Server 部と Client 部に分かれた構成になっている．Client 部は Adobe AIR と Flex3.2 によって実装した．
ClientDB には，Adobe AIR に搭載されている SQLite を使用した．Server 部は，Java（JDK は 1.6.0_18）で開発した．
ServerDB には MySQL を，その連携には JDBC5.1.7 を使用した．メッセージの送受信には Socket 通信を用いた．

4．比較
メッセージを送受信する代表的なものとしてメールとインスタントメッセンジャー（IM）をここではあげる．この2 つと本稿で提案する Lubri とを「返信の必要性」，「リアルタイム性」，「返信時の堅苦しさ」の 3 つの観点から比較すると表 3 のようになる．
メールでは，返信の必要性はリアルタイムにメッセージが交換される IM に比べて低く，相対的に中程度と考えられるが，堅苦しさが高い．送受信者の社会的関係が対等でない場合には，さまざまなことを考慮して返信文を作成しなければならないからである．
IM は簡単にメッセージを送信することができるが，リアルタイム性が高く，返信をその都度求められているような心理的な側面や，返信文を考える時間が短いといったIM の特徴からくる側面などからの要因が複合し，返信時にあせり等のストレスが生じてしまうことがある．
それに比べて，明示的な返信を必要としないというコンセプトの Lubri では，返信する際のストレスは生じない．
返信不要としている一方で，受信者がメッセージを閲覧しているかどうかがアクションログによって送信者は知ることができることから，リアルタイム性は高いと言える．送信者も相手の返信を必要としていない，返信を考えなくて良いといったように，気軽に扱うことができるのも Lubriの特徴の一つである．
アクションログによる受信者の閲覧状況を送信者が把握する点は，提示の方法によってはメッセージの受信時にIM と同様のあせり等を抱かせる場合があると予想される．
アクションログを適切に加工し，受信者がストレスを感じない提示方法は今後の検討課題とする．

5．おわりに本稿では，明示的な返信を不要とするメッセージ送受信
システム Lubri を提案した．
非同期分散環境でのメッセージ送受信では，送信者の返信への期待の有無を受信者が想像し，返信をした方がよいのか，返信文はどのようにすべきなのかといった迷いが生じることがある．受信者から新たな情報提供を必要としていない返信に着目し，メッセージ閲覧のアクションログを取得し，送信者がそれを閲覧することで，メッセージを受け取ったかどうか，閲覧したかどうかを確認できるようなシステムとした．Lubri を使用することで返信を前提としない簡便なメッセージ送受信を行うことができ，メールやメッセンジャーとは異なった用途でコミュニケーションを支援し，情報共有を円滑化すると考えられる．
アクションログの適切な提示方法の検討，セキュリティを考慮したシステムの拡張，および運用実験による評価が今後の課題として挙げられる．
参考文献[1] 岡田，“情報共有空間における協同”，情報処理，
Vol.48，No.2，pp.123-127 (2007)．
[2] Kraut, R., et al., ``Informal communication inorganizations: Form, function, and technology, People’s
Reactions to Technology’’, Oskamp, S. and Spacapan, S. (Eds),
pp.145-199, Sage Publications, London (1999).
[3] Isaacs, E., et al. ``Piazza: A Desktop Environment
Supporting Impromptu and Planned Interactions’’, Proc. ACM
CSCW’96, pp.315-324 (1996).

150（第4分冊）