JP5825417B2 - 業務向上支援システムおよび業務向上支援方法 - Google Patents

Description

本発明は、センサ端末を身に着けた人物間のインタラクションデータに基づき、組織における個人のコミュニケーションスタイル、さらに組織のコミュニケーションスタイルを可視化する組織コミュニケーション可視化システムに関する。

従来、携帯電話によるコミュニケーションを送受信履歴から分析し、人間関係をネットワークとして可視化する技術が開示されている（例えば、非特許文献１参照）。

また、従来、組織内もしくは組織間における電子メールのログや会議の記録などの複数の手段によって行われたコミュニケーションの記録を用い、共通の指標に統合して示す技術が開示されている（例えば、特許文献１参照）。

特開２００６‐１２７１４２号公報

イーグル Ｎ、ペントランド Ａ、「リアリティ・マイニング：センシング・コンプレックス・ソーシャル・システムズ」、Ｊ・オブ・パーソナル・アンド・ユビキタス・コンンピューティング、２００５年７月（Eagle, N., and Pentland, A., "Reality Mining: Sensing Complex Social Systems", J. of Personal and Ubiquitous Computing, July 2005）

あらゆる組織において生産性の向上は必須の課題となっており、職場環境の改善及び業務の効率化のために多くの試行錯誤がなされている。工場等の組立又は搬送を業務とする組織に限定した場合には、部品又は製品の移動経路を追跡することでそのプロセスや成果を客観的に分析することができる。一方、知識労働者から成る組織に関しては、モノではなく電子的な文書やＩＴ機器の使用ログを用いることによって、業務プロセスを可視化するものが既に知られている。

そもそも組織とは複数の人間が力を合わせることによって、個人ではできない大掛かりな業務を達成するために形成されている。よって、どのような組織においても２人又はそれ以上の人物間での意思決定及び合意のためには必ずコミュニケーションが行われている。コミュニケーションの手段としては、電話やファックス、電子メールなどが挙げられるが、最も頻繁に行われ、かつ最も強い影響力を持つものはｆａｃｅ−ｔｏ−ｆａｃｅ（対面）によるコミュニケーションである。対面コミュニケーションでは、身振りや視線、表情、声の調子など人間の身体を最大限に生かすことができる。このため、日常の挨拶による好意的な関係の形成、複雑に利益の絡む交渉の場での歩み寄り、など組織において欠かせないコミュニケーションの多くが、対面コミュニケーションによって当然のように実現されているのである。

また、対面コミュニケーションでは、関わる２人またはそれ以上の人間がリアルタイムで会話のリズムや場の雰囲気を生み出す。そのため、予測できないところから感情の共鳴やアイディアの創発が起こることがある。知識労働が中心である組織の成果において、このようにして生まれた創造的なアイディアによってもたらされている部分は大きい。その重要性に気づき、座席のフリーアドレス制や横断プロジェクトの編成などの試みを導入する組織は近年増加する傾向にある。これはどちらも多様なバックグラウンドを持つ人同士が接する機会を用意することで、新しい価値が創発することを期待したものである。

従来の方法ではいずれも作業を主体として分析しているが、知識労働については人を主体としなくてはその本質をつかむことはできない。なぜなら、作業別の手順や時間のみを切り出し効率化を目指すだけでは最大限の結果を引き出すことはできないからである。よって知識労働において良い結果を引き出すには、個人個人の特性に焦点を当てる、特にワークスタイルを知ることが必要であると考える。ワークスタイルとは、いつ、どこで、何を行うかという個人の業務の進め方のパターンである。ワークスタイルは、外的要因である業務の内容と内的要因である本人の性格の両者が反映されたものであり、知識労働のプロフェッショナルはそれぞれのワークスタイルを確立している。議論しながらアイディアを得る人もいれば、一人になってじっくり考える人もいる。また外に出て歩き回る人、机の前に座って雑誌をめくる人もおり、そのスタイルは多種多様である。知識労働はとりわけ精神的なものである分、最も効果を上げるための方法は、個人の資質、担っている役割などに依存してそれぞれ異なるものになる。しかし従来の作業を主体とした分析方法では直接的に業務の成果物に反映されていない事柄、例えば読書や散歩、雑談などが与える影響については全く考慮されることがない。よって人を主体とし、メンバ一人一人の実際の行動を観察することによってワークスタイルを捉えることが必要である。そして個人のワークスタイルを互いに把握し尊重し合うことで、組織全体としてのワークスタイルが確立され、生産性の向上に結びつくと考えられる。

さらに、知識労働における創造性は日常的な他者とのコミュニケーションから生み出されているものが多いと考えられる。このことから、ワークスタイルの中でもコミュニケーションの行い方が鍵となる。よってこれを「コミュニケーションスタイル」と呼び、コミュニケーションスタイルを分析するための切り口を見つけることが必要である。コミュニケーションスタイルとは例えば、友人との雑談を業務の活力にする、徹底的な議論を重視する、誰にも邪魔されずにじっくり考え抜くのを好む、といった業務の中での個人のコミュニケーションの行い方のパターンである。ワークスタイルと同様に、コミュニケーションスタイルも人を主体として実際のコミュニケーションを観察することによって捉えられるべきものである。またさらに、組織に属する全て、もしくは一部のメンバのコミュニケーションスタイルの総和や分布によって、組織全体の活発さやメンバの偏りを捉え、これを組織のコミュニケーションスタイルとする。また組織内に複数存在する下位組織ごとに活発さや属するメンバのコミュニケーションスタイルの偏りを捉え、これを下位組織のコミュニケーションスタイルとする。

しかしながら、上記非特許文献１、特許文献１のいずれも、実際の対面コミュニケーションを観察することによって組織に属する個人のコミュニケーションスタイル、組織のコミュニケーションスタイル、組織に含まれる下位組織のコミュニケーションスタイルを捉えるための具体的な可視化システムについては、何ら開示していない。

本発明では、実際の対面コミュニケーションを観察することによって組織に属する個人のコミュニケーションスタイル、組織のコミュニケーションスタイル、組織に含まれる下位組織のコミュニケーションスタイルを捉えるための可視化システムを提供することを目的とする。

本発明の代表的なものの一例を示せば、以下のようになる。すなわち、本発明の組織コミュニケーション可視化システムは、複数の端末と、前記複数の端末から送信されたデータを処理する処理装置とを具備して成る組織コミュニケーション可視化システムであって、前記各端末は、他の端末との対面状態を検出するセンサと、前記センサが検出したデータを送信するデータ送信部とを備え、前記処理装置は、第１の前記端末から送信されたデータに基づいて、前記第１の端末を装着した第１の人物あるいは物の有する当該組織の他の人物あるいは物との関係の強さを示す特徴量と、前記第１の端末を装着した第１の人物あるいは物の有する当該組織の他の人物あるいは物との関係の多様性を示す特徴量との、二種類の特徴量を併せて表示することを特徴とする。

本発明によれば、実際の対面コミュニケーションデータから、組織に属するメンバのコミュニケーションスタイル、組織のコミュニケーションスタイル、下位組織のコミュニケーションスタイルを可視化することができる。

本発明の第１の実施の形態における、インタラクションデータを取得する端末から、作成した画像の表示までを含むシステム全体の構成の説明図である。 本発明の第１の実施の形態において、センシングデータが端末からユーザに提供されるまでの処理を示すシーケンス図である。 本発明の第１の実施の形態において表示画面を作成するために実行される処理を示すフローチャートである。 本発明の第１の実施の形態において初期条件を設定するために実行される処理を示すフローチャートである。 本発明の第１の実施の形態の、ユーザＩＤ対応表の例を示す説明図である。 本発明の第１の実施の形態の、プロジェクト対応表の例を示す説明図である。 本発明の第１の実施の形態の、初期条件設定のために表示される画面の例を示す説明図である。 本発明の第１の実施の形態において実行される、データ取得から対面マトリクス作成の処理を示すフローチャートである。 本発明の第１の実施の形態のセンサネットサーバが保持するデータベース部の説明図である。 本発明の第１の実施の形態のセンサネットサーバが保持するデータベース部の説明図である。 本発明の第１の実施の形態のアプリケーションサーバによって作成される結合テーブルの説明図である。 本発明の第１の実施の形態のアプリケーションサーバによって作成される対面マトリクスの説明図である。 本発明の第１の実施の形態において対面人数と対面時間を計算するために実行される処理を示すフローチャートである。 本発明の第１の実施の形態においてデータをプロットするために実行される処理を示すフローチャートである。 本発明の第１の実施の形態を実行した結果出力される図面の一例である。 本発明の第１の実施の形態を実行した結果出力される、プロジェクト別の図面の一例である。 本発明の第１の実施の形態を実行した結果出力される、組織の時系列変化の図面の一例である。 本発明の第１の実施の形態を実行した結果出力される、プロジェクトの時系列変化の図面の一例である。 本発明の第２の実施の形態における、４領域の説明図である。 本発明の第２の実施の形態においてデータをプロットするために実行される処理を示すフローチャートである。 本発明の第２の実施の形態を実行した結果出力される図面の一例である。 本発明の第２の実施の形態を実行した結果出力される、プロジェクト別の図面の一例である。 本発明の第３の実施の形態における表現方法の説明図である。 本発明の第３の実施の形態においてデータをプロットするために実行される処理を示すフローチャートである。 本発明の第３の実施の形態を実行した結果出力される、プロジェクト別の時系列変化の図面の一例である。 本発明の第４の実施の形態を実行した結果出力される図面の一例である。 本発明の第４の実施の形態における表現方法の説明図である。 本発明の第４の実施の形態における、インタラクションデータを取得する端末から、作成した画像の表示までを含むシステム全体の構成の説明図である。 本発明の第４の実施の形態において、センシングデータが端末からユーザに提供されるまでの処理を示すシーケンス図である。 本発明の第４の実施の形態においてデータをプロットするために実行される処理を示すフローチャートである。 本発明の第４の実施の形態において利用する、パフォーマンス評価シートの見本である。 本発明の第４の実施の形態の、パフォーマンス結合テーブルの例を示す説明図である。 本発明の第５の実施の形態を実行した結果出力される図面の一例である。 本発明の第５の実施の形態を実行した結果出力される図面の一例である。 本発明の第５の実施の形態における主成分軸への射影の説明図である。 本発明の第５の実施の形態においてデータをプロットするために実行される処理を示すフローチャートである。 本発明の第６の実施の形態を実行した結果出力される図面の一例である。 本発明の第６の実施の形態において利用する、特徴量を色への対応付けの説明図である。

対象になる人物が装着したセンサ端末から、その人物と他の人物との対面に関するデータを取得し、コミュニケーションの多様性と量を二軸に取ってプロットすることで、個人と組織の様子を表現する表示システムを実現した。

最初に、本発明の第１の実施の形態について図面を参照して説明する。
＜全体の処理の流れの概要＞
第１の実施の形態では、無線送受信器を有するセンサ端末（ＴＲ）を組織の各メンバが装着し、その端末（ＴＲ）によって各メンバ間の交流（インタラクション）に関するデータを取得する。取得したデータは無線によって基地局（ＧＷ）に送信され、さらにセンサネットサーバ（ＳＳ）に格納される。組織コミュニケーションに関する表示を作成する際には、クライアント（ＣＬ）からアプリケーションサーバ（ＡＳ）に依頼を出し、組織に属するメンバに関するデータをセンサネットサーバ（ＳＳ）から取り出す。それをアプリケーションサーバ（ＡＳ）において、各メンバのコミュニケーションの量と多様性の基づいて処理・プロットし画像を作成する。さらにその画像をクライアント（ＣＬ）に戻し表示する。この一連の組織コミュニケーション可視化システムを実現した。

具体的には、複数の端末と、その複数の端末から送信されたデータを処理する処理装置とを具備して成る組織コミュニケーション可視化システムであって、各端末は、他の端末との対面状態を検出するセンサと、そのセンサが検出したデータを送信するデータ送信部とを備え、処理装置は、第１の端末から送信されたデータに基づいて、第１の端末を装着した第１の人物の、当該組織の他者と持つ関係の強さを示す特徴量と関係の多様性を示す特徴量とを視覚的に関係付けて表示する関係付け表示を行うことにより、当該組織のコミュニケーションスタイルを可視化することを特徴とする組織コミュニケーション可視化システムである。
＜表示内容の説明とその効果＞
第1の実施の形態は、図１のディスプレイ（ＣＬＷＤ）の内部、また図１４で例を示した組織コミュニケーションを示す図を描画するためのものである。この図は、例えば一日を単位として、各メンバが一日で対面した相手の人数を横軸、誰かと対面していた時間の合計数を縦軸に取り、プロットしたものである。ここで、対面時間の合計数とは、各メンバのコミュニケーションの量と捉えることができる。また、知識労働組織においては、多様な知識やバックグラウンドを持つ他者とコミュニケーションを行うことで新しいアイディアや価値が創発する可能性が高くなると考えられる。よって、横軸の対面人数とは、各メンバの行っているコミュニケーションの多様性を1つの視点から示したものであると捉えられる。この２つを軸とし、組織に属する全部もしくは一部のメンバの位置をプロットする。これによって、組織全体としてはコミュニケーションがどのように分布して行われているかを知ることができる。例えば、コミュニケーションについて一部の人のみに集中しているのか、全員がアクティブに関わりあっているのか、などである。さらに時系列に切り分けて表現すると、組織全体のアクティブさや偏り方を各時期の業務内容との照らし合わせることによって、業務のフェーズとコミュニケーションの行われ方がマッチしているかどうかを判断する材料としても用いることができる。また、プロジェクトなどの組織内の下位組織については、コミュニケーションの行われ方によってメンバ構成・業務内容に合わせたリーダーの組織運営の形態が可視化される。個人について焦点を合わせると、活発にコミュニケーションしているメンバは誰か、もしくはどのようなタイプのメンバか、コミュニケーションよりも個人作業を優先しているのはどのようなメンバかを知ることができる。また業務以外でも多くの他者とコミュニケーションを取っているメンバは知識創発のためのきっかけをもたらす可能性があるが、そのようなメンバは誰かを知ることができる。なお、縦軸と横軸を入れ替えて、縦軸を対面人数、横軸を対面時間としてプロットしても良い。

この場合、上記の関係付け表示は、強さを示す特徴量を一方の軸に割り当て、多様性を示す特徴量を他方の軸に割り当てた二軸構成の座標平面上に人物に対応する記号をプロットして行う表示である。

以上で述べた効果は、実際に横断プロジェクトの編成など知識労働の活性化のための試みを積極的に行っている組織において取得した実験データによって検証されたものである。結果の詳細は後述する。
＜全体システム＞
図１は、本発明の第１の実施の形態における、インタラクションデータを取得する端末から、取得したデータを表示するアプリケーションまでを含むシステム全体の構成の説明図である。

ユーザ（ＵＳ）は、クライアント（ＣＬ）を操作することによって、組織コミュニケーションに関する表示を受信する。クライアント（ＣＬ）は、ネットワーク（ＮＷ）を経由してアプリケーションサーバ（ＡＳ）に接続し、アプリケーションサーバで作成されたデータ処理結果情報（組織コミュニケーション表示）を受信し、ディスプレイ（ＣＬＷＤ）などに出力する。

アプリケーションサーバ（ＡＳ）はネットワーク（ＮＷ）を経由してセンサネットサーバ（ＳＳ）に接続し、データベース部（ＳＳＤＢ）に格納されているセンシングデータを受信する。受信した情報を処理・プロットすることによって、画像を作成する。

センサネットサーバ（ＳＳ）は、ネットワーク（ＮＷ）を経由して基地局（ＧＷ）に接続し、センシングデータを受信する。基地局（ＧＷ）は、ネットワーク（ＮＷ）を経由してセンサネットサーバ（ＳＳ）にセンシングデータを送信する。

基地局（ＧＷ）は、送信・受信部（ＧＷＳＲ）を経由して端末（ＴＲ）からセンシングデータを受信する。

端末（ＴＲ）は、人物に装着され、センシング部（ＴＲＳＥ）によってセンシングデータを取得する。基地局（ＧＷ）が通信可能なエリア内に、端末２（ＴＲ２）から端末４（ＴＲ４）が存在する。端末２（ＴＲ２）から端末４（ＴＲ４）のそれぞれは、各人物に装着され、端末（ＴＲ）と同様、センシング部（図示省略）によってセンシングデータを取得する。端末（ＴＲ）及び端末２（ＴＲ２）から端末４（ＴＲ４）は、取得したセンシングデータを、送信・受信部（ＴＲＳＲ）を用いて基地局（ＧＷ）に送信する。端末（ＴＲ）及び端末２（ＴＲ２）から端末４（ＴＲ４）によって送信されたセンシングデータには、そのデータを取得した端末（ＴＲ）及び端末２（ＴＲ２）から端末４（ＴＲ４）を識別する情報が含まれる。
＜端末＞
端末（ＴＲ）は小型端末であり、センシングの対象となる人物によって装着される。以下、端末（ＴＲ）の構成を説明する。図１には、さらに、端末２（ＴＲ２）から端末４（ＴＲ４）までの３個の端末が図示されている。これらの端末に関する説明は端末（ＴＲ）と同様であるため以降省略する。よって以下の説明は、端末（ＴＲ）を端末２（ＴＲ２）から端末４（ＴＲ４）までの任意のものに置き換えても成立する。なお、同様の端末が任意の数存在する場合にも、本発明を適用することができる。

端末（ＴＲ）には赤外線送信器（ＴＲＩＳ）と赤外線受信器（ＴＲＩＲ）が搭載されている。これらを用い、端末（ＴＲ）間で赤外線をやり取りすることによって、その端末（ＴＲ）が他の端末（ＴＲ）と対面したか否かが検出される。このため、端末（ＴＲ）は、人物の正面部に装着されることが望ましい。例えば、端末（ＴＲ）を名札型にし、紐によって人物の首からぶら下げてもよい。端末（ＴＲ）が人物の正面部に装着された場合、端末（ＴＲ）が他の端末（ＴＲ）と対面したことは、それらの端末（ＴＲ）を装着した人物が対面したことを意味する。

なお、以下、端末（ＴＲ）が赤外線信号をやり取りすることによって、その端末（ＴＲ）が他の端末（ＴＲ）と対面したか否かを判別する例を記載する。しかし実際には、赤外線信号以外の無線信号をやり取りすることによって対面の有無が判別されてもよい。

また端末（ＴＲ）は、送信・受信部（ＴＲＳＲ）、センシング部（ＴＲＳＥ）、入出力部（ＴＲＩＯ）、制御部（ＴＲＣＯ）、記録部（ＴＲＭＥ）によって構成されており、センシング部（ＴＲＳＥ）にてセンシングされたデータを送信・受信部（ＴＲＳＲ）を介して基地局（ＧＷ）に送信する。

送信・受信部（ＴＲＳＲ）は、基地局（ＧＷ）との間でデータを送信及び受信する。例えば、送信・受信部（ＴＲＳＲ）は、基地局（ＧＷ）から送られてきた制御コマンドに応じてセンシングデータ送信してもよいし、定期的にセンシングデータを送信してもよいし、センシングデータを取得した時に直ちにそのセンシングデータを送信してもよい。さらに、送信・受信部（ＴＲＳＲ）は、基地局（ＧＷ）から送られる制御コマンドを受信してもよい。受信した制御コマンドに従って、端末（ＴＲ）に関する制御情報の変更、又は、入出力部（ＴＲＩＯ）内の出力デバイスへの出力が実行される。また、送信・受信部（ＴＲＳＲ）は、入出力部（ＴＲＩＯ）内の入力デバイスによって選択された事項を、制御コマンドとして基地局（ＧＷ）へ送信する。

センシング部（ＴＲＳＥ）は、端末（ＴＲ）の状態を示す物理量をセンシングする。具体的には、センシング部（ＴＲＳＥ）は、種々の物理量をセンシングする一つ以上のセンサを備える。例えば、センシング部（ＴＲＳＥ）は、センシングに用いるセンサとして、赤外線送信器（ＴＲＩＳ）、赤外線受信器（ＴＲＩＲ）、温度センサ（ＴＲＴＥ）、マイクロホン（ＴＲＭＩ）、加速度センサ（ＴＲＡＣ）及び照度センサ（ＴＲＩＬ）を備える。

赤外線受信器（ＴＲＩＲ）は、他の端末（ＴＲ）の赤外線送信器（ＴＲＩＳ）から送信された赤外線信号をセンシングする。後述するように、センシングされた赤外線の情報は、端末（ＴＲ）が他の端末（ＴＲ）と対面したか否かを判定するために使用される。

加速度センサ（ＴＲＡＣ）は、Ｘ、Ｙ及びＺ軸方向の加速度をセンシングする。後述するように、センシングされた加速度の情報は、端末（ＴＲ）を装着した人物の動作の激しさや行動（例えば、歩行又は静止等）を判断するために使用される。

マイクロホン（ＴＲＭＩ）は、音声をセンシングする。センシングされた音声の情報は、例えば、端末（ＴＲ）を装着した人物が会話しているか否かを判別するために使用されてもよい。

温度センサ（ＴＲＴＥ）及び照度センサ（ＴＲＩＬ）は、それぞれ、温度及び照度をセンシングする。センシングされた温度及び照度の情報は、例えば、端末（ＴＲ）が置かれている環境を判断するために使用されてもよい。

センシング部（ＴＲＳＥ）は、上記のセンサの任意の一つ以上を備えてもよいし、他の種類のセンサを備えてもよい。さらに、センシング部（ＴＲＳＥ）は、外部入力（ＴＲＯＵ）を用いることによって、新たにセンサを追加することもできる。

なお、既に説明したように、端末（ＴＲ）は、赤外線信号以外の無線信号をやり取りすることによって対面の有無を判別してもよい。その場合、センシング部（ＴＲＳＥ）は、赤外線センサ（ＴＲＩＲ）以外の無線信号受信機を備えてもよい。あるいは、外部入力（ＴＲＯＵ）に赤外線センサ（ＴＲＩＲ）以外の無線信号受信機が接続されてもよい。

入出力部（ＴＲＩＯ）は、ボタン等の入力デバイスと、液晶ディスプレイ等の出力デバイスとを備え、対象となる人物が所望する情報の取得及びセンシングデータの表示を行う。入出力部（ＴＲＩＯ）として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。

制御部（ＴＲＣＯ）は、ＣＰＵ（図示省略）を備える。ＣＰＵが記録部（ＴＲＭＥ）に格納されているプログラムを実行することによって、センサ情報の取得タイミング、センサ情報の解析、及び、基地局（ＧＷ）への送受信のタイミングが制御される。

記録部（ＴＲＭＥ）は、ハードディスク、メモリ又はＳＤカード等の外部記録装置を備え、プログラム及びセンシングデータを格納する。さらに、記録部（ＴＲＭＥ）は、データ形式（ＴＲＤＦＩ）及び内部情報部（ＴＲＩＮ）を含む。

データ形式（ＴＲＤＦＩ）は、各センサから取得したデータ及び時刻情報を送信する際に、それらのデータをまとめる形式を指定する。

内部情報部（ＴＲＩＮ）は、端末（ＴＲ）に関する情報を格納する。端末（ＴＲ）に関する情報は、例えば、バッテリ残量（ＴＲＢＡ）、時計（ＴＲＴＩ）（すなわち時刻情報）及び端末情報（ＴＲＴＲ）である。

バッテリ残量（ＴＲＢＡ）には、端末（ＴＲ）の電源の残量が記録される。時計（ＴＲＴＩ）には、端末（ＴＲ）が内蔵するタイマで計測された現在の時刻が格納される。現在の時刻は、定期的に基地局（ＧＷ）から送信されたものに基づいて修正される。端末情報（ＴＲＴＲ）は、端末（ＴＲ）を識別するために使用される端末固有の情報であり、固有ＩＤとも呼ばれる。

基地局（ＧＷ）の時刻を端末（ＴＲ）の時刻として定期的に修正することによって、複数の端末（ＴＲ）間で時刻が同期される。これによって、異なる端末から得られたデータを時刻に基づいて整列させ、照らし合わせることが可能になる。コミュニケーションは必ず複数のメンバによって行われるため、双方の視点からデータを分析するためには時刻を同期させることは必須となる。なお、時刻修正は基地局（ＧＷ）をトリガとするのではなく、センサネットサーバ（ＳＳ）がトリガとなって基地局（ＧＷ）を介して端末（ＴＲ）に時刻を送信してもよい。
＜基地局＞
基地局（ＧＷ）は、情報を取得したいエリアに設置され、そのエリア内にある端末（ＴＲ）から無線によって送信されてくるセンシングデータを受信し、受信したセンシングデータをネットワーク（ＮＷ）を介してセンサネットサーバ（ＳＳ）へ送信する。基地局（ＧＷ）は、送信・受信部（ＧＷＳＲ）、制御部（ＧＷＣＯ）、入出力部（ＧＷＩＯ）、記録部（ＧＷＭＥ）及び内部情報部（ＧＷＩＮ）を備える。

図１には、さらに、基地局２（ＧＷ２）から基地局３（ＧＷ３）までの２個の基地局が図示されている。これらの基地局に関する説明は基地局（ＧＷ）と同様であるため以降省略する。よって以下の説明は、基地局（ＧＷ）を基地局２（ＧＷ２）から基地局４（ＧＷ４）までの任意のものに置き換えても成立する。なお、同様の基地局が任意の数存在する場合にも、本発明を適用することができる。いずれの基地局も、無線の到達可能圏内に存在する０から複数個の端末（ＴＲ）とコネクションを確立し、データのやり取りを行う。

送信・受信部（ＧＷＳＲ）は、端末（ＴＲ）との間でデータを送信及び受信する。例えば、送信・受信部（ＧＷＳＲ）は、端末（ＴＲ）に対して制御コマンドを送信してもよいし、定期的にセンシングデータを端末（ＴＲ）から受信してもよいし、端末（ＴＲ）がセンシングデータを受信したら直ちに端末（ＴＲ）からそのセンシングデータを受信してもよい。さらに、送信・受信部（ＧＷＳＲ）は、端末（ＴＲ）から送られてきた制御コマンドに従って、センサネットサーバ（ＳＳ）へ要求を送信し、その要求に応じてセンサネットサーバ（ＳＳ）から取得したデータを端末（ＴＲ）へ送信してもよい。また、送信・受信部（ＧＷＳＲ）は、入出力部（ＧＷＩＯ）における入力デバイスによって選択された事項を、制御コマンドとして端末（ＴＲ）やセンサネットサーバ（ＳＳ）に送信してもよい。逆に、送信・受信部（ＧＷＳＲ）は、センサネットサーバ（ＳＳ）又は端末（ＴＲ）から送られてきた制御コマンドを受信してもよい。受信した制御コマンドに従って出力デバイスの表示が変更される。

制御部（ＧＷＣＯ）は、ＣＰＵ（図示省略）を備える。ＣＰＵが記録部（ＧＷＭＥ）に格納されているプログラムを実行することによって、センサ情報の取得タイミング、センサ情報の解析、及び、端末（ＴＲ）又はセンサネットサーバ（ＳＳ）への送受信のタイミングが制御される。

入出力部（ＧＷＩＯ）は、ボタン又はキーボード等の入力デバイスと、液晶ディスプレイ等の出力デバイスとを備え、対象となるエリア内の状況等の情報及びセンシングデータを表示する。入出力部（ＧＷＩＯ）として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。

記録部（ＧＷＭＥ）は、ハードディスク、メモリ又はＳＤカード等の外部記録装置を備え、プログラム及びセンシングデータを格納する。さらに、記録部（ＧＷＭＥ）は、データ形式（ＧＷＤＦＩ）及び内部情報部（ＧＷＩＮ）を含む。

データ形式（ＧＷＤＦＩ）は、端末（ＴＲ）から受信したデータ及び時刻情報の形式であり、この形式に基づいてデータが各要素に判別される。

内部情報部（ＧＷＩＮ）は、基地局（ＧＷ）に関する情報を格納する。基地局（ＧＷ）に関する情報は、例えば、時計（ＧＷＴＩ）（すなわち時刻情報）、及び、基地局固有の情報である基地局情報（ＧＷＢＡ）である。
＜ネットワーク＞
ネットワーク（ＮＷ）は、基地局（ＧＷ）、センサネットサーバ（ＳＳ）、アプリケーションサーバ（ＡＳ）及びクライアント（ＣＬ）を接続するネットワークである。ネットワーク（ＮＷ）は、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ）又はその他の任意のネットワークであってよい。
＜センサネットサーバ＞
センサネットサーバ（ＳＳ）は、基地局（ＧＷ）から送られてくるセンシングデータを格納し、また、アプリケーションサーバ（ＡＳ）からの要求に基づいてセンシングデータを送信する。また、センサネットサーバ（ＳＳ）は、基地局（ＧＷ）からの制御コマンドを受信し、その制御コマンドによって得られた結果を基地局（ＧＷ）に送信する。

センサネットサーバ（ＳＳ）は、データベース部（ＳＳＤＢ）、制御部（ＳＳＣＯ）、送信・受信部（ＳＳＳＲ）、入出力部（ＳＳＩＯ）、記録部（ＳＳＭＥ）を備える。

データベース部（ＳＳＤＢ）は、端末（ＴＲ）から基地局（ＧＷ）を介して送られてきたセンシングデータを格納する。さらに、データベース部（ＳＳＤＢ）は、基地局（ＧＷ）からの制御コマンドに対する対処方法を格納する。データベース部（ＳＳＤＢ）は、後述する記録部（ＳＳＭＥ）が備えるハードディスク（図示省略）等に格納されてもよい。

制御部（ＳＳＣＯ）は、ＣＰＵ（図示省略）を備える。ＣＰＵが記録部（ＳＳＭＥ）に格納されているプログラムを実行することによって、データベース部（ＳＳＤＢ）の管理、及び、アプリケーションサーバ（ＡＳ）及び基地局（ＧＷ）から送信される情報の処理を行う。

送信・受信部（ＳＳＳＲ）は、基地局（ＧＷ）及びアプリケーションサーバ（ＡＳ）へのデータの送信、及び、それらからのデータの受信を行う。具体的には、送信・受信部（ＳＳＳＲ）は、基地局（ＴＲ）から送られてきたセンシングデータを受信し、アプリケーションサーバ（ＡＳ）へセンシングデータを送信する。また、送信・受信部（ＳＳＳＲ）は、基地局（ＧＷ）から制御コマンドを受信した場合、データベース部（ＳＳＤＢ）から選択した結果を基地局（ＧＷ）に送信する。

入出力部（ＳＳＩＯ）は、ボタン又はキーボード等の入力デバイスと、液晶ディスプレイ等の出力デバイスとを備え、対象となるエリア内の状況等の情報及びセンシングデータを表示する。入出力部（ＳＳＩＯ）として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。

記録部（ＳＳＭＥ）は、ハードディスク、メモリ又はＳＤカード等の外部記録装置を備え、プログラム及びセンシングデータを格納する。さらに、記録部（ＳＳＭＥ）は、データ形式（ＳＳＤＦＩ）を含む。

データ形式（ＳＳＤＦＩ）は、基地局（ＧＷ）から受信したデータ及び時刻情報の形式であり、この形式に基づいてデータが各要素に判別され、データベース部（ＳＳＤＢ）の適切な要素に振り分けられる。
＜アプリケーションサーバ＞
アプリケーションサーバ（ＡＳ）は、センサネットサーバ（ＳＳ）に格納されているセンシングデータの処理を行う計算機である。アプリケーションサーバ（ＡＳ）は、データ処理部（ＡＳＤＰ）、制御部（ＡＳＣＯ）、記録部（ＡＳＭＥ）、送信・受信部（ＡＳＳＲ）、及び入出力部（ＡＳＩＯ）を備える。なお、アプリケーションサーバ（ＡＳ）は、クライアント（ＣＬ）が兼ねても、センサネットサーバ（ＳＳ）が兼ねてもよい。

データ処理部（ＡＳＤＰ）は、センシングデータを処理し、組織コミュニケーションを表現するための画像を作成する。データ処理部（ＡＳＤＰ）は、対面マトリクス計算（ＡＰＩＭ）、対面人数・時間計算（ＡＰＩＣ）、データプロット（ＡＰＩＰ）を実行する。変形例として他の処理が追加される場合、それらの処理は、データ処理部（ＡＳＤＰ）によって実行される。データ処理部（ＡＳＤＰ）は、処理したデータを記録部（ＡＳＭＥ）に一時的に格納する。

データ処理部（ＡＳＤＰ）は、例えば、記録部（ＡＳＭＥ）に格納されたプログラムを制御部（ＡＳＣＯ）のＣＰＵが実行することによって実現されてもよい。その場合、対面マトリクス計算（ＡＰＩＭ）、対面人数・時間計算（ＡＰＩＣ）、データプロット（ＡＰＩＰ）などのデータ処理部内の処理は、実際には、制御部（ＡＳＣＯ）のＣＰＵによって実行される。

制御部（ＡＳＣＯ）は、ＣＰＵ（図示省略）を備える。ＣＰＵが記録部（ＡＳＭＥ）に格納されているプログラムを実行し、センサネットサーバ（ＳＳ）へのデータ取得依頼、データ処理の実行、及び、実行結果の管理等の処理を行う。

記録部（ＡＳＭＥ）は、ハードディスク、メモリ又はＳＤカード等の外部記録装置を備え、プログラム、センシングデータ、及び、データ処理部（ＡＳＤＰ）による処理結果を格納する。さらに、記録部（ＡＳＭＥ）は、初期条件設定（ＡＳＳＩＩ）及び結合テーブル（ＡＳＣＮＴ）等、処理のために一時的に保管すべき値を記録する。これらの値は、データの種類及び処理の種類に応じて随時追加・削除・変更することができる。また、ノードを装着しているユーザ（ＵＳ）とノードの固有ＩＤとの対応を示すユーザＩＤ対応表（ＡＳＵＩＴ）や、プロジェクトとそれに属するユーザ（メンバ）との対応を示すプロジェクト対応表（ＡＳＰＵＴ）を記録しておく。ユーザＩＤ対応表（ＡＳＵＩＴ）やプロジェクト対応表（ＡＳＰＵＴ）はセンサネットサーバ（ＳＳ）内の記録部（ＳＳＭＥ）やクライアント（ＣＬ）内の記録部（ＣＬＭＥ）に記録してもよい。また、対面マトリクス（ＡＳＴＭＸ）は、対面マトリクス計算（ＡＰＩＭ）によって作成される配列である。ユーザＩＤ対応表（ＡＳＵＩＴ）の例は図５に、プロジェクト対応表（ＡＳＰＵＴ）の例は図６に、対面マトリクス（ＡＳＴＭＸ）の例は図１１にそれぞれ示している。

ユーザＩＤ対応表（ＡＳＵＩＴ）やプロジェクト対応表（ＡＳＰＵＴ）はプログラム内に直接記述しても良いが、対応表のみを分けて保管することで、ユーザの変更、ノードＩＤの変更、プロジェクトの組織構成の変更などに柔軟に対応することができる。

送信・受信部（ＡＳＳＲ）は、センサネットサーバ（ＳＳ）からセンシングデータを受信し、クライアント（ＣＬ）からの処理結果要求に基づくデータ送信を行う。

入出力部（ＡＳＩＯ）は、ボタン又はキーボード等の入力デバイスと、液晶ディスプレイ等の出力デバイスとを備え、対象となるエリア内の状況等の情報及びセンシングデータを表示することができる。入出力部（ＡＳＩＯ）として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。
＜クライアント＞
クライアント（ＣＬ）は、ユーザからの依頼に基づいてデータ処理要求をアプリケーションサーバ（ＡＳ）に送信し、その処理結果をアプリケーションサーバ（ＡＳ）から受信し、受信した処理結果を画面に表示する。クライアント（ＣＬ）は、アプリケーション部（ＣＬＡＰ）、送信・受信部（ＣＬＳＲ）、入出力部（ＣＬＩＯ）、記録部（ＣＬＭＥ）及び制御部（ＣＬＣＯ）を備える。

制御部（ＣＬＣＯ）は、記録部（ＣＬＭＥ）に格納されているプログラムを実行するＣＰＵ（図示省略）を備える。制御部（ＣＬＣＯ）は、ユーザからの要求に基づいて、アプリケーションサーバ（ＡＳ）から受信した画像の大きさなどを調整し、作成された画面を入出力部（ＣＬＩＯ）のディスプレイ（ＣＬＷＤ）などの出力デバイスに表示することによってユーザに提供する。例えば、記録部（ＣＬＭＥ）に格納されたプログラムを制御部（ＣＬＣＯ）のＣＰＵが実行することによって実現されてもよい。

送信・受信部（ＣＬＳＲ）は、ユーザが指定した範囲のセンシングデータの処理結果を送信させる要求をアプリケーションサーバ（ＡＳ）に対して送信し、その処理結果（すなわち、アプリケーションサーバ（ＡＳ）によって処理された画像またはセンシングデータ）を受信する。

入出力部（ＣＬＩＯ）は、マウス（ＣＬＩＭ）やキーボード（ＣＬＩＫ）などの入力デバイスと、ディスプレイ（ＣＬＷＤ）などの出力デバイスとを備え、対象となるエリア内の状況等の情報及びセンシングデータを表示する。入出力部（ＣＬＩＯ）として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。またそれ以外の入出力装置を接続するために外部入出力（ＣＬＯＵ）が用いられてもよい。

記録部（ＣＬＭＥ）は、ハードディスク、メモリ又はＳＤカード等の外部記録装置を備え、メインプログラム、センシングデータ、及び、アプリケーションサーバから送られてきた画像や制御部（ＣＬＣＯ）による処理結果を格納する。また、記録部（ＣＬＭＥ）は、初期条件設定（ＣＬＩＳＩ）に、画面の大きさなどユーザによって設定された条件を記録する。
＜全体シーケンス図＞
図２は、本発明の第１の実施の形態において、センシングデータが端末（ＴＲ）からユーザ（ＵＳ）に提供されるまでの処理を示すシーケンス図である。

端末（ＴＲ）で取得されたセンシングデータは、定期的に基地局（ＧＷ）を介してセンサネットサーバ（ＳＳ）に届けられ、データベース（ＳＳＤＢ）に保管される。この流れが、図２のセンシングデータの取得（ＴＲＧＥ）からデータ格納（ＳＳＰＵ）までにあたる。また、時刻修正（ＧＷＴＭ）〜時刻修正（ＴＲＴＭ）は、センシングデータの取得の流れとは別の周期で実行される。

一方、ユーザの要求があった場合には、クライアント（ＣＬ）からアプリケーションサーバ（ＡＳ）を通してセンサネットサーバ（ＳＳ）に依頼を送信し、取得したデータからアプリケーションサーバ（ＡＳ）で画像を作成し、クライアント（ＣＬ）に戻すという流れを辿る。この流れは、図２のアプリケーション起動（ＵＳＳＴ）からアプリケーション終了（ＵＳＥＮ）までにあたる。

センシングデータの取得（ＴＲＧＥ）については、サンプリング周期、取得時間などセンシングデータを取得するために必要な情報が記録部（ＴＲＭＥ）に記載されており、この情報を基にして端末（ＴＲ）内のセンシング部（ＴＲＳＥ）がセンシングを行う。また、端末（ＴＲ）は一定の周期で端末（ＴＲ）自身を識別する情報を載せた赤外線を送信し続ける（ＴＲＩＳ）。端末（ＴＲ）が別の端末２（ＴＲ２）と対面した場合には、つまり端末（ＴＲ）と端末２（ＴＲ２）のユーザ同士が対面した場合には、端末（ＴＲ）は、端末２が送信した赤外線（ＴＲＩＳ２）を受信する（ＴＲＩＲ）。また対称的に、端末（ＴＲ）が送信した赤外線は、端末２（ＴＲ２）で受信される（ＴＲＩＲ２）。端末同士の角度など、条件によっては一方しか受信されない場合もありうる。さらに、端末（ＴＲ）は、センシングされたデータを記録部（ＴＲＭＥ）に記録する。

時刻添付（ＴＲＡＤ）において、端末（ＴＲ）は、センシングしたデータの取得時刻として、時計（ＴＲＴＩ）の時刻をセンシングデータと共に記録する。データ形式（ＴＲＤＦ）において、端末（ＴＲ）は、記録部（ＴＲＭＥ）内のデータ形式（ＴＲＤＦＩ）を参照し送信用データ形式にデータを統一する。

データ送信（ＴＲＳＥ）において、端末（ＴＲ）は、センシングデータの取得（ＴＲＧＥ）によってセンシングしたセンシングデータを、送信・受信部（ＴＲＳＲ）を経由し基地局（ＧＷ）に送信する。より詳細には、端末（ＴＲ）は、記録部（ＴＲＭＥ）に記録されているセンシングデータを記録部（ＴＲＭＥ）に格納されている基地局（ＴＲ）用の送信フォーマットを用いて制御部（ＴＲＣＯ）によって変換する。そして、端末（ＴＲ）は、送信フォーマットに変換されたセンシングデータを送信・受信部（ＴＲＳＲ）を経由して基地局（ＧＷ）に送信する。

データ受信（ＧＷＲＥ）において、基地局（ＧＷ）は、端末（ＴＲ）から基地局（ＧＷ）用の送信フォーマットで送信・受信部（ＴＲＳＲ）から送信されたセンシングデータを送信・受信部（ＧＷＳＲ）によって受信する。受信したセンシングデータは記録部（ＧＷＭＥ）に格納される。

データ形式判断（ＧＷＤＦ）において、基地局（ＧＷ）は、取得したデータの形式を記録部（ＧＷＭＥ）のデータ形式（ＧＷＤＦＩ）と比較してデータの形式を判断する。さらに、基地局（ＧＷ）は、基地局情報付与（ＧＷＡＤ）において、データ形式（ＧＷＤＦＩ）が示す適切な位置に基地局情報（ＧＷＢＡ）を追加する。

データ送信（ＧＷＳＥ）において、基地局（ＧＷ）は、記録部（ＧＷＭＥ）に格納されたセンシングデータを、送信・受信部（ＧＷＳＲ）を経由してセンサネットサーバ（ＳＳ）に送信する。より詳細には、基地局（ＧＷ）の制御部（ＧＷＣＯ）は、記録部（ＧＷＭＥ）に記録されているセンシングデータを記録部（ＧＷＭＥ）に格納されているセンサネットサーバ（ＳＳ）用の送信フォーマットに変換する。そして、基地局（ＧＷ）は、送信フォーマットに変換されたセンシングデータを送信・受信部（ＧＷＳＲ）を経由してセンサネットサーバ（ＳＳ）に送信する。

データ受信（ＳＳＲＥ）において、センサネットサーバ（ＳＳ）の送信・受信部（ＳＳＳＲ）は、基地局（ＧＷ）の送信・受信部（ＧＷＳＲ）からセンサネットサーバ（ＳＳ）用の送信フォーマットで送信されたセンシングデータを受信する。受信したセンシングデータは記録部（ＳＳＭＥ）に格納される。

データ形式判断（ＳＳＤＦ）において、センサネットサーバ（ＳＳ）は、取得したデータの形式を記録部（ＳＳＭＥ）のデータ形式（ＳＳＤＦＩ）と比較することによって、データの形式を判断する。さらに、データ分類（ＳＳＤＥ）において、センサネットサーバ（ＳＳ）は、各データを要素ごとに切り分ける。

データ格納（ＳＳＰＵ）において、センサネットサーバ（ＳＳ）の制御部（ＳＳＣＯ）は、センシングデータをデータベース部（ＳＳＤＢ）のフォーマットに変換する。変換されたセンシングデータは、データベース部（ＳＳＤＢ）に格納される。データベース部（ＳＳＤＢ）への格納方法は、後で検索する際に有効なクエリとして用いることができるようにすることが好ましい。有効なクエリとしては、例えば、センシングデータ名、時刻、端末固有ＩＤ及び基地局固有ＩＤがある。

センシングデータの取得（ＴＲＧＥ）からデータ格納（ＳＳＰＵ）までの一連の処理は定期的に行なわれる。

時刻修正（ＧＷＴＭ）は、基地局（ＧＷ）の時計（ＧＷＴＡ）の時刻を合わせるために行われる。基地局（ＧＷ）は、現在の時刻をネットワーク（ＮＷ）網にあるＮＴＰサーバ（図示省略）から取得する。時刻修正（ＧＷＴＭ）の処理は定期的に行なわれる。

時刻修正依頼（ＧＷＴＲ）は、端末（ＴＲ）の時刻を合わせるために、基地局（ＧＷ）から端末（ＴＲ）へ依頼される。時刻修正（ＴＲＴＭ）は、時刻修正依頼（ＧＷＴＲ）によって基地局（ＧＷ）から送信された時刻に基づいて、時計（ＴＲＴＩ）の時刻を修正する処理である。時刻修正依頼（ＧＷＴＲ）から時刻修正（ＴＲＴＭ）までの処理は定期的に行なわれる。

次に、端末（ＴＲ）のセンシング部（ＴＲＳＥ）におけるセンシングの間隔と、送信・受信部（ＴＲＳＲ）における送信のタイミングについて、本実施の形態の場合の例の一つを挙げて述べる。

端末（ＴＲ）は、三軸加速度センサ及び赤外線送受信器を備え、これらが全て１０秒サイクルでセンシング及びデータ送信を行う。

加速度センサは、１０秒中の始めの２秒間でＸ、Ｙ、Ｚ軸方向各１００回のセンシングを行う。センシングの結果として取得された加速度情報は、端末（ＴＲ）の状態を示す。端末（ＴＲ）が人物に装着されている場合、取得された加速度情報は、端末（ＴＲ）を装着した人物の活動の状態（例えば、その人物が静止しているか否か）を示す。

赤外線送信器は、１０秒間あたり６回ずつ端末（ＴＲ）の正面に向かって赤外線信号を送信する。送信される赤外線信号には、端末情報（ＴＲＴＲ）、すなわち、自端末（ＴＲ）のＩＤ（識別子）を示す信号が含まれる。

二つの端末（ＴＲ）が向かい合ったとき、つまり二人の人物が対面したときには、一方の端末（ＴＲ）の受信器が、もう一方の端末（ＴＲ）のＩＤを受信する。すなわち、一つの端末（ＴＲ）が他の端末（ＴＲ）のＩＤを受信したとき、それらの二つの端末が対面していることを意味する。つまり、それぞれの端末（ＴＲ）が人物の前面に装着されている場合、二つの端末（ＴＲ）が対面していることは、それらを装着した二人の人物が対面していることを意味する。赤外線の受信器側は、常に待機状態となっており、１０秒間のうちに受信したＩＤと、受信した回数を記録する。

そして、端末（ＴＲ）は、これらのセンシングデータにタイムスタンプ及び端末情報（ＴＲＴＲ）つまり自身の固有ＩＤを付与した後、それらのセンシングデータを基地局（ＧＷ）に一括して無線送信する。結局、上記の例において、端末（ＴＲ）から送信されるセンシングデータには、その端末の加速度を示す情報と、その端末の固有ＩＤと、その端末が他の端末と対面したことを示す情報と、それらの情報に対応付けられた時刻情報とが含まれる。これらのセンシングデータが、人物の交流を示すインタラクションデータとして利用される。

しかし、上記は一例に過ぎず、センシング間隔及び送信タイミングは、任意に設定することができる。

アプリケーション起動（ＵＳＳＴ）は、ユーザ（ＵＳ）によるクライアント（ＣＬ）のアプリケーションの起動である。

初期条件設定（ＣＬＩＳ）において、クライアント（ＣＬ）は、図の提示に必要な情報を設定する。ユーザ（ＵＳ）のボタン選択によって、表示の対象となるデータの時刻及び端末情報、表示方法の条件設定などを取得する。ここで設定した条件は、記録部（ＣＬＭＥ）に格納される。

データ依頼（ＣＬＳＱ）において、クライアント（ＣＬ）は、初期条件設定（ＣＬＩＳ）に基づき、アプリケーションサーバ（ＡＳ）に対して、データもしくは画像の依頼を行う。記録部（ＣＬＭＥ）には、検索対象のアプリケーションサーバ（ＡＳ）の名称、アドレス等、センシングデータを取得するために必要な情報が格納されている。クライアント（ＣＬ）は、データの依頼コマンドを作成し、アプリケーションサーバ（ＡＳ）用の送信フォーマットに変換される。送信フォーマットに変換されたコマンドは、送信・受信部（ＣＬＳＲ）を経由して、アプリケーションサーバ（ＡＳ）に送信される。

アプリーションサーバ（ＡＳ）は、データ依頼（ＡＳＲＱ）において、クライアント（ＣＬ）からの依頼を受信し、さらにセンサネットサーバ（ＳＳ）に対して取得すべきデータの時刻の範囲及びデータ取得対象である端末の固有ＩＤを送信しセンシングデータを要求する。送信される時刻及び端末の固有ＩＤは、アプリーションサーバ（ＡＳ）の記録部（ＡＳＭＥ）又はクライアント（ＣＬ）の記録部（ＣＬＭＥ）に格納されたものから自動的に設定されるものであってもよいし、クライアント（ＣＬ）の入出力部（ＣＬＩＯ）を通してユーザ（ＵＳ）が指定したものであってもよい。

データ検索（ＡＳＳＥ）において、アプリーションサーバ（ＡＳ）は、データ依頼（ＡＳＲＱ）に基づき、センサネットサーバ（ＳＳ）に対して、検索を行う。記録部（ＡＳＭＥ）には、検索対象のセンサネットサーバ（ＳＳ）の名称、アドレス、データベース名及びテーブル名等、データ信号を取得するために必要な情報が記載されている。アプリーションサーバ（ＡＳ）は、データ検索（ＡＳＳＥ）を行う際、データ依頼（ＡＳＲＱ）を通して検索内容を依頼し、データベースの情報を記録部（ＡＳＭＥ）から取得し、検索に用いるコマンドを作成する。作成されたコマンドは、制御部（ＡＳＣＯ）によって、記録部（ＡＳＭＥ）に格納されているセンサネットサーバ（ＳＳ）用の送信フォーマットに変換される。送信フォーマットに変換されたコマンドは、送信・受信部（ＡＳＳＲ）を経由してセンサネットサーバ（ＳＳ）に送信される。

センサネットサーバ（ＳＳ）内データベース（ＳＳＤＢ）は、受け取ったコマンドを実行してクエリし、アプリケーションサーバ（ＡＳ）にデータを送信する。

データ受信（ＡＳＲＥ）において、アプリーションサーバ（ＡＳ）は、データ検索（ＡＳＳＥ）のコマンドに基づいて、センサネットサーバ（ＳＳ）内のデータベース部（ＳＳＤＢ）から送信されたセンシングデータを受信する。送信・受信部（ＡＳＳＲ）が受信したセンシングデータは記録部（ＡＳＭＥ）に格納される。

データ分類（ＡＳＤＥ）において、アプリーションサーバ（ＡＳ）は、取得したデータを適切な各要素に分類する。その際、時刻情報とセンシングデータは必ず関連付けたままで分類される。

ここまでの、データ依頼（ＣＬＳＱ）からデータ分類（ＡＳＤＥ）までの流れが、図３のフローチャートにおけるデータ取得（ＡＰＤＧ）に相当する。

次に、対面マトリクス作成（ＡＰＩＳ）、対面人数・対面時間のカウント（ＡＰＩＣ）、データプロット（ＡＰIＰ）のそれぞれの処理を順に行う。処理の詳細な内容は図３以降のフローチャートにて示す。これらの処理を行うプログラムは、記録部（ＡＳＭＥ）に格納されており、データ処理部（ＡＳＤＰ）によって実行し、画像が作成される。

画像は、画像送信（ＡＰＷＳ）においてクライアントに送信され、クライアントの出力デバイス、例えばディスプレイ（ＣＬＷＤ）に表示される（ＣＬＤＩ）。

最後の、アプリケーション終了（ＵＳＥＮ）はユーザ（ＵＳ）によるアプリケーションの終了である。
＜全体のフローチャート＞
図３は、本発明の第１の実施の形態において、アプリケーションの立ち上げから表示画面がユーザ（ＵＳ）に提供されるまでの大まかな処理の流れを示すフローチャートである。

表示画面を作成するために、開始（ＡＰＳＴ）から、初期条件設定（ＡＰＩＳ）、データ取得（ＡＰＤＧ）、対面マトリクス作成（ＡＰＩＭ）、対面人数・対面時間のカウント（ＡＰＩＣ）、データプロット（ＡＰＩＰ）、画面表示（ＡＰＷＯ）の各手順が順次実行され、終了（ＡＰＥＮ）となる。各手順について、順に詳しく述べる。
＜初期条件設定のフローチャート＞
初期条件設定（ＡＰＩＳ）の中での手順を図４のフローチャートに示す。

初期条件設定（ＡＰＩＳ）は、開始（ＩＳＳＴ）から、ユーザＩＤ対応表読み込み（ＩＳＵＩ）、プロジェクト対応表読み込み（ＩＳＰＵ）、表示期間の設定（ＩＳＲＴ）、プロットするメンバの設定（ＩＳＲＭ）、役職の区別を設定（ＩＳＳＭ）、特定プロジェクトの強調の有無を設定（ＩＳＰＯ）の手順を行い、また特定プロジェクトを強調する（ＩＳＰＹ）場合には強調するプロジェクトを設定（ＩＳＰＳ）する。

ユーザＩＤ対応表読み込み（ＩＳＵＩ）では、例として図５のような、ノードの固有ＩＤ（ＡＳＵＩＴ３）とそれを装着しているユーザ名（ＡＳＵＩＴ２）とを一対一で対応づけているユーザＩＤ対応表（ＡＳＵＩＴ）を読み込む。ユーザには今後処理するときに用いるユーザ番号（ＡＳＵＩＴ１）を振っておく。必要があれば、役職（ＡＳＵＩＴ４）を示す列も用意する。図５の例の場合では、部長を２、課長を１、一般社員を０として数値化して表現している。役職の区別の仕方は自由に設定して良い。組織のメンバや職位などに変更があった場合には、ユーザＩＤ対応表（ＡＳＵＩＴ）のみを書き換えれば対応できる。

プロジェクト対応表読み込み（ＩＳＰＵ）では、例として図６のような、組織内に存在するプロジェクトの名前と、それに属するメンバとを対応付けるためのプロジェクト対応表（ＡＳＰＵＴ）を読み込む。なお、部や課という組織全体に対するグループやユニットなどの固定した組織、またプロジェクトなどの柔軟に変化する組織など、全ての下位組織を指して以降ではプロジェクトと統一して呼ぶものとする。プロジェクト対応表（ＡＳＰＵＴ）は、誰がどのプロジェクトに属しているか、が明確であれば良いのでユーザＩＤ対応表（ＡＳＵＩＴ）に一体化して、各一行で表されているユーザに対して属するプロジェクト名を書く列が存在するという形式でも良い。また、プロジェクトによって表示を区分する必要がなければプロジェクト対応表（ＡＳＰＵＴ）は必要ない。図６のプロジェクト対応表（ＡＳＰＵＴ）では、一人のメンバが複数のプロジェクトに掛け持ちして属することにも対応しているが、必ずしも対応していなくてもよい。プロジェクト対応表（ＡＳＰＵＴ）には、プロジェクト名（ＡＳＰＵＴ２）と所属ユーザ番号(ＡＳＰＵＴ３)の項目がある。また各プロジェクトには、今後処理するときに用いるプロジェクト番号（ＡＳＰＵＴ１）を振っておく。所属ユーザ番号(ＡＳＰＵＴ３)の項目の数字は、ユーザＩＤ対応表（ＡＳＵＩＴ）におけるユーザ番号（ＡＳＵＩＴ１）に対応している。プロジェクト対応表（ＡＳＰＵＴ）をプログラム本体とは別に用意することで、プロジェクトのメンバ構成に変更があった場合には、このプロジェクト対応表（ＡＳＰＵＴ）のみを書き換えることで容易に対応できる。しかしプログラム本体に直接記述しても良い。

表示期間の設定（ＩＳＲＴ）、プロットするメンバの設定（ＩＳＲＭ）、役職の区別を設定（ＩＳＳＭ）、特定プロジェクトの強調の有無を設定（ＩＳＰＯ）では、例えば図７のような初期条件設定ウィンドウ（ＡＳＩＳＷＤ）をクライアント（ＣＬ）のディスプレイ（ＣＬＷＤ）などの出力装置に表示し、マウス（ＣＬＩＭ）やキーボード（ＣＬＩＫ）などの入力装置を用いてユーザ（ＵＳ）に入力させることで、各々の設定を行う。初期条件設定ウィンドウ（ＡＳＩＳＷＤ）は、始めからクライアント（ＣＬ）内に保管しておいても良い。

表示期間の設定（ＩＳＲＴ）は、ウィンドウの表示期間選択（ＡＳＩＳＰＴ）のテキストボックス（ＰＴ０１〜０３、ＰＴ１１〜１３）にて日付を設定し、端末（ＴＲ）で取得された時刻がこの範囲内にあるデータを、表示のための計算に用いるものとする。必要があれば時刻の範囲設定を追加しても良い。

プロットするメンバの設定（ＩＳＲＭ）は、ウィンドウの表示メンバ選択（ＡＳＩＳＰＭ）において行う。ウィンドウには、ユーザＩＤ対応表読み込み（ＩＳＵＩ）で読み込んだ全ユーザ名、また必要ならばノードＩＤを反映させる。ユーザ（ＵＳ）はチェックボックス（ＰＭ０１〜ＰＭ０９）にチェックを入れる、もしくは入れないことでどのメンバのデータを表示するかを設定する。直接個々のメンバを指定するのではなく、既定のグループ単位、年齢などの条件によって表示メンバをまとめて指定させても良い。

役職の区別を設定（ＩＳＳＭ）、特定プロジェクトの強調の有無を設定（ＩＳＰＯ）は、ウィンドウの表示設定（ＡＳＩＳＰＤ）において行う。役割の区別のチェックボックス（ＰＤ１）にチェックを入れた場合には、表示において役職によって四角や丸などの異なる記号でプロットされる。役職によるコミュニケーションの行い方の違いを検証したい場合に用いる。特定プロジェクトの強調のチェックボックス（ＰＤ２）にチェックを入れた場合には、表示において特定のプロジェクトに属するメンバに対応する記号が、塗りつぶすなどして他の記号よりも強調して表示される。プロジェクトごとに、どのようなコミュニケーションの行い方をしているのかを検証したい場合に用いる。

さらにチェックボックス（ＰＤ２）にチェックが入れられた場合には、図４のフローチャートにおいて特定プロジェクトを強調する（ＩＳＰＹ）がyesとなり、強調するプロジェクトの設定（ＩＳＰＳ）を行う。強調するプロジェクトの設定（ＩＳＰＳ）は、プロジェクト対応表（ＡＳＰＵＴ）から読み込んだ各プロジェクト名を反映したチェックボックス（ＰＤ２１〜ＰＤ２５）にユーザがチェックを入れることで設定される。チェックの数は1つに限定しても良いし、複数であっても良い。

表示サイズ（ＡＳＩＳＰＳ）領域では、表示される画像のサイズが設定される。本実施の形態では、画面に表示される画像が長方形であることを前提とする。画像の縦の長さがテキストボックス（ＰＳ０１）に、横の長さがテキストボックス（ＰＳ０２）に入力される。入力される数値の単位として、ピクセル又はセンチメートル等、何らかの長さの単位が指定される。

全てを入力したら最後に、表示開始ボタン（ＡＳＩＳＳＴ）をユーザ（ＵＳ）が押すことで以上の初期条件を決定とし、図３におけるデータ取得（ＡＰＤＧ）のステップに進む。
＜データ取得〜対面マトリクスのフローチャート＞
図８は、本発明の第１の実施の形態において、図３のデータ取得（ＡＰＤＧ）と対面マトリクス作成（ＡＰＩＭ）のステップの詳細を示したフローチャートである。

開始（ＤＧＳＴ）からデータ取得（ＡＰＤＧ）と対面マトリクス作成（ＡＰＩＭ）を行い、終了（ＤＧＥＮ）する。データ取得（ＡＰＤＧ）は、センサネットサーバ（ＳＳ）内のデータベース部（ＳＳＤＢ）の中から必要なデータを取得するプロセスである。

データベース部（ＳＳＤＢ）には複数のメンバの複数種類のセンシングデータが記録されているが、そのうちの赤外線送受信による対面データをまとめたテーブルの例を図９の（ａ）（ｂ）に示す。図９の（ａ）は、対面テーブル（ＳＳＤＢ＿１００２）であり、ノードＩＤが１００２である端末（ＴＲ）から取得されたデータを集めたテーブルであることを想定している。同様に、図９の（ｂ）は、対面テーブル（ＳＳＤＢ＿１００３）であり、ノードＩＤが１００３である端末（ＴＲ）から取得されたデータを集めたテーブルとする。なお、取得したノードごとにテーブルを分けなくても良く、他の加速度や温度などのデータも同じテーブルに含んでも良い。

対面テーブルには端末（ＴＲ）からデータを送信した時刻（ＤＢＴＭ）、赤外線送信側ＩＤ（ＤＢＲ１）と受信回数（ＤＢＮ１）を１０組（ＤＢＲ１〜ＤＢＲ１０、ＤＢＮ１〜ＤＢＮ１０）分格納できる。今回は１０秒間に１回データ送信を行うようにしているため、前回の送信からの１０秒間のうちにどの端末（ＴＲ）から何回赤外線を受信したかを表しているものである。１０秒間中に複数の端末（ＴＲ）と対面した場合にも、１０組まで格納できるということである。なお、組の数は自由に設定することができる。対面、つまり赤外線の受信がなかった場合にはnullとなる。また、図９では時刻はミリ秒まで表記している。時刻の形式は統一されていればどのようなものでも良い。

図８のデータ取得（ＡＰＤＧ）では、まずセンサネットサーバ（ＳＳ）のデータベース部（ＳＳＤＢ）に接続（ＤＧＣＤ）し、前述の初期条件設定（ＡＰＩＳ）で設定した表示期間（ＡＳＩＳＰＴ）と表示メンバ（ＡＳＩＳＰＭ）の条件に基づきＳＱＬコマンドを作成し、データベース（ＳＳＤＢ）から、その時刻（ＤＢＴＭ）が設定した表示期間に含まれているデータを表示すべき全メンバの対面テーブルから取得する（ＤＧＳＧ）。

対面マトリクスの作成（ＡＰＩＭ）では、表示すべきメンバから一組（二人）を選択し（ＩＭＭＳ）、その二人のデータの時刻を揃えて結合テーブルを作成する（ＩＭＡＤ）。図９（ａ）の１００２番の端末（ＴＲ）のデータと、図９（ｂ）の１００３番の端末（ＴＲ）データから作成した結合テーブルの例が図１０の結合テーブル(ＡＳＣＮＴ１００２‐１００３）である。結合テーブルの作成（ＩＭＡＤ）の際には、それぞれの対面テーブルの時刻（ＤＢＴＭ）を揃え、結合テーブルの時刻（ＣＮＴＴＭ）とする。また、図９（ｂ）の一行目（ＲＥ０１）と二行目（ＲＥ０２）の間のように、データがセンシング周期（ここでは１０秒間隔）で入っていない場合には、補完する。また、二つの対面テーブルの時刻が完全に一致していない場合には、どちらかに合わせるか、完全に１０秒刻みになる時刻を設定し、それに近いデータをそれぞれ同時刻として扱うなどして、同じ時刻とみなせる行同士を見比べる。その中で、設定した二つの端末（ＴＲ）間での対面データが少なくとも一方の対面テーブルに存在した場合には、その時刻に二人のメンバが対面したとみなし、結合テーブルの対面の有無（ＣＮＴＩＯ）の欄を１とする。そうでないときは０とする。このようにして結合テーブルを作成する。さらに、全ての時刻の対面があった回数を合計する。

対面したと判別するための基準は、赤外線受信回数が閾値以上であった場合のみとする、など別の基準を用いても良い。また、結合テーブルは合計対面回数（ＲＥｓｕｍ）が計算できれば良いので、テーブルを作成せず、時刻をそろえながら対面回数をカウントしても良い。

次に、求めた合計対面回数の値を１０倍し、対面マトリクス（ＡＳＴＭＸ）の選択した二人のメンバを示す二箇所の要素に入れる（ＩＭＣＩ）。１０倍するのは、合計対面回数１に対して１０秒間対面したとみなし、対面マトリクスの値の単位を秒にそろえる目的である。必要がなければそろえなくても良い。

図１１に対面マトリクス（ＡＳＴＭＸ）の例を示す。行と列はそれぞれユーザＩＤ対応表（ＡＳＵＩＴ）におけるユーザ番号（ＡＳＵＩＴ１）に対応している。今の場合ではノードＩＤが１００２番のユーザ番号は２、ノードＩＤが１００３番のユーザ番号は３となるため、要素（ＴＭＸ２＿３）に値を入れる。また、対面に関しては一方が対面したならもう一方も対面したと考えるのが自然であるため、対面マトリクス（ＡＳＴＭＸ）が対称行列となるように対称要素（ＴＭＸ３＿２）にも同じ値を入れる。しかし、意図がある場合には非対称行列とすることも可能である。

一組のメンバについて対面マトリクス（ＡＳＴＭＸ）の要素を埋めたら、別の一組を選択し、全ての組の処理を完了するまで繰り返す（ＩＭＡＭ）。
＜対面時間・人数のカウント＞
図１２は、本発明の第１の実施の形態において、図３の対面人数・対面時間のカウント（ＡＰＩＣ）のステップの詳細を示したフローチャートである。

開始（ＩＣＳＴ）から終了（ＩＣＥＮ）までのステップでは、メンバごとに対面時間の合計と対面人数のカウントを行う。

まずメンバを一人選択し（ＩＣＭＳ）、対面マトリクス（ＡＳＴＭＸ）においてそのメンバのユーザ番号（ＡＳＵＩＴ１）に対応する行を決める。次にその一行の対面マトリクスの値を合計する。合計したものが、図１１の対面カウント（ＡＳＴＭＣ）の対面時間（ＴＭＴＩ）となる（ＩＣＴＩ）。対面時間（ＴＭＴＩ）はつまり、そのメンバが設定した表示期間（ＡＳＩＳＰＴ）内で何らかの人物とコミュニケーションを行った合計時間であり、コミュニケーションの量だとみなせる。またさらに、その一行の対面マトリクス（ＡＳＴＭＸ）の、要素が正の値、つまり０より大きい値である要素の数をカウントし、それを図１１の対面カウント（ＡＳＴＭＣ）の対面人数（ＴＭＮＭ）とする（ＩＣＮＭ）。対面人数は、表示期間（ＡＳＩＳＰＴ）内において関わりを持った他者の数であり、そのメンバの持つ関係の多様性と捉えることができる。

なお、図１１の対面カウント（ＡＳＴＭＣ）は、対面人数（ＴＭＮＭ）と対面時間（ＴＭＴＩ）を合わせたテーブルとしている、各メンバに対応する対面人数と対面時間の値が明確になっていれば、テーブル以外の形式でも良い。

以上の対面時間の合計（ＩＣＴＩ）と対面人数のカウント（ＴＣＮＭ）の手順を、全てのメンバについて終了するまで繰り返す（ＩＣＡＭ）。
＜データプロットのフローチャート＞
図１３は、本発明の第１の実施の形態において、図３のデータプロット（ＡＰＩＰ）のステップの詳細を示したフローチャートである。

データプロット（ＡＰＩＰ）では、カウントした対面人数（ＴＭＮＭ）と対面時間（ＴＭＴＩ）をそれぞれ横軸・縦軸に取った座標上に各メンバをプロットする。このとき、初期条件設定（ＡＰＩＳ）で設定した事項に基づき、メンバごとにプロットする記号の形や塗りつぶしの有無などを決定する。

データプロットの開始（ＩＰＳＴ）後、まずグラフ領域の大きさを決める（ＩＰ１０）。グラフ領域の大きさは表示画面のうちのグラフが占める領域の大きさであり、初期条件設定ウィンドウ（ＡＳＩＳＷＤ）で設定した表示サイズ（ＡＳＩＳＰＳ）から、縦横それぞれタイトルや軸の値、余白の部分を引いた値となるように計算する。

次に、横軸と縦軸それぞれの最大値を決定する（ＩＰ２０）。ここではプロットすべき全データ、つまり図１１の対面カウント（ＡＳＴＭＣ）の対面人数（ＴＭＮＭ）、対面時間（ＴＭＴＩ）のそれぞれの最大値を参考にし、最大値以上のきりのいい数字となるように軸の値を設定する。他に比べて突出した大きな値がある場合には対面カウント（ＡＳＴＭＣ）の最大値より小さな値を軸の最大値としてもよい。また、各軸は等差数列となるように目盛を区切った通常の軸（等差目盛）を想定しているが、対面人数（ＴＭＮＭ）または対面時間（ＴＭＴＩ）の分布によってはどちらか、もしくは両方を対数軸（対数目盛）としても良い。

次に、メンバを一人選択し、そのユーザ番号（ＡＳＵＩＴ１）に対応した対面カウント（ＡＳＴＭＣ）の対面人数（ＴＭＮＭ）・対面時間（ＴＭＴＩ）のデータから、先ほど決定した目盛を基準とし、プロットする座標を決定する（ＩＰ４０）。

さらに、初期条件設定（ＡＰＩＳ）の表示設定(ＡＳＩＳＰＣ)において役職の区別チェックボックス（ＰＤ１）がＯＮであった場合には（ＩＰ５０）、そのメンバの役職（ＡＳＵＩＴ４）をユーザＩＤ対応表（ＡＳＵＩＴ）から引き出し、役職に対応する記号を選択する（ＩＰ５１）。記号とはプロットする際に役職を区別するためのものであり、例えば部長は四角、課長は三角、一般社員は丸などとしてあらかじめ設定しておく。役職の区別を行わない場合には、デフォルトとして設定してある記号を用いる（ＩＰ５５）。役職の区別をするためには、プロットする記号を変える以外の方法を用いても良い。

また、初期条件設定（ＡＰＩＳ）の表示設定(ＡＳＩＳＰＣ)において特定プロジェクトの強調チェックボックス（ＰＤ２）がＯＮであった場合には（ＩＰ６０）、プロジェクト対応表（ＡＳＰＵＴ）を参照し（ＩＰ６１）、強調すべきとして設定されているプロジェクトにそのメンバが属している場合には（ＩＰ７０）、計算した座標上に記号を塗りつぶしてプロットする（ＩＰ７１）。メンバが該当プロジェクトに属していない場合には記号を塗りつぶさずに座標上にプロットする（ＩＰ７５）。なお、塗りつぶすのは該当プロジェクトに属しているメンバのみを強調させるためであるので、他の方法を用いて強調しても良い。

また、必要であればプロットした記号に隣接するように、そのメンバの氏名を表示させることも可能である。

全メンバに関してプロットが完了するまでＩＰ３０〜ＩＰ７１の手順を繰り返す（ＩＰ８０）。

また最後に、特定プロジェクトの強調チェックボックス（ＰＤ２）がＯＮになっている場合には（ＩＰ９０）、プロジェクトに属する全メンバ、つまり表示上ですでに塗りつぶされて表示されている全ての記号を、なるべく小さなもので包括するように楕円を描画する（ＩＰ９１）。これは、プロジェクトのメンバが座標上にどのように分布しているかをつかみやすくするためであるが、必要ない場合には行わなくても良い。

以上を終えると終了（ＩＰＥＮ）とする。
＜データプロットの結果例＞
図１４は、本発明の第１の実施の形態において、図３の初期条件設定（ＡＰＩＳ）からデータプロット（ＡＰＩＰ）までのステップを経て画面表示（ＡＰＷＯ）される結果の一例である。役職の区別はＯＮ、特定プロジェクトの強調はＯＦＦとしたものであり、実際の組織において約２ヶ月間、２６人のメンバに端末（ＴＲ）をつけて業務を行ってもらった際の実データを用いている。以降、本発明の実施例１から実施例４については、このとき得られた実データを用いて本発明の効果を検証する。

なお、役職に対応する記号については、部長が四角、課長が三角、一般社員がダイヤ型としている。

また図１４は、一日ごとに各メンバについて対面人数（ＴＭＮＭ）と対面時間（ＴＭＴＩ）を求め、さらに約２ヶ月分の結果をそれぞれ平均したものを座標に取り、プロットしている。よってこの方法ではプロットされた表示結果は、短期的な業務の内容よりも、メンバがその時期に負っている役割を強く反映したものが得られると考えられる。

図１４の結果では、全体の傾向としては、対面人数と対面時間には正の相関があることがわかる。また職位別に見ると、部長は右上に多く、課長は中央付近に多い。また、一般社員は左下に多くが集まっている。つまり、組織全体をマネジメントする役割を持つ部長は、運営会議やプロジェクトの報告など様々な長時間の会議に出席するため対面人数も対面時間も多くなっていると考えられる。一方、一般社員は通常はＰＣに向かって文献調査やデータ処理、文書作成などの個人作業がメインの業務であり、コミュニケーションは主に同僚との議論や直属の上司である課長との打合せにおいて行われるのみであるため、対面人数も対面時間も少なくなっているメンバが多いのだと考えられる。また、プロジェクトのリーダーとしての役割を持つ課長は、プロジェクトに属する部下との打合せと、上司である部長への報告との業務を持つため、両者の中間付近に位置するのだと考えられる。

よって、２ヶ月分のデータを用いたものを本発明の手法で表現することで、組織に置いてメンバが負っている役割を、コミュニケーションという切り口から表現できることがわかった。

しかし本発明の意義として重要なのは、一般的に期待されている役割に全員が従っているか否かを確認することよりも、役職として期待される平均的なやり方とは異なったやり方でコミュニケーションを行っている人物に注目できるという点である。例えば、図１４において個別のメンバについて見ると、人物ａや人物ｂは一般社員であるが、ほとんどの課長よりも多くの人と長く関わっている。また人物ｃは課長であるが個人作業型に属しており、対面時間も対面人数も一般社員の平均程度しかない。また、どの部長よりも多くの人と関わっている課長（人物ｄ）がいることもわかる。こういった異質なメンバは、たとえば人物ａや人物ｂは一般社員という枠を自ら超えた仕事を行っていると捉えられ、また人物ｄは組織の多様な人物とのコネクションを多く持っているはずだと考えられ、これらの人物が組織を動かす隠れた鍵となっている可能性がある。また、人物ｃについては他者とのコミュニケーションよりも一般社員的な実作業に追われてしまっている可能性がある。このことは組織全体として喜ばしいことなのかどうかを、本図面を用いることで再検討するきっかけとなる。
＜プロジェクト別の結果＞
図１５（ａ）〜（ｅ）は、本発明の第１の実施の形態において、特定プロジェクトの強調チェックボックス（ＰＤ２）をＯＮにし、５種類のプロジェクトにおけるメンバの分布を可視化した結果である。塗りつぶしてプロットされている記号がそのプロジェクトに属しているメンバであることを指し示しており、さらにそれらのメンバを包含するように描画された楕円がプロジェクトにおけるコミュニケーションの行い方の偏りや分布を示す助けとなっている。

図１５（ａ）のプロジェクトＡでは楕円が縦に細長い形状となっており位置としては右側に存在する。図１５（ｂ）のプロジェクトＢでは楕円が横に長い形状となっており、位置としては中央から上付近に存在する。これら二つは、似通ったコミュニケーションのスタイルを持つ複数のメンバに対して、一人が全く異なったスタイルを持っている場合である。図１５（ｃ）のプロジェクトＣでは楕円が底辺に張り付くような横長の形状となっており、対面人数については幅広く揃っているが、対面時間については全員が少ないプロジェクトであることがわかる。図１５（ｄ）のプロジェクトＤでは他と比べて楕円が丸く小さく、左下の領域に集まっている。つまりメンバ全員について、コミュニケーションが少なく閉じたメンバのみとしか関わっていないことがわかる。図１５（ｅ）のプロジェクトＥでは、丸みを帯びた楕円が中央付近に浮かんでいる。

またさらに、それぞれのプロジェクトにおいてリーダーに当たる人物が楕円の中のどのポジションにいるかを見ることで、それぞれのプロジェクトの進め方、リーダーの立ち位置がわかる。リーダーはほとんどの場合、四角で表現されている部長、または三角で表現されている課長が請け負っている。リーダーが複数存在するプロジェクトもあり、それは担当分野を切り分けてそれぞれがリーダーとなっているものである。

図１５（ａ）のプロジェクトＡではリーダーＡ１が突出して上にいる。会議は特に一回での時間が長くかかるため、会議の数が縦軸の対面時間に強く影響を与えていることがわかっている。よってこのリーダーＡ１が大きな会議にメインとなって出席しており、プロジェクトの左右を決定する役割を担っていると考えられる。また図１５（ｂ）のプロジェクトＢでは課長であるリーダーＢが突出して右に位置している。よって、リーダーＢは会議に多く出ているわけではないが、プロジェクトＢ以外の人とも多くのつながりを持ち、情報収集を積極的に行うリーダーであると考えられる。図１５（ｃ）のプロジェクトＣでは、リーダーは全体の真ん中に位置している。プロジェクトＣに新しい風を持ち込む可能性が高いのはむしろ右端に位置している一般社員であり、リーダーは自ら積極的にプロジェクト外部とコミュニケーションを取るタイプではない。各メンバから相談を持ちかけられた時には答えるが、日頃は部下を見守りサポートに徹しているリーダーであるように見受けられる。図１５（ｄ）のプロジェクトＤでは、全体的にバラつきが小さいがその中ではリーダーＤはコミュニケーションの量（対面時間）が多い方であり、メンバをまとめる役割をしていると考えられる。また、図１５（ｅ）のプロジェクトＥでは、二人のリーダーＥ１とリーダーＥ２が対面時間・人数共に多く、他の二人の一般社員は少ないため、会議やプロジェクトの進め方の検討など多くのコミュニケーションが必要な部分は二人のリーダーが行い、一般社員は個人作業に集中するという役割分担を明確にして進めているプロジェクトであることがわかる。
＜全体の時系列変化の結果＞
図１６（ａ）〜（ｆ）は、本発明の第１の実施の形態において、週ごとに図面を作成し組織コミュニケーションの時系列変化を追跡した結果である。

初期条件設定（ＡＰＩＳ）の表示設定（ＡＰＩＳＰＤ）において、役職の区別チェックボックス（ＰＤ１）をＯＮ、特定プロジェクトの強調チェックボックス（ＰＤ２）をＯＦＦにし、連続した６週間を週ごとに区切り、一枚ずつ図を作成したものである。なお、縦横それぞれの中央に線を入れて領域を４分割してあるが、この場合については実施例２において後述するためここでは省略する。また、図１５までとは記号と役職の対応が異なっており、横長の長方形が部長、正方形が課長、丸が一般社員を表している。

このデータを取得した組織では、図１６（ｃ）と図１６（ｅ）の週に、多数のメンバが関わって準備する必要のある対外的なイベントがあった。そのため、それぞれのイベントの前の週（図１６の（ｂ）・（ｄ））では組織が全体的に活性化し、あちこちで多くのコミュニケーションが行われていたことがわかる。また、イベントの週（図１６の（ｃ）・（ｅ））とイベント後の週（図１６の（ｆ））は、イベントのために先送りにされていた作業を行っているためか、コミュニケーションの量が減っている様子が各メンバを示す記号のバラつき具合から可視化されている。
＜あるプロジェクトの時系列変化＞
図１７（ａ）〜（ｄ）は、本発明の第１の実施の形態において、週ごとに図面を作成し、あるプロジェクトＦに着目して組織コミュニケーションの時系列変化を追跡した結果である。

初期条件設定（ＡＰＩＳ）の表示設定（ＡＰＩＳＰＤ）において、役職の区別チェックボックス（ＰＤ１）をＯＮ、特定プロジェクトの強調チェックボックス（ＰＤ２）をＯＮにし、連続した４週間を週ごとに区切って一枚ずつ図を作成したものである。

図１７（ａ）〜（ｄ）のそれぞれ楕円で囲まれている中の、正方形でプロットされているものがプロジェクトのリーダーＦである。本プロジェクトＦは、図１７の始めの時点では各メンバに担当部分を分担し、最終的に顧客に提出するために調査結果を文書にまとめている段階であった。そのため図１７（ａ）（ｂ）ではプロジェクトのメンバ全員がコミュニケーションが少なく、左下に集まっている。図１７（ａ）（ｂ）の時期には、リーダーＦ自身も文書執筆に関わっており、他者とのコミュニケーションを絶って執筆作業に集中していたようである。しかし、図１７（ｃ）の始めの時期に事態が一転し、文書の内容を再び一から構成しなおさなくてはならなくなった。そこでプロジェクトＦのメンバが集まり活発な議論を交わしていた様子が、図１７（ｃ）（ｄ）と楕円が立ち上がってくる様子に表れている。またその際にはリーダーＦが楕円の右上に位置しており、リーダーＦが部長との打合せやプロジェクトのメンバとの議論を積極的に行い、リーダーシップを発揮してプロジェクトを強く牽引したことがわかる。
＜対面時間・対面人数以外を軸に取る可能性＞
なお、本発明ではセンサネットによって取得した人物のコミュニケーションに関するデータから各メンバに関する対面人数と対面時間を計算し、それぞれ横軸と縦軸に取ってプロットしているが、軸の一方が他者との関わりの多様性、もう一方が他者との関わりの量を表すものであれば、この他の計算方法を用いたものを軸としてプロットすることも可能である。例えば、対面人数と対面時間をセンシングデータが取れている時間で割って基準化したものをそれぞれ軸としても良い。また、他者との関わりの多様性としては、同じプロジェクトではない人との対面に限定して人数をカウントしても良い。もしくは業務の種類の異なる人、座席の遠い人、役職の離れている人、頻繁に会わない人など対面相手に対して重み付けし合計したものを軸としても良い。一方、他者との関わりの量としては、音声や着席情報などから、メンバ同士が同じ場所にいた時間の量などを用いても良い。

また、対面したことの判別に、赤外線データだけでなく音声データによる分析も加え、「会話している」と判断できた場合のみを「対面」とみなすこともできる。
＜人以外の物に端末を装着した場合の可能性＞
なお、本発明におけるコミュニケーションとは、人と人の間における対面コミュニケーションに限定せず、人と物との相互作用も含む概念である。

例えば、店頭の商品に端末（ＴＲ）を取り付けた場合には、その商品に触れるもしくは覗き込むなどして商品に興味を持った顧客とのコミュニケーションが生じたと捉える。この情報を用いて表示を作成することによって、商品が幅広い顧客から興味を持たれているのか、特定のタイプの顧客から強い興味を持たれているのかを分析することができ、店内での商品の配置場所の決定、顧客へのアピール戦略の決定などに生かすことができる。またさらに、店員が顧客に対してその商品の説明を行った場合には、店員‐顧客‐商品の三項間でのコミュニケーションを端末（ＴＲ）を介して検出することができる。この情報は、店員が顧客に声をかけることによる売り上げへの効果の検証に役立てることができる。またそれぞれの端末（ＴＲ）で取得した加速度や音声データを合わせることにより、店員が顧客に声をかける効果的なタイミングや、説明する際の効果的な身振りや声のトーンを分析することができる。

また、オフィス内のＰＣやコピー機、コーヒーメーカーなどの装置に端末（ＴＲ）を取り付けた場合には、その端末（ＴＲ）の情報を用いて表示を作成することによって、多様な人が少しずつ利用する装置、特定の人だけが利用する装置、多くの人が長い時間利用する装置、などを分類することができる。また、装置や人の端末（ＴＲ）の情報によって、誰がどのような時間帯に装置を利用しているかがわかる。これによって、各メンバーのワークスタイルをより幅広く捉えることができる。また、コピーを取ったりコーヒーを淹れることをきっかけに多様な人との会話がはじまっていたりすることを検出し、コミュニケーションをより活性化させるためのオフィス設計に生かすこともできる。

またさらに、会議室や自販機、喫煙所などの部屋や領域において、その入り口や壁面、テーブルの中央などに端末（ＴＲ）を取り付けた場合には、その端末（ＴＲ）の情報を用いて表示を作成することによって、多様な人が入れ替わり立ち替わりする場所、特定の人だけが存在する場所、多くの人が長い時間滞在する場所、などを分類することができる。また、部屋・領域や人の端末（ＴＲ）の情報によって、その部屋もしくは領域にどのような人がどの時間帯に集まっているか、どの場所においてコミュニケーションが活発になっているか、どのような場所がアイディアを生むために効果的かを分析し、オフィス設計に生かすことができる。

本発明の第２の実施の形態について図面を参照して説明する。
＜実施例２の概要＞
実施例２では、実施例１の方法による表現を４つの領域に分割し、各領域に名前を付けて分類する。実施例１の結果を説明する際には、「右上」「下」などの用語を用いたが、分類によって、各メンバのコミュニケーションスタイルをより直感的にわかりやすくするためのものである。具体的には、図２０で示す図を作成する。
＜４分類の説明＞
図１８は、本発明の第２の実施の形態において、それぞれの領域が持つ意味を説明するためのものである。

右上の対面人数も多く対面時間も長いという領域にプロットされる人は、多くの人と長い時間のミーティングを行っている結果、この位置にプロットされていることが多い。実施例１の結果よりこの領域には特にマネージャーに多いことがわかったので、領域（ＣＴ１）を「マネージャー型」と名づける。

また、右下の対面人数は多いが対面時間は長くないという領域にプロットされる人は、挨拶・ちょっとした雑談を多くの人と行っている社交的な人だと言える。よって領域（ＣＴ２）を「社交型」と名づける。

また、左上の対面人数は少ないが対面時間は長いという領域にプロットされる人は、業務上でつながりの深い限られた特定の人（直接の上司・部下・同じプロジェクトのメンバなど）との会議・議論をじっくり行っていると考えられる。よって領域（ＣＴ３）を「特定型」と名づける。

また、左下の対面人数も少なく対面時間も短いという領域にプロットされる人は、限られた人と短い時間の会話しか行っていないことから、コミュニケーションが少なく個人作業に集中していると考えられる。よって領域（ＣＴ４）を「個人作業型」と名づける。

この場合、本発明の組織コミュニケーション可視化システムは、座標平面を４つの領域に分割し、その４つの領域のうち、強さを示す特徴量が大であり、かつ、多様性を示す特徴量が大である第１の領域をマネージャー型の領域とし、強さを示す特徴量が小であり、かつ、多様性を示す特徴量が大である第２の領域を社交型の領域とし、強さを示す特徴量が大であり、かつ、多様性を示す特徴量が小である第３の領域を特定型の領域とし、強さを示す特徴量が小であり、かつ、多様性を示す特徴量が小である第４の領域を個人作業型の領域とし、これら４つの領域の各領域に属する人物を互いに区別して認識できるように表示して当該組織のコミュニケーションの型を可視化することを特徴とする。

以上の領域ごとの名前は上に挙げたもの以外でどのようなものをつけても良い。しかしその領域の特性を適切に表すものとすると良い。
＜プロットのフローチャート＞
図１９は、本発明の第２の実施の形態において、図３の全体のフローチャートにおけるデータプロット（ＡＰＩＰ）のステップの詳細を示したフローチャートである。図３のデータプロット（ＡＰＩＰ）以外の部分の手順については実施例１とほぼ同じであるので説明を省略する。

また図１９は、図１３における全メンバのプロットを完了（ＩＰ８０）と特定プロジェクトの強調がＯＮ（ＩＰ９０）の間に新しい処理が導入される部分のみが新規であって他は全て図１３と同じである。

実施例２において新しく導入される手順は、領域を４つに分ける際の境界となる２つの基準値を計算すること（ＩＰ８１）と、それに基づいて２本の基準線（各領域間の境界線となる）を引くこと（ＩＰ８２）、また各領域に分類名を記載すること（ＩＰ８３）である。分類名を図中に記載する必要がなければ最後の手順は省略しても良い。

基準値の計算（ＩＰ８１）では、図面上にプロットする全メンバの対面人数と対面時間のそれぞれの中央値を計算し、その値を基準値とする。もしくはＩＰ２０で決定した横軸と縦軸の最大値の値の２分の１を基準値としても良い。前者を用いた場合には、基準線の左右に等しくメンバが分類される。基準線の上下にも等しくメンバが分類される。後者を用いた場合には、基準線が必ず図面の中央に来るので見やすいという利点がある。図１６・図１７の線は軸の２分の１の値を基準値として線を引いたものである。図２３以降では中央値を基準値として線を引いている。

次に、対面人数の基準値の位置に縦の基準線を、対面時間の基準値の位置に横の線を引く（ＩＰ８２）。そして決定された４つの領域内に、分類名を記述する（ＩＰ８３）。

基準値として全プロットデータの中央値を用いる場合には、全メンバのプロットする座標を計算済みである必要があるため、プロットを完了（ＩＰ８０）後にＩＰ８１〜ＩＰ８３を配置したが、基準値があらかじめ決定されている場合には、横軸と縦軸の最大値を決定（ＩＰ２０）後にこれらの手順を実施しても良い。
＜実施例２の結果＞
図２０は、本発明の第２の実施の形態において、作成された図面の一例である。プロットされたデータは図１４と同じものである。領域を明確にすることによって、人物ａはマネージャー型のコミュニケーションを行っており、人物ｃは課長だが個人作業型のコミュニケーションを行っている、などと分類名を用いて容易に説明することができる。
＜実施例２の結果（プロジェクト別）＞
図２１は、本発明の第２の実施の形態において、特定プロジェクトの強調チェックボックス（ＰＤ２）をＯＮにし、５種類のプロジェクトにおけるメンバの分布を可視化した結果である。プロットしたデータは図１５と同じものであり、領域を分割している点が図１５との違いである。

図２１（ａ）のプロジェクトＡでは４人中２人がマネージャー型、１人が特定型、１人が個人作業型であるが、全員中央から右の領域に位置している。対面時間にはバラつきがあるが多くの人と関わりを持つプロジェクトであることがわかる。

図２１（ｂ）のプロジェクトＢでは、３人中２人がマネージャー型、１人が個人作業型であるが、メンバは全員中央から上にかけての領域に位置している。コミュニケーションが多く議論好きな性質を持つプロジェクトであることが伺える。

図２１（ｃ）のプロジェクトＣでは、４人中１人が社交型、３人が個人作業型であり、メンバは全員中央から下にかけての領域に位置している。

図２１（ｄ）のプロジェクトＤでは、４人中全員が個人作業型である。全員が似たコミュニケーションスタイルを持っているため、プロジェクト内で関係が閉じており外のメンバとの接点が少なく、新しい変化の風が入ってこないのではないかということが懸念される。

図２１（ｅ）のプロジェクトＥでは、４人中２人がマネージャー型、２人が個人作業型である。図１５でわかったことと同じであるが、分類されていることで、プロジェクトＥの特異さが明確になっている。

図１５はメンバの分布・バラつき・リーダーのポジションという視点から結果を分析することができたが、図２１ではあえてデジタル化して４種類に分類してしまうことで、縦軸のみの共通点やバラつきに注目する、横軸のみの共通点やバラつきに注目する、など切り口を明確にした視点からの分析を可能にする。

本発明の第３の実施の形態について図面を参照して説明する。
＜実施例３の概要＞
実施例２の図２１では、プロットした図に領域を区分する基準線を加えることで、各プロジェクトのコミュニケーションスタイル、つまりどのようなコミュニケーションスタイルのメンバから構成されているかを示した。

実施例３では、実施例２をより単純化し、プロジェクトのメンバ構成を表現することに特化するためのものである。
＜プロジェクトの４象限＞
図２２は、本発明の第３の実施の形態において、作成された図面の一例である。実施例２の図２１において、各プロジェクトのメンバが４つの領域に何人ずつ含まれているかをカウントしたが、個人のプロットは省略し、多くのメンバが分布している領域を濃い色で表現することによりプロジェクトにおけるメンバの偏りを示したものである。

この場合、上記の関係付け表示は、強さを示す特徴量を一方の軸に割り当て、多様性を示す特徴量を他方の軸に割り当てた二軸構成の座標平面を４つの領域に分割し、その４つの領域のうち、強さを示す特徴量が大であり、かつ、多様性を示す特徴量が大である第１の領域をマネージャー型の領域とし、強さを示す特徴量が小であり、かつ、多様性を示す特徴量が大である第２の領域を社交型の領域とし、強さを示す特徴量が大であり、かつ、多様性を示す特徴量が小である第３の領域を特定型の領域とし、強さを示す特徴量が小であり、かつ、多様性を示す特徴量が小である第４の領域を個人作業型の領域とし、これら４つの領域の各領域に属する人物の数に対応する色調を各領域に配置して行う表示である。

社交型（ＣＴ２）が３人、個人作業型（ＣＴ４）が１人から成るプロジェクトは、図２２のように領域（ＣＴ２）を濃い色で、領域（ＣＴ４）を薄い色で、残りの領域（ＣＴ１、ＣＴ３）は白で表現される。よって、このプロジェクトのコミュニケーションの行い方は、多様性（対面人数）は大きいが量（対面時間）は少ないことが特徴であると解釈できる。
＜プロットのフローチャート＞
図２３は、本発明の第３の実施の形態において、図３の全体のフローチャートにおけるデータプロット（ＡＰＩＰ）のステップの詳細を示したフローチャートである。図３のデータプロット（ＡＰＩＰ）以外の部分の手順については実施例１とほぼ同じであるので説明を省略する。

データプロットの開始（ＩＰＳＴ）後、まず、グラフ領域の大きさを決定（ＩＰ１００）、対面人数・対面時間の最大値を計算（ＩＰ１１０）、基準値の計算（ＩＰ１２０）を行うが、これらはそれぞれ実施例２の図１９における処理（ＩＰ１０）、処理（ＩＰ２０）、処理（ＩＰ８１）と同じ処理である。

次に、各メンバごとにどの領域に分類されるかを判別し、各領域ごとの人数をカウントする。メンバを一人選択し（ＩＰ１３０）、そのメンバの対面人数が基準値より大きいかどうか（ＩＰ１４０）、さらにメンバの対面時間が基準値より大きいかどうか（ＩＰ１５０、ＩＰ１６０）を判別する。どちらも大きいの場合にはマネージャー型にカウント（ＩＰ１５０）、対面人数が大きく対面時間が少ない場合には社交型にカウント（ＩＰ１５２）、対面人数が少なく対面時間が大きい場合には特定型にカウント（ＩＰ１６１）、どちらも少ない場合には個人作業型にカウント（ＩＰ１６２）する。なお、対面人数と対面時間の基準値との判別の順序は逆でも良い。これを全メンバのカウントが終了するまで繰り返す（ＩＰ１７０）。

最後に、４つの領域をそれぞれの人数比に応じた色で塗り分け（ＩＰ１８０）、終了（ＩＰＥＮ）とする。色は人数比に応じて一色の濃さのみを変えても良いし、異なる色を設定しても良い。
＜各プロジェクトごとの結果＞
図２４は、本発明の第３の実施の形態において、各プロジェクトごと、一日ごとに図を作成した結果（ＰＡ０１〜ＰＡ０５、ＰＢ０１〜ＰＢ０５、ＰＣ０１〜ＰＣ０５、ＰＤ０１〜ＰＤ０５、ＰＥ０１〜ＰＥ０５）である。また、各プロジェクトの一週間通算での結果（ＰＡ１０、ＰＢ１０、ＰＣ１０、ＰＤ１０、ＰＥ１０）を最下部に、一日ごとの組織全体での結果（ＡＬＬ０１〜ＡＬＬ０５）を右端に記載した。

このように、関係付け表示を複数の時点で同様に実行し、その複数の時点を含む時系列に沿ってその複数の時点における座標平面を１次元的に配列して表示することができる。

あるいは、関係付け表示を複数の組織について同様に実行し、その複数の組織に対応する複数の座標平面を１次元的に配列して表示することもでき、更には、その関係付け表示を更に複数の時点で同様に実行し、その複数の時点を含む時系列に沿ってその複数の時点の各時点における複数の組織に対応する複数の座標平面の１次元的配列を更に１次元的に配列して全体を２次元的に表示することもできる。

ここでは、一日ごと・全メンバの対面人数と対面時間を５日分すべて計算し、日数×人数分の数のデータの中での対面人数と対面時間の中央値を共通の基準値として用いた。これは、プロジェクトごとの比較と日による変化を分析できるようにするためである。一週間通算の場合のみは、５日間での値を合算して対面人数と対面時間を求め、人数分の数のデータの中央値を基準値として用いた。よって、月曜日から金曜日の人数の合計が一週間通算に反映されているわけではない。

プロジェクト別・一日ごとのデータ（ＰＡ０１〜ＰＡ０５、ＰＢ０１〜ＰＢ０５、ＰＣ０１〜ＰＣ０５、ＰＤ０１〜ＰＤ０５、ＰＥ０１〜ＰＥ０５）では、各プロジェクトがそれぞれの日にどのように活動をしていたか、変化を追うことができる。例えばプロジェクトＢでは月曜日から水曜日（ＰＢ０１〜ＰＢ０３）までは全員が会議も多く活発にコミュニケーションしていたが、木曜日（ＰＢ０４）にはコミュニケーションの量が減ったことがわかる。

また、プロジェクトごとに一週間通算で計算したもの（ＰＡ１０、ＰＢ１０、ＰＣ１０、ＰＤ１０、ＰＥ１０）は、プロジェクトの業務の性質やメンバの性格を反映しているものであると考えられる。プロジェクトＢ（ＰＡ０１）はコミュニケーション量が多く議論好き、プロジェクトＤ（ＰＤ１０）は特定型ばかりで閉鎖的、などと解釈できる。

さらに、一日ごとの組織全体での結果（ＡＬＬ０１〜ＡＬＬ０５）では、全体としてコミュニケーションが活発だったのかどうかというその日のムードがわかる。例えば金曜日（ＡＬＬ０５）はマネージャー型に偏っており、多くのメンバがたくさんのコミュニケーションを活発にしていたようだが、水曜日（ＡＬＬ０３）は重心が下にあり、コミュニケーション量が少なく静かな日であったとわかる。

本発明の第４の実施の形態について図面を参照して説明する。
＜実施例４の概要＞
実施例４では、実施例１または実施例２の表現に加え、主観的なパフォーマンス評価による個人のコミュニケーションの志向性を矢印（ベクトル）で表現する。図２５に実施例４において作成した表示の結果の一例を示す。なお図２５は、実施例２の表現をベースにした場合のものである。

具体的には、プロットされた記号に加え、その記号に対応する人物のコミュニケーションに係る志向性を示す矢印をその記号に対応させて表示することを特徴とする組織コミュニケーション可視化システムである。
＜コミュニケーション志向の表現方法の説明＞
図２５の個々の矢印は、各メンバに関して、対面時間・対面人数とパフォーマンス評価との相関係数の正負を示している。そのメンバにとって、どのようなコミュニケーションを行うとパフォーマンスが向上するのか、もしくは低下するのかを矢印の向きで表現する。なお、相関係数の値の絶対値が一定値以下であった場合には無相関として矢印を表示しないものとする。図２６に矢印の方向と、対面時間と対面人数に対する相関係数の正負との関係を示す。対面時間に対して正の相関を持つ場合、つまり多くのコミュニケーションを行う方がパフォーマンスが向上するメンバは上向きの矢印になる。逆に、対面時間に対して負の相関を持つ場合、つまりコミュニケーション量は少ない方がパフォーマンスが向上するメンバは下向きの矢印となる。また、対面人数に対して正の相関を持つ場合、つまり多くの人と関わる方がパフォーマンスが向上するメンバは右向きの矢印となり、対面人数に対して負の相関を持つ場合、つまり多くの人と関わらない方がパフォーマンスが向上するメンバは左向きの矢印となる。さらに、対面時間と対面係数の両方が正、または両方が負、一方が正で一方が負であった場合には、それぞれ上下左右のベクトルの合計として考え、図２６に示したように斜め向きの矢印で表現する。なお、矢印（ベクトル）は向きのみを考慮するものとし、長さは全て一定にした。

全メンバについて相関を計算し、矢印を付加した結果が図２５である。個々のメンバに注目すると、個人の性格、業務の進め方のポリシーなどコミュニケーションにおける志向性を表すことができる。また、全体として俯瞰すると、現状行っているコミュニケーションのパターン、つまり実施例２で述べたコミュニケーションの４分類と、望むコミュニケーションの志向性にどのような傾向があるのかを図から捉えることができる。
＜実施例４の結果と効果＞
実施例４を組織マネジメントに応用することで得られる効果を、図２５の結果を用いて具体的に述べる。

まず図２５において、個人作業型の領域に注目してみると、ベクトルが右下を向いているメンバが多い。つまり、個人作業型のメンバは、多くの人と話すことはプラスだが、長い時間拘束されるのはマイナスだと感じているということである。特に、その内訳には一般社員が多いことを踏まえると、長時間会議や議論するよりも自分の業務に集中して取り組み、能力を高めたいという願望があるのではないかと考えられる。

対して右上マネージャー型の人物f、人物g、人物hの3人の部長は、それぞれ対面人数に対して負、対面時間に対して正、対面人数に対して正となっている。人物hは、関わる人が少ない方が満足度が高まるため、現状の対面人数は本人にとっても多すぎると感じていることが懸念される。人物gも現状では相対的に対面人数が多いが、人物hと対照的にそれでも多くの人と関わる方が業務の満足度が高まるとしている。また人物fも、関わる人数に関しては無相関だが対面時間は長い方が満足度が高まる。コミュニケーションタイプがマネージャー型に属するメンバは、現在すでに経営会議や部下との議論によって意思決定をすることが多い立場であると考えられる。よって人物fや人物gにとっては、多くの人と、または長い時間コミュニケーションすることが業務の達成であると感じていると考えられる。

よって、コミュニケーションタイプが個人作業型に属するメンバは調査・分析など個人の作業を重要な業務として捉えており、マネージャー型に属するメンバは会議が重要な業務であると捉えている人が多いということがわかった。このようなメンバは、コミュニケーションの行い方の「現状」と「志向性」が合っているとみなすことができる。しかし、「現状」はマネージャー型のコミュニケーションを行っているのに「志向性」としてはコミュニケーション量を減らしたいというように、「現状」と「志向性」が合っていないパターンでは、本人のスタイルと担当業務の性質がマッチしておらずストレスになっている可能性がある。このようなメンバに注目し、フォローしながら組織編成や業務の割り振りを見直すことで、より活気のある組織づくりに生かすことができる。
＜全体構成図＞
図２７は、本発明の第４の実施の形態における、インタラクションデータを取得する端末から、取得したデータを表示するアプリケーションまでを含むシステム全体の構成の説明図である。

実施例１の図１と異なる点は、アプリケーションサーバ（ＡＳ）内のデータ処理部（ＡＳＤＰ）にパフォーマンス相関（ＡＰＰＫ）が追加されている点、記録部（ＡＳＭＥ）内にパフォーマンス評価テーブル（ＡＳＰＴ）・パフォーマンス結合テーブル（ＡＳＰＣ）・パフォーマンス評価シート（ＡＳＰＳ）が追加されている点のみである。

パフォーマンス相関（ＡＰＰＫ）は、パフォーマンスデータとセンシングデータの相関を計算する処理である。計算の処理とプロット処理の詳細はあわせて図２９で示す。

パフォーマンス評価テーブル（ＡＳＰＴ）は、図３０で示した個人のパフォーマンス評価結果をまとめたテーブルである。

パフォーマンス評価シート（ＡＳＰＳ）は評価したパフォーマンスを入力させるためにユーザ（ＵＳ）に提示するものである。例は図３０に示す。パフォーマンス評価シート（ＡＳＰＳ）はアプリケーションサーバ（ＡＳ）上に保管しておき、ユーザ（ＵＳ）からの呼び出しがあった場合のみクライアント（ＣＬ）に送って画面に表示しても良いし、始めからクライアント（ＣＬ）内に保管しても良い。また、印刷して紙の形でユーザ（ＵＳ）の手元に置いておいても良い。

パフォーマンス結合テーブル（ＡＳＰＣ）は、同じ人物の同じ日付のセンシングデータとパフォーマンスデータを対応付けたテーブルであり、その例は図３１に示す。
＜シーケンス図＞
図２８は、本発明の第４の実施の形態における処理の流れを示すシーケンス図である。

パフォーマンスデータの入力、格納、処理にまつわる部分のみが図２と異なっている。個別に示すと、パフォーマンス入力（ＵＳＰＩ）、パフォーマンスデータ送信（ＣＬＰＳ）、パフォーマンスデータ格納（ＡＳＰＣ）、パフォーマンスデータ取得（ＡＳＰＧ）、パフォーマンス計算（ＡＳＰＫ）の５ヶ所である。

パフォーマンス入力（ＵＳＰＩ）は、例えば１日に１回など、定期的にユーザ（ＵＳ）が業務を振り返ってパフォーマンスを評価し、パフォーマンス評価シート（ＡＳＰＳ）に入力する。入力した結果は、クライアント（ＣＬ）を通してアプリケーションサーバ（ＡＳ）に送信され（ＣＬＰＳ）、アプリケーションサーバ（ＡＳ）内記録部（ＡＳＭＥ）のパフォーマンス評価テーブル（ＡＳＰＴ）に記録・格納される（ＡＳＰＣ）。

また、アプリケーションが起動され、図２５の図を作成する際には、パフォーマンスデータを利用する。図３の全体の処理の流れにおけるデータ取得（ＡＰＤＧ）としてセンシングデータをデータベースから取得する際に、パフォーマンス評価テーブル（ＡＳＰＴ）から必要なメンバ・日時のパフォーマンスデータを取得する（ＡＳＰＧ）。さらに、実施例１と同様にして対面人数・対面時間のカウント（ＡＰＩＣ）の後に、パフォーマンス相関計算（ＡＳＰＫ）を行う。その後のデータプロット（ＡＰＩＰ）の手順は図２９に示す。
＜フローチャート＞
図２９は、本発明の第４の実施の形態において、図３の全体のフローチャートにおけるデータプロット（ＡＰＩＰ）と新たに追加されるパフォーマンス相関計算（ＡＰＰＫ）のステップの詳細を合わせて示したフローチャートである。図３のデータプロット（ＡＰＩＰ）以外の部分の手順については実施例１とほぼ同じであるので説明を省略する。

実施例４におけるデータプロット（ＡＰＩＰ）は、実施例１または実施例２のデータプロット（ＡＰＩＰ）に、センシングデータ（対面時間・対面人数）とパフォーマンス評価値の相関計算もしくは重回帰分析の手順と矢印のプロットが追加される。

パフォーマンス相関計算（ＡＳＰＫ）では、説明変数を対面人数、目的変数をパフォーマンス評価値としたときの相関係数を求め、また、説明変数を対面時間、目的変数をパフォーマンス評価値としたときの相関係数を求める。もしくは、説明変数を対面人数と対面時間、目的変数をパフォーマンス評価値として重回帰分析を行い、偏回帰係数を求める。どちらの方法を用いても良いが、対面人数と対面時間がそれぞれパフォーマンス評価値に対して正の影響を与えているのか、負の影響を与えているのかを相関係数もしくは偏回帰係数から判断できれば良い。図２９のフローチャートでは重回帰分析を用いて求めた偏回帰係数を用いる方法を提示している。

まず、データプロットの開始（ＩＰＳＴ）後、各メンバごとにパフォーマンス結合テーブル（ＡＳＰＣ）を作成する。パフォーマンス結合テーブル（ＡＳＰＣ）の一例は図３１に示す。これは、あるノードＩＤが１００２であるユーザ（ＵＳ）に関するパフォーマンス結合テーブル（ＡＳＰＣ＿１００２）であると想定している。センシングデータから計算した特徴量として、このユーザ（ＵＳ）の１日の対面人数（ＴＭＮＭ）と対面時間（ＴＭＴＩ）、パフォーマンス評価値（ＴＭＰＱ）のデータに日付情報（ＴＭＤＴ）を加えて組にし、それを複数日分集めたものである。パフォーマンス評価値（ＴＭＰＱ）は、図３０のパフォーマンス評価シート（ＡＳＰＳ）に示した項目のうちから1つを選択する、もしくは複数の項目に処理を加えて新たな変数とする、もしくはパフォーマンス評価シート（ＡＳＰＳ）以外から取得したデータを用いる、などから設定する。

また、パフォーマンス結合テーブル（ＡＳＰＣ）上の対面人数（ＴＭＮＭ）、対面時間（ＴＭＴＩ）に関して平均値（ＲＥａｖｅ）を求めておき、図面上に記号をプロットする際には平均値をそのユーザ（ＵＳ）の代表値としてその座標上にプロットする。座標を決めるためには平均以外の方法を用いても良い。

次に、グラフ領域の大きさの決定（ＩＰ２２０）と対面人数・対面時間の最大値の計算（ＩＰ２３０）を行う。これらはそれぞれ、実施例１の図１３における処理（ＩＰ１０）、処理（ＩＰ２０）と同じ処理である。表示に４領域を区切る基準線を加える場合には、基準値の計算とプロットを実施例２の図１９の処理（ＩＰ８１、ＩＰ８２、ＩＰ８３）と同様にして行っておく。

次に、メンバを一人選択し（ＩＰ２４０）、パフォーマンス結合テーブル（ＡＳＰＣ）における対面時間データ（ＴＭＴＩ）と対面人数データ（ＴＭＮＭ）、パフォーマンス評価値（ＴＭＰＱ）をそれぞれ正規化し（ＩＰ２５０）、パフォーマンス結合テーブル（ＡＳＰＣ）上のデータを正規化後のデータに置き換える。そして、パフォーマンス結合テーブル（ＡＳＰＣ）の各行について重回帰式を作成し（ＩＰ２６０）、対面人数・対面時間に対応する偏回帰係数を取得する（ＩＰ２７０）。それぞれの偏回帰係数の正負に従って、プロットする矢印の向きを決定する。

次に、そのメンバの対面人数と対面時間の平均値をプロットするが、縦軸・横軸の座標計算（ＩＰ２９０）から記号のプロット（ＩＰ３００、ＩＰ３０１）までの流れは、実施例１の図１３における処理（ＩＰ４０）から処理（ＩＰ７１、ＩＰ７５）までと同じなので説明は割愛する。

最後にプロットした記号上に、先立って決定した向きの矢印をプロットする（ＩＰ３１０）。

これを全てのメンバのプロットを完了するまで繰り返し（ＩＰ３２０）、終了（ＩＰＥＮ）とする。
＜パフォーマンス評価シート＞
図３０は、本発明の第４の実施の形態において用いるパフォーマンス評価シート（ＡＳＰＳ）の一例である。

パフォーマンス評価シート（ＡＳＰＳ）は、業務の成果、業務のプロセス、また身体の調子について、各メンバの主観的な評価を付けてもらい、主観評価とセンサによる特徴量（ここでは対面人数と対面時間）との結びつきを分析するために用いる。

評価項目は、業務の遂行性、業務全体の出来としての満足度、業務のプロセスにおける個人作業、Ｆａｃｅ Ｔｏ Ｆａｃｅ（対面）またはサイバー上でのコミュニケーション、心の健康、体の健康、自由記述、とした。

また、個人に対する評価と共に、一部の評価項目についてはプロジェクトとしての業務の成果も並行して評価する。本来ならば全てのプロジェクトに対して属する全メンバが評価すべきであるが、複数プロジェクトに関わっているメンバには負担が大きくなる。そのため、メンバごとに評価対象とするプロジェクトをメインプロジェクトとして指定し、メインプロジェクトに関する自分の業務の評価、他のメンバも含んだ業務の評価、さらに携わっているプロジェクト全てに関する評価を区分した。

以上の評価項目は、その他（ＲＳ３００）の自由記述以外は５段階での評価とした。

本実施例において、ユーザ（ＵＳ）は、例えば１日１回各自の業務を振り返りこのシートの各項目について評価を記入する。図３０はプリントアウトした用紙に手書きで印をつけ、担当者がまとめてクライアント（ＣＬ）またはアプリケーションサーバ（ＡＳ）に入力することを想定しているが、入力用ウィンドウを用意し、各ユーザ（ＵＳ）が直接クライアント（ＣＬ）またはアプリケーションサーバ（ＡＳ）に入力しても良い。

入力された毎日の全ユーザ（ＵＳ）の評価データは、日付、ユーザ名（ＡＳＵＩＴ２）もしくはユーザＩＤ（ＡＳＵＩＴ３）、評価項目番号、評価データを組にしたパフォーマンス評価テーブル（ＡＳＰＴ）として、アプリケーションサーバ（ＡＳ）内記録部（ＡＳＭＥ）に格納される。
＜各項目の説明＞
図３０は、未記入のこの評価シートをプリントアウトした用紙を各ユーザ（ＵＳ）に配布し、手書きでユーザ（ＵＳ）に記入してもらうことを想定している。

まず、日付（ＲＳ０１）、氏名（ＲＳ０２）を記入する。日付（ＲＳ０１）は評価の対象となる月日であり、氏名（ＲＳ０２）はユーザ名（ＡＳＵＩＴ２）である。これらはユーザ（ＵＳ）本人が記入しても良いし、始めから記入された用紙を配布しても良い。

メインプロジェクト（ＲＳ０３）は、対象ユーザ（ＵＳ）が属しているプロジェクトのうち、特に評価してほしいものを選択し記入する。これは、ユーザ（ＵＳ）本人が、現在の業務の中心となっているプロジェクトから選択しても良いし、分析者が指定してもよい。

設問項目（ＲＳ１０）は、評価する項目の内容を示すものである。

設問項目（ＲＳ１０）は大別すると結果評価（ＲＳ１００）とプロセス評価（ＲＳ２００）、その他（ＲＳ３００）に分かれる。

結果評価（ＲＳ１００）とプロセス評価（ＲＳ２００）を分けたのは、日常的な業務において、個別の作業や他者との会話、本人の体調やメンタル状態などのプロセスに対する統合的な結果として、業務の良し悪しの結果評価があると考えるからである。なお、これらを区別しない評価シートを用いても良い。また、その他（ＲＳ３００）は、対象月日の出来事、感想などを自由筆記によってメモするために設けたものである。

結果評価（ＲＳ１００）には自分の業務全体の遂行性、自分の最重要案件の遂行性、満足度の項目がある。満足度は、達成の有無だけでなく全てを含んだ業務の成果に対する本人の主観評価である。

プロセス評価（ＲＳ２００）には個人作業、コミュニケーション、心の健康、体の健康の項目がある。さらにコミュニケーションにはＦａｃｅ Ｔｏ Ｆａｃｅ（対面）でのコミュニケーションとサイバー上（メールやブログ、ソーシャルネットワークなどを介したもの）でのコミュニケーションとを区分した。これは、組織において対面でのコミュニケーションによってもたらされる効果と、サイバー上でのコミュニケーションによってもたらされる効果は質が異なるという考えに基づいているからである。個人作業は、情報収集や分析・資料作成など基本的に一人で取り組む業務に関する評価である。心の健康とは、メンタル面での元気良さに関する評価であり、体の健康とは体調に関する評価である。

なお、個人に関するパフォーマンス評価、プロジェクトに関するパフォーマンス評価は図３０以外の評価項目を用いても良い。また本実施例４の結果（図２６）は、センシングデータとパフォーマンス評価との重回帰分析を行う際に、「業務の満足度」の「関係プロジェクト全体」の評価結果を用いたものである。

本発明の第５の実施の形態について図面を参照して説明する。
＜実施例５の概要＞
実施例５では、実施例１の表現に基づき、組織におけるメンバのコミュニケーションのスタイルの分布を時系列に沿って分析できるようにするものである。
＜完成イメージ図＞
図３２は本発明の第５の実施の形態において作成した表示の結果の一例である。横軸が日付、縦軸が対面人数と対面時間との主成分軸である。さらに、主成分軸を等分割し、その分割枠に属するコミュニケーション形態を取っているメンバの数によって分割枠の色・もしくは色の濃さを変える。図３２は色の濃さによって人数を表している。人数が０のときは白となる。例えば、２月２１日のように色が薄く、しかし下から上まで幅広く現われている場合には、組織においてコミュニケーションの多い人から少ない人まで満遍なく分布していたことがわかる。また、３月２８日のように色の濃いものが上部に集中している場合には、組織全体においてコミュニケーションが活発だったことがわかる。

さらに、全体としては中央の３月１３日前後はコミュニケーションが少なく静かな雰囲気だったことが伺えるが、３月１９日以降は急激にコミュニケーションが増え、活性化している。実施例５では、このように組織全体の大きな波を捉えることができる。

この場合、上記の関係付け表示は、強さを示す特徴量を一方の軸に割り当て、多様性を示す特徴量を他方の軸に割り当てた二軸構成の座標平面上に人物に対応する記号をプロットした場合に得られる２次元の分布を、座標平面上に所定の基準で設定された主成分軸上の１次元の分布に変換して行う表示であり、組織コミュニケーション可視化システムは、所定の時点で実行したその関係付け表示を更に他の時点で同様に実行し、各時点における１次元の分布をその各時点が含まれる時系列に沿って１次元的に配置し、主成分軸を一方の軸に割り当て、時系列を他方の軸に割り当てた二軸構成の座標平面上の分布として表示して各時点間の１次元の分布の推移を表示する。

なお、色や色の濃さで人数を表すのではなく、１つの色を１人のメンバに対応させ、そのメンバがどのようなコミュニケーションを行ったかを追跡できるようにしても良い。
＜拡大図＞
図３３は、図３２の画面を拡大して表示しなおした場合の画面の例である。拡大した場合には、どのメンバがどの分割領域に属しているのか、また分割枠の移動経路を示す線を表示する。線は一部のメンバのみに注目して表示しても良く、全メンバについて表示しても良い。また、図３２ではメンバごとに異なる種類の線で表示している。
＜主成分軸への射影＞
図３４は、本発明の実施の形態５において、実施例１の図面から主成分軸を作成し、データを射影する場面での説明図である。

実施例１の方法を用いて１日分のデータを対面時間と対面人数の２軸上にプロットした図面上に、主成分軸を引き、全てのプロットデータから主成分軸への垂線を引く。垂線と主成分軸との交点をコミュニケーションを示す新たな値とする。このとき、主成分軸の末端を０、図面上の先端を１００とするなど、始点（ＲＮ＿０）と終点（ＲＮ＿Ｎ）の基準はあらかじめ決めておく。この主成分軸が実施例５（図３２）の縦軸となる。

この場合、上記の関係付け表示は、強さを示す特徴量を一方の軸に割り当て、多様性を示す特徴量を他方の軸に割り当てた二軸構成の座標平面上に人物に対応する記号をプロットした場合に得られる２次元の分布を、座標平面上に所定の基準で設定された主成分軸上の１次元の分布に変換して行う表示である。

なお、主成分軸は、プロットされたデータについて主成分分析を行った結果として決定されるものであるが、最小二乗法などを用いて求めた回帰直線を利用しても良い。また、長期間での時系列変化を表すために、どの日付においても軸は固定であった方が良い。そのため、表示に用いる期間における全ての日付、全てのメンバに関する実施例１での座標を求めた上で、それらの主成分軸を求め、その軸を固定して一日ずつの射影の計算に用いることも可能である。図３５のフローチャートでは、まず主成分軸を決定し、その後一日分ずつの計算を行う方法で説明する。
＜フローチャート＞
図３５は、本発明の第５の実施の形態において、図３の全体のフローチャートにおけるデータプロット（ＡＰＩＰ）のステップの詳細を示したフローチャートである。

データプロット（ＡＰＩＰ）の開始（ＩＰＳＴ）後、まず、表示に用いる全てのメンバ・全ての日付の対面時間と対面人数を計算する（ＩＰ４００）。さらに、上記の方法で主成分軸を決定し（ＩＰ４１０）、主成分軸の始点（ＲＮ＿０）と終点（ＲＮ＿Ｎ）を決定する（ＩＰ４２０）。始点（ＲＮ＿０）と終点（ＲＮ＿Ｎ）の間を等間隔に分割し、各分割枠を決定する（ＩＰ４３０）。分割数はあらかじめ適当な値に決定しておく。

次に日付を1つ選択し（ＩＰ４４０）、さらにメンバと1人選択する（ＩＰ４５０）。そのメンバのその日の対面時間と対面人数の値から、主成分軸への射影を取る（ＩＰ４６０）。さらに射影した値が何番目の分割枠に含まれるかを求め、対応する分割枠にカウントを加える（ＩＰ４７０）。このようにして、全メンバのカウントを完了したら（ＩＰ４８０）、図３９のような図面上の、対応する日付において、カウントした人数の多い領域を濃い色で塗る（ＩＰ４９０）。全ての日付についてプロットを完了（ＩＰ５００）したら終了（ＩＰＥＮ）とする。

本発明の第６の実施の形態について図面を参照して説明する。
＜実施例６の概要＞
実施例６では、実施例１と同様のプロセスで計算した対面人数と対面時間の２変数を、それぞれ色相と明るさに対応させることでコミュニケーションスタイルを1つの色で表現する。これによって、ある時間単位内での1人のコミュニケーションスタイルを1つの分割領域で示すことができるため、横軸に時系列変化、縦軸に組織に属する全メンバーを取り、これら全てのコミュニケーションスタイルを合わせて２次元平面上で表現することが可能になる。なお、軸に関しては、横軸に組織に属するメンバー、縦軸に時系列変化を取っても良い。また、他の要素を軸として用いることも可能である。

この場合、上記の関係付け表示は、強さを示す特徴量を色相および明るさのいずれか一方に割り当てると共に多様性を示す特徴量を色相および明るさのうちの他方に割り当てた単一の色調を生成して行う表示である。１人の人物について実行した関係付け表示を更に組織内の他の人物について同様に実行し、所定の単位時間内での各人物のコミュニケーションスタイルを各1つの分割領域に対応させて示し、その分割領域を１次元的に配置すれば、各人物間のコミュニケーションスタイルの相違を色調の変化として表示することができる。あるいはまた、１人の人物について所定の時点で実行した関係付け表示を更に他の時点でその１人の人物について同様に実行し、所定の単位時間内でのコミュニケーションスタイルを各時点につき各1つの分割領域に対応させて示し、その分割領域を１次元的に配置すれば、各時点間のコミュニケーションスタイルの推移を色調の変化として表示することができ、更には、その１人の人物について各時点で実行した関係付け表示を更に前記組織内の他の人物について同様に各時点で実行し、その各時点を含んで成る時系列上での各人物のコミュニケーションスタイルの推移を一方の軸に割り当て、コミュニケーションスタイルの各人物間の相違を他方の軸に割り当てた二軸構成の座標平面を生成すれば、組織のコミュニケーションスタイルの時系列的な変化と人物間の相違とを座標平面上に一括表示することができる。

図３６は本発明の第６の実施の形態において作成した表示の結果の一例である。横軸が時間、縦軸が組織に属するメンバーであり、横一行が1人のメンバーに関するコミュニケーションスタイルの時系列変化を表現するものとなる。なお、1つ分割領域の時間単位は任意に設定することが可能である。例えば、時間単位を１時間として２４の領域を並べ、横軸の端から端までで１日分を表現しても良い。また、時間単位を一日として、３６５の領域を並べ、横軸の端から端までで1年分を表現しても良い。

これによって、遠くの始点から俯瞰するとこれを一枚の図として見ることができ、組織全体でのその日の傾向や時間的な活発さの波を目で捉えられる。また、一部分を注視して見ると、その日に活発にコミュニケーションを行っていたのは誰か、ミーティングの行われている時間帯はいつか、などを捉えることができる。

図３７は、対面人数と対面時間を色に対応付けるために利用する色相環である。例えば、対面人数に色相を割り当て、総時間を明るさに割り当ててコミュニケーションスタイルの人物間の分布や時系列変化を表現する。ここで、色相は周期的に変化するものであるので、用いる色の分布としては例えば赤を最高値、青を最低値として色相環の全方位を用いないようにする（未使用の部分が存在する）。これは３６０度全てを用いるようにすると、最低値と最高値を示す色が同じ色になってしまい区別ができなくなるからである。

以上、本発明の各実施例によれば、例えば、人員管理、プロジェクト管理などによって生産性向上の支援を行うためのコンサルティング産業等において、実際の対面コミュニケーションデータから、組織に属するメンバのコミュニケーションスタイル、組織のコミュニケーションスタイル、下位組織のコミュニケーションスタイルを可視化することができる。

ＴＲ、ＴＲ２〜ＴＲ４ 端末
ＧＷ、ＧＷ２、ＧＷ３ 基地局
ＮＡ ネットワーク
ＳＳ センサネットサーバ
ＡＳ アプリケーションサーバ
ＣＬ クライアント。

Claims (8)

1. クライアントからの処理結果の要求を受け付ける要求受付部と、
   複数の人物の行動に関するデータであって、前記人物が他の人物または物体と近接していることを示す情報を含むデータである行動データを受け付ける行動データ受付部と、
   前記人物が携わる業務の評価である業務データを受け付ける業務データ受付部と、
   前記行動データから、前記人物に関する複数の特徴量を生成する生成部と、
   前記複数の特徴量と、前記業務データとの相関関係を算出する算出部と、
   前記相関関係に基づいて前記処理結果を生成し、前記クライアントに送信する送信部と、を有することを特徴とする業務向上支援システム。
2. 請求項１において、
   前記処理結果の要求は、前記要求受付部に対するデータまたは画像の依頼であることを特徴とする業務向上支援システム。
3. 請求項１において、
   前記業務向上支援システムは、複数の端末を含み、
   前記行動データには、前記端末が他の端末と対面したことを示す情報が含まれることを特徴とする業務向上支援システム。
4. 請求項１において、
   前記業務向上支援システムは、複数の端末を含み、
   前記行動データには、前記端末を装着した人物の動作または行動に関する情報が含まれることを特徴とする業務向上支援システム。
5. 請求項１において、
   前記行動データには、前記人物の場所に関する情報が含まれることを特徴とする業務向上支援システム。
6. サーバによって実行される業務向上支援方法であって、
   クライアントからの処理結果の要求を受け付ける工程と、
   複数の人物の行動に関するデータであって、前記人物が他の人物または物体と近接していることを示す情報を含むデータである行動データを受け付ける工程と、
   前記人物が携わる業務の評価である業務データを受け付ける工程と、
   前記行動データから、前記人物に関する複数の特徴量を生成する工程と、
   前記複数の特徴量と、前記業務データとの相関関係を算出する工程と、
   前記相関関係に基づいて前記処理結果を生成し、前記クライアントに送信する工程と、
   を有することを特徴とする業務向上支援方法。
7. クライアントのアプリケーションからの処理結果の要求を受け付ける要求受付部と、
   複数の人物の行動に関するデータであって、前記人物が他の人物または物体と近接していることを示す情報を含むデータである行動データを受け付ける行動データ受付部と、
   前記人物が携わる業務の評価である業務データを受け付ける業務データ受付部と、
   前記行動データから、前記人物に関する複数の特徴量を生成する生成部と、
   前記複数の特徴量と、前記業務データとの相関関係を算出する算出部と、
   前記相関関係に基づいて前記処理結果を生成し、前記アプリケーションに送信する送信部と、を有することを特徴とする業務向上支援システム
8. サーバによって実行される業務向上支援方法であって、
   クライアントのアプリケーションからの処理結果の要求を受け付ける工程と、
   複数の人物の行動に関するデータであって、前記人物が他の人物または物体と近接していることを示す情報を含むデータである行動データを受け付ける工程と、
   前記人物が携わる業務の評価である業務データを受け付ける工程と、
   前記行動データから、前記人物に関する複数の特徴量を生成する工程と、
   前記複数の特徴量と、前記業務データとの相関関係を算出する工程と、
   前記相関関係に基づいて前記処理結果を生成し、前記アプリケーションに送信する工程と、を有することを特徴とする業務向上支援方法。

Images