ナレッジマネジメントシステムであって、プロジェクトの技術分野に係る属性とプロジェクトの顧客の業界に係る属性とを含むプロジェクト属性、及びプロジェクトに参加した社員の識別情報を含むプロジェクトデータを記憶する第1の記憶手段と、社員の識別情報を含む社員データを記憶する第2の記憶手段と、プロジェクトデータの検索条件の入力を受け付ける第1の受付手段と、前記第1の受付手段が受け付けた検索条件に基づいて、前記第1の記憶手段を検索するプロジェクト検索手段と、前記プロジェクト検索手段で検索されたプロジェクトデータを出力する第1の出力手段と、前記プロジェクト検索手段で検索されたプロジェクトデータに含まれている社員の識別情報に基づいて、前記第2の記憶手段を検索する社員検索手段と、前記社員検索手段で検索された社員データを出力する第2の出力手段と、を備えるナレッジマネジメントシステム。担当社員に識別情報を含む、見込み客に対する営業活動におけるコンタクトに係るコンタクトデータを記憶する第3の記憶手段と、コンタクトデータの検索条件の入力を受け付ける第2の受付手段と、前記第2の受付手段が受け付けた検索条件に基づいて、前記第3の記憶手段を検索するコンタクト検索手段と、前記コンタクト検索手段で検索されたコンタクトデータを出力する第3の出力手段と、をさらに備え、前記社員検索手段は、さらに、前記コンタクト検索手段で検索されたコンタクトデータに含まれている社員の識別情報に基づいて、前記第2の記憶手段を検索する、請求項1記載のナレッジマネジメントシステム。前記プロジェクト検索手段は、前記第1の受付手段が受け付けた検索条件に基づく検索結果に含まれている社員の識別情報を含む他のプロジェクトデータを前記第1の記憶手段から再度検索する、請求項1記載のナレッジマネジメントシステム。上述の通り、ナレッジマネジメントシステムを活用すれば、社員個人の知識やノウハウなどがシステムに蓄積され、それを他の社員が自由に参照できるので、理論的には社内での知識共有などがスムーズに進むはずである。現に、それを期待して多くの企業がナレッジマネジメントシステムを導入しているが、現実には必ずしも所期の目的を達成しているとは限らない。その原因の一つは、ナレッジマネジメントシステム内に社員に関する情報が十分に整備されていないことである。すなわち、ナレッジマネジメントシステムを利用する多くの企業は、各社員に対して、自分が有する知識やノウハウに関する情報を登録するよう義務づけているものの、全社員にそれを徹底させることは難しい。ナレッジマネジメントシステムの場合、その内部に登録されている社員個人のデータが整って初めて社員間での情報共有が可能となるので、それが担保されない限り所期の目的を達成し得ない。従って、ナレッジマネジメントシステムが有効に活用されるためには、社員の知識やノウハウなどの情報を整備しやすい構成が不可欠である。そこで、本発明の目的は、知識やノウハウに関する情報を整備しやすいナレッジマネジメントシステムを提供することである。本発明の一つの実施態様に従うナレッジマネジメントシステムは、プロジェクトの技術分野に係る属性とプロジェクトの顧客の業界に係る属性とを含むプロジェクト属性、及びプロジェクトに参加した社員の識別情報を含むプロジェクトデータを記憶する第1の記憶手段と、社員の識別情報を含む社員データを記憶する第2の記憶手段と、プロジェクトデータの検索条件の入力を受け付ける第1の受付手段と、前記第1の受付手段が受け付けた検索条件に基づいて、前記第1の記憶手段を検索するプロジェクト検索手段と、前記プロジェクト検索手段で検索されたプロジェクトデータを出力する第1の出力手段と、前記プロジェクト検索手段で検索されたプロジェクトデータに含まれている社員の識別情報に基づいて、前記第2の記憶手段を検索する社員検索手段と、前記社員検索手段で検索された社員データを出力する第2の出力手段と、を備える。好適な実施態様では、担当社員に識別情報を含む、見込み客に対する営業活動におけるコンタクトに係るコンタクトデータを記憶する第3の記憶手段と、コンタクトデータの検索条件の入力を受け付ける第2の受付手段と、前記第2の受付手段が受け付けた検索条件に基づいて、前記第3の記憶手段を検索するコンタクト検索手段と、前記コンタクト検索手段で検索されたコンタクトデータを出力する第3の出力手段と、をさらに備えてもよい。そして、前記社員検索手段は、さらに、前記コンタクト検索手段で検索されたコンタクトデータに含まれている社員の識別情報に基づいて、前記第2の記憶手段を検索するようにしてもよい。好適な実施態様では、前記プロジェクト検索手段は、前記第1の受付手段が受け付けた検索条件に基づく検索結果に含まれている社員の識別情報を含む他のプロジェクトデータを前記第1の記憶手段から再度検索してもよい。以下、本発明の一実施形態に係るナレッジマネジメントシステムについて、図面を参照して説明する。図1は、本実施形態に係るナレッジマネジメントシステムの全体構成を示す図である。本システムは、データベースサーバ1と、認証サーバ3と、一台以上のユーザ端末装置5と、管理者端末装置7とが、互いにネットワーク9を介して接続されている。データベースサーバ1、認証サーバ3、一台以上のユーザ端末装置5、及び管理者端末装置7は、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明する各サーバ1、3及び各端末装置5、7内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。ユーザ端末装置5及び管理者端末装置7は、それぞれ異なるコンピュータ上に実現されてもよいし、同一のコンピュータ上に実現されてもよい。認証サーバ3は、本システムにアクセスするユーザ及び管理者の認証を行う。例えば、認証サーバ3は、ユーザ端末装置5からの認証要求を受けて、ユーザ端末装置5を使用するユーザの認証を行う。また、認証サーバ3は、管理者端末装置7からの認証要求を受けて、管理者端末装置7を使用する管理者の認証を行う。認証サーバ3によって認証されたユーザ及び管理者は、それぞれ所与の権限の範囲内でデータベースサーバ1へアクセスすることができる。ユーザ端末装置5は、所定の入力装置及び出力装置を有する。ユーザ端末装置5は、ユーザに対して、データベースサーバ1のデータへアクセスするための各種インタフェースを提供する。例えば、以下に説明する各登録編集画面が各ユーザ端末装置5に表示され、その画面に対してユーザが入力することができる。また、各ユーザ端末装置5には、以下に説明する各検索画面からの検索要求に対する検索結果が表示される。管理者端末装置7は、所定の入力装置及び出力装置を有する。管理者端末装置7は、システム管理者に対して、システム管理のための各種インタフェースを提供する。データベースサーバ1は、各種データを記憶する。本システムは、顧客から受注したプロジェクトに関するデータと、プロジェクト受注へ向けた営業活動における顧客見込み客とのコンタクトに関するデータと、社員に関するデータと、顧客に関するデータと、その他のデータとを主に有している。そして、プロジェクトに関するデータ、コンタクトに関するデータ、社員に関するデータ及び顧客に関するデータが互いに関連づけられている。図2は、データベースサーバ1に記憶されているデータの一例を示す。データベースサーバ1は、プロジェクトに関連するデータとしてプロジェクトテーブル10及びプロジェクト属性テーブル11を有し、コンタクトに関するデータとしてコンタクトテーブル14及びコンタクト属性テーブル15を有し、社員に関するデータとして、社員テーブル18、講座テーブル19及び講座申込テーブル20を有し、顧客に関するデータとして顧客テーブル24及び顧客属性テーブル25を有する。データベースサーバ1は、さらに、その他のデータとして、エージェントに関するエージェントテーブル28と、フォーラムに関するフォーラム管理テーブル30及びフォーラムデータ記憶部31と、コミュニティに関するコミュニティ管理テーブル34及びコミュニティデータ35とを有する。データベースサーバ1は、上記の各データを検索するための検索エンジン40をさらに有する。<プロジェクト関連データ>図3は、プロジェクト登録編集画面1000の一例を示す。図4は、プロジェクトテーブル10及びプロジェクト属性テーブル11のデータ構造の一例を示す。顧客からプロジェクトを受注すると、そのプロジェクトの開始前または開始後にプロジェクト関連データが、プロジェクト登録編集画面1000から登録される。ここで入力されたデータがプロジェクトテーブル10及びプロジェクト属性テーブル11に保存される。プロジェクト関連データには、プロジェクトの技術分野に係る属性とプロジェクトの顧客の業界に係る属性とを含むプロジェクト属性及びプロジェクトに参加した社員の識別情報が含まれる。プロジェクトテーブル10及びプロジェクト属性テーブル11に保存されたデータは、その後、随時プロジェクト登録編集画面1000から更新することができる。なお、ここで示す入力項目及びデータ項目は一例に過ぎないので、これら以外の入力項目及びデータ項目を有していてもよいし、一部の項目は省略可能である。プロジェクト登録編集画面1000は、図3に示すように、プロジェクトID1001、顧客名1002、契約ID1003、開始日1004、終了日1005、先方担当者1006、テーマ候補1007、インダストリ1008、メンバー1009、フォーラム名1010、金額1011及びコンタクトID1012の各項目の入力領域を有する。開始日1004、及び終了日1005は、それぞれ、プロジェクトの開始日及び終了日である。登録時には開始予定日及び終了予定日がそれぞれ登録され、その後実際の開始時及び終了日に修正されてもよい。先方担当者1006には、顧客側の担当者に関するデータが設定される。テーマ候補1007には、プロジェクトの技術分野を示すテーマコードが設定される。インダストリ1008には、顧客の業種を示す業種コードが設定される。メンバー1009は、プロジェクトに参加する社員の識別情報社員ID、氏名等が入力される。フォーラム名1010には、プロジェクトごとに設定されるフォーラム名が設定される。金額1011はプロジェクトの契約金額である。コンタクトID1012は、後述するコンタクト関連データと関係づけるIDである。図4Aにプロジェクトテーブル10のデータ構造の一例を、図4Bにプロジェクト属性テーブル11のデータ構造の一例をそれぞれ示す。プロジェクトテーブル10及びプロジェクト属性テーブル11には、顧客から受注したプロジェクトに関するデータが保存される。プロジェクトテーブル10は、データ項目として、プロジェクトID100と、顧客ID101と、契約ID102と、開始日103と、終了日104と、金額105と、コンタクトID106とを有する。プロジェクトテーブル10の各データ項目には、プロジェクト登録編集画面1000のプロジェクトID1001、顧客名1002、契約ID1003、開始日1004、終了日1005、金額1011及びコンタクトID1012で入力されたデータが保存される。プロジェクト属性テーブル11は、データ項目として、プロジェクトID110と、属性ID111と、属性値ID112と、属性値113とを有する。属性ID111は、各属性の種類を識別するIDである。属性値ID112は、属性値として予め決められた値が設定される場合に、各属性値に割り当てられたIDである。属性値113には、ユーザによって自由に入力された属性値が保存される。プロジェクト属性テーブル11には、プロジェクトID110により関連づけられる様々なプロジェクトに関連する属性データが保存される。例えば、プロジェクト登録編集画面1000における、先方担当者1006、テーマ候補1007、インダストリ1008、メンバー1009、及びフォーラム名1010には、それぞれ属性IDが割り当てられていて、それぞれの入力項目に対して入力された値データが属性値ID112、ないしは属性値113に保存される。管理者は、管理者端末装置7からプロジェクト関連データを参照し、必要に応じて修正することができる。例えば、管理者は、プロジェクトの内容をメンバーからヒアリングしたり、提案書を参照したりしてその内容を理解し、テーマ候補1007及びインダストリ1008に設定されているデータが適切でない場合は、それを修正する。これにより、プロジェクト関連データを入力する者の違いによるデータのバラツキをなくし、利用価値の高いデータとすることができる。<コンタクト関連データ>図5は、コンタクト登録編集画面1400の一例を示す。図6は、コンタクトテーブル14及びコンタクト属性テーブル15のデータ構造の一例を示す。営業活動で顧客見込み客とコンタクトがあったときに、そのコンタクトに関するデータがコンタクト登録編集画面1400から登録される。この画面で入力されたデータがコンタクトテーブル14及びコンタクト属性テーブル15に保存される。コンタクト関連データには、見込み客に対する営業活動におけるコンタクトに係るデータが含まれる。コンタクトテーブル14及びコンタクト属性テーブル15に保存されたデータは、その後、随時コンタクト登録編集画面1400から更新することができる。なお、ここで示す入力項目及びデータ項目は一例に過ぎないので、これらの以外の入力項目及びデータ項目を有していてもよいし、一部の項目は省略可能である。コンタクト登録編集画面1400は、図5に示すように、コンタクトID1401、顧客名1402、案件名1403、コンタクト日1404、コンタクト方法1405、先方担当者1406、報告者1407、同行者1408、引き合い状況1409、コンペ情報1410、営業内容1411、メンバー募集に当たっての求める人材1412及び金額1413の各項目の入力領域を有する。コンタクトID1401は、商品またはサービスなどの所定の一連の営業活動単位に付与される識別情報である。例えば、ある商品またはサービスに関して同一顧客と複数回コンタクトがあったときには、それらの活動は共通のコンタクトIDを有するデータとして登録される。コンタクト方法1405には、個別訪問、セミナーや研究会での出会い、知人の紹介、電話営業などのコンタクトの取り方が設定される。報告者1407及び同行者1408には、コンタクトをした社員の識別情報氏名、社員ID等が設定される。引き合い状況1409には、コンタクトをとったきっかけや反応などが設定される。例えば、先方が積極的であるとか、特に反応のないセミナー出席者などへのプッシュとか、既存顧客からの紹介であるなどが登録される。コンペ情報1410は、各コンタクトがコンペ案件であるか否かを示す。営業内容1411には、コンタクトして行った提案やディスカッションの内容などの具体的な営業内容が設定される。求める人材1412には、このコンタクトからプロジェクトを受注した場合にメンバーとして欲しい人材の条件などが設定される。金額1413は、見込まれる契約金額が設定される。図6Aにコンタクトテーブル14のデータ構造の一例を、図6Bにコンタクト属性テーブル15のデータ構造の一例をそれぞれ示す。コンタクトテーブル14は、データ項目として、コンタクトID140と、コンタクト日141と、社員ID142と、顧客ID143と、金額144と、報告者フラグ145とを有する。コンタクトID140及びコンタクト日141には、コンタクト登録編集画面1400のコンタクトID1401及びコンタクト日1404で設定されたデータが保存される。社員ID142には、コンタクト登録編集画面1400の報告者1407または同行者1408で設定された社員の社員IDが保存される。顧客ID143には顧客名1402で設定された顧客の顧客IDが保存される。金額144には、金額1413で設定された金額が保存される。報告者フラグ145は、報告者1407である社員の場合に設定される。コンタクト属性テーブル15は、コンタクトID150と、属性ID151と、属性値ID152と、属性値153とを有する。コンタクト属性テーブル15には、コンタクトID150により関連づけられる様々なコンタクトに関する属性データが保存される。これは、プロジェクト属性テーブル11の場合と同様に、コンタクト登録編集画面1400の、コンタクトテーブル14に保存されない属性項目を属性ID151とし、それぞれ入力された値データを属性値ID152または属性値153として保存する。管理者は、管理者端末装置7から上述のコンタクト関連データを参照し、必要に応じて修正することができる。<社員関連データ>図7は、講座一覧画面1900の一例を示す。図8は、社員テーブル18、講座テーブル19及び講座申込テーブル20のデータ構造の一例を示す。会社内では、社員向けの多くの講座研修プログラムが用意されている。本システムでは、社員別の講座の受講申込及び受講状況の管理などを行うことができる。図7の講座一覧画面1900は、各社員が自らが受講する講座の申込、及びその受講状況を確認するための画面である。これ以外に、本システムは、マネージャが部下の社員について受講申込、及びその受講状況を確認するための画面を有していてもよい。講座一覧画面1900には、図7に示すように、講座ID1901、講座名1902、開催日1903、受講対象1904、状況1905、及び受講日1906が表示されている。そして、さらに、講座一覧画面1900には、各講座に対する申込の入力を受け付ける領域1907が設けられている。開催日1903には、各講座の開催予定日を示す。複数回予定されていれば、開催日1903にすべての開催日が表示される。状況1905には、社員個人の各講座の受講状況が表示される。受講日1906には、申込が確定した日または受講した日が設定される。申込領域1907に表示されている申込ボタンが押されると、その講座の申込を受け付ける。図8Aに社員テーブル18のデータ構造の一例を、図8Bに講座テーブル19のデータ構造の一例を、図8Cに講座申込テーブル20のデータ構造の一例をそれぞれ示す。社員テーブル18は、社員属性を保存するテーブルで、データ項目として、社員ID180と、所属181と、役職182と、入社年次183と、電子メールアドレス184とを有する。社員テーブル18のデータは、予め設定されている。例えば、社員テーブル18には、社内の他のシステムからデータを取得して設定してもよい。講座テーブル19は、講座属性を保存するテーブルで、データ項目として、講座ID190と、講座名191と、開催日192と、受講対象193とを有する。講座テーブル19には、講座ごとに各項目のデータが予め登録されている。講座一覧画面1900の講座ID1901、講座名1902、開催日1903、受講対象1904は、講座テーブル19に保存されているデータに基づいて表示される。講座申込テーブル20は、データ項目として、講座ID200と、社員ID201と、状況202と、受講日203とを有する。講座申込テーブル20には、講座一覧画面1900で入力されたデータが保存される。つまり、講座申込テーブル20には、社員別に、状況202と、受講日203のデータが保存される。ここで、状況202には、例えば、受講済み、申込確定、申込中、未受講及び欠席などが設定される。受講日203は、申込が確定した受講日である。講座の受講者の確定や受講状況の管理は、図示しない他のシステムで行ってもよいし、社員がマニュアルで行ってもよい。講座申込テーブル20には、最新の受講状況が設定される。<顧客関連データ><顧客関連データ>図9は、顧客登録編集画面2400の一例を示す。図10は、顧客テーブル24及び顧客属性テーブル25のデータ構造の一例を示す。顧客登録編集画面2400は、図9に示すように、顧客名2401、フリガナ2402、顧客ID2403、組織区分2404、業種コード2405、及び本社所在地2406の各入力項目を有する。組織区分2404には、例えば、会社形態株式会社、有限会社などを設定する。業種コード2405には、その顧客の業種を示すコードを設定する。図10Aに顧客テーブル24のデータ構造の一例を、図10Bに顧客属性テーブル25のデータ構造の一例を示す。顧客テーブル24は、データ項目として、顧客ID240を有する。顧客属性テーブル25は、データ項目として、顧客ID250と、属性ID251と、属性値ID252と、属性値253とを有する。顧客属性テーブル25には、顧客ID250により関連づけられる様々な顧客に関する属性データが保存される。これは、プロジェクト属性テーブル11及びコンタクト属性テーブル15の場合と同様に、顧客登録編集画面2400の、顧客テーブル24に保存されない属性項目を属性ID251とし、それぞれ入力された値データを属性値ID252または属性値253として保存する。<エージェント>図11は、エージェント新規登録編集画面2800の一例を示す。図12は、エージェントテーブル28のデータ構造を示す。エージェントは、ユーザの代わりに、ユーザが指定した条件に従って本システム内の所望のデータを収集してユーザへ提供する。エージェントは、エージェント新規登録編集画面2800に対してユーザが指定した条件に基づいて生成される。エージェント新規登録画面2800は、図11に示すように、登録者2801、案件名2802、検索対象2803、キーワード2804、報告者orメンバー2805、顧客2806及び送信先2807の各項目の入力領域を有する。登録者2801には、エージェントを登録する社員の識別情報氏名、社員ID等が設定される。案件名2802には、このエージェントの名称が設定される。検索対象2803には、エージェントがデータ収集を行う対象が設定される。キーワード2804は、検索を行う際のキーワードである。報告者orメンバー2805は、このエージェントが収集したデータを送信する社員である。顧客2806には、検索対象とする顧客の識別情報名称、顧客ID等が設定される。送信先2807には、報告者orメンバー2805のメールアドレスが設定される。図12にエージェントテーブル28のデータ構造の一例を示す。エージェントテーブル28は、データ項目として、エージェントID280と、名称281と、検索対象282と、キーワード283と、社員ID284と、検索対象顧客ID285と、送信先Eメールアドレス286とを有する。エージェント新規登録画面2800で入力されたデータが、それぞれエージェントテーブル28の対応する項目に格納される。データベースサーバ1は、エージェントテーブル28を参照してエージェントを生成する。生成されたエージェントは、例えば1日に1回、データベースサーバ1内のデータを検索して、それぞれキーワード283または検索対象顧客ID285に合致するデータを収集する。そして、エージェントは、収集したデータを送信先Eメールアドレス286に対して配信する。これにより、エージェントを登録したユーザは、自らが関心を持つ分野のデータを得ることができる。<フォーラム>図13にフォーラム管理テーブル30のデータ構造の一例を示す。フォーラム管理テーブル30は、データ項目として、プロジェクトID300と、フォーラムID301と、フォーラム名302とを有する。フォーラムはプロジェクトごとに設定され、各プロジェクトに参加しているメンバー間での情報交換の場として活用される。従って、プロジェクトID300によって、各フォーラムが対応付けられているプロジェクトが特定される。図3のプロジェクト登録編集画面1000でフォーラム名1010が設定されると、フォーラム管理テーブル30にデータが保存される。フォーラムデータ記憶部31は、フォーラムID別にフォーラム内の種々のデータを保存する。例えば、フォーラムに参加している社員の社員ID、フォーラムに書き込まれたデータ等がフォーラムID別に保存されている。<コミュニティ>図14にコミュニティ管理テーブル34のデータ構造の一例を示す。コミュニティ管理テーブル34は、データ項目として、コミュニティID340と、名称341とを有する。コミュニティは、本システム内で社員同士が様々な話題について議論したり、情報交換したりする場である。コミュニティデータ35は、コミュニティID別にコミュニティ内の種々のデータを保存する。例えば、コミュニティに参加している社員の社員ID、コミュニティに書き込まれたデータ等がコミュニティID別に保存されている。<データ検索>本実施形態では、上述した各登録編集画面によって登録されたデータを、ユーザが各自のユーザ端末装置5から各種検索画面を使って検索することができる。例えば、プロジェクト関連データ、コンタクトレポート、顧客データ、社員データなどを検索することができる。さらに、いずれかのデータに関して第1の検索を行って得た検索結果に基づいて、別のデータに関する第2の検索を行うことができる。まず、プロジェクト関連データ及びコンタクトレポートの検索について説明する。図15は、プロジェクト検索画面3000の一例を示す。プロジェクト検索画面3000は、プロジェクトデータの検索条件の入力を受け付ける領域を有している。同図の例では、検索条件として、顧客名、データ内の語句、テーマ候補、インダストリ、開始日、終了日及び金額等を設定することができる。プロジェクト検索画面3000で検索要求を受け付けると、検索エンジン40がここで指定された条件に従ってプロジェクトテーブル10及びプロジェクト属性テーブル11を検索し、条件に合致するプロジェクトを抽出する。抽出されたプロジェクトに関連するデータが、検索結果として出力される。ここで出力されるプロジェクト関連データには、プロジェクトに参加したメンバーが含まれる。本システムは、さらに、プロジェクトに参加した特定のメンバーの個人情報をさらに出力することができる。例えば、検索エンジン40は、その特定のメンバーの社員IDをキーにして、社員テーブル18、講座テーブル19、及び講座申込テーブル20を検索して、社員の属性データを取得する。あるいは、検索エンジン40は、その特定のメンバーの社員IDをキーにして、プロジェクトテーブル10及びプロジェクト属性テーブル11、またはコンタクトテーブル14及びコンタクト属性テーブル15をさらに検索し、その特定のメンバーが現在または過去に参加したプロジェクトやコンタクトに関するデータを抽出するようにしてもよい。これにより、その特定のメンバーが現在または過去に参加したプロジェクトやコンタクトに関するデータがさらに出力される。本システムでは、特にKnowWho検索を行う場合、まず、上記のプロジェクト検索により、知りたい技術分野テーマ候補、あるいは業界インダストリに関連するプロジェクトの検索を行う。そして、その検索により抽出されたプロジェクトに関わったメンバーの中には、知りたい技術分野あるいは業界に詳しい人がいると考えられる。このとき、本システムではさらに、特定の社員が有するノウハウなどについて、追加の情報検索が可能である。つまり、本システムでは、プロジェクト検索を介してKnowWho検索を行う。このようなKnowWho検索が行える背景には、プロジェクト関連データの精度の高さがある。つまり、通常のナレッジマネジメントシステムの場合、社員個人が自らの経験、スキルなどについて登録するようになっているが、現実にはこれを徹底させることが難しい。これに対して、本システムの場合、プロジェクト関連データは、本システム以外のシステムでも利用される重要なデータである。そのため、報告者は、好むと好まざるとに関わらず、プロジェクトに関するデータを入力せざるを得ず、かつ、入力したデータを管理者が見直すことによりデータの精度を高めている。従って、本システムでは、プロジェクト関連データの入力が保証され、かつ、その入力されたデータは高い信頼性を有する。これにより、欲しい情報と関連の深いプロジェクトの検索を介して、そのプロジェクトに関わった社員を特定することにより効果的なKnowWho検索を行うことができる。図16は、コンタクトレポート検索画面4000の一例を示す。コンタクトレポート検索画面4000は、同図に示すように、顧客名、データ内の語句、引き合い区分、インダストリ、コンタクト日及び金額等の検索条件の入力を受け付ける領域を有している。コンタクトレポート検索画面4000で検索要求を受け付けると、検索エンジン40がここで指定された条件に従ってコンタクトテーブル14及びコンタクト属性テーブル15を検索し、条件に合致するコンタクトデータを抽出して、そのコンタクトに関連するコンタクトデータが出力される。ここでも、出力されるコンタクトデータには、コンタクトに参加したメンバーが含まれる。本システムは、さらに、検索エンジン40によって、コンタクトに参加した特定のメンバーの社員属性をさらに検索することができる。例えば、検索エンジン40は、その特定のメンバーの社員IDをキーにして、社員テーブル18、講座テーブル19、及び講座申込テーブル20を検索して、社員属性を取得する。あるいは、検索エンジン40は、その特定のメンバーの社員IDをキーにして、プロジェクトテーブル10及びプロジェクト属性テーブル11、またはコンタクトテーブル14及びコンタクト属性テーブル15をさらに検索し、その特定のメンバーが現在または過去に参加したプロジェクトやコンタクトに関するデータを抽出するようにしてもよい。これにより、その特定のメンバーが現在または過去に参加したプロジェクトやコンタクトに関するデータがさらに出力される。従って、コンタクトレポートの検索によっても、上述のKnowWho検索が可能であり、社内でのナレッジ共有が促進される。また、本実施形態におけるコンタクトデータに代えて、またはこれに加えて、研究開発活動に関するデータを同様なデータ構造で保持するようにしてもよい。この研究開発データは、コンタクトデータと同様に登録及び編集ができ、検索対象とすることもできる。つまり、研究開発データを検索することにより、研究開発における特定の技術あるいはテーマについて多くの知識や経験を持っている社員を検索することができ、研究開発分野における社内でのナレッジ共有を促進することができる。さらに、各研究開発テーマ等とプロジェクトとの関連づけておくことにより、どの研究開発テーマが具体的にどのプロジェクトで活用されているのかも容易に把握することが可能となる。上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。