JP2010033530A - 設計支援システム、設計支援装置、設計支援プログラム及び該プログラムを記録した記録媒体 - Google Patents

Abstract

【課題】 ＱＦＤ手法を利用して得られる、製品開発の設計段階における技術的課題に対し、その技術的課題に対して検討すべき事項を提供する設計支援システムを提供すること。
【解決手段】 製品の開発に係る設計を支援する設計支援システムであって、ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを表示し、ユーザにより選択された組合せデータを送信する端末１０と、端末１０から送信された組合せデータを受信し、該組合せデータに基づき、ＤＢサーバ１２０に記憶された設計に対して検討すべき項目に関する検討項目データを抽出し、抽出された検討項目データを端末１０に送信し、ユーザに提供するアプリケーションサーバ１１０と、を有することを特徴とする。
【選択図】 図１

Description

本発明は、製品の開発に係る設計を支援する設計支援システムに関する。

製品の開発に係る設計を支援する種々の設計支援システムが知られている。例えば、以下に示す特許文献は、設計支援に関する技術として、部品間の設計要件の関連性を導出することを目的とするもの（特許文献１、特許文献２）、組立て不良を低減することを目的とするもの（特許文献３）、製品開発において発生した不具合に対する解決策を決定することを目的とするもの（特許文献４）、品質機能展開に関する手法（以下、ＱＦＤ手法という。）に関するデータを効率良く抽出することを目的とするもの（特許文献５）、製品のライフサイクル設計を効率よく行うことを目的とするもの（特許文献６）を開示している。

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

しかしながら、上述した特許文献１〜６に開示される設計支援技術は、設計者や開発者が設計段階において、要求品質に対し技術的にどのように実現すべきかという観点から、具体的に検討すべき事項まで提供するものではない。したがって、開発する製品の機種が異なる場合に、重複する部品が開発されたり、同じ機能で異なる部品が開発されたりする等、非効率な開発が行われる可能性がある。

本発明は、このような事情に鑑みてなされたものであり、ＱＦＤ手法を利用して得られる、製品開発の設計段階における技術的課題に対し、その技術的課題に対して検討すべき技術的事項を具体的に提供する設計支援システムを提供することを主たる目的とする。

かかる目的を達成するために、本発明の第一の態様は、製品の開発に係る設計を支援する設計支援システムであって、ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを表示し、ユーザにより選択された組合せデータを送信する端末と、端末から送信された組合せデータを受信し、該組合せデータに基づき、記憶手段に記憶された設計に対して検討すべき項目に関する検討項目データを抽出する抽出手段と、抽出手段で抽出された検討項目データを端末に送信し、ユーザに提供する提供手段と、を有することを特徴としている。

上記第一の態様によれば、端末からＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを送信すると、その組合せデータに対応付けられた、該組合せデータに対して検討すべき事項に関する検討項目データがユーザに提供される。

また、本発明の第二の態様は、抽出手段は、組合せデータに基づいて、製品の品質を担保するための品質特性に係る品質特性データを抽出し、該品質特性データに関連付けられた検討項目データを抽出することを特徴としている。

上記第二の態様によれば、開発者が要求品質と部品との組み合わせを特定すれば、その組み合わせに応じた品質特性が抽出され、該品質特性に対応する検討事項が提供される。

また、本発明の第三の態様は、抽出手段が、検討項目データに関連付けられて記憶手段に記憶された熟練者のナレッジ、レビュー期限、及び／又は、製品に係る過去のトラブルに関する付加データも併せて抽出し、提供手段は、抽出手段で抽出された付加データを端末に送信し、ユーザに提供することを特徴としている。

上記第三の態様によれば、開発経験の比較的浅い開発者であっても、熟練者のナレッジを利用することができる。

また、本発明の第四の態様は、抽出手段が、品質特性データに、顧客別の品質特性、及び／又は、仕向地別の品質特性に関する顧客別等品質特性データが含まれる場合に、抽出された品質特性データを顧客別等品質特性データに置換し、該顧客別等品質特性データに関連付けられた検討項目データを抽出する。

上記第四の態様によれば、顧客別の品質特性、仕向地別の品質特性に対応する検討事項が提供される。

また、本発明の第五の態様は、提供手段は、検討項目データを送信し、ユーザに提供した後に、ユーザにより選択された組合せデータに対し、選択の変化が発生した場合に、変化前後に係る組合せデータに関連付けられた検討項目データを対比してユーザに提供することを特徴としている。

上記第五の態様によれば、ＱＦＤ手法に関するデータに変化があっても、その変化が対比して提供される。

また、本発明の第六の態様は、検討項目データに対し、検討結果に関する検討結果データを端末からの指示に基づいて記憶手段に登録する第１の登録手段と、記憶手段に登録された検討結果データに対し、承認の度合いに応じたデータを包含する第１の包含手段と、をさらに含み、第１の登録手段は、検討結果データに対して承認度の高いデータが包含されたと判定した場合に、所定の情報をユーザに通知することを特徴としている。

上記第六の態様によれば、例えば検討事項に対し承認がなされると、その旨がユーザに通知されることとなり、検討事項が承認されていない状態で、検討会が開始されることが回避される。

また、本発明の第七の態様は、検討会に対する検討会結果に関する検討会結果データを端末からの指示に基づいて記憶手段に登録する第２の登録手段と、記憶手段に登録された検討会結果データに対し、検討結果を判定する判定データを包含する第２の包含手段と、をさらに含み、第２の登録手段は、検討会結果データに対して正の判定データが包含される度に、開発プロセスにおけるイベントデータを段階的に移行していくことを特徴としている。

上記第七の態様によれば、検討会での承認が得られない限り、製品の開発プロセスが進められなくなる。

また、本発明の第八の態様は、製品の開発に係る設計を支援する設計支援装置であって、ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを受信し、該組合せデータに基づき、記憶手段に記憶された設計に対して検討すべき項目に関する検討項目データを抽出する抽出手段と、抽出手段で抽出された検討項目データ送信する送信手段と、を有することを特徴としている。

また、本発明の第九の態様は、製品の開発に係る設計を支援する設計支援プログラムであって、コンピュータによって実行されたときに、当該コンピュータを、ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを受信し、該組合せデータに基づき、記憶手段に記憶された設計に対して検討すべき項目に関する検討項目データを抽出する抽出手段、抽出手段で抽出された検討項目データ送信する送信手段、として機能させることを特徴としている。

また、本発明の第十の態様は、上記プログラムを記録したコンピュータ読取可能な記録媒体である。

また、本発明の第十一の態様は、製品の開発に係る設計を支援する設計支援システムであって、ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する第１の組合せデータを表示し、ユーザにより選択された第１の組合せデータを送信する端末と、端末から送信された第１の組合せデータを取得すると共に、該第１の組合せデータの取得以前に既に選択され、又は、登録された、第２の組合せデータを記憶した記憶手段から、すべての第２の組合せデータを取得し、第１の組合せデータを基準に、すべての第２の組合せデータとそれぞれ比較し、比較結果に係る類似度の高い第２の組合せデータに関連付いた開発機種に関する機種データを抽出する変化点抽出手段と、変化点抽出手段で抽出された機種データを昇順に並び替えて端末に送信し、ユーザに提供する提供手段と、を有することを特徴としている。

上記第十一の態様によれば、端末からＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを送信すると、該第１の組合せデータの取得以前に既に選択され、又は、登録された、第２の組合せデータとの対比の対象となる機種の一覧が類似度の高い順にユーザに提供される。

また、本発明の第十二の態様は、変化点抽出手段は、記憶手段から、第１の組合せデータに関連付いた開発機種と異なる機種となる第２の組合せデータを取得することを特徴としている。

上記第十二の態様によれば、第１の組合せデータに関連付いた開発機種と異なる機種がユーザに提供される。

また、本発明の第十三の態様は、変化点抽出手段は、記憶手段から、第１の組合せデータに関連付いた開発機種の基となる第２の組合せデータを取得することを特徴としている。

上記第十三の態様によれば、第１の組合せデータに関連付いた開発機種の基となる機種がユーザに提供される。

また、本発明の第十四の態様は、変化点抽出手段は、記憶手段から、第１の組合せデータに関連付いた開発機種と同一の機種となる第２の組合せデータを時系列に取得することを特徴としている。

上記第十四の態様によれば、第１の組合せデータに関連付いた開発機種と同一の機種が時系列にユーザに提供される。

また、本発明の第十五の態様は、変化点手段は、第１の組合せデータからそれぞれの第２の組合せデータを差し引いた第１の差引データの数と、それぞれの第２組合せデータから第１組合せデータを差し引いた第２の差引データの数と、の和が、より小さくなる第２の組合せデータを類似度が高いと判断することを特徴としている。

上記第十五の態様によれば、第１の組合せデータと第２の組合せデータの相違点が少ないほど、類似度が高いと判定される。

また、本発明の第十六の態様は、提供手段は、第２の組合せデータと相違する第１の組合せデータの部分を強調して提供することを特徴としている。

上記第十六の態様によれば、第１の組合せデータと第２の組合せデータとの相違点が認識され易くなる。

また、本発明の第十七の態様は、製品の開発に係る設計を支援する設計支援装置であって、ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを取得すると共に、該第１の組合せデータの取得以前に既に選択され、又は、登録された、第２の組合せデータを記憶した記憶手段から、すべての第２の組合せデータを取得し、第１の組合せデータを基準に、すべての第２の組合せデータとそれぞれ比較し、比較結果に係る類似度の高い第２の組合せデータに関連付いた開発機種に関する機種データを抽出する変化点抽出手段と、変化点抽出手段で抽出された機種データを昇順に並び替えて端末に送信する機種データ送信手段と、を有することを特徴としている。

また、本発明の第十八の態様は、製品の開発に係る設計を支援する設計支援プログラムであって、コンピュータによって実行されたときに、当該コンピュータを、ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを取得すると共に、該第１の組合せデータの取得以前に既に選択され、又は、登録された、第２の組合せデータを記憶した記憶手段から、すべての第２の組合せデータを取得し、第１の組合せデータを基準に、すべての第２の組合せデータとそれぞれ比較し、比較結果に係る類似度の高い第２の組合せデータに関連付いた開発機種に関する機種データを抽出する変化点抽出手段、変化点抽出手段で抽出された機種データを昇順に並び替えて端末に送信する機種データ送信手段、として機能させることを特徴とする設計支援プログラムである。

また、本発明の第十九の態様は、上記プログラムを記録したコンピュータ読取可能な記録媒体である。

本発明によれば、ＱＦＤ手法を利用して得られる、製品開発の設計段階における技術的課題に対し、その技術的課題に対して検討すべき技術的事項を具体的に提供することで、製品開発に係る設計を支援することができる。

以下、本発明の実施の形態について、図面を参照して具体的に説明する。

（第１実施形態）
図１は、本発明の第１実施形態に係る設計支援システムの構成図である。設計支援システムは、図１に示すように、端末１０、アプリケーションサーバ１１０（以下、単にサーバという。）及びデータベースサーバ１２０（以下、ＤＢサーバという。）等がＬＡＮ、ＷＡＮ等のネットワーク４０によって互いに接続されて構成される。尚、サーバ１１０とＤＢサーバ１２０とを一体とした設計支援装置１００としてもよい。

端末１０は、例えば、キーボード、マウス等の入力手段、液晶ディスプレイやＣＲＴディスプレイ等の表示手段、これらを制御するコンピュータ等の制御手段を含むＰＣ（Personal Computer）で構成される。携帯電話やＰＤＡ（Personal Digital Assistants）等であってもよい。端末は、同図に示すように、複数台で構成されてもよいし、１台であってもよい。

ＤＢサーバ１２０は、設計支援に必要な各種データを記憶するデータベースサーバである。各種データとしては、例えば、開発する製品の機種に係るデータ、ＱＦＤ手法に関するデータ、熟練者の検討項目、ナレッジ（knowledge）、ノウハウ（know-how）、知恵等に関するデータ、デザインレビューに関するデータ、レビュー期限（検討期限）に関するデータ、レビュー結果に関するデータ等がある。ここで、デザインレビューとは、設定された目標を達成するための検討対象の適切性、妥当性及び有効性を判定するために行われる活動をいう（JIS Q 9001）。ＤＢサーバ１２０は、サーバ１１０から接続されて、各種データをサーバ１１０に提供する。

続いて、上述したサーバ１１０及びＤＢサーバ１２０の詳細について説明する。まず、サーバ１１０について図２を参照して説明する。

図２は、サーバ１１０の要部構成を例示する機能ブロック図である。

サーバ１１０は、図２に示すように、開発プロセス定義データ管理部１１１、ＱＦＤ・検討項目定義データ管理部１１２、開発機種管理部１１３、品質特性抽出部１１４、検討項目抽出部１１５及び制御部１１６等を含んで構成される。尚、品質特性抽出部１１４及び検討項目抽出部１１５等から本発明の抽出手段、提供手段又は送信手段が構成される。

これらの各部１１１〜１１５は、制御部１１６が端末１０からの指示（例えば依頼、要求又はコマンド等）、又は、他の機能の処理結果等を受信すると、制御部１１６が各部１１１〜１１６を稼動させる。また、必要な処理が終了すると、制御部１１６がこれを検出し、処理結果を端末１０に提供する。

また、サーバ１１０は、いわゆるコンピュータ、すなわち、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏインタフェース等がバスにより接続されたハードウェア構成により実現される。したがって、端末１０からの指示に応じて、ＣＰＵがＲＡＭやＲＯＭ等の記憶装置に格納された所要のプログラムを読み込み、当該プログラムに従った演算を行うことにより、上述したサーバ１１０の各機能が実現される。尚、このようなプログラムとしては後述するフローチャートに応じたプログラムとすることができる。これらの構成は、ＤＢサーバ１２０についても同様である。

開発プロセス定義データ管理部１１１は、端末１０から送信された開発プロセスの定義付けに関するデータを受信して、このデータを開発プロセス定義ＤＢ１２１に記憶する。開発プロセスの定義付に関するデータとしては、例えば、開発企画審議会、構想設計審議会、詳細設計審議会等、製品の開発を進めていく上で行われる種々の審議、検討会が含まれる。これにより、製品の開発に係るプロセス（工程）の定義付けがされ、開発プロセスの特定が可能となる。開発プロセスの追加要求や変更要求を受信した場合には、これらの要求に従って、開発プロセスの追加処理や変更処理を行う。追加された開発プロセスは開発プロセス定義ＤＢ１２１に新たに記憶される。変更要求を受信した場合には、変更対象となる開発プロセスを変更内容に応じて変更する。

ＱＦＤ・検討項目定義データ管理部１１２は、ＱＦＤ手法に関する各データ、具体的には、要求品質に関する要求品質データ、品質特性に関する品質特性データ、部品（機能、構造、モジュール等を含む。）に関する部品データ、ＱＦＤ手法により得られる技術的課題に対し検討すべき項目に関するデータの定義付けを行う。定義付けされたこれらのデータは、後述する要求品質ＤＢ１２２、品質特性ＤＢ１２３、部品ＤＢ１２４、検討項目ＤＢ１２５にそれぞれ記憶される。

開発機種管理部１１３は、製品の開発機種に関する種々のデータを管理する。このデータには開発機種ごとに識別データが付されている。これにより、開発機種を識別できる。製品は中間製品、最終製品のいずれでもよく、例えば携帯電話や自動車等の最終製品、及び、これらに利用する各種部品等が該当する。開発機種管理部１１３は、端末１０から開発機種の登録や変更、削除などの要求があったときに稼動する。例えば、登録要求であれば、その内容に関するデータを開発機種ＤＢ１２６に登録したり、変更要求であれば、開発機種ＤＢ１２６に記憶されているデータを変更内容に応じて変更したりする。

品質特性抽出部１１４は、端末１０から送信された要求品質と部品との組み合わせ（関連付け）に関する組合せデータに基づいて、その組合せデータに対応する品質特性データを品質特性ＤＢ１２３から抽出する。このように、端末１０から要求品質と部品との組み合わせを特定してサーバ１１０に送信すれば、要求品質と部品とに関連付けられた品質特性が得られる。

検討項目抽出部１１５は、品質特性抽出部１１４によって抽出された品質特性データに基づいて、この品質特性データに割り当てられた検討項目に関する検討項目データを検討項目ＤＢ１２４から抽出する。したがって、要求品質及び部品の組み合わせを特定することで、この組み合わせに対応する品質特性が得られ、さらに、この品質特性に対応する検討項目が抽出される。

次に、ＤＢサーバ１１０の詳細について説明する。

図３は、ＤＢサーバ１２０の要部構成を例示する機能ブロック図である。

ＤＢサーバ１２０は、図３に示すように、開発プロセス定義ＤＢ１２１、要求品質ＤＢ１２２、品質特性ＤＢ１２３、部品ＤＢ１２４、検討項目ＤＢ１２５、開発機種ＤＢ１２６及び制御部１２７等を含んで構成される。尚、これらの各ＤＢ１２１〜１２６から本発明の記憶手段が構成される。

開発プロセス定義ＤＢ１２１は、開発プロセスに関する各種データを記憶するデータベースである。このデータには、上述したような開発企画審議会、構想設計審議会、詳細設計審議会、量産設計審議会等がある。部品の製造順序、組立順序、検査順序に関する審議会等の組み合わせであってもよい。

要求品質ＤＢ１２２は、要求品質データを記憶するデータベースである。要求品質とは、開発する製品に対して目的とする品質に関する事項であり、例えば携帯電話であれば、操作キーの円滑な（スムースな）稼動希望等が該当する。

品質特性ＤＢ１２３は、品質特性データを記憶するデータベースである。品質特性とは、上述した要求品質を充足するか否かを評価するための技術的な指標又は要素をいう。例えば、上述した操作キーのスムース稼動であれば、キーボタンを押下した際に引っ掛かりがないことが品質特性となる。品質特性を保持することで、開発する製品の品質が担保される。

部品ＤＢ１２４は、部品データを記憶するデータベースである。携帯電話であれば、上述した操作キーの他、アンテナやケース、ヒンジ部、バッテリー等が部品として該当する。

検討項目ＤＢ１２５は、検討項目データを記憶するデータベースである。検討項目とは、製品を開発する開発者や設計者が、上述した品質特性を得るために検討、確認を行う項目をいう。上述した例であれば、例えば、操作キーを最大限押下（フルストローク）した際に操作キーの押下部分がケースより低い位置とならないこと等が検討項目に該当する。この検討項目は、製品の開発に長年携わった熟練者のナレッジ、ノウハウ、知恵等が利用される。これにより、開発経験の比較的浅い開発者であっても、熟練者のナレッジ等を利用できる。

開発機種ＤＢ１２６は、開発機種に関するデータを記憶するデータベースである。開発機種に関するデータには、例えば、車種や機種等のコードや車種・機種名、必要な部品や寸法等のデータがある。

続いて、設計支援システムの動作について説明する。

まず、開発プロセス等に関するデータの登録処理について図４及び図５を参照して説明する。開発プロセスは、連続するイベント（審議会等）の集合によって構成される。イベントが順次承認されることによって、開発プロセスが進められていく。

図４は、開発プロセス定義データ管理部１１１の動作の一例を示すフローチャート、図５は、イベントデータ等の登録過程を説明する図である。

開発プロセス定義データ管理部１１１は、図４に示すように、まず、端末１０からイベントに関するデータ（以下、イベントデータという。）の登録要求があったか否かを判定し（ステップＳ１）、登録要求があったと判定した場合には、イベントデータを開発プロセス定義ＤＢ１２１に登録する（ステップＳ２）。この結果、図５（ａ）に示すように、実施するイベントがイベント名に登録される。

開発プロセス定義データ管理部１１１は、次いで、端末１０からイベントの実施順序に関するデータの登録要求があったか否かを判定し（ステップＳ３）、登録要求があったと判定した場合には、イベントの実施順序に関するデータを開発プロセス定義ＤＢ１２１に登録する（ステップＳ４）。この結果、図５（ｂ）に示すように、イベントの実施順序が決定される。

開発プロセス定義データ管理部１１１は、次いで、端末１０からイベントデータに対する準備物に関するデータの登録要求があったか否かを判定し（ステップＳ５）、登録要求があったと判定した場合には、準備物に関するデータを開発プロセス定義ＤＢ１２１に登録する（ステップＳ６）。この結果、図５（ｃ）に示すように、イベントに向けて準備すべき必要資料が決定される。

開発プロセス定義データ管理部１１１は、次いで、端末１０から準備物データに対する確認内容に関するデータの登録要求があったか否かを判定し（ステップＳ７）、登録要求があったと判定した場合には、確認内容に関するデータを開発プロセス定義ＤＢ１２１に登録する（ステップＳ８）。この結果、図５（ｄ）に示すように、準備物に対する確認内容（例えば、企画内容や企画者）が決定される。

開発プロセス定義データ管理部１１１は、ここで、端末１０から継続して上述したイベントデータ等の登録を行う旨の要求があった場合には、図４に示したステップＳ１の処理に戻り、行わない旨の要求があった場合にはイベントデータ等の登録処理を終了する（ステップＳ９）。継続して行った場合、図５（ｅ）に示すように、実施していくイベントが順序付けられ、準備すべき資料や確認内容と共に関連付けられ、開発プロセス定義データとしてＤＢサーバ１２０に登録される。

次に、ＱＦＤ手法に利用するデータ、検討項目に関するデータ、ナレッジ等に関するデータのＤＢサーバ１２０への登録処理について図５から図８を参照して説明する。

図６及び図７は、ＱＦＤ・検討項目定義データ管理部１１２の動作の一例を示すフローチャート、図８は登録処理により得られるＱＦＤデータの一例である。尚、これらのフローチャートは一例のフローチャートであり、それぞれの図において、処理が継続される箇所に符号（Ａ１，Ａ２）が付されて対応付けされている。

図６に示すように、まず、ＱＦＤ・検討項目定義データ管理部１１２は、端末１０から要求品質データの登録要求があったか否かを判定し（ステップＳ１１）、登録要求があったと判定した場合には、要求品質データを要求品質ＤＢ１２２に登録する（ステップＳ１２）。要求品質データとしては、図８に示すように、「アンテナが適度な力で保持できる」等がある。

ＱＦＤ・検討項目定義データ管理部１１２は、次いで、端末１０から品質特性データの登録要求があったか否かを判定し（ステップＳ１３）、登録要求があったと判定した場合には、品質特性データを品質特性ＤＢ１２３に登録する（ステップＳ１４）。品質特性データとしては、図８に示すように、「キーボタンの潜り込みなきこと」等がある。

ＱＦＤ・検討項目定義データ管理部１１２は、次いで、端末１０から品質特性データに関連するナレッジデータの登録要求があったか否かを判定し（ステップＳ１５）、登録要求があったと判定した場合には、品質特性データに関連するナレッジデータをその品質特性データに関連付けて品質特性ＤＢ１２３に登録する（ステップＳ１６）。これにより、品質特性に対する熟練者のナレッジ等が生かされるようになる。

ＱＦＤ・検討項目定義データ管理部１１２は、次いで、端末１０から顧客別の品質特性に関するデータ（以下、顧客別品質特性データという。）の登録要求があったか否かを判定し（ステップＳ１７）、その登録要求があったと判定した場合には、登録済の品質特性データに対し、顧客別品質特性データを関連付けて登録する（ステップＳ１８）。品質を担保するための条件は、顧客ごとに異なる可能性があるため、通常の品質特性をさらに細かく顧客単位で定められるようにしたものである。尚、ステップＳ１７及びステップＳ１８の処理は、開発者が不要と考える場合には必ずしも行う必要がない。この場合、品質特性は、既に登録された通常の品質特性により決定される。したがって、品質特性は汎用性の高いものとなる。この品質特性は、初期設定（デフォルト）の品質特性となる。

ＱＦＤ・検討項目定義データ管理部１１２は、次いで、端末１０から仕向地別の品質特性に関するデータ（以下、仕向地別品質特性データという。）の登録要求があったか否かを判定し（ステップＳ１９）、その登録要求があったと判定した場合には、登録済の品質特性データに対し、仕向地別品質特性データを関連付けて登録する（ステップＳ２０）。品質を担保するための条件は、例えば日本国内とヨーロッパやアメリカ等の日本国外と、製品を販売する仕向地ごとに異なる可能性があるため、通常の品質特性をさらに細かく仕向地単位で定められるようにしたものである。尚、ステップＳ１９及びステップＳ２０の処理は、開発者が要求しない場合には、行わないようにしてもよい。

図７に移り、ＱＦＤ・検討項目定義データ管理部１１２は、次いで、端末１０から部品データの登録要求があったか否かを判定し（ステップＳ２１）、登録要求があったと判定した場合には、部品データを部品ＤＢ１２４に登録する（ステップＳ２２）。部品データとしては、図８に示すように、「下ケース裏面」等がある。

ＱＦＤ・検討項目定義データ管理部１１２は、次いで、端末１０から部品データに関連するナレッジデータの登録要求があったか否かを判定し（ステップＳ２３）、登録要求があったと判定した場合には、部品データに関連するナレッジデータをその部品データに関連付けて部品ＤＢ１２４に登録する（ステップＳ２４）。これにより、部品に対する熟練者のナレッジ等が生かされるようになる。

ＱＦＤ・検討項目定義データ管理部１１２は、次いで、端末１０から品質特性データと部品データとの組み合わせに対する、検討項目データの登録要求があったか否かを判定し（ステップＳ２５）、登録要求があったと判定した場合には、その検討項目データを上記組み合わせに関連付けて検討項目ＤＢ１２５に登録する（ステップＳ２６）。これにより、図８に示すように、品質特性と部品との組み合わせが特定されると、この組み合わせに対応する検討項目の抽出が可能となる。

ＱＦＤ・検討項目定義データ管理部１１２は、さらに、ステップＳ１６の処理で登録された検討項目データに対し、検討期限を関連付ける処理を行う（ステップＳ２７）。この検討期限は、後述するイベント（審査会等）の開催時期と対応付けされている。したがって、検討項目は、イベントの開催時期までに検討しなければならなくなる。

ＱＦＤ・検討項目定義データ管理部１１２は、次いで、端末１０から検討項目データに関連するナレッジデータの登録要求があったか否かを判定し（ステップＳ２８）、登録要求があったと判定した場合には、検討項目データに関連するナレッジデータをその検討項目データに関連付けて検討項目ＤＢ１２５に登録する（ステップＳ２９）。これにより、検討項目に対する熟練者のナレッジ等が生かされるようになる。

ＱＦＤ・検討項目定義データ管理部１１２は、ここで、端末１０から継続して上述したＱＦＤデータ等の登録を行う旨の要求があった場合には、図６に示したステップＳ１１の処理に戻り、行わない旨の要求があった場合にはＱＦＤデータ等の登録処理を終了する（ステップＳ３０）。

この結果、図８に示すように、ＱＦＤデータは、要求品質、品質特性及び部品の各データが関連付けられた三元表の雛形で表されることになる。同図によれば、要求品質の登録処理により、要求品質「アンテナが適度な力で保持できる」等が登録される。また、品質特性の登録処理により、品質特性「キーボタンの引掛かりなきこと」等が登録され、必要に応じて、顧客や仕向地ごとの登録が可能となる。さらに、部品の登録処理により、部品「下ケース前面」等が登録される。この三元表の雛形は、携帯電話を一例としたものであるが、開発機種に応じて種々のパターンを生成することができる。

また、要求品質と品質特性とにより構成される二元表（マトリクス）、品質特性と部品とにより構成されるマトリクスには、丸印が付された箇所と付されていない箇所がある。丸印が付された箇所は、要求品質と品質特性、又は、品質特性と部品との関連付けがなされていることを示す。例えば、品質特性「キーボタンの引掛かりなきこと」と部品「キー」とは、関連付けがなされているが、部品「バッテリー」とは関連付けがなされていない。そして、この関連付けに対し、検討項目が関連付けられる。尚、要求品質と品質特性との関連付けは、本システムを管理する管理者等により予め行うようにする。また、要求品質と部品との関連付けは、後述するように、本システムを利用するユーザ（、開発者、設計者等）により選択画面を通じて選択される。

次に、開発機種に関するデータのＤＢサーバ１２０への登録処理について図９を参照して説明する。

図９は、開発機種管理部１１３の動作の一例を示すフローチャートである。

開発機種管理部１１３は、まず、開発機種データの登録要求を端末１０から受け付けると、開発機種データを入力する入力画面を表示する（ステップＳ３１）。これにより、開発者は、開発機種に関する種々のデータの入力を行うことができる。

開発機種管理部１１３は、次いで、ＱＦＤ三元表の雛形を選択させる選択画面を表示させる（ステップＳ３２）。ＱＦＤ三元表の雛形は、例えば図８に示すようなものである。雛形を選択すればこの雛形に関連付けられた要求品質データ、品質特性データ、部品データ及び検討項目データがそれぞれ要求品質ＤＢ１２２、品質特性ＤＢ１２３、部品ＤＢ１２４及び検討項目ＤＢ１２５から取得されて表示される。尚、選択画面の表示に代えて、上記入力画面内にＱＦＤ三元表の雛形を選択させる選択ボックスを設けるようにしてもよい。これにより、開発機種に利用する三元表の雛形が決定される。

開発機種管理部１１３は、さらに、顧客別の品質特性に関するデータ、仕向地別の品質特性に関するデータを選択させる選択画面を表示させる（ステップＳ３３、Ｓ３４）。これらのデータは、品質特性ＤＢ１２３は取得して表示すればよい。当該選択画面についても、上記入力画面内に同じ機能を設けてもよい。

開発機種管理部１１３は、さらに、開発プロセスの雛形を選択させる選択画面を表示させる（ステップＳ３５）。開発プロセスの雛形は、開発プロセス定義ＤＢ１２１から取得して表示すればよい。当該選択画面についても、入力画面内に同じ機能を設けてもよい。

開発機種管理部１１３は、ここで、端末１０からの指示に基づいて、画面内に入力された内容、選択された内容の登録処理を行うか否かを判定する（ステップＳ３６）。登録処理を行う場合には、開発機種管理部１１３は、画面内の入力内容等を開発機種ＤＢ１２６に登録し（ステップＳ３７）、登録処理をキャンセルする場合には、処理を終了する。これにより、開発機種に関するデータに、ＱＦＤデータ、開発プロセスデータ等が関連付けられて開発機種ＤＢ１２６に記憶される。

ここまで説明したように、図４から図９に示すフローチャートにおける処理は、開発プロセスデータ、ＱＦＤデータ、開発機種に関するデータ等のＤＢサーバ１２０への登録処理を示している。これらのデータは、上述したように、開発者が行ってもよいが、設計支援システムの構成する構成要素以外のコンピュータシステム、データベース等から取得するようにしてもよい。これにより、開発者のデータ登録の手間が回避される。

続いて、開発者が設計支援システムを利用した場合ついて説明する。

図１０は、品質特性抽出部１２４の動作の一例を示すフローチャート、図１１は、要求品質と部品との組み合わせを選択する選択画面の一例である。

品質特性抽出部１２４は、端末１０からログイン要求を受け付けると、ログイン処理を開始する（ステップＳ４１）。ログイン処理は、例えば、開発者のユーザＩＤ、パスワード等を利用して行えばよい。

品質特性抽出部１２４は、次いで、開発機種の一覧を端末１０に表示する（ステップＳ４２）。開発機種の一覧は、開発機種ＤＢ１２６から取得すればよい。開発機種ＤＢ１２６には、上述したように、種々の開発機種に関するデータが記憶されている。

品質特性抽出部１２４は、ここで、開発機種の選択があったか否かを判定する（ステップＳ４３）。開発機種の選択判定は、端末１０の画面上に表示された開発機種が指示（例えばクリック等）されたか否かにより行われ、一の開発機種が選択されて指示された場合に、品質特性抽出部１２４は、開発機種の選択があったと判定する。これにより、設計支援を受ける開発機種が特定される。

品質特性抽出部１２４は、次いで、選択された開発機種に関連付けられたＱＦＤ三元表の雛形を端末１０に選択画面として表示する（ステップＳ４４）。開発機種とＱＦＤ三元表の雛形との関連付けは、上述したように、開発機種の登録処理の際に行われている。また、ＱＦＤ三元表の雛形に含まれるべき要求品質データ、部品データ等は、それぞれ要求品質ＤＢ１２２、部品ＤＢ１２４に記憶されている。このため、品質特性抽出部１２４は、要求品質ＤＢ１２２、部品ＤＢ１２４を検索して要求品質等に関するデータを抽出し、抽出された要求品質と部品とによってマトリクス状の選択画面を構成し表示する。

具体的には、図１１に示すように、選択画面は、抽出された複数の要求品質を縦軸に、抽出された複数の部品を横軸にしてマトリクスを構成する。このマトリクスの各マス目は、マウス等によって移動可能なポインタＰｔによって選択可能となっている。同図に示すように、マス目を選択していくと、そのマス目には例えば丸等の印が表示され、そのマス目が選択されたことを示す。したがって、開発者は、要求品質と部品とのマス目を必要に応じて選択していく。

品質特性抽出部１２４は、ここで、選択が完了したか否かを判定する（ステップＳ４５）。当該判定処理は、図１１に示す完了ボタンＢｔがポインタＰｔによって指示されたか否かによって判定する。

品質特性抽出部１２４は、ステップＳ４５の処理において、完了ボタンが押下されたと判定した場合等には、選択されたマス目に対応する品質特性データを抽出し（ステップＳ４６）、抽出処理が完了すると、その旨を検討項目抽出部１２５に送信する。

ここで、当該抽出処理について図１２を参照してさらに詳しく説明する。

図１２は、要求品質、品質特性及び部品によって構成される三元表マトリクスの一例であり、図８を参照して説明した三元表マトリクスを立体表記したものである。

この三元表マトリクスは、図１２に示すように、要求品質と部品とのマトリクス（図１２において第１マトリクスと示す。）、要求品質と品質特性とのマトリクス（同図において第２マトリクスと示す。）及び品質特性と部品とのマトリクス（同図において第３マトリクスと示す。）によって構成される。そして、第１マトリクスが、上述した選択画面に相当し、開発者が選択処理を行う選択画面となる。

したがって、第１マトリクス上の任意のマス目を開発者が選択すると、要求品質と部品との組み合わせが特定される。そして、品質特性抽出部１４６は、同図に示すように、この特定された組み合わせに対する品質特性データを抽出する。同図によれば、２つの品質特性データＡ，Ｂが抽出される。これにより、要求品質と部品との組み合わせに対応する品質特性が決定される。

図１３は、検討項目抽出部１２５の動作の一例を示すフローチャートである。検討項目抽出部１２５は、決定された品質特性から開発者が検討すべき項目を表示する処理を行うものである。

検討項目抽出部１２５は、品質特性抽出部１２４から抽出処理完了の旨を受信すると稼動し、図１３に示すように、まず、抽出された品質特性データの中に、顧客別品質特性データ、仕向地別品質特性データが含まれているか否かを判定し（ステップＳ５１）、さらに、抽出された品質特性データが顧客別品質特性データであるか否か判定する（ステップＳ５２）。

検討項目抽出部１２５は、ステップＳ５２の処理において、抽出された品質特性データに顧客別品質特性データが含まれると判定した場合には、デフォルト（初期設定）の品質特性データを、顧客別品質特性データに置換し（ステップＳ５３）、置換後の品質特性データと部品との組み合わせから検討項目データを抽出する（ステップＳ５４）。

一方、検討項目抽出部１２５は、ステップＳ５２の処理において、抽出された品質特性データが顧客別の品質特性データでないと判定した場合、又は、ステップＳ５４の処理を終了した場合には、次いで、抽出された品質特性データに仕向地別の品質特性データが含まれているか否かを判定する（ステップＳ５５）。

検討項目抽出部１２５は、ここで、抽出された品質特性データに仕向地別品質特性データが含まれていると判定した場合には、さらに、デフォルトの品質特性データが既に顧客別品質特性データに置換されているか否かを判定する（ステップＳ５６）。そして、置換されていないと判定した場合には、デフォルトの品質特性データを仕向地別品質特性データに置換し（ステップＳ５７）、置換されていると判定した場合には、仕向地別品質特性データを追加する（ステップＳ５８）。検討項目抽出部１２５は、ステップＳ５７又はＳ５８の処理を終えた仕向地別の品質データと部品データとの組み合わせから検討項目データを抽出する（ステップＳ５９）。

尚、上述したステップＳ５１の処理において、抽出された品質特性データの中に、顧客別の品質特性データ、仕向地別の品質特性データが含まれていないと判定した場合には、デフォルトの品質特性データと部品データとの組み合わせから検討項目データを抽出する（ステップＳ６０）。

ここで、検討項目データの抽出処理について、既に説明した図１２を参照して簡単に説明する。

既に説明したように、選択画面において、要求品質と部品とを選択により特定すると、これらの組み合わせに応じた品質特性が決定される。図１２においては、品質特性Ａ、Ｂが決定される。これらの品質特性データＡ、Ｂと選択された部品データに対応するものが、同図に示すように、検討項目Ｃ、Ｄとして抽出される。尚、顧客別の品質特性、仕向地別の品質特性が含まれる場合には、品質特性データＡ、Ｂがそれぞれ置換された上で部品データとの組み合わせが構成されて、検討項目データが抽出される。これにより、顧客の仕様（スペック）や、部品・製品等の納入地に応じた検討項目の抽出が可能となる。

検討項目抽出部１２５は、ここで、すべての検討項目データの抽出を行ったか否かを判定し（ステップＳ６１）、まだ、例えば、検討項目Ｃだけしか抽出し終えていないなど、すべての抽出を行っていないと判定した場合には、品質特性抽出１２４にその旨を送信する。一方、検討項目Ｃ、Ｄを抽出した等、すべての検討項目データの抽出を終えたと判定した場合には、図１４に示すように、選択された部品に関する表示（同図において部品ツリー画面と示す。）を表示する（ステップＳ６２）。この際、選択された部品が開発者に理解され易くするために、選択されていない他の部品と色を変えるようにしたり、大きさを変えるようにしてもよい。尚、同図においては、説明の都合上、選択された部品にハッチングを付している。

検討項目抽出部１２５は、上述した部品ツリー画面を表示すると、選択された部品に関連付いた要求品質データ及び品質特性データを表示する（ステップＳ６３）。具体的には、上述した部品ツリー画面の表示と併せて、図１５に示すように、検討項目表示画面（出力結果画面）内に要求品質データ及び品質特性データを表示する。

この検討項目表示画面は、画面のタイトル等を表示する画面タイトル部１５、ＱＦＤデータに関する項目等を表示する関連ＱＦＤデータ表示部１６、検討項目等を表示する検討項目表示部１７を含んで構成される。

画面タイトル部１５には、選択された部品名が表示される。これにより、表示されているＱＦＤデータや検討項目等は、選択した部品に関連付けられていると開発者は理解できる。

関連ＱＦＤデータ表示部１６は、選択した要求品質及びその分類、抽出された品質特性が品質特性ごとに表示される。これらの表示項目以外にも、機種ごとに入力される設計目標や課題、従来製品や他社製品との違い等を表示させるようにしてもよい。関連ＱＦＤデータ表示部１６は、ポインタＰｔからの指示により選択可能となっている。同図においては、品質特性「キーボタンの引掛りなきこと」が選択されていることを示している。

検討項目抽出部１２５は、ステップＳ６３の処理を終了すると、部品名とその部品に関連する検討項目を表示する（ステップＳ６４）。部品名と検討項目は、図１５に示すように、検討項目表示部１７に検討項目ごとに表示される。より詳しくは、検討項目表示部１７に検討項目の内容が具体的に表示される。尚、検討項目表示部１７では、検討項目の内容が部分的にしか表示されていないが、検討項目と検討期限との区切りは指示により左右に移動稼動であり、この区切りを移動させることで、画面下に示す吹き出しに記載された検討項目の内容が表示されるようになる。

また、図１５に示すように、検討項目表示部１７には、検討項目ごとに検討期限及びナレッジに関するファイルが表示される。開発者は、適宜、ナレッジを選択・指示し、ファイルを開くことで、検討項目に対する熟練者のナレッジ等を利用できる。これにより、開発経験の比較的浅い開発者であっても、熟練者のナレッジ、ノウハウ等を利用できる。尚、上述したように、関連ＱＦＤデータ表示部１６における品質特性が選択された場合に、選択された品質特性に対応する検討項目を表示するようにしてもよい。

以上、説明したように、本実施形態に係る設計支援システムでは、ＱＦＤ手法に係る要求品質及び部品を端末１０の画面上で開発者が適宜選択することで、その要求品質及び部品の組み合わせに対応する品質特性が特定され、さらに、その品質特性に対応する検討項目が表示されるようになる。この検討項目は、製品開発に対して検討すべき技術的事項である。そして、この検討項目には、熟練者のナレッジが関連付けられている。このため、開発経験の比較的浅い開発者であっても、検討項目やナレッジ等に沿って製品開発を行うことで、品質の高い製品開発が可能となる。

（第２実施形態）
続いて、本発明の第２実施形態について図１６から図２１を参照して説明する。

図１６は、上述した選択画面の他の一例である。

本実施形態に係る設計支援システムは、図１６に示すように、選択画面における要求品質と部品との組み合わせの特定が変更された場合に、その変更に応じて、上述した検討項目表示画面の出力結果を変えると共に、変更点が開発者に理解され易いように表示させるものである。同図によれば、開発者は、部品「下ケース裏面」でなく「アンテナ」により、要求品質「アンテナが適度な力で保持できる」を充足したいと考えている。

図１７は、品質特性抽出部１１４の動作の他の一例を示すフローチャートである。変更に伴う変更点等の表示は、品質特性抽出部１１４により機能する。

品質特性抽出部１１４は、選択画面内における要求品質と部品との組み合わせの特定が変更されたことを検出すると（ステップＳ７１）、検討項目ＤＢ１２５に対して変更後の組み合わせに対応する検討項目を探索する（ステップＳ７２）。

品質特性抽出部１１４は、ここで、対応する検討項目が存在すると判定した場合には（ステップＳ７３）、その検討項目に対応する品質特性を品質特性ＤＢ１２３から抽出する（ステップＳ７４）。具体的には、図１８に示すように、第１マトリクスにおいて、要求品質を同一としたまま部品が変更された場合、その要求品質と変更後の部品との組み合わせに対応する検討項目（例えば検討項目Ｅ）が第３マトリクス上で探索される。そして、検討項目が存在する場合には、その検討項目に対応する第２マトリクス上の品質特性（例えば品質特性Ｆ、Ｇ）が抽出される。尚、対応する検討項目が存在しない場合には、処理を終了する。終了に代えて、処理を中止したりや停止したりしてもよい。

品質特性抽出部１１４は、次いで、部品ツリー画面を表示すると共に、検討項目表示画面を表示する（ステップＳ７５）。部品ツリー画面では、図１９に示すように、変更後の部品名が他の部品名と表示色を変えて表示される。部品名の大きさを変えるようにしてもよい。また、検討項目表示画面の関連ＱＦＤデータ表示部１６では、図２０に示すように、要求品質、抽出された品質特性等を表示し、検討項目表示部１７には、探索された検討項目と、これに関連付けられた部品名が表示される。

品質特性抽出部１１４は、次いで、変更点検証画面を表示する（ステップＳ７６）。この表示と併せて、変更点と変更理由を変更履歴としてＤＢサーバ１２０に構成される不図示の履歴管理ＤＢに登録するようにしてもよい。変更点検証画面は、図２１に示すように、仕様変更後の部品名と仕様変更前の部品名とが対比して表示され、さらに、これらの部品名に関連付けられた品質特性及び検討項目が表示される。

このように、要求品質を同一にしたまま部品を変更した場合に、品質機能展開に基づいて、変化点の一元管理を可能としつつ、変更の影響が追跡可能となるので、開発者は、変更点検証画面を介して、変更に伴うＱＦＤデータの影響範囲を明確に理解することができる。尚、本実施形態では、要求品質を同一にしたまま部品を変更するようにしたが、部品を同一にしたまま要求品質を変更するようにしてもよいし、画面構成（レイアウト）を変更し、品質特性を変更できるようにしてもよい。

（第３実施形態）
続いて、本発明の第３実施形態について説明する。

本実施形態に係る設計支援システムは、審議会、検討会等のデザインレビューで必要となる審議資料等を管理しておき、この資料のすべてが揃わない限り、デザインレビューが始められないように制限をかけるものである。これにより、デザインレビューを開催する際に、検討項目に対する検討漏れ及びレビュー時の確認漏れを防止することが可能となる。

図２２は、本実施形態に係るサーバ１１０の要部構成を例示する他の機能ブロック図である。尚、図２に示されるサーバ１１０の各部と同様の構成には同一符号を付し、その説明を省略する。

サーバ１１０は、同図に示すように、検討実績管理部１１７、検討実績承認部１１８、イベント実施・指摘事項管理部１１９Ａ、イベント実施結果承認部１１９Ｂをさらに含んで構成される。尚、検討実績管理部１１７及び検討実績承認部１１８等から本発明の第１の登録手段及び第１の包含手段が構成され、イベント実施・指摘事項管理部１１９Ａ及びイベント実施結果承認部１１９Ｂ等から第２の登録手段及び第２の包含手段が構成される。

検討実績管理部１１７は、検討項目に対して行われた検討結果を管理する。具体的には、引き合い、要件定義から設計、検証、製造までの一連の工程に対し、それぞれの工程において検討された事項を検討結果として検討実績管理ＤＢ１２７に登録する。これにより、検討された内容が各工程で共有されると共に、有効活用が促進される。尚、検討結果が複数ある場合には、各々について管理する。

検討実績承認部１１８は、検討実績管理ＤＢ１２７に登録された検討実績に対し承認、否認を行う。複数ある場合には、各々について承認等を行う。この検討実績承認部１１８は、端末１０からの要求に応じて稼動するが、承認権限を有する者が操作する端末１０からの要求でないと稼動しない。承認権限を有する者であるか否かについては、承認権限を有する者のユーザＩＤに承認権限に関する識別フラグ等を関連付け、ログイン時等に判定すればよい。

イベント実施・指摘事項管理部１１９Ａは、デザインレビューが行われた際に、デザインレビューが行われた日時やその際に使用された議事録、指摘された事項等をイベント実施・指摘事項管理ＤＢ１２８に登録する。

イベント実施結果承認部１１９Ｂは、端末１０からの要求に基づいて、イベントに対する承認や否決を行う。この承認、否決等についても上述した承認権限を有する者が操作する端末１０からの要求に基づいて行われる。

続いて、本実施形態に係る設計支援システムの動作について説明する。

まず、検討実績管理部１１７及び検討実績承認部１１８の動作について図２５から図２７等を参照して説明する。

図２５から図２７は、検討実績管理部及び検討実績承認部の動作の一例を示すフローチャートである。図２５から図２７に示すフローチャートも、一連のフローチャートとなっている。

検討実績管理部１１７は、端末１０から登録済の開発機種を表示する旨の要求を受け付けると、その端末１０に登録済の開発機種一覧を表示する（ステップＳ８１）。これにより、開発者は、開発を予定する開発機種の登録・未登録を理解できる。未登録である場合には、適宜、開発機種を登録すればよい。

検討実績管理部１１７は、ここで、開発機種の選択がなされたか否かを判定する（ステップＳ８２）。開発機種の選択は、開発者が画面上に表示された開発機種の一を選択・指示することで行われる。端末１０は画面上の指示等を検出すると、これを検討実績管理部１１７に送信する。選択・指示が行われた場合には、検討実績管理部１１７は、その開発機種の表示を反転させる。

検討実績管理部１１７は、さらに、検討項目の検討を行うか否かを判定する（ステップＳ８３）。当該判定は、例えば、検討項目を行うか否かのポップアップ画面等を表示して、開発者に選択させるようにすればよい。

検討実績管理部１１７は、ステップＳ８３の処理において、検討項目の検討を行うと判定した場合には、開発機種を構成する部品を表示した部品ツリー画面を表示する（ステップＳ８４）。部品ツリー画面としては、既に説明した図１４に示すようなものが該当する。

検討実績管理部１１７は、ここで、部品ツリー画面内に表示された部品の一が選択されたか否かを判定し（ステップＳ８５）、部品が選択されたと判定した場合には、図２４に示すように、部品に関連付けられた検討項目を一覧表示する（ステップＳ８６）。

検討実績管理部１１７は、ここで、検討項目が未承認であるものに対し、検討結果を登録するか否かを選択させる（ステップＳ８７）。すなわち、検討項目の一覧を表示した場合に、その検討項目が承認されたか未承認であるか開発者は画面上で確認することができる。そして、未承認である検討項目に対しては、検討結果を承認してもらうべく、検討結果の登録要求を行う。

検討実績管理部１１７は、検討結果の登録要求を受信した場合には、検討結果の登録処理を行う（ステップＳ８８）。具体的には、対象となる検討項目と関連付けて検討項目ＤＢ１２５に登録する。そして、検討項目の承認依頼を受信した場合には（ステップＳ８９）、登録された検討項目に対し、承認依頼中である旨を示す識別フラグを付す（ステップＳ９０）。これにより、承認依頼中でない他の検討項目と区別できる。尚、未承認である場合には、識別フラグは付さないようにすればよい。

検討実績承認部１１８は、承認依頼中の検討結果に対して、端末１０から承認の可否を行う旨の要求を受信したか否かを判定する（ステップＳ９１）。この端末１０は、承認権限を有する者が操作する端末である。

検討実績承認部１１８は、検討結果に対し承認を行う旨の要求を受信した場合には、承認依頼中の識別フラグをこれと異なる承認済フラグを付し、検討結果を承認済とする（ステップＳ９２）。一方、検討結果に対し否認を行う旨の要求を受信した場合には、承認依頼中の識別フラグをこれと異なる否認フラグを付し、検討結果を否認とする（ステップＳ９３）。

検討実績管理部１１７は、検討項目の検討を終了しない旨の要求、すなわち、検討項目の検討を継続する旨の要求を端末１０から受信した場合には、ステップＳ８７の処理に戻る（ステップＳ９４）。これにより、承認依頼を行った検討結果とは別の検討結果に対しても、承認依頼が可能となる。

ここで、上述したステップＳ８３の処理において、検討実績管理部１１７は、検討項目と検討を行わない旨の要求を端末１０から受信した場合には、図２６に示すように、イベント開催に必要な準備物の登録を行うか否か選択させる（ステップＳ９５）。

検討実績管理部１１７は、ステップＳ９５の処理において、準備物の登録を行う旨の要求を端末１０から受信した場合には、選択された開発プロセスの雛形に定義付けされているイベントの一覧をイベントの実施順に表示する（ステップＳ９６）。具体的には、図２３に示すように、イベント一覧表示部１８に、「企画審査会」、「設計審査会」等と、実施する順序に従って、開発プロセスの雛形に定義付けられたイベントを表示する。

検討実績管理部１１７は、表示されたイベントの一が選択されたと判定した場合には（ステップＳ９７）、そのイベントに関連付けられた準備物の一覧を表示する（ステップＳ９８）。具体的には、図２３に示すように、イベント一覧表示部１８に表示されたイベント「設計審査会」を選択・指示すると、その下の審議対象書類一覧表示部１９に、この「設計審査会」に必要な準備物としての「提案書」や「必要データ」等が表示される。これにより、開発者は、選択したイベントに対する必要書類を確認できる。

検討実績管理部１１７は、ここで、準備物として不足するものが存在する旨の要求を端末１０から受信した場合（ステップＳ９９）、準備物の登録画面等を端末１０に表示し、開発者に準備物の登録を促し、端末１０から準備物の登録要求を受信した場合に、準備物の登録処理を行う（ステップＳ１００）。

検討実績管理部１１７は、さらに、準備物の登録を終了する旨の要求を受信しなかった場合（ステップＳ１０１）、ステップＳ９８の処理に戻る。これにより、開発者は、デザインレビューまでに必要となる準備物の登録を過不足無く行うことができる。

また、上述したステップＳ８７の処理において、検討実績管理部１１７が未承認の検討結果が存在しないと判定した場合や、ステップＳ９８の処理において、準備物の未登録が存在しないと判定した場合には、図２７に移り、検討実績管理部１１７は、必要な検討項目がすべて承認され（ステップＳ１０２）、かつ、準備物のすべてが登録されているか否かを判定する（ステップＳ１０３）。

検討実績管理部１１７は、ステップＳ１００の処理において、要件が満たされていると判定した場合には、次のイベントを開催するか否かについて端末１０に表示し（ステップＳ１０４）、開発者に判断を要求する。

検討実績管理部１１７は、次のイベントを開催する旨の要求を受信した場合には、イベントの開催可能である旨の通知を各端末１０に行う（ステップＳ１０５）。一方、次のイベントを開催する旨の要求を受信しなかった場合には、設計検討を終了するか否かの判定を開発者に画面上で求め、終了する旨の要求を受信した場合には、処理を終了する（ステップＳ１０６）。

このように、開発者に提示された検討項目に対し、開発者は検討結果を設計支援システムに登録することができ、この検討結果に対しては、承認権限を有する者が承認したり、否認したりすることができる。したがって、デザインレビュー等のイベントが実施されるまでに、検討項目に対し、検討されていない項目が存在してしまうという事態を回避することができる。また、不足する書類がある場合には、適宜、登録することもできる。

続いて、イベントの実施及びイベントの承認について説明する。

図２８は、イベント実施・指摘事項管理部１１９Ａの動作の一例を示すフローチャートである。

イベント実施・指摘事項管理部１１９Ａは、端末１０からの要求に基づいて、イベントが実施可能な開発機種の一覧を端末１０に表示する（ステップＳ１０７）。これにより、開発者は、イベントの実施を予定する開発機種を確認できる。

イベント実施・指摘事項管理部１１９Ａは、ここで、一の開発機種が選択されたか否かを判定する（ステップＳ１０８）。当該判定は、端末１０の画面上で一の開発機種が選択され、その旨の指示を受信した場合に、選択されたと判定する。

イベント実施・指摘事項管理部１１９Ａは、上記指示を受信した場合には、開発プロセスに定義付けされているイベントの一覧をイベントの実施順に表示する（ステップＳ１０９）。この表示は、すでに説明したように、図２３に示すように行われる。

イベント実施・指摘事項管理部１１９Ａは、表示されたイベントの一が選択されたと判定した場合には（ステップＳ１１０）、そのイベントに関連付けられた準備物の一覧を表示する（ステップＳ１１１）。この表示も、すでに説明したように、図２３に示すように行われる。

イベント実施・指摘事項管理部１１９Ａは、ここで、イベントを実施する旨の要求を端末１０から受信したか否かについて判定し（ステップＳ１１２）、さらに、イベントの準備物に対し、準備物の内容の未確認と、確認結果の未登録が存在するか否かについて判定する（ステップＳ１１３）。

イベント実施・指摘事項管理部１１９Ａは、ステップＳ１１２の処理において、イベントを実施する旨の要求を受信したと判定し、ステップＳ１１３の処理において、準備物の内容の未確認と、確認結果の未登録が存在すると判定した場合には、さらに、実施するイベントの準備物の行が選択されたか否かを判定する（ステップＳ１１４）。

イベント実施・指摘事項管理部１１９Ａは、イベントの準備物の行が選択されたと判定した場合には、開発機種で登録された準備物の一覧と準備物に対する確認項目を一覧表示し（ステップＳ１１５）、端末１０からの選択に応じて、実際に登録を行った準備物を表示する（ステップＳ１１６）。

図２９に移り、イベント実施・指摘事項管理部１１９Ａは、ステップＳ１１６で選択された準備物に対し、未登録の準備物が存在する旨を受信したと判定した場合には（ステップＳ１１７）、さらに、準備物は承認可能であるか否かを端末１０の画面に表示し（ステップＳ１１８）、開発者に選択を促す。

イベント実施・指摘事項管理部１１９Ａは、ここで、端末１０から承認可能である旨を受信した場合には、確認結果の承認処理を行い（ステップＳ１１９）、承認不可能である旨を受信した場合には、確認結果に否認処理を行う（ステップＳ１２０）。そして、ステップＳ１１９、Ｓ１２０の処理を終了した後、ステップＳ１１７の処理に戻る。これにより、確認結果が未承認のままとなる状態を回避できる。

一方、イベント実施・指摘事項管理部１１９Ａは、ステップＳ１１１の処理において、準備物のないよう未確認及び確認結果の未登録がないと判定した場合には、図３０に移り、イベントの議事録登録要求があったか否かを判定する（ステップＳ１２１）。

イベント実施・指摘事項管理部１１９Ａは、イベントの議事録登録要求があったと判定した場合には、イベントの議事録を登録する（ステップＳ１２２）。さらに、イベントの結果を登録する旨を受信した場合であって（ステップＳ１２３）、イベントのすべての準備物に対する確認結果がすべて承認されているときに（ステップＳ１２４）、イベントの可決処理を行い（ステップＳ１２５）、まだ、承認されていない確認結果があるときには、イベントの否決処理を行う（ステップＳ１２６）。

このように、イベントに対する準備物がすべて揃い、その内容の確認結果に登録されていないものが存在しない場合には、イベントの議事録が登録されることを条件に、イベントの可決、否決が行われる。これにより、イベントの承認依頼を行うことができる。

図３１から図３３は、イベント承認部１１９Ｂの動作の一例を示すフローチャートである。

イベント承認部１１９Ｂは、端末１０からイベントの承認が可能な開発機種の一覧を表示させる旨を受信すると、開発機種の一覧を表示する（ステップＳ１３１）。この端末１０は、イベントに対する承認権限を有する者が操作する端末である。

イベント承認部１１９Ｂは、端末１０から開発機種が選択されたと判定した場合には（ステップＳ１３２）、選択された開発機種に対するイベントの一覧をイベントの実施順に表示する（ステップＳ１３３）。

イベント承認部１１９Ｂは、ここで、表示されたイベントの一が選択されたか否かを判定し（ステップＳ１３４）、表示されたイベントの一が選択されたと判定した場合には、イベントの実施結果を表示し（ステップＳ１３５）、併せて、承認するイベントの準備物の一覧を表示する（ステップＳ１３６）。これにより、開発者は選択されたイベントの可決や否決、準備物の一覧を確認できる。

イベント承認部１１９Ｂは、ここで、イベント実施結果の承認を続行するか否かを判定する（ステップＳ１３７）。当該判定は、端末からイベント実施結果の続行を承認又は否認する旨を受信することによって行われ、イベント実施結果の承認を続行する旨を受信した場合には、さらに、準備物の確認結果の確認を続行するか否かを判定する（ステップＳ１３８）。

イベント承認部１１９Ｂは、ステップＳ１３８の処理において、準備物の確認結果の確認を続行すると判定した場合には、次いで、実施結果を承認するイベントの準備物が選択されたか否かを判定し（ステップＳ１３９）、選択されたと判定した場合には、準備物の一覧及びその準備物に対する確認項目の一覧を表示する（ステップＳ１４０）。さらに、イベントの準備物として、開発機種で実際に登録を行った準備物を表示する（ステップＳ１４１）。これにより、準備物に対する確認結果を確認できる。

一方、イベント承認部１１９Ｂは、ステップＳ１３８の処理において、準備物の確認結果の確認を続行しないと判定した場合には、図３２に移り、承認するイベントの議事録は登録されているか否かを判定する（ステップＳ１４２）。

イベント承認部１１９Ｂは、ここで、イベントの議事録が登録されていないと判定した場合には、イベントの議事録を登録するか否かを開発者に画面上で選択させ（ステップＳ１４３）、議事録を登録する旨を受信した場合には、議事録の登録処理を行う（ステップＳ１４４）。これにより、議事録の登録漏れが回避される。

イベント承認部１１９Ｂは、ステップＳ１４２で議事録が登録されていると判定した後や、ステップＳ１４４で議事録の登録処理が行われた後に、議事録の確認要求を受信した場合（ステップＳ１４５）、議事録の内容を表示する（ステップＳ１４６）。これにより、イベントの実施結果を承認又は否認しようとする者は、議事録の内容を確認できる。

イベント承認部１１９Ｂは、イベントの実施結果に対し、承認又は否認する旨を受信した場合には（ステップＳ１４７）、イベントの実施結果について承認または否認する処理を行い（ステップＳ１４８）、さらに、図３３に移り、準備物と確認結果に対してロック処理を行う（ステップＳ１４９）。このロック処理は、例えばロックされていることを示すロックフラグ等を付加すればよい。これにより、実施結果承認後の準備物及び確認結果に対しては、変更が不可能となり、データの整合性がとれなくなることが回避されるとともに、イベントの実施結果を履歴（証拠）として、改ざんされることなく正しく保管することができる。

イベント承認部１１９Ｂは、イベントの実施結果が承認であると判定した場合には（ステップＳ１５０）、さらに、そのイベントが選択された開発プロセスにおける最後のイベントであるか否かを判定し（ステップＳ１５１）、最後のイベントであると判定した場合には、開発を完了させるべく（ステップＳ１５２）、イベント承認処理を終了する。最後のイベントでない場合には、次のイベントに向けた開発フェーズに進行させる（ステップＳ１５３）。

一方、イベント承認部１１９Ｂは、ステップＳ１５０の処理において、イベントの実施結果が否認であると判定した場合には、再実施用のイベントの追加を要求し（ステップＳ１５４）、否認となった実施結果の内容を複製しつつ（ステップＳ１５５）、次のイベントに向けた開発フェーズに進行させる（ステップＳ１５６）。

このように、本実施形態に係る設計支援システムによれば、設計の企画を発表等する審査会等のイベントに対する承認が行われることによって、イベントデータに対し承認が行われた旨の識別フラグが付され、次のイベントに移行することができる。すなわち、開発者は、設計支援システムから提示された各検討項目に対し、検討結果を順次登録していき承認を得ることで、イベントを行うことができる。さらに、必要な検討結果が揃いすべて承認された上で、イベントに対する承認を得ることで、次のイベントを行うことができる。これを繰り返していくことで、一連のイベントが実施され、品質機能展開に基づいて、変化点の一元管理を可能としながら、品質の高い製品・部品等の完成が可能となる。

以上、本発明は、上述した第１実施形態から第３実施形態に限定されるものではなく、その要旨を逸脱しない範囲内で種々変形して実施することが可能である。例えば、本発明のプログラムを通信手段により提供することはもちろん、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することも可能である。

また、上述した実施形態では、設計支援システムの対象として携帯電話を一例として用いて説明したが、携帯電話に限られず、自動車、産業機械、電車、船舶、家電機器、ソフトウェア開発等、種々の製品、部品に適用できる。

熟練者や開発経験の比較的浅い開発者の区別、検討結果やイベントに対する承認権限を有する者とそうでない者は、ユーザＩＤごとに識別フラグ等を付しておけばよい。これにより、ログイン時に本システムを利用する者が熟練者か否か判定できる。また、イベントの承認は、承認、否認の二択に限定されず、承認の度合いに応じて行うようにしてもよい。

さらに、上述した第１実施形態から第３実施形態とは異なる第４実施形態について説明する。

（第４実施形態）
以下に、本発明の第４実施形態について説明する。

本実施形態に係る設計支援システムは、上述した開発機種に係る要求品質と部品との組合せに関する組合せデータを、他の機種に係る組合せデータと対比可能にしたものである。

これにより、開発機種に係る組合せデータに近い、既に設計や開発等が完了した別の機種に係る組合せデータを取得できれば、取得したその別の機種に係る組合せデータに関連付けられた検討項目やナレッジ、ノウハウ、不具合情報等を利用できる。特に、これらのナレッジ等に熟練者特有の技術が含まれていれば、設計等の経験が比較的浅い設計者・開発者であっても、これらのナレッジ等を利用して作業時間の短縮や作業量の低減が図れる。

尚、上述した対比は、開発機種の組合せデータと開発機種以外の機種の組合せデータとの対比に限らず、（１）開発機種の組合せデータとその開発機種の主な部分を構成する機種の組合せデータ（マスターの組合せデータ）との対比、（２）開発機種の組合せデータとその開発機種の組合せデータの過去の組合せデータとの対比、であってもよい。

以下に、これらの内容を実現する手段について図面を参照して詳述する。

図３４は、第４実施形態に係るサーバ１１０の要部構成を例示する他の機能ブロック図、図３５は、第４実施形態に係るＤＢサーバ１２０の要部構成を例示する他の機能ブロック図である。尚、図２に示されるサーバ１１０及び図３に示されるＤＢサーバ１２０の各部と同様の構成には同一符号を付し、その説明を省略する。

サーバ１１０は、図３４に示すように、変化点抽出部１１９Ｃをさらに含んで構成される。また、ＤＢサーバ１２０は、図３５に示すように、開発履歴ＤＢ１２８をさらに含んで構成される。尚、変化点抽出部１１９Ｃ等から本発明の変化点抽出手段や機種データ送信手段が構成される。

開発履歴ＤＢ１２８は、開発機種に係る組合せデータの取得以前に既に選択され、及び／又は、登録された、すべての機種に係る組合せデータを記憶する。例えば、図８や図１２を参照して説明した、要求品質と品質特性、品質特性と部品、要求品質と部品、の関連付けに関する情報を記憶する。この記憶は、機種ごとであれば望ましく、さらには、組合せデータの更新ごと、イベントごと、レビューごと、検討期限ごと等、時系列に沿っていることが望ましい。

変化点抽出部１１９Ｃは、端末１０から送信された開発機種に係る組合せデータを取得すると共に、開発履歴ＤＢ１２８から、開発機種と異なる機種に係る組合せデータを取得する。そして、開発機種に係る組合せデータを基準に、開発機種と異なる機種に係る組合せデータとそれぞれ比較し、比較結果に係る類似度の高い機種に係る組合せデータに関連付いた、開発機種データを抽出する。また、その他の例として、開発機種と同一の機種、又は、開発機種の基（マスター）となる機種の組合せデータを取得するようにしてもよい。尚、類似度とは、組合せデータ同士の各マス目の重複度合いをいう。

続いて、第４実施形態に係る設計支援システムの動作について説明する。

まず、開発機種と対比する機種の検索処理について図３６から図３８を参照して説明する。

図３６は、変化点抽出部１１９Ｃの動作の一例を示すフローチャート、図３７は、開発機種とその開発機種と異なる機種との対比を示す概念図、図３８は、変化点抽出部１１９Ｃの処理結果を表す画面の一例である。

変化点抽出部１１９Ｃは、図３６に示すように、まず、開発機種に係る要求品質データと部品データとの組合せデータを取得する（ステップＳ２０１）。この取得処理は、図１１を参照して説明したように、開発者や設計者によって選択画面におけるマトリクスの各マス目が選択され、完了ボタンが押下されると、変化点抽出部１１９Ｃが、選択された各マス目に対応する、要求品質データと部品データとの組合せデータを取得することで行われる。

変化点抽出部１１９Ｃは、次いで、開発機種を除くすべての開発機種データを比較対象として取得する（ステップＳ２０２）。開発機種データは、開発機種ＤＢ１２６に記憶されているため、変化点抽出部１１９Ｃは、この開発機種ＤＢに記憶されたすべての開発機種データを取得する。

変化点抽出部１１９Ｃは、次いで、開発機種に係る組合せデータに存在し、比較対象に係る機種の組合せデータに存在しない組合せデータの数を計数する（ステップＳ２０３）。

図３７を参照して具体的に説明すると、開発機種「機種Ｂ」に係る組合せデータには、例えば、要求品質データ「１．アンテナが適度な力で保持できる」と、部品データ「４．アンテナ」と、のマス目に丸印が付与されている。したがって、この組合せは、開発者等によって選択されたことを表す。

一方、ＤＢサーバ１２０（より詳細には開発履歴ＤＢ１２８）に記憶された開発機種「機種Ｃ」に係る組合せデータには、要求品質データ「１．アンテナが適度な力で保持できる」と、部品データ「４．アンテナ」と、のマス目に丸印が付与されていない。したがって、この組合せは、開発者等によって選択されなかったことを表す。

この結果、要求品質データ「１．アンテナが適度な力で保持できる」と、部品データ「４．アンテナ」と、のマス目に関して、計数処理が行われる。このように、開発機種に係る組合せデータに基づいて、対比する機種に係る組合せデータのマス目の不一致を計数する。尚、開発機種「機種Ｂ」と、この開発機種を基礎として対比される機種「機種Ｃ」は、ほぼすべて不一致であり、開発機種との類似度が低いことになる。

変化点抽出部１１９Ｃは、次いで、比較対象に係る組合せデータに存在し、開発対象に係る機種の組合せデータに存在しない組合せデータの数を計数する（ステップＳ２０４）。この計数処理は、ステップＳ２０３の処理を逆にしたものである。すなわち、比較対象に係る機種「機種Ｃ」の組合せデータの中で、丸印が付与されているが、開発対象に係る機種「機種Ｂ」の組合せデータの中で、丸印が付与されていないマス目を計数する。

変換点抽出部１１９Ｃは、次いで、ステップＳ２０３によって計数された計数結果と、ステップＳ２０４によって計数された計数結果と、の和を算出し、保持する（ステップＳ２０５）。したがって、この算出結果が開発機種「機種Ｂ」と対比機種「機種Ｃ」との類似度を判定するための値となる。

変化点抽出部１１９Ｃは、ここで、すべての機種に対して処理を終了したか否かを判定する（ステップＳ２０６）。すなわち、変化点抽出部１１９Ｃは、ステップＳ２０２で取得したすべての機種（例えば、「機種Ａ」や「機種Ｆ」等）に対し、ステップＳ２０３〜Ｓ２０５の処理を行う。この結果、開発機種と、開発機種以外の機種との類似度を判定するための値がすべて算出される。

変化点抽出部１１９Ｃは、ステップＳ２０６の処理において、すべての値が算出されると、これらの値を基に、開発機種データを昇順に並び替える（ステップＳ２０７）。この結果、上述した和が最大となった対比機種（例えば「機種Ｃ」）は類似度が低い機種であるとして下位に、最小となった対比機種（例えば「機種Ａ」）は類似度が高い機種であるとして上位に並び替えられる。

変化点抽出部１１９Ｃは、次いで、並び替えられた開発機種データを端末１０に表示する（ステップＳ２０８）。この結果、図３８に示すように、開発者は、開発機種「機種Ｂ」に最も類似する機種は「機種Ａ（ＭＯＤＥＬ＿Ａ）」であることを、逆に、開発機種「機種Ｂ」に類似しない機種は「機種Ｃ（ＭＯＤＥＬ＿Ｃ）」等であることを、認識できる。

次に、開発機種と対比する機種の比較処理について図３９から図４１を参照して説明する。

図３９は、変化点抽出部１１９Ｃの動作の他の一例を示すフローチャート、図４０は、開発機種と選択された機種との対比を説明するための図、図４１は、変化点抽出部１１９Ｃの処理結果を表す画面の他の一例である。

変化点抽出部１１９Ｃは、図３９に示すように、まず、機種の選択があったか否かを判定する（ステップＳ２１１）。この判定処理は、図３８に示す画面上で、一又は複数の機種が選択され、完了ボタンが押下されたか否かによって行われる。これにより、開発機種と対比する機種が特定される。

変化点抽出部１１９Ｃは、ステップＳ２１１の処理において、機種の選択があったと判定した場合には、開発機種に係る組合せデータを取得する（ステップＳ２１２）。開発機種に係る組合せデータの取得は、既に取得した組合せデータを利用してもよい。

変化点抽出部１１９Ｃは、次いで、選択された機種に係る組合せデータを取得する（ステップＳ２１３）。例えば、図３８では、機種Ａが選択されているため、機種「機種Ａ」に係る組み合わせデータを取得する。

変化点抽出部１１９Ｃは、次いで、開発機種に係る組合せデータに存在し、選択された機種に係る組合せデータに存在しない組合せデータを取得する（ステップＳ２１４）。

図４０を参照して具体的に説明すると、同図（ａ）に示すように、開発機種「機種Ｂ」に係る組合せデータは、要求品質「３．コネクタが容易に挿抜できる」に対し、部品「２．下ケース裏面」及び「１０．サイドキー（シーソー型）」が選択されている。また、要求品質「６．電池パックが脱落しない」に対し、部品「１０．サイドキー（シーソー型）」が選択されている。

一方、同図（ｂ）に示すように、開発機種「機種Ａ」に係る組合せデータは、要求品質「３．コネクタが容易に挿抜できる」に対し、部品「２．下ケース裏面」及び「５．サイドキー（プッシュ型）」が選択されている。また、要求品質「６．電池パックが脱落しない」に対し、部品「４．アンテナ」が選択されている。

このため変化点抽出部１１９Ｃは、同図（ａ）の破線で示すように、機種「機種Ａ」に存在しない、要求品質「３．コネクタが容易に挿抜できる」、部品「１０．サイドキー（シーソー型）」の組合せデータ、及び、要求品質「６．電池パックが脱落しない」、部品「１０．サイドキー（シーソー型）」の組合せデータを取得する。

変化点抽出部１１９Ｃは、ステップＳ２１４の処理を完了すると、次いで、選択された機種に係る組合せデータに存在し、開発機種に係る組合せデータに存在しない組合せデータを取得する（ステップＳ２１５）。

すなわち、図４０を参照して説明すると、変化点抽出部１１９Ｃは、同図（ｂ）の破線で示すように、機種「機種Ｂ」に存在しない、要求品質「３．コネクタが容易に挿抜できる」、部品「５．サイドキー（プッシュ型）」の組合せデータ、及び、要求品質「６．電池パックが脱落しない」、部品「４．アンテナ」の組合せデータを取得する。

変化点抽出部１１９Ｃは、ステップＳ２１５の処理を完了すると、次いで、取得された双方の組合せデータに対応するマトリクスのセルを強調表示する（ステップＳ２１６）。

この結果、図４１に示すように、機種「機種Ａ」に対し、開発機種「機種Ｂ」で新たに選択された組合せ、及び、選択されなかった組合せが強調して表示される。尚、同図においては、選択された組合せ、選択されなかった組合せの双方に同じ色を用いて強調表示しているが、選択された組合せの色と、選択されなかった組合せの色と、を分けるようにしてもよい。さらに、選択された組合せの印を二重丸、選択されなかった組合せの印をバツ印等と、印を変えるようにしてもよい。このように、開発者は、開発機種と、その開発機種に類似する機種との対比が可能となり、さらには、これらの組合せに関連付いた検討項目やナレッジ、不具合事例等も知ることができる。

尚、第４実施形態では、開発機種と、その開発機種と異なる機種との類似の度合いに基づいて、双方の組合せデータが比較できるようにしたが、図４２に示すように、開発機種と同一機種（例えば「機種Ｂ」）であって、その同一機種の過去の組合せデータをＤＢサーバ１２０（より詳細には開発履歴ＤＢ１２８）に記憶させておき、これらの組合せデータを比較するようにしてもよい。これにより、開発が行われている現在の開発機種の組み合わせと、過去の組合せとを比較でき、どのような変遷を辿って現在の組合せに至ったか、また、現在の開発機種の組合せが、過去に検討されていなかったかどうかを開発者は知ることができる。特に、過去に既に検討されていた場合には、重複作業が回避される。

また、第４実施形態では、開発機種と、その開発機種と異なる機種、同一機種との対比を説明したが、開発機種と、その開発機種の組合せデータの基となる組合せデータ（マスターデータ）と、の比較を行うようにしてもよい。このマスターデータは、図４３から図４５に示される。

図４３は、要求品質、品質特性及び部品に関するマスターデータの一例、図４４は、要求品質と品質特性、品質特性と部品、とを関連付ける関連付けに関するマスターデータの一例、図４５は、検討項目に関するマスターデータの一例である。

図４３から図４５に示すように、これらは相互に関連付いている。例えば、図４４（ａ）に示す要求品質ＩＤ「２」と品質特性ＩＤ「１０４」は関連付いているため、図４３（ａ）に示す、要求品質ＩＤ「２」に応じた「キーがスムースに操作できる」と、この内容に対応する、同図（ｂ）に示す品質特性ＩＤ「１０４」に応じた「キーボタンの引っ掛かりなきこと」とが関連付く。

さらに、図４４（ｂ）に示す要求品質ＩＤ「２」と部品ＩＤ「５」は関連付いているため、図４３（ｃ）に示す、要求品質ＩＤ「５」に応じた「サイドキー（プッシュ型）」とが関連付く。そして、図４５に示す品質特性ＩＤ「１０４」、部品ＩＤ「５」に応じた、検討項目ＩＤ「Ｋ１３４」とその検討項目「キーパッド浮きを防止する・・・」が関連付く。

例えば、開発機種に係る組合せデータと、その開発機種以外の機種に係る組合せデータとの類似度がほぼ全機種で高い場合、このマスターデータを変更することが好ましい場合もある。このような場合、開発者は、開発機種に係る組合せデータと、開発機種以外の機種に係る組合せデータとが一致する部分であって、マスターデータだけが不一致となる部分について、適宜、修正することができる。特に、マスターデータを修正することで、開発機種の開発後、再度、そのマスターデータを利用する場合、すべての機種で共通する組合せデータに関し、修正されたマスターデータを利用できる。

さらに、第４実施形態では、要求品質と部品との組合せについて説明したが、要求品質と品質特性、又は、品質特性と部品との組合せであってもよい。

さらに、第４実施形態では、最も類似度が高い機種を選択し、比較処理を行うようにしたが、そのような機種以外の機種を選択し、比較処理を行うようにしてもよい。例えば、特定の要求品質や部品等を部分的に比較したい場合に有益である。

なお、上記第１〜第４実施形態において、「熟練者」と言った場合、必ずしも、実年齢が高い人や、会社における入社年次が古い人や、能力が高いとの社内評価を受けている人といった、いわゆる「ベテラン」や「実力者」と呼ばれる人々を指すことが意図されているわけではなく、対象領域の広狭や技術的難度／深度にかかわらず、対象となる工程・作業・判断について何らかの経験・ノウハウを持っている人であればあらゆる人が含まれ得る。

設計支援システムの構成図である。 本発明の第１実施形態に係るサーバの要部構成を例示する機能ブロック図である。 本発明の第１実施形態に係るＤＢサーバの要部構成を例示する機能ブロック図である。 本発明の第１実施形態に係る開発プロセス定義データ管理部の動作の一例を示すフローチャートである。 本発明の第１実施形態に係るイベントデータ等の登録過程を説明する図である。 本発明の第１実施形態に係るＱＦＤ・検討項目定義データ管理部の動作の一例を示すフローチャートである。 本発明の第１実施形態に係るＱＦＤ・検討項目定義データ管理部の動作の一例を示すフローチャートである。 本発明の第１実施形態に係る登録処理により得られるＱＦＤデータの一例である。 本発明の第１実施形態に係る開発機種管理部の動作の一例を示すフローチャートである。 本発明の第１実施形態に係る品質特性抽出部の動作の一例を示すフローチャートである。 本発明の第１実施形態に係る要求品質と部品との組み合わせを選択する選択画面の一例である。 本発明の第１実施形態に係る要求品質、品質特性及び部品によって構成される三元表マトリクスの一例である。 本発明の第１実施形態に係る検討項目抽出部の動作の一例を示すフローチャートである。 本発明の第１実施形態に係る部品ツリー画面の一例である。 本発明の第１実施形態に係る検討項目表示画面の一例である。 本発明の第２実施形態に係る選択画面の一例である。 本発明の第２実施形態に係る品質特性抽出部の動作の一例を示すフローチャートである。 本発明の第２実施形態に係る三元表マトリクスの一例である。 本発明の第２実施形態に係る部品ツリー画面の一例である。 本発明の第２実施形態に係る検討項目表示画面の一例である。 本発明の第２実施形態に係る変化点検証画面の一例である。 本発明の第３実施形態に係るサーバ１１０の要部構成を例示する機能ブロック図である。 本発明の第３実施形態に係るイベント等表示画面の一例である。 本発明の第３実施形態に係る開発支援承認画面の一例である。 本発明の第３実施形態に係る検討実績管理部及び検討実績承認部の動作の一例を示すフローチャートである。 本発明の第３実施形態に係る検討実績管理部及び検討実績承認部の動作の一例を示すフローチャートである。 本発明の第３実施形態に係る検討実績管理部及び検討実績承認部の動作の一例を示すフローチャートである。 本発明の第３実施形態に係るイベント実施・指摘事項管理部の動作の一例を示すフローチャートである。 本発明の第３実施形態に係るイベント実施・指摘事項管理部の動作の一例を示すフローチャートである。 本発明の第３実施形態に係るイベント実施・指摘事項管理部の動作の一例を示すフローチャートである。 本発明の第３実施形態に係るイベント承認部の動作の一例を示すフローチャートである。 本発明の第３実施形態に係るイベント承認部の動作の一例を示すフローチャートである。 本発明の第３実施形態に係るイベント承認部の動作の一例を示すフローチャートである。 本発明の第４実施形態に係るサーバの要部構成を例示する他の機能ブロック図である。 本発明の第４実施形態に係るＤＢサーバの要部構成を例示する他の機能ブロック図である。 本発明の第４実施形態に係る変化点抽出部の動作の一例を示すフローチャートである。 開発機種とその開発機種と異なる機種との対比を示す概念図である。 本発明の第４実施形態に係る変化点抽出部の処理結果を表す画面の一例である。 本発明の第４実施形態に係る変化点抽出部の動作の他の一例を示すフローチャートである。 開発機種と選択された機種との対比を説明するための図である。 本発明の第４実施形態に係る変化点抽出部の処理結果を表す画面の他の一例である。 開発機種とその開発機種と同一機種との対比を示す概念図である。 要求品質、品質特性及び部品に関するマスターデータの一例である。 要求品質と品質特性、品質特性と部品、とを関連付ける関連付けに関するマスターデータの一例である。 検討項目に関するマスターデータの一例である。

符号の説明

１０ 端末
４０ ネットワーク
１１０ アプリケーションサーバ
１１１ 開発プロセス定義データ管理部
１１２ ＱＦＤ・検討項目定義データ管理部
１１３ 開発機種管理部
１１４ 品質特性抽出部
１１５ 検討項目抽出部
１１６ 制御部
１１７ 検討実績管理部
１１８ 検討実績承認部
１１９Ａ イベント実施・指摘事項管理部
１１９Ｂ イベント実施結果承認部
１１９Ｃ 変化点抽出部
１２０ ＤＢサーバ
１２１ 開発プロセス定義データＤＢ
１２２ 要求品質ＤＢ
１２３ 品質特性ＤＢ
１２４ 部品ＤＢ
１２５ 検討項目ＤＢ
１２６ 開発機種ＤＢ
１２７ 制御部
１２８ 開発履歴ＤＢ

Claims (19)

1. 製品の開発に係る設計を支援する設計支援システムであって、
   ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを表示し、ユーザにより選択された組合せデータを送信する端末と、
   前記端末から送信された前記組合せデータを受信し、該組合せデータに基づき、記憶手段に記憶された前記設計に対して検討すべき項目に関する検討項目データを抽出する抽出手段と、
   前記抽出手段で抽出された前記検討項目データを前記端末に送信し、ユーザに提供する提供手段と、
   を有することを特徴とする設計支援システム。
2. 前記抽出手段は、前記組合せデータに基づいて、前記製品の品質を担保するための品質特性に係る品質特性データを抽出し、該品質特性データに関連付けられた前記検討項目データを抽出することを特徴とする請求項１に記載の設計支援システム。
3. 前記抽出手段は、前記検討項目データに関連付けられて記憶手段に記憶された熟練者のナレッジ、レビュー期限、及び／又は、製品に係る過去のトラブルに関する付加データも併せて抽出し、
   前記提供手段は、前記抽出手段で抽出された前記付加データを前記端末に送信し、前記ユーザに提供することを特徴とする請求項１又は２に記載の設計支援システム。
4. 前記抽出手段は、前記品質特性データに、顧客別の品質特性、及び／又は、仕向地別の品質特性に関する顧客別等品質特性データが含まれる場合に、抽出された品質特性データを顧客別等品質特性データに置換し、該顧客別等品質特性データに関連付けられた検討項目データを抽出することを特徴とする請求項１から３のいずれか１項に記載の設計支援システム。
5. 前記提供手段は、前記検討項目データを送信し、ユーザに提供した後に、ユーザにより選択された組合せデータに対し、選択の変化が発生した場合に、変化前後に係る組合せデータに関連付けられた検討項目データを対比して前記ユーザに提供することを特徴とする請求１から４のいずれか１項に記載の設計支援システム。
6. 前記検討項目データに対し、検討結果に関する検討結果データをユーザからの指示に基づいて前記記憶手段に登録する第１の登録手段と、
   前記記憶手段に登録された検討結果データに対し、承認の度合いに応じたデータを包含する第１の包含手段と、をさらに含み、
   前記第１の登録手段は、前記検討結果データに対して承認度の高いデータが包含されたと判定した場合に、所定の情報をユーザに通知することを特徴とする請求項１から５のいずれか１項に記載の設計支援システム。
7. 前記検討会に対する検討会結果に関する検討会結果データを前記端末からの指示に基づいて前記記憶手段に登録する第２の登録手段と、
   前記記憶手段に登録された検討会結果データに対し、検討結果を判定する判定データを包含する第２の包含手段と、をさらに含み、
   前記第２の登録手段は、前記検討会結果データに対して正の判定データが包含される度に、開発プロセスにおけるイベントデータを段階的に移行していくことを特徴とする請求項６に記載の設計支援システム。
8. 製品の開発に係る設計を支援する設計支援装置であって、
   ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを受信し、該組合せデータに基づき、記憶手段に記憶された前記設計に対して検討すべき項目に関する検討項目データを抽出する抽出手段と、
   前記抽出手段で抽出された前記検討項目データ送信する送信手段と、
   を有することを特徴とする設計支援装置。
9. 製品の開発に係る設計を支援する設計支援プログラムであって、
   コンピュータによって実行されたときに、当該コンピュータを、
   ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを受信し、該組合せデータに基づき、記憶手段に記憶された前記設計に対して検討すべき項目に関する検討項目データを抽出する抽出手段、
   前記抽出手段で抽出された前記検討項目データ送信する送信手段、
   として機能させることを特徴とする設計支援プログラム。
10. 請求項９に記載した設計支援プログラムを記録したコンピュータ読取可能な記録媒体。
11. 製品の開発に係る設計を支援する設計支援システムであって、
    ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する第１の組合せデータを表示し、ユーザにより選択された第１の組合せデータを送信する端末と、
    前記端末から送信された第１の組合せデータを取得すると共に、該第１の組合せデータの取得以前に既に選択され、又は、登録された、第２の組合せデータを記憶した記憶手段から、すべての前記第２の組合せデータを取得し、前記第１の組合せデータを基準に、前記すべての第２の組合せデータとそれぞれ比較し、比較結果に係る類似度の高い第２の組合せデータに関連付いた開発機種に関する機種データを抽出する変化点抽出手段と、
    前記変化点抽出手段で抽出された前記機種データを昇順に並び替えて前記端末に送信し、ユーザに提供する提供手段と、
    を有することを特徴とする設計支援システム。
12. 前記変化点抽出手段は、前記記憶手段から、前記第１の組合せデータに関連付いた開発機種と異なる機種となる第２の組合せデータを取得することを特徴とする請求項１１に記載の設計支援システム。
13. 前記変化点抽出手段は、前記記憶手段から、前記第１の組合せデータに関連付いた開発機種の基となる第２の組合せデータを取得することを特徴とする請求項１１に記載の設計支援システム。
14. 前記変化点抽出手段は、前記記憶手段から、前記第１の組合せデータに関連付いた開発機種と同一の機種となる第２の組合せデータを時系列に取得することを特徴とする請求項１１に記載の設計支援システム。
15. 前記変化点手段は、前記第１の組合せデータからそれぞれの前記第２の組合せデータを差し引いた第１の差引データの数と、それぞれの前記第２組合せデータから前記第１組合せデータを差し引いた第２の差引データの数と、の和が、より小さくなる第２の組合せデータを類似度が高いと判断することを特徴とする請求項１１から１４のいずれか１項に記載の設計支援システム。
16. 前記提供手段は、前記第２の組合せデータと相違する前記第１の組合せデータの部分を強調して提供することを特徴とする請求項１１から１５のいずれか１項に記載の設計支援システム。
17. 製品の開発に係る設計を支援する設計支援装置であって、
    ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを取得すると共に、該第１の組合せデータの取得以前に既に選択され、又は、登録された、第２の組合せデータを記憶した記憶手段から、すべての前記第２の組合せデータを取得し、前記第１の組合せデータを基準に、前記すべての第２の組合せデータとそれぞれ比較し、比較結果に係る類似度の高い第２の組合せデータに関連付いた開発機種に関する機種データを抽出する変化点抽出手段と、
    前記変化点抽出手段で抽出された前記機種データを昇順に並び替えて前記端末に送信する機種データ送信手段と、
    を有することを特徴とする設計支援装置。
18. 製品の開発に係る設計を支援する設計支援プログラムであって、
    コンピュータによって実行されたときに、当該コンピュータを、
    ＱＦＤ手法で利用される要求品質と、該要求品質を実現する際に利用する部品と、の組合せに関する組合せデータを取得すると共に、該第１の組合せデータの取得以前に既に選択され、又は、登録された、第２の組合せデータを記憶した記憶手段から、すべての前記第２の組合せデータを取得し、前記第１の組合せデータを基準に、前記すべての第２の組合せデータとそれぞれ比較し、比較結果に係る類似度の高い第２の組合せデータに関連付いた開発機種に関する機種データを抽出する変化点抽出手段、
    前記変化点抽出手段で抽出された前記機種データを昇順に並び替えて前記端末に送信する機種データ送信手段、
    として機能させることを特徴とする設計支援プログラム。
19. 請求項１８に記載した設計支援プログラムを記録したコンピュータ読取可能な記録媒体。

Images