JP2010009151A - 設計支援装置、設計支援システム、設計支援方法、及び設計支援プログラム、並びに、コンピュータ読取可能記録媒体 - Google Patents

Abstract

【課題】ユーザ利便性を向上させた設計支援装置、設計支援システム、設計支援方法、及び設計支援プログラム、並びに、コンピュータ読取可能記録媒体を提供すること。
【解決手段】アプリケーションサーバ１８の登録結果配信モジュール４２が、設計者による製品の特定部分（例えば部位βの寸法Ａ）の指定を受けて、特定部分を変化させた場合の変化前の状態と変化後の状態との組み合わせ（例えば、０．５ｍｍ→１．５ｍｍ）に対応したスコアデータや不具合情報などの過去情報（過去情報ＤＢ３２に格納されている）を、設計者端末に提供するので、設計者は、当該過去情報を参照することで、特定部分の変化後の状態を適切に決定することができる。
【選択図】図２

Description

本発明は、概して、製品の設計過程における設計者の支援に用いられる設計支援装置、設計支援システム、設計支援方法、及び設計支援プログラム、並びに、コンピュータ読取可能記録媒体に係り、特に、ユーザ利便性を向上させた設計支援装置、設計支援システム、設計支援方法、及び設計支援プログラム、並びに、コンピュータ読取可能記録媒体に関する。

従来、製品設計の現場においては、製品のすべて又は一部を最初から新規に開発する場面よりも、過去に開発した設計資産を活用し、そこに製品仕様を満たすための何らかの変化を加えることによって新たな仕様に適合させる、いわゆる流用設計が行なわれている。流用設計において、製品設計・製造過程で生じる不具合は、既存の（流用元の）設計資産に変更を加えた部分（設計変化点）において発生する確率が比較的高いと言い得る。このため、近年においては、設計変化点に注目して、そこから生じ得る不具合とその原因を事前に検討・予測し、その結果に基づいて不具合対策を施すことで、早期に設計完成度を高めることを狙いとした手法が取り入れられてきた。

最近は、データベースを利用してこのような設計不具合情報を電子的に蓄積し、検索条件の入力に応じて当該条件に合致する不具合情報を検索結果として出力することを狙いとしたシステムが提案されてきている。

これに対し、設計不具合情報検索システムを構成するデータベースが、設計変化点検討項目毎に階層構造からなるマスタ（例えばシステムレベルマスタ、モジュールレベルマスタ、要素レベルマスタなど）を有することにより、不具合の検索漏れや見落としを防止することを狙いとした技術が提案されている（例えば、特許文献１参照）。

また、設計変化点を基点として、予測される不具合、不具合をもたらす影響、不具合への対策が相関関係を有する紐付け情報として登録された設計品質管理情報を用いて、特定製品に依存しない設計変化点データベースを実現し、これを用いることにより不具合対策を行うことを狙いとした技術も提案されている（例えば、特許文献２参照）。

特開２００５−３４６４８３号公報 特開２００５−１４９１４２号公報

しかしながら、上記従来技術では、製品の一部の構造を変更した場合の故障モードが検索されたり、特定の製品に限定することなく設計変化点に関する知識を広く活用することとしているが、設計者はこれらの情報を検索することはできるものの、この情報を使って実際にどのような設計をすれば良いのかを簡易かつ詳細に把握することができない。

また、上記特許文献２のように特定の製品に限定することなく、設計変化点に関する知識を様々な製品で広く活用しようとすると、不具合が生じた場合に得られた実測値を、そのまま別の製品に活用することができないという事態が生じることが想定される。具体的には、不具合が生じた場合に得られた実測値や実測結果が、ある部位の長さに関する数値や、ある部位の材料名であったとしても、その情報を別の製品の対応部分にそのまま活用することは難しく、別の製品に活用するには、長さに関する数値をある部分を基準とした比率で表したり、材料を性質（例えば硬度など）に基づいて数値化したりするなど、実測値等を一般化する必要があると考えられる。加えて、この一般化した数値を、現在設計を行っている製品に適用する場合には、製品の寸法や材料等に対応するように具体的な数値や材料等に換算・変換する必要があるため、設計に手間と時間を要するおそれがある。

そこで、本発明は上記の課題に鑑みてなされたものであり、ユーザ利便性を向上させた設計支援装置、設計支援システム、設計支援方法、及び設計支援プログラム、並びに、コンピュータ読取可能記録媒体を提供することを主たる目的とする。

上記課題を解決するための本発明の第１の態様は、製品の設計過程で生じる設計変化点ごとに、変化前の状態と変化後の状態との組み合わせに関連付けて過去情報が記憶された記憶手段と、設計者による前記製品の特定部分の指定を受けて、前記特定部分を変化させた場合の変化前の状態と変化後の状態との組み合わせに対応した過去情報を、前記記憶手段から前記設計者に提供する過去情報提供手段と、を備える設計支援装置である。

上記第１の態様によれば、過去情報提供手段が、設計者による製品の特定部分の指定を受けて、特定部分を変化させた場合の変化前の状態と変化後の状態との組み合わせに対応した過去情報を、設計者に提供するので、設計者は当該過去情報を参照することで、特定部分の変化後の状態を適切に決定することができる。このように、設計者による特定部分の変化後の状態の決定を支援することができるので、設計者（ユーザ）の利便性を向上することが可能となる。

上記第１の態様では、前記過去情報は、変化前の状態と変化後の状態との組み合わせに関する実績値のスコア情報を含むこととすることができる。かかる場合には、特定部分の変化内容を決定するために、過去の実績値を提供することで、設計者（ユーザ）の利便性を向上することができる。この場合、前記スコア情報には、前記実績値の信頼度が含まれていても良く、かかる場合には、更に設計者（ユーザ）の利便性を向上することができる。ここで、「スコア情報」とは、変化前の状態と変化後の状態との組み合わせに関する実績を示す様々な指標を示す情報であり、一例として、変化前と変化後の状態を示す「変化内容」、その変化が過去に何件あったかを示す「実績件数」、後述する「信頼度」、変化において不具合が生じた件数を示す「不具合総件数」、恒久対策がすでに実行されている不具合件数を示す「恒久対策済不具合件数」、恒久対策が未だ実行されていない不具合件数を示す「恒久対策未不具合件数」、不具合が生じた直近の日を示す「最新不具合発生日」などの種々の情報を含むものである。また、実績値の「信頼度」とは、過去の実績値をどの程度信頼して良いかを示す指標である。例えば、出図業務が行われてからの経過時間が大きいほど、製品の熟成が進んでいるという観点から、出図業務からの経過時間を指標として、信頼度を定義することが可能である。また、製造工程が進行するほど不具合等に対する検討がされていると考えられるので、製造工程の進行度合いを指標として、信頼度を定義することも可能である。また、製品の生産数が増えるほど当該製品の熟成が進んでいるという観点から、製品の生産数を指標として、信頼度を定義することも可能である。また、製品の開発等に関わる人や工場によっても、製品の信頼性は異なるので、開発工場や開発チームなどにおける開発の信頼度を示す度合い（人数や体制、過去の開発成績などの開発能力、該当地域などで分類したもの。ランクとも呼ばれる）を指標として、信頼度を定義することも可能である。また、上記に限らず、製品の熟成度や製品に関わる人や装置などに応じた種々の指標を用いて、信頼度を定義することも可能である。

上記第１の態様では、前記過去情報は、前記変化前の状態と前記変化後の状態との組み合わせに関連する事例情報を含むこととすることができる。かかる場合には、前記変化前の状態と前記変化後の状態との組み合わせに関連する事例情報（事例の内容）を提供することで、設計者（ユーザ）の利便性を向上することができる。また設計者（ユーザ）の利便性の観点から、前記過去情報は、前記変化前の状態と前記変化後の状態との組み合わせに対する関連度毎に、複数種類の事例情報を含むこととしても良い。更には、前記複数種類の事例情報は、前記変化前の状態、前記変化後の状態、及び変化の種類、のすべてが一致する第１の事例情報と、前記変化の種類と、前記変化前の状態及び前記変化後の状態のいずれかと、が一致する第２の事例情報と、前記変化前の状態、前記変化後の状態、及び変化の種類のいずれか一つが一致する第３の事例情報と、の少なくとも１つを含むこととしても良い。このように、複数の過去情報を重要度等に応じて差別化することにより、設計者による過去情報の閲覧の効率化を支援することができる。

また、上記のように、過去情報に複数種類の事例情報が含まれる場合には、前記過去情報提供手段は、前記複数種類の事例情報のうちの特定の事例情報が前記設計者により閲覧されなかった場合には、前記設計者に対して警告を発することとしても良い。例えば重要度が比較的高い過去情報が閲覧されなかった場合に設計者に対して警告を発することで、設計において最低限必要とされる過去情報の設計者による確認漏れを抑制することも可能である。

上記第１の態様では、前記製品の部分ごとの、前記変化に関する標準情報を保持する標準情報保持手段と、前記記憶手段に記憶された過去情報に基づいて、前記標準情報の改訂情報を出力する改訂情報出力手段と、を更に備えることができる。改訂情報出力手段が、記憶された過去情報に基づいて標準情報の改訂情報を出力することにより、ユーザによる標準情報の改訂作業の利便性が向上する。ここで、前記過去情報には、前記設計変化点において不具合が発生した失敗情報と、前記設計変化点において不具合が発生しなかった成功情報とが含まれても良く、前記改訂情報出力手段は、前記成功情報と失敗情報とに基づいて、前記標準情報の改訂情報を出力することとしても良い。このうち、「失敗情報」とは、不具合が発生した件数や発生頻度、不具合の発生個所・内容のみならず、その不具合対策を行った場合の結果（対応工数や影響度）などの情報も含む概念である。更に、前記改訂情報出力手段は、前記過去情報のうち前記変化後の状態が前記標準情報の範囲内にある場合における失敗情報の数量情報と、前記過去情報のうち前記変化後の状態が前記標準情報の範囲外にある場合における成功情報の数量情報と、の少なくとも一方を前記改訂情報として出力することとしても良い。このような数量情報を出力することで、ユーザによる標準情報の改訂作業の利便性が向上する。また、前記改訂情報出力手段は、前記過去情報のうち前記変化後の状態が前記標準情報の範囲内にある場合における失敗情報の数量と、前記過去情報のうち前記変化後の状態が前記標準情報の範囲外にある場合における成功情報の数量と、の少なくとも一方に基づいて、前記標準情報の改訂を行うか否かの判断を行うこととしても良い。

本発明の第２の態様は、製品の設計を行う設計者が使用する情報処理手段と、前記製品の設計過程で生じる設計変化点ごとに変化前の状態と変化後の状態との組み合わせに関連付けて過去情報が記憶された記憶手段と、前記情報処理手段における前記製品の特定部分の指定を受けて、前記特定部分を変化させた場合の変化前の状態と変化後の状態との組み合わせに対応した過去情報を、前記記憶手段から前記情報処理手段に対して送信する過去情報提供手段と、を備える設計支援システムである。

上記第２の態様によれば、過去情報提供手段が、設計者による製品の特定部分の指定を受けて、特定部分を変化させた場合の変化前の状態と変化後の状態との組み合わせに対応した過去情報を、情報処理手段に提供するので、情報処理手段を使用する設計者は当該過去情報を参照することで、特定部分の変化後の状態を適切に決定することができる。このように、設計者による特定部分の変化後の状態の決定を支援することができるので、設計者（ユーザ）の利便性を向上することが可能となる。

上記第２の態様では、前記過去情報は、変化前の状態と変化後の状態との組み合わせに関する実績値のスコア情報を含むこととすることができ、また、当該スコア情報には、前記実績値の信頼度が含まれることとすることができる。

また、上記第２の態様では、前記過去情報は、前記変化前の状態と前記変化後の状態との組み合わせに関連する事例情報を含むことができ、更には、前記変化前の状態と前記変化後の状態との組み合わせに対する関連度毎に、複数種類の事例情報を含むこととすることもできる。

また、上記第２の態様では、前記製品の部分ごとの、前記変化に関する標準情報を保持する標準情報保持手段と、前記記憶手段に記憶された過去情報に基づいて、前記標準情報の改訂情報を出力する改訂情報出力手段と、を更に備えることができる。改訂情報出力手段が、記憶された過去情報に基づいて標準情報の改訂情報を出力することにより、ユーザによる標準情報の改訂作業の利便性が向上する。更に、前記過去情報には、前記設計変化点において不具合が発生した失敗情報と、前記設計変化点において不具合が発生しなかった成功情報とが含まれることとし、前記改訂情報出力手段は、前記成功情報と失敗情報とに基づいて、前記標準情報の改訂情報を出力することとしても良い。また、前記改訂情報出力手段は、前記過去情報のうち前記変化後の状態が前記標準情報の範囲内にある場合における失敗情報の数量情報と、前記過去情報のうち前記変化後の状態が前記標準情報の範囲外にある場合における成功情報の数量情報と、の少なくとも一方を前記改訂情報として出力することとしても良い。このような数量情報を出力することで、ユーザによる標準情報の改訂作業の利便性が向上する。

本発明の第３の態様は、設計者による製品の特定部分の指定を受けるステップと、前記製品の設計過程で生じる設計変化点ごとに、変化前の状態と変化後の状態との組み合わせに関連付けて記憶された過去情報から、前記設計者による指定に応じ過去情報を、前記設計者に提供するステップと、を含む設計支援方法である。

上記第３の態様によれば、提供するステップで、設計者による製品の特定部分の指定を受けて、特定部分を変化させた場合の変化前の状態と変化後の状態との組み合わせに対応した過去情報を、設計者に提供するので、情報処理手段を使用する設計者は当該過去情報を参照することで、特定部分の変化後の状態を適切に決定することができる。このように、設計者による特定部分の変化後の状態の決定を支援することができるので、設計者（ユーザ）の利便性を向上することが可能となる。

本発明の第４の態様は、コンピュータによって実行されたときに、当該コンピュータを、製品の設計過程で生じる設計変化点ごとに、変化前の状態と変化後の状態との組み合わせに関連付けた過去情報の中から、設計者により指定された前記製品の特定部分を変化させた場合の変化前の状態と変化後の状態との組み合わせに対応した過去情報を、前記設計者に提供する過去情報提供手段として機能させることを特徴とする設計支援プログラムである。

上記第４の態様によれば、設計者による製品の特定部分の指定を受けて、特定部分を変化させた場合の変化前の状態と変化後の状態との組み合わせに対応した過去情報を、設計者に提供するので、設計者は当該過去情報を参照することで、特定部分の変化後の状態を適切に決定することができる。このように、設計者による特定部分の変化後の状態の決定を支援することができるので、設計者（ユーザ）の利便性を向上することが可能となる。

本発明の第５の態様は、本発明の設計支援プログラムを記録したコンピュータ読取可能記録媒体である。

本発明の設計支援装置及び方法、設計支援システム、並びにプログラム及び記録媒体は、ユーザの利便性を向上させることができるという効果を奏する。

以下、本発明の設計支援システムの一実施形態について図１〜図２２に基づいて詳細に説明する。

図１は、本実施形態に係る設計支援システム１００の概略構成を示す図である。この設計支援システム１００は、ある機器のある部位の寸法や形状、材質、色彩等様々な要素の設計において、設計者を支援するためのシステムである。この設計支援システム１００は、図１に示すように、複数の設計者端末１０と、管理者端末１２と、登録者端末１４と、データベースサーバ１６と、アプリケーションサーバ１８と、を備えている。これら端末１０，１２，１４及びサーバ１６，１８は、ＬＡＮやＷＡＮ、あるいはインターネット等のネットワーク２０によって接続されている。

設計者端末１０は、ＰＣ（Personal Computer）から構成される。なお、設計者端末１０としては、携帯電話やＰＤＡ（Personal Digital Assistants）等を採用しても良い。また、図１では、設計者端末１０を複数台（ここでは一例として３台）用意しているが、設計者端末１０は１台であっても良い。

管理者端末１２及び登録者端末１４も、設計者端末１０と同様にＰＣ等から構成される。

データベースサーバ１６は、設計支援に必要な各種データを記憶するものであり、図２に示すように、検討項目データベース（ＤＢ）２２、チェック項目ＤＢ２４、機能・構造（部品）ＤＢ２６、標準ＤＢ２８、変化点実績ＤＢ３０、過去情報ＤＢ３２等を有している。

検討項目ＤＢ２２は、図６に一例を示すような検討項目の一覧５０を格納している。チェック項目ＤＢ２４は、図７に一例を示すようなチェック項目表５２を格納している。機能・構造（部品）ＤＢ２６は、構造や部品に関する情報、画像等を格納している。標準ＤＢ２８は、構造や部品に関する標準（基準範囲情報）を格納している。この標準には、構造や部品の寸法は勿論、材質や質量、パラメータにより設定できる項目（例えば、ばね定数など）が含まれる。また、変化点実績ＤＢ３０は、図９に一例を示すスコアデータ５６を格納している。また、過去情報ＤＢ３２は、図２２に示す不具合情報５８（確認必須情報、確認推奨情報、参考情報を含む）を格納している。

図２に戻り、アプリケーションサーバ１８は、いわゆるコンピュータ、すなわち、ＣＰＵやＳＲＡＭ、ＤＲＡＭなどのＲＡＭ、フラッシュメモリ等のＲＯＭ等を有しており、複数のモジュール（図２に示す、情報登録モジュール４０、登録結果配信モジュール４２、過去情報管理モジュール４４、スコアデータ管理モジュール４６、チェック項目更新モジュール４８）を含んでいる。

このうち、情報登録モジュール４０は、後述する不具合事例の登録等の処理を実行するモジュールであり、登録結果配信モジュール４２は、設計者端末１０に設計者が入力したデータに応じて、データベースサーバ１６内に記憶されているデータを適宜提供して設計者の設計を支援するモジュールである。また、過去情報管理モジュール４４は、過去情報ＤＢ３２に格納されている過去情報（不具合情報を含む）を管理するモジュールであり、スコアデータ管理モジュール４６は、変化点実績ＤＢ３０に格納されているスコアデータ５６を管理するモジュールであり、チェック項目更新モジュール４８は、チェック項目ＤＢ２４に格納されているチェック項目表５２を適宜更新するモジュールである。

次に、本実施形態の設計支援システム１００において行われる設計支援方法について図３、図４のフローチャートに沿って、その他図面を適宜参照しつつ説明する。なお、以下においては、一例として、図５に示すように流用元機種がα−１であり、関連機種がα−２等であるものとして説明する。

図３のフローチャートの処理は、設計者が、設計者端末１０において設計支援ソフトウェア（コンピュータプログラム）を立ち上げたときに開始される。まず、図３のステップＳ１０では、アプリケーションサーバ１８の登録結果配信モジュール４２が、検討項目ＤＢ２２から検討項目の一覧を抽出して、設計者端末１０に送信し、設計者端末１０の画面上に表示する。この場合の設計者端末１０における表示状態の一例が、図６に示されている。この図６に示すように、検討項目の一覧５０には、「部位βの検討」や「部位γの検討」などの項目が含まれている。なお、部位βは、一例として、図５に示すような形状を有する部位であるものとする。

次いで、登録結果配信モジュール４２は、図３のステップＳ１２において、設計者による検討項目の選択が行われるまでの間、待機する。この場合、設計者は、図６の表示がなされた後、検討項目の一覧５０の中から一の項目を、マウスやキーボードを用いて選択することができる。登録結果配信モジュール４２では、設計者による選択が行われた段階で、ステップＳ１４に移行する。なお、ここでは、設計者は、検討項目の一覧５０の中から「部位βの検討」を選択したものとする。

次のステップＳ１４では、登録結果配信モジュール４２が、選択された検討項目に応じたチェック項目表を、チェック項目ＤＢから抽出して設計者端末１０に送信し、設計者端末１０上に表示する。この場合の設計者端末１０における表示状態の一例が、図７に示されている。この図７に示すように、チェック項目表５２には、「チェック内容」、「標準」、「流用元実績」、「検討値」の項目が含まれている。

このうち、「チェック内容」には、部位βの寸法Ａ，Ｂ，Ｃのうち、どの寸法を検討するかなどが表示され、「標準」には、各部位の寸法や材質など、各部位を設定する際の標準となる範囲が表示されている。また、「流用元実績」には、流用設計の元となる機種の寸法や材質などの実績値と、その実績値が成功例（ＯＫ）であったか、失敗例（ＮＧ）であったかを示す実績ステータスが表示されている。なお、「検討値」の欄は、設計者が任意の値を入力できるように、空白となっている。

また、設計者端末１０の画面上のチェック項目表５２の下には、流用元機種の開発ステージが表示されている。ここで、開発ステージについて、説明する。

開発ステージは、図８に示すように、ここでは一例としてステージ１〜ステージ４が設定されており、ステージの数値が大きいほど信頼性（信頼度）が高いことを意味している。この場合、設計者等は、様々な要素を指標としてステージを区分することができる。例えば、図８に示すように、出図業務からの経過時間を信頼性の指標とすることができる。この場合、出図業務が行われてからの時間が経過するほど、その製品が製造される数量が増えるため、その製品に対する検討回数が増し、製品の熟成度が増すと考えられる。したがって、図８に一例として示すように、先行検討から出図業務が行われるまでの間を最も低い信頼性（ステージ１）と取り扱い、出図から１２ヶ月以上経過した場合を最も高い信頼性（ステージ４）と取り扱うなどすることができる。また、これに限らず、信頼性の指標として、図８に示すように、工程の進行度合いを用いることも可能である。この場合、工程が進行するほど、製品が完成に近づくことを意味し、製品が完成に近づくほど、製品の不具合の検討等が進み、製品の熟成が図られていると考えられる。したがって、図８に一例として示すように、製品設計工程にある段階を最も低い信頼性（ステージ１）とし、生技・金型設計工程、金型製造工程、成型工程と進むにつれて、信頼性を高く（ステージ２，３，４）取り扱うことができる。また、信頼性の指標としては、図８に示すように、累積生産数を用いることも可能である。累積生産数が増えるほど、製品の不具合などに関する検討も多く行われ、信頼性が高くなっていると考えられるからである。この場合、図８に一例として示すように、生産前（累積生産数０）を最も低い信頼性（ステージ１）とし、累積生産数が、１〜１０００個、１０００１〜２００００個、２００００個以上となるにつれて、信頼性を高く（ステージ２，３，４）取り扱うことができる。更に、開発工場や開発チームなどを開発の信頼度を示す度合い（人数や体制、過去の開発成績などの開発能力、該当地域などで分類したもの。以下「ランク」と呼ぶ）で分類し、そのランク（Ａ以上〜Ｄ）に応じて、ステージを設定することも可能である。なお、これらどの基準を用いてステージを設定するかは、設計者などのユーザが自由に決定することが可能である。また、複数の指標を用いてステージを判断することとしても良い。この場合、指標ごとに異なるステージにあると判断された場合には、例えば、各ステージのうちの最も低いステージを開発ステージとして用いることとすることができる。また、これに限らず、例えば、各ステージの平均値を開発ステージとして用いることも可能である。なお、図７の例では、流用元となっている機種のランクが「ステージ４」というランクに属するものであることが表示されている。

次いで、ステップＳ１６では、登録結果配信モジュール４２が、設計者によるチェック項目の選択があったか否かを判断する。この場合、例えば、図７に一例を示すように、設計者が、検討したい「チェック内容」の欄（ここでは、「寸法Ａを設定すること」）にマウスポインタを合わせて（マウスポインタ１０１参照）クリックすることにより選択が行われる。

このステップＳ１６の判断が否定された場合には、ステップＳ２０に移行して、登録結果配信モジュール４２が、チェック項目の中の検討値に設計者が数値を入力したか否かを判断するが、ここでの判断が否定されると、ステップＳ１６に戻る。その後チェック項目の選択があったと判断された場合には、ステップＳ１６の判断が肯定されてステップＳ２２に移行する。他方、ステップＳ２０において検討値が入力されたと判断された場合には、図４のステップＳ４８に移行する。

ステップＳ２２では、登録結果配信モジュール４２が、選択されたチェック項目についてのスコアデータを変化点実績ＤＢ３０から抽出して、設計者端末１０上に表示する。この場合、図９に一例を示すようなスコアデータ５６がチェック項目の右隣に表示される。本実施形態においては、一例として、スコアデータには、「変化内容」、「実績件数」、「信頼度」、「不具合総件数」、「恒久対策済不具合件数」、「恒久対策未不具合件数」、「最新不具合発生日」の項目が含まれるものとする。ただし、スコアデータの項目は、これらに限られるものではなく、設計者等のユーザが、自由に設定、変更することが可能である。

このうち、「変化内容」には、変化（変更）前の状態と、変化（変更）後の状態が記載され、「実績件数」には、その変化内容と一致する変化（変更）が、過去に、どれだけ行われたかが記載されている。

また、「信頼度」には、変化内容の信頼度の指標の一例として、Ａ，Ｂ，Ｃ，Ｄ及び斜線のいずれかが表示される。ここで、「信頼度」について、図１０に基づいて説明する。この信頼度は、ステージ１〜４との関係を考慮して決定されるものであり、図１０の判断条件に基づいて決定される。この図１０に示すように、ステージ１で過去に不具合がない場合には「信頼度Ｄ」となり、ステージ２で過去に不具合がない場合には「信頼度Ｃ」となり、ステージ３で過去に不具合がない場合には「信頼度Ｂ」となり、ステージ１で過去に不具合がない場合には「信頼度Ａ」となり、開発ステージに関わらず過去に１件でも不具合（ＮＧ）があった場合には、信頼度の対象からは外れるので、信頼度の欄には斜線が付される。また、実績件数が増えると、信頼度Ａ，Ｂ，Ｃ，Ｄの複数の信頼度の条件を満たすこともあるが、このような場合には、最も低い信頼度を図９の信頼度の欄に表示することとする。ただし、これに限られるものではなく、例えば、複数の信頼度の平均を信頼度の欄に表示することとしても良い。具体的には、ステージ１とステージ３で不具合がなかった場合には、信頼度Ｃを信頼度の欄に表示するなどすることができる。また、例えば、複数の信頼度をその実績件数に応じて重み付けし、その重み付け平均を信頼度の欄に表示することとしても良い。具体的には、ステージ１における成功事例が２件、ステージ４における成功事例が４件あった場合には、重み付け平均が（１×２＋４×４）／６＝３となるので、ステージ３に対応する信頼度Ｂを信頼度の欄に表示するなどすることができる。

図９に戻り、「不具合総件数」には、その変化内容を行った場合において過去にどれだけ不具合が発生したかが記載され、「恒久対策済不具合件数」及び「恒久対策未不具合件数」には、不具合が発生した場合に恒久対策の対応が完了した件数及び恒久対策の対応が完了していない件数が記載されている。

また、「最新不具合発生日」には、不具合が発生した年月日のうち直近のものが記載されている。なお、「実績件数」は、不具合総件数（失敗数（ＮＧ数））と成功総件数（ＯＫ数）との和を意味している。すなわち、本実施形態では、過去の事例のうち、ＮＧ数とＯＫ数の両方を取得し、その合計を表示することとしている。また、図９のスコアデータ５６は、「実績件数」や「不具合総件数」などの項目名をクリックすることにより、クリックした項目に関して昇順又は降順となるように上下の表示順を並べ替えることができるようになっている。これにより、設計者は、スコアデータを様々な視点から検討することが可能となっている。

なお、上記においては、予め作成しておいたスコアデータ５６を変化点実績ＤＢ３０に格納しておき、設計者により選択されたチェック項目についてのスコアデータを、登録結果配信モジュール４２が変化点実績ＤＢ３０から抽出して、設計者端末１０上に表示する場合について説明したが、これに限られるものではない。例えば、変化点実績ＤＢ３０に、スコアデータ５６を構成しうる種々のデータ群を格納しておくこととし、設計者によりチェック項目が選択された段階で、当該チェック項目に応じて、それらのデータ群のダイジェスト版のような形態で、スコアデータをその都度作成（データの算出・演算・抽出・整理など）して、表示することとしても良い。

次いで、図３のステップＳ２４においては、登録結果配信モジュール４２が、設計者によるスコアデータの変化内容が選択されたか否かを判断する。この場合の選択は、「変化内容」の項目のうちの、検討したい内容を設計者がクリックすることにより行われる（図９のマウスポインタ１０２参照）。

ステップＳ２４での判断が否定された場合には、ステップＳ２６に移行して、登録結果配信モジュール４２が、設計者による実績件数の選択があったか否かを判断する。この場合の実績件数の選択は、図９において破線で示す部分を設計者がクリックすることにより行われる（マウスポインタ１０３参照）。ステップＳ２６の判断が肯定された場合には、ステップＳ２８に移行して、登録結果配信モジュール４２が、実績件数に関するグラフ表示を行う。この場合の実績件数に関するグラフは、図１１に示すようなグラフであり、上段のグラフは、各開発ステージにおいて寸法Ａを０．５ｍｍから１．５ｍｍに変化させた場合の成功事例数（ＯＫ数）と失敗事例数（ＮＧ数）を示している。また、中段のグラフは、各開発ステージにおいて寸法Ａを０．５ｍｍから１．０ｍｍに変化させた場合の成功事例数（ＯＫ数）と失敗事例数（ＮＧ数）を示している。更に、下段のグラフは、各開発ステージにおいて寸法Ａを０．５ｍｍから０．４ｍｍに変化させた場合の成功事例数（ＯＫ数）と失敗事例数（ＮＧ数）を示している。

なお、図１１の上段のグラフ（０．５ｍｍ→１．５ｍｍ）では、開発ステージに関わらず過去に不具合（ＮＧ）があったため、信頼度は斜線となる（図９参照）。また、図１１の中段のグラフ（０．５ｍｍ→１．０ｍｍ）では、ステージ１〜ステージ４において過去に不具合が発生していないため、信頼度Ａ〜信頼度Ｄのすべての条件を満たすが、このような場合の信頼度は、このうちの最も低い信頼度Ｄとなる(図９参照)。また、図１１の下段のグラフ（０．５ｍｍ→０．４ｍｍ）では、ステージ３において過去に不具合が発生していないため、信頼度はＢとなる(図９参照)。

次のステップＳ３０では、登録結果配信モジュール４２が、設計者による「切替」の選択があったか否かを判断する。この場合の選択は、図１１の右上に表示されている「リスト表示に切替」のボタンを設計者がクリックすることにより行われる。ステップＳ３０の判断が肯定されると、ステップＳ３２に移行し、登録結果配信モジュール４２が表示切替を行う。この場合、図１１のグラフ表示から図１２に示す実績に関するリスト表示が行われる。このリストは、「変化内容」、「機種名」、「開発ステージ」、「実績ステータス」、「不具合発生日時」、「恒久対策」の項目を含んでいる。なお、図１１のグラフ表示を行うことにより、当該グラフ表示を見た設計者が、各組み合わせのステージごとの実績件数を比較考慮することができるというメリットがある。また、図１２のリスト表示を行うことにより、設計者は、各組み合わせの機種名や不具合発生日時を比較考慮することができるというメリットがある。

次いで、ステップＳ３４では、「閉じる」が選択されたか否かを判断する。この場合の選択は、図１２の右上に表示されている「閉じる」ボタンを設計者がクリックすることにより行われる。なお、「閉じる」ボタンが選択されなかった場合には、ステップＳ３０に戻り、切替表示の選択があったか否かを判断し、選択があった場合には、ステップＳ３２においてグラフ表示からリスト表示に切り替えて、再度ステップＳ３４に移行する。その後、図１１の「閉じる」ボタン又は図１２の「閉じる」ボタンがクリックされて、ステップＳ３４の判断が肯定されると、ステップＳ３６に移行する。

ステップＳ３６では、登録結果配信モジュール４２が、チェック項目の中の検討値に設計者が数値を入力したか否かを判断するが、ここでの判断が否定されると、ステップＳ２４に戻る。その後、図９のスコアデータ５６上で変化内容の選択があったと判断された場合には、ステップＳ２４の判断が肯定されてステップＳ３８に移行する。一方、ステップＳ３６において、検討値が入力されたと判断された場合には、判断が肯定されて図４のステップＳ４８に移行する。なお、ここでは、一例として図９のマウスポインタ１０２に示すように、「変化内容」の項目のうち「０．５→１．５」が選択されたこととし、ステップＳ２４の判断が肯定された後、ステップＳ３８に移行したものとする。

次いで、図３のステップＳ３８では、登録結果配信モジュール４２が、過去情報ＤＢ３２から、不具合情報を抽出して、設計者端末１０に送信し、当該設計者端末１０の画面上に例えばその関連度の高い順に表示する。

これについて具体的に説明すると、図１３に一例を示すように、不具合情報は、関連度が高い順に「確認必須」情報、「確認推奨」情報、「参考」情報に分類される。このうち、例えば、「確認必須」情報は、設計者が選択した変化内容と、変化前の状態（ここでは０．５ｍｍ）、変化後の状態（ここでは、１．５ｍｍ）、変化行為（ここでは、寸法の変更）の全てが一致する事例情報である。また、「確認推奨」情報は、「確認必須」情報よりも関連度が比較的低いものであり、設計者が選択した変化内容と、変化前の状態及び変化行為が一致する事例情報、あるいは、設計者が選択した変化内容と、変化後の状態及び変化行為が一致する事例情報である。更に、「参考」情報は、「確認推奨」情報よりも関連度が比較的低いものであり、設計者が選択した変化内容と、変化前の状態、変化後の状態、変化行為のいずれか１つが一致する事例情報である。

上記のような不具合情報が表示された後、図４のステップＳ４０では、登録結果配信モジュール４２が、設計者による不具合情報の選択があったか否かを判断する。ここでは、図１３に示すように、不具合情報（例えば確認必須情報）をクリックすることにより、不具合情報の選択を行うことができる。

このステップＳ４０における判断が否定された場合、ステップＳ４２に移行して、登録結果配信モジュール４２が、チェック項目の中の検討値に設計者が数値を入力したか否かを判断するが、ここでの判断が否定されると、ステップＳ４０に戻る。その後、不具合情報の選択があったと判断された場合には、ステップＳ４０の判断が肯定されてステップＳ４４に移行し、検討値が入力されたと判断された場合には、ステップＳ４２の判断が肯定されてステップＳ４８に移行する。

ステップＳ４４では、登録結果配信モジュール４２が、過去情報ＤＢ３２から不具合情報の詳細を抽出して、設計者端末１０の画面上に表示する。この場合、図１４（ａ）に一例を示すような、不具合情報の詳細６０がポップアップ表示される。この不具合情報の詳細６０には、不具合の具体的な内容、不具合に対する対応内容（修正内容）が詳細に記載されている。

設計者は、図１４（ａ）の不具合情報の詳細６０を確認した後は、図１４（ｂ）に示すように、ウィンドウを閉じるボタンをクリックすることにより、不具合情報の詳細６０を非表示とすることができる。

次いで、登録結果配信モジュール４２は、図４のステップＳ４６において、チェック項目表５２の中の検討値の欄に、設計者により数値が入力されるまでの間、待機する。そして、このステップＳ４６の判断が肯定された場合、あるいは、前述した図３のステップＳ２０、Ｓ３６，図４のステップＳ４２のいずれかにおいて判断が肯定された場合に、ステップＳ４８に移行する。

なお、本実施形態では、設計者が、図１４（ａ）の不具合情報の詳細６０の内容を確認した結果、寸法Ａは、１．０ｍｍにするのが好ましいと考えたものとする。そして、当該検討の結果、設計者は、図１５に示すように、チェック内容「寸法Ａを設定すること」の検討値の欄に「１．０」を入力したものとする。ここで、検討値の欄には、図１１のグラフや図１５の「変化内容」などに表示されている数値「０．５」、「１．０」、「０．４」以外の数値を入力することも勿論可能である。すなわち、本実施形態では、図１１や図１５に表示されている数値の中から適切と考えられる数値を選択して検討値の欄に入力する場合に限らず、設計者端末１０上に表示される様々な過去の実績情報を検討した結果、どのような場合にどのような不具合が発生するかといった考察を経て、上記３つの数値以外の数値を検討値の欄に入力することも可能である。

なお、情報登録モジュール４０は、ステップＳ４６において検討値の入力があった段階で、変化内容のステータスをＯＫと仮定して、検討値を変化点実績ＤＢ３０に格納する。

次いで、ステップＳ４８では、登録結果配信モジュール４２が、過去情報ＤＢ３２を参照して、ステップＳ３５にて入力された検討値に関する不具合情報があるか否か、すなわち、変化内容「０．５ｍｍ→１．０ｍｍ」に関する不具合情報があるか否かを判断する。

ここで、図１５に一例として示されているスコアデータによれば、「０．５ｍｍ→１．０ｍｍ」に関する不具合情報は存在していない（不具合総件数の項目が「０」である）ので、ここでの判断は否定され、図３の処理を終了する。すなわち、寸法Ａの検討値を「１．０ｍｍ」で確定して、全処理を終了する。

一方、ステップＳ４８において、検討値に関する不具合情報が存在していた場合（例えば、検討値として「１．５ｍｍ」を入力したような場合）には、ステップＳ４８の判断が肯定され、ステップＳ５０に移行する。そして、次のステップＳ５０では、登録結果配信モジュール４２が、検討値に対する確認必須情報を表示したか、すなわち、ステップＳ４４を経ることにより、確認必須情報が表示されたか否かを判断する。ここでの判断が肯定された場合には、図４の処理を終了するが、判断が否定された場合には、ステップＳ５２において、登録結果配信モジュール４２が、図１６に示すように、確認必須情報（不具合情報の詳細）を強制的に表示する。なお、この場合、不具合情報の詳細とともに、「確認ボタン」と、「再検討ボタン」とを表示することとしている。このように、「確認ボタン」とともに「再検討ボタン」を表示するのは、強制的に表示した確認必須情報を見た設計者に検討値を変更する機会を提供するためである。

次いで、登録結果配信モジュール４２は、ステップＳ５４において、「確認ボタン」と「再検討ボタン」のいずれかが設計者により選択されるまでの間、待機する。そして、いずれかのボタンが選択されると、ステップＳ５６に移行し、登録結果配信モジュール４２が、選択されたボタンが「確認ボタン」であったか否かを判断する。ここでの判断が肯定された場合には、図３、図４の全処理を終了し、ここでの判断が否定された場合には、ステップＳ４６からやり直す。

以上のように、図３、図４の処理を実行することにより、設計者は、過去の不具合情報を参照しながら、検討値を決定することができるので、不具合が発生する可能性が比較的高いと考えられる検討値が設定されるのを未然に防止することが可能である。

次に、図３、図４の処理において用いられた過去情報（不具合情報やスコアデータ）を、過去情報ＤＢ３２や変化点実績ＤＢ３０に予め登録しておくための処理について、図１７、及び図１８のフローチャートに沿って説明する。なお、この登録処理は、設計者端末１０、管理者端末１２、及び登録者端末１４を用いて行われるものであり、換言すれば、登録処理には、設計者、管理者、登録者の三者が関わることになる。

設計者が設計を行っている間に不具合を発見した場合において、設計者が設計者端末１０を起動して、不具合登録用ソフトウェア（コンピュータプログラム）を立ち上げると、ステップＳ６０において、アプリケーションサーバ１８の情報登録モジュール４０が、機能・構造（部品）ＤＢ２６から発生箇所リスト及び不具合リストを抽出して、設計者端末１０上に表示する。ここで、発生箇所リストは、「部位β」や「部位γ」のような部位名称が含まれ、不具合リストには、「ヒケ」や「亀裂」などの不具合の名称が含まれる。

次いで、情報登録モジュール４０は、ステップＳ６２において、ステップＳ６０で表示したリストを用いた設計者による選択が行われるまでの間、待機する。

そして、設計者による選択がなされた段階で、ステップＳ６４に移行し、情報登録モジュール４０が、過去情報ＤＢ３２から関連する不具合情報を表示する。この場合の関連する不具合情報は、図１４（ａ）の不具合情報の詳細６０と略同一の内容であり、不具合の事象の詳細や不具合に対する対策事例が含まれる。

設計者は、この関連する不具合情報に基づいて、現在発生している不具合に対する暫定対策を検討するとともに、当該暫定対策を実際に実行する。そして、その暫定対策の結果が明らかとなった段階で、設計者は、設計者端末１０上からその結果を登録する。

次のステップＳ６６では、情報登録モジュール４０が、対策結果が登録されたか否かを判断する。ここでの判断が肯定された場合には、ステップＳ７４に移行するが、判断が否定された場合には、ステップＳ６８に移行して、納期が過ぎたか否かを判断する。この段階で納期が過ぎていなかった場合には、ステップＳ６６に戻り、対策結果の登録がない間は、納期が過ぎるまでステップＳ６８、Ｓ７０を繰り返す。

そして、対策結果の登録がないまま納期が過ぎた場合には、ステップＳ６８の判断が肯定されるので、情報登録モジュール４０は、次のステップＳ７０において、設計者端末１０に対して警告を発する。この場合の警告方法としては、画面上への直接的な警告表示を採用しても良いし、電子メール等を介した警告情報の配信やスピーカを介した警告音の出力、あるいはこれらの組み合わせを採用しても良い。

上記のようにして警告を行った後、情報登録モジュール４０は、ステップＳ７２において、設計者による対策結果の登録が行われるまでの間待機し、登録が行われた段階で、ステップＳ７４に移行する。

その後、情報登録モジュール４０は、ステップＳ７４、Ｓ７６において、登録内容を関連機種の関係者（具体的には、同一機器（別機種）の同一部位の設計に関与している者）の端末に配信したり、同一機種の関係者（具体的には、同一機器（同一機種）の別の部位の設計に関与している者）に配信したりする。この配信は、登録内容のダイジェスト版を上記のような関係者に速報的に知らせて、不具合情報を周知させる意義を有している。

そして、ステップＳ７６の処理が完了すると、設計者端末１０上での処理から、管理者端末１２上での処理(図１８のフローチャート)に移行する。

図１８のステップＳ８２では、情報登録モジュール４０が、管理者端末１２上から、管理者に対して、暫定対策結果の評価を行うように、指示を出す。次いで、情報登録モジュール４０は、ステップＳ８４において、暫定対策結果が管理者により評価され、その評価結果が管理者端末１２上から入力されるまでの間待機する。そして、管理者端末１２上で評価結果が入力された段階で、ステップＳ８６に移行する。

次いで、ステップＳ８６では、暫定対策結果を登録者端末１４に送信し、登録者端末１４上での処理に移行する。

次のステップＳ１１０では、情報登録モジュール４０は、登録者による登録者端末１４上からの登録手続が行われるまでの間待機する。この場合、登録者は、上述したステップＳ８６において、管理者端末１２側から送信された評価結果を確認した後、登録する手続を行う。

そして、登録者による登録手続が行われた段階で、ステップＳ１１２に移行し、情報登録モジュール４０が評価結果を登録処理を行う。その後は、ステップＳ１１４、Ｓ１１６において、情報登録モジュール４０が、評価内容を関連機種の関係者（具体的には、同一機器（別機種）の同一部位の設計に関与している者）の端末に配信したり、同一機種の関係者（具体的には、同一機器（同一機種）の別の部位の設計に関与している者）に配信したりする。この配信は、評価内容のダイジェスト版を上記のような関係者に速報的に知らせて、不具合情報を周知させる意義を有している。

次に、上述した図１７、図１８の処理と並行的に行われ得る、設計者端末１０上での詳細な登録処理、及び管理者端末１２上での標準改訂のための処理について図１９のフローチャートに沿って説明する。

まず、図１９のステップＳ１２０では、情報登録モジュール４０が、設計者によって詳細登録がなされたか否かを判断する。この場合の詳細登録とは、例えば、予め過去情報ＤＢに登録されている不具合発生理由リストや画像リスト（不具合部分を撮影した画像など）から、現在起こっている不具合と略一致したものを選択し、画像登録することを意味する。ここでの判断が肯定された場合には、管理者端末１２側の処理に移行するが、判断が否定された場合には、ステップＳ１２２に移行して、納期が過ぎたか否かを判断する。この段階で納期が過ぎていなかった場合には、ステップＳ１２０に戻り、詳細登録がない間は、納期が過ぎるまでステップＳ１２０、Ｓ１２２を繰り返す。

そして、納期を過ぎた場合には、ステップＳ１２２の判断が肯定されるので、情報登録モジュール４０は、ステップＳ１２４において、設計者端末１０に対して警告を発する。この場合においても、警告方法としては、画面上への直接的な警告表示を採用しても良いし、電子メール等を介した警告情報の配信やスピーカを介した警告音の出力、あるいはこれらの組み合わせを採用しても良い。

上記のようにして警告を行った後、情報登録モジュール４０は、ステップＳ１２６において、詳細登録が行われるまで待機し、設計者端末１０からの詳細登録が行われた段階で、管理者端末１２側の処理に移行する。

次のステップＳ１４０では、情報登録モジュール４０が、管理者端末１２を介して管理者に対し、不具合の分析を行うよう指示を出す。

管理者は、当該指示に応じて、（１）不具合の発生原因の分析、（２）不具合が発生した工程の分析、（３）変化内容と不具合情報の関連付けの分析、を実行する。これらの分析により、管理者は、前述した、図１４（ａ）のような不具合情報の詳細を作成することが可能となる。

したがって、情報登録モジュール４０は、図１９のステップＳ１４２において、設計検討時に確認すべき不具合情報の詳細を作成するために必要な、変化内容と不具合情報の関連付けが登録されるまで待機し、登録者により登録が行われた段階で、次のステップＳ１４４、Ｓ１４６に移行する。

これらステップＳ１４４、Ｓ１４６では、情報登録モジュール４０が、ステップＳ１４２において登録された関連付け内容を関連機種の関係者（具体的には、同一機器（別機種）の同一部位の設計に関与している者）の端末に配信したり、同一機種の関係者（具体的には、同一機器（同一機種）の別の部位の設計に関与している者）に配信したりする。この配信は、関連付け内容のダイジェスト版を上記のような関係者に速報的に知らせて、不具合情報を周知させる意義を有している。

そして、次のステップＳ１４８では、情報登録モジュール４０が、変化内容のステータスが実績ＯＫとなっているか否かを判断する。この場合、基本的には実績ステータスは「実績ＯＫ」となっているので（図４のステップＳ４６において実績ＯＫと仮定されているため）、ステータスを実績ＮＧに変更する必要がある。したがって、ここでの判断が肯定された場合には、ステップＳ１５０において、情報登録モジュール４０が変化内容のステータスを実績ＮＧに変更し、ステップＳ１５２に移行する。また、ステップＳ１４８の判断が否定された場合には、直接ステップＳ１５２に移行する。

その後、ステップＳ１５２では、不具合発生率を変更することにより、図１９の全処理を終了する。

ここで、上記不具合発生率について具体的に説明する。この不具合発生率には、図２０（ａ）に示すように、各部位、各寸法ごとに設定される、「標準内ＮＧ率」、「標準外ＯＫ率」が含まれる。ここで「標準内ＮＧ率」とは、図１４（ａ）に示すように、各部位の各寸法に設定されている標準５４（図１４（ａ）では、一例として、部位βの寸法Ａの標準が、０．５ｍｍ〜１．５ｍｍに設定されている）内の値を検討値として設定したにもかかわらず、不具合の発生が確認された割合を意味する。また、「標準外ＯＫ率」とは、各部位の各寸法に設定されている標準５４の範囲外の値を検討値として設定したにもかかわらず、不具合の発生が確認されなかった割合を意味する。

次に、上記不具合発生率を利用した標準改訂処理について、図２１のフローチャートに沿って説明する。なお、この図２１の処理は、図２のアプリケーションサーバ１８のスコアデータ管理モジュール４６が管理者端末１２上における管理者からの入力に基づいて実行するものである。

まず、スコアデータ管理モジュール４６は、ステップＳ１７０において、標準内ＮＧ率が閾値以上であるか否かを判断する。ここでは、例えば標準内ＮＧ率が２５％で、閾値（例えば、２０％とする）を超えていたため、ステップＳ１７０の判断が肯定されたものとする。

次いで、ステップＳ１７４では、管理者端末１２に対して、スコアデータ管理モジュール４６が、標準改訂検討要請を告知する。この場合、スコアデータ管理モジュール４６は、管理者端末１２上に図２０（ａ）に示すような標準改訂画面を表示する。

次いで、スコアデータ管理モジュール４６は、ステップＳ１７６において、標準改訂を行う項目が選択されるまでの間、待機する。この場合の選択は、例えば、図２０（ｂ）に示すように、管理者が、部位βの部分にマウスポインタを合わせ、クリックすることにより行われる。

このステップＳ１７６の判断が肯定されると、ステップＳ１７８において、スコアデータ管理モジュール４６が、図２２に示すような選択された項目（部位β）についての詳細を表示する。この図２２の内容は、図１２のリストの内容と対応している。

次いで、スコアデータ管理モジュール４６は、ステップＳ１８０において、例えば、図２２の標準内ＮＧ率の欄（一例として２５％と表示されている欄）が管理者によってクリックされることにより、標準項目の改訂の必要があると管理者が判断したか否かを判断する。ここでの判断が否定された場合には、標準改訂の必要が無いので、図２１の全処理を終了する。

一方、ステップＳ１８０の判断が肯定された場合には、ステップＳ１８２において、標準項目の修正が完了するまでの間、待機する。管理者は、図２２の画面上において、寸法Ａの標準（「０．５−１．５」と記載されている欄）を適宜変更することができるようになっている。このため、管理者は、標準の欄に、標準内ＮＧが発生しないような狭い範囲を入力することができる（例えば、標準の欄に０．５ｍｍ〜１．０ｍｍを入力しなおすことができる）。上記入力により、ステップＳ１８２の判断が肯定されると、ステップＳ１８４に移行し、スコアデータ管理モジュール４６が、標準ＤＢ２８内に格納されている標準を図２２の標準の欄に入力しなおされた範囲の値に更新する。

その後は、ステップＳ１８６において、スコアデータ管理モジュール４６が設計者に更新情報を送信することにより、図２１の全処理を終了する。

一方、ステップＳ１７０の判断が否定された場合には、ステップＳ１７２に移行し、標準外ＯＫ率が閾値（例えば３０％など）以上になったか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１７４以降の処理を上記と同様に実行する。そして、管理者は、標準を広げる方向（標準外でＯＫになった検討値が標準に含まれるように標準を広げる方向）に修正することができる。一方、ステップＳ１７２の判断が否定された場合には、ステップＳ１７０に戻り、上記と同様の処理を実行する。

上記においては、ステップＳ１７０の判断が否定された場合に、ステップＳ１７０の判断を行うこととして、標準内ＮＧ率を標準外ＯＫ率に優先して判断することとした。これは、標準内ＮＧ率のほうが、不具合の発生に比較的大きな影響を与えると考えられるため、改訂が比較的急がれるからである。しかしながら、本実施形態がこれに限られるものではなく、例えば、標準内ＮＧ率と標準外ＯＫ率が閾値を超えているか否かを同時に判断することとしても良いし、標準外ＯＫ率の方を優先して判断することとしても良い。

なお、図１７のフローチャートでは、一例として、設計者が不具合を発見する場合について説明した。しかしながら、本発明はこれに限られるものではなく、不具合は、例えば、製造工程担当者、品質管理担当者、評価担当者等が発見することもあるので、これら不具合を発見した者が当該不具合の登録を行えるようにしても良い。

なお、本実施形態では、検討値や標準が寸法（数値）である場合について説明したが、これに限られるものではなく、本実施形態は、ある部位の材質についての検討についても好適に適用することができる。例えば、ある部位を樹脂Ｘから樹脂Ｙに変える場合、樹脂Ｘから樹脂Ｚに変える場合などにおいて、不具合が発生したか否かを実績値として取得しておき、それらに基づいて、標準を改訂したり不具合情報を表示したりすることとしても良い。また、これに限らず、表面処理方法など種々の設計要素に関する検討にも、本実施形態の設計支援システムは好適に適用することができる。

以上説明したように、本実施形態によると、アプリケーションサーバ１８の登録結果配信モジュール４２が、設計者による製品の特定部分（例えば部位βの寸法Ａ）の指定（選択）を受けて、特定部分を変化させた場合の変化前の状態と変化後の状態との組み合わせ（例えば、０．５ｍｍ→１．５ｍｍ）に対応したスコアデータや不具合情報などの過去情報を、設計者端末１０に提供するので、設計者は、当該過去情報を参照することで、特定部分の変化後の状態を適切に決定することができる。このように、設計者による特定部分の変化後の状態の決定を支援することができるので、設計者（ユーザ）の利便性を向上することが可能となる。

また、本実施形態によると、収集された実績値に基づいてチェック内容に関する「標準」を改訂するので、収集された実績値が新しく、かつ数が多いほど、「標準」を適切な値に改訂することが可能である。このため、設計者は、本実施形態の設計支援システムを使えば使うほど、実績フィードバックが促進され、ＰＤＣＡサイクルが有効に回るため、標準を益々適切な値に改訂することができる。また、実績値の収集数が多くなると、これら実績値に基づいて設計者に提供される不具合情報に関する信頼度も向上する。このように、本実施形態によると、使用を重ねるほど、不具合の発生がより一層未然に防止される。

また、本実施形態では、変更前の状態と変更後の状態を具体的な数値（過去の生データそのまま）にて表示するので、設計者は、様々な装置に援用可能な一般的な数値を用いる場合のように、目的の装置に特化した値に換算するような作業を行う必要が無い。これにより、設計を簡易に行うことが可能である。

また、本実施形態によると、登録結果配信モジュール４２は、設計者端末１０に対して、スコアデータや不具合情報などの過去情報を重要度に応じて複数提供することとしているので、設計者は、過去情報の閲覧を効率良く行うことが可能であり、結果的に、製品の設計を効率的に行うことが可能である。

また、本実施形態では、登録結果配信モジュール４２は、複数の過去情報のうち最も関連度の高い情報（確認必須情報）を閲覧せずに検討値を入力した場合に、強制的に警告を発することとしているため、検討値決定のために最低限必要とされる過去情報を、設計者が確認しないようなことがないようにすることが可能である。これにより、不具合の発生率を低減することが可能である。

また、本実施形態では、標準ＤＢ２８が製品の部分ごとの標準（基準範囲情報）を保持しており、スコアデータ管理モジュール４６が、過去の実績（標準内ＮＧ率及び標準外ＯＫ率）に基づいて、標準を改訂するので、過去の実績に応じた適切な標準（基準範囲情報）を標準ＤＢ２８内に常時格納しておくことができる。また、標準内ＮＧ率が比較的高い場合には標準を狭める方向に改訂し、標準外ＯＫ率が比較的高い場合には標準を広げる方向に改訂するなど、標準改訂を適切に行うことが可能である。なお、標準改訂は、上記のように、範囲を広げたり狭めたりする場合に限らず、標準の範囲幅を一定に維持したまま、その上限値と下限値を変更する（標準の範囲幅をスライドさせる）ようにしても良い。

なお、上記実施形態では、一例として、図１のように複数のＰＣ等を含んで構成される設計支援システムについて説明したが、本発明の実施形態はこれに限られるものではなく、上記実施形態で説明したアプリケーションサーバ１８やデータベースサーバ１６、設計者端末１０の機能を包含する一の情報処理装置により、設計支援装置を構成することとしても良い。

なお、上記実施形態において説明した処理シーケンスにおいては、設計者、管理者、登録者等に判断を委ねていたものもあるが、そのうちの一部をＰＣやサーバに行わせることとしても良い。例えば、上記実施形態の図２１では、標準内ＮＧ率又は標準外ＯＫ率が閾値以上であった場合（ステップＳ１７０、Ｓ１７２）に、管理者端末１２に告知（改訂情報の提供）を行い、当該告知に基づいて、管理者が改訂を行うか否かを判断し、標準を変更することとしたが、標準内ＮＧ率又は標準外ＯＫ率が閾値以上であった場合（ステップＳ１７０、Ｓ１７２）に、スコアデータ管理モジュール４６が、不具合部分が含まれなくなるように標準を自動で変更するようにしても良い。なお、このような処理を行う場合には、自動で変更した標準に対して、管理者が承認を行うことによりはじめて標準が確定するものとしても良い。

なお、上記実施形態では、一例として、アプリケーションサーバ１８、データベースサーバ１６、端末１０，１２，１４をそれぞれ別の装置として構成したが、ＣＰＵ、ＲＯＭ、及びＲＡＭなどを組み合わせて計算機システムを構成し、上記の各装置の機能を計算機システムに内蔵されたプログラム、及び当該プログラムが格納された記憶媒体によって実現することも可能である。

上述した各実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

本発明の一実施形態に係る設計支援システムの概略構成を示す図である。 本発明の一実施形態に係るアプリケーションサーバ及びデータベースサーバの機能・構成を示す図である。 本発明の一実施形態に係る、不具合情報を利用した設計支援方法について示すフローチャート（その１）である。 本発明の一実施形態に係る、不具合情報を利用した設計支援方法について示すフローチャート（その２）である。 本発明の一実施形態において設計する部位の一例を示す図である。 本発明の一実施形態に係る設計者端末に検討項目の一覧を表示した状態を示す図である。 本発明の一実施形態に係る設計者端末にチェック項目表を表示した状態を示す図である。 本発明の一実施形態に係るステージについて説明するための図である。 本発明の一実施形態に係る設計者端末にスコアデータを表示した状態を示す図である。 本発明の一実施形態に係る信頼度及びその条件について示す図である。 本発明の一実施形態に係る実績のグラフ表示を示す図である。 本発明の一実施形態に係る実績のリスト表示を示す図である。 本発明の一実施形態に係る設計者端末に過去情報を表示した状態を示す図である。 本発明の一実施形態に係る設計者端末に不具合情報の詳細を表示した状態を示す図である。 本発明の一実施形態に係る設計者端末上で検討値が入力された状態を示す図である。 本発明の一実施形態に係る設計者端末上で強制的に不具合情報の詳細を表示した状態を示す図である。 本発明の一実施形態において、不具合事例の登録処理のうち設計者端末で行われる処理を示すフローチャートである。 本発明の一実施形態において、不具合事例の登録処理のうち管理者端末及び登録者端末で行われる処理を示すフローチャートである。 本発明の一実施形態に係る、不具合事例の詳細登録処理を示すフローチャートである。 本発明の一実施形態に係る標準改訂処理における、標準内ＮＧ率及び標準外ＯＫ率の表示例を示す図である。 本発明の一実施形態に係る標準改訂処理を示すフローチャートである。 図２１のステップＳ１７８における表示例を示す図である。

符号の説明

１０ 設計者端末
２８ 標準ＤＢ
３２ 過去情報ＤＢ
４２ 登録結果配信モジュール
４６ スコアデータ管理モジュール
１００ 設計支援システム

Claims (22)

1. 製品の設計過程で生じる設計変化点ごとに、変化前の状態と変化後の状態との組み合わせに関連付けて過去情報が記憶された記憶手段と、
   設計者による前記製品の特定部分の指定を受けて、前記特定部分を変化させた場合の変化前の状態と変化後の状態との組み合わせに対応した過去情報を、前記記憶手段から前記設計者に提供する過去情報提供手段と、を備える設計支援装置。
2. 前記過去情報は、変化前の状態と変化後の状態との組み合わせに関する実績値のスコア情報を含むことを特徴とする請求項１に記載の設計支援装置。
3. 前記スコア情報には、前記実績値の信頼度が含まれることを特徴とする請求項２に記載の設計支援装置。
4. 前記過去情報は、前記変化前の状態と前記変化後の状態との組み合わせに関連する事例情報を含むことを特徴とする請求項１〜３のいずれか一項に記載の設計支援装置。
5. 前記過去情報は、前記変化前の状態と前記変化後の状態との組み合わせに対する関連度毎に、複数種類の事例情報を含むことを特徴とする請求項４に記載の設計支援装置。
6. 前記複数種類の事例情報は、前記変化前の状態、前記変化後の状態、及び変化の種類、のすべてが一致する第１の事例情報と、前記変化の種類と、前記変化前の状態及び前記変化後の状態のいずれかと、が一致する第２の事例情報と、前記変化前の状態、前記変化後の状態、及び変化の種類のいずれか一つが一致する第３の事例情報と、の少なくとも１つを含むことを特徴とする請求項５に記載の設計支援装置。
7. 前記過去情報提供手段は、前記複数種類の事例情報のうちの特定の事例情報が前記設計者により閲覧されなかった場合に、前記設計者に対して警告を発することを特徴とする請求項５又は６に記載の設計支援装置。
8. 前記製品の部分ごとの、前記変化に関する標準情報を保持する標準情報保持手段と、
   前記記憶手段に記憶された過去情報に基づいて、前記標準情報の改訂情報を出力する改訂情報出力手段と、を更に備える請求項１〜７のいずれか一項に記載の設計支援装置。
9. 前記過去情報には、前記設計変化点において不具合が発生した失敗情報と、前記設計変化点において不具合が発生しなかった成功情報とが含まれ、
   前記改訂情報出力手段は、前記成功情報と前記失敗情報とに基づいて、前記標準情報の改訂情報を出力することを特徴とする請求項８に記載の設計支援装置。
10. 前記改訂情報出力手段は、前記過去情報のうち前記変化後の状態が前記標準情報の範囲内にある場合における失敗情報の数量情報と、前記過去情報のうち前記変化後の状態が前記標準情報の範囲外にある場合における成功情報の数量情報と、の少なくとも一方を前記改訂情報として出力することを特徴とする請求項９に記載の設計支援装置。
11. 前記改訂情報出力手段は、前記過去情報のうち前記変化後の状態が前記標準情報の範囲内にある場合における失敗情報の数量と、前記過去情報のうち前記変化後の状態が前記標準情報の範囲外にある場合における成功情報の数量と、の少なくとも一方に基づいて、前記標準情報の改訂を行うか否かの判断を行うことを特徴とする請求項８に記載の設計支援装置。
12. 製品の設計を行う設計者が使用する情報処理手段と、
    前記製品の設計過程で生じる設計変化点ごとに変化前の状態と変化後の状態との組み合わせに関連付けて過去情報が記憶された記憶手段と、
    前記情報処理手段における前記製品の特定部分の指定を受けて、前記特定部分を変化させた場合の変化前の状態と変化後の状態との組み合わせに対応した過去情報を、前記記憶手段から前記情報処理手段に対して送信する過去情報提供手段と、を備える設計支援システム。
13. 前記過去情報は、変化前の状態と変化後の状態との組み合わせに関する実績値のスコア情報を含むことを特徴とする請求項１２に記載の設計支援システム。
14. 前記スコア情報には、前記実績値の信頼度が含まれることを特徴とする請求項１３に記載の設計支援システム。
15. 前記過去情報は、前記変化前の状態と前記変化後の状態との組み合わせに関連する事例情報を含むことを特徴とする請求項１２〜１４のいずれか一項に記載の設計支援システム。
16. 前記過去情報は、前記変化前の状態と前記変化後の状態との組み合わせに対する関連度毎に、複数種類の事例情報を含むことを特徴とする請求項１５に記載の設計支援システム。
17. 前記製品の部分ごとの、前記変化に関する標準情報を保持する標準情報保持手段と、
    前記記憶手段に記憶された過去情報に基づいて、前記標準情報の改訂情報を出力する改訂情報出力手段と、を更に備える請求項１２〜１６のいずれか一項に記載の設計支援システム。
18. 前記過去情報には、前記設計変化点において不具合が発生した失敗情報と、前記設計変化点において不具合が発生しなかった成功情報とが含まれ、
    前記改訂情報出力手段は、前記成功情報と失敗情報とに基づいて、前記標準情報の改訂情報を出力することを特徴とする請求項１７に記載の設計支援システム。
19. 前記改訂情報出力手段は、前記過去情報のうち前記変化後の状態が前記標準情報の範囲内にある場合における失敗情報の数量情報と、前記過去情報のうち前記変化後の状態が前記標準情報の範囲外にある場合における成功情報の数量情報と、の少なくとも一方を前記改訂情報として出力することを特徴とする請求項１８に記載の設計支援システム。
20. 設計者による製品の特定部分の指定を受けるステップと、
    前記製品の設計過程で生じる設計変化点ごとに、変化前の状態と変化後の状態との組み合わせに関連付けて記憶された過去情報から、前記設計者による指定に応じた過去情報を、前記設計者に提供するステップと、を含む設計支援方法。
21. コンピュータによって実行されたときに、当該コンピュータを、
    製品の設計過程で生じる設計変化点ごとに、変化前の状態と変化後の状態との組み合わせに関連付けた過去情報の中から、設計者により指定された前記製品の特定部分を変化させた場合の変化前の状態と変化後の状態との組み合わせに対応した過去情報を、前記設計者に提供する過去情報提供手段として機能させることを特徴とする設計支援プログラム。
22. 請求項２１に記載の設計支援プログラムを記録したコンピュータ読取可能記録媒体。

Images