JPH08106494A - 開発支援システム - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】新製品の開発を支援して、複数の開発担当者の
協調作業環境。 【構成】製品のモデル、製品開発に使用する資源のモデ
ルを格納するリソースモデル、及び製品開発の活動のモ
デルを格納する手段、製品の開発日程、原価、性能の目
標値を格納する手段、前記各モデルから、開発日程、原
価及び性能の予想値を推定する手段、各開発担当者によ
る前記各モデル、各目標値及び各予想値の参照、変更並
びに詳細化を支援する手段、並びに各モデルの変更、詳
細化が行なわれた場合に、前記予想値が対応する目標値
を満足するか否かを判定し、満足しない場合にはその旨
を利用者に通知する手段を有し、開発に必須な業務処理
の電子メールの中から開発進捗に係る情報をモニタリン
グして、進捗管理情報として格納し、各開発者に進捗情
報を提供する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、企業や工場等において
用いられる、新製品の開発を支援する開発支援システム
に関し、特に、複数の開発担当者の協調作業環境を提供
する開発支援システムに関するものである。

【０００２】

【従来の技術】従来，複数の利用者による協調作業を支
援するシステムとしては、例えば、特開平３−２５０３
６５号公報記載のシステムが知られている。

【０００３】このシステムによれば、例えば、複数人が
グル−プとして行っている業務の段階段階において、複
数の情報処理装置を用いて離れた場所から会議を行い、
それぞれが別個に行ってきた各作業の状況を把握し、こ
の結果を踏まえて、それぞれの作業に戻ることができ
る。

【０００４】また、その他の従来の開発を管理するシス
テムとしては、例えば、特開平４−３６４５２９号公報
記載のシステムが知られている。この従来技術では、複
数の開発者によるソフトウェアの開発において、開発者
間の通信に使用する電文（電子メール）に、各モジュー
ル開発に係わる内容、即ち命令コード項目、プロジェク
ト名項目、作業コード項目、作業データ項目、依頼元項
目、依頼先項目、期間項目、優先度項目を設け、これら
の開発管理情報を含む電子メールを交換することで、ソ
フトウエアの開発管理を行うものである。

【０００５】このようなシステムによれば、電子メール
を用いるので、連絡相手の都合に左右されることなく、
開発に係わる事項を通知することができ、更に文書等の
印刷物を用意する必要のない開発管理が行える。

【０００６】

【発明が解決しようとする課題】ところで、ある新製品
を開発する開発プロジェクトは、プロジェクトの各段階
で、開発プロジェクト全体の目標値、開発プロジェクト
全体の進行予想値、プロジェクト各作業の目標値、プロ
ジェクト各作業の進行予想値を、相互に整合させながら
実施する必要がある。

【０００７】しかし、前述した第１の従来の支援システ
ムにおける単なる情報交換による協調作業の支援では、
このような整合性は、全て利用者自身が管理せねばなら
ない。

【０００８】このため、このような従来の支援システム
を用いても、開発製品の性能、原価、日程等の目標達成
の管理等に利用者が払わなければならない負担を充分に
軽減することができない。

【０００９】すなわち、従来の支援システムでは、この
うな開発プロジェクト全体および部分の目標値および進
行予想値、相互の整合性管理を充分に支援しているとは
いえない。

【００１０】また、前述した第２の従来システムでは、
前記開発管理のための電文のやり取りが必要となり、こ
の電文のやり取りがないと、開発管理がまったく行えな
くなる。また、開発者が進捗の実態と異なる報告をして
も、それをチェックする機能を有していない。

【００１１】そこで、本発明は、製品開発の開発プロジ
ェクト全体および部分の目標値および進行予測値、相互
の整合性管理を支援することのできる開発支援システム
を提供することを第１の目的とする。

【００１２】また、本発明は、特に開発管理のための電
文のやり取りを行なわなくても、開発者に負担をかけ
ず、かつ、客観的に進捗状況をモニタリングできる開発
進捗モニタリング手段を提供することを第２の目的とす
る。

【００１３】

【課題を解決するための手段】前記第１の目的達成のた
めに、本発明は、複数の開発担当者による製品の開発を
支援するシステムであって、製品のモデルと、製品開発
に使用する資源のモデルを格納するリソースモデルと、
製品開発の活動のモデルとを格納する手段と、製品の原
価、性能、開発日程の全体の目標値と個々の部分の目標
値を格納する手段と、前記各モデルから、原価、性能、
開発日程の進行予想値を推定する手段と、各開発担当者
による、前記各モデルと各目標値と各進行予想値の参照
を支援する手段と、開発担当者による前記各モデルの変
更、詳細化を支援する手段と、各モデルの変更、詳細化
が行われた場合に、前記各進行予想値が、対応する目標
値を満足するか否かを判定し、少なくとも満足しない場
合には、その旨を利用者に通知する手段とを有すること
を特徴とする開発支援システムを提供する。

【００１４】また、前記第１の目的達成のために、本発
明は、複数の開発担当者による製品の開発を支援するシ
ステムであって、製品のモデルと、製品開発に使用する
資源のモデルを格納するリソースモデルと、製品開発の
活動のモデルとを格納する手段と、製品の原価、性能、
開発日程の全体の目標値と個々の部分の目標値を格納す
る手段と、前記各モデルから、原価、性能、開発日程の
進行予想値を推定する手段と、各開発担当者による、前
記各モデルと各目標値と各進行予想値の参照を支援する
手段と、開発担当者による前記各モデルの変更、詳細化
を支援する手段と、開発担当者による前記各目標値の変
更、詳細化を支援する手段と、目標値の変更、詳細化が
行われた場合に、全体目標値と部分目標値の整合性を評
価し、少なくとも不整合である場合に、利用者に、その
旨を通知する手段とを有することを特徴とする開発支援
システムを提供する。

【００１５】また、上記第２の目的は、製品の開発に係
る複数の担当者が、互いに電子的な情報を送受信して、
前記製品の開発に係る業務に伴い生じる複数の処理を順
次完了する前記製品の開発作業を、支援するシステムに
おける、前記製品の開発進捗状況をモニタリングする開
発進捗モニタリング手段であって、前記電子的な情報を
送受信して行なわれる前記複数の処理のそれぞれに対応
する複数の項目を設け、そのうちの１以上の項目を、前
記製品の開発進捗の指標となる進捗管理項目として格納
する進捗管理項目格納部と、前記電子的な情報に含まれ
る、前記進捗管理項目についての情報を抽出する進捗管
理情報モニタリング部と、前記抽出された情報を、進捗
管理情報として格納する進捗管理情報格納部と、前記格
納されている進捗管理情報を参照するための進捗管理情
報参照部とを有することを特徴とする開発進捗モニタリ
ング手段により達成される。

【００１６】

【作用】本発明に係る開発支援システムによれば、各モ
デルの変更、詳細化が行われた場合に、前記各進行予想
値が、対応する目標値を満足するか否かを判定し、少な
くとも満足しない場合には、その旨を利用者に通知す
る。

【００１７】また、目標値の変更、詳細化が行われた場
合には、全体目標値と部分目標値の整合性を評価し、少
なくとも不整合である場合に、利用者に、その旨を通知
する。したがって、製品開発の各担当者は、開発の当初
においては詳細が決定していない開発計画を、開発の進
展に伴って詳細化しながら、設計結果から客観的に得ら
れる全体および個々の作業の進行予想値と目標値との整
合性、全体の作業の目標値と個々の作業の目標値との整
合性を確認しながら、目標達成に対する最適な計画を立
てることができる。

【００１８】更に、本発明による開発進捗モニタリング
手段においては、前記のような開発に係る担当者が送受
信する情報の中から、自動的に開発進捗に係わる情報で
ある、前記進捗管理項目に関する情報をモニタリング
し、その情報を進捗管理情報格納部に格納する。この格
納されている進捗管理情報を各開発担当者もしくは開発
進捗管理者が参照することで、開発の進捗状況を把握す
ることができる。

【００１９】このように進捗管理項目に関する情報は、
特に開発管理のための電文をやり取りすることによって
得るものではないので、開発管理のために特別な工数を
要するということはない。また、この情報は、開発に必
須な業務処理に係わる電子メールからモニタリングされ
るので、進捗の実態と異なることもなく、新たに工数を
かけずとも、客観的に進捗状況をモニタリングすること
ができる。

【００２０】

【実施例】以下、本発明に係る開発支援システムの一実
施例を説明する。

【００２１】本実施例では、開発支援システムの利用者
として、開発管理者、機械設計者、電気設計者、試作品
製作者、試作品試験者等の開発メンバを想定する。

【００２２】図１に、本実施例に係る開発支援システム
の構成を示す。

【００２３】図中、１０００は各開発メンバがそれぞれ
使用するクライアントマシン、２０００は各クライアン
トマシン１０００の要求に応じて処理を行うサ−バマシ
ンである。

【００２４】各クライアントマシン１０００は、開発メ
ンバが、製品モデル、開発活動モデル、リソースモデル
を作成する際に使用するモデル作成部１を備えており、
作成されたモデルは、それぞれ、サ−バマシン２０００
の、２の製品モデル格納部、３の開発活動モデル格納
部、４のリソースモデル格納部に格納される。

【００２５】尚、製品モデルには製品の構造、属性、特
性等が記述される。また、開発活動モデルには開発全体
の活動を部分的な活動に分割した活動単位毎に、活動単
位間の先行関係や活動の予定と実績等が記述される。そ
して、リソースモデルには試作品の製造設備や試験設備
など開発に要する設備の能力や開発従事者の情報が記述
される。開発活動モデルは，図２に示すように，その活
動に関する製品モデルとリソースモデルをリンクしてい
る。

【００２６】次に、サ−バマシン２０００中の、５は開
発活動モデルがリンクした製品モデルから原価を推定す
る原価推定部、６は開発活動モデルがリンクした製品モ
デルから性能を推定する性能推定部、７は開発活動モデ
ルの単位毎に開発作業量とリソースから開発日程を推定
する日程推定部であり、これらが推定した推定値は８の
推定値格納部に格納される。尚，各推定値は，各々原価
推定値格納部８１，性能推定値格納部８２，日程推定値
格納部８３に格納される。

【００２７】また、原価、性能、日程の目標値が１２の
目標値格納部に格納される。この目標値は、開発当初に
おいて企画・構想の結果として、１３の目標値割付部を
用いて決定され、目標値格納部１２に格納される。

【００２８】目標値格納部１２に格納された目標値は開
発の進行に伴って変更されたり詳細化されたりする。こ
の変更や詳細化は、各開発メンバの協議や判断によって
行われるが、これらの協議や判断と、これに基づく目標
値の変更や詳細化を管理するのが１１のコミュニケーシ
ョン管理部である。

【００２９】この目標値と先に述べた原価、性能、日程
の推定値は一致するとは限らないが、目標値に一致する
ように開発活動は管理されねばならない。

【００３０】このような管理を実現するため、推定値・
目標値レビュー部９は、推定値と目標値の差異をチェッ
クし、これをクライアントマシン１０００を介して開発
メンバに知らせたり参照できるようにする。また、目標
値は種々のレベルの部分的目標値があり、これら部分的
な値と全体の値は整合がとれていなければならない。全
体・部分整合性維持部１０は、この整合性をチェック
し、整合性がくずれる場合はクライアントマシン１００
０を介して開発メンバに知らせ、整合性をくずす目標値
の変更を行わないようにする。

【００３１】次に図２に、開発活動モデル格納部３に格
納される開発活動モデルの構成例を示す。

【００３２】図２に示すように、開発活動モデル格納部
３に格納される開発活動モデルは、活動単位と、その先
行関係をグラフで表現したものである。

【００３３】また、各活動単位には、例えば、図示する
ように開発活動名称、開発活動の責任担当者、開発活動
の制約条件、開発活動に使用するリソースモデル、開発
活動の時に参照する製品モデル、開発活動の結果を示す
製品モデル、活動の開始および終了時期の予定値と実績
値等を記述する。

【００３４】このように開発活動モデルには、開発活動
の予定と実績が開発活動の単位で示されるが、この予定
は開発の進行に伴って詳細化され、また変更も生じる。
これは、製品開発が多くの不確定要素を含む活動である
ことから必然的に生じることである。そこで、本開発支
援システムは、開発活動モデルの内容が変更された場合
に、その日程、原価、性能に対する影響を以下の実施例
に示すように推定し、目標値との関係を各開発メンバに
連絡する。

【００３５】これにより、各開発メンバは、開発活動モ
デルの変更の影響が容易に把握評価でき、各時点での見
通しに基づいて、各目標値を満足する開発完了までの計
画を立て、開発活動モデルに記述することができる。

【００３６】以下、原価、性能、日程の各々について、
これらの目標値と推定値が整合するように管理しなが
ら、各開発メンバが協調して開発を進める場合を例にと
り、本実施例に係る開発支援システムの動作を説明す
る。

【００３７】まず、開発日程を管理しながら開発を進め
る場合の動作について説明する。

【００３８】まず、目標値割付部１３の中の日程割付部
３２０が開発開始時における日程目標を目標値格納部に
設定する。この目標値設定は、新製品の企画・構想担当
が、新製品の発売時期を定める。そして、日程割付部３
２０は、従来の開発実績等のデータを入力し、これを参
考にして、定められた開発時期を実現するのに必要な開
発活動の単位毎に日程割付を行う。

【００３９】この後、図６に示すように、例えば、機械
電気等の設計担当者は、開発活動モデルで示される自分
の担当部分の設計を行い、設計結果を製品モデル格納部
２に格納すると共に、設計中および未着手の開発活動に
関しても作業量を推定して活動計画を開発活動モデルに
設定する６０１。

【００４０】また、設計担当者だけでなく、試作、試験
の担当者も、開発活動モデルで示される各々の担当部分
の作業結果を製品モデル格納部２に格納したり、作業中
および未着手の開発活動に関して作業量を推定して活動
計画を開発活動モデルに設定したり、開発に使用できる
設備や人員等のリソースデータをリソースモデル格納部
４に格納する６０２。

【００４１】この開発活動モデルから日程推定部７はそ
の時点の開発進行状況と、残りの開発作業量を把握し６
０３、リソースモデル格納部４に格納されている開発設
備や人員のデータを用いて、以降の開発日程を推定し、
日程推定値を推定値格納部８に格納する６０４。

【００４２】ここで、日程推定部７の計算方式について
図８を用いて説明する。図８は日程推定部７の計算手順
を表すフローチャートである。日程推定部７では、ま
ず、開発活動モデル格納部３より対象プロジェクトの現
状の日程データの取得を行なう８０１。次に、リソース
に関する情報をリソースモデル格納部４より取得する８
０２。次に、進捗度の計算を行なうが８０４、本発明に
おいては、図９に示したような進捗度の定義を使用して
残りの工数を推定する。図９に示した２つの指標は実施
項目の終了状況の統計的分析による残りの工数を推定す
るものである８０５。指標１は，推定時点までに終了し
た実施項目と，それに要した工数から残りの工数を推定
する指標であり，指標２は，推定時点までに解決した問
題と，それに要した工数から残りの工数を推定する指標
である。ここで問題とは、プロジェクトの進行を阻害す
るような問題であり、例えば新製品の開発過程での試作
機の試験工程においては、試作機に発生した種々のトラ
ブル等である。尚，指標１は、プロジェクトの開始時に
は分母が０の特異点があり，指標２も解決問題数が０の
とき特異点があるが，これを避ける処理によりプロジェ
クト全般において日程推定をすることができる。

【００４３】推定値・目標値レビュー部９は、日程推定
値とそれに対応する日程目標値を比較し６０５、その情
報を開発メンバが参照できるようにする。

【００４４】このようにして作業が進み、日程推定値が
日程目標値を達成できないことが判明した場合、推定値
・目標値レビュー部９は、この情報を開発メンバに伝え
対策を要求する６０６。

【００４５】図１０は推定値・目標値レビュー部９の上
記処理の手順を表したフローチャートである。推定値・
目標値レビュー部９は、まず日程推定値格納部８３から
終了推定値を取得する１００１。次に、日程目標値格納
部１２３から終了目標値を取得する１００２。次に、こ
れらの差を計算し１００３、遅れの値があらかじめ定め
られたしきい値を越えている場合には警告のメッセージ
を生成する１００５。この警告メッセージにはメッセー
ジの送付先データも付加している。このように、推定値
・目標値レビュー部によれば、プロジェクトの進行途中
で、問題のある日程計画が即座にビジュアル化され、早
期の対策が可能となる。

【００４６】対策としては、目標達成の上でネックとな
っている開発活動の順序の変更や開発リソースの増強等
がある。いずれの場合も、他の開発活動に影響するの
で、開発メンバの協議６０７が必要となる。コミュニケ
ーション管理部１１は、協議された内容に基づき、目標
値格納部１２の目標値を変更したり、リソ−スモデルや
開発活動モデルを変更する６０８。日程推定部７は、変
更された開発活動モデルから、以降の開発日程を再推定
し、日程推定値を推定値格納部８に格納する。

【００４７】一方、協議および判断され目標値格納部１
２に反映された内容は、全体・部分整合性維持部１０が
評価する。そして、推定値と目標値、もしくは、個々の
部分の目標値と全体の目標値の不整合がある場合には、
その情報を開発メンバに伝えるので、不整合の状態が放
置されることはない。

【００４８】以上示した実施例を画面例を用いて詳細に
説明する。図１１は、開発活動モデルにおける活動項目
（活動単位）の日程を指定するための一画面例を示す図
である。ここでは、設計が終了し、試作機に対して目標
性能の達成を確認するための性能試験フェーズを例に説
明する。この例の場合、活動項目（活動単位）は性能確
認試験項目のこととなる。ここでは，性能試験の日程管
理を試験部門が行う場合を例としているので，図１１に
示すようにまずユーザを表すボタン群を表示するウィン
ドウ１１００で、試験部門に対応するボタンを選択して
日程計画画面に入る。

【００４９】日程計画画面は、計画対象プロジェクト名
称表示部１１０１と、プロジェクト終了日程表示部１１
０２と、該プロジェクトにおいて実施する全実施項目表
示部１１０３と、該実施項目を行うためのリソース表示
部１１０４と、該実施項目の標準所要時間表示部１１０
５と、日程を標準所要時間に基づいた長さで表示する日
程表示部１１０６ととから構成される。例えば、今日の
日付が９月２日であるとすると、当日表示ライン１１０
７が該当日付の部分に表示される。上記のように、日程
バー１１０８の長さは、標準所要時間表示部１１０５に
表示された標準所要時間に対応した長さとなる。プロジ
ェクト名称は、クライアントマシン１０００のモデル作
成部１においてキーボードにより入力される。入力され
たプロジェクト名称は、開発活動モデル格納部３に格納
される。プロジェクト終了日程表示部１１０２に表示さ
れているプロジェクト終了予定日は、開発活動モデル格
納部３に格納されている終了日を表示しているものであ
り、目標値設定ボタン１１０２で設定変更が可能であ
る。目標値設定ボタンの処理は、コミュニケーション管
理部１１の目標値設定の処理を行うためのボタンであ
る。プロジェクト終了日程表示部１１０２に表示されて
いるプロジェクト終了推定日は、推定値格納部８に格納
されている日程であり、これは図８を用いて説明したと
おり、日程推定部７が計算した値である。このプロジェ
クト終了目標値と、推定終了日程を比較したときには、
システムは警告として、ユーザを表すボタン群を表示す
るウィンドウ１１００において、日程管理者である「試
験部門」のボタンを点滅させる。

【００５０】次に、実施状況入力ボタン１１０９につい
て説明する。１つの実施項目が終了すると、その項目が
終了したかどうかの確認がこのような試験工程では必要
である。すべての実施試験項目をクリアしてはじめて製
品の設計が終了したといえるからである。そこで、各項
目に対して、「合格」、「不合格」、「保留」といった
状況を入力するための手段がこの実施状況入力ボタン１
１０９である。

【００５１】次に、複写／移動ボタン１１１０について
説明する。実施項目の間にはあらかじめ先行関係が定義
されている。これは、クライアントマシン１０００のモ
デル作成部１において初期計画時に指定されるものであ
り、例えば「項目Ｂは項目Ａが合格にならない限り実行
できない」といった項目の実行に対する拘束関係を表す
ものである。このような先行関係をもった項目の複写、
連動移動について図１２を用いて説明する。ここでは、
項目Ｂと項目Ｃの間にあらかじめ先行関係が定義されて
いるとする。すなわち、項目Ｃは項目Ｂが「合格」とな
るまで、実行できないことになる。まず、「複写」につ
いて説明する。図１２の（ａ）は、項目Ｂが合格となら
なかったため、２日後に再度項目Ｂを行うという状況を
示している。本システムにおける操作では、複写ボタン
を用いて該当する試験項目をコピーすることで実現でき
る。このコピーでは、項目実施日以外のすべての項目属
性が複写される。コピーしたあとで、項目Ｂを２日後に
実行するように指定すると、図１２（ａ）の右図のよう
に項目Ｃは連動して項目Ｂのあとに続いて移動する。こ
のとき、あいた日程は自動的につめられ、それ以降の日
程は、後ろに自動的にずれる。次に、「移動」について
説明する。図１２の（ｂ）は、はじめの計画日に何らか
の原因で項目Ｂが実行できなかった場合に、項目Ｂを２
日後に強制的にずらす場合を表す。この場合、項目Ｂを
２日後にずらすと、先行関係を持った項目Ｃが自動的に
連動移動し、あいた日程に後ろにあった項目Ｄと項目Ｅ
が自動的につめられる。この結果を示すのが図１２
（ｂ）の右図である。このような項目間に先行関係を定
義したことにより、実施すべき項目の計画を誤りなく迅
速に立案することができる。

【００５２】次に、コミュニケーション管理部１１によ
る、担当者間の協議内容に基づく、目標値格納部１２の
目標値の調整や不整合の警告処理の一例を図１３を用い
て説明する。プロジェクトの進行中に進行を阻害する問
題点が発生した場合には、直ちにその対策を実行し、プ
ロジェクトの日程を遅延させないようにしなければなら
ない。しかしながら、日程計画を立案修正するのが、こ
の例の場合試験部門であるのに対して、対策を立案する
のは設計部門であり、対策を実行に移して試作機に修正
を加えるのは試作部門である。このため、問題が発生し
たときに試験部門が再試験日を計画するためには、設計
及び試作部門の予定を知る必要がある。コミュニケーシ
ョン管理部１１はこのような他部門の予定を知ること
と、その予定に基づいて期限の約束をするためにも用い
られる。図１３はこのための、予定の入力を説明するた
めの図である。図１３では、項目４についての約束を入
力する画面を示している。図１１に示した日程表示画面
上にて、項目４を選択すると図のようなウインドウが表
示され、まず問題点表示欄１３０１とその問題点に対す
る実施対策欄１３０２が表示される。そこで、ユーザは
それぞれ自分の該当する部門の欄に約束日程を入力す
る。一例を挙げると、設計変更予定欄１３０３と、設計
変更終了欄１３０４と、改造希望欄１３０５は設計部門
で入力し、改造約束欄１３０６と、改造実施欄１３０７
と、試験希望欄１３０８は試作部門で入力する。試験日
程を立案する試験部門は、このウインドウ上の約束期限
を参照して、試験日程を再スケジュールすることができ
る。本システムによれば、電話等での問い合わせ時に担
当者が不在であっても担当者が入力したデータを参照す
ることができる。ここでシステムは、設計部門の入力す
る設計変更予定欄１３０３と、設計変更終了欄１３０４
の値を常時監視しており、設計変更予定欄１３０３に記
入されている日付を過ぎても、設計変更終了欄１３０４
に日付が入力されていない場合に、期限を過ぎていると
判断してシステムは警告を発生して、上記で説明したよ
うに、該当する設計部門のボタンが赤くなり点滅する。
また、試作部門の改造約束欄１３０６と改造実施欄１３
０７にも同様に期限に遅れがある場合、警告を発生する
動作をする。このように、システムが自動的に期限管理
をして警告を発生することにより、日程進捗の遅れを最
低限にすることができるという効果がある。

【００５３】以上日程を管理しながら，開発を進める場
合における本発明の機能と使用形態を示したが，次に、
原価を管理しながら開発を進める場合について説明す
る。

【００５４】まず、新製品の企画・構想担当は、市場情
報等から、新製品の目標原価を定める。図３に示すよう
に、目標値割付部１３は、製品の構成単位である各ユニ
ットへの原価目標値の割り付けを行う原価割り付け部３
００、性能の割り付けを行う性能割り付け部３１０、日
程の割り付けを行う日程割り付け部３２０を有してお
り、原価割付部３００は、この目標原価を製品を構成す
る各ユニットに割り付け、各ユニットの原価目標値を目
標値格納部１２に設定する。

【００５５】図３に示すように、原価割付部３００は、
既存の参考機種情報３３０を入力し参考機種のユニット
別原価構成や工程別原価構成を分析する原価分析モジュ
ール３０１と、生産数量や原材料人件費等の原価基準値
情報３４０を入力し、これらと製品原価の関係をシミュ
レーションする原価シミュレーションモジュール３０３
と、原価分析モジュールや原価シミュレーションモジュ
ールの機能を利用してユニット毎の原価配分を行う原価
配分３０２モジュールを備えている。

【００５６】尚、目標値割付部１３が、全て自動で原価
割付を行うのではなく、適宜、企画・構想担当者からの
対話型の指示を受けながら原価割付をするようにするの
が望ましい。さて、ここでの原価割付は、開発当初なの
で、部品一つ一つに対して割り付けられているものでは
なく、製品を構成する部品のブロックや、主要なユニッ
ト別に割り付けられている。次に、図４に示すように、
開発メンバは設計を詳細化していく。

【００５７】例えば、機械電気等の設計担当者は、開発
活動モデルで示される自分の担当部分の設計を行い、設
計結果を構造モデルおよび属性モデルとして製品モデル
格納部２に格納する４００。

【００５８】このモデルから原価推定部５は原価を推定
し４０１、原価推定値を推定値格納部８に格納する４０
２。推定値・目標値レビュー部９は、この原価推定値と
対応する原価目標値を比較し、その情報結果を必要に応
じて各開発メンバが適宜参照できるようにする。

【００５９】さて、この時点で、原価推定された部分と
原価目標値が設定されているユニットが対応しておら
ず、原価推定された部分が原価目標値が設定されている
ユニットの一部である場合、推定値・目標値レビュー部
９は、原価目標値を原価推定された部分と、原価推定さ
れていない部分に分割し、ユニット全体の原価目標値か
ら原価推定された値を引いた値を残りの部分の目標原価
として格納する。

【００６０】さて、このようにして設計が進み、原価目
標値が設定された各ユニットの原価推定値が求まった
時、求まった原価推定値が原価目標値を上回ると、推定
値・目標値レビュー部９は、この情報を開発メンバに伝
え対策を要求する４０５。

【００６１】対策としては、原価目標値を上回った部分
の設計を変更して、推定原価を低くする方法、この部分
の目標原価を原価推定値に合わせて上げる方法がある。

【００６２】しかし、後者の方法による場合、全体の原
価目標と部分の原価目標の合計が一致しなくなる。そこ
で、全体・部分整合性維持部１０はこれを検出し、開発
メンバに、この情報を伝え、対策を要求する。

【００６３】尚、この対策としては、他の部分の原価目
標値を下げて全体の原価目標値を達成する方法と、全体
の原価目標値を変更する方法がある。この判断は、各開
発メンバの協議４０７あるいは開発責任者の判断によ
る。コミュニケーション管理部１１は、この協議された
内容を把握し、その結果を目標値格納部１２に設定する
４０６。

【００６４】このように協議および判断した結果は目標
値格納部１２に反映され、反映された内容は、全体・部
分整合性維持部１０が評価する。そして、推定値と目標
値、もしくは、個々の部分の目標値と全体の目標値の不
整合がある場合には、その情報を開発メンバに伝えるの
で、不整合の状態が放置されることはない。

【００６５】以下、目標性能を管理しながら開発を進め
るの動作について説明する。

【００６６】性能の管理も原価管理と同様に、まず、目
標値割付部１３の中の性能割付部３１０が開発開始時に
おける性能目標値を目標値格納部に設定する。この目標
値設定は、新製品の企画・構想担当が、市場情報等か
ら、新製品の目標性能を定め、性能割付部３１０が、こ
の目標性能を満足するように、従来の参考機種の特性
や、開発機種に関する実験結果を入力し、これを参考に
して関係する製品特性を割り付けることにより行われ
る。

【００６７】例えば製品としてエアコンを、性能として
冷房能力と騒音を考えると、冷房能力に関係する特性と
して、熱交換器の特性や圧縮機やファンの特性があり、
騒音に関する特性として、ファンの送風音や筐体の振動
音やモータの運転音等がある。この場合、性能割付部
は、従来の参考機種の特性や、開発機種に関する実験結
果を入力し、これを参考に、全体の騒音目標から、送風
音、振動音、運転音に許される騒音目標値を定める。

【００６８】次に、この性能目標値を用いて、開発メン
バは、図５に示すように、設計を詳細化していく。

【００６９】すなわち、例えば、機械電気等の設計担当
者は、開発活動モデルで示される自分の担当部分の設計
を行い、設計結果を特性モデルとして製品モデル格納部
２に格納する５０１。このモデルから性能推定部５は性
能を推定し５０２、性能推定値を推定値格納部８に格納
する５０３。

【００７０】この性能推定は、いわゆるシミュレーショ
ンや、従来の実績データからの推定、および開発した試
作機の試験データに基づく推定等の方法により行う。こ
こで、シミュレーションや従来の実績データからの推定
と、試作機を製作して試験した結果では、推定精度が大
きく異なるので、性能推定値には、推定方法も含めて格
納するようにする。

【００７１】推定値・目標値レビュー部９は、性能推定
値とそれに対応する性能目標値を比較し５０４、その情
報を開発メンバが参照できるようにする。

【００７２】このようにして設計が進んだ結果、性能推
定値（試験による性能達成値を含む）が性能目標値を達
成できないことが判明した場合、推定値・目標値レビュ
ー部９は、この情報を開発メンバに伝え対策を要求する
５０５。

【００７３】対策としては、性能目標値を達成できない
部分の設計を変更する方法と、この部分の目標性能を性
能推定値に合わせて落とす方法がある。後者の場合は、
開発メンバの協議あるいは開発責任者の判断が必要とな
る。コミュニケーション管理部１１は、この協議された
内容を把握し、その結果を目標値格納部１２に設定する
５０６。

【００７４】このように協議および判断した結果は目標
値格納部１２に反映され、反映された内容は、全体・部
分整合性維持部１０が評価する。そして、推定値と目標
値、もしくは、個々の部分の目標値と全体の目標値の不
整合がある場合には、その情報を開発メンバに伝えるの
で、不整合の状態が放置されることはない。

【００７５】次に、開発の進行に伴って開発活動モデル
の詳細化や変更を行う動作について説明する。

【００７６】先に述べたように開発当初は概略を示すモ
デルとなっている開発活動モデルは、次第に詳細化され
る。

【００７７】この詳細化の作業は、次のように行うこと
ができる。

【００７８】例えば、電気の実装設計をするためには、
機械的なレイアウト設計の結果が必要になったり、詳細
な設計パラメータを決定するためには、その設計仕様に
関する特性試験の結果が必要になった場合等、各開発メ
ンバが、開発活動モデルで示される自分の担当部分の業
務を行う過程で、他の業務の結果を必要とすることがし
ばしば生じる。これらの作業が、開発活動モデルにおけ
る活動単位として記述されていれば、その作業結果や作
業日程を、この開発メンバは、参照できるが、その作業
が、開発活動モデルに記述されている活動単位の一部で
ある場合は、その作業の結果や作業日程は、その活動単
位の担当者以外の開発メンバには、わからない。

【００７９】このような場合、開発メンバは、図７に示
すように、詳細を知りたい作業の担当者、すなわち、作
業を含む活動単位の担当者に、作業の結果や予定を質問
する７０１。このような質問は、質問先の担当者に、定
められたフォーマット７０３の電子メールを送ることに
より実現することができる。この質問に対する回答７０
２も同様に電子メ−ルによって行われる。ここで活動単
位には、先に図２に示したように、その活動の担当責任
者を識別するコードが設けられており、開発活動モデル
を各開発メンバは参照することができるので、各活動単
位に関する問い合わせ先を互いに認識でき、先に述べた
ような電子メ−ルを送ることが可能となる。

【００８０】さて、コミュニケーション管理部１１は、
このような電子メールによる質問７０１と回答７０２の
内容を管理し、その回答の内容に応じて、それまで設定
されていなかった新たな目標値を目標値格納部１２に設
定したり７０５、開発活動モデル格納部３に新たな開発
活動単位を設定したりする７０４。

【００８１】新たな目標値として設定する例としては、
例えば、概略の日程しか決まっていなかった作業の詳細
な日程内訳や、原価や性能の目標値内訳等がある。

【００８２】また、ここで設定された目標値を得るため
の開発活動が一つの活動単位として、新たに開発活動モ
デルに記述されることになる。

【００８３】このように、開発メンバが互いに自分が知
りたい業務に関する質問と回答をすることによって、開
発活動モデルや目標値を詳細化して行くことができる。

【００８４】尚、開発活動モデルにおける各活動単位の
詳細化や変更は元になる活動単位の担当責任者が行う。
担当責任者の変更は可能である。また、製品モデル、リ
ソースモデルに関してもモデルを構成する各項目に、内
容を設定した担当者を識別するコードを設け、各担当者
に対し参照、書き込みの管理を行う。

【００８５】以上説明してきたように、本実施例によれ
ば、各開発担当者が担当する部分毎に設計した製品の構
造や特性を表現する製品モデルを製品モデル格納部に格
納し、この製品モデルから製品の性能や原価を推定する
と共に、各部分の開発作業量と開発リソースから日程を
推定し、この部分的な進行予想値を集計して製品開発全
体に対する進行予想値を求める。これにより開発の進展
に伴って変化する開発全体の進行予想値を各担当者が共
有することができる。そして、この全体および部分進行
予想値を目標値と比較して、目標を達成できるよう開発
活動の計画を調整することができる。また、相互に関連
する活動の目標や予定を、開発担当者が互いに質問、回
答をするコミュニケーションの情報から自動的に修正あ
るいは詳細化することにより、常に最新の目標値を保持
し、各担当者に提示することができる。

【００８６】したがって、製品開発の各担当者は、開発
の当初においては詳細が決定していない開発計画を、開
発の進展に伴って詳細化しながら、設計結果から客観的
に得られる進行予想値の全体部分の整合性を保ち、目標
達成に対する最適な計画を立てることができる。

【００８７】次に，コミュニケーション管理部１１が，
担当者間で伝達される情報をモニタリングして，開発活
動モデル格納部３の実績情報や目標値格納部１２の目標
値を自動的に設定する処理について示す。

【００８８】本実施例のコミュニケーション管理部１１
は、図１４に示すように、予め定めた進捗管理の指標と
する進捗管理項目を格納する進捗管理項目格納部１４０
１と、開発に係る部門間でやり取りされる定形化された
電子メールを収集する定形電子メール収集部１４０２
と、収集された電子メールに含まれている上記進捗管理
項目についての情報を抽出する進捗管理情報モニタリン
グ部１４０３と、抽出された情報を進捗管理情報として
格納する進捗管理情報格納部１４０４と、進捗管理情報
格納部に格納されている進捗管理情報を参照するための
進捗管理情報参照部１４０５と、外部からの操作を受付
けると共に処理結果を表示する入出力部（図示せず）と
を有する。

【００８９】進捗管理項目格納部１４０１に記憶されて
いる進捗の指標となる進捗管理項目としては、開発しよ
うとする製品またはそれを構成する各部品についての、
構造に関する進捗管理項目と、その機能に関する進捗管
理項目とがある。構造に関する進捗管理項目としては、
例えば、設計図面の着手日および完成日、その図面に基
づいた見積りの依頼日およびその回答日を用いる。

【００９０】また、機能に関する進捗管理項目として
は、例えば、要求する性能の検討開始日および決定日、
試作指示日および納入日、機能実験の開始日および結果
取得日を用いることができる。ここで、機能に関する進
捗管理項目は、開発の進捗を直接に示すのではなく、達
成しようとする機能特性に関する達成の度合を示すもの
である。

【００９１】進捗管理項目格納部１４０１に記憶されて
いる進捗管理項目は、キーボード等の入力装置（不図
示）により、外部からの操作を受け付けて、追加または
削除ができる構成となっている。

【００９２】進捗管理情報格納部１４０４は、進捗管理
項目格納部１４０１に記憶されている各進捗管理項目に
ついての情報の具体的な内容である、進捗管理情報（日
付等）を記憶する。

【００９３】進捗管理情報参照部１４０５は、キーボー
ド等の入力装置（不図示）により、外部からの指示を受
け付け、その指示に対応して、進捗管理情報格納部１４
０４に記憶されている進捗管理情報を、ＣＲＴ等の出力
装置（不図示）を介して、表示する。

【００９４】本実施例のコミュニケーション管理部１１
は、具体的には、例えば、ＣＰＵおよびメモリを備えた
情報処理装置と、ＣＲＴおよびキーボードを備える入出
力装置とを有するコンピュータにより実現できる。

【００９５】本実施例のコミュニケーション管理部１１
は、ＬＡＮ（Local Area Network)等の情報ネットワー
ク１０４により、開発に係る部門の担当者の開発ツール
１０１、１０２、１０３・・・と接続されている。

【００９６】各開発に係る担当者は、開発ツール１０
１、１０２、１０３・・・、例えば、ＣＡＤ（Computer
Assisted Design）ツールや業務情報の処理端末を用い
て、開発に係る業務を行うと共に、各自の業務の中で必
要な、見積り依頼と回答連絡、発注手配指示と納入連
絡、試作品製作指示と製作実績連絡のような業務連絡を
行うものである。ここで、開発に係る担当者とは、例え
ば、製品の開発を中心的に行なう開発担当者とするが、
本発明の担当者とはこれに限定されず、例えば、他の、
管理部門の担当者でもよい。

【００９７】本発明においては、このような業務連絡の
うち、上記進捗管理項目に関する情報を含むような業務
連絡に関しては、定形化された電子メールを用いて行う
構成としている。尚、情報ネットワーク１０４には、必
ずしも、開発ツール１０１・・・が接続されている必要
はなく、開発ツールの代わりに、上記定形電子メールの
入出力端末が接続されている構成であっても構わない。

【００９８】本実施例のコミュニケーション管理部１１
の構成によれば、定形電子メールに含まれている予め定
められた進捗管理項目についての情報を、定形電子メー
ル収集部１４０２および進捗管理情報モニタリング部１
４０３でモニタすることで、開発の進捗状況を把握する
ことができる。以下に、より具体的な例を挙げて説明す
る。

【００９９】本実施例において、開発製品の構造に関す
る進捗管理項目についての情報である、進捗管理情報を
用いる具体的な例を、図１５を用いて説明する。ここで
は、進捗管理情報格納部１４０４に、進捗管理情報を記
憶する一形態として、製品の構成を示す製品構成ツリー
を用いるものとする。この製品構成ツリーは、製品全
体、モジュール、部品の階層関係が示されており、通
常、製品構成ツリーと呼ばれるデータと基本的に同一の
構造である。

【０１００】この進捗管理情報格納部１４０４における
製品構成ツリーの特徴は、ツリーのノードの情報とし
て、図１５に示すように、通常の設計図面データに加
え、見積り依頼と回答、発注手配指示と納入、試作品製
作指示と製作実績のような処理に関する進捗を示す情報
（例えば、処理日時）を、進捗管理項目についての情報
として、予め設けられた各部品ごとに設けられた進捗属
性の欄に、各図面と対応させて格納することにある。

【０１０１】上記進捗管理項目についての情報は、設
計、資材、製造部門等の各担当者が開発に関する業務連
絡をする際に用いられる定形化された電子メールから抽
出され、製品構成ツリーを構成する部品の進捗状況を示
す進捗属性の欄に格納される。

【０１０２】例えば、設計部門担当者が設計した部品に
対する見積り依頼を、資材部門担当者へ定形電子メール
２１１を用いて行なうと、そのメール２１１が定形電子
メール収集部１４０２により収集される。電子メールの
収集の具体的な方法に関しては、後記する。収集された
電子メール２１１の情報２０３は、進捗管理情報モニタ
リング部１４０３によりモニタされ、そのメール２１１
の発行日時が、進捗管理情報格納部１４０４の中の、対
象とする部品の見積り依頼の欄に格納される。

【０１０３】また、この見積り依頼電子メール２１１を
受けた資材部門担当者が見積り回答を定形電子メール２
１２を用いて行なうと、そのメール２１２が進捗管理情
報モニタリング部１４０３によりモニタされ、その見積
り回答電子メール２１２の情報２０４に含まれる発行日
時が、進捗管理情報格納部１４０４の中の、対象とする
部品の見積り回答の欄に格納される。

【０１０４】以上は、開発されている製品の部品の見積
り依頼、回答の欄への日時の登録の処理を示したもので
あるが、各部品の構成部材の発注手配指示日および納入
日、試作指示日および製作完了日も、上記情報と同様
に、それぞれ、定形化された電子メール２１３、２１
４、２１５、２１６のそれぞれに含まれる情報２０５、
２０６、２０７、２０８をモニタすることで、進捗管理
情報格納部１４０４の所定の欄に格納される。

【０１０５】また、図１５に示された、進捗管理情報で
ある日時の他に、例えば、見積り依頼における見積り条
件や、見積り回答における見積り金額のような情報も登
録する構成としても良い。これらの情報は、進捗を参照
する時、日時だけでなく進捗の内容を把握するために有
効である。

【０１０６】上記のような構成を用いれば、開発される
製品の各モジュールや部品の開発進捗を示す、１）いつ
図面作成に着手し、２）いつ図面が完成し、３）いつ見
積り依頼し、４）いつ見積り回答が出、５）いつ発注手
配され、６）いつ納入され、７）いつ試作指示され、
８）いつ製作されたかを把握することができる。

【０１０７】進捗管理情報格納部１４０４に格納された
進捗管理情報を、進捗管理情報参照部１４０５によっ
て、表示する場合の例を、図１６に示す。進捗の表現形
式としては、例えば、日時表示形式（図１６（１））
や、グラフィカル表示形式（図１６（２））がある。

【０１０８】日時表示形式では、図１６（１）に示すよ
うに、本実施例の出力装置の出力画面１６００に、開発
されている製品を構成する部品名称１６１０と、進捗管
理情報に関する日時、すなわち、設計図作図着手日１６
１１〜製作完了日１６１８と、現在の日時またはこれら
進捗管理情報が更新された日時１６０１とを、表形式で
示す。また、上記進捗管理情報のうち、未着手のものは
空欄で、実施されたものはその日時を表示する。

【０１０９】本図では、例えば、開発されている製品の
構成部品の一つであるキャビネット１６０２について
は、見積りの依頼日１６０３は１月１５日であるが、そ
れに対する回答１６０４は得られていない状態を示して
いる。

【０１１０】グラフィカル表示形式では、図１６（２）
に示すように、上記進捗管理情報１６１１〜１６１８に
対応する処理が完了したことを示すために、各情報毎
に、色、または、模様、または、それらの組み合わせに
よる特定のマーク１６２１〜１６２８を決めておく。

【０１１１】尚、上記進捗管理項目は、製品の進捗状況
を直接示す指標である。すなわち、例えば、図１６
（１）において、上記進捗管理項目の日時が１つずつ決
定されていく毎に、製品の開発が進んでいることを示し
ている。このため、以下では、上記進捗管理項目のそれ
ぞれに対応する処理を、開発における進捗ステップと呼
ぶ。

【０１１２】グラフィカル表示形式では、更に、出力画
面１６００に、進捗ステップ（上記進捗管理項目に対応
する処理）１６１１〜１６１８と、進捗ステップごとに
割り当てられたマーク１６２１〜１６２８との対応関
係、および、この対応関係により決定されたマークを用
いて表現された、部品構成ツリーにおける各ノードのモ
ジュールや部品の進捗状況を示している。図１６（２）
は、図１６（１）に示されている進捗状況と同じもの
を、上記決められたマークで表示したものである。

【０１１３】このグラフィカル表示形式では、厳密な日
時はわからないが、例えば、マークに用いられる色を、
進捗状況の進行に応じて、薄くから濃くしたりすること
により、全体状況が一目で把握できるという良さがあ
る。

【０１１４】また、本実施例では、時間的に最も新しい
時期に行なわれた処理について、表示がされているが、
例えば、今までに行なわれたすべての処理についても、
同じように、マークを用いて表現する形式としても良
い。

【０１１５】次に、本実施例の作用を、図１７、図１
８、図１９、および、図２０を用いて説明する。

【０１１６】本実施例においては、定形電子メール収集
部１４１２が、開発に係る部門間でやり取りされる定形
化された電子メールを収集する。定形電子メール収集部
１４１２は、図１８に示すように、例えば、電子メール
の収集、発行などを行うメールサーバ１８０１を備える
構成とする。

【０１１７】本実施例における定形電子メールは、例え
ば、図１９に示すように、その内容を、メールの種類、
日時、および、内容属性により定形化することが可能で
ある。ここで、メールの種類は、進捗管理項目格納部１
４０１に格納されている進捗管理項目に対応するもの
で、例えば、見積依頼メール２１１、見積回答メール２
１２等がある。日時は、メールの発行日を示す。内容属
性は、そのメールの種類に対応するもので、例えば、見
積回答メール２１２の内容属性としては、見積依頼番号
および見積金額が含まれる。

【０１１８】このような定形電子メールは、例えば、図
１７に示すような操作画面１７００を備える電子メール
送信端末において、図２０に示すフローチャートに従う
操作を行うことで、作成、送信することができる。

【０１１９】すなわち、最初に、送ろうとする電子メー
ルの種類を、メニュー１７０１から選択する（ステップ
１２０１）。ここで、選択可能なメールの種類は、進捗
管理項目格納部１に記憶されている進捗管理項目に対応
するように決定されるもので、例えば、図６に示すよう
なメールの種類を選択枝として、設定する。

【０１２０】次に、選択したメールの種類に対応する内
容属性を入力する（ステップ１２０２）。図１７では、
メニュー１７０１で選択されたメールの種類「見積り依
頼」に対して、それに必要な内容属性「見積り図番」の
入力欄１７０２を表示し、それに必要な情報が入力され
ている状態を示している。このステップで、入力される
内容属性は、上記ステップで選択されたメールの種類に
対応するもので、具体的には、図１９の内容属性の欄に
示されているような情報である。

【０１２１】最後に、メールの送信先をメニュー１７０
３から選択する（ステップ１２０３）。ここで、送信先
としては、開発に関係する部門を少なくとも含むものと
する。以上のようにして、作成されたメール文１７０４
には、更に、発行の日付および発行元の部門に関する情
報を加え、発行する。

【０１２２】本実施例においては、メニューを用いて定
形電子メールを作成発行する方法の一例を説明したが、
本発明においては、図１９に例示されたような情報を含
む電子メールを作成することができれば、その作成方法
や作成装置の具体的な構成を、限定するものではない。

【０１２３】以上のようにして、各部門で作成、発行さ
れた定形電子メールは、図１８に示すように、定形電子
メール収集部１４０２のメールサーバ１８０１により一
旦収集される。次に、進捗管理情報モニタリング部１４
０３は、それら収集された定形電子メールのうち、進捗
管理項目格納部１４０１に格納されている進捗管理項目
についての情報を含んだ電子メールを選択し、その選択
された電子メールから当該情報を抽出して、進捗管理情
報格納部１４０４に記憶させる。

【０１２４】具体的には、図１８に示されているフロー
チャートに従い、進捗管理情報モニタリング部１４０３
は、最初、メールサーバ１８０１から電子メールを読み
だし（ステップ１８１１）、読み出された電子メールの
種類を抽出する（ステップ１８１２）。

【０１２５】次に、抽出された電子メールの種類が、進
捗管理項目格納部１４０１により定義されている進捗管
理項目１８０２の１つを含む形式のメールに該当するか
を調べる（ステップ１８１３）。進捗管理項目１８０２
の１つを含む形式のメールに該当しなければ（ステップ
１８１３でＮｏ）、なにも処理せず終了とする。

【０１２６】該当する場合は（ステップ１８１３でＹｅ
ｓ）、このメールの日付と内容属性とを取りだし（ステ
ップ１８１４、１８１５）、それらを進捗管理情報格納
部１４０４の所定の進捗属性欄に格納して（ステップ１
８１６）、処理を終了する。

【０１２７】上記のような進捗管理情報モニタリング部
１４０３の処理を起動する方法としては、新規の電子メ
ールが、メールサーバ１８０１に来る度に実行したり、
または、定期的にメールサーバ１８０１の新規メールを
チェックする方法がある。

【０１２８】また、進捗管理情報モニタリング部１４０
３をメールの送信先の１つと設定して、全ての電子メー
ルを進捗管理情報モニタリング部１４０３にも自動的に
送信されるような構成としてもよい。このような構成に
よれば、定形電子メール収集部１４０２を介さずに、進
捗管理情報モニタリング部１４０３が電子メールを受け
取ることができる。

【０１２９】上記実施例で例示されたような進捗管理情
報モニタリング部１４０３による電子メールの処理は、
電子メールに含まれるメッセージの形式をメール種類、
日時、内容属性のように定形化することにより実現され
る。

【０１３０】次に、本実施例において、開発製品の機能
に関する進捗管理項目についての情報を用いる具体的な
例を、図２１を用いて説明する。ここでは、進捗管理情
報格納部１４０４に、進捗管理項目を記憶する一形態と
して、製品の機能についての、進捗状況を表すことがで
きるように、製品全体あるいは部分の特性の計算や実験
の実施結果を示す情報を、機能属性欄２１００に格納し
ている。

【０１３１】製品の開発において、製品の機能特性の計
算は、計算条件や計算方法を変えて複数回実施されるこ
とがあり、機能特性に関する実験も、実験条件や対象と
する試作機を変えて複数回実施されることがある。この
ような機能特性の計算処理や機能特性に関する実験は、
製品の品種などのカテゴリーに対応して、予め定められ
ているものが多い。

【０１３２】したがって、これらの計算処理や実験処理
をモニタリングすることで、開発されている製品の機能
に対する達成度、すなわち、開発の機能的一面における
進捗状況を計ることができる。このため、本例において
は、特性の計算や実験の実施結果を格納する機能属性欄
２１００は、求めようとする機能特性に関し、複数回の
実施結果を格納できるような表形式を有している。

【０１３３】機能属性欄２１００に格納される情報の内
容は、設計、解析、試験部門等の各担当者が開発試験に
関する業務連絡をする際に用いられる定形化された電子
メールから抽出され格納される。

【０１３４】例えば、設計部門担当者が設計した部品に
対する機能特性に関する計算の依頼を、解析部門担当者
へ定形電子メール２１１１を用いて行なうと、そのメー
ル２１１１が定形電子メール収集部１４０２により収集
される。収集された電子メール２１１１の情報２１０１
は、進捗管理情報モニタリング部１４０３によりモニタ
され、そのメール２１１１の計算条件が、進捗管理情報
格納部１４０４の中の、対象とする機能特性の計算条件
の欄に格納される。

【０１３５】また、この特性計算依頼電子メール２１１
１を受けた解析部門担当者が特性計算結果を定形電子メ
ール２１１２を用いて行なうと、そのメール２１１２が
進捗管理情報モニタリング部１４０３によりモニタさ
れ、そのメール２１１２の情報２１０２に含まれる計算
結果が、進捗管理情報格納部１４０４の中の、対象とす
る機能特性の計算結果の欄に格納される。

【０１３６】また、機能特性実験の条件および手配指示
や、実験結果の報告も、上記と同様に、それぞれ、定形
化された電子メール２１１３、２１１４の情報２１０
３、２１０４をモニタすることで、進捗管理情報格納部
１４０４の所定の欄に格納される。

【０１３７】このようにして情報が入力された機能属性
欄２１００を参照することにより、製品全体あるいは部
分の特性の計算や実験がいつ実施され、どのような結果
が得られたかがわかる。

【０１３８】次に、本発明を適用した開発進捗モニタリ
ングシステムの他の実施例を、図２２を用いて説明す
る。本実施例は、開発製品の機能に関する開発進捗状況
をモニタリングするために、その開発製品の機能特性の
計算の実施における計算機への計算指示の情報を用いる
ものである。

【０１３９】本実施例のコミュニケーション管理部１１
は、図２２に示すように、開発ツール１０１、１０２・
・・から、計算機２２００へ送られる計算指示の情報
を、開発ツール１０１、１０２・・・および計算機２２
００が接続されている情報ネットワーク１０４を通して
モニタリングする構成を有している。

【０１４０】本実施例は、予め定めた進捗管理の指標と
する進捗管理項目を格納する進捗管理項目格納部１４０
１と、計算機２２００へ送られる計算指示情報に含まれ
る進捗管理項目についての情報を抽出する計算指示モニ
タリング部１４０６と、抽出された情報を進捗管理情報
として格納する進捗管理情報格納部１４０４と、進捗管
理情報格納部１４０４に格納されている進捗管理情報を
参照するための進捗管理情報参照部１４０５と、外部か
らの操作を受け付けると共に処理結果を表示する入出力
部（図示せず）とを有する。

【０１４１】進捗管理項目格納部１４０１に記憶されて
いる進捗管理項目としては、例えば、開発製品またはそ
の構成部品についての、見積り計算や、機能特性の計算
等、計算機２２００により行われる当該製品または部品
に関する計算の指示情報を用いることができる。

【０１４２】上記実施例では開発関係者間でやり取りさ
れる業務連絡の電子メールの内容をモニタリングしてい
たが、本実施例では、電子メールの代わりに、開発者か
らの計算機２２００へ対する計算指示の情報をモニタリ
ングしている。

【０１４３】本実施例の構成においては、上記実施例に
含まれていた定形電子メール収集部１４０２と進捗管理
情報モニタリング部１４０３とがなく、その代わりに、
計算指示モニタリング部１４０６が備えられている。モ
ニタリングされた計算指示の内容は、図１８に示された
上記実施例における処理と同様に、進捗管理項目格納部
１４０１に記憶されている進捗管理項目に該当するかど
うかが判断され、該当する場合はその内容が抽出され、
進捗管理情報格納部１４０４に格納される。

【０１４４】本実施例によれば、電子メールを収集しモ
ニタリングすることなく、電子メール収集部を設ける必
要がないため、システム構成がより単純化でき、製品の
機能特性の開発進捗状況を把握することが可能となる。

【０１４５】次に、本発明を適用した開発進捗管理シス
テムの他の実施例を、図２３を用いて説明する。

【０１４６】本実施例は、進捗管理情報格納部１４０４
に、各進捗管理項目に対応する処理の完成予定日時を設
定し、完成予定と実際の進捗状況との比較表示や、完成
予定より遅延している進捗管理項目を表示するものであ
る。

【０１４７】本実施例は、図２３に示すように、予め定
めた進捗の指標とする進捗管理項目を格納する進捗管理
項目格納部１４０１と、開発に係る部門間でやり取りさ
れる定形化された電子メールを収集する定形電子メール
収集部１４０２と、収集された電子メールに含まれてい
る進捗管理項目についての情報を抽出する進捗管理情報
モニタリング部１４０３と、抽出された情報を進捗管理
情報として格納する進捗管理情報格納部１４０４と、進
捗管理情報格納部１４０４に格納されている進捗管理情
報を参照するための進捗管理情報参照部１４０５と、外
部からの操作を受け付けると共に処理結果を表示する入
出力部と、上記進捗管理項目に対応する処理の終了予定
日を設定する進捗管理情報設定部１４０７とを有する。

【０１４８】本実施例において、進捗管理情報設定部１
４０７以外の構成要件の構成および作用は、図１４の実
施例と同じであり、ここでの説明は省略する。

【０１４９】本実施例において、進捗管理情報設定部１
４０７による、上記進捗管理項目に対応する処理の終了
予定日時の設定は、図２４に示すような、入出力部の出
力装置の表示画面１６００を通して行われる。この進捗
管理情報設定部１４０７の予定日設定処理は、例えば、
表示画面１６００上に設けられた予定設定ボタン２４０
１を、マウスまたはキーボード等の入力装置によりクリ
ックすることで起動される。尚、図２４は、この予定日
設定処理が起動された後の画面１６００の状態を示して
いる。

【０１５０】予定設定を行う画面１６００においては、
開発製品の構成部品の名称１６１０と、上記進捗管理項
目に対応する処理１６１１〜１６１８とが表形式で示さ
れている。終了予定日を入力するには、例えば、操作者
が、マウス等で画面１６００上の入力しようとする欄を
指定して、キーボードから日付を入力する。進捗管理情
報設定部１４０７は、これらの指示を受け入れ、各部品
の進捗管理項目に対応する処理毎に予定日を設定する。

【０１５１】また、予定日の設定においては、本実施例
のようにそれぞれ入力するのではなく、例えば、予め標
準的な期間を当該処理ごとに設定しておき、入力された
処理以降の処理に関する終了予定日を自動的に設定でき
る構造としてもよい。

【０１５２】本実施例においては、進捗管理情報設定部
１４０７による予定日設定の後に、進捗管理情報参照部
１４０５を起動させて、各進捗管理項目に対応する処理
の終了予定日時と、進捗管理情報格納部１４０４に格納
されている実際の終了日とを併せて表示することで、予
定と実際の進捗状況とを比較することができる。

【０１５３】進捗管理情報参照部１４０５の表示処理
は、図２４に示されている予定日の設定を行うための画
面１６００に設けられている進捗参照ボタン２４０２
を、クリックすることで、起動される。

【０１５４】表示形態としては、例えば、日時予定と実
績とを合わせて数字で表示する日時予定／実績表示形式
（図２５（１））と、実際の進捗状況が予定よりも遅れ
ているかどうか予め定めたマークで表示するグラフィカ
ル表示形式（図２５（２））とがある。

【０１５５】尚、図２５（１）および（２）の表示選択
は、画面１６００上に設けられた進捗参照ボタン２４０
２をクリックすることで新たに表示される、日時ボタン
２５０３およびアラームボタン２５０４のうち、いずれ
か一方をクリックすることで行われる。

【０１５６】日時予定／実績表示形式では、図２５
（１）に示すように、進捗管理項目に対応する処理１６
１１〜１６１８のそれぞれに対して、終了予定日２５０
５と、実際の終了日２５０６とが併せて表示する。

【０１５７】グラフィカル表示形式では、図２５（２）
に示すように、予定より遅れている進捗管理項目に対応
する処理と、遅れていない処理との差異が明確に表れる
ように、色や模様を変えたマーク１１０５と、マーク１
１０６とで表現する。

【０１５８】また、本実施例のグラフィカル表示形式
と、図１６の表示形式のような進捗管理項目の各処理に
対応した色または模様を備えるマークによる表現形式と
を併せて、予定より遅れている処理名が具体的に特定で
きるような構成としても良い。

【０１５９】本実施例によれば、進捗管理項目と対応す
る処理ごとに終了予定日を設定し、それを実際の処理日
と比較することができるため、開発の進捗状況がより明
確に把握することができる。

【０１６０】次に、設計部門と試験部門の間において行
なう問題発生の連絡について図２６を用いて説明する。
試験部門で試験中に問題が発生したときには、直ちに対
応部門に連絡をする必要がある。今、問題が発生してそ
の対応部門が機械設計部門である場合、試験部門は試験
中発生した問題の内容を直ちに連絡しなければならな
い。電話の場合、設計部門の担当者が席にいないことも
ありえるため、コミュニケーション管理部１１を用い
て、連絡メールを伝送する。図２６はこの連絡メールの
発信画面の一例を示す図である。図２６は、試験部門が
試験中に発生した問題を送信するための画面である。図
２６の問題連絡メール発信画面９００において、試験者
氏名を選択する試験者選択欄９０１と設計者氏名を選択
する設計者選択欄９０２をもっている。これは、一般の
メールでいう発信者と宛先の関係である。このようにメ
ニューからスクロールにより選択することで設定でき
る。今、「モータの騒音が大きい」という問題が試験中
に発生したとする。試験者は試験中に問題が発生したと
きメールを直ちに発信するがその手順は、まず分類１か
らモータを選択する。この分類１リスト９０４は、主に
場所とか部品を指すカテゴリである。分類１リスト９０
４の選択をしたとき、分類２リスト９０３には、分類１
リスト９０４の場所とか部品に対応した計測値の種類が
現われる。ここで「音」を選ぶと、音に関係のあるメー
ルの例がメニュー９０５に表示されるので、この「騒音
が大きい」というメッセージを選択して発信ボタンを押
すと問題連絡メールがコミュニケーション管理部１１に
より連絡事項格納部１５の問題履歴格納部１５１に格納
され、設計に新規メールが到着したことが伝送される。
また発信されたメールは、発信履歴管理表示部９０６に
発信時刻と共に表示される。もし発信したメールを履歴
から削除したい場合には削除ボタンを押すことで削除が
実行され、伝送済みのメールの取消ができる。

【０１６１】次に、設計部門における上記連絡メールの
取り扱いについて図２７と図２８を用いて説明する。上
記連絡メールを受けた設計者はそのメニュー２７０１の
自分の名前のところが赤く点滅する。このメニュー２７
０１は、上記においてユーザを機械設計と、電気設計
と、試作と、試験部門にわけていたものを人の名前に詳
細化したものである。図２７は連絡メールが「鈴木」宛
に到着していることを示している。このとき、メール内
容を表示させると該当する試験室名称表示部２７０２に
使用している試験室名称が表示され、問題の発生した試
験項目の試験条件が条件表示部２７０３に表示され、更
に伝送された問題連絡メールが連絡メール表示部２７０
４に表示される。あらかじめ試験の測定データは、コミ
ュニケーション管理部１１により連絡事項格納部１５に
格納されているので、測定データと問題連絡メールの関
係付けを行なえば画面上に試験データを表示することが
できる。上記設計者への表示を示したものが図２８であ
る。図２７においてメールを選択すると、図２８に示し
たように測定値のグラフを表示することができる。この
グラフの表示は、図２９に示した測定値名称とメールの
関係を記述した対応テーブルから表示すべき測定項目名
のデータをグラフ化する。図２９の項目群欄２９０２
は、例えば「モータ騒音大きい」といった問題連絡メー
ルに対して表示すべき測定項目群が記述されている部分
である。このように、問題種類とその問題に関係する測
定項目を関係付けたテーブルを使用することにより、１
つの問題が発生した場合、その問題の原因追及のために
どんな測定値を参照したらよいかを考える必要がなく、
非常に効率的に原因究明を行なえるという効果がある。
すなわち、計測結果をリアルタイムに把握することがで
きるので、問題が発生しても迅速に対策検討と対策実施
に移行できるという特長を持つ。

【０１６２】

【発明の効果】以上のように、本発明によれば、製品開
発の開発プロジェクト全体および部分の目標値および進
行予想値、相互の整合性管理を支援することのできる開
発支援システムを提供することができる。

【０１６３】更に、本発明は、開発に係る担当者が、自
分の担当する部分に関する、開発に必須な業務処理を行
なうと、その処理に用いる電子メールの中から自動的に
開発進捗に係わる情報をモニタリングし、その情報を進
捗管理情報として格納して、各開発者が開発全体の進捗
を参照できるようにしたものである。ここで、モニタさ
れる進捗管理項目についての情報は、特に、開発管理の
ための電文をやり取りすることによって得るものではな
い。

【０１６４】したがって、本発明によれば、従来の開発
支援システムのように、開発管理のために特別な工数を
要し、そのため開発管理が、開発者にとって負担となる
という問題が解消される。

【０１６５】更に、本発明によれば、従来の開発支援シ
ステムを用いる際の問題として挙げられている、開発管
理のための客観的な情報収集が難しいという問題が解決
される。

【０１６６】すなわち、開発活動自身は、主に、人間の
知的な活動であるため、その進捗状況に関する情報は、
従来は、各開発者の自己申告に依っていた。一方、生産
活動は、生産物がどの工程にあるか目に見えるので、客
観的な進捗が容易に客観的に把握できた。この点が、開
発活動の進捗管理と生産活動の進捗管理との、大きく異
なるところである。

【０１６７】したがって、従来、開発管理においては、
自己申告された主観的な情報が主に利用されており、客
観的な進捗情報を収集することが難しいという状態にあ
った。このため、従来の開発支援システムでは、いかに
高度な管理機能を備えていても、客観的で、有効な開発
管理が行なえないという問題があった。

【０１６８】本発明では、進捗状況を計るための情報
は、開発に必須な業務処理に関する情報から自動的にモ
ニタリングされるもので、各開発者の自己申告によるも
のではないのではない。このため、開発進捗の実態と異
なることがない。

【０１６９】したがって、本発明によれば、有効な開発
管理にとって、最も重要な客観的な進捗に関する情報を
得られるという点で、従来の開発支援システムの最大の
問題を解決している。

【図面の簡単な説明】

【図１】本発明の一実施例に係る開発支援システムの構
成を示すブロック図である。

【図２】本発明の一実施例に係る開発支援システムが用
いる開発活動モデルの構成を示す説明図である。

【図３】本発明の一実施例に係る開発支援システムを用
いた開発目標値の設定の手順を示す説明図である。

【図４】本発明の一実施例に係る開発支援システムを用
いた原価管理の動作の手順を示す説明図である。

【図５】本発明の一実施例に係る開発支援システムを用
いた目標性能達成管理の手順を示す説明図である。

【図６】本発明の一実施例に係る開発支援システムを用
いた目標日程達成管理の手順を示す説明図である。

【図７】本発明の一実施例に係る開発支援システムを用
いた開発活動モデルの詳細化および変更の手順を示す説
明図である。

【図８】本発明の終了日程推定の方式を説明する説明図
である。

【図９】プロジェクトの進捗度の定量化の例を示す説明
図である。

【図１０】本発明の警告メッセージ生成方式を説明する
説明図である。

【図１１】日程計画の立案・編集のための一画面例を示
す図である。

【図１２】実施項目間の先行関係を説明するための説明
図である。

【図１３】設計・試作・試験部門が互いに日程入力を行
なうための一画面例を示す説明図である。

【図１４】本発明の一実施例に係わる開発進捗モニタリ
ングシステムの構成を示すブロック図である。

【図１５】製品の構造に基づく進捗管理情報を用いて開
発進捗をモニタリングする方法の例を示す説明図であ
る。

【図１６】図１６（１）：進捗管理情報を用いて進捗状
況を表示する画面の例を示す説明図である。 図１６（２）：進捗管理情報を用いて進捗状況を表示す
る画面の例を示す説明図である。

【図１７】各種定形電子メールの作成を行う操作画面の
例を示す説明図である。

【図１８】進捗管理情報モニタリング部が電子メールの
内容をモニタリングして、進捗管理情報格納部に進捗管
理情報を登録する処理を示す説明図である。

【図１９】電子メールの内容解釈を可能とする定形電子
メールのメッセージの形式例を示す説明図である。

【図２０】定形電子メールの作成処理の一例を示すフロ
ーチャートである。

【図２１】製品の機能に基づく進捗管理情報を用いて開
発進捗をモニタリングする方法の例を示す説明図であ
る。

【図２２】本発明の他の実施例に係わる開発進捗モニタ
リングシステムの構成を示すブロック図である。

【図２３】本発明の他の実施例に係わる開発進捗モニタ
リングシステムの構成を示すブロック図である。

【図２４】各進捗管理項目に対応する処理の終了予定日
時を設定する操作画面の例を示す説明図である。

【図２５】図２５（１）：終了予定と実際状況との比較
を表示する画面の例を示す説明図である。 図２５（２）：終了予定と実際状況との比較を表示する
画面の例を示す説明図である。

【図２６】試験中の発生問題点の連絡に用いる連絡メー
ル発信の一画面例を示す説明図である。

【図２７】試験中に受信した連絡メール表示の一画面例
を示す図である。

【図２８】連絡メールにより試験中の測定データを参照
するための一画面例を示す説明図である。

【図２９】問題連絡メールと測定項目の関係データ構造
の一例を示す図である。

【符号の説明】

１……モデル作成部 ２……製品モデル格納部 ３……開発活動モデル格納部 ４……リソースモデル格納部 ５……原価推定部 ６……性能推定部 ７……日程推定部 ８……推定値格納部 ９……推定値・目標値レビュー部 １０……全体・部分整合性維持部 １１……コミュニケーション管理部 １２……目標値格納部 １３……目標値割付部 １５……連絡事項格納部 １４０１……進捗管理項目格納部、 １４０２……定形電子メール収集部、 １４０３……進捗管理情報モニタリング部、 １４０４……進捗管理情報格納部、 １４０５……進捗管理情報参照部、 １４０６……計算指示モニタリング部、 １４０７……進捗管理情報設定部。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 キシカワ ロベルト 神奈川県横浜市戸塚区吉田町292番地株式 会社日立製作所生産技術研究所内 (72)発明者 岡本 啓一 神奈川県横浜市戸塚区吉田町292番地株式 会社日立製作所生産技術研究所内 (72)発明者 大成 尚 神奈川県横浜市戸塚区吉田町292番地株式 会社日立製作所生産技術研究所内 (72)発明者 大橋 敏二郎 神奈川県横浜市戸塚区吉田町292番地株式 会社日立製作所生産技術研究所内 (72)発明者 北沢 浩 静岡県清水市村松390番地株式会社日立製 作所清水工場内 (72)発明者 出石 峰敏 静岡県清水市村松390番地株式会社日立製 作所清水工場内 (72)発明者 早川 光春 神奈川県川崎市幸区鹿島田890番地株式会 社日立製作所情報システム事業部内

Claims (17)

【特許請求の範囲】
1. 【請求項１】製品の開発を支援するシステムであって、 製品のモデルと、製品開発に使用する資源のモデルを格
   納するリソースモデルと、製品開発の活動のモデルとを
   格納する手段と、 製品の開発日程、原価、性能の全体の目標値と個々の部
   分の目標値を格納する手段と、 前記各モデルから、開発日程、原価、性能の進行予想値
   を推定する手段と、 開発担当者による、前記各モデルと各目標値と各進行予
   想値の参照を支援する手段と、 開発担当者による前記各モデルの変更、詳細化を支援す
   る手段と、 各モデルの変更、詳細化が行われた場合に、前記各進行
   予想値が、対応する目標値を満足するか否かを判定し、
   少なくとも満足しない場合には、その旨を利用者に通知
   する手段とを有する開発支援システム。
2. 【請求項２】製品の開発を支援するシステムであって、 製品のモデルと、製品開発に使用する資源のモデルを格
   納するリソースモデルと、製品開発の活動のモデルとを
   格納する手段と、 製品の開発日程、原価、性能の全体の目標値と個々の部
   分の目標値を格納する手段と、 前記各モデルから、開発日程、原価、性能の進行予想値
   を推定する手段と、 開発担当者による、前記各モデルと各目標値と各進行予
   想値の参照を支援する手段と、 開発担当者による前記各モデルの変更、詳細化を支援す
   る手段と、 開発担当者による前記各目標値の変更、詳細化を支援す
   る手段と、 目標値の変更、詳細化が行われた場合に、全体目標値と
   部分目標値の整合性を評価し、少なくとも不整合である
   場合に、利用者に、その旨を通知する手段とを有する開
   発支援システム。
3. 【請求項３】請求項１記載の開発支援システムにおい
   て、 開発担当者による前記各目標値の変更、詳細化を支援す
   る手段と目標値の変更、詳細化が行われた場合に、全体
   目標値と部分目標値の整合性を評価し、少なくとも不整
   合である場合に、利用者に、その旨を通知する手段と
   を、さらに有することを特徴とする開発支援システム。
4. 【請求項４】請求項１、２または３記載の開発支援シス
   テムにおいて、 前記各目標値の変更、詳細化を支援する手段は、 複数の開発担当者の開発支援システムを介した協議を支
   援する手段と、当該協議の結果に応じて目標値の変更、
   詳細化を行う手段とから成る開発支援システム。
5. 【請求項５】請求項１または２記載の開発支援システム
   において、 前記開発活動モデルは、開発活動単位毎に、当該開発活
   動単位の名称、当該開発活動単位の制約条件、当該開発
   活動単位に使用するリソースモデル、当該開発活動単位
   で参照する製品モデル、開発活動単位の結果を示す製品
   モデル、活動の開始および終了時期の予定値と実績値を
   記述した、複数の活動単位情報を、活動単位の先行関係
   を示すグラフで表現したモデルである。
6. 【請求項６】請求項５記載の開発支援システムにおい
   て、 前記開発活動モデルを構成する活動単位毎に担当責任者
   を識別するコードを記述する開発支援システム。
7. 【請求項７】請求項１または２記載の開発支援システム
   において、 製品モデル、リソースモデルの各項目に、内容を設定し
   た担当者を識別するコードを記述する開発支援システ
   ム。
8. 【請求項８】請求項１または２記載の開発支援システム
   において、 製品の開発進捗の指標となる進捗管理項目を登録してお
   く進捗管理項目格納部と、 製品の開発に係る複数の担当者が、開発時情報ネットワ
   ークを介して送信する電子的な情報の中より、前記製品
   の開発進捗の指標となる進捗管理項目についての情報を
   抽出する進捗管理情報モニタリング部と、 前記抽出された情報を、進捗管理情報として格納する進
   捗管理情報格納部と、 利用者の要求に応じて、前記格納されている進捗管理情
   報を利用者に参照可能とする進捗管理情報参照部とを有
   する開発支援システム。
9. 【請求項９】請求項８記載の開発支援システムにおい
   て、 前記電子的な情報は、前記製品の開発に係る業務に伴い
   生じる複数の処理のそれぞれについて、送受信される電
   子メールであり、 前記進捗管理情報モニタリング部は、前記電子メールに
   含まれる、前記進捗管理項目のそれぞれについての情報
   を抽出して、前記進捗管理情報として前記進捗管理情報
   格納部へ格納する開発支援システム。
10. 【請求項１０】請求項９記載の開発支援システムにおい
    て、 前記電子メールを用いて行なわれる処理は、前記製品を
    構成する各部品についての、見積り依頼、その見積り依
    頼に対する回答、発注手配指示、その発注手配指示に対
    する納入報告、試作品製作指示、および、その指示され
    た試作品の納入報告、のうちの少なくとも１つの処理で
    あり、 前記進捗管理項目格納部は、前記電子メールを用いて行
    なわれる処理に対応する項目のうちの１つである、当該
    処理の完了日時を、前記進捗管理項目として格納し、 前記進捗管理情報モニタリング部は、前記電子メールを
    用いて行なわれた処理の完了日時を、前記電子メールか
    ら抽出し、前記進捗管理情報として、前記進捗管理情報
    格納部へ格納する開発支援システム。
11. 【請求項１１】請求項８記載の開発支援システムにおい
    て、 前記進捗管理情報参照部は、前記進捗管理情報格納部に
    格納されている前記進捗管理情報に対応する前記進捗管
    理項目のうちの、１以上の前記進捗管理項目を、その前
    記進捗管理項目に対応して予め定められているマークを
    用いて表示する表示手段を有する開発支援システム。
12. 【請求項１２】請求項１１記載の開発支援システムにお
    いて、 前記表示手段は、前記製品を構成する部品毎に、前記進
    捗管理情報格納部に格納されている前記進捗管理情報の
    うちの、時間的に最も新しい時期に格納された１つの前
    記進捗管理情報に対応する前記進捗管理項目を、その前
    記進捗管理項目に対応して予め定められているマークを
    用いて表示する開発支援システム。
13. 【請求項１３】請求項８記載の開発支援システムにおい
    て、 前記進捗管理項目格納部に格納されている前記進捗管理
    項目のうちの、少なくとも１以上の前記進捗管理項目
    の、それぞれに対応する処理の完了予定日時を設定する
    進捗管理情報設定部をさらに有し、 前記進捗管理情報参照部は、前記進捗管理情報格納部に
    格納されている前記進捗管理情報に対応する前記進捗管
    理項目のうちの、前記完了予定日時が設定された前記進
    捗管理項目について、前記設定された前記完了予定日
    時、および、前記進捗管理情報である完了日時、のうち
    の一方もしくは両方を表示する表示手段を有する開発支
    援システム。
14. 【請求項１４】請求項８記載の開発支援システムにおい
    て、 前記進捗管理項目格納部に格納されている前記進捗管理
    項目のうちの、少なくとも１以上の前記進捗管理項目
    の、それぞれに対応する処理の完了予定日時を設定する
    進捗管理情報設定部をさらに有し、 前記進捗管理情報参照部は、前記進捗管理情報格納部に
    格納されている前記進捗管理情報に対応する前記進捗管
    理項目のうちの、前記完了予定日時が設定された前記進
    捗管理項目について、前記完了日時が前記設定された完
    了予定日時よりも遅れている前記進捗管理項目を、前記
    完了日時が前記設定された完了予定日時よりも遅れてい
    ない前記進捗管理項目と区別して表示する表示手段を有
    する開発支援システム。
15. 【請求項１５】請求項８記載の開発支援システムにおい
    て、 前記進捗管理項目格納部は、前記製品全体もしくはその
    構成部品についての、機能的特性の計算指示、その指示
    された計算の結果報告、機能的特性の実験指示、およ
    び、その指示された実験の結果報告、のうちの少なくと
    も１つの処理に関する予め定めた項目を、前記管理項目
    として格納する開発支援システム。
16. 【請求項１６】請求項１または２記載の開発支援システ
    ムにおいて、 製品の開発に係る複数の担当者の電子的コミュニケーシ
    ョンの内容から製品開発の活動のモデルや、製品の原
    価、性能、開発日程の目標値を自動的にモニタリングす
    るため、前記複数の計算処理のそれぞれに対応する複数
    の項目を設け、そのうちの１以上の項目を、前記製品の
    開発に係る管理項目として格納する進捗管理項目格納部
    と、 前記複数の計算処理のそれぞれについての、前記予め定
    めた計算機への計算処理指示、および、前記予め定めた
    計算機からの処理結果出力のうちの、少なくとも一方に
    含まれる情報から、前記管理項目についての情報を抽出
    する進捗管理情報モニタリング部と、 前記抽出された情報を格納する進捗管理情報格納部と、 前記格納されている情報を参照するための進捗管理情報
    参照部とを有する開発支援システム。
17. 【請求項１７】製品の開発に係る複数の担当者が、前記
    製品の開発に係る業務に伴い生じる複数の処理を、互い
    に電子的な情報を送受信しながら順次完了する開発作業
    を支援する開発支援システムにおいて、 前記複数の担当者のそれぞれが、前記電子的な情報を送
    受信する、複数の情報処理装置と、 前記複数の情報処理装置のそれぞれと接続して、前記複
    数の情報処理装置について、互いに前記電子的な情報の
    やり取りを可能とする情報ネットワーク装置と、 前記情報ネットワーク装置と接続して、前記複数の情報
    処理装置から送信される前記電子的な情報の流れを制御
    して、前記電子的な情報毎に特定されている送付先の前
    記情報処理装置へ、前記情報ネットワークを介して、前
    記送信された前記電子的な情報を送る電子的な情報配布
    装置と、 前記製品の開発進捗状況のモニタリングする開発進捗モ
    ニタリングシステムとを有し、 前記開発進捗モニタリングシステムは、 前記電子的な情報に含まれる、予め定めた進捗管理項目
    についての情報を抽出する進捗管理情報モニタリング部
    と、 前記抽出された情報を格納する進捗管理情報格納部と、 前記格納されている情報を参照するための進捗管理情報
    参照部とを有する開発支援システム。