(57)【要約】【課題】利便性を高める。【解決手段】所定の分野の所定の事象に関し第１の観点からみた場合の価値基準を反映する第１のデータ項目群を備えた中央データベース部を有するデータベースシステムにおいて、データ項目提供部と、自由データ受付部と、第２のユーザインタフェース部と、第１のユーザインタフェース部とを備える。前記第１のデータ項目群に、第１のユーザ集合に属するユーザと、第２のユーザ集合に属するユーザとが、意思を疎通するためのデータ項目である連絡用データ項目を設けることも好ましい。さらに、前記第１のユーザインタフェース部が、前記第１のユーザ集合に属するユーザからの求めに応じて、テンプレートとしてのデータ項目の変更を要求することも望ましい。【選択図】  図１
2004192048.tif 000002
【特許請求の範囲】
【請求項１】
所定の分野の所定の事象に関し第１の観点からみた場合の価値基準を反映する第１のデータ項目群を備えた中央データベース部を有するデータベースシステムにおいて、
前記第１のデータ項目群に属するデータ項目をテンプレートとして提供するデータ項目提供部と、
前記事象を、前記第１の観点に拘束されない自由な観点からみた価値基準を反映した自由データの供給を受ける自由データ受付部と、
前記事象を第２の観点からみる１または複数のユーザから構成される第２のユーザ集合に属するユーザが、前記データ項目提供部が提供するデータ項目を用いて当該自由データを第１のデータ項目群に属するデータ項目に対応付け、対応付けの結果を前記中央データベース部に供給するための第２のユーザインタフェース部と、
前記事象を、前記第１の観点からみる１または複数のユーザから構成される第１のユーザ集合に属するユーザが、当該対応付けの結果にアクセスするための第１のユーザインタフェース部とを備えたことを特徴とするデータベースシステム。
【請求項２】
所定の分野の所定の事象に関し第１の観点からみた場合の価値基準を反映する第１のデータ項目群と、当該事象に関し第２の観点からみた場合の価値基準を反映する第２のデータ項目群とを備えた中央データベース部を有するデータベースシステムにおいて、
前記第１のデータ項目群に属するデータ項目のなかで主キーを構成する１または複数のデータ項目である第１の基準データ項目の値と、前記第２のデータ項目群に属するデータ項目のなかで主キーを構成する１または複数のデータ項目である第２の基準データ項目の値とを対応付ける対応関係管理部を備え、
前記第１のデータ項目群または第２のデータ項目群のうち少なくともいずれか一方には、前記事象を、前記第１の観点からみる１または複数のユーザから構成される第１のユーザ集合に属するユーザと、当該事象を第２の観点からみる１または複数のユーザから構成される第２のユーザ集合に属するユーザとが意思を疎通するためのデータ項目である連絡用データ項目を設けておき、前記第１の基準データ項目または第２の基準データ項目のいずれかの値の属する行のなかでいずれかのデータ項目の値が変更されたとき、前記対応関係管理部によってその第１または第２の基準データ項目の値に対応付けられた第２または第１の基準データ項目の値が属する行の連絡用データ項目の値を変化させることを特徴とするデータベースシステム。
【請求項３】
請求項１または２のデータベースシステムにおいて、
前記第１のデータ項目群には、
前記第１のユーザ集合に属するユーザと、第２のユーザ集合に属するユーザとが、意思を疎通するためのデータ項目である連絡用データ項目を含むことを特徴とするデータベースシステム。
【請求項４】
請求項１のデータベースシステムにおいて、
前記第１のユーザインタフェース部は、
前記第１のユーザ集合に属するユーザからの求めに応じて、前記テンプレートとしてのデータ項目の変更を要求することを特徴とするデータベースシステム。
【請求項５】
請求項１のデータベースシステムにおいて、
前記第２のユーザインタフェース部は、
前記第２のユーザ集合に属するユーザからの求めに応じて、前記テンプレートとしてのデータ項目の変更を要求することを特徴とするデータベースシステム。
【請求項６】
請求項３または４のデータベースシステムにおいて、
前記変更には、前記テンプレートとしての第１のデータ項目群に対する新たなデータ項目の追加および／または既存のデータ項目の削除を含むことを特徴とするデータベースシステム。
【請求項７】
請求項１または２のデータベースシステムにおいて、
前記第１のユーザ集合に属するユーザと、前記第２のユーザ集合に属するユーザとのあいだで、メッセージ交換を行うためのメッセージ交換部を設けたことを特徴とするデータベースシステム。
【請求項８】
請求項１のデータベースシステムにおいて、
前記中央データベース部に対し、データを提供する１または複数の周辺データベース部を設け、
前記自由データは、当該周辺データベースから、前記自由データ受付部に供給することを特徴とするデータベースシステム。
【請求項９】
請求項１のデータベースシステムにおいて、
前記第１のユーザインタフェース部は、
前記中央データベース部に格納されている第１のデータ項目群の各データに対して検索に使用した検索条件を記憶しておく第１の検索条件記憶部と、
当該第１の検索条件記憶部に記憶されている検索条件を再利用して検索を行うとき、第１のデータ項目群の各データのうち、当該検索条件に適合し、なおかつ、前回の検索の際に比べて値が変化しているデータだけを選択的に検索し、その検索結果を出力する第１の差分検索実行部とを備えることを特徴とするデータベースシステム。
【請求項１０】
請求項１のデータベースシステムにおいて、
前記第２のユーザインタフェース部は、
前記中央データベース部に格納されている第１のデータ項目群の各データに対して検索に使用した検索条件を記憶しておく第２の検索条件記憶部と、
当該第２の検索条件記憶部に記憶されている検索条件を再利用して検索を行うとき、第１のデータ項目群の各データのうち、当該検索条件に適合し、なおかつ、前回の検索の際に比べて値が変化しているデータだけを選択的に検索し、その検索結果を出力する第２の差分検索実行部とを備えることを特徴とするデータベースシステム。
【請求項１１】
所定の分野の所定の事象に関し第１の観点からみた場合の価値基準を反映する第１のデータ項目群を備えた中央データベース部を用いるデータベースサービス方法において、
データ項目提供部が、前記第１のデータ項目群に属するデータ項目をテンプレートとして提供し、
自由データ受付部が、前記事象を、前記第１の観点に拘束されない自由な観点からみた価値基準を反映した自由データの供給を受け、
前記事象を第２の観点からみる１または複数のユーザから構成される第２のユーザ集合に属するユーザが、第２のユーザインタフェース部を介し、前記データ項目提供部が提供するデータ項目を用いて当該自由データを第１のデータ項目群に属するデータ項目に対応付けると共に、対応付けの結果を前記中央データベース部に供給し、
前記事象を、前記第１の観点からみる１または複数のユーザから構成される第１のユーザ集合に属するユーザが、第１のユーザインタフェース部を介して、当該対応付けの結果にアクセスすることを特徴とするデータベースサービス方法。
【請求項１２】
所定の分野の所定の事象に関し第１の観点からみた場合の価値基準を反映する第１のデータ項目群と、当該事象に関し第２の観点からみた場合の価値基準を反映する第２のデータ項目群とを備えた中央データベース部を用いるデータベースサービス方法において、
対応関係管理部が、前記第１のデータ項目群に属するデータ項目のなかで主キーを構成する１または複数のデータ項目である第１の基準データ項目の値と、前記第２のデータ項目群に属するデータ項目のなかで主キーを構成する１または複数のデータ項目である第２の基準データ項目の値とを対応付け、
前記第１のデータ項目群または第２のデータ項目群のうち少なくともいずれか一方には、前記事象を、前記第１の観点からみる１または複数のユーザから構成される第１のユーザ集合に属するユーザと、当該事象を第２の観点からみる１または複数のユーザから構成される第２のユーザ集合に属するユーザとが意思を疎通するためのデータ項目である連絡用データ項目を設けておき、前記第１の基準データ項目または第２の基準データ項目のいずれかの値の属する行のなかでいずれかのデータ項目の値が変更されたとき、前記対応関係管理部によってその第１または第２の基準データ項目の値に対応付けられた第２または第１の基準データ項目の値が属する行の連絡用データ項目の値を変化させることを特徴とするデータベースサービス方法。
【請求項１３】
請求項１１のデータベースサービス方法において、
前記第１のデータ項目群には、
前記第１のユーザ集合に属するユーザと、第２のユーザ集合に属するユーザとが、意思を疎通するためのデータ項目である連絡用データ項目を含むことを特徴とするデータベースサービス方法。
【請求項１４】
請求項１１のデータベースサービス方法において、
前記第１のユーザインタフェース部は、
前記第１のユーザ集合に属するユーザからの求めに応じて、前記テンプレートとしてのデータ項目の変更を要求することを特徴とするデータベースサービス方法。
【請求項１５】
請求項１１のデータベースサービス方法において、
前記第２のユーザインタフェース部は、
前記第２のユーザ集合に属するユーザからの求めに応じて、前記テンプレートとしてのデータ項目の変更を要求することを特徴とするデータベースサービス方法。
【請求項１６】
請求項１４または１５のデータベースサービス方法において、
前記変更には、前記テンプレートとしての第１のデータ項目群に対する新たなデータ項目の追加および／または既存のデータ項目の削除を含むことを特徴とするデータベースサービス方法。
【請求項１７】
請求項１１または１２のデータベースサービス方法において、
前記第１のユーザ集合に属するユーザと、前記第２のユーザ集合に属するユーザとのあいだで、メッセージ交換部を用いてメッセージ交換を行うことを特徴とするデータベースサービス方法。
【請求項１８】
請求項１１のデータベースサービス方法において、
前記中央データベース部に対し、１または複数の周辺データベース部がデータを提供する場合、
前記自由データは、当該周辺データベースから、前記自由データ受付部に供給することを特徴とするデータベースサービス方法。
【請求項１９】
請求項１１のデータベースサービス方法において、
前記第１のユーザインタフェース部では、
第１の検索条件記憶部が、前記中央データベース部に格納されている第１のデータ項目群の各データに対して検索に使用した検索条件を記憶しておき、
当該第１の検索条件記憶部に記憶されている検索条件を再利用して検索を行うとき、第１の差分検索実行部が、第１のデータ項目群の各データのうち、当該検索条件に適合し、なおかつ、前回の検索の際に比べて値が変化しているデータだけを選択的に検索し、その検索結果を出力することを特徴とするデータベースサービス方法。
【請求項２０】
請求項１１のデータベースサービス方法において、
前記第２のユーザインタフェース部では、
第２の検索条件記憶部が、前記中央データベース部に格納されている第１のデータ項目群の各データに対して検索に使用した検索条件を記憶しておき、
当該第２の検索条件記憶部に記憶されている検索条件を再利用して検索を行うとき、第２の差分検索実行部が、第１のデータ項目群の各データのうち、当該検索条件に適合し、なおかつ、前回の検索の際に比べて値が変化しているデータだけを選択的に検索し、その検索結果を出力することを特徴とするデータベースサービス方法。
【請求項２１】
コンピュータを、所定の分野の所定の事象に関し第１の観点からみた場合の価値基準を反映する第１のデータ項目群を備えた中央データベース部として機能させるグループウエアにおいて、
前記第１のデータ項目群に属するデータ項目をテンプレートとして提供するデータ項目提供機能と、
前記事象を、前記第１の観点に拘束されない自由な観点からみた価値基準を反映した自由データの供給を受ける自由データ受付機能と、
前記事象を第２の観点からみる１または複数のユーザから構成される第２のユーザ集合に属するユーザが、前記データ項目提供部が提供するデータ項目を用いて当該自由データを第１のデータ項目群に属するデータ項目に対応付け、対応付けの結果を前記中央データベース部に供給するための第２のユーザインタフェース機能と、
前記事象を、前記第１の観点からみる１または複数のユーザから構成される第１のユーザ集合に属するユーザが、当該対応付けの結果にアクセスするための第１のユーザインタフェース機能を備えることを特徴とするグループウエア。
【請求項２２】
コンピュータを、所定の分野の所定の事象に関し第１の観点からみた場合の価値基準を反映する第１のデータ項目群と、当該事象に関し第２の観点からみた場合の価値基準を反映する第２のデータ項目群とを備えた中央データベース部として機能させるグループウエアにおいて、
前記第１のデータ項目群に属するデータ項目のなかで主キーを構成する１または複数のデータ項目である第１の基準データ項目の値と、前記第２のデータ項目群に属するデータ項目のなかで主キーを構成する１または複数のデータ項目である第２の基準データ項目の値とを対応付ける対応関係管理機能を備え、
前記第１のデータ項目群または第２のデータ項目群のうち少なくともいずれか一方には、前記事象を、前記第１の観点からみる１または複数のユーザから構成される第１のユーザ集合に属するユーザと、当該事象を第２の観点からみる１または複数のユーザから構成される第２のユーザ集合に属するユーザとが意思を疎通するためのデータ項目である連絡用データ項目を設けておき、前記第１の基準データ項目または第２の基準データ項目のいずれかの値の属する行のなかでいずれかのデータ項目の値が変更されたとき、前記対応関係管理機能によってその第１または第２の基準データ項目の値に対応付けられた第２または第１の基準データ項目の値が属する行の連絡用データ項目の値を変化させることを特徴とするグループウエア。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はデータベースシステム、データベースサービス方法、およびグループウエアに関し、例えば、ある企業の内部で、顧客からの要望に応じた要求仕様をまとめる企画部門の社員と、製品の設計仕様をまとめる設計部門の社員とのあいだで連携して協調的に作業を進める場合などに利用して好適なものである。
【０００２】
【従来の技術】
製造業に属するある企業の内部で、顧客からの要求に応じた要求仕様をまとめる企画部門の社員と、製品の設計仕様（製品仕様）をまとめる設計部門の社員とのあいだで連携して作業を進める場合、データベースなどを含むグループウエアを利用するのが効率的である。
【０００３】
当該企業の製品を利用した顧客などから提出され、各販売店などのＣＲＭシステムを介して当該企業へ供給される要望や苦情などは、企画部門の社員により、要求仕様としてまとめられ、グループウエアを利用して、設計部門の社員に伝えられる。
【０００４】
企画部門や設計部門の個々の社員は、それぞれに異なるスケジュールで自身の業務に関する活動を行っているため、会議を開いて意見交換を行わないかぎり、要求仕様の内容を伝えたり、当該要求仕様中の個々の項目に関し、設計部門がどのように対応し設計仕様に反映させているのか、あるいは反映させていないのかなどを企画部門の社員が知ることはできないが、当該グループウエアを利用すれば、会議を開かなくても、ある程度、詳細な意見交換を行うことが可能である。
【０００５】
【発明が解決しようとする課題】
ところが、既存のグループウエアのデータベースは要求仕様中の各項目と、設計仕様中の各項目との対応関係が必ずしも明確ではないため利便性に欠け、当該データベースを介して企画部門の社員と設計部門の社員が要求仕様や設計仕様の内容を相互に伝え合ったり、要求仕様や設計仕様中の個々の項目に関する作業の進捗状況を確認したりすることが困難で、利便性に欠け、結局、要求仕様に対応しない設計仕様が決定され、その設計仕様に応じた新製品が製造されてしまうことも少なくない。
【０００６】
意思の疎通が不十分であると感じたときには、前記会議を開くことも考えられるが、実際の企業の内部では各社員が多忙なことも多く、１つの事案に関してそれほど頻繁に会議を開くことも難しい。また、頻繁に会議を開くようでは、グループウエアの本来の目的であるグループの生産性の向上に反する結果となってしまう。
【０００７】
さらに、本来、新製品は顧客からの要望や苦情に対応した機能を持つものとして設計されるべきものであると考えられ、要求仕様が完全に定義（決定）され、設計部門に正確に伝達されたあとで設計仕様が定義される手順となるのが理想であるが、実際には、新製品の開発スケジュールが予め決まっていてそのスケジュールに合わせて設計仕様が作成されることも多く、設計仕様が一応、決定されたあとで新たな要求仕様が出され、それに対応するために設計仕様を変更すること等も起こり得る。
【０００８】
これらの事情を考慮すると、グループウエアの機能や利便性が、要求仕様の作成や設計仕様の作成を含む一連の作業の流れの効率や質に決定的な影響を与える可能性が高いということができる。
【０００９】
このような問題は、情報共有や情報交換の手段としてデータベースを用いるシステムやサービスに広く共通するものである。
【００１０】
【課題を解決するための手段】
かかる課題を解決するために、第１の発明では、所定の分野の所定の事象（例えば、プリンタ装置などの製品（あるいは、製品開発））に関し第１の観点（例えば、設計部門の観点）からみた場合の価値基準を反映する第１のデータ項目群を備えた中央データベース部（例えば、共有データベース３２）を有するデータベースシステムにおいて、前記第１のデータ項目群に属するデータ項目をテンプレート（例えば、当該仕様項目関連テーブルＴＢ３を中核とする仕様項目テンプレート）として提供するデータ項目提供部（例えば、仕様項目テンプレートＴＢ３）と、前記事象を、前記第１の観点に拘束されない自由な観点（例えば、製品を購入した顧客の観点）からみた価値基準を反映した自由データの供給を受ける自由データ受付部（例えば、要望テーブルＴＢ４）と、前記事象を第２の観点（例えば、企画部門の観点）からみる１または複数のユーザから構成される第２のユーザ集合（例えば、企画部門）に属するユーザ（例えば、Ｕ２０）が、前記データ項目提供部が提供するデータ項目を用いて当該自由データを第１のデータ項目群に属するデータ項目に対応付け、対応付けの結果を前記中央データベース部に供給するための第２のユーザインタフェース部（例えば、クライアントソフトＣＬ２０）と、前記事象を、前記第１の観点からみる１または複数のユーザから構成される第１のユーザ集合（例えば、設計部門）に属するユーザが、当該対応付けの結果にアクセスするための第１のユーザインタフェース部（例えば、クライアントソフトＣＬ２２）とを備えたことを特徴とする。
【００１１】
また、第２の発明では、所定の分野の所定の事象に関し第１の観点からみた場合の価値基準を反映する第１のデータ項目群と、当該事象に関し第２の観点からみた場合の価値基準を反映する第２のデータ項目群とを備えた中央データベース部を有するデータベースシステムにおいて、前記第１のデータ項目群に属するデータ項目のなかで主キー（例えば、葉仕様項目ＩＤ）を構成する１または複数のデータ項目である第１の基準データ項目の値と、前記第２のデータ項目群に属するデータ項目のなかで主キー（例えば、要求仕様項目ＩＤ）を構成する１または複数のデータ項目である第２の基準データ項目の値とを対応付ける対応関係管理部（例えば、仕様項目関連テーブルＴＢ３）を備え、前記第１のデータ項目群または第２のデータ項目群のうち少なくともいずれか一方には、前記事象を、前記第１の観点からみる１または複数のユーザから構成される第１のユーザ集合に属するユーザと、当該事象を第２の観点からみる１または複数のユーザから構成される第２のユーザ集合に属するユーザとが意思を疎通するためのデータ項目である連絡用データ項目（例えば、意思疎通管理列）を設けておき、前記第１の基準データ項目または第２の基準データ項目のいずれかの値の属する行のなかでいずれかのデータ項目の値（例えば、重要度）が変更されたとき、前記対応関係管理部によってその第１または第２の基準データ項目の値に対応付けられた第２または第１の基準データ項目の値が属する行の連絡用データ項目の値を変化させることを特徴とする。
【００１２】
さらに、第３の発明では、所定の分野の所定の事象に関し第１の観点からみた場合の価値基準を反映する第１のデータ項目群を備えた中央データベース部を用いるデータベースサービス方法において、データ項目提供部が、前記第１のデータ項目群に属するデータ項目をテンプレートとして提供し、自由データ受付部が、前記事象を、前記第１の観点に拘束されない自由な観点からみた価値基準を反映した自由データの供給を受け、前記事象を第２の観点からみる１または複数のユーザから構成される第２のユーザ集合に属するユーザが、第２のユーザインタフェース部を介し、前記データ項目提供部が提供するデータ項目を用いて当該自由データを第１のデータ項目群に属するデータ項目に対応付けると共に、対応付けの結果を前記中央データベース部に供給し、前記事象を、前記第１の観点からみる１または複数のユーザから構成される第１のユーザ集合に属するユーザが、第１のユーザインタフェース部を介して、当該対応付けの結果にアクセスすることを特徴とする。
【００１３】
さらにまた、第４の発明では、所定の分野の所定の事象に関し第１の観点からみた場合の価値基準を反映する第１のデータ項目群と、当該事象に関し第２の観点からみた場合の価値基準を反映する第２のデータ項目群とを備えた中央データベース部を用いるデータベースサービス方法において、対応関係管理部が、前記第１のデータ項目群に属するデータ項目のなかで主キーを構成する１または複数のデータ項目である第１の基準データ項目の値と、前記第２のデータ項目群に属するデータ項目のなかで主キーを構成する１または複数のデータ項目である第２の基準データ項目の値とを対応付け、前記第１のデータ項目群または第２のデータ項目群のうち少なくともいずれか一方には、前記事象を、前記第１の観点からみる１または複数のユーザから構成される第１のユーザ集合に属するユーザと、当該事象を第２の観点からみる１または複数のユーザから構成される第２のユーザ集合に属するユーザとが意思を疎通するためのデータ項目である連絡用データ項目を設けておき、前記第１の基準データ項目または第２の基準データ項目のいずれかの値の属する行のなかでいずれかのデータ項目の値が変更されたとき、前記対応関係管理部によってその第１または第２の基準データ項目の値に対応付けられた第２または第１の基準データ項目の値が属する行の連絡用データ項目の値を変化させることを特徴とする。
【００１４】
また、第５の発明では、コンピュータを、所定の分野の所定の事象に関し第１の観点からみた場合の価値基準を反映する第１のデータ項目群を備えた中央データベース部として機能させるグループウエアにおいて、前記第１のデータ項目群に属するデータ項目をテンプレートとして提供するデータ項目提供機能と、前記事象を、前記第１の観点に拘束されない自由な観点からみた価値基準を反映した自由データの供給を受ける自由データ受付機能と、前記事象を第２の観点からみる１または複数のユーザから構成される第２のユーザ集合に属するユーザが、前記データ項目提供部が提供するデータ項目を用いて当該自由データを第１のデータ項目群に属するデータ項目に対応付け、対応付けの結果を前記中央データベース部に供給するための第２のユーザインタフェース機能と、前記事象を、前記第１の観点からみる１または複数のユーザから構成される第１のユーザ集合に属するユーザが、当該対応付けの結果にアクセスするための第１のユーザインタフェース機能を備えることを特徴とする。
【００１５】
さらにまた、第６の発明では、コンピュータを、所定の分野の所定の事象に関し第１の観点からみた場合の価値基準を反映する第１のデータ項目群と、当該事象に関し第２の観点からみた場合の価値基準を反映する第２のデータ項目群とを備えた中央データベース部として機能させるグループウエアにおいて、前記第１のデータ項目群に属するデータ項目のなかで主キーを構成する１または複数のデータ項目である第１の基準データ項目の値と、前記第２のデータ項目群に属するデータ項目のなかで主キーを構成する１または複数のデータ項目である第２の基準データ項目の値とを対応付ける対応関係管理機能を備え、前記第１のデータ項目群または第２のデータ項目群のうち少なくともいずれか一方には、前記事象を、前記第１の観点からみる１または複数のユーザから構成される第１のユーザ集合に属するユーザと、当該事象を第２の観点からみる１または複数のユーザから構成される第２のユーザ集合に属するユーザとが意思を疎通するためのデータ項目である連絡用データ項目を設けておき、前記第１の基準データ項目または第２の基準データ項目のいずれかの値の属する行のなかでいずれかのデータ項目の値が変更されたとき、前記対応関係管理機能によってその第１または第２の基準データ項目の値に対応付けられた第２または第１の基準データ項目の値が属する行の連絡用データ項目の値を変化させることを特徴とする。
【００１６】
このような構成により、第１のユーザ集合に属するユーザと第２のユーザ集合に属するユーザのあいだの意思疎通を効率的に行うことができる。
【００１７】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかるデータベースシステム、データベースサービス方法、およびグループウエアの実施形態について説明する。
【００１８】
（Ａ−１）実施形態の構成
本実施形態の通信システム１０の全体構成例を図１に示す。
【００１９】
図１において、当該通信システム１０の構成要素は、大きく外部システム１１と内部システム１２の２つに分かれる。
【００２０】
内部システム１２は、製造業者である企業Ｅ１の主として社内に構築されるシステムであり、外部システム１１はこの企業Ｅ１の社外に存在する。ただし外部システム１１は、内部システム１２に対立する概念であり、それ自体が必ずしも一体的なシステムである必要はない。通常、当該外部システム１１は、広域に分散配置された個々の販売店などのＣＲＭ（顧客関係管理）システムの寄せ集めである。したがって、外部システム１１中のあるＣＲＭシステムと他のＣＲＭシステムのあいだに、厳密な統一性や関係（連携関係など）が存在している必要はない。販売店を運営する事業者が異なれば、各ＣＲＭシステム（例えば、ＣＲＭデータベース１５と１６）のあいだに統一性や連携関係は存在しないのが普通である。
【００２１】
一般的なＣＲＭの概念は広範な内容を含んでいるが、本実施形態におけるＣＲＭは、企業Ｅ１が製造し各販売事業者Ｅ２，Ｅ３の販売店が販売した製品（一例としては、プリンタ装置など）に関し、その購入者（顧客）から寄せられた要望（苦情も含む）を収集して外部ネットワーク１３経由で内部システム１２のデータベース（３２など）へ供給する機能があれば足りる。
【００２２】
図１に示したＣＲＭデータベース１５と１６は、それぞれ異なる事業者が運営する販売店に配置されたデータベースで、それぞれ別個のＣＲＭシステムに属する。ここでは、ＣＲＭデータベース１５は販売事業者Ｅ２のＣＲＭシステムに属するデータベースであり、ＣＲＭデータベース１６は販売事業者Ｅ３のＣＲＭシステムに属するデータベースであるものとする。このＣＲＭデータベース１５，１６に、前記顧客からの要望が蓄積され、例えば、定期的に、内部システム１２のデータベースへ供給される。
【００２３】
ＣＲＭシステムのデータベースである以上、何らかの意味で、顧客からの要望を格納するためのデータ項目は設けられているのが普通であると考えられるが、属するＣＲＭシステムに統一性がないため、ＣＲＭデータベース１５，１６のデータ項目（関係表の列名）にも統一性はなく、広狭の相違などが存在する。その具体的なデータ項目は、例えば、事業者Ｅ２では包括的な１つのデータ項目「顧客の要望」であり、事業者Ｅ３では「製品の外観に関する問題点」、「製品の操作性に関する問題点」等と製品に関する顧客の要望を細かく複数のデータ項目に分類してある可能性もある。
【００２４】
また、このような外部のＣＲＭシステム相互間だけでなく、外部のＣＲＭシステムと内部システム１２のあいだでも統一性は存在しないから、ＣＲＭデータベース１５（または１６）と、内部システム１２内のデータベース（例えば、３２）のあいだでも、詳細なレベルではデータ項目が一致しないのが普通である。
【００２５】
なお、データベースには、その論理データモデル（ＤＢＭＳのタイプ）に応じて網型、階層型などのタイプがあり、本発明は網型や階層型のデータベースにも適用可能であるが、本実施形態で使用するデータベースは、データベース１５，１６，３２なども含め、すべて関係型データベースであるものとする。
【００２６】
ＣＲＭデータベース１５，１６から内部システム１２のデータベース（例えば、３２）へ供給されるとき、各ＣＲＭデータベース１５、１６内のデータ項目にしたがって記述された当該要望は、例えば、ＣＳＶ（コンマ区切り）形式のファイルなどに収容し、ＦＴＰプロトコル等を用いて転送するものであってよい。
【００２７】
ただし、外部システム１１と内部システム１２のあいだで相互運用性を確保するため、当該ＣＳＶファイルにおいて、コンマで区切られた各項目の順番や意味には、ある程度の統一性を付与しておくことが望ましい。もし必要ならば、外部システム１０側が送信した時点のＣＳＶファイルにはこのような統一性を付与せず、内部システム１４側で行う作業によって統一性を確保するようにしてもよい。
【００２８】
一例として、ＣＳＶファイルのコンマ（，）で区切られた各項目の意味およびその順序は次のフォーマット（１０）のようなものであってよい。
【００２９】
「報告日，製品の機種名，要望の内容，要望元，緊急度」  …（１０）
このうち要望の内容は、上述した「顧客の要望」や、「製品の外観に関する問題点」、「製品の操作性に関する問題点」など、事業者Ｅ２，Ｅ３間で広狭の相違などが存在し得る項目であるが、それらすべてを、当該「要望の内容」という区分に収容する。この「要望の内容」は、本実施形態にとって最も重要な項目である。
【００３０】
なお、「報告日」とは、その要望が各事業者Ｅ２，Ｅ３などに報告された日付を指し、「製品の機種名」とは、要望の対象となっている製品（例えば、プリンタ装置など）を特定するための機種名を指し、「要望元」とは、その要望を提出した顧客またはその要望をとりまとめた地域、組織、人などの名称を指し、「緊急度」とはその要望に企業Ｅ１が対応する際の緊急性の度合いを示す。この緊急度の値は、顧客または事業者Ｅ２，Ｅ３の希望である。
【００３１】
もちろん、これ以外の項目が含まれていてもよく、これらの項目の一部を省略したり、これらの項目の一部を他の項目と置き換えてもよいことは当然である。ただし、前記「要望の内容」は必須であり、多くの場合、「製品の機種名」も欠かすことのできない項目であると考えられる。また、各項目の順番がこの通りでなくてもよいことは当然である。
【００３２】
図１上では外部システム１１に分類してある外部ネットワーク１３は、前記ＣＲＭデータベース１５や１６を内部ネットワーク１４に接続するためのネットワークである。当該外部ネットワーク１３は、インターネットであってもよく、専用線などであってもよい。
【００３３】
外部ネットワーク１３に接続されるＣＲＭデータベースの数は、図示した２つに限定する必要はない。多くの場合、２つよりもはるかに多くのＣＲＭデータベースから、前記要望が、内部システム１２のデータベースへ供給されるものと考えられる。
【００３４】
前記内部システム１２は、図１に示すように、内部ネットワーク１４と、通信端末２０〜２５と、管理システム２６と、電子掲示板システム３０と、データベースサーバ３１と、共有データベース３２と、対応シート作成システム３３と、要望管理システム３４と、製品仕様書作成システム３５とを備えている。
【００３５】
このうち内部ネットワーク１４は、前記企業Ｅ１の社内に構築されたＬＡＮ（ローカルエリアネットワーク）であってよい。当該内部ネットワーク１４と前記外部ネットワーク１３のあいだには、図示しないルータやファイアウオールなどが介在するのが普通である。
【００３６】
また、データベースサーバ３１は、共有データベース３２を管理するサーバで、ＤＢＭＳの中心的な機能を提供する。本実施形態の論理データモデルは関係モデルであるから、ＤＢＭＳはＲＤＢＭＳ（関係ＤＢＭＳ）である。そして、当該共有データベース３２は、関係表の集まりである。企画部門と設計部門のユーザＵ２０〜Ｕ２３に共有され得る製品仕様テーブルＴＢ１や対応シートテーブルＴＢ２なども、関係表の１つとして、当該共有データベース３２に含まれている。
【００３７】
その詳細については後で説明するが、対応シートテーブルＴＢ２の内容は、要求仕様書（要求仕様書の内容は実質的に、顧客の要望に対応するための対応シートに等しい）に反映され、製品仕様テーブルＴＢ１の内容は、設計仕様書（製品仕様書）の内容に反映される。
【００３８】
要求仕様書や設計仕様書そのものは、電子文書として文書管理部２８で管理され、適宜、通信端末（２０など）を操作するユーザによって閲覧され、編集されるが、その記述内容は、対応シートテーブルＴＢ２，製品仕様テーブルＴＢ１に応じたものである。また、通信端末（２０など）を介して行う編集作業によって、要求仕様書や、製品仕様書の記述内容を変更すれば、その変更は、テーブルＴＢ１、ＴＢ２に反映される。
【００３９】
なお、当該共有データベース３２はもちろん、物理的には、ハードディスクなどの記憶装置が提供する記憶機能を利用して実現されるものである。
【００４０】
一方、前記管理システム２６はその配下にタスク管理部２７と、文書管理部２８と、ユーザ管理部２９を有する一種のサーバである。
【００４１】
タスク管理部２７は内部システム１２中の各ユーザ（社員など）Ｕ２０〜Ｕ２５のタスク（仕事）の進捗状況などを管理する部分で、必要に応じて、前記共有データベース３２へのアクセス（データの書き込みや読み出し等）を行う。当該タスク管理部２７自体が、図示しないデータベースを持つものであってもよい。
【００４２】
文書管理部２８は、内部システム１２中でユーザＵ２０〜Ｕ２５によって作成され閲覧される各文書（各文書ファイル）を蓄積し管理する部分である。当該文書管理部２８も、必要に応じて、前記共有データベース３２へのアクセスを行い、図示しないデータベースを持つものであってよい。
【００４３】
なお、前記ユーザＵ２０〜Ｕ２５のうち、ユーザＵ２０とＵ２１は当該企業Ｅ１中の企画部門の社員であり、ユーザＵ２２とＵ２３は当該企業Ｅ１中の設計部門の社員であり、ユーザＵ２４は共有データベース３２に対するデータの入力作業などを担当するオペレータであり、ユーザＵ２５は当該企業Ｅ１中の管理職であって、企画部門に属するユーザＵ２０，Ｕ２１や、設計部門に属するユーザＵ２２，Ｕ２３を管理、監督する立場にあるものとする。
【００４４】
顧客からの要望に対応するために主として企画部門のユーザ（例えば、Ｕ２０）が作成する対応シートや、製品仕様を定義するために主として設計部門のユーザ（例えば、Ｕ２２）が作成する製品仕様書も、文書ファイルとして当該文書管理部２８に蓄積される。ここでは、対応シートを収容した文書ファイルをＦ１とし、製品仕様書を収容した文書ファイルをＦ２とする。
【００４５】
この場合、当該対応シートや製品仕様書は、共有データベース３２の複数のデータ項目に対応した一覧表を主体とする文書となる。
【００４６】
ユーザがいったん作成した文書の編集を行おうとする場合、当該文書管理部２８にアクセスすることになる。ただし、製品仕様書の内容や対応シートの内容は、共有データベース３２内の各テーブルの内容を反映したものであるため、文書管理部２８で管理される文書の内容が変更された場合、その変更は、共有データベース３２内の該当するテーブルに反映される必要がある。
【００４７】
文書の変更を各テーブルに反映させる機能は、後述するクライアントソフト（例えば、ＣＬ２０など）が持つものであってもよく、当該文書管理部２８が持っていてもよい。また、文書の変更を各テーブルに反映させる際、ユーザの操作を要求するものとしてもよく、ユーザの操作を要求せず、自動的に反映させるようにしてもよい。
【００４８】
企画部門が使用する対応シートのデータ項目としては、前記対応シートテーブルＴＢ２のデータ項目をそのまま利用し、製品仕様書のデータ項目としては、前記製品仕様テーブルＴＢ１のデータ項目をそのまま利用することができる。
【００４９】
設計され開発される製品の機種ごとに開発プロジェクトが組織され、プロジェクトごとに企画部門の社員や、設計部門の社員がそのメンバとなるものとすると、プロジェクトごとに（すなわち、製品ごとに）対応シートや製品仕様書のデータ項目は異なるものとなる。
【００５０】
ただし、製品の機種が異なっても同じ範疇に属する製品などは、データ項目の一部または大部分が共通となることも多いものと考えられる。例えば、個人ユーザ向けや、ＳＯＨＯ向けの低価格のプリンタ装置と、業務用の高価格のプリンタ装置などは、データ項目の一部または大部分が共通となる可能性が高い。
【００５１】
そのような場合、前回使用し、文書管理部２８に蓄積されている文書ファイル（例えば、対応シートを収容した文書ファイル）をもとに編集することで、効率的に、今回のプロジェクトのための対応シートを作成することができる。製品仕様書の場合もこれと同様である。
【００５２】
各プロジェクトごとの対応シートにおける要求仕様項目は、そのプロジェクトの要求特性の値として定義される。
【００５３】
ユーザ管理部２９は内部システム１２中の各ユーザＵ２０〜Ｕ２５を識別し、管理する部分である。当該ユーザ管理部２９は、その機能上、データベース（ユーザ管理データベースＤＢ１）を備えることが必要であり、各ユーザＵ２０〜Ｕ２５の前記共有データベース３２中の各データに対するアクセスや前記文書ファイルのアクセスにつき、アクセス権限に応じたアクセス制御を行う。
【００５４】
当該ユーザ管理部２９は、前記共有データベース３２中の各データに対するアクセス制御では前記データベースサーバ３１と連携することが必要であり、前記文書管理部２８中の各文書ファイルに対するアクセス制御では、前記文書管理部２８と連携することが必要である。
【００５５】
本実施形態の構成上、これら構成要素２７〜２９のなかで最も重要なのは、文書管理部２８である。
【００５６】
前記電子掲示板システム３０は、内部システム１２中で前記ユーザＵ２０〜Ｕ２５が相互にメッセージ交換を行うための電子掲示板を提供するシステムである。電子掲示板の機能の実現法には様々なものがあるが、内部ネットワーク１４がＴＣＰ／ＩＰネットワークである場合には、例えば、ＣＧＩを利用したＣＧＩ掲示板が簡便である。ＣＧＩ掲示板の場合、当該電子掲示板システム３０はＣＧＩプログラムを搭載したＷｅｂサーバから構成されることになる。
【００５７】
このＣＧＩプログラムにユーザ認証機能を持たせれば、掲示板に対するアクセス制御を行い、掲示板に書き込まれたあるメッセージを特定のユーザ（例えば、Ｕ２０）だけが読めるようにすることも可能である。このアクセス制御を行う際には、電子掲示板システム３０が前記ユーザ管理部２９と連携し、前記ユーザ管理データベースＤＢ１中に格納されている各ユーザのユーザＩＤやパスワードを利用できるようにしてもよい。
【００５８】
なお、当該電子掲示板システム３０は、異なる部門に属するユーザ間（例えば、Ｕ２０とＵ２２のあいだ）でメッセージ交換を行う場合だけでなく、同じ部門に属するユーザ間（例えば、Ｕ２０とＵ２１のあいだ）でメッセージ交換を行う場合にも利用できることは当然である。同じ部門に属するユーザでも、異なるスケジュールで業務を行っている場合などには、対面で意思を伝達することは難しく、電子掲示板システム３０を活用する必要性は高い。
【００５９】
前記製品システム３３は、当該企業Ｅ１が過去に製造したあるいは現在製造中の各製品の仕様や、当該企業Ｅ１以外の同業他社が過去に製造したあるいは現在製造中の各製品の仕様などを製品仕様データベースＤＢ２に蓄積し管理するシステムである。この製品仕様データベースＤＢ２に格納されている製品仕様の内容は、主として、設計部門に属するユーザＵ２２，ユーザ２３などからの要求に応じて読み出され参照される。
【００６０】
例えば、顧客からの要望として、企業Ｅ１の製品であるプリンタ装置ＰＴ１に印刷出力を指示してから当該プリンタ装置ＰＴ１が印刷を開始するまでの時間（応答時間（図４に示すユーザの待ち時間に相当）が長すぎると指摘されたものとすると、当該製品仕様データベースＤＢ２を用いて同業他社の同程度の価格の１または複数のプリンタ装置などと当該応答時間を比較する。この比較の結果、有意な差が認められない場合や、プリンタ装置ＰＴ１の応答時間（ＴＲ１秒）のほうが短い場合などにはその要望には対応せず、当該プリンタ装置ＰＴ１の応答時間ＴＲ１秒が有意に長い場合には、次回の新製品の設計仕様の項目のうち応答時間に関連する１または複数の項目の値を改善して、その要望に対応するという判断を行うことができる。
【００６１】
また、製品仕様の各項目に関連する知識（すなわち、専門家の経験則や知恵など）も、当該製品仕様データベースＤＢ２など関連付けて蓄積しておくことが望ましい。一例として、ある型番のプロセッサＰ１を搭載したプリンタ装置（前記ＰＴ１もこのようなプリンタ装置であるものとする）では、計算上、応答時間をある値（例えば、前記ＴＲ１秒）以下に短縮することが可能であっても、実際にＴＲ１秒以下にすると動作が不安定になることがあるから注意したほうがよい等の情報が、この知識に該当し得る。
【００６２】
このような知識を知れば、設計部門のユーザ（例えば、Ｕ２２）は、前記プリンタ装置ＰＴ１の後継機として開発予定のプリンタ装置ＰＴ２では、プロセッサを前記Ｐ１よりも高機能なものに変更して応答時間を短縮する等の判断を行うことができる。
【００６３】
前記要望管理システム３４は、前記共有データベース３２の要望テーブルＴＢ４に格納された顧客からの要望を管理し処理するためのシステムである。なお、必要ならば、要望管理システムに要望管理データベースＤＢ３を設けて、当該要望テーブルＴＢ４に相当するテーブルは、この要望管理データベースＤＢ３に格納するようにしてもよい。
【００６４】
要望管理システム３４は主として、オペレータＵ２４が後述するグルーピングを行う際に利用される。図３に示す画面ＭＧ１の一覧は、ビュー表の１つに相当するもので、ＣＳＶファイルをインポートするときに使用するが、当該要望テーブルＴＢ４のスキーマ構造（スキーマのうち属性（データ項目）の組み合わせ）およびインスタンスの一例は、この画面ＭＧ１の一覧と同じであってよい。
【００６５】
表（テーブル）の値（インスタンス）は動的に変動し得るので、テーブルの本質は、このスキーマ構造によって示すことができる。
【００６６】
また、ビュー表とは、問い合わせの結果として表（テーブル）から導出される仮想的な表である。ユーザ（例えば、Ｕ２０）やアプリケーション（ここでは、例えば、クライアントソフトＣＬ２０や文書管理部２８など）はビュー表を通じてデータベース（例えば、共有データベース３２）にアクセスし、データベースの内容を知る（データベースが提供する世界をみる）ことになる。
【００６７】
なお、オペレータＵ２４がグルーピングを実行するときには、図４に示す画面ＭＧ６を利用することになる。
【００６８】
製品仕様書作成システム３５は、製品仕様書の作成を支援するシステムで、作成または編集される製品仕様書の内容に応じて前記共有データベース３２の製品仕様テーブルＴＢ１に格納された製品仕様書の内容を管理し処理する。当該製品仕様書作成システム３５を利用するのは、主として、設計部門のユーザである。製品仕様テーブルＴＢ１は製品仕様書ごとに存在し、例えば、図９に示す画面ＭＧ７に対応したスキーマ構造およびインスタンスを持つ要素テーブルの集合体として構成することができる。
【００６９】
この要素テーブルの集合体は、図９の木構造（ツリー構造）に応じて、例えば、葉より１つ上位の節に相当する下位節要素テーブルと、この節より１つ上位の節（中位節）に相当する中位節要素テーブルと、最上位の節（すなわち、根）に相当する単一の上位節要素テーブルとから構成される。そして各要素テーブルは例えば次のように構成することができる。
【００７０】
すなわち、前記下位節要素テーブルには葉より１つ上位の節（下位節）の名称（例えば、複写速度、ウオーミングアップタイムなど）を付与し、そのスキーマは、次のスキーマ構造（２）を持つものであってよい。
【００７１】
（葉仕様項目ＩＤ，葉仕様項目，評価，ステータス，担当者，変更日時，期限）      …（２）
ただしこの葉仕様項目には、図９の木の葉の名称（例えば、連続複写時、ＡＤＤ排出速度など）が対応し、葉仕様項目ＩＤは、共有データベース３２内でその葉仕様項目を一意に識別することのできる識別情報である。この下位節要素テーブルは下位節の数だけ存在する。
【００７２】
また、前記中位節要素テーブルには、前記中位節の名称（例えば、基本仕様など）を付与し、そのスキーマは次のスキーマ構造（３）を持つものであってよい
（下位節仕様項目ＩＤ，下位節仕様項目）      …（３）
このような中位節要素テーブルは中位節の数だけ存在する。
【００７３】
さらに、前記上位節要素テーブルには、根の名称（図９の例では、製品仕様書）を付与し、そのスキーマは次のスキーマ構造（４）を持つものであってよい
（中位節仕様項目ＩＤ，中位節仕様項目）    …（４）
根の数は１つであるから、当該上位節要素テーブルの数も１つである。
【００７４】
このように要素テーブルの集合体を構成しておけば、図９に示すように木構造のすべてを画面表示させることもでき、木構造の一部だけを画面表示させること等も、例えば、ＳＱＬの問い合わせ（ＳＥＬＥＣＴ文）の内容を変更するだけで、容易に実現可能である。ただし図９に示すような画面を表示するには、問い合わせの結果を、一覧（ビュー表）としてでなく、木構造で表現するユーザインタフェースを用意しておく必要がある。
【００７５】
なお、図９では、仕様項目間の包含、被包含の関係などをわかりやすくするために木構造を用いているが、必要に応じて、対応シートと同様な一覧の形式で、製品仕様書の内容を表示してもよいことは当然である。
【００７６】
前記対応シート作成システム３３は、前記共有データベース３２の対応シートテーブルＴＢ２に格納された対応シートの内容を管理し処理するためのシステムである。したがって当該対応シート作成システム３５を利用するのは、主として、企画部門のユーザである。対応シートテーブルＴＢ２は、例えば、図６に示す画面ＭＧ３の一覧に対応したスキーマ構造およびインスタンスを持つ単一の関係表として構成することができる。
【００７７】
すなわち、対応シートテーブルＴＢ２のスキーマ構造（７）は、次のようになる。
【００７８】
（要求特性，要求カテゴリ，要求，対応，評価，担当者，変更日時，ステータス）        …（７）
なお、管理の都合上、当該対応シートテーブルＴＢ２には、画面ＭＧ３に表示したデータ項目のほか、個々の要求仕様項目（要求特性の値（例えば、ユーザの待ち時間など））を共有データベース３０内で一意に識別するための識別情報である要求仕様項目ＩＤをデータ項目として用意することが望ましい。また、図６上でアイコンが表示されている列では列名（データ項目）が空白になっているが、対応シートテーブルＴＢ２としては、このデータ項目にも、例えば、意思疎通管理列などの名称を付与するとよい。意思疎通管理列の詳細については後述するが、意思疎通管理列は、対応シートや製品仕様書などを閲覧するユーザが、双方向で、または一方向で、意思を伝えるための値を持つデータ項目である。
【００７９】
内部システム１１中では通常、同時並列的に複数の開発プロジェクトが作られ、活動するため、共有データベース３２内にも複数組の対応シートテーブル（例えば、ＴＢ２）と製品仕様テーブル（例えば、ＴＢ１）が同時に格納されることになる。したがって、内部システム１２やデータベースサーバ３１は、ユーザからの問い合わせにこたえる場合などに、注目している対応シートテーブル（または製品仕様テーブル）がどの製品仕様テーブル（または対応シートテーブル）と同じ組に属するか（対応しているか）を識別する必要がある。
【００８０】
この識別は、共有データベース３２内に格納された仕様書関連テーブルＴＢ５を用いて行う。この仕様書関連テーブルＴＢ５のスキーマは、例えば、次のスキーマ構造（６）を持つことで、対応シートテーブルと製品仕様テーブルの対応関係を管理することができる。
【００８１】
（製品仕様書ＩＤ，対応シートＩＤ）    …（６）
このうち製品仕様書ＩＤは、共有データベース３２内で製品仕様テーブルを一意に識別するための識別情報である。同様に、対応シートＩＤは、共有データベース３２内で、対応シートテーブルを一意に識別するための識別情報である。
【００８２】
また、当該対応シートテーブルＴＢ２の各仕様項目と、前記製品仕様テーブルＴＢ１の各仕様項目とを対応付けるため、前記製品仕様書の各仕様項目（例えば、葉仕様項目）と、対応シートの各仕様項目（要求仕様項目、すなわち要求特性）との対応関係を格納した仕様項目関連テーブルＴＢ３が用意されている。なお、前記製品仕様書の各仕様項目と、対応シートの各仕様項目との対応関係は、製品の種類に依存して相違し得る（例えば、プリンタ装置とファクシミリ装置などでは相違し得る）ため、開発プロジェクトごとに相違する可能性があるが、ここでは、簡単のために、そのような相違はないものとする。
【００８３】
このような対応付けを行うため、当該仕様項目関連テーブルＴＢ３のスキーマは、例えば、次のスキーマ構造（５）を持つことになる。
【００８４】
（意思疎通管理列，要求仕様項目ＩＤ，葉仕様項目ＩＤ）    …（５）
このうち要求仕様項目ＩＤと葉仕様項目ＩＤは、外部キーであり、この部分の値で、前記製品仕様書の各仕様項目（例えば、葉仕様項目）と、対応シートの各仕様項目（要求仕様項目）との対応付けを行うことができる。また、意思疎通管理列の値は、図６の一覧の左端に表示したアイコンの表示、非表示などの基礎となる情報である。このように関連テーブルＴＢ２に意思疎通管理列を設ける場合には、実表としての前記対応シートテーブルＴＢ２のデータ項目からは意思疎通管理列を省略し、ＳＥＬＥＣＴ文による検索の結果を用いて導出される表（ビュー表）として、図６に示す一覧を生成することも望ましい。
【００８５】
当該仕様項目関連テーブルＴＢ３は、後述する仕様項目テンプレートの中核をなす構成要素である。
【００８６】
なお、前記電子掲示板システム３０やデータベースサーバ３１なども含め、サーバ機能に相当する構成要素２６〜３５は、図１に示したように必ずしも機能ごとに別なサーバマシンに配置する必要はなく、１または少数のサーバマシンに集約できることは当然である。
【００８７】
企業Ｅ１内の社員（ユーザ）は、それぞれ通信端末２０〜２５を用いて、通信システム１０が提供するサービスを利用する。
【００８８】
通信端末２０〜２５は専用のハードウエアを持つ端末であってもかまわないが、ここでは、通常のパーソナルコンピュータであるものとする。また、１つの通信端末を複数のユーザで共用することも可能であるが、ここでは、１ユーザが１端末を使用するものとする。
【００８９】
すなわち、通信端末２０はユーザＵ２０によって使用され、通信端末２１はユーザＵ２１によって使用され、通信端末２２はユーザＵ２２によって使用され、通信端末２３はユーザＵ２３によって使用され、通信端末２４はユーザＵ２４によって使用され、通信端末２５はユーザＵ２５によって使用される。
【００９０】
また、ユーザＵ２０とＵ２１は企画部門の社員であり、ユーザＵ２２とＵ２３は設計部門の社員であり、ユーザＵ２４は上述したオペレータであり、ユーザＵ２５は管理者である。
【００９１】
なお、オペレータとは、グルーピングの作業を担当する者のことである。
【００９２】
グルーピングとは、外部システム１１から供給され、前記要望に関するデータ項目に統一性のない前記ＣＳＶファイルの内容を、要求仕様書の仕様項目（要求仕様項目）である要求特性の値のいずれかに分類する作業である。グルーピングは、個々の顧客からの要望を整理し、まとめる作業であるから、本来は、企画部門の仕事である。したがって、企画部門に属するユーザＵ２０やＵ２１がグルーピングを行ってもよいが、本実施形態では、専任のオペレータであるユーザＵ２４がこの作業を担当している。
【００９３】
ただしオペレータＵ２４は、ユーザＵ２０やＵ２１の指示を受け、指示通りに作業を進めるため、実質的には、ユーザＵ２０，Ｕ２１自身が作業を行っているのに等しいとみることができる。
【００９４】
グルーピングの際の分類の方法は、一度、決定すればその後のグルーピングでは同じ方法を繰り返すだけでよいため、作業を繰り返せば、通常、グルーピングのための作業負担は軽減される。
【００９５】
通信端末２０〜２５の内部構成例を図２に示す。通信端末２０〜２５の内部構成は実質的に同じであるが、以下では、図２には主として、通信端末２０の内部構成例を示したものとして説明を進める。
【００９６】
（Ａ−１−１）通信端末の内部構成例
図２において、当該通信端末２０は、通信部４０と、制御部４１と、表示部４２と、操作部４３と、記憶部４４とを備えている。
【００９７】
このうち通信部４０は、内部ネットワーク１４を経由して内部システム１２内の各構成要素と通信するために機能する部分である。通信部４０による通信の相手には、内部システム１２内のあらゆる構成要素を選ぶことができるが、当該通信端末２０の場合、企画部門のユーザＵ２０が使用するため、少なくとも、管理システム２６、電子掲示板システム３０、データベースサーバ３１、対応シート作成システム３３と通信する必要がある。また、必要に応じて、要望管理システム３４と通信することも望ましい。
【００９８】
操作部４３は、ユーザＵ２０が操作して通信端末２０に指示を伝える部分で、例えば、マウスなどのポインティングデバイスやキーボードなどを有する。
【００９９】
制御部４１は、ハードウエア的には当該通信端末２０のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）やクライアントソフトＣＬ２０などの各種プログラムに相当する部分である。
【０１００】
クライアントソフトＣＬ２０は、ユーザＵ２０が通信端末２０を用いて、内部システム１２が提供する各種グループウエアサービスを利用するためのプログラムである。汎用的なクライアントソフトウエアであるＷｅｂブラウザなどをクライアントソフトＣＬ２０として利用することも可能であるが、本実施形態では、専用のプログラムとしてクライアントソフトＣＬ２０を構成するものとする。
【０１０１】
汎用的なＷｅｂブラウザなどを利用すればシステムの導入は容易になるが、Ｗｅｂサーバ側のＣＧＩプログラムなどに多くの機能を配分することになるため、Ｗｅｂサーバ側の負荷が大きくなる。また、当然、Ｗｅｂサーバを用意する必要がある。これに対し、専用のプログラムをクライアントソフトＣＬ２０とすれば、必要に応じて、クライアント側にも多くの機能を配分することができ、必ずしもＷｅｂサーバを用意する必要はない。
【０１０２】
例えば当該クライアントソフトＣＬ２０の機能により、ユーザＵ２０に宛てたメッセージが電子掲示板システム３０に書き込まれていることを、ユーザＵ２０に伝えることができるように構成すること等も望ましい。
【０１０３】
当該クライアントソフトＣＬ２０は、前記通信部４０が通信する内部システム１２内の上述した各構成要素のクライアントとして機能することになる。
【０１０４】
表示部４２は、クライアントソフトＣＬ２０などの機能に応じて画面表示を行うディスプレイ装置に対応する部分である。通信端末２０を操作するユーザＵ２０は企画部門に属するから、当該表示部４２には、前記クライアントソフトＣＬ２０の機能により、少なくとも対応シート（要求仕様書）を表示し、ユーザＵ２０がその閲覧や編集を行うことを可能にする。
【０１０５】
対応シート（要求仕様書）は、顧客の要望に対応した製品を提供するために企画部門のユーザによって作成される文書である。顧客の要望に対応した製品を提供するには、対応シートを用いて顧客の要望を正確に設計部門に伝え、製品仕様書（設計仕様書）に反映させる必要がある。対応シートは、１つの開発プロジェクトにおいて、複数作成するようにしてもよいが、通常は、１つ作成される。また、対応シートと要求仕様書の相違は、要求仕様書がワープロソフトを利用して作成される自由な形式の文書であるのに対し、対応シートは、当該要求仕様書の内容を表形式にまとめたものである点にある。
【０１０６】
したがって、ユーザ（例えば、Ｕ２０）からみた場合、対応シートと要求仕様書は、実質的に同じ内容を持つ文書であるが、内部システム１２内の共有データベース３２などを活用して、前記製品仕様書とのあいだで相互運用性を確保するには、対応シートを利用する必要がある。
【０１０７】
ワープロソフトの機能などにも依存するが、要求仕様書の内容は、容易に対応シートに変換することが可能である。
【０１０８】
当該製品仕様書は、個々の製品の具体的な仕様について定義するために、設計部門のユーザ（例えば、Ｕ２２）によって作成される文書である。
【０１０９】
内部システム１２が提供するグループウエアサービスを利用する際、通信端末２０の表示部４２に表示され、企画部門に属するユーザＵ２０が目視するのは、例えば、図５〜図８に示す画面ＭＧ２〜ＭＧ５である。
【０１１０】
図５に示す画面ＭＧ２は、内部システム１２内で作成する各種の文書につき、文書属性を指示するための画面で、図示の状態では、プロジェクト名がＡＡＡという開発プロジェクトの対応シートに関する属性を指示している。
【０１１１】
文書の属性には、図５に示したように、文書タイプ、プロジェクト、ＩＤ、文書名、所在、担当者、ステータス、作成日時、変更日時、期限、関連文書などが含まれ得る。
【０１１２】
文書タイプは、その文書のタイプを記述するためのフィールドである。文書タイプの例としては、図示の対応シートのほか、製品仕様書などがある。文書タイプが製品仕様書の画面ＭＧ２を見るのは、主として、設計部門のユーザである。
【０１１３】
プロジェクトは、当該文書を使用する開発プロジェクトの名称を記述するフィールドで、ＩＤは当該文書を内部システム１２中で一意に識別するための識別情報を記述するフィールドで、文書名は当該文書に付与した名称を記述するフィールドで、所在は当該文書が格納されているディレクトリなどを記述するフィールドで、担当者は当該文書の担当者を記述するためのフィールドで、ステータスは当該文書の状態を記述するフィールドで、作成日時は当該文書の作成日時を記述するためのフィールドで、変更日時は当該文書が変更された最も近い過去の日時を記述するためのフィールドで、期限は当該文書の有効期限を記述するためのフィールドである。
【０１１４】
前記ステータスには、図示した編集中を示すＡＣＴＩＶＥのほか、新規に作成された状態を示すＮＥＷ、公開中または完了状態を示すＣＯＭＰＬＥＴＥＤ、保留状態を示すＳＵＳＰＥＮＤＥＤ、削除対象であることを示すＤＥＬＥＴＥＤなどがあってよい。前記テーブルＴＢ１〜ＴＢ４やこれらから生成されるビュー表は、同時に複数のユーザから参照され得るため、例えば、このＡＣＴＩＶＥをビュー表（このビュー表は、製品仕様書や、対応シートなどに相当し得る）に表示すれば、参照中のユーザはそのビュー表の内容が変更されている最中であることを認識することができる。
【０１１５】
また、関連文書タブには、当該文書に対して関連付けたい文書を記述するフィールドが用意されている。
【０１１６】
当該文書が対応シートである場合、通常、関連付けられるのは製品仕様書である。１つの対応シートに複数の製品仕様書を関連付けられるようにしてもよいが、ここでは、１つの製品仕様書だけを関連付けるものとする。関連付けが行われると、前記共有データベース３２内の上述した仕様書関連テーブルＴＢ５の同じ行に、当該対応シートに相当する対応シートテーブルの対応シートＩＤと、製品仕様書に相当する前記製品仕様テーブルの製品仕様書ＩＤが格納される。
【０１１７】
なお、このような関連付けは、対応シート側から企画部門のユーザ（ここでは、Ｕ２０）が行うだけでなく、製品仕様書側から設計部門のユーザ（例えば、Ｕ２２）が行うことも可能である。また、このような関連付けを実行するためには、前提として、関連付けられるべき対応シートと製品仕様書がすでに作成され文書管理部２８や共有データベース３２内で管理されているか、あるいは、作成されていない場合でも、少なくともそのＩＤ（対応シートＩＤまたは製品仕様書ＩＤ）は決まっている必要がある。
【０１１８】
この関連付けが行われることによってはじめて、対応シートの記述内容と製品仕様書の記述内容が内部システム１２によって対応付けられ、一方の記述内容の変更が他方の記述内容の変更をもたらし、企画部門のユーザＵ２０と設計部門のユーザが意思を疎通することが可能となる。
【０１１９】
例えば、製品仕様書のなかのある製品仕様項目ＤＡ１の内容が変更されると、その製品仕様書に関連付けられた対応シートのなかで、当該製品仕様項目ＤＡ１に対応する要求仕様項目ＲＡ１につき、後述する意思疎通管理列の値（例えば、表示されるアイコンの種類や表示、非表示など）が変更される。これにより、企画部門のユーザ（Ｕ２０など）は、設計部門のユーザと対面の打ち合わせなどを行わなくても、動的な意思疎通を行うことができる。
【０１２０】
具体的な変更の詳細を企画部門のユーザが知るには、例えば、企画部門のユーザが製品仕様書の閲覧を行ったり、電子掲示板システム３０や電子メールシステム（図示せず）などのメッセージ交換手段を利用してもよい。電子掲示板システム３０は、ユーザ認証の機能を装備することにより、前記ＡＡＡプロジェクトに属する特定のユーザだけしか掲示板にアクセスできないようにすることができる。
【０１２１】
なお、前記とは反対に、例えば、要求仕様書のなかのある製品仕様項目ＲＡ２の内容に変更があった場合には、その要求仕様書に関連付けられている製品仕様書のなかで、当該要求仕様項目ＲＡ２に対応する製品仕様項目ＤＡ２につき、製品仕様書側に設けられた前記意思疎通管理列に相当する機能（例えば、図１０に示す画面ＭＧ７上のアイコンなど）が、当該変更を設計部門のユーザに伝える。
【０１２２】
変更の事実を知った設計部門のユーザが変更の詳細を知るためには、前記と同様に、設計部門のユーザが対応シートの内容を閲覧したり、電子掲示板システム３０や電子メールシステムを利用してよい。
【０１２３】
なお、意思疎通の種類によっては、必ずしもその詳細を知る必要のないものも少なくない。例えば、ある要求仕様項目の重要度（図７参照）が上方修正（重要さの度合いが増す方向への修正）された場合、その旨を製品仕様書側の意思疎通管理列に表示する構成は望ましいが、そのような構成でそのような表示が行われたケースでは、表示されるアイコンの種類などによって重要度が上方修正されたことさえ認識できれば、多くの場合、設計部門のユーザにとって十分であると考えられる。
【０１２４】
また、意思疎通管理列や意思疎通管理列に相当する機能を利用した意思疎通は、電子掲示板システム３０や電子メールシステムを利用するメッセージ交換に比べ、電子掲示板にアクセスしたり、メーラを起動してメールサーバから着信した電子メールを取り出す操作などが不要であり、業務の遂行上、必ず閲覧する必要のある画面（例えば、図６や図１０の画面）上のアイコンを確認することによって簡単に意思疎通を行うことができる利点がある。
【０１２５】
図５に示した各フィールドは必ずしもすべてが必須というわけではなく、一部のフィールドを他のフィールドと置き換えたり、一部のフィールドを省略することも可能である。この点は、図５以外に図示した画面上の表示部品（押しボタンや、スクロールバーなど）に関しても同様である。
【０１２６】
ただし図５において、文書タイプと関連文書タブ内のフィールド（必ずしもタブ内にこのフィールドを設ける必要はないが）は必須であり、多くの場合、ステータスも欠くことができない。
【０１２７】
図５では、ＡＡＡプロジェクトで使用する対応シートにＡＡＡ対応シートという名称を付与している。
【０１２８】
図６の画面ＭＧ３は、当該ＡＡＡ対応シートの内容の表示例である。
【０１２９】
図６から明らかなように、対応シートは、関係表と同様な形式を備え、データ項目として、要求特性、要求カテゴリ、要求、対応、評価、担当者、変更日時、ステータスなどを備えている。
【０１３０】
また、図６の左端には、データ項目の名称は示していないが、スケジュール管理や設計部門のユーザと企画部門のユーザの意思疎通に利用できる列として前記意思疎通管理列が設けてある。
【０１３１】
これらのデータ項目のうち、担当者、変更日時、ステータスは、図５に示した同名の各フィールドに対応したものであるが、図５の各項目は文書単位の情報を示すのに対し、図６では、仕様項目単位の情報を示している。通常、１つの対応シートには複数の要求仕様項目が含まれているので、図６では、仕様項目単位で独立に情報を表示することになる。
【０１３２】
図６のデータ項目のうち重要なものは、前記意思疎通管理列と、要求特性と、要求と、対応である。
【０１３３】
要求特性とは上述しように、値として前記要求仕様項目を持つデータ項目である。図示の例では、例えば、「ユーザの待ち…」（ユーザの待ち時間）、「テストプリント…」などがその値である。図示の状態では必ずしもすべての値について全部を表示してはいないが、マウスカーソルなどを用いた所定の操作により、値の全部を表示させることも可能である。
【０１３４】
顧客からの生の要望は、上述したグルーピングによって、当該要求特性のいずれかの値に分類される。
【０１３５】
要求カテゴリは、各要求特性の値（要求仕様項目）の属する大きな分類を値として持つデータ項目であり、要求は、グルーピング前の顧客からの生の要望を値として持つデータ項目であり、対応は、顧客から寄せられた各要望に対し企画部門のユーザが提案した対応策を値として持つデータ項目である。
【０１３６】
なお、評価は、要求が提示した課題の達成レベルを、例えば、５段階の数値で記述するためのデータ項目である。したがって、評価に有効な値が格納されるのは、対応シートと製品仕様書が関連付けられたあとである。
【０１３７】
図６に示す画面ＭＧ３上で、ユーザＵ２０がマウスカーソルなどを用いて特定の行を選択すると、その行内の対応の値や、要求の値などを変更するための画面が、前記表示部４２に表示される。図６の一覧を関係表とみると、要求特性が主キーであることは明白であるから、この行の選択は、要求特性の値を選択することを意味する。
【０１３８】
このとき表示される画面は、一例として、図７に示す画面ＭＧ４である。当該画面ＭＧ４は、図６の一覧の上から４つ目の行、すなわち、要求特性の値（要求仕様項目）として「トナー交換作業」を選択したときに表示される画面である。
【０１３９】
なお、当該画面ＭＧ４上には、上述した要求の重要度が一例として、スピンコントロールにより指定できるようになっている。
【０１４０】
図７上でコメントタブを選択したときに表示される要望コメントを記述するフィールドでは、顧客から寄せられた前記要望をそのまま記述してもよいが、要約したものを記述することが望ましい。顧客からの要望がない場合には、企画部門のユーザが作成した要望を記述してもよい。
【０１４１】
また、対応コメントを記述するフィールドでは、その要望コメントが提示する問題点（課題）に対する対応策を企画部門のユーザが記述する。
【０１４２】
また、図７上で要求仕様タブを選択したときには、画面は、図８に示す画面ＭＧ５に変化する。要求仕様タブは、対応シートの要求特性の値の削除や追加を行う場合に使用するタブである。必ずしもタブの形式で用意する必要はないが、この機能自体は本実施形態にとって重要な機能の１つである。
【０１４３】
要求特性の値を追加するには、所定の仕様項目テンプレートのなかから、新たな値（新たな要求仕様項目）を選択して「仕様追加」ボタンを操作する。
【０１４４】
仕様項目テンプレートは、対応シートで使用する要求仕様項目や、製品仕様書で使用する製品仕様項目として標準的な仕様項目の集合体であるが、その中核には、前記仕様項目関連テーブルＴＢ３が存在する。
【０１４５】
一般的に、既存の要求仕様項目は、製品仕様項目と１対１の対応関係を持たず、１対多の対応関係を持つことが多い。一例として、図６に示す前記ユーザの待ち（時間）という１つの要求仕様項目には、図９に示す連続複写時（の複写速度）、ＡＤＤ排出速度、原稿読み込みスピード、ファーストコピー（の複写速度）などが対応し得る。そして、要求仕様項目と製品仕様項目の関係が、１対１の対応関係にある場合だけでなく、１対多の対応関係（場合によっては、多対１の対応関係）にある場合でも、上述した意思疎通管理列や意思疎通管理列に相当する機能を用いた画面上に所定のアイコンを表示（あるいは、非表示）するために、システム内部では対応関係を管理している必要がある。
【０１４６】
このような対応関係の管理には様々な方法を用いることが可能であるが、本実施形態では、基本的に、当該仕様項目関連テーブルＴＢ３（すなわち、仕様項目テンプレート）を用いて管理する。
【０１４７】
仕様項目テンプレートの使用方法には、大きく分けて２つの方法がある。その１つは、製品仕様書の全仕様項目と対応シートの全仕様項目を、例外を許容せず、この仕様項目テンプレートから選ぶ方法（完全テンプレート法）であり、もう１つは、製品仕様書の仕様項目と対応シートの仕様項目を基本的には当該仕様項目テンプレートから選ぶが、例外的に仕様項目テンプレートに存在しない仕様項目を選ぶことを許容する方法（例外許容法）である。
【０１４８】
例外許容法はさらに、製品仕様書における仕様項目の選定にのみ例外を許容する方法（製品仕様例外許容法）と、対応シートにおける仕様項目の選定にのみ例外を許容する方法（要求仕様例外許容法）と、双方に例外を許容する方法（双方例外許容法）に細分することができる。
【０１４９】
完全テンプレート法には、ユーザが要求仕様項目や製品仕様項目を設定する際の自由度が制限される点で不利であるが、要求仕様項目と製品仕様項目の対応関係がユーザからみても、システムの処理上も完全に明確となる利点がある。
【０１５０】
一方の例外許容法では、要求仕様項目と製品仕様項目の対応関係が完全に明確とはならないが、ユーザが要求仕様項目や製品仕様項目を設定する際の自由度が高いという利点がある。
【０１５１】
例外許容法において、仕様項目テンプレートに存在しない仕様項目（例外仕様項目）を選んだ方（例えば、対応シート側）のユーザは、他方（例えば、製品仕様書側）のユーザに対し、その例外仕様項目（に対応する仕様項目）を他方の仕様項目として採用するように要求（テンプレート化要求）するようにしてもよい。この場合、製品仕様書側のユーザがこのテンプレート化要求を受け入れて所定の操作を行えば、前記仕様項目関連テーブルＴＢ３に新たな行が１行追加され、例外仕様項目は仕様項目テンプレートのなかの１つの仕様項目として登録されることになり、例外仕様項目ではなくなる。テンプレート化要求を出すために、例えば、図８に示す画面ＭＧ５の「仕様化依頼」ボタンを使用するようにしてもよい。
【０１５２】
このようなテンプレート化要求を行わない場合や、行っても他方が受け入れを拒否した場合など（電子掲示板システム３０などを利用して必要性を説明しても拒否された場合なども含む）には、仕様項目レベルの対応付けは行えなくなる。その場合、前記対応シート側のユーザは当該例外仕様項目を要求仕様項目として使用することを諦めてもよいが、諦めずに使用してもよい。前記例外許容法の場合には、諦めずに使用することが可能である。
【０１５３】
諦めずに使用する場合、当該例外仕様項目に関するかぎり、仕様項目レベルの対応づけは行えないが、仕様書レベルの関連付けは、前記スキーマ構造（６）の仕様書関連テーブルＴＢ５により、すでに対応シートと製品仕様書のあいだで行われているため、例えば、対応シート側で当該例外仕様項目に関する情報（例えば、重要度）が変更されたことを製品仕様書を表示する画面に反映させること等は可能である。
【０１５４】
現実に、完全テンプレート法を用いるには、仕様項目テンプレートに用意する仕様項目の種類が十分に多いことが必要になるものと考えられる。そのような仕様項目テンプレートが用意できない場合には、例外許容法を用いるほうが現実的であると考えられる。あるいは、内部システム１２の運用開始当初は、例外許容法を用い、運用により仕様項目テンプレート中の仕様項目が十分に豊富化されたあとで、完全テンプレート法へ移行するようにしてもよい。
【０１５５】
例外許容法の場合でも、製品仕様書の仕様項目の多くは、この仕様項目テンプレートから選んだ仕様項目であるため、要求仕様書の仕様項目を当該仕様項目テンプレートから選択すればするほど、要求仕様書は製品仕様書と仕様項目が一致する割合が高まり、仕様項目間に１対１の対応関係を見つけだしやすくなる。これによって、設計部門のユーザが要求仕様書を参照しやすくなり、顧客の要望なども製品の設計に反映させやすくなることが期待できる。
【０１５６】
ただし、製品仕様書の仕様項目の多くを仕様項目テンプレートから選べるようにするためには、仕様項目テンプレート中の各仕様項目は、製品仕様書向けの仕様項目にする必要がある。製品仕様書向けの仕様項目は、製品（プリンタ装置など）に関する技術的な専門家である設計部門のユーザにとっては分かりやすくても、通常、技術的な専門家ではない企画部門のユーザＵ２０やオペレータＵ２４にとっては必ずしも分かりやすくないため、実質的に同じ内容の仕様項目でも画面上に表示される表現を、製品仕様書上と対応シート上で相違させることも可能である。例えば、製品仕様書上では技術的な専門家である設計部門のユーザに分かりやすい専門用語で表現した仕様項目を表示し、対応シート上では、技術的な専門家ではない企画部門のユーザに分かりやすい、専門用語を用いずに表現した仕様項目（別名による仕様項目）を表示するようにすることも可能である。
【０１５７】
これは、当然、前記完全テンプレート法にも、例外許容法にも適用可能であるが、完全テンプレート法に適用した場合に、いっそう有効であると考えられる。例えば、仕様項目設定の自由度が制限される不利を、仕様項目の表現を変更することによって補える可能性があるからである。この別名による仕様項目の実現法には様々なものが考えられるが、例えば、前記仕様項目関連テーブルＴＢ３で相互に関連付けられている葉仕様項目と要求仕様項目（要求特性）の値として、それぞれ異なる項目名を、前記対応シートテーブルＴＢ２と、前記製品仕様テーブルＴＢ１の要素テーブルの１つで前記スキーマ構造（２）を有する下位節要素テーブルに格納することによって、容易に実現できる。
【０１５８】
なお、通信端末を使用するのがユーザＵ２０などの企画部門のユーザではなく、例えば、設計部門のユーザＵ２２，Ｕ２３である場合には、（通信端末２２などの）表示部４２には、例えば、上述した木構造を有する図９の画面ＭＧ７や、図１０に示す画面ＭＧ８が表示されることになる。
【０１５９】
また、通信端末を使用するのが、オペレータＵ２４の場合には、（通信端末２４の）表示部４２には、上述した図３の画面ＭＧ１や図４に示す画面ＭＧ６などが表示されることになる。
【０１６０】
さらに、通信端末を使用するのが管理者Ｕ２５の場合、管理者にはオールマイティなアクセス権限を与えるのが普通なので、（通信端末２５の）表示部４２には、前記画面ＭＧ１〜ＭＧ８のすべてが表示され得る。加えて、効率的な管理を行うための管理者専用の画面を用意しておくことも望ましい。
【０１６１】
なお、各ユーザＵ２２〜Ｕ２５が自身の通信端末２２〜２５に搭載して使用するクライアントソフトＣＬ２２〜ＣＬ２５の機能は、基本的に、前記企画部門のユーザＵ２０（Ｕ２１も同様）のクライアントソフトＣＬ２０と同じであってよい。
【０１６２】
図２に示す記憶部４４は、ＲＡＭ（ランダムアクセスメモリ）や、ハードディスクなどによって構成される記憶資源である。前記クライアントソフトＣＬ２０などのプログラムファイルも、この記憶部４４に記憶されている。また、前記表示部４２に一覧を含む各種画面（例えば、ＭＧ３など）が表示されているときには、その一覧に対応するビュー表が、この記憶部４４に格納された状態であり得る。
【０１６３】
通信端末２０〜２５以外の内部システム１２の構成要素２６〜３１，３３〜３６も基本的に図２に示すものと同じ内部構成を備えるものであってよい。ただしこれらはサーバであるから、表示部４２や操作部４３は主として、保守管理などのために使用することになる。遠隔保守などを実行する場合などには、表示部４２や操作部４３は省略可能である。
【０１６４】
また、これらはサーバであるから記憶部４４にはクライアントソフト（例えば、ＣＬ２０）ではなく、各サーバソフト（例えば、電子掲示板システム３０の場合なら、電子掲示板用のＣＧＩプログラムなどを主体とするサーバ用のプログラム）のためのプログラムファイルなどが格納されることになる。
【０１６５】
以下、上記のような構成を有する本実施形態の動作について説明する。
【０１６６】
（Ａ−２）実施形態の動作
ある開発プロジェクト（前記ＡＡＡプロジェクトとする）が組織され、そのＡＡＡプロジェクトのメンバとして、企画部門からはユーザＵ２０とＵ２１が選ばれ、設計部門からはユーザＵ２２，Ｕ２３が選ばれ、管理者としてユーザＵ２５が選ばれ、オペレータＵ２４も決まったものとする。
【０１６７】
管理者Ｕ２５は当該ＡＡＡプロジェクトを管理するプロジェクトマネージャのような存在であってもよく、組織上、当該ＡＡＡプロジェクトとはかかわりないが、内部システム１２を管理するシステム管理者などであってもよい。
【０１６８】
オペレータＵ２４は必ずしも個々の開発プロジェクト（ここでは、ＡＡＡプロジェクト）とは関係なく、前記グルーピングの作業を実行するものであってもよい。
【０１６９】
ＡＡＡプロジェクト組織後、最初に１回程度、メンバが対面して打ち合わせを行い、ＡＡＡプロジェクトの基本的な方針などを確認してもよいが、このような確認も、電子掲示板システム３０などを利用して行ってもよい。いずれにしても、基本的には企画部門のユーザ（例えば、Ｕ２０）がまとめる要求仕様書が、製品開発の具体的な指針となるため、前記対応シートＦ１が作成される。このとき、オペレータＵ２４が行ったグルーピングの結果が利用される。
【０１７０】
各ユーザＵ２０〜Ｕ２５が、前記グルーピング、対応シート、製品仕様書に関連する作業を始めようとするとき、それぞれの通信端末２０〜２５の表示部４２が提供する画面上で最初に目視するのは、アプリケーションの起動や切り替えを行うユーティリティであるランチャが提供する図１１に示す画面ＭＧ０である。画面ＭＧ０上の左端部に配置されているメニューをマウスカーソルなどで選択することにより、各ユーザＵ２０〜Ｕ２５は、中央から右端にかけて広がる大きなウインドウに、当該選択に対応した表示を行わせることができる。一例として、ユーザＵ２２などがメニュー上で製品仕様を選択したときには、画面ＭＧ０は、図９に示す画面ＭＧ７に変わる。
【０１７１】
また、対応シートの作成を行うとき、ユーザＵ２０は、図１１の画面ＭＧ０のメニュー上で対応シートを選択することになる。
【０１７２】
すでに製品仕様書が設計部門のユーザ（例えば、Ｕ２２）によって作成されているか、あるいは、個々の製品仕様項目の内容は確定的なものではないとしても、少なくとも形式的には、製品仕様書の体裁を有する文書Ｆ２が文書管理部２８に格納されているものとする。例えば、当該製品仕様書の製品仕様書ＩＤが決定されていることをもって、製品仕様書Ｆ２が文書管理部２８に格納されているとみなすように構成してもよい。
【０１７３】
文書管理部２８に製品仕様書Ｆ２が格納されていれば、ユーザＵ２０は通信端末２０の表示部４２に表示された図５に示した画面ＭＧ２を介して、対応シートＦ１と製品仕様書Ｆ２との関連付けを行うことができる。
【０１７４】
このとき、前記スキーマ構造（６）を有する仕様書関連テーブルＴＢ５の１つの行の値として、当該対応シートＦ１の対応シートＩＤと当該製品仕様書Ｆ２の製品仕様書ＩＤが格納され、両文書Ｆ１、Ｆ２の関連付けが行われる。
【０１７５】
これと反対に、製品仕様書Ｆ２側から対応シートＦ１側へ関連付けを行ってもよい点はすでに述べた通りである。まず最初に対応シートＦ１の内容が決まり、この内容に応じて製品仕様書Ｆ２の内容が決まるのが通常の作業手順であるが、例えば、新製品の開発スケジュールが予め決まっていてそのスケジュールに合わせて製品仕様書Ｆ２が作成される場合などには、対応シートＦ１よりも早く製品仕様書Ｆ２が文書管理部２８に格納されることが起こり得る。
【０１７６】
すでに、前記スキーマ構造（５）を有する仕様項目関連テーブルＴＢ３には、要求仕様項目ＩＤと葉仕様項目ＩＤが関連付けられているから、対応シートＦ１と製品仕様書Ｆ２が関連付けられれば、この仕様項目関連テーブルＴＢ３を介して、個々の仕様項目のレベルでも、自動的に関連付けが行われる。
【０１７７】
このとき各ユーザは、特に仕様項目テンプレートから仕様項目を選んだということを意識しなくても、該当する名前の仕様項目を記述すれば、自動的に、前記仕様項目関連テーブルＴＢ３によって関連付けを行わせることが可能である。もちろん、必要ならば、ユーザが仕様項目を選ぶとき、仕様項目テンプレートから選ぶのか否かを明示的に意思表示させるようなユーザインタフェースを構成してもよいことは当然である。
【０１７８】
仕様項目関連テーブルＴＢ３によるこの関連付けが行われたあとで、例えば、ユーザＵ２０が対応シートＦ１を編集し、図７に示す画面ＭＧ４などを介して、要求仕様項目の１つであるトナー交換作業に関し、前記重要度を上方修正したとすると、設計部門のユーザＵ２２などは、図１０に示す画面ＭＧ８に示す仕様項目ツリーなどで対応する部分に該当するアイコンを表示されていることを目視できる。これにより、ユーザＵ２０は打ち合わせなどを行うことなく、効率的に、ユーザＵ２２の注意を促すことができる。
【０１７９】
要求仕様項目の１つであるトナー交換作業には通常、複数の製品仕様項目が対応するため、当該アイコンは、複数の製品仕様項目（前記葉仕様項目）上に表示されることが望ましい。
【０１８０】
またこの際、上述した完全テンプレート法と例外許容法に応じて、異なる処理が行われ得ることは、すでに説明した通りである。
【０１８１】
（Ａ−３）実施形態の効果
以上のように、本実施形態によれば、グループウエアサービスの利便性を高めることができる。
【０１８２】
これにより、対応シートに忠実に対応した製品仕様書を作成でき、顧客の要望に的確に対応した製品開発を、効率的に行うことが可能になる。
【０１８３】
（Ｂ）他の実施形態
上記実施形態において一部の機能は省略したり、他の機能と置き換えたりすることが可能である。例えば、必要に応じて、ユーザ管理部２９や製品システム３６などは省略してもよいし、電子掲示板システム３０などは電子メールシステム等と置換可能である。また、必要ならば、電子掲示板システム３０は、電子メールシステムと併用することも可能である。
【０１８４】
なお、上記実施形態では、多くの関係表やビュー表の構成例（スキーマ構造も含む）を示したが、本発明が、上記実施形態に示した以外の構成を持つ関係表やビュー表にも適用できることは当然である。必要に応じて、関係表には、第１〜第３正規化を施してもよい。
【０１８５】
また、上記実施形態では、データベースはすべて関係型データベースであるものとしたが網型や、階層型などのデータベースを用いてもよいことは上述した通りである。さらにまた、網型、階層型、関係型などタイプ（型）の異なるデータベースが混在していてもかまわない。
【０１８６】
なお、上記実施形態では、企業Ｅ１が自社内に内部システム１２を構築したが、内部システム１２に相当する機能を持つグループウエアサービスは、ＡＳＰ（アプリケーションサービスプロバイダ）などが提供するアウトソースサービスの形で、企業Ｅ１が利用するものであってもよい。
【０１８７】
その場合、各種サーバ機能は、ＡＳＰのデータセンタなどに配置する形態を用いてもよく、レンタルサーバ（レプリケーションサーバ）として、企業Ｅ１の内部ネットワーク１４に配置してもよい。
【０１８８】
アウトソースサービスとする場合には、前記クライアントソフト（ＣＬ２０など）は、通常のＷｅｂブラウザなどの汎用的なクライアントソフトを用いるほうが有利となる可能性が高い。
【０１８９】
なお、上記実施形態では、図示した多くの具体的な画面例を用いて説明したが、本発明が、図示した以外の構成を有する画面に適用可能なことは当然である。
【０１９０】
また、上記実施形態では、主として、同じ開発プロジェクト内の企画部門のユーザと設計部門のユーザがグループウエアサービスを利用したが、本発明は製品の開発プロジェクトに限って適用されるものではなく、したがって、企画部門と設計部門に限って利用できるものでもない。また本発明は、必ずしも企業活動に限って適用するものでもない。
【０１９１】
本発明は、何らかの目的のために、協調して、効率的な共同作業を行う行うケースに広く適用可能である。
【０１９２】
以上の説明では主としてソフトウエア的に本発明を実現したが、本発明はハードウエア的に実現することも可能である。
【０１９３】
【発明の効果】
以上に説明したように、本発明によれば、利便性が高まる。
【図面の簡単な説明】
【図１】実施形態にかかる通信システムの全体構成例を示す概略図である。
【図２】実施形態で使用される通信端末の内部構成例である。
【図３】実施形態で通信端末に表示される画面の構成例である。
【図４】実施形態で通信端末に表示される画面の構成例である。
【図５】実施形態で通信端末に表示される画面の構成例である。
【図６】実施形態で通信端末に表示される画面の構成例である。
【図７】実施形態で通信端末に表示される画面の構成例である。
【図８】実施形態で通信端末に表示される画面の構成例である。
【図９】実施形態で通信端末に表示される画面の構成例である。
【図１０】実施形態で通信端末に表示される画面の構成例である。
【図１１】実施形態で通信端末に表示される画面の構成例である。
【符号の説明】
１０…通信システム、１１…外部システム、１２…内部システム、１３…外部ネットワーク、１４…内部ネットワーク、２０〜２５…通信端末、２６…管理システム、２７…タスク管理部、２８…文書管理部、２９…ユーザ管理部、３０…電子掲示板システム、３１…データベースサーバ、３２…共有データベース、３３…対応シート作成システム、３４…要望管理システム、３５…製品仕様書作成システム、４０…通信部、４１…制御部、４２…表示部、４３…操作部、４４…記憶部、ＴＢ１〜ＴＢ５…テーブル（関係表）、ＣＬ２０〜ＣＬ２５…クライアントソフト。
【図１】
2004192048.tif 000003
【図２】
2004192048.tif 000004
【図３】
2004192048.tif 000005
【図４】
2004192048.tif 000006
【図５】
2004192048.tif 000007
【図６】
2004192048.tif 000008
【図７】
2004192048.tif 000009
【図８】
2004192048.tif 000010
【図９】
2004192048.tif 000011
【図１０】
2004192048.tif 000012
【図１１】
2004192048.tif 000013