(57)【要約】【課題】従来の開発マネジメントシステムでＦＭＥＡによる故障モード予測と危険度推定を行う場合、デザインレビューでは、必ずしも出席を要しない者も課題検討に参加することがあり、全体的な効率の低下を生ずると共に、設計完成度にばらつきを生ずることがある。【解決手段】過去の設計課題データベースと、開発関係者を包含する組織表とを用いて、現在の設計上で予想される少なくとも１つの故障モードに対する課題に関して、それぞれについての関係者や関係部署のメンバーをコンピュータが自動的に選択してデザインレビューを行うことにより、過去の課題の有効活用と、関係部門の人員の適切な選択をして、効率のよいデザインレビューを行うことが可能となる。【選択図】図１
2005025570.tif 000002
【特許請求の範囲】
【請求項１】
設計品質を向上させる開発マネジメントシステムにおいて、
過去の設計における課題及び前記課題に関連する過去の組織情報を蓄積し、前記課題毎に対応する前記過去の組織情報を参照できる課題データベースと、
開発に携わる開発者を包含した組織表と、
前記課題データベースに蓄積された前記過去の組織情報に対して、前記課題に関連する現在の組織情報を追加することにより、前記課題と組織とを対応させた課題リストを生成する課題リスト生成手段と、
前記課題リストのうち、現在の設計対象において予想される故障モードに対応する前記課題を参照して、前記課題に対処するのに最適な開発組織部署を選択する選択手段とを備える
ことを特徴とする開発マネジメントシステム。
【請求項２】
設計品質を向上させる開発マネジメントシステムにおいて、
過去の設計における課題及び前記課題に関連する少なくとも１つの副課題を蓄積し、前記課題毎に対応する前記副課題のデータを参照できる課題データベースと、
前記課題に関連する前記副課題毎に設定された重要度ランクに対して、副課題のランキング値を生成する副課題ランキング手段と、
前記副課題ランキング手段により生成された前記ランキング値に基づく所定の演算を、前記課題毎に行うことにより、前記課題処理のランキングリストを生成する課題処理ランキングリスト生成手段とを備える
ことを特徴とする開発マネジメントシステム。
【請求項３】
請求項２記載の開発マネジメントシステムにおいて、
前記課題処理ランキングリスト生成手段は、前記故障モードに対応する前記副課題項目毎の前記副課題ランキング値から、最大値を算出する構成である
ことを特徴とする開発マネジメントシステム。
【請求項４】
請求項２記載の開発マネジメントシステムにおいて、
前記課題処理ランキングリスト生成手段は、前記故障モードに対応する前記副課題項目毎の前記副課題ランキング値の合計値又は乗算値を算出する構成である
ことを特徴とする開発マネジメントシステム。
【請求項５】
請求項２、３又は４記載の開発マネジメントシステムにおいて、
前記副課題項目は、課題の発生頻度、課題の対策費用及び課題の対策日程を含み、
前記副課題ランキング値は、前記発生頻度の頻度が高いほどレベルが高く、前記課題の対策費用の費用が高いほどレベルが高く、前記対策日程の日程が長いほどレベルが高い
ことを特徴とする開発マネジメントシステム。
【請求項６】
請求項５記載の開発マネジメントシステムにおいて、
前記副課題項目は、更に、開発担当者の実務経験年数、開発担当者の技術スキルレベル、課題の検出手段、課題の対策工数を含み、
前記副課題ランキング値は、前記開発担当者の実務経験年数の年数が短いほどレベルが高く、前記開発担当者の技術スキルが低いほどレベルが高く、前記課題の検出手段の手段が少ないほどレベルが高く、前記課題の対策工数が多いほどレベルが高い
ことを特徴とする開発マネジメントシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、開発マネジメントにおいて、開発効率を向上させて、設計完成度を高める開発手法に関するものである。
【０００２】
【従来の技術】
従来、新規設計や既存品の変更を行う場合に、ＦＭＥＡ（Ｆａｉｌｕｒｅ  Ｍｏｄｅ  ａｎｄ  Ｅｆｆｅｃｔ  Ａｎａｌｙｓｉｓ）が用いられることが多く、例えば半導体装置や精密機器などの知識集約型製品の開発に際し、設計経験者を集めたデザインレビューを効率よく実施することにより設計完成度を高めることができる。このＦＭＥＡは、設計対象の基となるベース品種に対する新規点及び変更点を明確にして、それら新規設計及び変更に対して想定されるリスクの度合いを数値化することにより、新規設計及び変更に付随する複数の課題の優先度を明らかにし、その優先度に基づいて対策を行うことができるものである。また、対策後に再評価することにより、対策効果も確認することができる優れた品質対策ツールである。
【０００３】
以下に、図表を用いてＦＭＥＡの詳細を説明する。図５は、従来の開発マネジメントシステムにおいてＦＭＥＡを用いた場合のフローチャートを示す（例えば、非特許文献１参照。）。
【０００４】
図５中、５０１は開発対象に対して行うＦＭＥＡ開始を示す。５０２はベース品種に対する開発品種の新規点及び変更点を明確にする工程、５０３は前記５０２において明確にされた変更点などに対して想定される故障モードを挙げ、その故障モードのリスク度合いを数値化する工程、５０４は前記５０３において数値化された故障モードに対する課題について、対策を行う優先度を明確にする工程、５０５は課題に対して改善を図り、設計完成度を向上させる設計開発工程、５０６は前記５０５の設計開発工程における改善により課題の解決が図れたかどうかを確認するための危険度の再評価工程、５０７は、前記５０６において行われた危険度の再評価の結果が安全範囲に入っているかどうかを判断する工程、５０８は前記判断工程５０７で問題なしと判断した場合に設計品の試作および評価を行う工程、５０９は前記試作評価５０８において試作された製品に問題がないかどうかを判断する工程、５１０は前記試作評価判定５０９において問題がなしと判断した場合、量産化可能と判断して量産を行う量産工程、５１１は前記量産工程５１０において問題が発生しているかどうかを判断する工程、５１２は前記試作評価判断工程５０９、前記量産評価判断工程５１１において問題が発生した場合にその課題内容を整理し、蓄積するデータベースである。
【０００５】
次に、従来の開発マネジメントにＦＭＥＡを導入した取り組みにおいての具体例として、半導体製品の開発を挙げ、図５のフローチャートを用いて説明を行う。
【０００６】
情報機器産業は技術進歩が激しく、新規製品を早期に市場に出すことが求められる。それらの情報機器に用いられる半導体製品も、実績のあるベース品種において、できるだけ変更点が少ない設計を行い、且つ高い性能向上を図ることが求められる。以下、具体例として、通信用半導体機器について説明する。
【０００７】
図５のフローチャートにおいて、５０２の変更内容の明確化により、ベースとなる通信用半導体機器に対して、通信速度を向上させることを目的とした高速データインタフェースを新規に開発する内容の変更を行うものとする。具体的には、新規のアナログ制御回路の設計及び電源回路の強化を目的とした開発が行われる。続いて、５０３の危険度の数値化においては、新規のアナログ制御回路の設計及び電源回路の強化に対するそれぞれの故障モードとして、１）アナログ回路のノイズマージン低減による通信不良と、２）電源容量不足に起因する電源電圧降下による動作速度低下とが発生すると考える。これら２つの故障モードに対して、５０４の優先度の明確化の段階では、電源の能力不足はすべての制御回路ブロックに影響を与えるため最も優先度が高いと判断し、電源回路の強化の開発が最優先課題であると考える。ここで、５０５の設計完成度向上活動においては、明確化された最優先課題の電源回路強化に対し、その改善手段として、従来よりも駆動能力の高い安定電源回路への変更、半導体回路内のレイアウト配線の強化、及び半導体回路に供給する電源配線を安定化させるバイパスコンデンサの補強などを列挙する。次に、これらの改善により補強された電源回路から安定した電源電流が供給されることを前提としてアナログ回路の設計が行われる。このとき、電源変動や温度変動、拡散プロセス変動が考慮され、所望のノイズレベルで安定動作する高速データインタフェース回路が設計される。ここで、これらの改善結果は、手順５０６において危険度についての再評価を受ける。その再評価結果は、５０７において安全範囲かどうかの判断を経て、設計内容が不十分であれば、５０５の設計完成度向上活動に戻され、同様の手順が繰り返される。また、５０７の安全範囲の判断において、所望の電源安定性と耐ノイズ性が確認されると試作工程５０８に入る。試作された製品は、試作工程５０８の手順において結果を評価され、続く５０９において、新たな課題が発生したか否かの判断がされる。この際、試作に問題が発生すれば、その結果が、課題リストとしてデータベース５１２に蓄積される。この蓄積されたデータベース５１２は、次期品種開発のための設計完成度向上活動５０５において、適宜参照され、設計レベルの向上に有益なノウハウとなる。一方、試作結果において課題なしと判断された場合は、量産化工程５１０に入る。量産化工程の結果は、試作段階と同様に結果の評価を受け、課題が発生したかどうかが５１１において判断される。問題がなければ量産は継続されるが、問題があった場合、前記試作の場合と同様に結果が課題データベースに蓄積されて、次の品種開発で活用される。
【０００８】
このようにして一連の技術開発が行われ、品種の品質改善向上が図られる。
【０００９】
【非特許文献１】ロビン・Ｅ・マクダモット，レイモンド・Ｊ・ミクラク，マイケル・Ｒ・ビューレガード（Ｒｏｂｉｎ  Ｅ．Ｍｃｄｅｒｍｏｔｔ，Ｒａｙｍｏｎｄ  Ｊ．Ｍｉｋｕｌａｋ，Ｍｉｃｈａｅｌ  Ｒ．Ｂｅａｕｒｅｇａｒｄ）著，「ザ  ベイシック  オブ  エフエムイーエー（Ｔｈｅ  Ｂａｓｉｃｓ  ｏｆＦＭＥＡ）」，（米国），プロダクティビティ  インク（Ｐｒｏｄｕｃｔｉｖｉｔｙ，  Ｉｎｃ），１９９６年，ｐ．２７−４４
【００１０】
【発明が解決しようとする課題】
しかしながら、従来の開発マネジメントシステムでは、変更内容の明確化５０２、危険度の数値化５０３、優先度の明確化５０４、設計完成度向上活動５０５、危険度の再評価５０６などの工程で実施されるデザインレビューには、具体的対策や課題列挙では必要がなくても、関係部門の関係者が参加する場合がある。
【００１１】
例えば、従来例において示した前記電源回路設計の技術者やアナログ回路設計の技術者が、同一のデザインレビューに同席することになる。これは、課題を共有化する意味において同席することは必要であっても、具体的対策や課題列挙では必要性がないことも多い。また、当該課題に関係の少ないソフトウエア開発設計者やレイアウト設計者については、必要不可欠人員とは言いがたく、開発設計者の時間を無駄に拘束することにより、全体的な設計効率が低下する恐れがある。
【００１２】
また、危険度の数値化５０３においては、設計者の経験や過去の知識が参照されて、設計者の主観に委ねられることにより、開発メンバーの構成によっては設計完成度にばらつきが生じるという課題がある。特に開発に精通していない開発技術者が数値化する場合は、当該技術に関する深い知識がなく、正しい指標化が困難である。
【００１３】
本発明では、前記問題を解決するものであり、その目的は、参加者の技術レベルや主観に起因する設計完成度のばらつきを防止し、デザインレビューの効率を向上させることにある。
【００１４】
【課題を解決するための手段】
以上の課題を解決するために、本発明では、課題データベースに蓄積された過去の課題データを利用して、設計上予想される故障モードに対する現課題を処理する対応部署の選択又は現課題処理の重要度の数値化をコンピュータシステムが自動的に行う。
【００１５】
すなわち、請求項１記載の発明の開発マネジメントシステムは、過去の設計における課題及び前記課題に関連する過去の組織情報を蓄積し、前記課題毎に対応する前記過去の組織情報を参照できる課題データベースと、開発に携わる開発者を包含した組織表と、前記課題データベースに蓄積された前記過去の組織情報に対して、前記課題に関連する現在の組織情報を追加することにより、前記課題と組織とを対応させた課題リストを生成する課題リスト生成手段と、前記課題リストのうち、現在の設計対象において予想される故障モードに対応する前記課題を参照して、前記課題に対処するのに最適な開発組織部署を選択する選択手段とを備えることを特徴とする。
【００１６】
請求項２記載の発明は、過去の設計における課題及び前記課題に関連する少なくとも１つの副課題を蓄積し、前記課題毎に対応する前記副課題のデータを参照できる課題データベースと、前記課題に関連する前記副課題毎に設定された重要度ランクに対して、副課題のランキング値を生成する副課題ランキング手段と、前記副課題ランキング手段により生成された前記ランキング値に基づく所定の演算を、前記課題毎に行うことにより、前記課題処理のランキングリストを生成する課題処理ランキングリスト生成手段とを備えることを特徴とする。
【００１７】
請求項３記載の発明は、請求項２記載の開発マネジメントシステムにおいて、前記課題処理ランキングリスト生成手段は、前記故障モードに対応する前記副課題項目毎の前記副課題ランキング値から、最大値を算出する構成であることを特徴とする。
【００１８】
請求項４記載の発明は、請求項２記載の開発マネジメントシステムにおいて、前記課題処理ランキングリスト生成手段は、前記故障モードに対応する前記副課題項目毎の前記副課題ランキング値の合計値又は乗算値を算出する構成であることを特徴とする。
【００１９】
請求項５記載の発明は、請求項２、３又は４記載の開発マネジメントシステムにおいて、前記副課題項目は、課題の発生頻度、課題の対策費用及び課題の対策日程を含み、前記副課題ランキング値は、前記発生頻度の頻度が高いほどレベルが高く、前記課題の対策費用の費用が高いほどレベルが高く、前記対策日程の日程が長いほどレベルが高いことを特徴とする。
【００２０】
請求項６記載の発明は、請求項５記載の開発マネジメントシステムにおいて、前記副課題項目は、更に、開発担当者の実務経験年数、開発担当者の技術スキルレベル、課題の検出手段、課題の対策工数を含み、前記副課題ランキング値は、前記開発担当者の実務経験年数の年数が短いほどレベルが高く、前記開発担当者の技術スキルが低いほどレベルが高く、前記課題の検出手段の手段が少ないほどレベルが高く、前記課題の対策工数が多いほどレベルが高いことを特徴とする。
【００２１】
以上により、請求項１記載の発明では、予想される故障モードに対応した過去の課題を課題データベースから抽出し、その課題に現在の組織情報を追加及び関連付けることにより、現課題の開発における組織対応に基づいた課題リストを自動的に作成することができる。これにより、デザインレビューをするに際し、最適な開発メンバーを自動的に選択することが可能となる。
【００２２】
また、請求項２記載の発明では、予想される故障モードに対応した過去の課題を課題データベースから抽出し、現在の設計上、その課題に付随する複数の関連要件又は関連課題を考慮した処理の重要度レベルによるランキング付けを自動的に行うことができ、関係者の主観的判断により課題の処理順位が決定されることの防止が可能となる。
【００２３】
更に、請求項３記載の発明では、故障モードに対する課題に関連して存在する複数の副課題項目毎の重要度ランキングの結果について自動的に最大値を算出することにより、設計及び開発に最も影響を与える課題の項目を正確且つ速やかに判別することが可能となる。
【００２４】
続いて、請求項４記載の発明では、故障モードに対する課題に関連して存在する複数の副課題項目毎に重要度ランキング結果の合計値、又は乗算値を自動的に算出することにより、故障モードに対応する課題毎に全ての副課題項目の内容が与える影響を考慮されて、設計及び開発に最も影響を与える課題の項目を正確且つ速やかに判別することが可能となる。
【００２５】
また、請求項５記載の発明では、課題に関連して考慮すべき副課題項目として課題の発生頻度、課題の対策費用、課題の対策日程が含まれており、それぞれ、発生頻度が高いほどレベルが高く、対策費用が高いほどレベルが高く、また、対策日程が長いほどレベルが高く配点されるように設定することにより、開発に関する課題の発生頻度、開発の費用及び日程における重要度の数値化を自動で行うことが可能となる。
【００２６】
更に、請求項６記載の発明では、課題に関連して考慮すべき副課題項目に、開発担当者の実務経験年数、開発担当者の技術スキルレベル、課題の検出手段、及び課題の対策工数が含まれており、それぞれは、実務経験が短いほどレベルが高く、技術スキルが低いほどレベルが高く、課題の検出手段が少ないほどレベルが高く、また、課題の対策工数が長いほどレベルが高く配点されるように設定することにより、課題の発生頻度、開発の費用及び日程に加え、開発者の経験やスキルのレベルなどを自動的に数値化して更に精度の高い指標化が可能となる。
【００２７】
【発明の実施の形態】
以下、コンピュータシステムを用いた本発明の実施の形態の開発マネジメントシステムについて、図面に基づいて説明をする。
【００２８】
（第１の実施の形態）
図１は本実施の形態である開発マネジメントシステムのフローを示す。
【００２９】
１０１は従来例と同様に過去の設計において発生した問題に対して、その問題に関連する各種情報、例えば、本実施の形態では、課題毎に対応処理を行った関連部署の過去の組織情報等とともに、整理された課題が蓄積されている課題データベース、１０２は開発担当者を包含する現在の組織表、１０３は前記課題データベースと前記組織表１０２の情報を入力することにより、組織毎に対応する課題を抽出する課題抽出装置（課題リスト生成手段）が抽出した組織間課題抽出リスト（課題リスト）、１０４は新規に設計を行う場合に予想される故障モードの列挙、１０５は課題を処理する部署の開発者を選択する選択装置（選択手段）であり、列挙された前記故障モード１０４に対応する課題がどこの開発部門（開発組織部署）に関係するものなのかを前記組織間課題抽出リスト１０３の情報と前記故障モードの情報との入力データに基づいてコンピュータが関係付けを行い、関係する開発者をリストアップ（選択）する。この際、課題が自部門以外の関係部署に係る場合は、その関係部門の開発者をリストアップし、それ以外の場合は、自部門において処理を行う。１０６はその関係部門の開発者のリストであり、１０７はリストアップされた開発者によるデザインレビューにより危険度を指標化する指標化工程、１０８は課題が自部門に関わるものである場合に自部門のみで行う危険度指標化工程である。１０９は前記関係者による危険度指標化工程１０７と前記自部門での危険度指標化工程１０８とにより、全ての故障モードに対する課題を処理する優先度を明確化する工程、１１０は前記明確化する工程１０９により明確化された優先度を参照しながら設計を実施し、完成度を高めていく設計完成向上活動、１１１は前記設計完成度向上活動１１０を行った結果に対して危険度を再評価する危険度再評価工程、１１２は前記の再評価した危険度が予め設定しておいた安全範囲内であれば試作工程１１３に移行し、安全レベルに達していない場合は再度設計完成度向上活動を繰り返すために設計完成度向上活動１１０の工程に戻す判断をする判断工程である。
【００３０】
以下に、本発明の開発マネジメントシステムによる実施の形態として半導体製品の開発を例に、図１のフローチャートを用いて説明を行う。本実施の形態では、従来例と同様に通信用半導体機器を例として、データ通信速度を高速化する場合について説明を行う。
【００３１】
はじめに故障モード抽出工程１０４において、従来例と同様にデータ速度高速化に際し、故障モードとして、アナログ回路のノイズマージン不足と電源能力不足とを予想する。ここで、自部門の設計開発者は主にアナログ回路技術に精通しており、他のある部門では電源回路技術に精通しているものとする。また、その他の部門では、機能設計やソフトウエア開発部門があるものとする。
【００３２】
故障モード抽出工程１０４による故障モードの抽出に続いて、選択工程１０５では、組織表１０２を用いて過去の課題データベース１０１から抽出した組織間課題抽出リスト１０３に基づいて、前記故障モードに対する課題がどの開発者に最も関係するものであるのかを判断し、選択する。
【００３３】
図３（ａ）は課題データベース１０１上に整理された故障モードと関係組織との関係を示した表である。ここでは、故障モードとして「電源リーク」、「動作速度低下」、「歩留まり低下」及び「不要輻射発生」の４つが記録されており、それらに関係する関係部門として、部門Ａ、Ｂ及びＣの３部門が記録されている。そして、これらの故障モード毎に関係した開発技術者が部門毎にリストアップされている。すなわち、過去の電源リーク課題に携わった開発技術者は、部門Ａに所属するＡＢ氏及びＣＤ氏と、部門Ｂに所属するＫＬ氏が列挙されている。また、不要輻射発生課題に関しては、部門Ｃに所属するＵＶ氏だけが携わっていたことがわかる。
【００３４】
本実施の形態では、組織表１０２は、組織の編成によって適宜配置異動が行われるが、都度対応表が図３（ｂ）のように更新されていくものとする。
【００３５】
このように課題データベース１０１のデータを示した図３（ａ）と、組織表１０２の記録情報を示した図３（ｂ）とを参照することにより、２００２年度では、不要輻射発生課題に関係していたＵＶ氏は、部門Ｃに所属していることが明確であり、その後、２００３年度には、部門Ａに異動しているが、本実施の形態における開発マネジメントシステムでは、課題との対応は順次更新されて、自動的に対応することが可能である。
【００３６】
本実施の形態のように、自部門はアナログ回路技術を担当しており、電源回路問題に対しては十分な経験がない場合、先ず、電源回路の故障モードに対しては、その課題に精通している部門Ａが選択され、この部門Ａに所属する担当の開発技術者ＡＢ氏とＣＤ氏が列挙される。ここで、ＡＢ氏、ＣＤ氏の両方が業務の都合により本課題のデザインレビューに参加できない場合は、部門ＢのＫＬ氏が選択される場合もある。このように、電源リーク課題についてのデザインレビューを、本課題解決に最適な部門の開発技術者である、部門ＡのＡＢ氏、ＣＤ氏又は部門ＢのＫＬ氏と共に行い、議論しながら危険度の数値化して課題の危険度をリストアップすることにより、深い知識を有しない者が参加して議論が行われるというような、参加者によるばらつきを防止し、精度の高い設計を行うことができる。
【００３７】
一方、自部門での課題については、自部門危険度指標化工程１０８によって数値化が行われる。このように、自部門と関係部門とで数値化されたリスクについてリストアップされることになる。その後は、担当部門が設計完成度向上の活動を自主的に実施することができる。更に、その後の再評価については、関係する部門ＡのＡＢ氏やＣＤ氏又は部門ＢのＫＬ氏と、自部門の関係者を交えてデザインレビューすることにより設計完成度の確認を行うことができる。
【００３８】
このように、故障モードに精通した設計技術者が過去のデータから自動的に選択されることにより、精度の高いデザインレビューが行える。すなわち、対策案が具体的で効果的なものが提案できるので、設計完成度の向上が図りやすい開発マネジメントシステムが可能となる。
【００３９】
（第２の実施の形態）
次に、本発明の第２の実施の形態の開発マネジメントシステムについて説明する。
【００４０】
図２は、本実施の形態の開発マネジメントシステムのフローチャートを示す。同図において、２０１は過去の設計課題を蓄積及び参照するための課題データベースである。この課題データベースには、過去の故障モードや課題の発生頻度、課題の対策費用、課題の対策日程、課題に対応した開発技術者の経験年数、技術的スキルレベル、課題の検出手段、課題の対策工数などの課題に関連する副課題が蓄積され、これらの副課題のリスクに応じた数値（副課題のデータ）が設定されており、課題毎にこの副課題の数値を参照することができる。この数値は課題の発生に応じて値が変動するものであり、過去の課題と比較されて順次入れ替わり、常に最新のデータに更新されている。２０２は上記課題データベース２０１から参照される過去の課題の発生頻度についてのリストであり、故障モードごとに発生頻度が示されている。この発生頻度については、課題の技術レベルの難易とは直接関係を有さないのでケアレスミスを原因とする発生も多く含まれているリストである。２０３は対策費用についてのリストであり、故障モードに対する課題の改善の際に修正した半導体製品のマスク枚数に応じた費用が記載されており、微細化されたプロセスの場合はマスクの単位費用も高いものとなっている。２０４はマスク修正対策の日程をリストアップしたものである。ここでは、たとえ修正マスクが１〜２枚であっても、拡散日程が初期の工程の場合、修正から試作に要する工程数が多くなる。２０５は当該故障モードを抽出したリスト、２０６〜２０８は前記発生頻度２０２、対策費用２０３及び対策日程２０４の数値データが入力され、それらの数値データと前記故障モード２０５との比較を行い、それぞれの項目毎に、数値化した危険度のデータを出力する比較装置、２０９は前記比較装置２０６〜２０８が出力した危険度のデータを整理して、課題毎に所定の演算を行い、各故障モードに対する危険度を数値化しランク付けされたリストである。また、前記比較装置２０６〜２０８の出力結果に基づいて危険度ランキングリストを生成する構成２１４は危険度ランキングリスト生成装置（課題処理ランキングリスト生成手段）である。以下、２１０から２１３では、従来例および前記本発明の第１の実施の形態のように課題の優先度に基づいて設計完成度向上活動を行い、危険度の再評価と安全範囲の判別によって再度、設計完成度向上活動を実施する。
【００４１】
次に、具体的な数値化の例として、図４を用いて以下に説明する。尚、ここでは、５段階評価の場合を例にあげる。
【００４２】
図４（ａ）は、前記危険度ランキングリストの指標化の具体例であり、たとえば過去の課題事例から機能及び性能に関する項目として、ラッチアップなどの過電流発生による電源破壊などの場合は最も危険度が高いとして、ランクを５とする。課題が発生する場合でも使用条件によって問題ない場合はランクを１とする。このように課題の発生する内容に応じて危険度が異なるため、ランキングは過去のデータを統計したものを活用することで、より幅の広い視点から課題の数値化が可能となるものである。次に対策日程については、課題対策としてマスクデータを修正して再度試作を行う場合、２週間以上の場合は長期の日程を要するので、課題を重要視して、ランク５とし、１週間以内の場合はランク１とする。対策工数とは、課題が発生した場合に課題内容の把握とその対策に必要な工数であり、課題発生から修正マスクが完成するまでに２週間以上のものは重要度が高く、ランク５とし、１週間以内の場合はランク１とする。開発担当者については、当該故障モードに関する類似品種の設計経験者がいない場合は、課題処理が困難であるのでランク５とし、開発メンバー全員が類似品種の設計経験者の場合はランク１とするものである。検出手段とは、課題が発生した場合に課題を絞り込み原因をしらべることができる解析ツールの有無と、解析するための手段を列挙したものであり、決まった手法がなく、方針検討がない場合は処理の難易度が高いものとしてランク５とする。対策費用については、対策するための修正マスクに必要な費用によって金額が異なり、同図中の例の場合、１０００万円以上の高額な費用が発生する場合は重要課題であり、ランク５とし、若干の費用の場合はランク１とする。
【００４３】
以上の例は、過去の設計課題データベースに連携掲載している危険度ランキングリストから、当該故障モードに関わるリスクレベルを参照することができるものである。
【００４４】
ここで、各故障モードに対して、副課題項目にそれぞれ異なるランキングが生成されることになる。最終的に、設計上予想される故障モードに対する課題は、これら副課題のランキング値の最大値を前記危険度ランキングリスト生成装置（課題処理ランキングリスト生成手段）２１４により算出し、その結果をリストアップすることにより危険度を厳しく判断することができる。尚、ここで示す危険度の意味は広く、処理の困難さを示す難易度や、処理の優先度を示す重要度をも含むものである。
【００４５】
たとえば、図４（ｂ）に示すように、電源リークに関する過去の事例から、発生頻度がＷ回でランクは２、対策費用がＡ万円でランクが４、対策日程が３ヶ月でランクが５となった場合、最大値のランク５がリストアップされる。
【００４６】
故障モードが動作速度低下の場合については、発生頻度がＸ回でランク３、対策費用はＢ万円でランクが２、対策日程が１ヶ月でランクが３となった場合、最大値は発生頻度と対策日程が同じランクで３となる。
【００４７】
この例に示すように同じ副課題のランクが発生する場合、リスクの課題内容が重要となるので、最大値を出力するだけではなく、その内容と、図４（ｂ）には示さなかったが、具体的な修正概要を示すリストを同時に出力する機能を持たせることで課題内容の把握が可能となる。
【００４８】
したがって、この場合、図２中の過去の危険度ランキングリスト２０９を生成する危険度ランキングリスト生成装置２１４は、単純に危険度の数値化を過去の課題データベースから自動的に出力するだけでなく、課題内容に関連する事例も同時に出力することができるので、数値だけに着目してリスクの判定ミスを起こしてしまうことを防止する設計課題数値化の構成をとることも可能である。
【００４９】
上記の数値化の例では、多数の副課題項目について、算出した数値の最大値をインデックスに列挙したが、危険度ランキングリスト生成装置（ここでは、合計値又は乗算値を算出する構成）２１４において副課題のランキング値の合計値又は乗算値を演算することにより、多数の副課題項目の数値の合計値や乗算結果を列挙して、最もリスクの高い課題を列挙することも可能となる。最もリスクの高い課題項目を列挙することで、設計完成度向上活動の優先度が明確になるとともに、故障モードごとに課題項目も列挙されるため、具体的な取り組みの方針を決めるうえでも有益な情報となる。
【００５０】
尚、上記実施の形態では半導体装置を例に示したが、精密機器装置や輸送機器など一般的な開発手法として利用できることは言うまでもない。
【００５１】
【発明の効果】
以上説明したように、請求項１記載の発明によれば、課題データベースに蓄積された過去の課題データに組織情報を関連付けて、予想される故障モードと対応付けられた課題のリストを生成することにより、デザインレビューを行うに際し、最適な開発メンバーをコンピュータにより自動的に選択することができ、人員と開発期間とを有効に活用した効率のよい設計完成度活動が可能となる。
【００５２】
請求項２記載の発明によれば、課題データベースに蓄積された過去の課題を利用して、その課題に付随する複数の関連要件又は関連課題を考慮したランキング付けをコンピュータが自動的に行うことにより、関係者の主観的判断により、課題のレベルが決定されることを防止でき、精度の高い指標化が可能となる。
【００５３】
請求項３記載の発明によれば、故障モードに対して存在する複数の副課題項目毎の課題ランキングの結果からコンピュータが自動的に最大値を算出することにより、課題毎に最も課題に影響を与える副課題項目を速やかに判別でき、更に、その結果から最も重要度の高い課題を速やかに判別することができ、対策の早期着手を行うことが可能となる。
【００５４】
請求項４記載の発明によれば、故障モードに対して存在する複数の副課題項目毎に得られる副課題のランキング結果に対して、課題毎に、その副課題ランキング結果の合計値、又は乗算値をコンピュータが自動的に算出することにより、課題毎に全ての副課題の影響が考慮され、設計及び開発に最も影響を与える課題項目を速やかに判別でき、対策の早期着手を行うことが可能となる。
【００５５】
請求項５記載の発明によれば、副課題項目として、課題の発生頻度、課題の対策費用、課題の対策日程が含まれており、それぞれ発生頻度が高いほどレベルが高く、対策費用が高いほどレベルが高く、また、対策日程が長いほどレベルが高く配点されるように設定したことにより、開発に関する課題発生頻度、費用及び日程の重要度の数値化をコンピュータが自動的に行うことができるので、精度の高い指標化が可能となる。
【００５６】
請求項６記載の発明によれば、副課題項目として、開発担当者の実務経験年数、開発担当者の技術スキルレベル、課題の検出手段、及び課題の対策工数が含まれており、それぞれ、実務経験が短いほどレベルが高く、技術スキルが低いほどレベルが高く、課題の検出手段が少ないほどレベルが高く、また、課題の対策工数が長いほどレベルが高く配点されるように設定したことにより、課題頻度、費用、日程に加え、開発者の経験やスキルのレベルなどを数値化して更に精度の高い指標化が可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態における開発マネジメントシステムのフローチャート図である。
【図２】本発明の第２の実施の形態における開発マネジメントシステムのフローチャート図である。
【図３】（ａ）本発明の第１の実施の形態における故障モードと関係組織の関係を示した図である。（ｂ）本発明の第１の実施の形態における開発関係者の配置異動対応表を示した図である。
【図４】（ａ）本発明の第２の実施の形態における危険度リストの指標化の具体例を示した図である。（ｂ）本発明の第２の実施の形態における故障モードに対する危険度リストの指標を示した図である。
【図５】従来例の開発マネジメントシステムのフローチャート図である。
【符号の説明】
１０１、２０１    課題データベース
１０２            組織表
１０３            組織間課題抽出リスト（課題リスト）
１０４            故障モード抽出リスト
１０５            部署間課題選択装置（選択手段）
２０６、２０７、２０８          比較装置（副課題ランキング手段）
２０９            危険度ランキングリスト
２１４            危険度ランキングリスト生成装置
（課題処理ランキングリスト生成手段）
【図１】
2005025570.tif 000003
【図２】
2005025570.tif 000004
【図３】
2005025570.tif 000005
【図４】
2005025570.tif 000006
【図５】
2005025570.tif 000007