JP2746173B2 - 並行設計管理システム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、複数の作業者によって
製品等を共同で設計する際に、ある作業者が要求した設
計データの更新に対して、その更新に影響を受ける作業
者間で討議して意思決定を行う過程を管理する並行設計
管理システムに関する。

【０００２】

【従来の技術】ネットワーク化された計算機上で、複数
の作業者が共同して製品の設計・生産を行う時、設計業
務を複数の工程（例：コンピュータ製品におけるＬＳＩ
設計／基板実装設計／価格設計など）に分担して同時並
行的に進めることで、設計を効率良く進めることが出来
る。このような設計方式は、一般に「並行設計（コンカ
レントデザイン）」と呼ばれる。

【０００３】しかし実際には、製品の設計データや管理
情報が相互に依存関係を持つので、並行化された工程を
各々独立に進めることは出来ない。すなわち、互いの工
程の作業状況や設計変更に作業者が気を配り、製品構成
の上で矛盾が生じないように必要に応じて作業の調整を
行う必要がある。

【０００４】従来、このような目的で、全ての作業者が
共通にアクセスできる一元的なデータベースを設け、各
工程からの設計データや管理情報などをこのデータベー
ス上に集中させ、互いにレビューするシステムがいくつ
か提案されている。これによって、異なる工程間で、製
品の現在の設計状態や進捗を共有しつつ作業を進める事
ができる。

【０００５】ここで言う「レビュー」とは、並行設計に
おいて、ある作業者が、自分以外の作業者が作成した設
計データを閲覧して、変更してほしい箇所や設計意図が
分からない箇所があった場合に、変更のための操作やコ
メントによる要求を加える行為である。一人の作成した
設計データには、複数の作業者からレビューが加えられ
る。これによって、各作業者が作成した設計データの誤
りや妥当性を、客観的に評価することができる。

【０００６】例えば特開平０５−２４２１７４号公報
（以下、文献１）では、ＣＡＤシステムで共同設計を行
う際に、部品形状データベースに部品の形状データを集
中的に格納することにより、部品の設計を行う設計者
と、同じ部品を参照する設計者とが、最新の部品の形状
データを共有できることを特徴とする。

【０００７】同じく特開平０５−３２４２９５号公報
（以下、文献２）では、ソフトウェアの共同開発支援を
行う際に、設計手順を抽象的レベルで分割し、各レベル
毎に作成すべき仕様情報や設計部品情報、およびそれら
の詳細化によって作成されたドキュメントをデータベー
スで管理することにより、設計ドキュメントの管理、チ
ェックを容易にすることを特徴とする。

【０００８】また、前述した全ての作業者が共通にアク
セスできる一元的なデータベース上の設計データが変更
された場合に、関連する作業者（例えば修正された部分
を参照している設計の担当者）たちに電子メールなどで
変更を通知することによって、異なる工程同士でのレビ
ューを促すシステムも提案されている。

【０００９】例えば特開平０２−２４５８６５号公報
（以下、文献３）では、共有データ領域を集中管理する
作業スペースプロセスと、各ユーザ毎に割り当てられる
覗き窓プロセスとを有し、共有データに対する変更要求
が直ちに覗き窓プロセスに伝達されることにより、画面
上の共有データの表示の変更を視覚的に確認させること
を特徴とする。

【００１０】同じく特開昭０２−０３６４３９号公報
（以下、文献４）では、設計データ間の階層関係を抽出
して、ある設計データが更新された時に、その更新が上
位階層に影響を及ぼすか否か、変更の警告をどの利用者
に通知するか、などを判定して、警告を通知することに
より、処理フロー内の設計データの整合性を保証するこ
とを特徴とする。

【００１１】更に、前記の共有データベース上の設計デ
ータが変更された場合に、関連する作業者の間で変更要
求を含むメッセージ（電子メールなど）を交換して、複
数の作業者からの変更案やコメントを収集してから変更
を決定するシステムも提案されている。

【００１２】例えば特開平０３−０８５８８８号公報
（以下、文献５）では、ワードプロセッサで作成したテ
キストの一部に対する削除やコメントの要求を電子メー
ルで他の作業者に送付し、受信した作業者の側で、その
メール内容を前記のテキストの変更を要求された部分に
論理的に対応づけることにより、変更要求を収集するこ
とを特徴とする。

【００１３】

【発明が解決しようとする課題】文献１および文献２に
記載のシステムでは、共有された設計データに対してあ
る表示・編集ツールで変更を加えた場合、その変更箇所
／内容を、異なる表示・編集ツールに反映させることが
できない。例えば、特に並行設計の場合、設計対象の一
つの部品の変更は、設計工程ではＣＡＤ図面上での部品
の置換に、経理工程では部品価格表のレコードの置換
に、各々反映されなければならないが、そのような変換
機能が無い。

【００１４】また、文献３および文献４に記載のシステ
ムでは、変更による影響の通知は全て並行かつ同時に扱
われる。即ち、レビューを開始するタイミングや手順を
適切に与えることが出来ない。そのため、例えば「機能
仕様での変更が概要仕様にまで影響する場合、（上位工
程の成果物である）概要仕様のレビューを優先させる」
といった手順がその都度生成できないので、かえって設
計の混乱を招き兼ねない。また例えば、変更による影響
の通知が常にリアルタイムの同期的な通信で行われる
と、各作業者が自分のペースで設計を進めることが難し
くなる。

【００１５】更に、文献５に記載のシステムでは、レビ
ューを行う全ての作業者が同一の表示・編集ツールの上
で変更要求とレビュー対象の設計データとの対応を取る
ことを前提としている。従って、複数の作業者から収集
された変更要求を様々な観点から評価して、最終的な変
更の意思決定を下すことが困難である。例えば、特に並
行設計の場合、レビュー中の変更案は異なる工程の担当
者が個別の表示・編集ツール（例えば設計担当ならＣＡ
Ｄツール、経理担当なら表計算ツール）で作成されるの
で、各自の変更案が他の工程でどのような影響を及ぼす
かを各々のツールで相互に比較して把握するようなこと
ができない。

【００１６】また、前述した従来例で挙げたシステムで
は、作業者が変更の事実を知ることは出来るが、その後
に作業者間で変更の影響を検討・調整する間のコミュニ
ケーション過程を分かりやすく整理するものは無い。例
えば、特定の変更に対するレビューを繰り返す間に行わ
れる討議を個別の要求ごとに記録する機能がない。その
ため、特に並行設計において複数のレビューが同時並行
的に続けられると、レビューの対象が何であるのかを見
失ったり、レビューすること自体を途中で忘れたりする
という欠点がある。

【００１７】以上問題点を指摘したように、並行設計に
おいて、設計データの変更が要求された時点で影響を受
ける作業者同士で変更の是非をレビューし意思決定する
ためには、以下の課題が解決されなければならない。 １）各作業者がレビューを行う際に、設計データの変更
箇所や影響を受ける箇所を、設計データの表示・編集ツ
ールの相違に依らずに互いに交換すること。 ２）各作業者が変更要求に対するレビューを行う際のコ
ミュニケーションにおいて、レビューに用いるメッセー
ジを送信する適切な配送先とタイミングを設定するこ
と。 ３）並行して進められるレビューのコミュニケーション
に対して、その履歴を分かりやすく分類・蓄積し、各作
業者に表示すること。 ４）任意の作業者から寄せられたレビューに含まれる変
更要求を様々な観点から検討して、設計データに反映さ
せること。

【００１８】本発明の目的は、上述した課題を解決し、
並行設計を進める際に、ある作業者が要求した設計デー
タの更新に対して、その更新に影響を受ける作業者間で
レビューして意思決定を行う過程を円滑化する並行設計
管理システムを提供することにある。

【００１９】

【課題を解決するための手段】本発明、第１の発明は、
ネットワーク化された計算機上で、複数の作業者が共同
して製品等の設計を行うために、各々の作業者が作成し
た設計データを共有し、作業者間で並行設計を進める過
程を管理する並行設計管理システムにおいて、各々の作
業者が前記設計データを固有のデータ表現形式に基づい
て編集を行う設計データ編集手段と、前記設計データ編
集手段が必要とする前記製品等の構成要素の各種属性記
述（形状／価格データ、機能定義等）と前記要素間の関
係記述とを全て含んだ標準的なデータ表現形式で記述さ
れる標準設計データと、前記固有のデータ標準形式によ
る設計データとを相互に変換する設計データ表現形式変
換手段と、前記標準設計データを格納し共有する共有デ
ータベースと、前記設計データ編集手段および設計デー
タ表現形式変換手段を用いて、前記標準設計データの任
意の箇所に対して作業者が変更あるいはコメントを加え
た際に、前記標準設計データの前記変更を要求する前の
版との比較によって、前記箇所の変更差分あるいはコメ
ントを識別し、前記任意の箇所と前記識別された変更差
分あるいはコメントとの組からなる変更要求を構成する
レビュー支援システムと、前記変更要求の実施によって
影響を受ける可能性のある前記標準設計データの集合で
ある変更要求範囲を前記共有データベース内で特定し、
前記標準設計データの作成者に前記変更要求を通知する
変更要求通知手段と、前記作業者が与えた変更要求を含
むレビューメッセージの送出と受信を制御するコミュニ
ケーション制御手段と、前記複数の作業者間でやりとり
した一連のレビューメッセージを収集・表示するレビュ
ー履歴収集手段とを有することを特徴とする。

【００２０】第２の発明は、第１の発明において、前記
設計データ表現形式変換手段が、設計に参加する作業者
と、各作業者が利用するデフォルトの設計データ編集手
段とを対応付ける設計データデフォルト選択手段と、前
記作業者が変更要求の対象となった標準設計データを表
示・編集する設計データ編集手段を任意に指定する設計
データ任意選択手段とを有することを特徴とする。

【００２１】第３の発明は、第１、第２の発明におい
て、前記コミュニケーション制御手段が、送出前のメッ
セージを一時的に蓄積するメッセージ一時蓄積手段と、
前記コミュニケーション制御手段が送出するメッセージ
の配送先（アドレス）とタイミングを決める規則である
配送規則を設定する配送規則設定手段と、前記配送規則
を解釈して、前記メッセージ一時蓄積手段に蓄積された
メッセージを配送するよう指示を出す配送規則実行手段
とを有することを特徴とする。

【００２２】第４の発明は、第３の発明において、前記
変更要求通知手段が、レビュー開始のためのメッセージ
を通知する全ての可能な順序を算出するレビュー順序算
出手段と、前記レビュー順序算出手段が導出したレビュ
ー順序の一つを選択するレビュー順序選択手段と、前記
レビュー順序選択手段が選択した順序に基づいて、メッ
セージを配送するような配送規則を生成するレビュー順
序設定手段を有することを特徴とする。

【００２３】第５の発明は、第４の発明において、前記
レビュー順序算出手段が、算出した順序の各々に対し
て、前記順序でレビューを行う際のレビュー参加者の業
務負荷の予測値であるレビューコストを評価するレビュ
ーコスト評価手段を有し、前記レビュー順序選択手段
が、前記レビューコストを最小にする順序を選択するこ
とを特徴とする。

【００２４】第６の発明は、第１の発明において、前記
レビュー履歴収集手段が、レビューの参加者がやりとり
するメッセージのうち、特定の変更要求箇所に対する変
更要求を含むものを選択する特定レビュー選択手段と、
前記特定の変更要求箇所ごとに選択されたメッセージ群
であるレビュー履歴を一まとめにして蓄積するレビュー
履歴分別手段と、蓄積された前記レビュー履歴を、前記
特定の変更要求箇所ごとに各作業者の画面上に表示する
レビュー履歴表示手段とを有することを特徴とする。

【００２５】第７の発明は、第６の発明において、前記
レビュー履歴表示手段が、特定の作業者が受信したメッ
セージの中で参照されている変更要求について、同じ変
更要求箇所に対するレビュー履歴のまとまりを前記作業
者の画面上で特定する特定レビュー履歴検索手段とを有
することを特徴とする。

【００２６】第８の発明は、第６、第７の発明におい
て、前記レビュー履歴収集手段が、特定の変更要求箇所
に対して収集・蓄積されたメッセージの一つを作業者が
選択するレビュー履歴選択手段と、前記選択されたメッ
セージが参照する変更要求について、前記変更要求置換
手段が置換した変更後の標準設計データのコピーを任意
の前記設計データ編集手段によって表示するレビュー結
果評価手段と、任意の作業者がレビュー履歴の中の一つ
のメッセージをレビュー結果として決定し、前記メッセ
ージを他のメッセージと区別して各作業者の画面に表示
させるレビュー結果決定手段とを有することを特徴とす
る。

【００２７】

【作用】本発明による並行設計管理システムでは、第１
の発明にあるように、本システムにおいて共有データベ
ースに格納する設計データおよび変更要求を、各設計工
程で必要な設計情報が不足無く含まれるような標準的な
データモデルで構成し、作業者が変更要求を含む設計デ
ータを表示・編集ツールで表示する際に、前記設計デー
タをその表示・編集ツールが必要とする固有のデータ形
式に変換する。また、第２の発明にあるように、各作業
者が前記変更要求を含む設計データを表示・編集するツ
ールを作業者が自由に設定できるようにする。これによ
って、一つの表示・編集ツールで設計データに加えた変
更要求（箇所／内容）の情報を、前記標準的データモデ
ルとの変換を介して任意の表示・編集ツールで確認する
ことが出来る。これによって、前述した課題の第一を解
決する。

【００２８】また、第３の発明にあるように、本システ
ムにおいてレビューのメッセージを一旦蓄積したあと、
誰にどのタイミングで送出するかを、コミュニケーショ
ン手段に対する制御規則によって設定させる事によっ
て、レビューの進め方をレビューに関わる作業者の都合
に合わせて変化させることが出来る。また、第４の発明
にあるように、変更通知をその変更に影響される作業者
に一斉通知するのでなく一定の順序で通知することによ
って、作業者間のコミュニケーションの錯綜を抑制しな
がら、検討の結果を順次引き渡すことが出来る。更に、
第５の発明にあるように、レビューを始めてからのコミ
ュニケーションの後戻りや行き詰まりが発生しにくいよ
うな順序を予測して、その順序でメッセージが流れるよ
うな前記コミュニケーション手段に対する制御規則をシ
ステムが生成することによって、レビューをさらに円滑
に進めることが出来る。これらによって、前述した課題
の第二を解決する。

【００２９】また、第６の発明にあるように、本システ
ムにおけるレビューのメッセージに記載された変更要求
の参照情報から、同じ変更要求箇所ごとにメッセージを
自動的に分別して蓄積・表示することによって、特定の
変更要求箇所に対するレビューに用いられたメッセージ
だけを整理して見ることができる。このため、複数のレ
ビューが並行して進行する状況の中でもレビューの進捗
把握や調整が容易になる。また、第７の発明にあるよう
に、特定のメッセージが参照する変更要求箇所に対し
て、同じ変更要求箇所に対するそれまでのレビューの履
歴を画面上で特定することにより、自分以外の作業者の
コメントや修正案を容易に把握することが出来る。これ
らによって、前述した課題の第三を解決する。

【００３０】また、第８の発明にあるように、レビュー
履歴の中から選択したレビューメッセージについて、そ
の中で参照される特定の変更要求の通りに変更したと仮
定した場合の設計データを標準設計データで表現し、作
業者が選んだ任意の表示・編集ツール向けに変換して表
示することによって、どの工程、あるいはどのツールに
よって編集されたレビューであるかに関係なく、平等か
つ直感的に複数の変更の案を評価し、その変更を反映し
た結果を共有することができる。これらによって、前述
した課題の第四を解決する。

【００３１】

【実施例】以下、図面を用いて本発明の実施例を詳細に
説明する。

【００３２】図１は、本発明による並行設計管理システ
ムの構成の一実施例を示すブロック図である。

【００３３】図において、レビュー支援システム（００
０）は、少なくとも、 （１）レビュー対象となる設計データの物理ファイルあ
るいは製品モデルデータについて変更が加えられた場
合、その変更の前後での物理ファイルあるいは製品モデ
ルデータの版を比較することによって、その変更箇所と
変更差分とを取得し、一組の変更要求を構成すること。 （２）レビュー対象となる設計データの物理ファイルあ
るいは製品モデルデータの特定の箇所についてコメント
が加えられた場合、その箇所とコメントとを取得し、一
組の変更要求を構成すること。 （３）変更要求の変更箇所の記述から、その変更要求が
加えられた設計データの物理ファイルあるいは製品モデ
ルデータを特定すること。 （４）設計データの物理ファイルあるいは製品モデルデ
ータの変更差分を含む変更要求について、変更箇所を変
更差分と置換して新しい版の物理ファイルまたは製品モ
デルデータを構成すること。が可能なシステムであると
する。このようなシステムとしては、例えば特開平０３
−０８５８８８号公報「文書添削支援方式及び装置」な
どを利用することが出来る。

【００３４】変更要求を構成する変更要求箇所、変更差
分およびコメントは、レビューメッセージに含まれる際
には、各々のデータ実体として直接含まれていてもよい
し、別の場所（例えば共有データベース（００１））に
格納された各々のデータ実体を一意に参照するような参
照情報が含まれていてもよい。

【００３５】例えば、変更要求箇所を一意に特定する情
報としては、変更を要求された標準設計データを書き込
む物理ファイル名と、その変更要求箇所の開始／終了位
置を用いて、「Ａファイル：２３４−２４６」のように
記述することが出来る。これは、物理ファイル名がＡフ
ァイルで、変更要求箇所の開始位置が先頭から２３４文
字目、終了位置が２４６文字目であることを示してい
る。

【００３６】また、変更差分またはコメントを一意に特
定する情報としては、データの実体が作成された時刻と
作成した作業者名を用いて、「ＤＩＦＦ：ｔａｂｕｃｈ
ｉ９５０１２４２３３９００」のように記述することが
出来る。これは、作業者ｔａｂｕｃｈｉが９５年１月２
４日２３時３９分に作成した変更差分（ＤＩＦＦ：は変
更差分であることを示すフラグ情報）であることを示し
ている。変更要求自体の参照情報は、これら変更要求箇
所と変更差分またはコメントの参照情報を組にして、
（Ａファイル：２３４−２４６，ＤＩＦＦ：ｔａｂｕｃ
ｈｉ９５０１２４２３３９００）のように記述されるこ
ととするが、もちろん、これはあくまで一例である。

【００３７】共有データベース（００１）は、複数の標
準設計データを作業者が一意に特定できる方法（例えば
名前付きの物理ファイル）で格納し、少なくとも、 （１）各標準設計データの最新の版を各作業者に提供す
る機能 （２）最新の版のデータに対して更新の許可／不許可を
制御する機能（例えば特定の作業者からの更新のみを受
け付ける等）を有する。このようなシステムとしては、
例えば米国オラクル社の製品であるリレーショナルデー
タベース管理システム「オラクル」などを利用すること
が出来る。

【００３８】設計データ編集手段（００２）は、形状デ
ータや価格データなど設計対象を構成する各種設計デー
タを作業者が入力して対話的に編集する機能と画面イン
タフェースとを提供する（例えばＣＡＤツールやテキス
トエディタなど）。各設計データは固有のデータ表現形
式を持つ。

【００３９】設計データ表現形式変換手段（００３）
は、各設計データ編集手段（００２）の固有のデータ表
現形式で表現された設計データと、標準設計データとの
間で相互に標準形式の変換を行う。

【００４０】標準設計データの表現形式は、少なくと
も、本発明の並行設計管理システムを適用する並行設計
の作業環境における全ての設計データ編集手段（００
２）に固有の設計データ表現について、製品を構成する
要素の属性記述（形状／価格データ、機能定義など）と
要素間の関係記述とを不足無く含む。このような表現形
式としては、例えば国際標準規格（アイ・エス・オー）
１０３０３で規定される「エクスプレス」データ表現を
利用することが出来る。

【００４１】変更要求通知手段（００４）は、作業者が
標準設計データを変更しようとしたとき、その変更要求
が影響を与える設計データの集合（変更影響範囲）を特
定し、前記の変更要求を加えた作業者から変更通知を送
付させるための計画を生成する。

【００４２】ここで言う「影響を与える」とは、製品全
体の整合性を保とうとするための変更に伴う影響であ
る。例えば、ソフトウェアの機能モジュール設計におい
て、一つの機能モジュールが別の機能モジュールで提供
されるライブラリ関数を利用するとして、提供側の機能
モジュールでライブラリ関数の定義における引数や返却
値を変更した場合、そのライブラリ関数を利用する（呼
び出す）側の機能モジュールの記述でも、関数の定義を
整合させるために関数呼び出し部分を変更しなければな
らない。この場合、該ライブラリ関数の変更が、それを
利用する機能モジュールに「影響を与え」たことにな
る。

【００４３】コミュニケーション制御手段（００５）
は、前記の変更要求を含むレビューメッセージを構成
し、その送信と受信を作業者ごとに制御する。少なくと
も、 （１）送信するメッセージに宛先（一人または複数）や
変更要求を設定する機能 （２）受信したメッセージを解析して、発信者や変更要
求を取得する機能 （３）受信したメッセージを作業者が読むまで一時的に
蓄積しておく機能 （４）送信するメッセージのタイミングを任意に設定す
る機能 を持つ。

【００４４】レビュー履歴収集手段（００６）は、各作
業者が受け取ったレビューメッセージを収集・蓄積し
て、作業者間で共有する。また、蓄積されたメッセージ
の任意のものを選択して、変更要求を受けた設計データ
を作業者に提示する。メッセージの蓄積の機能は、共有
データベース（００１）と同じデータベース上に実現さ
れてもよいし、そうでなくても構わない。

【００４５】コミュニケーション手段（００７）は、前
記の変更要求を含むレビューメッセージを並行設計に参
加する任意の作業者の間で伝達する。具体的には、電子
メールネットワークやパケット通信網などを用いること
が出来る。

【００４６】以上が図１の説明である。

【００４７】図２は、本実施例によって複数の作業者で
並列設計を行う過程を説明するフローチャートである。

【００４８】図２において、Ａ）は、ある作業者Ａが設
計データに対して変更要求を加えたとき、その変更要求
を含むレビューメッセージを影響を受ける任意の作業者
Ｂに発信するまでの過程、Ｂ）は、レビューメッセージ
を受け取った作業者Ｂが変更要求を承認して設計データ
を更新するまでの過程、Ｃ）は、作業者Ａの変更要求の
承認とある作業者Ｃによる標準設計データへの反映の過
程を、各々示すフローチャートである。

【００４９】図２のＡ）において、並行設計に参加する
全ての作業者は、設計データ編集手段（００２）を用い
て、設計すべき製品に対する各自の担当分の設計データ
を作成する。作成された設計データは、各設計データ編
集手段（００２）の固有のデータ表現形式で表現されて
いるので、これを設計データ表現形式変換手段（００
３）を用いて標準設計データの形式に変換し、共有デー
タベース（００１）に新規登録・格納する（ステップ１
００）。

【００５０】共有データベース（００１）に格納された
設計データを作業者が編集する場合も、設計データ表現
形式変換手段（００３）を用いて、作業者が利用する設
計データ編集手段（００２）固有のデータ表現形式に変
換し、設計データ編集手段（００２）に引き渡す（ステ
ップ１０１）。

【００５１】ある作業者Ａが共有データベース（００
１）に登録済みの任意の設計データを編集した後、レビ
ュー支援システム（０００）は、設計データ表現形式変
換手段（００３）が再度変換した表現設計データについ
て、変更またはコメントが与えられたか否かを判別し、
与えられない場合には、更に編集を続けるために（１０
１）へ戻る（ステップ１０２）。

【００５２】変更またはコメントが与えられた場合は、
その標準設計データの変更あるいはコメントが与えられ
た箇所と、変更差分またはコメントとを組にして、変更
要求を構成し、コミュニケーション制御手段（００５）
に引き渡す。コミュニケーション制御手段（００５）
は、その変更要求を含むレビューメッセージを構成す
る。編集された標準設計データは、共有データベース
（００１）に未承認のデータとして仮格納される（ステ
ップ１０３）。

【００５３】更に、前記のレビューメッセージを配送す
る作業者を決定するために、変更要求通知手段（００
４）は、前記の仮格納された標準設計データに与えられ
た変更要求に影響される変更影響範囲を、共有データベ
ース（００１）から全て取得する。メッセージの配送先
は、この変更影響範囲に含まれる標準設計データの作成
担当者（その中の任意の一人を仮に作業者Ｂとする）と
なる。変更要求通知手段（００４）は、作業者Ａから作
業者Ｂにメッセージを配送するための計画（宛先の設
定、発信のタイミングなど）を生成する（ステップ１０
４）。

【００５４】生成された計画は、作業者Ａのコミュニケ
ーション制御手段（００５）に送られ、先に構成したレ
ビューメッセージを発信する際の制御情報として用いら
れる。発信されたメッセージは、コミュニケーション手
段（００７）によって作業者Ｂを含む影響を受ける作業
者に配布される。配布先は、影響を受ける作業者の全部
であっても、一部を選択しても構わない（ステップ１０
５）。

【００５５】作業者Ｂのコミュニケーション制御手段
（００５）が受け取ったレビューメッセージは、レビュ
ー履歴収集手段（００６）に収集・蓄積される。更に、
作業者Ｂは、受け取ったメッセージに含まれる変更要求
を閲覧するために、任意のメッセージを一つ選択する
（ステップ１０６）。

【００５６】レビュー支援システム（０００）は、先に
選択されたメッセージに含まれる変更要求を、その変更
要求が加えられた標準設計データのコピーを共有データ
ベース（００１）から取得する。更に、その変更要求が
変更差分を含むなら、変更要求箇所を変更差分で置き換
え、コメントを含むなら、例えば変更箇所に相当するデ
ータ内容を選択状態とする。その結果、作業者Ｂが作成
担当である標準設計データも影響を受けて変更されるの
で、その変更後の標準設計データのコピーを共有データ
ベース（００１）から取得する（ステップ１０７）。

【００５７】取得した標準設計データは、設計データ表
現形式変換手段（００３）によって、作業者Ｂが利用す
る設計データ編集手段（００２）に固有の設計データ形
式に変換され、設計データ編集手段（００２）に表示さ
れる。作業者Ｂは、これによって作業者Ａから要求され
た変更要求が自分の担当工程の設計データにどう影響す
るのかを確認する（ステップ１０８）。

【００５８】作業者Ｂが、作業者Ａとは別の新たな変更
要求を対案として要求する場合は、先のステップ１０１
に移り、今度は作業者Ｂが設計データ編集手段（００
２）によって変更要求を作成する過程を開始する（ステ
ップ１０９）。

【００５９】対案を要求せず、先の変更要求を承認する
場合は、先の作業者Ａからの変更要求に対する作業者Ｂ
のレビューは終了する。承認しない場合は、他の作業者
からの別の対案を持ってステップ１０８以降を繰り返す
（ステップ１１０）。

【００６０】レビューに対する最終的な意思決定を加え
るため、作業者Ｃ（作業者ＡまたはＢと同一でも異なる
作業者でもよい）は、レビュー履歴収集手段（００６）
に収集されたレビューメッセージのうち、作業者Ａある
いは対案を出した作業者からの変更要求のいずれかにつ
いて、影響を受ける全ての作業者が承認したかどうかを
調べる。先の全ての変更要求について、全員の承認が得
られないなら、作業者Ａに再検討を要請し、作業者Ａに
ステップ１０１以下を繰り返させる（ステップ１１
１）。

【００６１】全ての作業者が承認する場合でも、コメン
トによる変更要求なら、実際に設計データを変更しなけ
ればならないので、作業者Ａまたは対案の提出者にステ
ップ１０１以下を繰り返させる（ステップ１１２）。

【００６２】変更差分による変更要求なら、レビュー支
援システム（０００）は、その変更要求箇所を変更差分
で置換した標準設計データを作成し、共有データベース
（００１）の旧版を更新する（ステップ１１３）。

【００６３】このように、レビューメッセージに含まれ
る変更要求を標準設計データの表現形式で記述してお
き、各作業者が利用する設計データの表示・編集手段に
合わせて表現形式を変換することにより、異なる工程の
作業者が正確にレビュー内容を交換することが出来る。

【００６４】以上が図２の説明である。

【００６５】ここで、標準設計データと設計データ編集
手段（００２）固有のデータ表現との間のデータ変換を
具体的に実現する方法を図を用いて説明する。

【００６６】図３は、本実施例において、標準設計デー
タと設計データ編集手段（００２）固有の設計データと
のデータ変換の例を説明するブロック図である。

【００６７】図３において、機械部品である部品Ａと部
品Ｂが、その形状については形状設計ツール（２００）
で、価格については価格表ツール（２０１）で、両者の
機械的な構成については構成管理ツール（２０２）で、
同時に設計されている。各々の設計データは、形状デー
タ記述（２０３）・部品価格データ記述（２０４）・構
成データ記述（２０５）に、各々のツールに固有の記述
形式で記述される。例えば図３において、形状データ記
述（２０３）は、部品Ａについての多角形の頂点の座標
値、厚み、穴の位置など、部品Ｂについての長方形の頂
点の座標値と直行座標上での回転角などを並べたリスト
で記述している。

【００６８】これらのデータ記述に対して、設計データ
表現形式変換手段（００３）は、表現形式変換規則（２
０６）を適用して、標準設計データ（２０８）と等価で
且つ計算機による動的な操作が可能な標準設計データモ
デル（２０７）を生成する。

【００６９】表現形式変換規則（２０６）は、特定の設
計データごとに、その表現形式における構成要素の値
と、標準設計データモデル（２０７）の構成要素の属性
／関係記述との対応を決定し、適切なデータ型変換や構
造の分析・融合などを行うための変換仕様の集合であ
る。

【００７０】一つの変換仕様は、例えば特定の設計デー
タから標準設計データへの変換ならば、「もし（特定の
設計データ記述のテンプレート）があれば、その値を
（標準設計データの表現形式のテンプレート）に代入す
る」という形式で、変換のための仕様を記述する。標準
設計データから特定の設計データへの変換についても、
同様の変換仕様を記述する。変換仕様においては、単純
な代入操作だけでなく、設計データの値の算術演算や論
理演算などを適用して、標準設計データモデル（２０
７）および設計データ記述のより複雑な値を構成するこ
とも出来る。

【００７１】例えば、形状データ記述（２０３）の（部
品Ａ、ポリゴン（２０，２０，１０，１００，０，２
０），厚さ（５））という部分は、「もし（Ｘ１，ポリ
ゴン（Ｘ２，Ｘ３，Ｘ４，Ｘ５，Ｘ６，Ｘ７，Ｘ８，Ｘ
９），厚さ（Ｘ１０）があれば、（名前：Ｘ１ タイ
プ：板 形状：（Ｘ２，Ｘ３，Ｘ４，Ｘ５，Ｘ６，Ｘ
７，Ｘ８，Ｘ９，Ｘ１０））に代入する」という仕様で
標準設計データモデル（１０７）の部品Ａに関する記述
に変換される。ここでＸ１からＸ１０は規則内の変数で
ある。

【００７２】構成された標準設計データモデル（２０
７）は、物理ファイルなどの実体を持つ標準設計データ
（２０８）に等価変換され、共有データベース（００
１）に格納される。

【００７３】標準設計データ（２０８）から各ツールの
設計データへの変換も同様に、目標とする設計データ表
現形式に向けた表現形式変換規則（２０６）を適用し
て、標準設計データモデル（２０７）から必要なデータ
部分だけを抽出し、適切なデータ型変換や構造の分解・
融合などの操作を行う。例えば、標準設計データモデル
（２０７）から形状データ記述（２０３）を構成するに
は、部品Ａ、Ｂ各々の名前・タイプ・形状・「穴」部分
の属性の各データ部分を抽出し、部品Ａ、Ｂの頂点の座
標値、厚み、穴の位置のデータ記述を再構成する規則を
適用する。

【００７４】以上が図３の説明である。

【００７５】また、前述のステップ１０４の説明で、あ
る標準設計データの変更に影響を受ける範囲を特定す
る、と記載したが、その方法について図面を用いて詳細
に説明する。

【００７６】図４は、標準設計データモデル（２０８）
の構成要素間の関係記述を示す模式図である。

【００７７】図４において、作業者が形状設計ツール
（３００）で機械部品Ａ、Ｂを設計しており、両者は、
部品Ａ（３０１）の穴の部分と部品Ｂ（３０２）の凸部
分とで接合されているとする。この場合、両者の接合を
保つには、 ・部品Ａ（３０１）の穴の中心が部品Ｂ（３０２）の凸
部の中心と一致する。 ・部品Ａ（３０１）の穴の半径が部品Ｂ（３０２）の凸
部よりも大きい。 という関係が両者の間になければならない。

【００７８】このような関係を、図４の例では、形状設
計データを設計データ表現形式変換手段（００３）で変
換して製品全体の標準設計データモデル（２０７）を構
成する際に、その構成要素である部品Ａの構成要素（３
０３）と、部品Ｂの構成要素（３０４）との間の制約
（３０５）として記述する。

【００７９】制約（３０５）は、複数の構成要素を各々
参照することによって、構成要素間を関係付ける。図４
の例では一対一の関係付けを示したが、一対多の関係付
けでも良い。更に、前記の部品Ａ（３０１）と部品Ｂ
（３０２）の接合部分にあるような、構成要素の属性値
などの間で守られるべき関係は、算術演算を含む関係式
によって詳細に記述される。図４の例の関係式は、例え
ば 部品Ａ．属性：穴（１）＝＝部品Ｂ．属性：凸部（１） 部品Ａ．属性：穴（２）＝＝部品Ｂ．属性：凸部（２） 部品Ａ．属性：穴（３）＞＞部品Ｂ．属性：凸部（３） のように記述される。「部品Ａ．属性」の表記は、部品
Ａの属性の項目への参照であるとする。また、「穴
（１）」の表記は、各構成要素の記述のうち、穴属性の
パラメータ位置の１番目のパラメータ値であることを示
しているとする。ただし、図４の例では、穴属性のパラ
メータが（中心Ｘ座標、中心Ｙ座標、半径）の並びで、
凸部属性のパラメータが（中心Ｘ座標、中心Ｙ座標、半
径、高さ）の並びで、それぞれ記述されるとする。

【００８０】このような制約（３０５）の関係式は、形
状設計ツール（３００）または他の制約記述用のツール
で作業者が与えた制約の入力指示を設計データ表現形式
変換手段（００３）が変換して与えるか、製品データモ
デルに関する一般的な知識を提供する知識ベースが与え
ても良い。

【００８１】制約解釈手段（３０６）は、制約（３０
５）における関係式を解釈することにより、ある標準設
計データモデルの構成要素に変更が加えられたときに、
影響を受ける他の構成要素を特定する。図の例で、例え
ば作業者が形状設計ツール（３００）で部品Ａ（３０
１）の穴の位置を移動したとする。その際、制約解釈手
段（３０６）は、制約（３０５）の関係式に各構成要素
の属性値などを代入して、作業者の移動操作終了後も関
係式が成立するか否かを判定する。この場合、 部品Ａ．属性：穴（１）＝＝部品Ｂ．属性：凸部（１） 部品Ａ．属性：穴（２）＝＝部品Ｂ．属性：凸部（２） が成立しないことが分かる。制約解釈手段（３０６）
は、更に、作業者が変更しなかった標準設計データの構
成要素を制約（３０６）の関係式から判別し（この場合
は部品Ｂの構成要素（３０４）の「凸部」属性）、制約
（３０５）の関係式を満たすためにその構成要素が取る
べき値を設定する。この場合、部品Ｂの構成要素（３０
４）の「凸部」属性の中心座標を移動後の部品Ａの構成
要素（３０３）の穴の中心座標と一致させれば良い。値
を設定する構成要素は、先の関係式が満たされる限り、
作業者が変更しなかった部分の一部であってもよい。

【００８２】このように、制約（３０５）の関係式を通
じて、作業者が加えた変更を他の標準設計データモデル
（２０７）に伝搬させ、さらにその伝搬による変更を再
帰的に適用することによって、変更の影響を受ける標準
設計データモデル（２０７）の構成要素の範囲を得るこ
とが出来る。

【００８３】以上が図４の説明である。

【００８４】ところで、並行設計では各作業者が利用す
る設計データ編集手段（００２）が様々に異なるので、
表現形式変換規則（２０６）も、利用される設計データ
編集手段（００２）と同じ数だけ用意し、利用時に適宜
選択しなければならない。その選択の方式について図を
用いて詳細に説明する。

【００８５】図５は、設計データ表現形式変換手段（０
０３）が、表現形式変換規則（２０６）の中から各作業
者の用いる設計データ編集手段（００２）に対応するた
めの規則を選択する方式の一実施例を説明するブロック
図である。

【００８６】図５において、設計データ任意選択手段
（４００）は、設計データ表現形式変換手段（００３）
において標準設計データと相互変換可能な全ての設計デ
ータ表現に対応する設計データ編集手段（００２）のコ
マンド名と、その設計データ表現に対応する表現形式変
換規則（２０６）とを一対一に対応付けて保持するため
の表を持つ。この表は、特定の表現形式変換規則（２０
６）を登録する際に、利用者が予め作成しておく。

【００８７】一方、設計データデフォルト選択手段（４
０２）は、並行設計に参加する作業者を一意に特定する
名前情報と、各々の作業者がデフォルトで利用する設計
データ編集手段（００２）を一意に特定するコマンド名
とを一対一に対応付けて保持するための表を持つ。デフ
ォルトのコマンド名は、例えば作業者のコミュニケーシ
ョン制御手段（００５）で受け取ったレビューメッセー
ジを最初に表示させる時のように、作業者がどの設計デ
ータ編集手段（００２）を利用すべきが特定できない場
合に用いられる。例えば、各々の作業者が担当する業務
で最も頻繁に使われる設計データ編集手段（００２）の
コマンド名がデフォルトのコマンド名となる。

【００８８】作業者が、作業者指示手段（４０１）を用
いて、前記の設計データ任意選択手段（４００）の対応
表に記載されたコマンド名の集合の中から、自分が利用
する設計データ編集手段（００２）の任意の一つを選択
する。作業者指示手段（４０１）は、例えば作業者の画
面インタフェース内のマウスなどの指示入力手段を用い
て実現できる。

【００８９】設計データ表示形式変換手段（００３）
は、作業者が任意の標準設計データを読み込む際に、ま
ず設計データ任意選択手段（４００）に問い合わせて、
選択されたコマンド名があるかどうかを調べる。もしな
ければ、設計データ表現形式変換手段（００３）は、設
計データデフォルト選択手段（４０２）に問い合わせ、
前記の作業者の名前からデフォルトのコマンド名を得
る。

【００９０】設計データ表現形式変換手段（００３）
は、作業者が選択した、あるいはデフォルトの、コマン
ド名に対応する表現形式変換規則（２０６）を設計デー
タ任意選択手段（４００）の対応表から得て、それを用
いて、選択された設計データ編集手段（００２）に固有
の設計データ表現形式に変換し、前記の作業者に対して
表示する。

【００９１】以上が図５の説明である。

【００９２】次に、コミュニケーション制御手段（００
５）が変更要求を含むレビューメッセージを送信する際
に、適切な配送先とタイミングとを設定し制御する方式
を、以下で図面を用いて詳細に説明する。

【００９３】図６は、変更要求通知手段（００４）が、
各作業者のコミュニケーション制御手段（００５）に対
して、レビューメッセージ送信時の宛先とタイミングを
設定するための規則（配送規則）を構成する方式の一実
施例を示すブロック図である。

【００９４】配送規則実行手段（００５）は、配送規則
設定手段（５０１）を用いて作業者が入力した配送規則
を解釈し、配送規則のタイミングの条件が満たされた時
点で、コミュニケーション制御手段（００５）に対し
て、特定のレビューメッセージを、配送規則内に記述さ
れた配送先に対して発信するよう要求する指示を送る。

【００９５】ある変更要求に対してコミュニケーション
制御手段（００５）が構成したレビューメッセージは、
前記の発信を要求する指示を待つために、その変更を要
求した作業者が持つメッセージ一時蓄積手段（５０２）
に一旦蓄積される。そして、配送規則実行手段（５０
０）から特定のレビューメッセージの送出要求が来た時
点で、コミュニケーション制御手段（００５）は、メッ
セージ一時蓄積手段（５０２）に蓄積されているメッセ
ージがあれば、その古いものから順に、前記の配送規則
に記述された配送先を与えてから、コミュニケーション
手段（００７）に対して送信する。もし蓄積されていな
ければ、コミュニケーション制御手段（５０２）は、レ
ビュー支援システム（０００）に対して、現在編集中の
設計データから変更要求を強制的に取得してメッセージ
一時蓄積手段（５０２）に蓄積することも出来る。

【００９６】ここで言う配送規則はもし、あるタイミン
グの条件が満たされたら、特定の作業者宛に、特定の記
載内容に対する条件を満たすメッセージを送付するとい
う形式で書かれている。タイミングの条件には、時計な
ど時刻の計測手段による特定の時刻の到来通知や、コミ
ュニケーション手段（００７）による特定のメッセージ
の発信・着信の通知などが該当する。特定の作業者の配
送先は、コミュニケーション手段（００７）の中で一意
に特定可能なアドレス情報（例えば電子メールアドレ
ス）によって記述する。送付するメッセージの記載内容
に対する条件には、「メッセージ内の変更要求の変更箇
所が、ある特定のファイルの特性の箇所と一致する」の
ように指定する事が出来る。

【００９７】例えば、コミュニケーション手段（００
７）がパケット通信などの実時間通信系で実現されてい
て、ある作業者Ａから作業者Ｂ、Ｃ、Ｄに所定の時間間
隔で変更要求を送り出さなければならない場合、時計な
ど時刻の計測手段が所定の時間間隔で時刻の経過通知を
発生するとして、もし、時刻の経過通知が発生したら、
作業者Ｂ、Ｃ、Ｄに（無条件で）メッセージを送付する
という配送規則を作業者Ａの配送規則実行手段（５０
０）で実行する。

【００９８】また例えば、ある作業者Ａがレビュー過程
の主導権を持ち、別の作業者Ｂの変更要求を必要になっ
た時点で取り寄せたい場合、作業者Ａが取り寄せ要求を
発信する手段を持つ（例えば作業者Ｂに特定の書式の電
子メールを送付する等）場合、もし、作業者Ａからの取
り寄せ要求をコミュニケーション手段（００７）が受信
したら、作業者Ａに（無条件で）メッセージを送付する
という配送規則を作業者Ｂの配送規則実行手段（５０
０）で実行する。

【００９９】一方、本実施例によれば、レビューメッセ
ージを発信する際に、変更要求の影響を受ける作業者へ
の一斉同報だけでなく、一定の順序に従って、関係する
作業者に順次行き渡るようにメッセージを配送すること
が出来る。

【０１００】まず、コミュニケーション制御手段（００
５）が変更要求を含むレビューメッセージを構成した時
点で、そのメッセージがメッセージ一時蓄積手段（５０
２）に一旦蓄積される。同時に、変更要求通知手段（０
０４）の中で、変更影響範囲特定手段（５０３）が前記
の変更によって影響を受ける標準設計データの集合を特
定し、それらの作成担当者の名前情報の集合をレビュー
順序算出手段（５０４）に引き渡して、前記の変更通知
メッセージの可能な送信順序を算出させる。

【０１０１】レビュー順序選択手段（５０５）は、前記
の可能な送信順序のうち、適当なものを一つ選択して、
レビュー順序設定手段（５０６）に引き渡す。送信順序
の選択は、例えば特定の作業者（並行設計業務全体の進
捗管理者など）が行う。

【０１０２】レビュー順序設定手段（５０６）は、選択
された送信順序に従ってレビューが進むような配送規則
を配送規則実行手段（５０４）に対して入力し、実行さ
せる。このような配送規則の例については、後述する。

【０１０３】更に、本実施例によれば、レビュー順序算
出手段（５０４）が算出した変更通知の配送順序を、作
業者が選択するのではなく、並行設計業務全体の効率化
のために、レビューを行う際の業務負荷が最も少なくな
ると予測されるような順序を自動的に設定することも出
来る。

【０１０４】まず、レビュー順序算出手段（５０４）
は、変更影響範囲に含まれる標準設計データを、算出し
た変更通知メッセージの配送順序で順序づけしたリスト
をレビューコスト評価手段（５０７）に引き渡す。レビ
ューコスト評価手段（５０７）は、レビューに関わる作
業者の業務負荷の予測値（レビューコスト）を評価する
ための評価手続き（５０８）を持ち、与えられた標準設
計データの並びの全てについて評価を行う。

【０１０５】評価手続き（５０８）は、現在レビューさ
れている変更要求が他の標準設計データに与える影響の
大きさと、その影響の依存・伝播の関係を考慮して、特
定のレビュー順序でレビューを実施したと仮定した場合
の作業者の業務負荷に対する評価値を与える。評価値の
算出方法については後述する。

【０１０６】評価手続き（５０８）は、特定のレビュー
順序におけるこれら業務負荷の評価要因に対して重み付
けをし、その重みの総和を評価値とする。レビュー順序
選択手段（５０５）は、その評価値が最も高い（あるい
は最も低い）並びを選択して、レビュー順序設定手段
（５０６）に引き渡す。評価値が最も高い（低い）同じ
並びが複数残る場合は、例えば作業者が選択するか、ラ
ンダムに一つ選べばよい。

【０１０７】このようにして、各作業者が変更要求に対
するレビューメッセージを送信する際に、順次レビュー
・一斉レビューを含めて、適切な配送先とタイミングと
を設定し制御することが出来る。

【０１０８】以上が図６の説明である。

【０１０９】ここで、レビューメッセージを配布する作
業者の集合から生成される配布順序を図を用いて詳細に
説明をする。

【０１１０】図７は、例えば前記の作成担当者の集合が
作業者Ａ、Ｂ、Ｃの３人であった場合の可能な送信順序
の全てを示す模式図である。

【０１１１】すなわち図７の６００は、Ａ、Ｂ、Ｃの各
々に一人ずつ順番に送信される場合（６通り）である。
図７の６０１は、Ａ、Ｂ、Ｃのうち部分的な同報（この
場合たかだか二人）を含む送信順序（６通り）である。
図７の６０２は、Ａ、Ｂ、Ｃに一斉同報される場合（１
通り）である。このように、全ての作業者名の名前情報
の組合せを一部重複を許して並べる順番を列挙する。

【０１１２】例えば、ある作業者Ｄが標準設計データで
あるファイルＤの１０文字目から２０文字目への変更を
要求した時に、その変更要求を図７の６００における順
番１−２でレビューを進めるよう選択した場合、作業者
Ｄの配送規則実行手段（５００）には、 ・（無条件で）作業者ＡにファイルＤの１０文字目から
２０文字目への変更要求を含むメッセージを発信する。 ・もし作業者ＡからファイルＤの１０文字目から２０文
字目への変更要求を含むメッセージが作業者Ｄに返送さ
れたら、作業者Ｂに同じメッセージを送る。 ・もし作業者ＢからファイルＤの１０文字目から２０文
字目への変更要求を含むメッセージが作業者Ｄに返送さ
れたら、作業者Ｃに同じメッセージを送る。 という配送規則が入力される。この配送規則に従うメッ
セージの送出要求がコミュニケーション制御手段（００
５）に送られ、メッセージ一時蓄積手段（５０２）から
ファイルＤの１０文字目から２０文字目への変更要求を
含むメッセージを順次配送することにより、このメッセ
ージはまず作業者Ａに送られ、作業者Ａによるレビュー
が終了して発信元である作業者Ｄのコミュニケーション
制御手段（００５）に返送された後で作業者Ｂに送ら
れ、最後に同様に作業者Ｂのレビュー終了後に作業者Ｃ
に送られる。

【０１１３】この例では、作業者Ｄの配送気相実行手段
（５００）が、メッセージの配送順序を集中的に制御す
るよう説明したが、例えば、作業者Ａの配送規則実行手
段（５００）・（無条件で）作業者ＢにファイルＤの１
０文字目から２０文字目への変更要求を 含むメッセー
ジを発信する。という配送規則を、同じく作業者Ｂの配
送規則実行手段（５００）には、 ・（無条件で）作業者ＣにファイルＤの１０文字目から
２０文字目への変更要求を 含むメッセージを発信す
る。 という配送規則を各々実行させて、レビューメッセージ
の制御を各作業者に分散させても、同じ順序によるレビ
ューが実現できる。

【０１１４】以上が図７の説明である。

【０１１５】また、以上説明したようなレビューの順序
について、作業者の業務負荷の評価値を算出する方法を
図面を用いて説明する。

【０１１６】図８は、図７で説明した作業者Ａ、Ｂおよ
びＣが作成を担当する設計データの参照関係を示すブロ
ック図と、その参照関係に基づいてレビュー順序の業務
負荷を算出する方法を説明するフローチャートである。

【０１１７】図８において、作業者Ａ、ＢおよびＣが作
成を担当する設計データ（モジュール）を各々モジュー
ルＡ（７００）、モジュールＢ（７０１）、モジュール
Ｃ（７０２）とし、これらがある変更要求によって影響
を受けるとする。また、各モジュールで提供する機能
（例えばソフトウェアモジュールにおけるライブラリ関
数など）を参照する他のモジュールの個数が、モジュー
ルＡへの参照（７０３）が２個、特にモジュールＢから
モジュールＡへの参照（７０６）が１個、モジュールＢ
への参照（７０４）が３個、およびモジュールＣへの参
照（７０５）が１個であるとする。

【０１１８】業務負荷を算出する際に、例えば、モジュ
ールの参照関係は、各作成担当者のレビューに関する業
務負荷を評価する手がかりの一例となる。何故なら、あ
るモジュールを参照するモジュールが多いほど、参照さ
れるモジュールを変更した場合に他のモジュールに影響
が波及する可能性が高く、各々の変更の影響をレビュー
するための負荷が高くなると予測できるためである。

【０１１９】一方、変更を受けるモジュールの集合同士
に参照関係がある場合には、参照される側のモジュール
（図８の例では７０６の参照におけるモジュールＡ）の
レビューを先に、参照する側のモジュール（図８の例で
は７０６の参照におけるモジュールＢ）を後（あるいは
次善策として同報）に回す、という別の制約が発生する
ことも予測できる。何故なら、参照する側のモジュール
は、参照される側のモジュールの変更に従属するから、
参照される側の変更を先にレビューして確定しないと、
レビューの後戻りを発生させてしまうからである。

【０１２０】少なくとも以上の二点を考慮した場合、モ
ジュール間の参照関係に基づく業務負荷の評価値を算出
する評価手続き（５０８）は、例えば次のようになる。

【０１２１】まず、評価手続き（５０８）は、レビュー
順序算出手段（５０４）から評価するレビュー順序を与
えられたとき、そのレビュー順序内の各モジュールに評
価値の初期値となる得点（例えば１０ポイント）を与え
る（ステップ７０７）。

【０１２２】次に、そのモジュールを参照する他のモジ
ュールの個数によって大きい順に整列する。図の例で
は、モジュールＢ（７０１）、モジュールＡ（７００）
→モジュールＣ（７０２）の順になる。これは、与えら
れたモジュール同士の参照による依存関係を無視したレ
ビュー順序となる（以下では「レビュー順序規準」と呼
ぶ）（ステップ７０８）。

【０１２３】次に評価手続き（５０８）は、評価するレ
ビュー順序が、 ・前記のレビュー順序規準からどの程度隔たった順序
か。 ・与えられたモジュール同士の参照関係（図では７０６
の参照）に従う順序か。を調べる。

【０１２４】即ち、あるモジュールが評価されるレビュ
ー順序内で占める位置と、同じモジュールのレビュー順
序規準内での位置との距離で、そのモジュールの評価値
を重み付けする。例えば、距離１つ毎に２倍の重みをか
けるとすると、モジュールＡ→モジュールＢ→モジュー
ルＣというレビュー順序は、モジュールＡ：１０、モジ
ュールＢ：２０、モジュールＣ：２０となる。ここでは
レビュー順序規準からのずれに対する重み付けを一定値
としたが、モジュール毎に重み付けを変えてもよい。こ
れによって、例えば特に参照の覆いモジュールがレビュ
ー順序規準からずれると評価値が極端に大きくなるよう
に操作することが出来る。（ステップ７０９）。

【０１２５】次に、与えられたモジュール同士の参照関
係に従う順序かどうかをチェックし、従わない場合はペ
ナルティに相当する重み付けを加える。例えば、モジュ
ールＢ（７０１）→モジュールＡ（７００）の順の並び
にプラス２０、両モジュールへの同報にプラス１０、の
ような重み付けを課すことが出来る（ステップ７１
０）。

【０１２６】このようにして得られた各モジュールの得
点の総和を、評価されるレビュー順序の業務負荷の評価
値とする。この例の場合、得点が小さいものほど業務負
荷の小さいレビュー順序である（ステップ７１１）。

【０１２７】ここではモジュール間の参照関係のみに着
目した業務負荷の算出方法を例示したが、他の評価の観
点として、例えば各作業者が同時に作成を担当する設計
データの個数による評価や、作業者の職制による評価
（上司になるほど後にレビューさせる）なども導入して
もよい。

【０１２８】以上が図８の説明である。

【０１２９】次に、レビュー履歴収集手段（００６）に
おいて、複数の変更要求に対するレビューメッセージを
同時並行的に収集する際に、その収集結果を作業者に対
して分かりやすく整理して提示する方式について、以下
で図面を用いて詳細に説明する。

【０１３０】図９は、各作業者のレビューを同じ変更要
求箇所ごとに分別して蓄積し、その結果を表示する方式
の実施例を示すブロック図である。

【０１３１】図９において、レビュー履歴分別手段（８
００）は、レビューメッセージに含まれる特定の変更要
求箇所と、レビューメッセージを格納するレビュー履歴
データベース（８０１）とを対応付けて管理する。レビ
ュー履歴収集手段（００６）は、並行設計に参加する全
ての作業者からレビューメッセージを収集するので、レ
ビュー履歴データベース（８０１）も、共有データベー
ス（００１）と同じデータベース上に構成できるが、別
の格納手段を用いても構わない。

【０１３２】特定レビュー選択手段（８０２）は、作業
者のコミュニケーション制御手段（００５）がコミュニ
ケーション手段（００７）からレビューメッセージを受
け取った時に、まず、そのメッセージに含まれる変更要
求の変更要求箇所を特定する。次に、特定レビュー選択
手段（８０２）は、レビュー履歴分別手段（８００）が
先の変更要求箇所に対応するレビュー履歴データベース
（８０１）を持っている場合は、そこに前記メッセージ
を追加する。持っていなければ、レビュー履歴分別手段
（８００）にレビュー履歴データベース（８０１）を新
規生成させて前記のメッセージを格納し、先の変更要求
箇所と対応付ける。その結果、一つのレビュー履歴デー
タベース（８０１）には、同じ変更要求箇所に関する異
なるレビューメッセージが順次蓄積していくことにな
る。

【０１３３】レビュー履歴データベース（８０１）に蓄
積されたメッセージの集合は、例えば格納された順に蓄
積していくだけでなく、更にその中で特定の観点から分
別されたり関係付けを加えられても構わない。例えば、
コミュニケーション手段（００７）が実時間の通信手段
を用いてレビューメッセージをやりとりしている場合、
ある作業者が編集を開始してから終了するまでの間に、
その作業者から連続的に同じ変更箇所に対する変更要求
を含むレビューメッセージが到着することになる。従っ
てこの場合、一連のレビューメッセージをレビュー履歴
データベース（８０１）の中で更に作業者ごとに分別し
ておけば、各作業者が加えた一連の変更の過程を忠実に
保存することが出来る。

【０１３４】作業者は、任意の時点でレビュー履歴分別
手段（８００）が管理するレビュー履歴データベース
（８０１）の集合をレビュー履歴表示手段（８０３）で
表示させる。レビュー履歴表示手段（８０３）は、個々
のレビュー履歴データベース（８０１）の存在およびそ
の中の個々のメッセージのリストを、作業者の画面上で
例えばアイコンによる表示によって示す。これによって
作業者は、複数の変更要求箇所についてレビューが並行
して進められても、そのメッセージを自動的に分類して
分かりやすく閲覧することが出来る。

【０１３５】一方、特定レビュー選択手段（８０２）が
レビューメッセージを受け取った時、作業者は、そのメ
ッセージに含まれる変更要求箇所について過去にどのよ
うなレビューがなされてきたかを参照して、自分のレビ
ュー内容を考える下地とする必要が生じる。すなわち、
レビュー履歴表示手段（８０３）に表示されている複数
のレビュー履歴データベース（８０１）から、現在対象
とするレビューメッセージと同じ変更要求箇所に関する
ものを選択して閲覧しなければならない。

【０１３６】このために、特定レビュー選択手段（８０
２）は、コミュニケーション制御手段（００５）が受け
取ったレビューメッセージから、その中に含まれる変更
要求の変更要求箇所を特定し、レビュー履歴分別手段
（８００）が管理する変更要求箇所とレビュー履歴デー
タベース（８０１）との対応を用いて、前記メッセージ
に含まれる変更要求箇所に対応しているレビュー履歴デ
ータベース（８０１）を検索する。

【０１３７】更にレビュー履歴検索手段（８０４）は、
検索されたレビュー履歴データベース（８０１）をレビ
ュー履歴表示手段（８０３）の上で、例えばアイコンに
よる表示の色や形状を変えることで特定し、利用者に知
らせる。

【０１３８】このようにして、複数の変更要求に対する
レビューメッセージを同時並行的に収集する際に、各レ
ビューメッセージに含まれる特定の変更要求箇所ごとに
分別して収集・表示することで、レビュー履歴を作業者
に対して分かりやすく整理して提示することができる。

【０１３９】以上が図９の説明である。

【０１４０】以上説明したレビュー履歴表示手段（８０
３）で、変更要求箇所ごとのレビュー履歴が作業者に対
してどのように表示されるかを、ここで図を用いて説明
する。

【０１４１】図１０は、レビュー履歴表示手段（８０
３）の表示画面例である。

【０１４２】図１０において、レビュー履歴リスト（９
００）は、レビュー履歴分別手段（８００）が管理する
全てのレビュー履歴データベース（８０１）を列挙する
ウィンドウである。ウィンドウの中には、レビュー履歴
データベース（８０１）に１対１対応で割り当てられる
レビュー履歴アイコン（９０１）と、各レビュー履歴デ
ータベース（８０１）が収集している特定の変更要求箇
所や累積しているメッセージの数などの詳細情報を提示
するレビュー履歴情報（９０２）を含む。これらによっ
て作業者は、特定の変更箇所に対するレビュー履歴の存
在とその詳細情報を視覚的に把握できる。

【０１４３】更に、レビュー履歴検索手段（８０４）が
特定の変更要求箇所に対するレビュー履歴データベース
（８０１）を検索すると、対応するレビュー履歴アイコ
ン（９０１）は選択状態となる。同様の選択操作は、作
業者がマウスなどの指示入力手段でレビュー履歴アイコ
ン（９０１）を指示することによっても実現できる。選
択されたレビュー履歴アイコン（９０３）は、画面上で
表示の色や形状を変えて表示される。これによって作業
者は、特定のレビュー履歴データベース（８０１）およ
び対応するレビュー履歴アイコン（９０１）を、他のも
のと視覚的に区別することが出来る。

【０１４４】レビューメッセージリスト（９０４）は、
選択されたレビュー履歴アイコン（９０３）に対応する
レビュー履歴データベース（８０１）内のレビューメッ
セージを列挙するウィンドウである。ウィンドウの中に
は、レビューメッセージに１対１対応で割り当てられる
レビューメッセージアイコン（９０４）と、各レビュー
メッセージの作成者や作成日時などの詳細情報を提示す
るレビューメッセージ情報（９０６）を含む。これらに
よって作業者は、特定の変更箇所に対する過去のレビュ
ーメッセージの存在とその詳細情報を視覚的に把握でき
る。

【０１４５】以上が図１０の説明である。

【０１４６】次に、レビュー履歴収集手段（００６）で
収集された複数のレビューメッセージから、設計データ
に反映させるための変更要求を決定する際に、メッセー
ジ内の変更要求を選択し評価する方式について、以下で
図面を用いて詳細に説明する。

【０１４７】図１１は、任意の作業者から寄せられたレ
ビューに含まれる変更要求を様々な観点から検討して、
設計データに反映させる方式の一実施例を示すブロック
図である。

【０１４８】図１１において、並行設計に参加する作業
者は、レビュー履歴収集手段（００６）に収集されたレ
ビューメッセージの蓄積から、レビュー履歴選択手段
（１００１）を用いて、任意のメッセージを選択する。
作業者が選択を行うためのユーザインタフェースは、例
えば、画面上に示されたメッセージのアイコンをマウス
などの指示入力装置で指示することで実現できる。

【０１４９】次いで、レビュー履歴収集手段（００６）
が選択されたメッセージを検索し、そのメッセージに含
まれる変更要求を取得して、レビュー結果評価手段（１
０００）に送られる。同じ変更要求がレビュー支援シス
テム（０００）にも送られる。

【０１５０】レビュー支援システム（０００）は、先に
選択されたメッセージに含まれる変更要求を、その変更
要求が加えられた標準設計データのコピーを共有データ
ベース（００１）から取得する。更に、その変更要求が
変更差分を含むなら、変更要求箇所を変更差分で置き換
え、コメントを含むなら、例えば変更箇所に相当するデ
ータ内容を選択状態とする。その結果、他の作業者が作
成した標準設計データも影響を受けて変更されるので、
その変更後の標準設計データのコピーを共有データベー
ス（００１）から全て取得する。

【０１５１】レビュー結果評価手段（１０００）は、変
更の影響を受けた標準設計データの各々を設計データ表
現形式変換手段（００３）に引き渡し、特定の設計デー
タ編集手段（００２）に固有の設計データ表現に変換さ
せ、変換後の設計データを対応する設計データ編集手段
（００２）を用いて表示させる。表示させる標準設計デ
ータおよび表示に用いる設計データ編集手段（００２）
は、作業者が任意に選択する。これによって、ある変更
要求を実施した時の影響を、設計上の様々な観点から評
価することができる。

【０１５２】レビュー結果決定手段（１００２）は、レ
ビュー履歴選択手段（１００１）が現在選択しているレ
ビューメッセージが最終的なレビュー結果であることを
決定するための指示を入力する。最終的なレビュー結果
となったレビューメッセージは、他の決定されなかった
メッセージとの違いを識別させるために、作業者の画面
上で、例えばメッセージのアイコンの形状や色を変える
などして区別して表示される。

【０１５３】最後に、レビュー結果決定手段（１００
２）は、決定されたレビューメッセージに含まれる変更
要求をレビュー支援システム（０００）に送る。レビュ
ー支援システム（０００）は、その変更要求が変更差分
を含む場合、その変更要求箇所と変更差分とを置換した
標準設計データのコピーを作成し、前記の変更要求を加
えられた標準設計データに変わる新しい版として共有デ
ータベース（００１）に正式に登録する。

【０１５４】このようにして、ある変更要求に影響され
る設計データを任意の設計データ編集手段（００２）を
選んで表示させることによって、複数の作業者の要求を
平等かつ直感的に評価した上で、設計データに反映させ
ることが出来る。

【０１５５】以上が図１１の説明である。

【０１５６】ここで、収集されたレビューメッセージの
中から、最終的に設計データに反映させる変更要求をど
のように選択し意思決定するかを、図面を用いて説明す
る。

【０１５７】図１２は、レビュー履歴収集手段（００
６）において、収集されたレビューメッセージの選択・
評価・意思決定を行う表示画面例である。

【０１５８】図１２において、レビュー履歴評価ウィン
ドウ（１１００）は、レビューメッセージの存在を示す
レビューメッセージアイコン（１１０１）と、あるレビ
ューメッセージに含まれる変更要求に影響を受ける標準
設計データの存在を示す標準設計データアイコン（１１
０２）と、前記の標準設計データの変更後の状態を評価
するための設計データ編集手段（００２）を選択するツ
ール選択メニュー（１１０３）と、最終的なレビュー結
果を選択するレビュー結果決定ボタン（１１０６）とを
含むウィンドウである。このウィンドウは、先に説明し
たレビュー履歴リスト（９０３）と同一であっても、異
なっていても構わない。

【０１５９】作業者がマウスなどの指示入力手段を用い
て、任意のレビューメッセージアイコン（１１０１）を
選択すると、レビュー履歴評価ウィンドウ（１１００）
は、選択したレビューメッセージアイコン（１１０１）
に対応するレビューメッセージ内の変更要求に影響され
る標準設計データの集合を、標準設計データアイコン
（１１０２）の並びで表示する。

【０１６０】作業者が任意の標準設計データアイコン
（１１０２）を選択し、更に、選択した標準設計データ
を表示させたい設計データ編集手段（００２）をツール
選択メニュー（１１０３）から選択すると、選択したツ
ール選択メニュー（１１０３）に対応する設計データ編
集手段（００２）に、選択した標準設計データに対応す
る変更要求実施後の設計データが表示される。図１２で
は、機械系製品の部品ファイルであるファイルＢの変更
について、形状設計ツール（１１０４）および価格表ツ
ール（１１０５）で表示している（点線部分を変更要求
箇所とする）ところを示している。

【０１６１】選択されたレビューメッセージ内の変更要
求に影響される標準設計データを全て評価して、いずれ
にも問題が無ければ、レビュー結果決定ボタン（１１０
６）をマウスなどの指示入力手段を用いて選択すること
により、選択されたレビューメッセージを最終的なレビ
ュー結果として決定する。決定後は、図１２に示したよ
うに、決定されたレビューメッセージアイコン（１１０
１）の色や形状などを変化させて、最終的なレビュー結
果であることが分かるように強調表示する。

【０１６２】以上が図１２の説明である。

【０１６３】

【発明の効果】以上説明したように、本発明の並行設計
管理システムは、各作業者がレビューを行う際に、設計
データの変更箇所や影響を受ける箇所を、設計データの
表示・編集ツールの相違に依らずに互いに交換し、各作
業者が変更要求に対するレビューを行う際のコミュニケ
ーションにおいて、レビューに用いるメッセージを送信
する適切な配送先とタイミングを設定し、並行して進め
られるレビューのコミュニケーションに対して、その履
歴を分かりやすく分類・蓄積して各作業者に表示し、任
意の作業者から寄せられたレビューに含まれる変更要求
を様々な観点から検討して、設計データに反映させるこ
とによって、並行設計に参加する作業者が任意の設計デ
ータ編集ツールを用いて作成した変更要求を、滞ること
なくレビューし、またそのレビュー過程が同時並行的に
進行しても、その履歴を整理して、かつ作業者が多様な
レビューを的確に評価することを可能にする。

【図面の簡単な説明】

【図１】本発明の並行設計管理システムの一実施例を示
すブロック図である。

【図２】本発明の並行設計管理システムによって、複数
の作業者で並行設計を行う過程を説明するフローチャー
トである。

【図３】標準設計データと設計データ編集手段固有のデ
ータ表現との間のデータ変換の例を示すブロック図およ
び画面例である。

【図４】標準設計データモデルの構成要素間の関係記述
を示す摸式図である。

【図５】各作業者の用いる設計データ編集手段と標準設
計データとの変換規則を選択する方式の一実施例を説明
するブロック図である。

【図６】各作業者がレビューに用いるメッセージを送信
する適切なタイミングと配送先を設定する方式の一実施
例を示すブロック図である。

【図７】作業者Ａ、Ｂ、Ｃの３人に対してレビューメッ
セージを一部重複を許して順次配布する際の、可能な送
信順序の全てを示す摸式図である。

【図８】作業者Ａ、ＢおよびＣが作成を担当する設計デ
ータの参照関係を示すブロック図と、その参照関係に基
づいてレビュー順序の業務負荷を算出する方法を説明す
るフローチャートである。

【図９】各作業者のレビューを同じ変更要求箇所ごとに
分別・蓄積した結果を表示する方式の一実施例を示すブ
ロック図である。

【図１０】収集したレビュー履歴を作業者に表示する表
示画面例である。

【図１１】任意の作業者からのレビューに含まれる変更
要求を様々な観点から検討して、設計データに反映させ
る方式の一実施例を示すブロック図である。

【図１２】収集されたレビューメッセージの選択・評価
・意思決定を行う表示画面例である。

【符号の説明】

０００ レビュー支援システム ００１ 共有データベース ００２ 設計データ編集手段 ００３ 設計データ表現形式変換手段 ００４ 変更要求通知手段 ００５ コミュニケーション制御手段 ００６ レビュー履歴収集手段 ００７ コミュニケーション手段 ２００ 形状設計ツール ２０１ 価格表ツール ２０２ 構成管理ツール ２０３ 形状データ記述 ２０４ 部品価格データ記述 ２０５ 構成データ記述 ２０６ 表現形式変換規則 ２０７ 標準設計データモデル ２０８ 標準設計データ ３００ 形状設計ツール ３０３ 部品Ａの構成要素 ３０４ 部品Ｂの構成要素 ３０５ 制約 ３０６ 制約解消手段 ４００ 設計データ任意選択手段 ４０１ 作業者指示手段 ４０２ 設計データデフォルト選択手段 ４０６ 表現形式変換規則 ５００ 配送規則実行手段 ５０１ 配送規則設定手段 ５０２ メッセージ一時蓄積手段 ５０３ 変更影響範囲特定手段 ５０４ レビュー順序算出手段 ５０５ レビュー順序選択手段 ５０６ レビュー順序設定手段 ５０７ レビューコスト評価手段 ５０８ 評価手続き ８００ レビュー履歴分別手段 ８０１ レビュー履歴データベース ８０２ 特定レビュー選択手段 ８０３ レビュー履歴表示手段 ８０４ レビュー履歴検索手段 １０００ レビュー結果評価手段 １００１ レビュー結果選択手段 １００２ レビュー結果決定手段

Claims (8)

(57)【特許請求の範囲】
1. 【請求項１】ネットワーク化された計算機上で、複数の
   作業者が共同して製品等の設計を行うために、各々の作
   業者が作成した設計データを共有し、作業者間で並行設
   計を進める過程を管理する並行設計管理システムにおい
   て、 各々の作業者が前記設計データを固有のデータ表現形式
   に基づいて編集を行う設計データ編集手段と、 前記設計データ編集手段が必要とする前記製品等の構成
   要素の各種属性記述（形状／価格データ、機能定義等）
   と前記要素間の関係記述とを全て含んだ標準的なデータ
   表現形式で記述される標準設計データと、前記固有のデ
   ータ標準形式による設計データとを相互に変換する設計
   データ表現形式変換手段と、 前記標準設計データを格納し共有する共有データベース
   と、 前記設計データ編集手段および設計データ表現形式変換
   手段を用いて、前記標準設計データの任意の箇所に対し
   て作業者が変更あるいはコメントを加えた際に、前記標
   準設計データの前記変更を要求する前の版との比較によ
   って、前記箇所の変更差分あるいはコメントを識別し、
   前記任意の箇所と前記識別された変更差分あるいはコメ
   ントとの組からなる変更要求を構成するレビュー支援シ
   ステムと、 前記変更要求の実施によって影響を受ける可能性のある
   前記標準設計データの集合である変更要求範囲を前記共
   有データベース内で特定し、前記標準設計データの作成
   者に前記変更要求を通知する変更要求通知手段と、 前記作業者が与えた変更要求を含むレビューメッセージ
   の送出と受信を制御するコミュニケーション制御手段
   と、 前記複数の作業者間でやりとりした一連のレビューメッ
   セージを収集・表示するレビュー履歴収集手段とを有す
   ることを特徴とする並行設計管理システム。
2. 【請求項２】前記設計データ表現形式変換手段が、設計
   に参加する作業者と、各作業者が利用するデフォルトの
   設計データ編集手段とを対応付ける設計データデフォル
   ト選択手段と、前記作業者が変更要求の対象となった標
   準設計データを表示・編集する設計データ編集手段を任
   意に指定する設計データ任意選択手段とを有することを
   特徴とする請求項１の並行設計管理システム。
3. 【請求項３】前記コミュニケーション制御手段が、送出
   前のメッセージを一時的に蓄積するメッセージ一時蓄積
   手段と、前記コミュニケーション制御手段が送出するメ
   ッセージの配送先（アドレス）とタイミングを決める規
   則である配送規則を設定する配送規則設定手段と、前記
   配送規則を解釈して、前記メッセージ一時蓄積手段に蓄
   積されたメッセージを配送するよう指示を出す配送規則
   実行手段とを有することを特徴とする請求項１または２
   の並行設計管理システム。
4. 【請求項４】前記変更要求通知手段が、レビュー開始の
   ためのメッセージを通知する全ての可能な順序を算出す
   るレビュー順序算出手段と、前記レビュー順序算出手段
   が導出したレビュー順序の一つを選択するレビュー順序
   選択手段と、前記レビュー順序選択手段が選択した順序
   に基づいて、メッセージを配送するような配送規則を生
   成するレビュー順序設定手段を有することを特徴とする
   請求項３の並行設計管理システム。
5. 【請求項５】前記レビュー順序算出手段が、算出した順
   序の各々に対して、前記順序でレビューを行う際のレビ
   ュー参加者の業務負荷の予測値であるレビューコストを
   評価するレビューコスト評価手段を有し、 前記レビュー順序選択手段が、前記レビューコストを最
   小にする順序を選択することを特徴とする請求項４の並
   行設計管理システム。
6. 【請求項６】前記レビュー履歴収集手段が、レビューの
   参加者がやりとりするメッセージのうち、特定の変更要
   求箇所に対する変更要求を含むものを選択する特定レビ
   ュー選択手段と、前記特定の変更要求箇所ごとに選択さ
   れたメッセージ群であるレビュー履歴を一まとめにして
   蓄積するレビュー履歴分別手段と、 蓄積された前記レビュー履歴を、前記特定の変更要求箇
   所ごとに各作業者の画面上に表示するレビュー履歴表示
   手段とを有することを特徴とする請求項１の並行設計管
   理システム。
7. 【請求項７】前記レビュー履歴表示手段が、特定の作業
   者が受信したメッセージの中で参照されている変更要求
   について、同じ変更要求箇所に対するレビュー履歴のま
   とまりを前記作業者の画面上で特定する特定レビュー履
   歴検索手段とを有することを特徴とする請求項６の並行
   設計管理システム。
8. 【請求項８】前記レビュー履歴収集手段が、特定の変更
   要求箇所に対して収集・蓄積されたメッセージの一つを
   作業者が選択するレビュー履歴選択手段と、前記選択さ
   れたメッセージが参照する変更要求について、前記変更
   要求置換手段が置換した変更後の標準設計データのコピ
   ーを任意の前記設計データ編集手段によって表示するレ
   ビュー結果評価手段と、任意の作業者がレビュー履歴の
   中の一つのメッセージをレビュー結果として決定し、前
   記メッセージを他のメッセージと区別して各作業者の画
   面に表示させるレビュー結果決定手段とを有することを
   特徴とする請求項６または７の並行設計管理システム。