(57)【要約】【課題】  ネットワークを介してユーザから入力された質疑や応答などの情報がどのような状況に属するのかを可視化することができる情報処理システムを提供する。【解決手段】  本発明に係る好ましい情報処理システムは、ネットワークを介してユーザ間で送受される質疑応答される情報が、（１）業務プロセスのどの段階で、（２）問題解決ステップのどの段階で成されたのかを判別可能とし、さらに、特定のユーザの質問や応答などの情報の、（３）量と質、および（４）それが他の誰となされたかを可視化することを可能とする。【選択図】      図１６
2005301972.tif 000002
【特許請求の範囲】
【請求項１】
ユーザからの質疑や応答などを含む情報を蓄積し、当該蓄積した情報をネットワークを介して公開する機能を備えた情報処理システムであって、
質疑に関する質疑情報に加えて、当該質疑情報がどのような状況に属するかを判別するための属性情報を入力する質疑入力手段と、
入力された質疑情報および属性情報を蓄積する質疑蓄積手段と、
前記質疑情報が公開されたとき、当該質疑情報に対する応答情報を入力する応答入力手段と、
入力された応答情報を蓄積する応答蓄積手段と、
質疑応答の状況を表示するための条件を入力する条件入力手段と、
入力された条件に従い、前記質疑蓄積手段および応答蓄積手段に蓄積された質疑情報、属性情報および応答情報に基づき質疑応答の状況を表示する表示制御手段と、
を有する情報処理システム。
【請求項２】
前記表示制御手段は、質疑情報を入力したユーザと当該質疑情報に対する応答情報を入力したユーザとの質疑応答関係を可視化する、請求項１に記載の情報処理システム。
【請求項３】
前記表示制御手段は、属性情報毎に、質疑情報を入力したユーザと応答情報を入力したユーザとの質疑応答関係を可視化する、請求項２に記載の情報処理システム。
【請求項４】
前記表示制御手段は、特定のユーザを中心に、当該特定のユーザからの質疑情報に対する他のユーザからの応答情報の関係を可視化する、請求項３に記載の情報処理システム。
【請求項５】
前記表示制御手段は、当該特定のユーザから他のユーザの質疑に対する応答情報の関係を可視化する、請求項３または４に記載の情報処理システム。
【請求項６】
前記表示制御手段は、質疑情報を入力したユーザと応答情報を入力したユーザとのコミュニケーション頻度を可視化する、請求項１ないし５いずれか１つに記載の情報処理システム。
【請求項７】
前記表示制御手段は、質疑情報を入力したユーザと応答情報を入力したユーザとの関係を可視化したとき、ユーザからの指示に応答して、当該可視化された関係に対応する質疑情報および／または応答情報を表示する、請求項１ないし６いずれか１つに記載の情報処理システム。
【請求項８】
前記表示制御手段は、複数のユーザ間における質疑情報と応答情報間の質疑応答関係を可視化する、請求項１ないし７いずれか１つに記載の情報処理システム。
【請求項９】
前記表示制御手段は、特定のグループに含まれる複数のユーザの質疑応答関係を可視化する、請求項１ないし８いずれか１つに記載の情報処理システム。
【請求項１０】
前記表示制御手段は、特定のグループに含まれる複数のユーザ間の質疑応答量を可視化する、請求項９に記載の情報処理システム。
【請求項１１】
前記表示制御手段は、特定のグループに含まれる複数のユーザ間の質疑応答頻度を属性情報毎に可視化する、請求項９または１０に記載の情報処理システム。
【請求項１２】
前記表示制御手段は、特定のグループに含まれる複数のユーザ間の質疑とそれに対する応答をそれぞれ識別して可視化する、請求項１ないし１１いずれか１つに記載の情報処理システム。
【請求項１３】
前記属性情報は、予め用意された複数の定義の中から選択される、請求項１ないし１２いずれか１つに記載の情報処理システム。
【請求項１４】
前記複数の定義は、状況を時系列的に分割するものである、請求項１３に記載の情報処理システム。
【請求項１５】
前記複数の定義は、状況を種別的に分割するものである、請求項１３に記載の情報処理システム。
【請求項１６】
前記条件入力手段は、属性情報、質疑応答の期間、ユーザ名、グループ名の少なくとも１つの条件を入力する、請求項１ないし１５いずれか１つに記載の情報処理システム。
【請求項１７】
質疑入力手段、応答入力手段および条件入力手段は、予め決められたフォーマットの入力テンプレートを有する、請求項１ないし１６いずれか１つに記載の情報処理システム。
【請求項１８】
ユーザからの質疑や応答などを含む情報を蓄積し、当該蓄積した情報をネットワークを介して公開する機能を備えた情報処理システムにおける情報処理方法であって、
質疑に関する質疑情報に加えて、当該質疑情報がどのような状況に属するかを判別するための属性情報を入力する質疑入力ステップと、
入力された質疑情報および属性情報を蓄積する質疑蓄積ステップと、
質疑情報が公開されたとき、当該質疑情報に対する応答情報を入力する応答入力ステップと、
入力された応答情報を蓄積する応答蓄積ステップと、
質疑応答の状況を表示するための条件を入力する条件入力ステップと、
入力された条件に応答し、蓄積された質疑情報および応答情報に基づき質疑応答の状況を表示する表示ステップと、
を有する情報処理方法。
【請求項１９】
前記情報処理方法はさらに、予め複数の定義からなる属性情報を設定する設定ステップを含み、
前記質疑入力ステップは、質疑情報を入力するとき、前記設定ステップにて設定された複数の定義から該当する定義を属性情報として入力する、請求項１４に記載の情報処理方法。
【請求項２０】
前記表示ステップは、質疑情報を入力したユーザと当該質疑情報に対する応答情報を入力したユーザとの質疑応答関係を可視化する、請求項１８に記載の情報処理方法。
【請求項２１】
前記情報処理方法はさらに、可視化された質疑応答関係から質疑情報または応答情報を表示させるための指示を入力するステップを含む、請求項２０に記載の情報処理方法。
【請求項２２】
ユーザからの質疑・応答などを含む情報を蓄積し、当該蓄積した情報をネットワークを介して公開する機能を備えた情報処理システムにおけるプログラムであって、
質疑に関する質疑情報に加えて、当該質疑情報がどのような状況に属するかを判別するための属性情報を入力する質疑入力ステップと、
入力された質疑情報および属性情報を蓄積する質疑蓄積ステップと、
質疑情報が公開されたとき、当該質疑情報に対する応答情報を入力する応答入力ステップと、
入力された応答情報を蓄積する応答蓄積ステップと、
質疑応答の状況を表示するための条件を入力する条件入力ステップと、
入力された条件に応答し、蓄積された質疑情報および応答情報に基づき質疑応答の状況を表示する表示ステップと、
を有する情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してコミュニケーションされるユーザの質疑応答関係を可視化する情報処理システムに関し、特に、コンピュータ・ネットワークにおいて、ユーザが公開した質問および応答などの情報を、分かり易く分類し、整理して表示することが可能な情報処理システムに関する。
【０００２】
ある仕事をするグループのメンバの所在が分散しているとき、インターネット上のコンピュータシステムや電話などの通信システムを用いて、仕事に関するコミュニケーションが一般に行われている。こうしたコミュニケーションを円滑化するために、インターネットなどのネットワークを介してユーザが入力した質問やその応答などのテキストデータを、ネットワークコンピュータの記憶装置に蓄積させ、蓄積された情報を公開し、情報を共有するシステムが用いられている。
【０００３】
例えば特許文献１は、コンピュータネットワーク上で、ユーザからの有益な情報の公開を促進するために、公開された情報を他のユーザからの参照の頻度で、有益度を評価し、また、公開された情報について利用実績を評価するシステムを開示している。さらに、ユーザ間のコミュニケーションの有無をディスプレイ上に表現することを提案している。
【０００４】
また、特許文献２は、ネットワーク上のコミュニティにおけるコミュニケーション経過や内容をより理解しやすくし、またネットワーク上のコミュニティにおけるコミュニケーションをより円滑に進めるためのコミュニケーション方法またはコミュニケーションシステムを提供する。これによれば、コミュニケーションにおける情報単位を多層構造にし、一つの情報単位または複数の情報単位の組み合わせにより、コミュニケーションの経過や内容の表示、集計、コミュニケーションの目的や段階に応じたコミュニケーション機能の提供を行うこととしている。
【０００５】
また、特許文献３は、コンピュータネットワーク利用による掲示板システムに関し、ユーザが質問や回答を登録して公開することが可能である。特に、登録するユーザ自身が、登録時に、自分が答えらそうな知識のカテゴリーを申請したり、回答をするユーザ自身が、回答に関する属性を登録することができるものであった。その属性は、質問に対する本来の回答か、専門家または素人の質問か、自身の有無を表すものであった。
【０００６】
【特許文献１】特開平１０−８３３８６（特に図２６および図２７）
【特許文献２】特開２００３−２３３５５６
【特許文献３】特開２００１−２７３４３２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上述した従来技術におけるコミュニケーションの表示システムでは、グループのメンバであるのユーザの質問や応答などの個々の情報が、（１）業務プロセスのどの段階で、あるいは、（２）ユーザ個人の問題解決ステップのどの段階で成されたのか、判別することができないという課題があった。これに加えて、特定のユーザの質問や応答などの情報の（３）量と質、および（４）それが他の誰となされたか、も分からない課題があった。同様に、ある特定の業務グループの複数ユーザの質問や応答においても、（１）業務プロセスのどの段階で、（２）個々のユーザの問題解決ステップのどの段階で、（３）どのような量と質でなされたかを、（４）グループの複数ユーザ間で比較できることができないという課題があった。
【０００８】
本発明は、上記の従来の課題を解決するものであり、インターネットなどのネットワークを介してユーザが入力した質疑や応答などの情報を蓄積し、それらをネットワークを介して公開する機能を備えた情報処理システムにおいて、グループ間またはユーザ間の質疑や応答などの情報について、それらの情報がどのような状況に属するのかを判別して可視化することができる情報処理システムを提供すること目的とする。
【課題を解決するための手段】
【０００９】
本発明に係る情報処理システムは、ユーザからの質疑や応答などを含む情報を蓄積し、当該蓄積した情報をネットワークを介して公開する機能を備えており、以下の手段を有する。質疑に関する質疑情報に加えて、当該質疑情報がどのような状況に属するかを判別するための属性情報を入力する質疑入力手段と、入力された質疑情報および属性情報を蓄積する質疑蓄積手段と、前記質疑情報が公開されたとき、当該質疑情報に対する応答情報を入力する応答入力手段と、入力された応答情報を蓄積する応答蓄積手段と、質疑応答の状況を表示するための条件を入力する条件入力手段と、入力された条件に従い、前記質疑蓄積手段および応答蓄積手段に蓄積された情報に基づき質疑応答の状況を表示する表示制御手段とを有して構成される。これにより、質疑応答の状況は、少なくとも質疑情報とともに入力された属性情報を反映するため、質疑応答に関する情報がどのような状況に属して成されたかを容易に把握することができる。
【００１０】
好ましくは表示制御手段は、質疑情報を入力したユーザと当該質疑情報に対する応答情報を入力したユーザとの質疑応答関係を可視化する。つまり、質疑情報に対する応答が、どのユーザからどのユーザに向けられたものかを容易に把握することができる。
【００１１】
好ましくは表示制御手段は、属性情報毎に、質疑情報を入力したユーザと応答情報を入力したユーザとの質疑応答関係を可視化する。例えば、質疑応答関係にあるユーザ間を直線にて連結して表示させる。その際に、矢印等を用いて、どのユーザからどのユーザへの応答かを表示する。これにより、属性情報毎に、ユーザ間のコミュニケーションの指向性をより明確化することができる。
【００１２】
好ましくは、表示制御手段は、特定のユーザを中心に、当該特定のユーザからの質疑情報に対する他のユーザからの応答情報の関係を可視化する。これにより、状況を把握するユーザを基準とすることで、当該ユーザと他のユーザとの相対的なコミュニケーション関係をより明確化することができる。好ましくは表示制御手段は、当該特定のユーザから他のユーザの質疑に対する応答情報の関係を可視化する。これにより、当該ユーザの質疑に対する他のユーザの応答に加えて、他のユーザの質疑に対する当該ユーザの応答が表示され、ユーザ間の質疑、応答の関係をより明確化することができる。
【００１３】
好ましくは表示制御手段は、質疑情報を入力したユーザと応答情報を入力したユーザとのコミュニケーション頻度を可視化する。例えば、頻度の大きいユーザをディスプレイ上に相対的に大きく表示したりする。これにより、ユーザ間の関係の深さをより明確化することができる。
【００１４】
好ましくは表示制御手段は、質疑情報を入力したユーザと応答情報を入力したユーザとの関係を可視化したとき、ユーザからの指示に応答して、当該可視化された関係に対応する質疑情報および／または応答情報を表示する。これにより、どのような質疑内容を行ったのか、あるいは、どのような応答内容を行ったのかを、即座に表示できるので、利便性が高まる。
【００１５】
好ましくは前記表示制御手段は、特定のグループに含まれる複数のユーザの質疑応答関係を可視化するようにする。例えば、特定のグループに含まれる複数のユーザ間の質疑応答量を可視化したり、複数のユーザ間の質疑応答頻度を属性情報毎に可視化する。好ましくは、実施例の図３２に示すように、特定のグループの複数のユーザ間の質疑とそれに対する応答をそれぞれ識別して可視化する。これにより、グループのメンバであるユーザの質問や応答が、どのような量と質で成されたのかを、グループの複数のユーザ間で相対的に比較することができる。
【００１６】
好ましくは属性情報は、予め用意された複数の定義を含み、前記質疑情報を入力するとき、複数の定義の中から該当するものを選択する。属性情報の定義を予め複数用意することで、ユーザ間に統一した基準の属性情報を使用させることができる。
【００１７】
属性情報に含まれる複数の定義は、状況を時系列的に分割するものであってもよい。例えば、実施例にあるように、プロジェクトにおける業務プロセスの各段階（計画、コントロール、実施、終結など）を属性定義に割り当てても良い。また、複数の属性は、状況を種別的に分割するものでもよい。例えば、実施例にあるように、問題解決ステップにおける、問題設定、対策、実施、評価などである。
【００１８】
本発明に係る情報処理方法は、ユーザからの質疑や応答などを含む情報を蓄積し、当該蓄積した情報をネットワークを介して公開する機能を備えた情報処理システムにおいて、以下のステップを有する。質疑に関する質疑情報に加えて、当該質疑情報がどのような状況に属するかを判別するための属性情報を入力する質疑入力ステップと、入力された質疑情報および属性情報を蓄積する質疑蓄積ステップと、質疑情報が公開されたとき、当該質疑情報に対する応答情報を入力する応答入力ステップと、入力された応答情報を蓄積する応答蓄積ステップと、質疑応答の状況を表示するための条件を入力する条件入力ステップと、入力された条件に従い、蓄積された質疑情報、属性情報および応答情報に基づき質疑応答の状況を表示する表示ステップとを有する。
【００１９】
本発明に係る情報処理プログラムは、ユーザからの質疑・応答などを含む情報を蓄積し、当該蓄積した情報をネットワークを介して公開する機能を備えた情報処理システムにおいて以下のステップを有する。質疑に関する質疑情報に加えて、当該質疑情報がどのような状況に属するかを判別するための属性情報を入力する質疑入力ステップと、入力された質疑情報および属性情報を蓄積する質疑蓄積ステップと、質疑情報が公開されたとき、当該質疑情報に対する応答情報を入力する応答入力ステップと、入力された応答情報を蓄積する応答蓄積ステップと、質疑応答の状況を表示するための条件を入力する条件入力ステップと、入力された条件に応答し、蓄積された質疑情報、属性情報および応答情報に基づき質疑応答の状況を表示する表示ステップとを有する。
【発明の効果】
【００２０】
本発明に係る情報処理システムによれば、質疑情報を入力するときに、その質疑情報がどの状況に属するかを判別するための属性情報を併せて入力するようにしたので、ユーザ間の質疑応答の関係を表示するときに、それがどの状況においえ行われたコミュニケーションであるかを認識することができる。さらに、質疑入力を行ったユーザと質疑入力に対する応答入力を行ったユーザとの関係を可視化することで、誰の質疑に対して誰が答えたのか、ということを一見して認識することができる。さらに、条件入力手段により、例えば特定グループを選択することにより、当該特定グループのユーザ間の質疑応答がどのような状況においてどのような質および量で成されたかを可視化させることができ、グループのユーザ間のコミュニケーションの認識を容易に把握することができる。
【発明を実施するための最良の形態】
【００２１】
本発明に係る情報処理システムは、好ましくは、インターネット等のネットワークを介して接続されたサーバとクライアント間のコミュニケーションシステムにおいて実施される。以下、図面を参照して詳細を説明する。
【実施例】
【００２２】
図１は、本実施例に係る情報処理システムの構成例を示す図である。同図に示すように、情報処理システム１は、サーバ１００と、クライアント２００と、両者を接続するコンピュータネットワーク３００とを有している。同図には、代表的なクライアント２００を１つ示しているが、勿論、これ以外にも複数のクライアントが接続される。情報処理システム１において、サーバ１００は、クライアント２００からの質疑・応答などを含む情報を蓄積し、当該蓄積した情報をネットワーク３００を介してクライアント２００へ公開する機能を備えている。
【００２３】
サーバ１００は、ＣＰＵ１１０、主記憶装置１２０、入力装置１３０、外部記憶装置１４０および表示装置１５０を含み、これらはバス１６０を介して相互に接続される。外部記憶装置１４０は、好ましくはハードディスク等の大容量記憶装置を用い、後述するように、クライアント３００から入力された質問やその応答に関する情報を蓄積するデータベースを構成する。さらに、外部記憶装置１４０は、種々のプログラムを記憶し、ＣＰＵ１１０はそれらのプログラムに従い動作を実行する。
【００２４】
クライアント２００は、ＣＰＵ２１０、主記憶装置２２０、入力装置２３０、外部記憶装置２４０および表示装置２５０を含み、これらはバス２６０を介して相互に接続される。外部記憶装置２４０は、サーバ１００からのデータを記憶したり、プログラムを記憶する。また、ＣＰＵ２１０は、そのプログラムに従い各部を制御する。
【００２５】
サーバ１００およびクライアント２００は、それぞれ通信機能を有し、ネットワーク３００を介して相互に情報の送受を行う。ネットワークは、例えば、インターネットやＬＡＮなどである。
【００２６】
本実施例に係る情報処理システム１は、図２に示すように、３つの基本的機能を有している。すなわち、質疑応答属性定義手段４００、質疑応答手段５００および質疑応答状況表示手段６００である。
【００２７】
質疑応答属性定義手段４００は、属性を入力するための属性定義入力手段４２０と、入力された属性を保存する属性定義保持手段４４０とを含んでいる。質疑応答属性定義手段４００は、質疑応答手段５００および質疑応答状況表示手段６００が実行される前に実行されるべきものであり、いわば、質疑応答のための初期設定である。
【００２８】
質疑応答属性定義手段４００の動作を図３のフローチャートを参照して説明する。左側はクライアント側の動作、右側はサーバ側の動作である。初めに、クライアント２００の表示装置２５０の画面から、入力装置２３０に含まれるユーザインターフェースのボタンなど操作して、質疑応答のための属性を定義するための入力画面を呼び出す（ステップＳ１０１）。
【００２９】
クライアント２００からの呼び出し要求がサーバ１００に伝えられると、サーバ１００は、属性定義入力用の画面をサーバ側のプログラムで作成し、これをクライアント１００へ送信する（ステップＳ１０２）。
【００３０】
クライアント２００は、属性定義入力画面を受け取り、図４に示すような属性定義入力画面を表示装置２５０に表示させる。本実施例では、質疑応答に関する属性を、業務プロセスと問題解決ステップとのそれぞれにおいて定義する。図４に示すように、属性定義入力画面は、業務プロセスフィールドＦ１と、問題解決フィールドＦ２とを有する。業務プロセスフィールドＦ２には、プロジェクト名４０２、業務プロセスの属性４０４、登録済みの属性リスト４０６が含まれている。問題解決ステップフィールドＦ２には、問題解決ステップの属性４１２および登録済み属性リスト４１４が含まれている。
【００３１】
属性定義入力画面は、個人が抱える問題に関する、問題解決のステップを表わす属性４１２を定義するためのユーザ・インターフェースと、その問題に関連して、個人が属する仕事を遂行する組織やチームを表すプロジェクト名４０２や、そのプロジェクト内での業務プロセスのステップを表わす属性４０４を定義するユーザ・インターフェースである。さらに、組織、グループやチームの構成員であるメンバを定義するためのユーザインターフェースを加えてもよい。
【００３２】
問題解決のステップを表わす属性４１２の設定において、管理者などのユーザは、属性を入力するテキスト枠に属性４１２を入力し、登録ボタンを押すことで、これを登録済み属性リスト４１４に登録することができる。この例では、属性名として、「原因」を入力し、これを登録ボタンにより登録するところを表示している。登録ボタンを押すと、「原因」が登録済み属性リスト４１４に登録される。この例では、問題設定、対策、実施、評価の属性が既に設定されている。リスト中の属性の順序は、属性名の行をドラッグアンドドロップ、置き換えることができる。また、属性は、それを選択して削除ボタンを押せば、登録済み属性リスト４１４から削除することができる。属性４１２は、後述するトリガー質問入力画面などで、問題解決のステップを選択するチェックボックスとして表示される。業務プロセスの属性４０４についても同様の操作により設定、削除、並べ替えを行うことができる。図の例は「立ち上げ」を入力しこれを登録するところを表示している。また、属性リスト４０６には、計画、コントロール、実施、終結が既に登録されている。問題解決ステップの属性および業務プロセスの属性は、予めテンプレートに用意された複数の定義の中から選択するようにすることができる。
【００３３】
再び、図３のフローチャートに戻り、クライアント２００から図４に示す質疑応答属性定義について登録ボタン４１６が押下されると、これらの定義が入力されたことになる（ステップＳ１０３）。サーバ１００は、定義の入力を受け付けると、質疑応答保持手段４４０により質疑応答属性定義を保存する（ステップＳ１０４）。
【００３４】
属性定義保持手段４４０は、図５に示すようなデータ構造により定義を保存する。図５（ａ）のデータ構造は、プロジェクトＩＤに関し、入力されたプロジェクト名に自動的にプロジェクトＩＤを与えて、これらを登録する。プロジェクトＩＤは、シーケンシャルに付与され、重複しない。図５（ｂ）は、業務プロセスＩＤに関し、各プロジェクト毎の業務プロセス名（属性）に自動的に業務プロセスＩＤを付与して登録する。図５（ｃ）は、問題解決ステップＩＤに関し、各プロジェクト毎の問題解決ステップ名（属性）に自動的に問題解決ステップＩＤを付与して登録する。業務プロセスＩＤは、対応するプロジェクトＩＤが同じであれば重複しない。問題解決ステップＩＤは、対応するプロジェクトＩＤが同じであれば重複しない。また、表示順序は、登録済み属性リスト４０６、４１４のリスト順に対応する。
【００３５】
このようにしてサーバ１００において属性定義が保持された後、サーバ１００は登録成功の画面を生成し、これをクライアント２００へ送付する（ステップＳ１０５）。クライアント２００は、登録成功画面を受領し、定義属性が登録されたことを確認する（ステップＳ１０６）。
【００３６】
なお、クライアント２００とサーバ１００の間の通信プロトコルは、例えば、ＴＣＰ／ＩＰやＨＴＴＰプロトコルなど公知のものでよい。クライアント用のユーザインターフェースは、ＨＴＭＬやＸＭＬなどのマークアップ言語で作成されたものを表示することができる。さらに、図形などのグラフィックスは、Ｊａｖａ（登録商標）やＯｐｅｎＧＬなど、専用のプログラミング言語やライブラリ関数で作成されたものでもよい。ユーザインターフェースやグラフィックスを作成するプログラムは、クライアント側で処理されるものであっても良いし、また、サーバ側で処理されるものであっても良い。あるいは、それらを作成するプログラムをサーバからクライアントへ送ってから、クラインと側で実行しても良い。ユーザインターフェースやグラフィックスを作成するプログラムは、その作成や表示の最中に、ユーザからの指示で、クライアントとサーバ間の通信を行っても良い。サーバ側でのデータの保持手段の例として、Ｏｒａｃｌｅなどの関係データベースシステムを利用しても良い。これらの違いは、公知の技術であり、プログラムの作り方の違いなので、フローチャート上には、その差異を示していない。
【００３７】
次に、質疑応答手段５００を説明する。質疑応答手段５００は、トリガー質問入力手段５２０、質疑応答履歴表示手段５４０、応答入力手段５６０および質疑応答保持手段５８０を含んでいる。質疑応答保持手段５８０は、トリガー質問入力手段５２０および応答入力手段５６０によって入力された情報をサーバ１００の外部記憶装置１４０に保存する機能を有する。
【００３８】
トリガー質問入力手段５２０の動作を図６のフローチャートを参照して説明する。始めに、クライアント２００からトリガー質問の入力の画面の呼び出しが成される（ステップＳ２０１）。このとき、ユーザは、特定のプロジェクト名を指定する。この呼び出しに応答してサーバ１００は、図４の属性定義保持手段で保持された属性を参照し、指定されたプロジェクトについてのトリガー質問の入力画面を生成し、これをクライアント２００へ送付する（ステップＳ２０２）。
【００３９】
クライアントの表示装置２５０には、図７に示すようなトリガー質問の入力画面が表示される（ステップＳ２０３）。トリガー質問は、ユーザがコンピュータネットワーク上で、あるテーマについて最初に開始する質問で、これに応じて他のユーザが応答を入力する。プロジェクト名「社内プロジェクトの実態調査」において、ユーザ名：Taguchiのユーザが、トリガー質問のテーマであるタイトル「調査対象にするプロジェクトについて」５０２をテキスト入力し、業務プロセスの属性５０４として、「計画」をチェックボックスで指定し、問題解決ステップの属性５０６として、「対策」をチェックボックスで指定し、質問文５０８をテキスト入力する。そして、登録ボタン５１０を押すことにより、入力画面の内容がサーバ１００へ送信される。これらの動作は、トリガー質問入力手段５２０によって行われる。
【００４０】
サーバ１００は、クライアントからのトリガー質問を入力し、これを保存する（ステップＳ２０４）。この動作は、質疑応答保持手段５８０によって行われる。トリガー質問の内容は、図８に示すようなデータ構造によって保存される。図８は、トリガー質問が登録されたときに、データが保持されるデータ構造である。図７のトリガー質問入力画面での入力が登録される処理の時に、トリガー質問ＩＤと登録日が自動的に設定され、保持される。トリガー質問ＩＤは、このシステムにおいて重複しない番号である。このＩＤ番号によって、表内の行を特定することが可能であり、トリガー質問を特定することができる。また、プロジェクトＩＤ、業務プロセスＩＤ、問題解決ステップＩＤは、図４の属性定義手段に対応するものが保持される。トリガー質問者名（ユーザＩＤ）、タイトル、質問文は、図７の入力画面に対応するものが保持される。属性についての値は、チェックボックスなので２値である。業務プロセスのステップを属性についても同様である。
【００４１】
また、図７の入力画面のデータを見易くするために、これを図８の見出し行の次の一行目に示している。そのほかの行は、同様のトリガー質問入力によって、プロジェクト名「社内プロジェクトの実態調査」（プロジェクトＩＤ：P0001）におけるトリガー質問が、Ｑ０００１からＱ０００９まで保持されている。なお、図中、質問文、応答文、その他の行は、記載の省略のために、「…・」で示している。
【００４２】
再び、図６のフローチャートに戻り、サーバ１００は、登録成功の画面を生成し、これをクライアント２００へ送付する（ステップＳ２０５）。クライアント２００は、登録成功画面を受け取り、これを確認する（ステップＳ２０６）。
【００４３】
次に、質疑応答履歴表示手段５４０の動作を図９のフローチャートを参照して説明する。クライアント２００は、例えば、プロジェクト名「社内プロジェクトの実態調査」（プロジェクトID：P0001）において既に登録された、トリガー質問のタイトルの一覧が表示された画面などから、閲覧したいトリガー質問を選択する。この例では、タイトル「調査対象にするプロジェクトについて」のトリガー質問が選択される（ステップＳ３０１）。
【００４４】
質疑応答履歴表示手段５４０は、トリガー質問とそれに対応した応答を同時に示す。図１１は、トリガー質問を登録した直後に、質疑応答を表示するものである。登録されたときに、自動的に付けられたトリガー質問ＩＤ：Q0001、登録日、登録された業務プロセスの属性名、問題解決ステップ、トリガー質問のユーザ名、質問の内容Ｑが、表示されている。一番下には、このトリガー質問に対する応答を入力するために、応答入力画面を呼び出すためのボタンが表示されている。
【００４５】
図１２は、図１４による応答が入力されたあとの画面の例である。トリガー質問Ｑの下に応答Ｒが表示されている。応答ＩＤ、応答したユーザ名、登録日、応答の内容が表示されている。同じく、一番したに応答の入力画面を呼び出すボタン「応答入力」が表示されている
【００４６】
質疑応答履歴表示手段５４０は、例えば、図８の中から、タイトル「調査対象にするプロジェクトについて」がある行を選択し、トリガー質問ＩＤ（Ｑ０００５）を確認する。このトリガー質問に対応する応答があるのかどうかを、応答ＩＤを保持した図１０のデータで調べる。仮に、探してない場合には、図１１のような質疑応答の表示画面を生成してクライアントに送付する。この場合、トリガー質問（Ｑ０００５）に関する応答は、誰も登録していないことを意味している。図１０に示すように、すでに応答がある場合には、Ｑ０００５に対応する応答ＩＤ：Ｒ０００７があることがわかる。この場合、図８のＱ０００５の行と、図１０のＲ０００７の行をに基づいて、図１２に示すような質疑応答の表示画面を生成して送付する。
【００４７】
次に、クライアント２００は、ユーザ・インターフェースのボタンなどで、質疑応答の履歴の表示を要求する（ステップＳ３０２）。サーバ３００は、そのトリガー質問に対応するトリガー質問の内容、応答の内容を、図８および図１０のデータから抽出し、その表示用の画面を作成して、クライアント側に送付する。
【００４８】
クライアント２００は、図１２に示すような質問Ｑに対する応答Ｒが成された質疑応答履歴を閲覧する（ステップＳ３０４）。応答Ｒがないときは、図１１のような質問履歴を閲覧することも可能である。
【００４９】
次に、応答入力手段５６０の動作を図１３のフローチャートを参照して説明する。クライアント２００は、図１２に示すような質疑応答履歴の表示画面の応答入力のボタンを押下し、応答入力の呼び出しを行う（ステップＳ４０１）。この呼び出しを受けたサーバ１００は、図８に示すデータを参照し、図１４に示すような応答入力画面を生成し、これをクライアント２００へ送付する（ステップＳ４０２）。
【００５０】
クライアント２００は、送信された応答入力画面を表示装置２５０に表示させ、そこで応答内容の入力を行う（ステップＳ４０３）。図１４に示す応答入力画面には、プロジェクト名、業務プロセスの属性、問題解決ステップの属性、トリガー質問タイトル、トリガー質問ＩＤ、トリガー質問ユーザ名（Taguchi）、登録日が書誌的事項として表示されている。この例は、ユーザである、Ishidaが、図７のトリガー質問に対する応答を入力するためのユーザインターフェースである。このユーザインターフェースは、図１１、図１２の応答入力ボタンを押すことによって表示される。
【００５１】
クライアント２００からの入力がサーバ３００へ送信され、質疑応答保持手段５８０によりサーバにおいて登録される（ステップＳ４０４）。クライアントからの応答内容は、上記した図１０に示すデータ構造によって保持される。
【００５２】
図１４の応答入力画面での入力が登録される処理のときに、応答ＩＤと登録日は、自動的に設定され保持される。応答ＩＤは、このシステムにおいて重複しない番号である。この番号によって、図１０に示す表の行を特定することができるし。すなわち一つの応答に関する情報を特定することができる。また、プロジェクトＩＤ、トリガー質問ＩＤも図５の属性定義手段に対応するものが保持される。また、応答ユーザ名（ユーザＩＤ）、業務プロセスＩＤ、問題解決ステップＩＤ、応答文は、図１４の画面に対応するものが保持される。そのほかの行は、同様の処理によって、プロジェクト名「社内プロジェクトの実態調査」（プロジェクトＩＤ：P0001）における、トリガー質問毎の応答の内容が登録されている。図１４の応答を見やすくするように表の見出し行の次の一行目に示している。この応答ＩＤは、Ｒ０００７である。
【００５３】
次に、サーバ１００は、登録成功の画面を生成し、これをクライアント２００に送信し（ステップＳ４０５）、クライアント２００においてこれを確認する（ステップＳ４０６）。
【００５４】
次に、図２に示す質疑応答状況表示手段６００について説明する。質疑応答状況表示手段６００は、状況把握条件入力手段６２０、状況表示手段６４０および状況保持手段６６０を含んでいる。
【００５５】
状況把握条件入力手段６２０は、特定のユーザの質疑応答の状況を把握する時、表示の条件を入力するインターフェースである。条件入力は、例えば図１５に示すように、蓄積されたデータの範囲を設定する期間６２１、状況を把握するユーザ名６２２、業務プロセスの属性６２３、問題解決ステップの属性６２４、トリガー質問の表示の有無６２５、および応答の表示の有無６２６を設定する。
【００５６】
図１５の表示例では、プロジェクト名が、「社内プロジェクトの実態把握」、について、期間が２００４年３月１日から３月３１日の間に、ユーザ名：Taguchiのユーザについて、そのユーザの業務プロセスが「計画」の段階において、問題解決の「全ステップ」で、トリガー質問と応答を表示する、という条件を、メニュー形式のユーザインターフェースで選択している。最下部には、表示の指示をサーバへ送る表示ボタン６２７がある。メニュー形式のユーザ・インターフェースで指定できるようになっているが、この方法に限定する必要はない。
【００５７】
状況表示手段６４０は、図１５で指定された表示条件がクライアントからサーバに送られると、サーバは、その表示条件に従いデータ処理を行い、表示データをクライアントに送付する。そして、クライアントは、図１６に示すような質疑応答の状況を表示装置に表示する。
【００５８】
図１６の状況表示画面は、プロジェクト名、期間、ユーザ名、業務プロセスについてのテキスト表示と、問題解決ステップの各属性毎に、ユーザ間の質疑、応答の関係が矢印および図形を用いて表示されている。
【００５９】
プロジェクト名は、「社内プロジェクトの実態把握」、業務プロセスは、「計画」、ユーザ名は、「Taguchi」、トリガー質問および応答の表示あり、が図１６に示されている。これは、図１５の条件入力に対応している。トリガー質問と応答は、問題解決ステップ別（属性毎）に分類されてある。各トリガー質問と応答に関わった他のユーザとの間が矢印によって結ばれ、矢印方向により情報の方向が識別できるようになっている。
【００６０】
ここでは、ユーザ名：Taguchiのユーザ６４２が、問題解決ステップの「問題設定」においてトリガー質問を４件ほど発信している。一つのトリガー質問は、白い太い軸の上向き矢印Ｐ１で示される。その４件は、質問の発生時間順に上方向に４つ積み重ねて表示される。さらに、問題解決ステップの「対策」のステップにおいて、トリガー質問を１件発信している。同じく「対策」のステップにおいて、７件の応答を出している。それらは、黒の太い軸の上向き矢印Ｐ２によって示されている。
【００６１】
さらに、ユーザ名：Taguchiのユーザのトリガー質問に応答したユーザ名と、ユーザ名：Taguchiのユーザが応答したユーザが表示されている。ユーザ名：Yamadaを表わす楕円形６４４からは、ユーザ名：Taguchiのトリガー質問に対し、実線の矢印が６本描画されている。これは、Taguchiの４件のトリガー質問のそれぞれについて、Yamadaが６件の応答を行ったことを意味している。６件のうち、３件は、一つのトリガー質問に対して応答していることが示されている。
【００６２】
「対策」ステップでは、Taguchiは、１件のトリガー質問を発していて、それにIshida(楕円６４４)が応答している。また、Taguchiは、７件の応答をしているが、そのうち、３件は、Yamada(楕円６４６)のトリガー質問への応答であることがわかる。同様に、Taguchiは、Ishidaのトリガー質問に対して、３件の応答をしている。同じく対策ステップでは、Kim(楕円６４８)のトリガー質問に対して、1件の応答をしている。Yamada, Ishida, Kimのトリガー質問は、図１６には示していないが、楕円の中などに何らかの図形や文字を用いて、表示してもいい。また、Yamada、Ishida、Kimを基準とした表示画面を行いたいときには、図１５の条件入力において、「状況を把握するユーザ名」において選択すればよい。      
【００６３】
図１６では、Taguchiのトリガー質問に応答したユーザは、YamadaとIshidaであり、Taguchiが応答したユーザ、すなわちトリガー質問を発したユーザは、Yamada、Ishida、Kimであることがわかる。このことは、Taguchiに関係のある他者は誰であるのか、また、その関係は、問題解決のどのようなステップ(属性)で、どのような質疑応答で、成り立っているのか、を把握することができる。
【００６４】
Taguchiに関係したユーザのユーザ名は、楕円の中に記載され、それぞれ、楕円の大きさが異なっている。この楕円の大きさは、Taguchiとの関わりの程度を表わしている。応答の件数が多い場合には、楕円の大きさを大きくしている。応答が少ない場合には小さくしている。TaguchiとYamadaとの間では、あわせて９件の応答があり、Ishidaとの間では４件、Kimとの間では１件である。これらの件数に応じて楕円６４４、６４６、６４８の大きさを変えている。これにより、Taguchiとのつながりの深いユーザを、業務プロセス別、および、問題解決ステップ別に、容易に把握することができる。
【００６５】
楕円の大きさは、応答の件数に比例して決めることとしたが、応答の質の評価を加味して、大きさ、色、形を変えるようにしてもよい。つまり、トリガー質問をしたユーザが応答を受けたら、その応答について、３段階くらいの評価基準、たとえば、「有益だった」、「どちらともいえない」、「有益でなかった」などで、応答を受けたユーザ（＝トリガー質問をしたユーザ）が評価してもよい。また、短いコメント文を加えてもよい。それらの評価情報を、スコア化して、楕円の大きさ、色、形に反映することが可能であり、これにより、質疑応答の質を可視化することができる。
【００６６】
さらに、質疑応答の内容を詳しく知りたいときには、図１６の画面を利用し、それらを閲覧することができる。例えば、Taguchiは、問題設定のステップで、トリガー質問を４つ発していることを上向きの白い太い矢印で表わしているが、その矢印をクリックすることで対応するトリガー質問の内容を表示させることができる。質疑応答履歴表示手段５４０により、図１１のような画面を表示させるようにしても良い。同様に、白い太い上向きの矢印に向かっている、Yamadaからの実線の矢印をクリックすると、トリガー質問とそれに対応するYamadaの応答の内容を表示させるようにしてもよい。例えば、図１２に示すようなトリガー質問とその応答の対が表示される。
【００６７】
このように質疑応答の状況を図１６のように表示することで、以下のようなときに優れた効果がある。
（１）業務プロセスの計画段階において、ユーザＡが、最もサポートした相手のユーザは誰かを知りたいとき；
（２）ユーザＡを、最もサポートしてくれたユーザが、誰かを知りたいとき；
（３）ユーザＡが、問題解決のどのステップで、周辺ユーザと質疑応答をして、問題解決を相互に支援しているか、または、していないかを知りたいとき；
（４）ユーザＡが、業務プロセスのどの段階で、周辺ユーザと質疑応答をして、問題解決を相互に支援しているか、または、していないかを知りたいとき。
【００６８】
さらに、ユーザを、予め決められたメンバから構成されるプロジェクトのメンバに適用すれば、プロジェクト内の問題解決が、メンバのコミュニケーションの協力によりどのように実施されているかを把握することができる。プロジェクトチーム毎に比較して、長所があれば、プロジェクトチームとして誉めて評価することができ、弱点があれば、それを改善するようにすることができる。
【００６９】
次に、状況保持手段６６０について説明する。状況保持手段６６０は、状況表示手段５４０が図１６に示す質疑応答の状況を表示するときに必要なデータを保持する。必要なデータは、図１５に示す表示条件入力に従い、蓄積された図８および図１０のデータに基づき生成され、かつ保持される。
【００７０】
図１７(ａ)、（ｂ）、（ｃ）までは、Taguchiの登録したトリガー質問、それに対する応答、およびその応答したユーザ毎の応答件数についてのデータである。図１８（ａ）、（ｂ）、（ｃ）までは、Taguchiが対応した応答、それに対するトリガー質問、および応答したユーザ毎の応答件数についてのデータである。
【００７１】
図１７（ａ）は、Taguchiが登録したトリガー質問ＩＤと、それにおける問題解決ステップ（属性）ＩＤを表している。これは、図８に示すデータから抽出される。プロジェクトＩＤをP0001，業務プロセスを計画、トリガー質問者名をTaguchi、登録日の期間を２００４年３月１日から３１日を、表示条件として入力したとき、図８から該当するデータが検索される。図１２では、白い太い上向き矢印に相当するデータである。
【００７２】
図１７（ｂ）は、図１７（ａ）で抽出されたトリガー質問ＩＤ（Ｑ０００１、Ｑ０００２、Ｑ０００３、Ｑ０００４、Ｑ０００５）に対する応答ＩＤとその応答を登録したユーザのＩＤの一覧である。図１０に対して、図１７（ａ）でわかったトリガー質問ＩＤを条件に検索する。ここで、Taguchiのトリガー質問に対する応答のＩＤとその応答を発したユーザＩＤがわかることになる。図１６で言えば、Taguchiのトリガー質問を表す上向きの白い太い矢印に対して、他のユーザの楕円から伸びる実線の矢印に相当する。
【００７３】
図１７（ｃ）は、Taguchiのトリガー質問に対して、応答をあたえたユーザごとに、応答の件数を表している。これは、図１７（ｂ）の「応答したユーザＩＤ」の列をカウントし、ユーザ毎の合計を算出する。この件数により、ユーザをあらわす楕円の大きさを決める。
【００７４】
図１８（ａ）は、Taguchiが、他のユーザのトリガー質問に対する応答を、問題解決ステップ毎に並べ、それらの応答した相手のユーザＩＤを対応させている。これには図１０のデータを用いる。プロジェクトＩＤをP0001，業務プロセスＩＤを「計画」を表す0002、応答ユーザ名をTaguchi、登録した期間を２００４年３月１日から３１日の条件にしたときに、この条件に該当するデータが図１０から検索される。これは、図１６の表示において、黒い太い上向き矢印と、そこから、他のユーザの楕円に伸びる実線の矢印を表している。
【００７５】
図１８（ｂ）は、図１８(ａ)において、トリガー質問ＩＤ（Ｑ０００６、Ｑ０００７、Ｑ０００８、Ｑ０００９）に対応するユーザＩＤを、図８から検索したものである。図１８（ａ）において、Taguchiが応答したトリガー質問は、Ｑ０００６、Ｑ０００７、Ｑ０００８、Ｑ０００９で、それぞれに対する応答の件数は、Ｑ０００６が２件、Ｑ０００７が１件、Ｑ０００８が３件、Ｑ０００９が１件である。これらのトリガー質問ＩＤをもとに、図８のトリガー質問ＩＤの列を調べ、対応するトリガー質問者名を調べる。このことは、図１６で言えば、Taguchiが応答した応答先のユーザを決定するもので、Taguchiが何件の応答をしたかを表すものである。
【００７６】
図１８（ｃ）は、トリガー質問を発したユーザが、それぞれ、Taguchiから、何件の応答を受けとったかを表すものである。これにより、ユーザの楕円の大きさを計算するときに参考にする。
【００７７】
次に、質疑応答状況表示手段の全体の動作を図１９のフローチャートに示す。はじめに、クライント側で、ユーザが指定したプロジェクト、例えば「社内プロジェクトの実態把握」（プロジェクトＩＤ：Ｐ０００１）について、その質疑応答状況の表示のための条件を入力する画面を呼び出す（ステップＳ５０１）。
【００７８】
サーバはその呼び出しにより、図５の属性定義保持手段に保持されたプロジェクトＩＤ（Ｐ０００１）に関する属性を参考にして、メニューを含めたユーザインターフェースを生成してクライアント側に送る（ステップＳ５０２）。ここでは、サーバ側で画面を作るとしたが、画面を作るプログラムをクライアントに送って、クライアント側で作成してもよい。その場合は、図５の属性定義データをクライアント側から呼び込む場合がある。
【００７９】
ユーザは、そのメニュー画面で、状況把握の条件を設定して、表示ボタンを押して、表示の処理の開始をサーバ側に伝える（ステップＳ５０３）。
【００８０】
サーバによる状況表示の処理が行われる。処理の結果がクライントへ送付され（ステップＳ５０４）、クライアントにおいて、ユーザがTaguchiの質疑応答の状況を閲覧する（ステップＳ５０５）。
【００８１】
次に、状況表示手段６４０の動作を図２０のフローチャートを参照して説明する。始めに、図１５に示す状況条件入力手段において、特定ユーザのトリガー質問、および応答を表示する（ステップＳ６０１）。サーバにおける処理は、表示の条件に応じて異なる。ステップＳ６１１からＳ６１４は、トリガー質問のみを表示する場合であり、ステップＳ６２１からＳ６２４は、応答のみを表示する場合、そして、ステップＳ６３１からＳ６３６は、トリガー質問と応答の両方を表示する場合である。最後の処理は、図１６に示す状況の表示に該当する。
【００８２】
トリガー質問のみを表示する場合、図８のデータについて、表示条件入力（図１５）で指定された、プロジェクト、期間、状況を把握するユーザ名に従い、該当するデータを検索し、図１７(ａ)のようなデータを算出する（ステップＳ６１１）。この場合、Taguchiのトリガー質問を、問題解決ステップの情報をともなって集めることができる。
【００８３】
次に、図１７（ａ）のトリガー質問ＩＤのリストに基づいて、図１７（ｂ）のデータを算出する（ステップＳ６１２）。次に、図１７（ｂ）のデータに基づいて、トリガー質問に対応して応答をしたユーザの一覧と、ユーザ毎の応答件数を作成する（ステップＳ６１３）。この例では、Taguchiのトリガー質問に対して、Yamadaが６件、Ishidaが１件の応答をしている。
【００８４】
上記のステップで生成され、かつ保持されたデータに基づき、状況を可視化する図形を生成する（ステップＳ６１４）。図形生成のために、上記した図１７（ａ）ないし図１７（ｃ）のデータが利用される。
【００８５】
最初に、ユーザTaguchiを表わす楕円と、問題解決ステップを区別する矩形と、それらを、結ぶ線を描く。次に、図１７（ａ）のデータを参照し、問題解決ステップ（属性）毎に、白い太い上向き矢印を、トリガー質問の件数だけ描画する。図１６でいえば、問題設定の四角い図形の上の４本の白く太い上向き矢印と、対策の図形の上の１本の白く太い上向きの矢印を生成し、描画する。上下の並び順は、時系列的に表すことができる。さらに、図１７（ｃ）のデータを参照し、応答件数に応じて、楕円の大きさを決め、かつ、ユーザを表す楕円を生成する。この例では、YamadaとIshidaの楕円を作成する。楕円の面積は、応答件数に応じて、６対１の比率にする。
【００８６】
そして、図１７（ｂ）のデータを参照し、先に作成したトリガー質問の上向きの白く太い矢印と、楕円を矢印で結ぶ。矢印の向きは、楕円から、トリガー質問の太い矢印へ向かうものとする。この例では、Yamadaの楕円から６本、Ishidaの楕円から、１本の矢印が、トリガー質問の白く太い矢印に向かうようにする。
【００８７】
次に、応答のみを表示する場合には、図１０のデータを対象にし、図１５で指定された、プロジェクト、期間、状況を把握するユーザ名の条件に従い、図１８（ａ）のようなデータ結果を算出する（ステップＳ６２１）。この場合、Taguchiの実施した応答を、問題解決ステップと、応答したトリガー質問ＩＤの情報をともなって集める。
【００８８】
次に、図１８（ａ）の３列目に出てくるトリガー質問ＩＤ毎に、図８のデータを用いて、トリガー質問を出したユーザＩＤを調べる(ステップＳ６２２)。すなわち、Ｑ０００６のトリガー質問に対して、Yamadaという対を作る。これによって、図１８（ａ）および（ｂ）のデータにより、問題解決ステップのＲ０００８というTaguchiの応答は、トリガー質問ＩＤＱ０００６を発したYamadaの楕円に矢印を引くことができる。
【００８９】
Taguchiが応答した先のユーザの楕円の大きさを決める（ステップＳ６２３）。このため、図１８（ａ）の３列目のトリガー質問ＩＤについて、それを発したユーザ名に、図１８（ｂ）を用いて置き換える。すなわち、Ｑ０００６とＱ０００９はYamadaに、Ｑ０００７はKimに、Ｑ０００８はIshidaに置き換える。そして、それらのユーザ名の重複を数える。これにより、各ユーザの楕円に、行き着く応答を表す矢印の数を表すことができる。この数を、楕円の大きさの決定に用いる。
【００９０】
上記のステップで生成され、かつ保持されたデータに基づき、状況を可視化できる図形を生成する（ステップＳ６２４）。この場合、図１８（ａ）ないし図１８（ｃ）のデータを用いる。
【００９１】
最初に、ユーザTaguchiを表わす楕円と、問題解決ステップを区別する矩形と、それらを結ぶ線を描く。図１８（ａ）のデータを参照し、問題解決ステップ毎に、黒い上向き矢印を、応答の件数だけ生成する。図１６の表示で言えば、対策の四角い図形の上の７本の黒く太い上向き矢印を生成する。さらに、図１８（ｃ）のデータを参照し、応答件数に応じて、楕円の大きさを決め、ユーザを表す楕円を作る。ここでは、Yamada、KimとIshidaの楕円を作成する。楕円の面積は、３対３対１の比率にすることができる。そして、図１８（ａ）と図１８（ｂ）のデータを参照し、先に作成した応答を表すの上向きの黒く太い矢印と、ユーザを表す楕円を矢印で結ぶ。矢印の向きは、楕円へ向かうものとする。この例では、Yamadaの楕円へ３本、Ishidaの楕円へ３本ら、Kimの楕円へ１本の矢印が向かうようにする。
【００９２】
トリガー質問と応答の双方を表示する場合には、上記したステップＳ６１１〜Ｓ６１４と、ステップＳ６２１〜Ｓ６２４までの処理を行うことになる。つまり、トリガー質問を検索し（ステップＳ６３１）、対応する応答と応答したユーザを検索し（ステップＳ６３２）、応答と対応するトリガー質問を検索し（ステップＳ６３３）、トリガー質問したユーザを検索する（ステップＳ６３４）。さらに、応答とトリガー質問をしたユーザのノードの大きさを計算する（ステップＳ６３５）。この処理は、ユーザ名毎に、その件数を足し合わせた合計となる。ここでは、図１７（ｃ）の応答件数と、図１８（ｃ）の応答件数の合計である。各行は、（Yamada、９）、（Ishida、４）、（Kim、１）となる。これは、Taguchiに対して、３人の各々のユーザの間の矢印の線の数を表している。
【００９３】
最後に、こうして得られたデータに基づきグラフィックを作成する（ステップＳ６３６）。つまり、ステップＳ６１４とステップＳ６２４の処理の合成に等しい。最初に、ユーザTaguchiを表わす楕円と、問題解決ステップを区別する矩形と、それらを、結ぶ線を描く。次に、ステップＳ６３５の結果を用いて、Taguchiと関係のあるユーザの楕円の大きさを決めて、楕円を描く。次に、ステップＳ６３１の結果（図１８（ａ）と同じ）を用いて、Taguchiのトリガー質問の図形を、問題解決ステップ別の矩形の上に作画する。ステップＳ６３２の結果を用いて、Taguchiのトリガー質問に対して応答したユーザとの間の応答を表わす実践の矢印を描く。さらに、ステップＳ６３３とＳ６３４の結果（図１８（ａ）、図１８（ｂ）と同じ）を用いて、Taguchiの応答した応答を、問題解決ステップ別に、黒い太い矢印で表わし、応答先のユーザとの間を矢印で結ぶ。
【００９４】
このように本実施例によれば、インターネットなどのコンピュータネットワーク上で、テキストデータを用いて、ユーザが質問やその応答などの情報を入力でき、それらがコンピュータネットワーク上の記憶装置に蓄積され、公開される時に、ユーザからの入力の際に、質疑応答の情報を、業務プロセスと問題解決のステップの視点で区別して指定するようにしたので、ある特定のユーザの質問や応答などの情報について、（１）業務プロセスのどの段階で、（２）問題解決ステップのどの段階で、（３）どのような量と質で、（４）他の誰となされたか、可視化し、容易に認識することができるという優れた効果を有する。
【００９５】
特に、仕事をしているメンバが、互いに席や職場を離れている場合、監督者や管理者が、メンバ間の問題解決に関するコミュニケーションの状況を把握することが難しいような状況において、本実施例のような情報処理システムを用いることで、問題解決のステップ毎に、質疑応答の状況を可視化させ、メンバ間のコミュニケーションの問題を把握したり、長所を把握したりすることができる。
【００９６】
次に、本発明の第２の実施例について説明する。第２の実施例では、グループのメンバであるユーザの質疑応答が、どのような質と量で成されたのかを、より分かり易く、グループの複数のユーザ間で可視化するものである。
【００９７】
ハードウエア構成は、第１の実施例のときと同様に、サーバ１００、クライアント２００、コンピュータネットワーク３００によって構成される。図２１は、第２の実施例に係る情報処理機の基本的機能を示すブロック図である。第１の実施例と同様のものは、説明を省略する。図２１に示すように、質疑応答属性定義手段４０２は、第１の実施例に加えて、グループメンバ定義入力手段４６０およびグループメンバ定義保持手段４８０を備えている。また、質疑応答状況表示手段６０２は、グループ内の状況条件入力手段６２２、グループ内の状況表示手段６４２およびグループ内の状況保持手段６６２を備えている。
【００９８】
質疑応答属性定義手段４０２における属性定義入力手段４２０および属性定義保持手段４４０は第１の実施例と同様である。グループメンバ定義入力手段４６０を図２２に示す。これは、特定のプロジェクト内のグループとそのメンバであるユーザを定義するのものである。このグループの中のメンバ間の質疑応答の状況を比較する。
【００９９】
属性定義入力手段により入力された情報は、上述した図５（ａ）〜（ｃ）のようなデータ構造の中に格納される。グループメンバ定義入力手段４６０によって、入力されたグループメンバの定義のデータは、図２３のようなデータ構造に格納される。グループＩＤは、システムによってプロジェクト内で重複のないように設定される。図２３のグループ名とメンバは、図２２の画面で入力されるものに対応する。
【０１００】
質疑応答属性定義は、第１の実施例のときと同様に図３の手順に従って行われる。図２４は、グループメンバ定義入力手段のフローチャートである。この処理は、第１の実施例の図３の処理と類似している。主要な違いは、格納するデータ構造であり、第１の実施例のときの質疑応答属性の代わりに、グループメンバの定義属性が対象となる。
【０１０１】
質疑応答属性定義手段４０２により、各種の属性が登録された後に、質疑応答手段５００を利用することができる。質疑応答手段５００における、トリガー質問入力手段を図２５に示す。プロジェクト名「社内プロジェクトの実態調査」において、ユーザがトリガー質問入力画面を呼び出すユーザ・インターフェースがあってもよく、そこから、図２５の画面を呼び出す。これは、ユーザがコンピュータネットワーク上で、あるテーマについて最初に開始する質問で、これに応じて他のユーザが応答を入力していく。
【０１０２】
図２５では、ユーザ名：Taguchiのユーザが、プロジェクトの内のグループ「プロジェクト調査グループ」における、トリガー質問のテーマを表す、タイトル「調査対象にするプロジェクトについて」をテキスト入力枠に入力し、業務プロセスの種別、問題解決プロセスの種別をチェックボックスで指定し、質問文を入力する。そして、登録ボタンを押すことにより、質疑応答保持手段５８０に記録させる。
【０１０３】
質疑応答手段５００における、質疑応答履歴表示手段５４０を図２６に示す。これは、トリガー質問とそれに対応した応答を同時に示すものである。図２６は、トリガー質問を登録した直後に、質疑応答を表示するものである。登録されたときに、自動的に付けられたトリガー質問ID：Q0001、登録日、登録された業務プロセスの属性名、問題ステップ、トリガー質問のユーザ名、質問の内容が、表示されている。一番下には、このトリガー質問に対する応答を入力するために、応答入力画面を呼び出すためのボタンが表示されている。
【０１０４】
図２７は、図２８による応答が入力されたあとの画面の例である。トリガー質問の下に応答が表示されている。応答ID、応答したユーザ名、登録日、応答の内容が表示されている。同じく、一番したに応答の入力画面を呼び出すボタン「応答入力」が表示されている。
【０１０５】
質疑応答手段５００における応答入力手段５６０を図２８に示す。これは、ユーザ名：Ishidaのユーザが、図２５のトリガー質問に対する応答を入力するためのユーザ・インターフェースである。このユーザ・インターフェースは、図２６、図２７の応答入力ボタンを押すことによって表示される。
【０１０６】
図２９、３０は、トリガー質問と応答を保持するためのデータ構造を示している。同図のデータは、トリガー質問が登録されたときに、データが保持されるものである。図２５のトリガー質問入力画面での入力が登録される処理の時に、トリガー質問ＩＤと、登録日は、自動的に設定され保持される。トリガー質問ＩＤは、このシステムにおいて重複の無い番号である。この番号によって、図２９の表の行を特定することもできるし、トリガー質問を特定することができる。また、プロジェクトＩＤ、業務プロセスＩＤと問題解決ステップＩＤは、属性定義手段４０２に対応するものが保持される。トリガー質問者名（ユーザＩＤ）、タイトル、質問文は、図２５の入力画面の中に対応するものが保持される。図２９では、図２５により入力されたデータは、見やすいように、一行目に記載してある。そのほかの行は、同様の手段によって、プロジェクト名「社内プロジェクトの実態調査」（プロジェクトID：P0001）におけるトリガー質問がＱ０００１からＱ０００９まで保持されている。
【０１０７】
図２９、図３０における、質問文、応答文や、その他の行は、記載の省略のために、「…・」と書いてある。図３０は、応答が入力されたときに、データが保持されるデータ構造である。図２８の応答入力画面での入力が登録される処理のときに、応答ＩＤ、と登録日は、自動的に設定され保持される。応答ＩＤは、このシステムにおいて重複の無い番号である。この番号によって、図３０の表の行を特定することもできるし、応答を特定することができる。また、プロジェクトＩＤ、トリガー質問ＩＤも属性定義手段に対応するものが保持される。また、応答ユーザ名（ユーザＩＤ）、業務プロセスＩＤ、問題解決ステップＩＤ、応答文は、図２８の画面に対応するものが保持される。この図３０では、そのほかの行は、同様の手段によって、プロジェクト名「社内プロジェクトの実態調査」（プロジェクトＩＤ：P0001）における、トリガー質問毎に応答の内容が登録されている。図３０の応答は、見やすいように一行目に登録されている。応答ＩＤは、Ｒ０００７である。
【０１０８】
トリガー質問の入力と登録は、第１の実施例の図６と同様の手順で行われ、質疑応答履歴の表示は、第１の実施例の図９と同様の手順で行われ、応答の入力と登録は第１の実施例の図１３と同様の手順で行われる。
【０１０９】
質疑応答履歴表示のフローにおいて（図９を参照）、ユーザは、クライアント側でプロジェクト名「社内プロジェクトの実態調査」（プロジェクトＩＤ：P0001）において既に登録された、トリガー質問のタイトルの一覧が表示された画面などから、閲覧したいトリガー質問を選択する。この実施例では、タイトル「調査対象にするプロジェクトについて」のトリガー質問が選択される。この場合、図２９の中から、タイトル「調査対象にするプロジェクトについて」がある行が選ばれ、トリガー質問ＩＤ（Ｑ０００５）を確認する。このトリガー質問に対応する応答があるのかどうかを、図３０の形式の表で調べる。仮に、探してない場合には、図２６のような閲覧画面を生成してクライアントに送付する。この場合、トリガー質問（Ｑ０００５）に関する応答は、誰も登録していないことを意味している。図３０のように、すでに応答がある場合には、Ｑ０００５に対応する応答ＩＤ：Ｒ０００７があることがわかる。この場合には、図２９のＱ０００５の行と、図３０のＲ０００７の行をに基づいて、図２７のような閲覧画面を生成して閲覧画面に送付する。
【０１１０】
次に、ユーザ・インターフェースのボタンなどで、質疑応答の履歴の表示を要求する。サーバは、そのトリガー質問に対応するトリガー質問の内容、応答の内容を、図２９と図３０の質疑応答保持手段から取り出して、その表示用の画面を作成して、クライアント側に送付する。クライアント側で、図２７のような質疑応答履歴を閲覧する。
【０１１１】
応答入力手段のフローにおいて（図１３を参照）、図２７のような質疑応答履歴の表示画面の応答入力ボタンを押すことによって、サーバ側で、図２９のデータを参考にして、図２８の画面を生成してクライアント側に送付する。ユーザが入力して登録し、質疑応答保持手段に登録する。
【０１１２】
図３１は、特定のプロジェクトにおける、グループ内の質疑の状況を把握するために、状況の表示の条件を入力するインターフェースである（図２１のグループ内の状況条件入力手段６０２に対応）。図３１では、プロジェクト名が、「社内プロジェクトの実態把握」（プロジェクトＩＤ：Ｐ０００１）、について、期間が、2004年3月1日から3月31の間に、グループ名が「プロジェクト調査グループ」（グループＩＤ：Ｇ０００１）のグループについて、その業務プロセスが「計画」（業務プロセスＩＤ：０００２）の段階において、問題解決の「全ステップ」（問題解決ステップＩＤ：０００１、０００２、０００３、０００４、０００５）で、トリガー質問とそれに応じて受けとった応答と、発信した応答について、それらの両方を表示するための条件を、メニュー形式のユーザ・インターフェースで選択して設定したところを、表わしている。最下部には、表示の指示をサーバへ送る表示ボタンがある。メニュー形式のユーザ・インターフェースで指定できるようになっているが、この方法に限定する必要はない。
【０１１３】
図３１で指定した状況の表示条件をユーザが入力してから、表示ボタンを押して、表示の要求をサーバにしたあと、計算され表示された質疑応答の状況を図３２に示す（図２１のグループ内の状況表示手段６４２に対応）。図３２では、プロジェクト名：社内プロジェクトの実態把握（プロジェクトＩＤ：Ｐ０００１）、期間が、２００４年3月１日から3月31日までの、グループ名：プロジェクト調査グループ（グループＩＤ：Ｇ０００１）における、業務プロセスが計画（業務プロセスＩＤ：０００２）の段階における、トリガー質問と、応答の状況を、グループのメンバであるTaguchi, Yamada、Kim、Ishidaについて示している。
【０１１４】
トリガー質問とそれに対して受信した応答と、発信した応答は、問題解決の各ステップ別に分類してある。そのステップは、図の中央に柱状に重ねて示してある。各ステップの柱の高さは、そこでのトリガー質問と応答の量に応じて、変化させている。つまり、対策のステップの柱の高さは、トリガー質問とそれに対して受信した応答高さが、他のステップより多いので、高さも他よりも高くなっている。
【０１１５】
その柱の右側には、トリガー質問とそれに対して受信した応答の件数を、左側には、発信した応答の件数を、メンバ別に示している。柱の右側は、あるメンバが質疑応答で、質問を発し、それに対して他のメンバから応答を貰っている状況を示しているので、そのメンバが助けられた状況を示している。また、左側は、あるメンバが、応答によって、他のメンバを助けた状況を示している。
【０１１６】
これより、図の解釈について説明する。柱の右側について説明する。問題解決ステップの問題設定の右側に着目する。Taguchiは、トリガー質問を４件ほど行い、それに対して、６件ほどの応答も受けている。トリガー質問は、右向きの一つの矢印が１件である。それに対する応答は、左向きの一つの矢印で1件を表わしている。トリガー質問の矢印の水平方向の並びの下に、応答の矢印をならべている。同じように、対策のステップでは、TaguchiとKimは、それぞれ、1件のトリガー質問を出して、1件の応答を貰っている。また、Yamadaは、トリガー質問を２件、応答を３件、Ishidaは、トリガー質問を１件、応答を３件ほど受けている。
【０１１７】
柱の左側について説明する。問題設定のステップでは、Yamadaが、６件の応答を行い、他のメンバを助けていることがわかる。同じように、対策のステップで、Taguchiが７件の応答を行い、Ishidaが１件の応答を行っている。原因、評価、その他のステップでは、柱の左右の両方で、トリガー質問と応答は、全く行われていないことがわかる。
【０１１８】
以上のことから、このグループの中では、問題設定のステップでは、Taguchiは、トリガー質問を他のメンバより多く出し、助けらていることがわかる。また、Yamadaは、７件も応答して、Taguchi、Ishida、Kimよりも、他のメンバを助けていることがわかる。対策のステップでは、グループのメンバであるユーザは、万弁なく質疑応答をしているが、Taguchiは、突出して、応答に応じているので助け役になっていることがわかる。
【０１１９】
また、グループ全体としては、対策のステップでは、コミュニケーションが活発で、次に、問題設定であるが、そこには、特定のメンバ（TaguchiとYamada）に偏りがあることがわかる。また、もし、柱の右側で、トリガー質問を沢山しているが、貰う応答が極端に少ないメンバがいれば、そのユーザは、周囲のユーザからあまり助けられてい可能性があることこともわかる。
【０１２０】
図３２のような表示を用いれば、たとえば、以下のようなことが、可能になる。業務プロセスのそれぞれの段階における、特定のグループについて、問題解決のステップ別に、
（１）トリガー質問の発している件数を、メンバ間で比較できる。（問題解決ステップの柱の右側）。
（２）他人のトリガー質問に対応して応答している件数を、メンバ間で比較できる。（問題解決ステップの柱の左側）。
（３）自分のトリガー質問に対応してもらい、受け取った応答の件数を、メンバ間で比較できる（問題解決ステップの柱の左側）。
（４）自分のトリガー質問の件数に対して、どの程度の割合で応答を受け取っているかを、メンバ間で、比較できる（問題解決ステップの柱の右側）。
（５）問題解決ステップ別に、トリガー質問と応答の件数を表示しているので、このグループの質疑応答の頻度が、どのステップで多く、または、少ないのか、がわかる。つまり、ステップ別の柱の高さを比較すれば良い。
【０１２１】
グループ内の状況保持手段６６２（図２１参照）は、図３２の状況を表示する処理において必要なデータの保持手段である。これらは、図３１の状況表示の条件に基づいて、処理が始まり、図２９と図３０に基づいて表示の処理をするときに保持されるデータである。
【０１２２】
図３３（a）は、図１２の柱の右側の部分を作成するために必要なデータを保持した状態である。図２９と図３０を使って検索などの計算処理をして作成する。４列目のトリガー質問ＩＤリストと、６列目の応答ＩＤリストは、それぞれリスト構造をもったデータ型である。その他の列は、文字列型、または、整数型である。また、図３３（ｂ）は、図３０を使って検索などの計算処理をして作成する。４列目の応答ＩＤリストは、リスト構造をもったデータ型である。その他の列は、文字列型か整数型である。
【０１２３】
図３４は、グループ内の質疑応答状況閲覧手段のフローチャートである。この図は、質疑応答状況表示手段６０２の全体のフローを表す。クライント側で、ユーザが指定したプロジェクト「社内プロジェクトの実態把握」（プロジェクトＩＤ：Ｐ０００１）について、その質疑応答状況の表示のための条件を入力する画面を呼び出す（ステップＳ８０１）。こでは、ユーザが図３１の画面を呼び出す指示である。
【０１２４】
サーバはその呼び出しにより、図２３の属性定義保持手段４０２に保持されたプロジェクトＩＤ（Ｐ０００１）に関する属性を参考にして、メニューを含めたユーザ・インターフェースを生成して、クライアント側に送る（ステップＳ８０２）。すなわち、サーバは、図３１の画面を作成して、クライアント側に送る。ここでは、サーバ側で画面を作るとしたが、画面を作るプログラムをクライアントに送って、クライアント側で作成してもいい。その場合は、図２３のデータを、クライアント側から呼び込む場合がある。
【０１２５】
ユーザは、図３１の画面のメニューで、状況把握の条件、即ち、各種ＩＤと、期間、表示の条件、を設定して、表示ボタンを押して、表示の処理の開始をサーバ側に伝える（ステップＳ８０３）。
【０１２６】
グループ内の状況画面の表示処理をする（ステップＳ８０４）。状況表示の処理は、図３５のフローによってなされる。処理の結果はクライント側で図３２として表示される。ユーザが、図３２に示したように、グループ内の質疑応答状況を閲覧する（ステップＳ８０５）。
【０１２７】
次に、図３５にグループ内の状況表示手段のフローチャートを示す。グループ内の状況条件入力手段６２２（図３１を参照）において、状況把握の条件が設定される（ステップＳ９０１）。その条件を使って処理する。条件のうち、トリガー質問に対応して受けた応答、即ち、図３２の柱の右側を、表示し、または、非表示とすし、発信した応答、即ち、図３２の柱の左側を、表示し、または、非表示とする、組み合わせがある。その組み合わせにより、フローが３つに分かれる。ステップＳ９０１では、それを判断する。
【０１２８】
ステップＳ９１１からＳ９１４は、トリガー質問とそれに対応する応答のみを表示する場合である。そのうちＳ９１１からＳ９１３の処理によって、図３３（ａ）を作成する。また、Ｓ９２１からＳ９２３は、発信した応答のみを表示する場合である。そのうち、Ｓ９２１とＳ９３２の処理によって、図３３（ｂ）を作成する。ステップＳ９３１からＳ９３３は、それらの両方を表示する場合である。
【０１２９】
ステップＳ９１１では、図２９のデータと、図３１で指定された条件を使う。図３１で指定された条件が、プロジェクトＩＤ：Ｐ０００１、かつ、グループＩＤ：Ｇ０００１、かつ、登録日が２００４年３月１日から３１日、かつ、業務プロセスＩＤ：０００２、かつ、問題解決ステップＩＤがすべての場合、図２９のデータの行について、問題解決ステップのＩＤの順番で行をならべ、さらにその順番の中で、トリガー質問者名（ユーザＩＤ）が同じものを、となりあわせて並べる。そうすると、問題解決ステップＩＤが０００１で、トリガー質問者名がTaguchiのものは４行できる。また、問題解決ステップが０００３のもので、Taguchiの行は１行、Yamadaの行は２行、Kimの行は１行、Ishidaの行は、１行できる。
【０１３０】
ステップＳ９１２では、Ｓ９１１の結果について、さらに、同一のトリガー質問者が複数行ある場合は、それららの行の行数を集計して、トリガー質問件数とする。そして、トリガー質問ＩＤは、まとめて、リスト構造にする。例えば、Taguchiの４行は、トリガー質問件数は４件となり、トリガー質問ＩＤリストは、Ｑ０００１、Ｑ０００２、Ｑ０００３、Ｑ０００４となる。同様にして、他のトリガー質問者についても行う。その結果、図３３（ａ）の左から１列目から４列目までのデータができる。
【０１３１】
ステップＳ９１３では、Ｓ９１２の結果について、行毎に、トリガー質問ＩＤリストの個々のトリガー質問ＩＤに対応した応答の応答ＩＤを探して、図３３（ａ）の６列目の応答ＩＤリストを作成し、その応答の件数を集計して、５列目を作成する。それには、図３３（ａ）の４列目の個々のトリガー質問ＩＤについて、図２９の９列目のトリガー質問ＩＤの列のデータを手掛かりに、図３０の１列名の応答ＩＤを探し出す。そして、見付けたものを、図３３（ａ）の６列目の応答ＩＤリストとして集めていく。図３０のデータをすべて調べて、リストが完成すると、リストの中の応答ＩＤの個数を調べて、図３３（ａ）の５列目の応答件数とする。このようにして、図３３（ａ）の５列目と６列目ができ、図３３（ａ）が完成する。
【０１３２】
ステップＳ９１４では、図３３（ａ）のデータに基づいて、図３２の中央の柱の右側の部分に相当する、グラフィックスを作成して、クライアントで表示する。
【０１３３】
ステップＳ９２１では、図３０のデータと、図３１で指定された条件を使う。図３１で指定された条件が、プロジェクトＩＤ：Ｐ０００１、かつ、グループＩＤ：Ｇ０００１、かつ、登録日が２００４年３月１日から３１日、かつ、業務プロセスＩＤ：０００２、かつ、問題解決ステップＩＤがすべての場合、図３０のデータの行について図３１で指定された業務プロセスＩＤが０００２の行について、問題解決ステップのＩＤの順番でならべ、さらにその順番の中で、応答ユーザ名（ユーザＩＤ）が同じものを、となりあわせてならべる。そうすると、問題解決ステップが０００１の行で、応答ユーザ名がYamadaの行は、６行できる。また、問題解決ステップが０００３のもので、Taguchiの行は７行、Ishidaの行は、１行できる。
【０１３４】
ステップＳ９２２では、Ｓ９２１の結果について、さらに、同一の応答ユーザ名が複数行ある場合は、それららの行の行数を集計して、応答件数とする。そして、応答ＩＤは、まとめて、リスト構造にする。例えば、Yamadaの６行は、応答件数は６件となり、応答ＩＤリストは、Ｒ０００１、Ｒ０００２、Ｒ０００３、Ｒ０００４、Ｒ０００５、Ｒ０００６となる。同様にして、他の応答ユーザ名についても行う。その結果、図３３（ｂ）の左から１列目から４列目までのデータが完成する。
【０１３５】
ステップＳ９２３では、図３３（ｂ）のデータに基づいて、図３２の中央の柱の左側の部分に相当する、グラフィックスを作成して、クライアントで表示する。
【０１３６】
ステップＳ９３１からからＳ９３３は、トリガー質問と対応する応答と、発信した応答との両方を表示する処理である。図３２の柱の両側を計算して表示する。この処理は、ステップＳ９１１からＳ９１３の処理と、Ｓ９２１とＳ９２２の処理に、表示用のグラフィックスを作成する処理Ｓ９３３を加えたものである。
【０１３７】
以上説明したように、本実施例によれば、インターネットなどのコンピュータ・ネットワーク上で、テキストデータを用いてユーザが質問やその応答などの情報を入力でき、それらがコンピュータネットワーク上の記憶装置に蓄積され、公開される時に、入力の際に質疑応答の情報を業務プロセスと問題解決のステップの視点で区別して指定して入力でき、それらの情報に基づいて計算を行い、表示条件にしたがって表示するようにしたので、ある特定のユーザの質問や応答などの情報について、１）業務プロセスのどの段階で、２）問題解決ステップのどの段階で、３）どのような量と質で、なされたかを、４）グループ内の複数ユーザ間で比較できることが可能な情報処理装置を提供することができる。
【０１３８】
特に、仕事をしているメンバが互いに席や職場を離れている場合、監督者や管理者がメンバ間の問題解決に関するコミュニケーションの状況を把握することが難しい。このような状況で、問題解決のステップ別に、質疑応答の状況を把握して、メンバ間のコミュニケーションの問題を把握したり、長所を把握することに、効果を発揮する。
【０１３９】
以上、本発明の好ましい実施の形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【０１４０】
上記実施例において用いた、質問と質疑は同義である。さらに、質問、質疑、応答は、特に限定的に解釈されるべきものではなく、広義のものとして解釈されるものである。
【産業上の利用可能性】
【０１４１】
本発明に係る情報処理システム、方法およびプログラムは、ネットワーク接続されたコンピュータ等の電子装置間において利用することができる。また、それらの利用は、ユーザ間のコミュニケーションの可視化、ユーザ評価等において広く利用することが期待できる。
【図面の簡単な説明】
【０１４２】
【図１】本発明の実施例に係る情報処理システムの構成を示すブロック図である。
【図２】本発明の第１の実施例に係る情報処理システムの基本的機能を示す部ブロック図である。
【図３】図２の質疑応答属性定義手段の動作を説明するフローチャートである。
【図４】属性定義入力手段における属性定義入力画面を示す図である。
【図５】入力された属性定義を保存するときのデータ構造を示す図である。
【図６】質疑応答手段の動作を説明するフローチャートである。
【図７】トリガー質問入力手段によるユーザインターフェースの一例を示し、トリガー質問入力画面を示す図である。
【図８】質疑応答保持手段におけるトリガー質問処理時のデータ構造を示す図である。
【図９】質疑応答履歴の動作フローチャートである。
【図１０】質疑応答保持手段における応答処理時のデータ構造を示す図である。
【図１１】質疑応答の表示画面例である。
【図１２】質疑応答の表示画面例である。
【図１３】応答入力と登録の動作フローチャートである。
【図１４】応答の入力画面例である。
【図１５】質疑応答の状況表示条件入力の表示画面例である。
【図１６】質疑応答の状況の表示例である。
【図１７】質疑応答の状況を表示するためのデータ構造を示す図である。
【図１８】質疑応答の状況を表示するためのデータ構造を示す図である。
【図１９】質疑応答の状況把握の全体の動作を示すフローチャートである。
【図２０】質疑応答の状況を表示するための動作を示すフローチャートである。
【図２１】本発明の第２の実施例に係る情報処理システムの基本的機能を示す部ブロック図である。
【図２２】グループメンバ定義入力手段におけるグループメンバ定義入力画面を示す図である。
【図２３】グループメンバ定義手段が保持するデータを説明する図である。
【図２４】第２の実施例による質疑応答属性定義手段の動作を説明するフローチャートである。
【図２５】第２の実施例によるトリガー質問入力画面を示す図である。」
【図２６】第２の実施例による質疑応答の表示画面例である。
【図２７】第２の実施例によるトリガー質問に対する応答を入力した後に表示される画面例である。
【図２８】第２の実施例による応答の入力画面例である
【図２９】第２の実施例による地次応答保持手段が保持するデータを説明する図である。
【図３０】第２の実施例による地次応答保持手段が保持するデータを説明する図である。
【図３１】グループ内の質疑応答の状況表示条件入力の表示画面例である。
【図３２】第２の実施例によるグループ内の質疑応答状況の表示画面例である。
【図３３】グループ内の状況表示のために設定するデータを説明する図である。
【図３４】グループ内の質疑応答状況表示手段の処理を示すフローチャートである。
【図３５】第２の実施例によるグループ内の質疑応答状況表示手段における動作フローチャートである。
【符号の説明】
【０１４３】
１：情報処理システム                  １００：サーバ
２００：クライアント                  ３００：コンピュータネットワーク
４００、４０２：質疑応答属性定義手段  ４２０：属性定義入力手段
４４０：属性定義保持手段              ４６０：グループメンバ定義入力手段
４８０：グループメンバ定義保持手段    ５００：質疑応答手段
５２０：トリガー質問入力手段          ５４０：質疑応答履歴表示手段
５６０：応答入力手段                  ５８０：質疑応答保持手段
６００、６０２：質疑応答状況閲覧手段  ６２０：状況把握条件入力手段
６２２：グループ内状況把握条件入力手段
６４０：状況表示手段                ６４２：グループ内状況表示手段
６６０：状況保持手段                ６６２：グループ内状況保持手段
【図１】
2005301972.tif 000003
【図２】
2005301972.tif 000004
【図３】
2005301972.tif 000005
【図４】
2005301972.tif 000006
【図５】
2005301972.tif 000007
【図６】
2005301972.tif 000008
【図７】
2005301972.tif 000009
【図８】
2005301972.tif 000010
【図９】
2005301972.tif 000011
【図１０】
2005301972.tif 000012
【図１１】
2005301972.tif 000013
【図１２】
2005301972.tif 000014
【図１３】
2005301972.tif 000015
【図１４】
2005301972.tif 000016
【図１５】
2005301972.tif 000017
【図１６】
2005301972.tif 000018
【図１７】
2005301972.tif 000019
【図１８】
2005301972.tif 000020
【図１９】
2005301972.tif 000021
【図２０】
2005301972.tif 000022
【図２１】
2005301972.tif 000023
【図２２】
2005301972.tif 000024
【図２３】
2005301972.tif 000025
【図２４】
2005301972.tif 000026
【図２５】
2005301972.tif 000027
【図２６】
2005301972.tif 000028
【図２７】
2005301972.tif 000029
【図２８】
2005301972.tif 000030
【図２９】
2005301972.tif 000031
【図３０】
2005301972.tif 000032
【図３１】
2005301972.tif 000033
【図３２】
2005301972.tif 000034
【図３３】
2005301972.tif 000035
【図３４】
2005301972.tif 000036
【図３５】
2005301972.tif 000037