対象になる人物が装着したセンサ端末から、その人物と他の人物との対面に関するデータを取得し、コミュニケーションの多様性と量を二軸に取ってプロットすることで、個人と組織の様子を表現する表示システムを実現した。
最初に、本発明の第1の実施の形態について図面を参照して説明する。
<全体の処理の流れの概要>
第1の実施の形態では、無線送受信器を有するセンサ端末(TR)を組織の各メンバが装着し、その端末(TR)によって各メンバ間の交流(インタラクション)に関するデータを取得する。取得したデータは無線によって基地局(GW)に送信され、さらにセンサネットサーバ(SS)に格納される。組織コミュニケーションに関する表示を作成する際には、クライアント(CL)からアプリケーションサーバ(AS)に依頼を出し、組織に属するメンバに関するデータをセンサネットサーバ(SS)から取り出す。それをアプリケーションサーバ(AS)において、各メンバのコミュニケーションの量と多様性の基づいて処理・プロットし画像を作成する。さらにその画像をクライアント(CL)に戻し表示する。この一連の組織コミュニケーション可視化システムを実現した。
具体的には、複数の端末と、その複数の端末から送信されたデータを処理する処理装置とを具備して成る組織コミュニケーション可視化システムであって、各端末は、他の端末との対面状態を検出するセンサと、そのセンサが検出したデータを送信するデータ送信部とを備え、処理装置は、第1の端末から送信されたデータに基づいて、第1の端末を装着した第1の人物の、当該組織の他者と持つ関係の強さを示す特徴量と関係の多様性を示す特徴量とを視覚的に関係付けて表示する関係付け表示を行うことにより、当該組織のコミュニケーションスタイルを可視化することを特徴とする組織コミュニケーション可視化システムである。
<表示内容の説明とその効果>
第1の実施の形態は、図1のディスプレイ(CLWD)の内部、また図14で例を示した組織コミュニケーションを示す図を描画するためのものである。この図は、例えば一日を単位として、各メンバが一日で対面した相手の人数を横軸、誰かと対面していた時間の合計数を縦軸に取り、プロットしたものである。ここで、対面時間の合計数とは、各メンバのコミュニケーションの量と捉えることができる。また、知識労働組織においては、多様な知識やバックグラウンドを持つ他者とコミュニケーションを行うことで新しいアイディアや価値が創発する可能性が高くなると考えられる。よって、横軸の対面人数とは、各メンバの行っているコミュニケーションの多様性を1つの視点から示したものであると捉えられる。この2つを軸とし、組織に属する全部もしくは一部のメンバの位置をプロットする。これによって、組織全体としてはコミュニケーションがどのように分布して行われているかを知ることができる。例えば、コミュニケーションについて一部の人のみに集中しているのか、全員がアクティブに関わりあっているのか、などである。さらに時系列に切り分けて表現すると、組織全体のアクティブさや偏り方を各時期の業務内容との照らし合わせることによって、業務のフェーズとコミュニケーションの行われ方がマッチしているかどうかを判断する材料としても用いることができる。また、プロジェクトなどの組織内の下位組織については、コミュニケーションの行われ方によってメンバ構成・業務内容に合わせたリーダーの組織運営の形態が可視化される。個人について焦点を合わせると、活発にコミュニケーションしているメンバは誰か、もしくはどのようなタイプのメンバか、コミュニケーションよりも個人作業を優先しているのはどのようなメンバかを知ることができる。また業務以外でも多くの他者とコミュニケーションを取っているメンバは知識創発のためのきっかけをもたらす可能性があるが、そのようなメンバは誰かを知ることができる。なお、縦軸と横軸を入れ替えて、縦軸を対面人数、横軸を対面時間としてプロットしても良い。
この場合、上記の関係付け表示は、強さを示す特徴量を一方の軸に割り当て、多様性を示す特徴量を他方の軸に割り当てた二軸構成の座標平面上に人物に対応する記号をプロットして行う表示である。
以上で述べた効果は、実際に横断プロジェクトの編成など知識労働の活性化のための試みを積極的に行っている組織において取得した実験データによって検証されたものである。結果の詳細は後述する。
<全体システム>
図1は、本発明の第1の実施の形態における、インタラクションデータを取得する端末から、取得したデータを表示するアプリケーションまでを含むシステム全体の構成の説明図である。
ユーザ(US)は、クライアント(CL)を操作することによって、組織コミュニケーションに関する表示を受信する。クライアント(CL)は、ネットワーク(NW)を経由してアプリケーションサーバ(AS)に接続し、アプリケーションサーバで作成されたデータ処理結果情報(組織コミュニケーション表示)を受信し、ディスプレイ(CLWD)などに出力する。
アプリケーションサーバ(AS)はネットワーク(NW)を経由してセンサネットサーバ(SS)に接続し、データベース部(SSDB)に格納されているセンシングデータを受信する。受信した情報を処理・プロットすることによって、画像を作成する。
センサネットサーバ(SS)は、ネットワーク(NW)を経由して基地局(GW)に接続し、センシングデータを受信する。基地局(GW)は、ネットワーク(NW)を経由してセンサネットサーバ(SS)にセンシングデータを送信する。
基地局(GW)は、送信・受信部(GWSR)を経由して端末(TR)からセンシングデータを受信する。
端末(TR)は、人物に装着され、センシング部(TRSE)によってセンシングデータを取得する。基地局(GW)が通信可能なエリア内に、端末2(TR2)から端末4(TR4)が存在する。端末2(TR2)から端末4(TR4)のそれぞれは、各人物に装着され、端末(TR)と同様、センシング部(図示省略)によってセンシングデータを取得する。端末(TR)及び端末2(TR2)から端末4(TR4)は、取得したセンシングデータを、送信・受信部(TRSR)を用いて基地局(GW)に送信する。端末(TR)及び端末2(TR2)から端末4(TR4)によって送信されたセンシングデータには、そのデータを取得した端末(TR)及び端末2(TR2)から端末4(TR4)を識別する情報が含まれる。
<端末>
端末(TR)は小型端末であり、センシングの対象となる人物によって装着される。以下、端末(TR)の構成を説明する。図1には、さらに、端末2(TR2)から端末4(TR4)までの3個の端末が図示されている。これらの端末に関する説明は端末(TR)と同様であるため以降省略する。よって以下の説明は、端末(TR)を端末2(TR2)から端末4(TR4)までの任意のものに置き換えても成立する。なお、同様の端末が任意の数存在する場合にも、本発明を適用することができる。
端末(TR)には赤外線送信器(TRIS)と赤外線受信器(TRIR)が搭載されている。これらを用い、端末(TR)間で赤外線をやり取りすることによって、その端末(TR)が他の端末(TR)と対面したか否かが検出される。このため、端末(TR)は、人物の正面部に装着されることが望ましい。例えば、端末(TR)を名札型にし、紐によって人物の首からぶら下げてもよい。端末(TR)が人物の正面部に装着された場合、端末(TR)が他の端末(TR)と対面したことは、それらの端末(TR)を装着した人物が対面したことを意味する。
なお、以下、端末(TR)が赤外線信号をやり取りすることによって、その端末(TR)が他の端末(TR)と対面したか否かを判別する例を記載する。しかし実際には、赤外線信号以外の無線信号をやり取りすることによって対面の有無が判別されてもよい。
また端末(TR)は、送信・受信部(TRSR)、センシング部(TRSE)、入出力部(TRIO)、制御部(TRCO)、記録部(TRME)によって構成されており、センシング部(TRSE)にてセンシングされたデータを送信・受信部(TRSR)を介して基地局(GW)に送信する。
送信・受信部(TRSR)は、基地局(GW)との間でデータを送信及び受信する。例えば、送信・受信部(TRSR)は、基地局(GW)から送られてきた制御コマンドに応じてセンシングデータ送信してもよいし、定期的にセンシングデータを送信してもよいし、センシングデータを取得した時に直ちにそのセンシングデータを送信してもよい。さらに、送信・受信部(TRSR)は、基地局(GW)から送られる制御コマンドを受信してもよい。受信した制御コマンドに従って、端末(TR)に関する制御情報の変更、又は、入出力部(TRIO)内の出力デバイスへの出力が実行される。また、送信・受信部(TRSR)は、入出力部(TRIO)内の入力デバイスによって選択された事項を、制御コマンドとして基地局(GW)へ送信する。
センシング部(TRSE)は、端末(TR)の状態を示す物理量をセンシングする。具体的には、センシング部(TRSE)は、種々の物理量をセンシングする一つ以上のセンサを備える。例えば、センシング部(TRSE)は、センシングに用いるセンサとして、赤外線送信器(TRIS)、赤外線受信器(TRIR)、温度センサ(TRTE)、マイクロホン(TRMI)、加速度センサ(TRAC)及び照度センサ(TRIL)を備える。
赤外線受信器(TRIR)は、他の端末(TR)の赤外線送信器(TRIS)から送信された赤外線信号をセンシングする。後述するように、センシングされた赤外線の情報は
、端末(TR)が他の端末(TR)と対面したか否かを判定するために使用される。
加速度センサ(TRAC)は、X、Y及びZ軸方向の加速度をセンシングする。後述するように、センシングされた加速度の情報は、端末(TR)を装着した人物の動作の激しさや行動(例えば、歩行又は静止等)を判断するために使用される。
マイクロホン(TRMI)は、音声をセンシングする。センシングされた音声の情報は、例えば、端末(TR)を装着した人物が会話しているか否かを判別するために使用されてもよい。
温度センサ(TRTE)及び照度センサ(TRIL)は、それぞれ、温度及び照度をセンシングする。センシングされた温度及び照度の情報は、例えば、端末(TR)が置かれている環境を判断するために使用されてもよい。
センシング部(TRSE)は、上記のセンサの任意の一つ以上を備えてもよいし、他の種類のセンサを備えてもよい。さらに、センシング部(TRSE)は、外部入力(TROU)を用いることによって、新たにセンサを追加することもできる。
なお、既に説明したように、端末(TR)は、赤外線信号以外の無線信号をやり取りすることによって対面の有無を判別してもよい。その場合、センシング部(TRSE)は、赤外線センサ(TRIR)以外の無線信号受信機を備えてもよい。あるいは、外部入力(TROU)に赤外線センサ(TRIR)以外の無線信号受信機が接続されてもよい。
入出力部(TRIO)は、ボタン等の入力デバイスと、液晶ディスプレイ等の出力デバイスとを備え、対象となる人物が所望する情報の取得及びセンシングデータの表示を行う。入出力部(TRIO)として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。
制御部(TRCO)は、CPU(図示省略)を備える。CPUが記録部(TRME)に格納されているプログラムを実行することによって、センサ情報の取得タイミング、センサ情報の解析、及び、基地局(GW)への送受信のタイミングが制御される。
記録部(TRME)は、ハードディスク、メモリ又はSDカード等の外部記録装置を備え、プログラム及びセンシングデータを格納する。さらに、記録部(TRME)は、データ形式(TRDFI)及び内部情報部(TRIN)を含む。
データ形式(TRDFI)は、各センサから取得したデータ及び時刻情報を送信する際に、それらのデータをまとめる形式を指定する。
内部情報部(TRIN)は、端末(TR)に関する情報を格納する。端末(TR)に関する情報は、例えば、バッテリ残量(TRBA)、時計(TRTI)(すなわち時刻情報)及び端末情報(TRTR)である。
バッテリ残量(TRBA)には、端末(TR)の電源の残量が記録される。時計(TRTI)には、端末(TR)が内蔵するタイマで計測された現在の時刻が格納される。現在の時刻は、定期的に基地局(GW)から送信されたものに基づいて修正される。端末情報(TRTR)は、端末(TR)を識別するために使用される端末固有の情報であり、固有IDとも呼ばれる。
基地局(GW)の時刻を端末(TR)の時刻として定期的に修正することによって、複数の端末(TR)間で時刻が同期される。これによって、異なる端末から得られたデータを時刻に基づいて整列させ、照らし合わせることが可能になる。コミュニケーションは必ず複数のメンバによって行われるため、双方の視点からデータを分析するためには時刻を同期させることは必須となる。なお、時刻修正は基地局(GW)をトリガとするのではなく、センサネットサーバ(SS)がトリガとなって基地局(GW)を介して端末(TR)に時刻を送信してもよい。
<基地局>
基地局(GW)は、情報を取得したいエリアに設置され、そのエリア内にある端末(TR)から無線によって送信されてくるセンシングデータを受信し、受信したセンシングデータをネットワーク(NW)を介してセンサネットサーバ(SS)へ送信する。基地局(GW)は、送信・受信部(GWSR)、制御部(GWCO)、入出力部(GWIO)、記録部(GWME)及び内部情報部(GWIN)を備える。
図1には、さらに、基地局2(GW2)から基地局3(GW3)までの2個の基地局が図示されている。これらの基地局に関する説明は基地局(GW)と同様であるため以降省略する。よって以下の説明は、基地局(GW)を基地局2(GW2)から基地局4(GW4)までの任意のものに置き換えても成立する。なお、同様の基地局が任意の数存在する場合にも、本発明を適用することができる。いずれの基地局も、無線の到達可能圏内に存在する0から複数個の端末(TR)とコネクションを確立し、データのやり取りを行う。
送信・受信部(GWSR)は、端末(TR)との間でデータを送信及び受信する。例えば、送信・受信部(GWSR)は、端末(TR)に対して制御コマンドを送信してもよいし、定期的にセンシングデータを端末(TR)から受信してもよいし、端末(TR)がセンシングデータを受信したら直ちに端末(TR)からそのセンシングデータを受信してもよい。さらに、送信・受信部(GWSR)は、端末(TR)から送られてきた制御コマンドに従って、センサネットサーバ(SS)へ要求を送信し、その要求に応じてセンサネットサーバ(SS)から取得したデータを端末(TR)へ送信してもよい。また、送信・受信部(GWSR)は、入出力部(GWIO)における入力デバイスによって選択された事項を、制御コマンドとして端末(TR)やセンサネットサーバ(SS)に送信してもよい。逆に、送信・受信部(GWSR)は、センサネットサーバ(SS)又は端末(TR)から送られてきた制御コマンドを受信してもよい。受信した制御コマンドに従って出力デバイスの表示が変更される。
制御部(GWCO)は、CPU(図示省略)を備える。CPUが記録部(GWME)に格納されているプログラムを実行することによって、センサ情報の取得タイミング、センサ情報の解析、及び、端末(TR)又はセンサネットサーバ(SS)への送受信のタイミングが制御される。
入出力部(GWIO)は、ボタン又はキーボード等の入力デバイスと、液晶ディスプレイ等の出力デバイスとを備え、対象となるエリア内の状況等の情報及びセンシングデータを表示する。入出力部(GWIO)として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。
記録部(GWME)は、ハードディスク、メモリ又はSDカード等の外部記録装置を備え、プログラム及びセンシングデータを格納する。さらに、記録部(GWME)は、データ形式(GWDFI)及び内部情報部(GWIN)を含む。
データ形式(GWDFI)は、端末(TR)から受信したデータ及び時刻情報の形式であり、この形式に基づいてデータが各要素に判別される。
内部情報部(GWIN)は、基地局(GW)に関する情報を格納する。基地局(GW)に関する情報は、例えば、時計(GWTI)(すなわち時刻情報)、及び、基地局固有の情報である基地局情報(GWBA)である。
<ネットワーク>
ネットワーク(NW)は、基地局(GW)、センサネットサーバ(SS)、アプリケーションサーバ(AS)及びクライアント(CL)を接続するネットワークである。ネットワーク(NW)は、Local Area Network(LAN)、Wide Area Network(WAN)又はその他の任意のネットワークであってよい。
<センサネットサーバ>
センサネットサーバ(SS)は、基地局(GW)から送られてくるセンシングデータを格納し、また、アプリケーションサーバ(AS)からの要求に基づいてセンシングデータを送信する。また、センサネットサーバ(SS)は、基地局(GW)からの制御コマンドを受信し、その制御コマンドによって得られた結果を基地局(GW)に送信する。
センサネットサーバ(SS)は、データベース部(SSDB)、制御部(SSCO)、送信・受信部(SSSR)、入出力部(SSIO)、記録部(SSME)を備える。
データベース部(SSDB)は、端末(TR)から基地局(GW)を介して送られてきたセンシングデータを格納する。さらに、データベース部(SSDB)は、基地局(GW
)からの制御コマンドに対する対処方法を格納する。データベース部(SSDB)は、後述する記録部(SSME)が備えるハードディスク(図示省略)等に格納されてもよい。
制御部(SSCO)は、CPU(図示省略)を備える。CPUが記録部(SSME)に格納されているプログラムを実行することによって、データベース部(SSDB)の管理、及び、アプリケーションサーバ(AS)及び基地局(GW)から送信される情報の処理を行う。
送信・受信部(SSSR)は、基地局(GW)及びアプリケーションサーバ(AS)へのデータの送信、及び、それらからのデータの受信を行う。具体的には、送信・受信部(SSSR)は、基地局(TR)から送られてきたセンシングデータを受信し、アプリケーションサーバ(AS)へセンシングデータを送信する。また、送信・受信部(SSSR)は、基地局(GW)から制御コマンドを受信した場合、データベース部(SSDB)から選択した結果を基地局(GW)に送信する。
入出力部(SSIO)は、ボタン又はキーボード等の入力デバイスと、液晶ディスプレイ等の出力デバイスとを備え、対象となるエリア内の状況等の情報及びセンシングデータを表示する。入出力部(SSIO)として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。
記録部(SSME)は、ハードディスク、メモリ又はSDカード等の外部記録装置を備え、プログラム及びセンシングデータを格納する。さらに、記録部(SSME)は、データ形式(SSDFI)を含む。
データ形式(SSDFI)は、基地局(GW)から受信したデータ及び時刻情報の形式であり、この形式に基づいてデータが各要素に判別され、データベース部(SSDB)の適切な要素に振り分けられる。
<アプリケーションサーバ>
アプリケーションサーバ(AS)は、センサネットサーバ(SS)に格納されているセンシングデータの処理を行う計算機である。アプリケーションサーバ(AS)は、データ処理部(ASDP)、制御部(ASCO)、記録部(ASME)、送信・受信部(ASSR)、及び入出力部(ASIO)を備える。なお、アプリケーションサーバ(AS)は、クライアント(CL)が兼ねても、センサネットサーバ(SS)が兼ねてもよい。
データ処理部(ASDP)は、センシングデータを処理し、組織コミュニケーションを表現するための画像を作成する。データ処理部(ASDP)は、対面マトリクス計算(APIM)、対面人数・時間計算(APIC)、データプロット(APIP)を実行する。変形例として他の処理が追加される場合、それらの処理は、データ処理部(ASDP)によって実行される。データ処理部(ASDP)は、処理したデータを記録部(ASME)に一時的に格納する。
データ処理部(ASDP)は、例えば、記録部(ASME)に格納されたプログラムを制御部(ASCO)のCPUが実行することによって実現されてもよい。その場合、対面マトリクス計算(APIM)、対面人数・時間計算(APIC)、データプロット(APIP)などのデータ処理部内の処理は、実際には、制御部(ASCO)のCPUによって実行される。
制御部(ASCO)は、CPU(図示省略)を備える。CPUが記録部(ASME)に格納されているプログラムを実行し、センサネットサーバ(SS)へのデータ取得依頼、データ処理の実行、及び、実行結果の管理等の処理を行う。
記録部(ASME)は、ハードディスク、メモリ又はSDカード等の外部記録装置を備え、プログラム、センシングデータ、及び、データ処理部(ASDP)による処理結果を格納する。さらに、記録部(ASME)は、初期条件設定(ASSII)及び結合テーブル(ASCNT)等、処理のために一時的に保管すべき値を記録する。これらの値は、データの種類及び処理の種類に応じて随時追加・削除・変更することができる。また、ノードを装着しているユーザ(US)とノードの固有IDとの対応を示すユーザID対応表(ASUIT)や、プロジェクトとそれに属するユーザ(メンバ)との対応を示すプロジェクト対応表(ASPUT)を記録しておく。ユーザID対応表(ASUIT)やプロジェクト対応表(ASPUT)はセンサネットサーバ(SS)内の記録部(SSME)やクライアント(CL)内の記録部(CLME)に記録してもよい。また、対面マトリクス(ASTMX)は、対面マトリクス計算(APIM)によって作成される配列である。ユーザID対応表(ASUIT)の例は図5に、プロジェクト対応表(ASPUT)の例は図6に、対面マトリクス(ASTMX)の例は図11にそれぞれ示している。
ユーザID対応表(ASUIT)やプロジェクト対応表(ASPUT)はプログラム内に直接記述しても良いが、対応表のみを分けて保管することで、ユーザの変更、ノードIDの変更、プロジェクトの組織構成の変更などに柔軟に対応することができる。
送信・受信部(ASSR)は、センサネットサーバ(SS)からセンシングデータを受信し、クライアント(CL)からの処理結果要求に基づくデータ送信を行う。
入出力部(ASIO)は、ボタン又はキーボード等の入力デバイスと、液晶ディスプレイ等の出力デバイスとを備え、対象となるエリア内の状況等の情報及びセンシングデータを表示することができる。入出力部(ASIO)として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。
<クライアント>
クライアント(CL)は、ユーザからの依頼に基づいてデータ処理要求をアプリケーションサーバ(AS)に送信し、その処理結果をアプリケーションサーバ(AS)から受信し、受信した処理結果を画面に表示する。クライアント(CL)は、アプリケーション部(CLAP)、送信・受信部(CLSR)、入出力部(CLIO)、記録部(CLME)及び制御部(CLCO)を備える。
制御部(CLCO)は、記録部(CLME)に格納されているプログラムを実行するCPU(図示省略)を備える。制御部(CLCO)は、ユーザからの要求に基づいて、アプリケーションサーバ(AS)から受信した画像の大きさなどを調整し、作成された画面を入出力部(CLIO)のディスプレイ(CLWD)などの出力デバイスに表示することによってユーザに提供する。例えば、記録部(CLME)に格納されたプログラムを制御部(CLCO)のCPUが実行することによって実現されてもよい。
送信・受信部(CLSR)は、ユーザが指定した範囲のセンシングデータの処理結果を送信させる要求をアプリケーションサーバ(AS)に対して送信し、その処理結果(すなわち、アプリケーションサーバ(AS)によって処理された画像またはセンシングデータ)を受信する。
入出力部(CLIO)は、マウス(CLIM)やキーボード(CLIK)などの入力デバイスと、ディスプレイ(CLWD)などの出力デバイスとを備え、対象となるエリア内の状況等の情報及びセンシングデータを表示する。入出力部(CLIO)として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。またそれ以外の入出力装置を接続するために外部入出力(CLOU)が用いられてもよい。
記録部(CLME)は、ハードディスク、メモリ又はSDカード等の外部記録装置を備え、メインプログラム、センシングデータ、及び、アプリケーションサーバから送られてきた画像や制御部(CLCO)による処理結果を格納する。また、記録部(CLME)は、初期条件設定(CLISI)に、画面の大きさなどユーザによって設定された条件を記録する。
<全体シーケンス図>
図2は、本発明の第1の実施の形態において、センシングデータが端末(TR)からユーザ(US)に提供されるまでの処理を示すシーケンス図である。
端末(TR)で取得されたセンシングデータは、定期的に基地局(GW)を介してセンサネットサーバ(SS)に届けられ、データベース(SSDB)に保管される。この流れが、図2のセンシングデータの取得(TRGE)からデータ格納(SSPU)までにあたる。また、時刻修正(GWTM)〜時刻修正(TRTM)は、センシングデータの取得の流れとは別の周期で実行される。
一方、ユーザの要求があった場合には、クライアント(CL)からアプリケーションサーバ(AS)を通してセンサネットサーバ(SS)に依頼を送信し、取得したデータからアプリケーションサーバ(AS)で画像を作成し、クライアント(CL)に戻すという流れを辿る。この流れは、図2のアプリケーション起動(USST)からアプリケーション終了(USEN)までにあたる。
センシングデータの取得(TRGE)については、サンプリング周期、取得時間などセンシングデータを取得するために必要な情報が記録部(TRME)に記載されており、この情報を基にして端末(TR)内のセンシング部(TRSE)がセンシングを行う。また、端末(TR)は一定の周期で端末(TR)自身を識別する情報を載せた赤外線を送信し続ける(TRIS)。端末(TR)が別の端末2(TR2)と対面した場合には、つまり端末(TR)と端末2(TR2)のユーザ同士が対面した場合には、端末(TR)は、端末2が送信した赤外線(TRIS2)を受信する(TRIR)。また対称的に、端末(TR)が送信した赤外線は、端末2(TR2)で受信される(TRIR2)。端末同士の角度など、条件によっては一方しか受信されない場合もありうる。さらに、端末(TR)は、センシングされたデータを記録部(TRME)に記録する。
時刻添付(TRAD)において、端末(TR)は、センシングしたデータの取得時刻として、時計(TRTI)の時刻をセンシングデータと共に記録する。データ形式(TRDF)において、端末(TR)は、記録部(TRME)内のデータ形式(TRDFI)を参照し送信用データ形式にデータを統一する。
データ送信(TRSE)において、端末(TR)は、センシングデータの取得(TRGE)によってセンシングしたセンシングデータを、送信・受信部(TRSR)を経由し基地局(GW)に送信する。より詳細には、端末(TR)は、記録部(TRME)に記録されているセンシングデータを記録部(TRME)に格納されている基地局(TR)用の送信フォーマットを用いて制御部(TRCO)によって変換する。そして、端末(TR)は、送信フォーマットに変換されたセンシングデータを送信・受信部(TRSR)を経由して基地局(GW)に送信する。
データ受信(GWRE)において、基地局(GW)は、端末(TR)から基地局(GW)用の送信フォーマットで送信・受信部(TRSR)から送信されたセンシングデータを送信・受信部(GWSR)によって受信する。受信したセンシングデータは記録部(GWME)に格納される。
データ形式判断(GWDF)において、基地局(GW)は、取得したデータの形式を記録部(GWME)のデータ形式(GWDFI)と比較してデータの形式を判断する。さらに、基地局(GW)は、基地局情報付与(GWAD)において、データ形式(GWDFI)が示す適切な位置に基地局情報(GWBA)を追加する。
データ送信(GWSE)において、基地局(GW)は、記録部(GWME)に格納されたセンシングデータを、送信・受信部(GWSR)を経由してセンサネットサーバ(SS)に送信する。より詳細には、基地局(GW)の制御部(GWCO)は、記録部(GWME)に記録されているセンシングデータを記録部(GWME)に格納されているセンサネットサーバ(SS)用の送信フォーマットに変換する。そして、基地局(GW)は、送信フォーマットに変換されたセンシングデータを送信・受信部(GWSR)を経由してセンサネットサーバ(SS)に送信する。
データ受信(SSRE)において、センサネットサーバ(SS)の送信・受信部(SSSR)は、基地局(GW)の送信・受信部(GWSR)からセンサネットサーバ(SS)用の送信フォーマットで送信されたセンシングデータを受信する。受信したセンシングデータは記録部(SSME)に格納される。
データ形式判断(SSDF)において、センサネットサーバ(SS)は、取得したデータの形式を記録部(SSME)のデータ形式(SSDFI)と比較することによって、データの形式を判断する。さらに、データ分類(SSDE)において、センサネットサーバ(SS)は、各データを要素ごとに切り分ける。
データ格納(SSPU)において、センサネットサーバ(SS)の制御部(SSCO)は、センシングデータをデータベース部(SSDB)のフォーマットに変換する。変換されたセンシングデータは、データベース部(SSDB)に格納される。データベース部(SSDB)への格納方法は、後で検索する際に有効なクエリとして用いることができるようにすることが好ましい。有効なクエリとしては、例えば、センシングデータ名、時刻、端末固有ID及び基地局固有IDがある。
センシングデータの取得(TRGE)からデータ格納(SSPU)までの一連の処理は定期的に行なわれる。
時刻修正(GWTM)は、基地局(GW)の時計(GWTA)の時刻を合わせるために行われる。基地局(GW)は、現在の時刻をネットワーク(NW)網にあるNTPサーバ(図示省略)から取得する。時刻修正(GWTM)の処理は定期的に行なわれる。
時刻修正依頼(GWTR)は、端末(TR)の時刻を合わせるために、基地局(GW)から端末(TR)へ依頼される。時刻修正(TRTM)は、時刻修正依頼(GWTR)によって基地局(GW)から送信された時刻に基づいて、時計(TRTI)の時刻を修正する処理である。時刻修正依頼(GWTR)から時刻修正(TRTM)までの処理は定期的に行なわれる。
次に、端末(TR)のセンシング部(TRSE)におけるセンシングの間隔と、送信・受信部(TRSR)における送信のタイミングについて、本実施の形態の場合の例の一つを挙げて述べる。
端末(TR)は、三軸加速度センサ及び赤外線送受信器を備え、これらが全て10秒サイクルでセンシング及びデータ送信を行う。
加速度センサは、10秒中の始めの2秒間でX、Y、Z軸方向各100回のセンシングを行う。センシングの結果として取得された加速度情報は、端末(TR)の状態を示す。端末(TR)が人物に装着されている場合、取得された加速度情報は、端末(TR)を装着した人物の活動の状態(例えば、その人物が静止しているか否か)を示す。
赤外線送信器は、10秒間あたり6回ずつ端末(TR)の正面に向かって赤外線信号を送信する。送信される赤外線信号には、端末情報(TRTR)、すなわち、自端末(TR)のID(識別子)を示す信号が含まれる。
二つの端末(TR)が向かい合ったとき、つまり二人の人物が対面したときには、一方の端末(TR)の受信器が、もう一方の端末(TR)のIDを受信する。すなわち、一つの端末(TR)が他の端末(TR)のIDを受信したとき、それらの二つの端末が対面していることを意味する。つまり、それぞれの端末(TR)が人物の前面に装着されている場合、二つの端末(TR)が対面していることは、それらを装着した二人の人物が対面していることを意味する。赤外線の受信器側は、常に待機状態となっており、10秒間のうちに受信したIDと、受信した回数を記録する。
そして、端末(TR)は、これらのセンシングデータにタイムスタンプ及び端末情報(TRTR)つまり自身の固有IDを付与した後、それらのセンシングデータを基地局(GW)に一括して無線送信する。結局、上記の例において、端末(TR)から送信されるセンシングデータには、その端末の加速度を示す情報と、その端末の固有IDと、その端末が他の端末と対面したことを示す情報と、それらの情報に対応付けられた時刻情報とが含まれる。これらのセンシングデータが、人物の交流を示すインタラクションデータとして利用される。
しかし、上記は一例に過ぎず、センシング間隔及び送信タイミングは、任意に設定することができる。
アプリケーション起動(USST)は、ユーザ(US)によるクライアント(CL)のアプリケーションの起動である。
初期条件設定(CLIS)において、クライアント(CL)は、図の提示に必要な情報を設定する。ユーザ(US)のボタン選択によって、表示の対象となるデータの時刻及び端末情報、表示方法の条件設定などを取得する。ここで設定した条件は、記録部(CLME)に格納される。
データ依頼(CLSQ)において、クライアント(CL)は、初期条件設定(CLIS)に基づき、アプリケーションサーバ(AS)に対して、データもしくは画像の依頼を行う。記録部(CLME)には、検索対象のアプリケーションサーバ(AS)の名称、アドレス等、センシングデータを取得するために必要な情報が格納されている。クライアント(CL)は、データの依頼コマンドを作成し、アプリケーションサーバ(AS)用の送信フォーマットに変換される。送信フォーマットに変換されたコマンドは、送信・受信部(CLSR)を経由して、アプリケーションサーバ(AS)に送信される。
アプリーションサーバ(AS)は、データ依頼(ASRQ)において、クライアント(CL)からの依頼を受信し、さらにセンサネットサーバ(SS)に対して取得すべきデータの時刻の範囲及びデータ取得対象である端末の固有IDを送信しセンシングデータを要求する。送信される時刻及び端末の固有IDは、アプリーションサーバ(AS)の記録部(ASME)又はクライアント(CL)の記録部(CLME)に格納されたものから自動的に設定されるものであってもよいし、クライアント(CL)の入出力部(CLIO)を通してユーザ(US)が指定したものであってもよい。
データ検索(ASSE)において、アプリーションサーバ(AS)は、データ依頼(ASRQ)に基づき、センサネットサーバ(SS)に対して、検索を行う。記録部(ASME)には、検索対象のセンサネットサーバ(SS)の名称、アドレス、データベース名及びテーブル名等、データ信号を取得するために必要な情報が記載されている。アプリーションサーバ(AS)は、データ検索(ASSE)を行う際、データ依頼(ASRQ)を通して検索内容を依頼し、データベースの情報を記録部(ASME)から取得し、検索に用いるコマンドを作成する。作成されたコマンドは、制御部(ASCO)によって、記録部(ASME)に格納されているセンサネットサーバ(SS)用の送信フォーマットに変換される。送信フォーマットに変換されたコマンドは、送信・受信部(ASSR)を経由してセンサネットサーバ(SS)に送信される。
センサネットサーバ(SS)内データベース(SSDB)は、受け取ったコマンドを実行してクエリし、アプリケーションサーバ(AS)にデータを送信する。
データ受信(ASRE)において、アプリーションサーバ(AS)は、データ検索(ASSE)のコマンドに基づいて、センサネットサーバ(SS)内のデータベース部(SSDB)から送信されたセンシングデータを受信する。送信・受信部(ASSR)が受信したセンシングデータは記録部(ASME)に格納される。
データ分類(ASDE)において、アプリーションサーバ(AS)は、取得したデータを適切な各要素に分類する。その際、時刻情報とセンシングデータは必ず関連付けたままで分類される。
ここまでの、データ依頼(CLSQ)からデータ分類(ASDE)までの流れが、図3のフローチャートにおけるデータ取得(APDG)に相当する。
次に、対面マトリクス作成(APIS)、対面人数・対面時間のカウント(APIC)、データプロット(APIP)のそれぞれの処理を順に行う。処理の詳細な内容は図3以降のフローチャートにて示す。これらの処理を行うプログラムは、記録部(ASME)に格納されており、データ処理部(ASDP)によって実行し、画像が作成される。
画像は、画像送信(APWS)においてクライアントに送信され、クライアントの出力デバイス、例えばディスプレイ(CLWD)に表示される(CLDI)。
最後の、アプリケーション終了(USEN)はユーザ(US)によるアプリケーションの終了である。
<全体のフローチャート>
図3は、本発明の第1の実施の形態において、アプリケーションの立ち上げから表示画面がユーザ(US)に提供されるまでの大まかな処理の流れを示すフローチャートである。
表示画面を作成するために、開始(APST)から、初期条件設定(APIS)、データ取得(APDG)、対面マトリクス作成(APIM)、対面人数・対面時間のカウント(APIC)、データプロット(APIP)、画面表示(APWO)の各手順が順次実行され、終了(APEN)となる。各手順について、順に詳しく述べる。
<初期条件設定のフローチャート>
初期条件設定(APIS)の中での手順を図4のフローチャートに示す。
初期条件設定(APIS)は、開始(ISST)から、ユーザID対応表読み込み(ISUI)、プロジェクト対応表読み込み(ISPU)、表示期間の設定(ISRT)、プロットするメンバの設定(ISRM)、役職の区別を設定(ISSM)、特定プロジェクトの強調の有無を設定(ISPO)の手順を行い、また特定プロジェクトを強調する(ISPY)場合には強調するプロジェクトを設定(ISPS)する。
ユーザID対応表読み込み(ISUI)では、例として図5のような、ノードの固有ID(ASUIT3)とそれを装着しているユーザ名(ASUIT2)とを一対一で対応づけているユーザID対応表(ASUIT)を読み込む。ユーザには今後処理するときに用いるユーザ番号(ASUIT1)を振っておく。必要があれば、役職(ASUIT4)を示す列も用意する。図5の例の場合では、部長を2、課長を1、一般社員を0として数値化して表現している。役職の区別の仕方は自由に設定して良い。組織のメンバや職位などに変更があった場合には、ユーザID対応表(ASUIT)のみを書き換えれば対応できる。
プロジェクト対応表読み込み(ISPU)では、例として図6のような、組織内に存在するプロジェクトの名前と、それに属するメンバとを対応付けるためのプロジェクト対応表(ASPUT)を読み込む。なお、部や課という組織全体に対するグループやユニットなどの固定した組織、またプロジェクトなどの柔軟に変化する組織など、全ての下位組織を指して以降ではプロジェクトと統一して呼ぶものとする。プロジェクト対応表(ASPUT)は、誰がどのプロジェクトに属しているか、が明確であれば良いのでユーザID対応表(ASUIT)に一体化して、各一行で表されているユーザに対して属するプロジェクト名を書く列が存在するという形式でも良い。また、プロジェクトによって表示を区分する必要がなければプロジェクト対応表(ASPUT)は必要ない。図6のプロジェクト対応表(ASPUT)では、一人のメンバが複数のプロジェクトに掛け持ちして属することにも対応しているが、必ずしも対応していなくてもよい。プロジェクト対応表(ASPUT)には、プロジェクト名(ASPUT2)と所属ユーザ番号(ASPUT3)の項目がある。また各プロジェクトには、今後処理するときに用いるプロジェクト番号(ASPUT1)を振っておく。所属ユーザ番号(ASPUT3)の項目の数字は、ユーザID対応表(ASUIT)におけるユーザ番号(ASUIT1)に対応している。プロジェクト対応表(ASPUT)をプログラム本体とは別に用意することで、プロジェクトのメンバ構成に変更があった場合には、このプロジェクト対応表(ASPUT)のみを書き換えることで容易に対応できる。しかしプログラム本体に直接記述しても良い。
表示期間の設定(ISRT)、プロットするメンバの設定(ISRM)、役職の区別を設定(ISSM)、特定プロジェクトの強調の有無を設定(ISPO)では、例えば図7のような初期条件設定ウィンドウ(ASISWD)をクライアント(CL)のディスプレイ(CLWD)などの出力装置に表示し、マウス(CLIM)やキーボード(CLIK)などの入力装置を用いてユーザ(US)に入力させることで、各々の設定を行う。初期条件設定ウィンドウ(ASISWD)は、始めからクライアント(CL)内に保管しておいても良い。
表示期間の設定(ISRT)は、ウィンドウの表示期間選択(ASISPT)のテキストボックス(PT01〜03、PT11〜13)にて日付を設定し、端末(TR)で取得された時刻がこの範囲内にあるデータを、表示のための計算に用いるものとする。必要があれば時刻の範囲設定を追加しても良い。
プロットするメンバの設定(ISRM)は、ウィンドウの表示メンバ選択(ASISPM)において行う。ウィンドウには、ユーザID対応表読み込み(ISUI)で読み込んだ全ユーザ名、また必要ならばノードIDを反映させる。ユーザ(US)はチェックボックス(PM01〜PM09)にチェックを入れる、もしくは入れないことでどのメンバのデータを表示するかを設定する。直接個々のメンバを指定するのではなく、既定のグループ単位、年齢などの条件によって表示メンバをまとめて指定させても良い。
役職の区別を設定(ISSM)、特定プロジェクトの強調の有無を設定(ISPO)は、ウィンドウの表示設定(ASISPD)において行う。役割の区別のチェックボックス(PD1)にチェックを入れた場合には、表示において役職によって四角や丸などの異なる記号でプロットされる。役職によるコミュニケーションの行い方の違いを検証したい場合に用いる。特定プロジェクトの強調のチェックボックス(PD2)にチェックを入れた場合には、表示において特定のプロジェクトに属するメンバに対応する記号が、塗りつぶすなどして他の記号よりも強調して表示される。プロジェクトごとに、どのようなコミュニケーションの行い方をしているのかを検証したい場合に用いる。
さらにチェックボックス(PD2)にチェックが入れられた場合には、図4のフローチャートにおいて特定プロジェクトを強調する(ISPY)がyesとなり、強調するプロジェクトの設定(ISPS)を行う。強調するプロジェクトの設定(ISPS)は、プロジェクト対応表(ASPUT)から読み込んだ各プロジェクト名を反映したチェックボックス(PD21〜PD25)にユーザがチェックを入れることで設定される。チェックの数は1つに限定しても良いし、複数であっても良い。
表示サイズ(ASISPS)領域では、表示される画像のサイズが設定される。本実施の形態では、画面に表示される画像が長方形であることを前提とする。画像の縦の長さがテキストボックス(PS01)に、横の長さがテキストボックス(PS02)に入力される。入力される数値の単位として、ピクセル又はセンチメートル等、何らかの長さの単位が指定される。
全てを入力したら最後に、表示開始ボタン(ASISST)をユーザ(US)が押すことで以上の初期条件を決定とし、図3におけるデータ取得(APDG)のステップに進む。
<データ取得〜対面マトリクスのフローチャート>
図8は、本発明の第1の実施の形態において、図3のデータ取得(APDG)と対面マトリクス作成(APIM)のステップの詳細を示したフローチャートである。
開始(DGST)からデータ取得(APDG)と対面マトリクス作成(APIM)を行い、終了(DGEN)する。データ取得(APDG)は、センサネットサーバ(SS)内のデータベース部(SSDB)の中から必要なデータを取得するプロセスである。
データベース部(SSDB)には複数のメンバの複数種類のセンシングデータが記録されているが、そのうちの赤外線送受信による対面データをまとめたテーブルの例を図9の(a)(b)に示す。図9の(a)は、対面テーブル(SSDB_1002)であり、ノードIDが1002である端末(TR)から取得されたデータを集めたテーブルであることを想定している。同様に、図9の(b)は、対面テーブル(SSDB_1003)であり、ノードIDが1003である端末(TR)から取得されたデータを集めたテーブルとする。なお、取得したノードごとにテーブルを分けなくても良く、他の加速度や温度などのデータも同じテーブルに含んでも良い。
対面テーブルには端末(TR)からデータを送信した時刻(DBTM)、赤外線送信側ID(DBR1)と受信回数(DBN1)を10組(DBR1〜DBR10、DBN1〜DBN10)分格納できる。今回は10秒間に1回データ送信を行うようにしているため、前回の送信からの10秒間のうちにどの端末(TR)から何回赤外線を受信したかを表しているものである。10秒間中に複数の端末(TR)と対面した場合にも、10組まで格納できるということである。なお、組の数は自由に設定することができる。対面、つまり赤外線の受信がなかった場合にはnullとなる。また、図9では時刻はミリ秒まで表記している。時刻の形式は統一されていればどのようなものでも良い。
図8のデータ取得(APDG)では、まずセンサネットサーバ(SS)のデータベース部(SSDB)に接続(DGCD)し、前述の初期条件設定(APIS)で設定した表示期間(ASISPT)と表示メンバ(ASISPM)の条件に基づきSQLコマンドを作成し、データベース(SSDB)から、その時刻(DBTM)が設定した表示期間に含まれているデータを表示すべき全メンバの対面テーブルから取得する(DGSG)。
対面マトリクスの作成(APIM)では、表示すべきメンバから一組(二人)を選択し(IMMS)、その二人のデータの時刻を揃えて結合テーブルを作成する(IMAD)。図9(a)の1002番の端末(TR)のデータと、図9(b)の1003番の端末(TR)データから作成した結合テーブルの例が図10の結合テーブル(ASCNT1002
‐1003)である。結合テーブルの作成(IMAD)の際には、それぞれの対面テーブルの時刻(DBTM)を揃え、結合テーブルの時刻(CNTTM)とする。また、図9(b)の一行目(RE01)と二行目(RE02)の間のように、データがセンシング周期(ここでは10秒間隔)で入っていない場合には、補完する。また、二つの対面テーブルの時刻が完全に一致していない場合には、どちらかに合わせるか、完全に10秒刻みになる時刻を設定し、それに近いデータをそれぞれ同時刻として扱うなどして、同じ時刻とみなせる行同士を見比べる。その中で、設定した二つの端末(TR)間での対面データが少なくとも一方の対面テーブルに存在した場合には、その時刻に二人のメンバが対面したとみなし、結合テーブルの対面の有無(CNTIO)の欄を1とする。そうでないときは0とする。このようにして結合テーブルを作成する。さらに、全ての時刻の対面があった回数を合計する。
対面したと判別するための基準は、赤外線受信回数が閾値以上であった場合のみとする、など別の基準を用いても良い。また、結合テーブルは合計対面回数(REsum)が計算できれば良いので、テーブルを作成せず、時刻をそろえながら対面回数をカウントしても良い。
次に、求めた合計対面回数の値を10倍し、対面マトリクス(ASTMX)の選択した二人のメンバを示す二箇所の要素に入れる(IMCI)。10倍するのは、合計対面回数1に対して10秒間対面したとみなし、対面マトリクスの値の単位を秒にそろえる目的である。必要がなければそろえなくても良い。
図11に対面マトリクス(ASTMX)の例を示す。行と列はそれぞれユーザID対応表(ASUIT)におけるユーザ番号(ASUIT1)に対応している。今の場合ではノードIDが1002番のユーザ番号は2、ノードIDが1003番のユーザ番号は3となるため、要素(TMX2_3)に値を入れる。また、対面に関しては一方が対面したならもう一方も対面したと考えるのが自然であるため、対面マトリクス(ASTMX)が対称行列となるように対称要素(TMX3_2)にも同じ値を入れる。しかし、意図がある場合には非対称行列とすることも可能である。
一組のメンバについて対面マトリクス(ASTMX)の要素を埋めたら、別の一組を選択し、全ての組の処理を完了するまで繰り返す(IMAM)。
<対面時間・人数のカウント>
図12は、本発明の第1の実施の形態において、図3の対面人数・対面時間のカウント(APIC)のステップの詳細を示したフローチャートである。
開始(ICST)から終了(ICEN)までのステップでは、メンバごとに対面時間の合計と対面人数のカウントを行う。
まずメンバを一人選択し(ICMS)、対面マトリクス(ASTMX)においてそのメンバのユーザ番号(ASUIT1)に対応する行を決める。次にその一行の対面マトリクスの値を合計する。合計したものが、図11の対面カウント(ASTMC)の対面時間(TMTI)となる(ICTI)。対面時間(TMTI)はつまり、そのメンバが設定した表示期間(ASISPT)内で何らかの人物とコミュニケーションを行った合計時間であり、コミュニケーションの量だとみなせる。またさらに、その一行の対面マトリクス(ASTMX)の、要素が正の値、つまり0より大きい値である要素の数をカウントし、それを図11の対面カウント(ASTMC)の対面人数(TMNM)とする(ICNM)。対面人数は、表示期間(ASISPT)内において関わりを持った他者の数であり、そのメンバの持つ関係の多様性と捉えることができる。
なお、図11の対面カウント(ASTMC)は、対面人数(TMNM)と対面時間(TMTI)を合わせたテーブルとしている、各メンバに対応する対面人数と対面時間の値が明確になっていれば、テーブル以外の形式でも良い。
以上の対面時間の合計(ICTI)と対面人数のカウント(TCNM)の手順を、全てのメンバについて終了するまで繰り返す(ICAM)。
<データプロットのフローチャート>
図13は、本発明の第1の実施の形態において、図3のデータプロット(APIP)のステップの詳細を示したフローチャートである。
データプロット(APIP)では、カウントした対面人数(TMNM)と対面時間(TMTI)をそれぞれ横軸・縦軸に取った座標上に各メンバをプロットする。このとき、初期条件設定(APIS)で設定した事項に基づき、メンバごとにプロットする記号の形や塗りつぶしの有無などを決定する。
データプロットの開始(IPST)後、まずグラフ領域の大きさを決める(IP10)。グラフ領域の大きさは表示画面のうちのグラフが占める領域の大きさであり、初期条件設定ウィンドウ(ASISWD)で設定した表示サイズ(ASISPS)から、縦横それぞれタイトルや軸の値、余白の部分を引いた値となるように計算する。
次に、横軸と縦軸それぞれの最大値を決定する(IP20)。ここではプロットすべき全データ、つまり図11の対面カウント(ASTMC)の対面人数(TMNM)、対面時間(TMTI)のそれぞれの最大値を参考にし、最大値以上のきりのいい数字となるように軸の値を設定する。他に比べて突出した大きな値がある場合には対面カウント(ASTMC)の最大値より小さな値を軸の最大値としてもよい。また、各軸は等差数列となるように目盛を区切った通常の軸(等差目盛)を想定しているが、対面人数(TMNM)または対面時間(TMTI)の分布によってはどちらか、もしくは両方を対数軸(対数目盛)としても良い。
次に、メンバを一人選択し、そのユーザ番号(ASUIT1)に対応した対面カウント(ASTMC)の対面人数(TMNM)・対面時間(TMTI)のデータから、先ほど決定した目盛を基準とし、プロットする座標を決定する(IP40)。
さらに、初期条件設定(APIS)の表示設定(ASISPC)において役職の区別チェックボックス(PD1)がONであった場合には(IP50)、そのメンバの役職(ASUIT4)をユーザID対応表(ASUIT)から引き出し、役職に対応する記号を選択する(IP51)。記号とはプロットする際に役職を区別するためのものであり、例えば部長は四角、課長は三角、一般社員は丸などとしてあらかじめ設定しておく。役職の区別を行わない場合には、デフォルトとして設定してある記号を用いる(IP55)。役職の区別をするためには、プロットする記号を変える以外の方法を用いても良い。
また、初期条件設定(APIS)の表示設定(ASISPC)において特定プロジェクトの強調チェックボックス(PD2)がONであった場合には(IP60)、プロジェクト対応表(ASPUT)を参照し(IP61)、強調すべきとして設定されているプロジェクトにそのメンバが属している場合には(IP70)、計算した座標上に記号を塗りつぶしてプロットする(IP71)。メンバが該当プロジェクトに属していない場合には記号を塗りつぶさずに座標上にプロットする(IP75)。なお、塗りつぶすのは該当プロジェクトに属しているメンバのみを強調させるためであるので、他の方法を用いて強調しても良い。
また、必要であればプロットした記号に隣接するように、そのメンバの氏名を表示させることも可能である。
全メンバに関してプロットが完了するまでIP30〜IP71の手順を繰り返す(IP80)。
また最後に、特定プロジェクトの強調チェックボックス(PD2)がONになっている場合には(IP90)、プロジェクトに属する全メンバ、つまり表示上ですでに塗りつぶされて表示されている全ての記号を、なるべく小さなもので包括するように楕円を描画する(IP91)。これは、プロジェクトのメンバが座標上にどのように分布しているかをつかみやすくするためであるが、必要ない場合には行わなくても良い。
以上を終えると終了(IPEN)とする。
<データプロットの結果例>
図14は、本発明の第1の実施の形態において、図3の初期条件設定(APIS)からデータプロット(APIP)までのステップを経て画面表示(APWO)される結果の一例である。役職の区別はON、特定プロジェクトの強調はOFFとしたものであり、実際の組織において約2ヶ月間、26人のメンバに端末(TR)をつけて業務を行ってもらった際の実データを用いている。以降、本発明の実施例1から実施例4については、このとき得られた実データを用いて本発明の効果を検証する。
なお、役職に対応する記号については、部長が四角、課長が三角、一般社員がダイヤ型としている。
また図14は、一日ごとに各メンバについて対面人数(TMNM)と対面時間(TMTI)を求め、さらに約2ヶ月分の結果をそれぞれ平均したものを座標に取り、プロットしている。よってこの方法ではプロットされた表示結果は、短期的な業務の内容よりも、メンバがその時期に負っている役割を強く反映したものが得られると考えられる。
図14の結果では、全体の傾向としては、対面人数と対面時間には正の相関があることがわかる。また職位別に見ると、部長は右上に多く、課長は中央付近に多い。また、一般社員は左下に多くが集まっている。つまり、組織全体をマネジメントする役割を持つ部長は、運営会議やプロジェクトの報告など様々な長時間の会議に出席するため対面人数も対面時間も多くなっていると考えられる。一方、一般社員は通常はPCに向かって文献調査やデータ処理、文書作成などの個人作業がメインの業務であり、コミュニケーションは主に同僚との議論や直属の上司である課長との打合せにおいて行われるのみであるため、対面人数も対面時間も少なくなっているメンバが多いのだと考えられる。また、プロジェクトのリーダーとしての役割を持つ課長は、プロジェクトに属する部下との打合せと、上司である部長への報告との業務を持つため、両者の中間付近に位置するのだと考えられる。
よって、2ヶ月分のデータを用いたものを本発明の手法で表現することで、組織に置いてメンバが負っている役割を、コミュニケーションという切り口から表現できることがわかった。
しかし本発明の意義として重要なのは、一般的に期待されている役割に全員が従っているか否かを確認することよりも、役職として期待される平均的なやり方とは異なったやり方でコミュニケーションを行っている人物に注目できるという点である。例えば、図14において個別のメンバについて見ると、人物aや人物bは一般社員であるが、ほとんどの課長よりも多くの人と長く関わっている。また人物cは課長であるが個人作業型に属しており、対面時間も対面人数も一般社員の平均程度しかない。また、どの部長よりも多くの人と関わっている課長(人物d)がいることもわかる。こういった異質なメンバは、たとえば人物aや人物bは一般社員という枠を自ら超えた仕事を行っていると捉えられ、また人物dは組織の多様な人物とのコネクションを多く持っているはずだと考えられ、これらの人物が組織を動かす隠れた鍵となっている可能性がある。また、人物cについては他者とのコミュニケーションよりも一般社員的な実作業に追われてしまっている可能性がある。このことは組織全体として喜ばしいことなのかどうかを、本図面を用いることで再検討するきっかけとなる。
<プロジェクト別の結果>
図15(a)〜(e)は、本発明の第1の実施の形態において、特定プロジェクトの強調チェックボックス(PD2)をONにし、5種類のプロジェクトにおけるメンバの分布を可視化した結果である。塗りつぶしてプロットされている記号がそのプロジェクトに属しているメンバであることを指し示しており、さらにそれらのメンバを包含するように描画された楕円がプロジェクトにおけるコミュニケーションの行い方の偏りや分布を示す助けとなっている。
図15(a)のプロジェクトAでは楕円が縦に細長い形状となっており位置としては右側に存在する。図15(b)のプロジェクトBでは楕円が横に長い形状となっており、位置としては中央から上付近に存在する。これら二つは、似通ったコミュニケーションのスタイルを持つ複数のメンバに対して、一人が全く異なったスタイルを持っている場合である。図15(c)のプロジェクトCでは楕円が底辺に張り付くような横長の形状となっており、対面人数については幅広く揃っているが、対面時間については全員が少ないプロジェクトであることがわかる。図15(d)のプロジェクトDでは他と比べて楕円が丸く小さく、左下の領域に集まっている。つまりメンバ全員について、コミュニケーションが少なく閉じたメンバのみとしか関わっていないことがわかる。図15(e)のプロジェクトEでは、丸みを帯びた楕円が中央付近に浮かんでいる。
またさらに、それぞれのプロジェクトにおいてリーダーに当たる人物が楕円の中のどのポジションにいるかを見ることで、それぞれのプロジェクトの進め方、リーダーの立ち位置がわかる。リーダーはほとんどの場合、四角で表現されている部長、または三角で表現されている課長が請け負っている。リーダーが複数存在するプロジェクトもあり、それは担当分野を切り分けてそれぞれがリーダーとなっているものである。
図15(a)のプロジェクトAではリーダーA1が突出して上にいる。会議は特に一回での時間が長くかかるため、会議の数が縦軸の対面時間に強く影響を与えていることがわかっている。よってこのリーダーA1が大きな会議にメインとなって出席しており、プロジェクトの左右を決定する役割を担っていると考えられる。また図15(b)のプロジェクトBでは課長であるリーダーBが突出して右に位置している。よって、リーダーBは会議に多く出ているわけではないが、プロジェクトB以外の人とも多くのつながりを持ち、情報収集を積極的に行うリーダーであると考えられる。図15(c)のプロジェクトCでは、リーダーは全体の真ん中に位置している。プロジェクトCに新しい風を持ち込む可能性が高いのはむしろ右端に位置している一般社員であり、リーダーは自ら積極的にプロジェクト外部とコミュニケーションを取るタイプではない。各メンバから相談を持ちかけられた時には答えるが、日頃は部下を見守りサポートに徹しているリーダーであるように見受けられる。図15(d)のプロジェクトDでは、全体的にバラつきが小さいがその中ではリーダーDはコミュニケーションの量(対面時間)が多い方であり、メンバをまとめる役割をしていると考えられる。また、図15(e)のプロジェクトEでは、二人のリーダーE1とリーダーE2が対面時間・人数共に多く、他の二人の一般社員は少ないため、会議やプロジェクトの進め方の検討など多くのコミュニケーションが必要な部分は二人のリーダーが行い、一般社員は個人作業に集中するという役割分担を明確にして進めているプロジェクトであることがわかる。
<全体の時系列変化の結果>
図16(a)〜(f)は、本発明の第1の実施の形態において、週ごとに図面を作成し組織コミュニケーションの時系列変化を追跡した結果である。
初期条件設定(APIS)の表示設定(APISPD)において、役職の区別チェックボックス(PD1)をON、特定プロジェクトの強調チェックボックス(PD2)をOFFにし、連続した6週間を週ごとに区切り、一枚ずつ図を作成したものである。なお、縦横それぞれの中央に線を入れて領域を4分割してあるが、この場合については実施例2において後述するためここでは省略する。また、図15までとは記号と役職の対応が異なっており、横長の長方形が部長、正方形が課長、丸が一般社員を表している。
このデータを取得した組織では、図16(c)と図16(e)の週に、多数のメンバが関わって準備する必要のある対外的なイベントがあった。そのため、それぞれのイベントの前の週(図16の(b)・(d))では組織が全体的に活性化し、あちこちで多くのコミュニケーションが行われていたことがわかる。また、イベントの週(図16の(c)・(e))とイベント後の週(図16の(f))は、イベントのために先送りにされていた作業を行っているためか、コミュニケーションの量が減っている様子が各メンバを示す記号のバラつき具合から可視化されている。
<あるプロジェクトの時系列変化>
図17(a)〜(d)は、本発明の第1の実施の形態において、週ごとに図面を作成し、あるプロジェクトFに着目して組織コミュニケーションの時系列変化を追跡した結果である。
初期条件設定(APIS)の表示設定(APISPD)において、役職の区別チェックボックス(PD1)をON、特定プロジェクトの強調チェックボックス(PD2)をONにし、連続した4週間を週ごとに区切って一枚ずつ図を作成したものである。
図17(a)〜(d)のそれぞれ楕円で囲まれている中の、正方形でプロットされているものがプロジェクトのリーダーFである。本プロジェクトFは、図17の始めの時点では各メンバに担当部分を分担し、最終的に顧客に提出するために調査結果を文書にまとめている段階であった。そのため図17(a)(b)ではプロジェクトのメンバ全員がコミュニケーションが少なく、左下に集まっている。図17(a)(b)の時期には、リーダーF自身も文書執筆に関わっており、他者とのコミュニケーションを絶って執筆作業に集中していたようである。しかし、図17(c)の始めの時期に事態が一転し、文書の内容を再び一から構成しなおさなくてはならなくなった。そこでプロジェクトFのメンバが集まり活発な議論を交わしていた様子が、図17(c)(d)と楕円が立ち上がってくる様子に表れている。またその際にはリーダーFが楕円の右上に位置しており、リーダーFが部長との打合せやプロジェクトのメンバとの議論を積極的に行い、リーダーシップを発揮してプロジェクトを強く牽引したことがわかる。
<対面時間・対面人数以外を軸に取る可能性>
なお、本発明ではセンサネットによって取得した人物のコミュニケーションに関するデータから各メンバに関する対面人数と対面時間を計算し、それぞれ横軸と縦軸に取ってプロットしているが、軸の一方が他者との関わりの多様性、もう一方が他者との関わりの量を表すものであれば、この他の計算方法を用いたものを軸としてプロットすることも可能である。例えば、対面人数と対面時間をセンシングデータが取れている時間で割って基準化したものをそれぞれ軸としても良い。また、他者との関わりの多様性としては、同じプロジェクトではない人との対面に限定して人数をカウントしても良い。もしくは業務の種類の異なる人、座席の遠い人、役職の離れている人、頻繁に会わない人など対面相手に対して重み付けし合計したものを軸としても良い。一方、他者との関わりの量としては、音声や着席情報などから、メンバ同士が同じ場所にいた時間の量などを用いても良い。
また、対面したことの判別に、赤外線データだけでなく音声データによる分析も加え、「会話している」と判断できた場合のみを「対面」とみなすこともできる。
<人以外の物に端末を装着した場合の可能性>
なお、本発明におけるコミュニケーションとは、人と人の間における対面コミュニケーションに限定せず、人と物との相互作用も含む概念である。
例えば、店頭の商品に端末(TR)を取り付けた場合には、その商品に触れるもしくは覗き込むなどして商品に興味を持った顧客とのコミュニケーションが生じたと捉える。この情報を用いて表示を作成することによって、商品が幅広い顧客から興味を持たれているのか、特定のタイプの顧客から強い興味を持たれているのかを分析することができ、店内での商品の配置場所の決定、顧客へのアピール戦略の決定などに生かすことができる。またさらに、店員が顧客に対してその商品の説明を行った場合には、店員‐顧客‐商品の三項間でのコミュニケーションを端末(TR)を介して検出することができる。この情報は、店員が顧客に声をかけることによる売り上げへの効果の検証に役立てることができる。またそれぞれの端末(TR)で取得した加速度や音声データを合わせることにより、店員が顧客に声をかける効果的なタイミングや、説明する際の効果的な身振りや声のトーンを分析することができる。
また、オフィス内のPCやコピー機、コーヒーメーカーなどの装置に端末(TR)を取り付けた場合には、その端末(TR)の情報を用いて表示を作成することによって、多様な人が少しずつ利用する装置、特定の人だけが利用する装置、多くの人が長い時間利用する装置、などを分類することができる。また、装置や人の端末(TR)の情報によって、誰がどのような時間帯に装置を利用しているかがわかる。これによって、各メンバーのワークスタイルをより幅広く捉えることができる。また、コピーを取ったりコーヒーを淹れることをきっかけに多様な人との会話がはじまっていたりすることを検出し、コミュニケーションをより活性化させるためのオフィス設計に生かすこともできる。
またさらに、会議室や自販機、喫煙所などの部屋や領域において、その入り口や壁面、テーブルの中央などに端末(TR)を取り付けた場合には、その端末(TR)の情報を用いて表示を作成することによって、多様な人が入れ替わり立ち替わりする場所、特定の人だけが存在する場所、多くの人が長い時間滞在する場所、などを分類することができる。また、部屋・領域や人の端末(TR)の情報によって、その部屋もしくは領域にどのような人がどの時間帯に集まっているか、どの場所においてコミュニケーションが活発になっているか、どのような場所がアイディアを生むために効果的かを分析し、オフィス設計に生かすことができる。
本発明の第4の実施の形態について図面を参照して説明する。
<実施例4の概要>
実施例4では、実施例1または実施例2の表現に加え、主観的なパフォーマンス評価による個人のコミュニケーションの志向性を矢印(ベクトル)で表現する。図25に実施例4において作成した表示の結果の一例を示す。なお図25は、実施例2の表現をベースにした場合のものである。
具体的には、プロットされた記号に加え、その記号に対応する人物のコミュニケーションに係る志向性を示す矢印をその記号に対応させて表示することを特徴とする組織コミュニケーション可視化システムである。
<コミュニケーション志向の表現方法の説明>
図25の個々の矢印は、各メンバに関して、対面時間・対面人数とパフォーマンス評価との相関係数の正負を示している。そのメンバにとって、どのようなコミュニケーションを行うとパフォーマンスが向上するのか、もしくは低下するのかを矢印の向きで表現する。なお、相関係数の値の絶対値が一定値以下であった場合には無相関として矢印を表示しないものとする。図26に矢印の方向と、対面時間と対面人数に対する相関係数の正負との関係を示す。対面時間に対して正の相関を持つ場合、つまり多くのコミュニケーションを行う方がパフォーマンスが向上するメンバは上向きの矢印になる。逆に、対面時間に対して負の相関を持つ場合、つまりコミュニケーション量は少ない方がパフォーマンスが向上するメンバは下向きの矢印となる。また、対面人数に対して正の相関を持つ場合、つまり多くの人と関わる方がパフォーマンスが向上するメンバは右向きの矢印となり、対面人数に対して負の相関を持つ場合、つまり多くの人と関わらない方がパフォーマンスが向上するメンバは左向きの矢印となる。さらに、対面時間と対面係数の両方が正、または両方が負、一方が正で一方が負であった場合には、それぞれ上下左右のベクトルの合計として考え、図26に示したように斜め向きの矢印で表現する。なお、矢印(ベクトル)は向きのみを考慮するものとし、長さは全て一定にした。
全メンバについて相関を計算し、矢印を付加した結果が図25である。個々のメンバに注目すると、個人の性格、業務の進め方のポリシーなどコミュニケーションにおける志向性を表すことができる。また、全体として俯瞰すると、現状行っているコミュニケーションのパターン、つまり実施例2で述べたコミュニケーションの4分類と、望むコミュニケーションの志向性にどのような傾向があるのかを図から捉えることができる。
<実施例4の結果と効果>
実施例4を組織マネジメントに応用することで得られる効果を、図25の結果を用いて具体的に述べる。
まず図25において、個人作業型の領域に注目してみると、ベクトルが右下を向いているメンバが多い。つまり、個人作業型のメンバは、多くの人と話すことはプラスだが、長い時間拘束されるのはマイナスだと感じているということである。特に、その内訳には一般社員が多いことを踏まえると、長時間会議や議論するよりも自分の業務に集中して取り組み、能力を高めたいという願望があるのではないかと考えられる。
対して右上マネージャー型の人物f、人物g、人物hの3人の部長は、それぞれ対面人数に対して負、対面時間に対して正、対面人数に対して正となっている。人物hは、関わる人が少ない方が満足度が高まるため、現状の対面人数は本人にとっても多すぎると感じていることが懸念される。人物gも現状では相対的に対面人数が多いが、人物hと対照的にそれでも多くの人と関わる方が業務の満足度が高まるとしている。また人物fも、関わる人数に関しては無相関だが対面時間は長い方が満足度が高まる。コミュニケーションタイプがマネージャー型に属するメンバは、現在すでに経営会議や部下との議論によって意思決定をすることが多い立場であると考えられる。よって人物fや人物gにとっては、多くの人と、または長い時間コミュニケーションすることが業務の達成であると感じていると考えられる。
よって、コミュニケーションタイプが個人作業型に属するメンバは調査・分析など個人の作業を重要な業務として捉えており、マネージャー型に属するメンバは会議が重要な業務であると捉えている人が多いということがわかった。このようなメンバは、コミュニケーションの行い方の「現状」と「志向性」が合っているとみなすことができる。しかし、「現状」はマネージャー型のコミュニケーションを行っているのに「志向性」としてはコミュニケーション量を減らしたいというように、「現状」と「志向性」が合っていないパターンでは、本人のスタイルと担当業務の性質がマッチしておらずストレスになっている可能性がある。このようなメンバに注目し、フォローしながら組織編成や業務の割り振りを見直すことで、より活気のある組織づくりに生かすことができる。
<全体構成図>
図27は、本発明の第4の実施の形態における、インタラクションデータを取得する端末から、取得したデータを表示するアプリケーションまでを含むシステム全体の構成の説明図である。
実施例1の図1と異なる点は、アプリケーションサーバ(AS)内のデータ処理部(ASDP)にパフォーマンス相関(APPK)が追加されている点、記録部(ASME)内にパフォーマンス評価テーブル(ASPT)・パフォーマンス結合テーブル(ASPC)・パフォーマンス評価シート(ASPS)が追加されている点のみである。
パフォーマンス相関(APPK)は、パフォーマンスデータとセンシングデータの相関を計算する処理である。計算の処理とプロット処理の詳細はあわせて図29で示す。
パフォーマンス評価テーブル(ASPT)は、図30で示した個人のパフォーマンス評価結果をまとめたテーブルである。
パフォーマンス評価シート(ASPS)は評価したパフォーマンスを入力させるためにユーザ(US)に提示するものである。例は図30に示す。パフォーマンス評価シート(ASPS)はアプリケーションサーバ(AS)上に保管しておき、ユーザ(US)からの呼び出しがあった場合のみクライアント(CL)に送って画面に表示しても良いし、始めからクライアント(CL)内に保管しても良い。また、印刷して紙の形でユーザ(US)の手元に置いておいても良い。
パフォーマンス結合テーブル(ASPC)は、同じ人物の同じ日付のセンシングデータとパフォーマンスデータを対応付けたテーブルであり、その例は図31に示す。
<シーケンス図>
図28は、本発明の第4の実施の形態における処理の流れを示すシーケンス図である。
パフォーマンスデータの入力、格納、処理にまつわる部分のみが図2と異なっている。個別に示すと、パフォーマンス入力(USPI)、パフォーマンスデータ送信(CLPS)、パフォーマンスデータ格納(ASPC)、パフォーマンスデータ取得(ASPG)、パフォーマンス計算(ASPK)の5ヶ所である。
パフォーマンス入力(USPI)は、例えば1日に1回など、定期的にユーザ(US)が業務を振り返ってパフォーマンスを評価し、パフォーマンス評価シート(ASPS)に入力する。入力した結果は、クライアント(CL)を通してアプリケーションサーバ(AS)に送信され(CLPS)、アプリケーションサーバ(AS)内記録部(ASME)のパフォーマンス評価テーブル(ASPT)に記録・格納される(ASPC)。
また、アプリケーションが起動され、図25の図を作成する際には、パフォーマンスデータを利用する。図3の全体の処理の流れにおけるデータ取得(APDG)としてセンシングデータをデータベースから取得する際に、パフォーマンス評価テーブル(ASPT)から必要なメンバ・日時のパフォーマンスデータを取得する(ASPG)。さらに、実施例1と同様にして対面人数・対面時間のカウント(APIC)の後に、パフォーマンス相関計算(ASPK)を行う。その後のデータプロット(APIP)の手順は図29に示す。
<フローチャート>
図29は、本発明の第4の実施の形態において、図3の全体のフローチャートにおけるデータプロット(APIP)と新たに追加されるパフォーマンス相関計算(APPK)のステップの詳細を合わせて示したフローチャートである。図3のデータプロット(APIP)以外の部分の手順については実施例1とほぼ同じであるので説明を省略する。
実施例4におけるデータプロット(APIP)は、実施例1または実施例2のデータプロット(APIP)に、センシングデータ(対面時間・対面人数)とパフォーマンス評価値の相関計算もしくは重回帰分析の手順と矢印のプロットが追加される。
パフォーマンス相関計算(ASPK)では、説明変数を対面人数、目的変数をパフォーマンス評価値としたときの相関係数を求め、また、説明変数を対面時間、目的変数をパフォーマンス評価値としたときの相関係数を求める。もしくは、説明変数を対面人数と対面時間、目的変数をパフォーマンス評価値として重回帰分析を行い、偏回帰係数を求める。どちらの方法を用いても良いが、対面人数と対面時間がそれぞれパフォーマンス評価値に対して正の影響を与えているのか、負の影響を与えているのかを相関係数もしくは偏回帰係数から判断できれば良い。図29のフローチャートでは重回帰分析を用いて求めた偏回帰係数を用いる方法を提示している。
まず、データプロットの開始(IPST)後、各メンバごとにパフォーマンス結合テーブル(ASPC)を作成する。パフォーマンス結合テーブル(ASPC)の一例は図31に示す。これは、あるノードIDが1002であるユーザ(US)に関するパフォーマンス結合テーブル(ASPC_1002)であると想定している。センシングデータから計算した特徴量として、このユーザ(US)の1日の対面人数(TMNM)と対面時間(TMTI)、パフォーマンス評価値(TMPQ)のデータに日付情報(TMDT)を加えて組にし、それを複数日分集めたものである。パフォーマンス評価値(TMPQ)は、図30のパフォーマンス評価シート(ASPS)に示した項目のうちから1つを選択する、もしくは複数の項目に処理を加えて新たな変数とする、もしくはパフォーマンス評価シート(ASPS)以外から取得したデータを用いる、などから設定する。
また、パフォーマンス結合テーブル(ASPC)上の対面人数(TMNM)、対面時間(TMTI)に関して平均値(REave)を求めておき、図面上に記号をプロットする際には平均値をそのユーザ(US)の代表値としてその座標上にプロットする。座標を決めるためには平均以外の方法を用いても良い。
次に、グラフ領域の大きさの決定(IP220)と対面人数・対面時間の最大値の計算(IP230)を行う。これらはそれぞれ、実施例1の図13における処理(IP10)、処理(IP20)と同じ処理である。表示に4領域を区切る基準線を加える場合には、基準値の計算とプロットを実施例2の図19の処理(IP81、IP82、IP83)と同様にして行っておく。
次に、メンバを一人選択し(IP240)、パフォーマンス結合テーブル(ASPC)における対面時間データ(TMTI)と対面人数データ(TMNM)、パフォーマンス評価値(TMPQ)をそれぞれ正規化し(IP250)、パフォーマンス結合テーブル(ASPC)上のデータを正規化後のデータに置き換える。そして、パフォーマンス結合テーブル(ASPC)の各行について重回帰式を作成し(IP260)、対面人数・対面時間に対応する偏回帰係数を取得する(IP270)。それぞれの偏回帰係数の正負に従って、プロットする矢印の向きを決定する。
次に、そのメンバの対面人数と対面時間の平均値をプロットするが、縦軸・横軸の座標計算(IP290)から記号のプロット(IP300、IP301)までの流れは、実施例1の図13における処理(IP40)から処理(IP71、IP75)までと同じなので説明は割愛する。
最後にプロットした記号上に、先立って決定した向きの矢印をプロットする(IP310)。
これを全てのメンバのプロットを完了するまで繰り返し(IP320)、終了(IPEN)とする。
<パフォーマンス評価シート>
図30は、本発明の第4の実施の形態において用いるパフォーマンス評価シート(ASPS)の一例である。
パフォーマンス評価シート(ASPS)は、業務の成果、業務のプロセス、また身体の調子について、各メンバの主観的な評価を付けてもらい、主観評価とセンサによる特徴量(ここでは対面人数と対面時間)との結びつきを分析するために用いる。
評価項目は、業務の遂行性、業務全体の出来としての満足度、業務のプロセスにおける個人作業、Face To Face(対面)またはサイバー上でのコミュニケーション、心の健康、体の健康、自由記述、とした。
また、個人に対する評価と共に、一部の評価項目についてはプロジェクトとしての業務の成果も並行して評価する。本来ならば全てのプロジェクトに対して属する全メンバが評価すべきであるが、複数プロジェクトに関わっているメンバには負担が大きくなる。そのため、メンバごとに評価対象とするプロジェクトをメインプロジェクトとして指定し、メインプロジェクトに関する自分の業務の評価、他のメンバも含んだ業務の評価、さらに携わっているプロジェクト全てに関する評価を区分した。
以上の評価項目は、その他(RS300)の自由記述以外は5段階での評価とした。
本実施例において、ユーザ(US)は、例えば1日1回各自の業務を振り返りこのシートの各項目について評価を記入する。図30はプリントアウトした用紙に手書きで印をつけ、担当者がまとめてクライアント(CL)またはアプリケーションサーバ(AS)に入力することを想定しているが、入力用ウィンドウを用意し、各ユーザ(US)が直接クライアント(CL)またはアプリケーションサーバ(AS)に入力しても良い。
入力された毎日の全ユーザ(US)の評価データは、日付、ユーザ名(ASUIT2)もしくはユーザID(ASUIT3)、評価項目番号、評価データを組にしたパフォーマンス評価テーブル(ASPT)として、アプリケーションサーバ(AS)内記録部(ASME)に格納される。
<各項目の説明>
図30は、未記入のこの評価シートをプリントアウトした用紙を各ユーザ(US)に配布し、手書きでユーザ(US)に記入してもらうことを想定している。
まず、日付(RS01)、氏名(RS02)を記入する。日付(RS01)は評価の対象となる月日であり、氏名(RS02)はユーザ名(ASUIT2)である。これらはユーザ(US)本人が記入しても良いし、始めから記入された用紙を配布しても良い。
メインプロジェクト(RS03)は、対象ユーザ(US)が属しているプロジェクトのうち、特に評価してほしいものを選択し記入する。これは、ユーザ(US)本人が、現在の業務の中心となっているプロジェクトから選択しても良いし、分析者が指定してもよい。
設問項目(RS10)は、評価する項目の内容を示すものである。
設問項目(RS10)は大別すると結果評価(RS100)とプロセス評価(RS200)、その他(RS300)に分かれる。
結果評価(RS100)とプロセス評価(RS200)を分けたのは、日常的な業務において、個別の作業や他者との会話、本人の体調やメンタル状態などのプロセスに対する統合的な結果として、業務の良し悪しの結果評価があると考えるからである。なお、これらを区別しない評価シートを用いても良い。また、その他(RS300)は、対象月日の出来事、感想などを自由筆記によってメモするために設けたものである。
結果評価(RS100)には自分の業務全体の遂行性、自分の最重要案件の遂行性、満足度の項目がある。満足度は、達成の有無だけでなく全てを含んだ業務の成果に対する本人の主観評価である。
プロセス評価(RS200)には個人作業、コミュニケーション、心の健康、体の健康の項目がある。さらにコミュニケーションにはFace To Face(対面)でのコミュニケーションとサイバー上(メールやブログ、ソーシャルネットワークなどを介したもの)でのコミュニケーションとを区分した。これは、組織において対面でのコミュニケーションによってもたらされる効果と、サイバー上でのコミュニケーションによってもたらされる効果は質が異なるという考えに基づいているからである。個人作業は、情報収集や分析・資料作成など基本的に一人で取り組む業務に関する評価である。心の健康とは、メンタル面での元気良さに関する評価であり、体の健康とは体調に関する評価である。
なお、個人に関するパフォーマンス評価、プロジェクトに関するパフォーマンス評価は図30以外の評価項目を用いても良い。また本実施例4の結果(図26)は、センシングデータとパフォーマンス評価との重回帰分析を行う際に、「業務の満足度」の「関係プロジェクト全体」の評価結果を用いたものである。