JP2007109073A - 製品開発プロセス支援システム及び製品開発プロセス支援方法 - Google Patents

Abstract

【課題】 複雑な製品を開発する過程における無駄な繰り返し作業を容易に低減する
【解決手段】 製品開発プロセス支援システム１０は、複数の階層の何れかに属する、製品開発プロセスにおける複数の要件間の依存関係を分析するシステムであって、それぞれ隣接した階層に属する２つの要件間の依存関係を示す情報、及び要件の製品開発に対する影響度を示す情報の入力を受け付ける入力受付部１２と、同一の階層に属する任意の２つの要件間の依存関係を、入力受付部１２により受け付けられた当該２つの要件とそれ以外の要件との依存関係を示す情報及び当該２つの要件の影響度を示す情報から、予め設定された依存関係導出ルールに基づいて導出する依存関係導出部１３とを備える。
【選択図】 図１

Description

本発明は、複数の階層の何れかに属する、製品開発プロセスにおける複数の要件間の依存関係を分析する製品開発プロセス支援システム、及び製品開発プロセス支援方法に関する。

製品開発プロセスにおいて、マーケティング上の上位の開発要件（顧客要求、システム要件）を、製品の各設計項目の要件にブレークダウンしていく手法として、品質機能展開（ＱＦＤ：Quality Function Deployment）手法がある。例えば、自動車やデジタル複写機等の工業製品の開発において、上位の開発要件を達成するために製品が多くのモジュールや部品に展開される。ＱＦＤ手法では、上下の要件間（上位の開発要件とモジュールや部品の設計項目の要件との間）の依存関係が整理され、この整理に基づき各モジュールや部品の設計項目の要件の内容が決定される。この決定に基づいて、各モジュールや部品の設計が、設計項目毎に多くの設計担当者や検証担当者により行われる。

一方、展開されたモジュールや部品の設計項目間の関連を整理するための手法としてＤＳＭ（Design Structure Matrix）手法がある。ＤＳＭ手法によれば、モジュールや部品の設計項目（の設計担当者や検証担当者）間で、どのように連携（コラボレーション）をとっていくべきか把握することができる（例えば、下記特許文献１参照）。
特開２００４−２８０２４９号公報

ＱＦＤ手法において、上位の要件が妥当に展開され、個々の設計にリスクが全くなければ、設計上の問題は発生しない。しかし、一般的には上位要件の展開に矛盾があったり、各設計項目の要素がリスクを持っていたりして、ブレークダウンされた要件を何れかのモジュールや部品が達成できなくなるというケースは頻繁に起こる。

この場合、要件が達成できないモジュールや部品の要件を、他のモジュールや他の部品の設計と調整して、目標達成できるように見直しや設計修正を行うことが必要となる。このように、ＱＦＤ手法による場合、一旦設計した内容を自要因及び他要因によって、設計をやり直す等の無駄な繰り返し作業が頻繁に発生するおそれがある。

これを回避するには、展開された各モジュールや部品の設計項目（の設計担当者や検証担当者）で円滑な作業連携が必要となる。しかしながら、ＱＦＤ手法では、上下の要件間の依存関係を把握することができても、展開された各モジュールや部品の設計項目の要件間の関連を把握するのが困難である。

一方、上述したＤＳＭ手法では、展開された各モジュールや部品の設計項目の要件間の関連を整理することができるが、要件間の総当りの依存関係を記述する必要がある。要件間の総当りの依存関係を一旦記述することができれば、必要な連携を把握し、無駄な繰り返し作業を回避することが可能になる。しかしながら、要件間の総当りの依存関係を記述するのは、複雑な製品であればあるほど非常に困難であり、現実的にこれを行うことは難しい。

本発明は、以上の問題点を解決するためになされたものであり、複雑な製品を開発する過程における無駄な繰り返し作業を、容易に低減することができる製品開発プロセス支援システム及び製品開発プロセス支援方法を提供することを目的とする。

本発明に係る製品開発プロセス支援システムは、複数の階層の何れかに属する、製品開発プロセスにおける複数の要件間の依存関係を分析する製品開発プロセス支援システムであって、それぞれ隣接した階層に属する２つの要件間の依存関係を示す情報、及び要件の製品開発に対する影響度を示す情報の入力を受け付ける入力受付手段と、同一の階層に属する任意の２つの要件間の依存関係を、入力受付手段により受け付けられた当該２つの要件とそれ以外の要件との依存関係を示す情報及び当該２つの要件の影響度を示す情報から、予め設定された依存関係導出ルールに基づいて導出する依存関係導出手段と、を備えることを特徴とする。ここで、階層とは、システム要件、モジュール機能要件等の、製品開発プロセスにおける具体性のレベルを示すものである。また、要件とは、各レベルにおける達成すべき仕様のことである。

本発明に係る製品開発プロセス支援システムでは、容易に入力することができる、入力とする隣接した階層に属する２つの要件間の依存関係を示す情報と要件の製品開発に対する影響度を示す情報とから、同一の階層に属する任意の２つの要件間の依存関係を導出することができる。従って、容易に入力できる情報から、同一の階層に属する任意の２つの要件間の依存関係を導出することができる。ユーザは、この依存関係を参照して、無駄な繰り返し作業を防止することができる製品開発プロセスにおける要件に関しての決定を行うことができる。これにより、複雑な製品を開発する過程における無駄な繰り返し作業を、容易に低減することができる。

製品開発プロセス支援システムは、依存関係導出手段により導出された依存関係から、予め設定された分析ルールに基づいて、製品開発プロセスにおける同一の階層に属する要件の優先順位を決定すると共に、当該要件をパーティション分けする分析手段を更に備えることが望ましい。この構成によれば、無駄な繰り返し作業を防止するという点で、望ましい順序及び区分で製品開発プロセスにおける要件に関しての決定を行うことができる。

入力受付手段は、ＱＦＤ表の形式での依存関係を示す情報の入力を受け付け、依存関係導出手段は、ＤＳＭ表に従って、依存関係を導出する、ことが望ましい。ここで、ＱＦＤ表及びＤＳＭ表とは、それぞれＱＦＤ手法及びＤＳＭ手法の分析で用いられるマトリックスを含む表である。この構成によれば、ＱＦＤ手法やＤＳＭ手法の分析手法を適用することができ、より確実に本発明を実施することができる。

ところで、本発明は、上記のように製品開発プロセス支援システムの発明として記述できる他に、以下のように製品開発プロセス支援方法の発明としても記述することができる。これらはカテゴリが異なるだけで、実質的に同一の発明であり、同様の作用及び効果を奏する。

本発明に係る製品開発プロセス支援方法は、複数の階層の何れかに属する、製品開発プロセスにおける複数の要件間の依存関係を分析する製品開発プロセス支援方法であって、それぞれ隣接した階層に属する２つの要件間の依存関係を示す情報、及び要件の製品開発に対する影響度を示す情報の入力を受け付ける入力受付ステップと、同一の階層に属する任意の２つの要件間の依存関係を、入力受付ステップにおいて受け付けられた当該２つの要件とそれ以外の要件との依存関係を示す情報及び当該２つの要件の影響度を示す情報から、予め設定された依存関係導出ルールに基づいて導出する依存関係導出ステップと、を有することを特徴とする。

本発明によれば、容易に入力できる情報から、同一の階層に属する任意の２つの要件間の依存関係を導出することができる。ユーザは、この依存関係を参照して、無駄な繰り返し作業を防止することができる製品開発プロセスにおける要件に関しての決定を行うことができる。これにより、複雑な製品を開発する過程における無駄な繰り返し作業を、容易に低減することができる。

以下、図面とともに本発明に係る製品開発プロセス支援システム及び製品開発プロセス支援方法の好適な実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

図１に本実施形態に係る製品開発プロセス支援システム１０を示す。製品開発プロセス支援システム１０は、製品開発プロセスにおける複数の要件間の依存関係を分析して、製品開発プロセスの支援を行うシステムである。ここでいう製品開発プロセスとは、マーケティング上の上位の開発要件（顧客要求、システム要件）から開発対象の製品のモジュールの機能要件を決定して、当該決定されたモジュールの機能から設計要素を決定するという一連のプロセスである。図２に示すように、このように製品開発プロセスは、「システム要件」「モジュール機能要件」「モジュール設計要素」といった複数の階層に分かれており、個別の各要件は何れかの階層に属している。また、「モジュール機能要件」の階層の要件は、「システム要件」の階層の要件をブレークダウンしたもの、「モジュール設計要素」の階層の要件は、「モジュール機能要件」の階層の要件をブレークダウンしたものにそれぞれなっており、階層間には隣接する関係がある。

具体的には例えば、プリンタの開発プロセスにおいては、上記の要件は以下のようになる。「システム要件」の階層の要件は、「プリント品質がよい」「プリントが早い」といったものが相当する。より具体的には例えば、「プリント品質がよい」という要件は、プリンタのユーザからプリント品質に関してのどの位の満足度を得ようとするかの目標仕様である。「モジュール機能要件」の階層の要件は、例えばモジュール毎に定義され、具体的にはプリント部分のモジュールに対して「ウォームアップ時間」「定着性」といったものが相当する。より具体的には例えば、「ウォームアップ時間」という要件は、そのモジュールが暖機運転に要する時間の目標仕様である。「モジュール設計要素」の階層の要件は、「ヒートローラ部のヒータ」「加圧部の加圧ローラ」といったものが相当する。より具体的には例えば、「ヒータ」という要件は、ヒータが具体的にどの様な寸法や材質であればよいという目標仕様である。

製品開発プロセス支援システム１０は、製品開発プロセスにおける複数の要件間の依存関係を分析するものである。より具体的には、隣接した２つの階層に属する２つの要件間の依存関係を示す情報、及び要件の製品開発に対する影響度を示す情報を入力として、同一の階層に属する任意の２つの要件間の依存関係を導出するものである。

製品開発プロセス支援システム１０は、ワークステーションやＰＣ（Personal Computer）等から構成されており、ＣＰＵ（CentralProcessing Unit）やメモリ等のハードウェアを備える。製品開発プロセス支援システム１０における処理は、製品開発プロセス支援システム１０による情報処理たる製品開発プロセス支援方法が実行されることにより行われる。製品開発プロセス支援システム１０では、上記のハードウェアがプログラム等により動作することにより、製品開発プロセス支援システム１０の、後述する機能が発揮されて上記の情報処理が実行される。なお、本実施形態では、製品開発プロセス支援システム１０は一つの装置で実現されているが、製品開発プロセス支援システム１０の各機能を分散した複数の情報処理装置がネットワークにより互いに接続されて構成される情報処理システムにより実現されていてもよい。

図１に示すように、製品開発プロセス支援システム１０は、入出力インターフェース１１と、入力受付部１２と、依存関係導出部１３と、分析部１４とを備える。入出力インターフェース１１は、入力インターフェースと出力インターフェースとからなっている。入力インターフェースは、キーボード等から構成され、製品開発プロセス支援システム１０において演算処理に用いられるデータを入力するためにユーザに用いられるものである。出力インターフェースは、モニタ等から構成され、製品開発プロセス支援システム１０の出力をユーザに参照させるために、出力の表示等を行うものである。

入力受付部１２は、入出力インターフェース１１により入力された情報の入力を受け付ける入力受付手段である。入力受付部１２により受け付けられる情報は、製品開発プロセスにおける、それぞれ隣接した階層に属する２つの要件間の依存関係を示す情報、及び要件の製品開発に対する影響度を示す情報である。より具体的には後述する。入力受付部１２により受け付けられた情報は、依存関係導出部１３に送信される。

依存関係導出部１３は、同一の階層に属する２つの要件間の依存関係を導出する依存関係導出手段である。依存関係の導出は、入力受付部１２により受け付けられた隣接した階層に属する２つの要件間の依存関係を示す情報、及び要件の製品開発に対する影響度を示す情報を用いて行われる。また、依存関係の導出は、予め設定された依存関係導出ルールに基づいて行われる。この依存関係導出ルールは、依存関係導出部１３に予め記憶されている。依存関係の導出については、より具体的に後述する。導出された依存関係を示す情報は、分析部１４に送信される。

分析部１４は、依存関係導出部１３により導出された依存関係を分析する分析手段である。この分析には、同一の階層に属する要件の優先順位を決定して、当該要件を区分することを含む。分析部１４による分析については、より具体的に後述する。分析部１４による分析の結果は、入出力インターフェース１１に送信される。

引き続いて、図３のフローチャートを用いて本実施形態に係る製品開発プロセス支援方法（製品開発プロセス支援システム１０において実行される処理）を説明する。まず、図２の範囲２１で示すモジュールの機能要件及びモジュール設計要素の階層の各要件の依存関係（２階層の要件の依存関係）を分析するものを説明する。その後、図２の範囲２２で示す製品開発プロセス全体の各要件の依存関係（３階層の要件の依存関係）を分析するものを説明する。

以下、図３のフローチャートに従って、図２の範囲２１で示すモジュール機能要件の階層及びモジュール設計要素の階層の各要件の依存関係を分析するものを説明する。まず、製品開発プロセス支援システム１０では、ユーザが入出力インターフェース１１を用いて入力した情報が、入力受付部１２により受け付けられる（Ｓ０１、入力受付ステップ）。ユーザにより入力される情報は、モジュール機能要件とモジュール設計要素との間の依存関係を示す情報、及びそれらの要件の製品開発に対する影響度を示す情報である。入力は、図４に示すようなＱＦＤ表の形式のフォームに従って行われる。このフォームに関する情報は、予め製品開発プロセス支援システム１０に記憶されており、入出力インターフェース１１に表示される。また、各要件の項目に関する情報（項目名等）の入力を受け付けて、それらの入力された情報からフォームの情報を生成することとしてもよい。

図４に示すように、ＱＦＤ表の形式のフォームは、縦方向にモジュール機能要件の各項目が記載されている（範囲３１、各行データに対応している）。また、横方向にモジュール設計要素の各項目が記載されている（範囲３２、各列データに対応している）。ＱＦＤ表のマトリックス３３には、各モジュール機能要件と各モジュール設計要素の依存関係を示す情報を入力できるようになっている。なお、図４に示すＱＦＤ表は、既に依存関係を示す情報が入力されたものになっており、入力前のＱＦＤ表は全て空欄である。

ここで依存関係を示す情報は、モジュール機能要件の達成に対してモジュール設計要素が影響する度合を示す情報であり、具体的には数値で表現される。依存関係の度合を示す数値は、例えば図４に示すように“９”、“６”、“３”、“なし”の４つの値を入力することができ、数値が大きいほど強い依存関係であることを示している。各数値は図５の表で示す意味合いを有している。

図４のＱＦＤ表における、範囲３４，３５の欄は、それぞれ対応するモジュール機能要件の製品開発に対する個々の影響度を示す情報を入力できるようになっている。具体的には、個々の影響度を示す情報としては、機能重要度（範囲３４の欄に対応）と、未達リスク（範囲３５の欄に対応）とがある。機能重要度及び未達リスクは、図４に示すように１〜５までの５段階（５が最も強い）の数値として入力される。機能重要度は、そのモジュール機能要件が満たせない場合の商品企画（商品の魅力）に与えるインパクトを示したものである。未達リスクは、そのモジュール機能要件が設計構想で実現できない（無調整で実現できない）可能性を示したものである。これら２つの製品開発に対する個々の影響度を示す情報から求められる影響度として優先度がある。優先度は、以下の式により計算され、０〜１までの数値をとる（１が最も強い）。
優先度＝機能重要度・未達リスク／２５
この計算は、入力受付部１２において、機能重要度及び未達リスクが入力された後行われる。図４において、優先度は範囲３６の欄の数値に対応する。以降の演算では、各システム要件の製品開発に対する影響度として、この優先度の数値も用いられる。

図４のＱＦＤ表における、範囲３７，３８の欄は、それぞれ対応するモジュール設計要素の製品開発に対する個々の影響度を示す情報を入力できるようになっている。具体的には、個々の影響度を示す情報としては、要素リスク（範囲３７の欄に対応）と、変更自由度（範囲３８の欄に対応）とがある。要素リスク及び変更自由度は、図４に示すように１〜５までの５段階（５が最も強い）の数値として入力される。要素リスクは、そのモジュール設計要素が、従来設計からどの程度新規に設計されているかの評価を示したものである。変更自由度は、現状の設計案から、どの程度の設計としての選択肢があるかの評価を示したものである。例えば、そのモジュール設計要素が共通部品なので変更ができない場合は、変更自由度は低くなる。また、そのモジュール設計要素が部品として他に選択肢がない場合は、変更自由度は低くなる。これら２つの製品開発に対する個々の影響度を示す情報から求められる影響度として調整度がある。調整度は、以下の式により計算され、０〜１までの数値をとる（１が最も強い）。
調整度＝要素リスク・変更自由度／２５
この計算は、入力受付部１２において、要素リスク及び変更自由度が入力された後行われる。図４において、調整度は範囲３９の欄の数値に対応する。以降の演算では、各モジュール機能要件の製品開発に対する影響度として、この調整度の数値も用いられる。

入力受付ステップでは、モジュール機能要件とモジュール設計要素との間の依存関係を示す情報が、図４における範囲３３のマトリックスにユーザにより入力された数値として、入力受付部１２に受け付けられる。また、それらの要件の製品開発に対する影響度を示す情報が図４における範囲３４，３５，３７，３８の欄にユーザにより入力された数値として、入力受付部１２に受け付けられる。これら受け付けられた情報は、依存関係導出部１３に送信される。また、上記計算された各影響度を示す情報も依存関係導出部１３に送信される。

続いて、依存関係導出部１３が、入力受付部１２により受け付けられた依存関係を示す情報、及び入力受付部１２により受け付けられて計算された各影響度を示す情報から、２つのモジュール機能要件間及び２つのモジュール設計要素間の依存関係を導出する（Ｓ０２、依存関係導出ステップ）。この関係の導出は、ＤＳＭ表に従って行われる。依存関係導出部１３は、ＤＳＭ表の形式で、演算したデータを保持する。具体的には、以下に示す依存関係導出ルールに基づいて行われる。

ＤＳＭ表とは、図６に示すような表であり、表の行と列とに同じ要素を並べてそれらの双方向の依存関係を記述したものである（図６では、本処理で既に導出されたＤＳＭ表における依存関係の数値が入力されている）。ＤＳＭ表の行データに着目した場合、その行の要素は、他のどの要素に（どの程度）依存しているかが記述されていることになる。また、ＤＳＭ表の列データに着目した場合、その列の要素は、他のどの要素が（どの程度）依存しているかが記述されていることになる。本実施形態の場合、全てのモジュール機能要件の項目と、全てのモジュール設計要素の項目とがＤＳＭ表における行及び列の各要素に対応している。図６では、モジュール機能要件の項目は、範囲４１（列データ）及び範囲４２（行データ）に相当する。また、モジュール設計要素の項目は、範囲４３（列データ）及び範囲４４（行データ）に相当する。

マトリックス４５〜４８は、依存関係導出部１３により導出された各項目間の依存関係が格納される。図６に示すように、マトリックス４５には、モジュール設計要素に対するモジュール設計要素（モジュール設計要素→モジュール設計要素）の依存関係の度合を示す数値が格納される。マトリックス４６には、モジュール機能要件に対するモジュール設計要素（モジュール設計要素→モジュール機能要件）の依存関係の度合を示す数値が格納される。マトリックス４７には、モジュール機能要件に対するモジュール機能要件（モジュール機能要件→モジュール機能要件）の依存関係の度合を示す数値が格納される。マトリックス４８には、モジュール設計要素に対するモジュール機能要件（モジュール機能要件→モジュール設計要素）の依存関係の度合を示す数値が格納される。以下、各マトリックス４５〜４８に格納される依存関係の内容、及び導出方法について説明する。

マトリックス４５に数値が格納される、モジュール設計要素に対するモジュール設計要素の依存関係は、図７に示すように、同じモジュール機能要件に影響を与える関係であり、各モジュール設計要素が他のモジュール設計要素の設計条件をどの程度考慮しながら設計すべきか示すものである。モジュール設計要素ａのモジュール設計要素ｂに対する（ａ→ｂ）依存関係の度合を示す数値は、Ｓ０１において受け付けられたＱＦＤ表の情報を用いて導出される。具体的には、ＱＦＤ表のうち、モジュール設計要素ａとモジュール設計要素ｂとの、各モジュール機能要件を介した依存関係について以下の式を用いた計算をそれぞれ行い、そのうちの最大値を当該依存関係の度合を示す数値とする。
（依存関係の算出式）
＜モジュール設計要素ａ及びモジュール設計要素ｂのモジュール機能要件Ａに対する依存関係の数値が共に１以上の場合＞
＝（モジュール設計要素ａの要素リスク）／５・（モジュール設計要素ａとモジュール機能要件Ａとの間の依存関係）・（モジュール機能要件Ａの優先度）・（モジュール設計要素ｂの自由度）／５
※数値は小数点を切り捨てたものとする。

上記の式は、下記の現象を式に表したものである。（ｉ）モジュール機能要件の達成度に対して、強い影響を与えるモジュール設計要素（要素リスクが高く、ＱＦＤ上の依存関係が強いもの）ほど、他のモジュール設計要素の前提とする（依存関係における依存元となる）。（ｉｉ）モジュール設計要素の自由度が高いほど、同じモジュール機能要件に影響を与える他のモジュール設計要素を考慮できる。（ｉｉｉ）依存関係は、優先度の高いモジュール機能要件を介して発生する。

マトリックス４６に数値が格納される、モジュール機能要件に対するモジュール設計要素の依存関係は、図８に示すように、モジュール設計要素によってモジュール機能要件の達成度が影響を受ける関係である。モジュール設計要素ａのモジュール機能要件Ａに対する（ａ→Ａ）依存関係の度合を示す数値は、Ｓ０１において受け付けられたＱＦＤ表の情報を用いて導出される。具体的には、ＱＦＤ表のモジュール設計要素ａとモジュール機能要件Ａとの間の依存関係の数値を、モジュール設計要素ａの要素リスクを考慮した依存関係の数値に変換する。具体的には、以下の式に従って算出される。
（依存関係の算出式）
＝（モジュール設計要素ａとモジュール機能要件Ａとの間の依存関係）・（モジュール設計要素ａの要素リスク）／５
※数値は小数点を切り捨てたものとする。

上記の式は、下記の現象を式に表したものである。（ｉ）モジュール機能要件の達成度において留意すべきモジュール設計要素とは、強い影響を受けているモジュール設計要素であり、また、モジュール設計要素の要素リスクが高いものほど留意すべきである。

マトリックス４７に数値が格納される、モジュール機能要件に対するモジュール機能要件の依存関係は、図９に示すように、同じモジュール設計要件から影響を受ける関係である。このような依存関係にある、モジュール機能要件間は、互いのモジュール機能要件の達成度を確認しながら製品開発を進めていく必要があり、この依存関係の度合は、モジュール機能要件の確認を進める際に、他のモジュール機能要件の達成状況をどの程度考慮すべきか示すものである。モジュール機能要件Ａのモジュール機能要件Ｂに対する（Ａ→Ｂ）依存関係の度合を示す数値は、Ｓ０１において受け付けられたＱＦＤ表の情報を用いて導出される。具体的には、ＱＦＤ表のうち、モジュール機能要件Ａ及びモジュール機能要件Ｂに対する、各モジュール設計要件を介した依存関係について以下の式を用いた計算をそれぞれ行い、そのうちの最大値を当該依存関係の度合を示す数値とする。
（依存関係の算出式）
＝（モジュール機能要件Ａの優先度）・（モジュール設計要素ａとモジュール機能要件Ａとの間の依存関係）・（モジュール設計要素ａの調整度）・（モジュール設計要素ａとモジュール機能要件Ｂとの間の依存関係）／９
※数値は小数点を切り捨てたものとする。

上記の式は、下記の現象を式に表したものである。（ｉ）モジュール機能要件の優先度が高いほど（機能重要度が高く、未達リスクが高いほど）、未達成によって影響を受けているモジュール設計要素への修正がより多く発生する。（ｉｉ）モジュール機能要件の未達成でモジュール設計要素への修正が発生する場合、強い依存関係を受けているモジュール設計要素のうち調整度の高いモジュール設計要素への修正がより多く発生する。（ｉｉｉ）修正を行ったモジュール設計要素に強い影響を受けている他のモジュール機能要件ほど、その修正による影響をより強く受けることになるので、留意が必要である。

マトリックス４８に数値が格納される、モジュール設計要素に対するモジュール機能要件の依存関係は、図１０に示すように、モジュール機能要件の達成状況がモジュール設計要素の修正等の影響を与える関係であり、モジュール機能要件の確認結果から影響を受けるモジュール設計要素の設計条件の変更にどの程度繋がるかを示している。モジュール設計要素の設計条件は、影響を与えるモジュール機能要件の達成状況によっては、修正が必要になる。モジュール機能要件Ａのモジュール設計要素ａに対する（Ａ→ａ）依存関係の度合を示す数値は、Ｓ０１において受け付けられたＱＦＤ表の情報を用いて導出される。具体的には、ＱＦＤ表のモジュール設計要素ａとモジュール機能要件Ａとの間の依存関係の数値に基づいて、モジュール機能要件Ａが満たせずモジュール設計要素ａの再調整に戻らなければならない度合の数値を算出する。具体的には、以下の式に従って算出される。
（依存関係の算出式）
＝（モジュール機能要件Ａの優先度）・（モジュール設計要素ａとモジュール機能要件Ａとの間の依存関係）・（モジュール設計要素ａの調整度）
※数値は小数点を切り捨てたものとする。

上記の式は、下記の現象を式に表したものである。（ｉ）モジュール機能要件の優先度が高いほど（機能重要度が高く、未達リスクが高いほど）、モジュール機能要件の未達成によって影響を受けるモジュール設計要素への修正がより多く発生する。（ｉｉ）モジュール機能要件の未達成で、モジュール設計要素への修正が発生する場合、強い依存関係を受けているモジュール設計要素で調整度の高いモジュール設計要素への修正がより多く発生する。

上記のように、依存関係導出部１３により各依存関係の数値が導出されると、図６に示した（数値が入った）マトリックス４５〜４８が得られる。得られた依存関係の数値は、分析部１４に出力される。なお、上記の数値の導出は代表例であり、優先度や調整度の扱いは、場合に応じて修正して実施されることもある。

続いて、分析部１４が、依存関係導出部１３により、ＤＳＭ表に従って導出された依存関係から、製品開発プロセスにおけるモジュール機能要件及びモジュール設計要素の考慮すべき優先順位を決定すると共に、モジュール機能要件及びモジュール設計要素をパーティション分けする（Ｓ０３、分析ステップ）。これらの処理は、以下に示すような、予め設定された分析ルールに従って行われる。分析ルールは、予め分析部１４に記憶されている。

要件の各要素の優先順位の決定（要素の順番の並び替え）と、パーティション分けとは、ＤＳＭ手法における公知の分析手法（パーティション（Partition）分析）に基づいて行われることとしてよい。ＤＳＭ表に順序の概念を持ち込んだ場合、順序として先のもの（より依存元になっているもの）、行としては上方向、列としては左方向になる。

優先順位の決定（要素の順番の並び替え）と、パーティション分けとは、以下のように行われる。ＤＳＭ表の行例の順序を変更するが、ＤＳＭ表を構成している各要素や各要素間の依存関係は変更しない。ＤＳＭ表のパーティション分析は、要素間の依存関係のループをなるべく小さいまとまり（ループチェイン又はブロックという）に押さえ込むためにＤＳＭ表の行列順序を並べかえる。この並べ替えは、結果的に、分析対象の要素間の依存関係を整理し、どの要素を他の要素の前提とすべきかを整理し、ループ（＝やりなおし）を最小化する要素の順序を導くものとなる。以下、パーティション分析の一例を説明する。この分析方法は、例えば、「Systems Analysis and Management（STRUCTURE, STRATEGY AND DESIGN）」（Donald V.Steward著）等にも記載されている公知な方法である。

説明を分かりやすくするため、図１１に示すサンプルのＤＳＭ表を用いる。図１１に示すように、サンプルのＤＳＭ表は、要素の数が１０のものである。以降、図１２のフローチャートを用いてパーティション分析を説明する。

まず、分析部１４は、以下のパーティション分析で用いる、依存関係のしきい値を初期化（ｓ＝１）する（Ｓ１１）。しきい値ｓは、分析部１４にデータとして記憶される。続いて、分析部１４は、順位が確定又は仮決定していない要素があるか否かを判断する（Ｓ１２）。ここでは、確定又は仮決定した要素は一つも無いので、そのような要素があると判断される。

そのように判断された場合、分析部１４は、順位未決定の要素すべてに依存元及び依存先があるか否かを判断する（Ｓ１３）。ここで、判断に係る依存関係は、しきい値以上の数値を有しているもののみに限られる。ここでは、“要素１”と“要素９”とが、依存元及び依存先の両方を有しておらず、すべてに依存元及び依存先がないと判断される。そのように判断された場合、分析部１４は、依存元のない要素があるか否かを判断する（Ｓ１４）。ここでは、“要素１”の依存元がないので、依存元のない要素があると判断される。なお、ここで依存元がないということは、ＤＳＭ表では行方向に依存関係がないことである。

そのように判断された場合、分析部１４は、依存元のない要素（ここでは“要素１”）を最上位に移動させる（Ｓ１５）。続いて、分析部１４は、依存先のない要素があるか否かを判断する（Ｓ１６）。ここでは、“要素９”の依存先がないので、依存先のない要素があると判断される。なお、ここで依存先がないということは、ＤＳＭ表では列方向に依存関係がないことである。そのように判断された場合、分析部１４は、依存先のない要素（ここでは“要素９”）を最下位に移動させる（Ｓ１７）。

続いて、分析部１４は、Ｓ１５又はＳ１７で移動させた要素は、しきい値を超える依存関係を縮退させているか否かを判断する（Ｓ１８）。移動された“要素１”及び“要素９”は、依存関係を縮退させていないので、縮退させていないと判断される。そのように判断された場合、分析部１４は、移動させた要素（ここでは“要素１”及び“要素９”）の順位を確定する（Ｓ１９）。順位を確定した要素及びそれらの要素に関係する依存関係を以降の考慮から除外する（Ｓ２０）。図１１に示す初期状態から、ここまでの処理を行った状態を図１３（ａ）に示す。この段階で順位が確定した又は仮決定していない要素は、“要素２，３，４，５，６，７，８，１０”である。これらの要素は全て、依存元及び依存先がある状態である。

続いて、分析部１４は、Ｓ１２及びＳ１３の判断を再度行う。ここでは、Ｓ１３の判断において、順位が確定又は仮決定していない要素全てには、要素すべてに依存元及び依存先があるので、そのように判断される。続いて、分析部１４は、順位未決定の要素のうち、最上位の要素を選択する（Ｓ２１）。ここでは、“要素２”が選択される。続いて、分析部１４は、選択された要素から依存先の要素を、同じ要素を２度検索するまで、連鎖的にサーチする（Ｓ２２）。このとき、サーチに用いる依存関係は、依存関係の数値がしきい値以上（即ちここでは１以上）のものを用いる。ここでは、分析部１４は、“要素２”→“要素３”→“要素２”という“要素２”に戻るループを識別することができる。続いて、分析部１４は、ループを構成する要素のうち、最初にサーチした要素を選択する（Ｓ２３）。ここでは、“要素２”が選択される。

続いて、分析部１４は、ループに含まれる要素をＳ２３で選択した要素に縮退させる（Ｓ２４）。縮退させるとは、具体的には以下の処理を行うことである。まず、縮退元の要素（ループに含まれる要素）を、一旦考慮しない対象とする。次に、縮退元の行列データを、縮退先（Ｓ２３で選択された要素）に一旦コピーする。なお、ここで、コピー先に数値が入っている場合は、コピーを行わない。ここまでの処理を行った状態を図１３（ｂ）に示す。この段階で順位が確定した又は仮決定していない要素は、“要素２（３），４，５，６，７，８，１０”である。これらの要素は全て、依存元及び依存先がある状態である。

続いて、再度Ｓ１２の判断に戻り、上記と同様（Ｓ１２，Ｓ１３，Ｓ２０〜Ｓ２４）の処理を行い、“要素７”、“要素６”、“要素４”、“要素５”、“要素８”、“要素１０”を順次、“要素２”に縮退させる。ここまでの処理を行った状態を図１３（ｃ）に示す。ここで、考慮すべき要素は、“要素２”だけの状態となる。ここで、考慮すべき要素の範囲で“要素２”には依存元がない。ここで、Ｓ１２，Ｓ１３，Ｓ１４の判断を経て、“要素２”が順位未決定範囲で最上位に移動されることになるが、既に最上位であるので移動はない。続いて、分析部１４は、移動された要素（厳密にいうと移動対象となった要素、即ちここでは“要素２”）は、しきい値を縮退させているか否かを判断する（Ｓ１８）。“要素２”は、上述したように各要素を縮退させているので、そのように判断される。そのように判断された場合、分析部１４は、その要素（“要素２”）の順位を仮確定する（Ｓ２５）。この状態で、全ての要素がしきい値ｓ＝１において、順位確定又は仮決定された。

続いて、分析部１４は、Ｓ１２の判断に戻り、順位確定又は仮決定していない要素はない、と判断する。そのように判断すると、分析部１４は、順位仮確定していた要素をリセットする（Ｓ２６）。続いて、分析部１４は、しきい値ｓ＝１で確定された要素と、未確定の要素とをパーティション分けするループチェインを生成する（Ｓ２７）。具体的には、図１３（ｄ）に模式的に示すように、依存関係のマトリックスに枠を示したようにループチェインを生成する。続いて、分析部１４は、依存関係のしきい値に１を加え（ｓ＝ｓ＋１）、しきい値を更新する（Ｓ２８）。続いて、分析部１４は、依存関係のしきい値は、ＤＳＭ表に含まれる依存関係の数値の最大値以内か否かを判断する（Ｓ２９）。最大値以内と判断された場合は、分析部１４は、Ｓ２８で更新されたしきい値を用いて、上述したＳ１２〜Ｓ２９の処理を再度、行う。ここでは、更新したしきい値ｓは２であり、ＤＳＭ表に含まれる依存関係の数値の最大値３以内であるので、再度処理が行われる。

一方、最大値以内でないと判断された場合は、分析部１４は、そこで処理を終了し、そこまで処理を行ったＤＳＭ表を出力する。図１４に、出力されるＤＳＭ表を示す。図１４における３つの枠は、外側から、それぞれしきい値が１の枠、しきい値が２の枠、しきい値が３の枠である。以上の処理により、各要素の優先順位の決定と、パーティション分けとが行われる。

図６のＤＳＭ表に対して上記のパーティション分析を行い、製品開発プロセスにおけるモジュール機能要件及びモジュール設計要素の考慮すべき優先順位を決定すると共に、モジュール機能要件及びモジュール設計要素をパーティション分けしたＤＳＭ表を図１５に示す。図１５のＤＳＭ表では、パーティション分けにより６つのループチェインが生成されている。

図２のフローチャートに戻り説明を続ける。続いて、製品開発プロセス支援システム１０では、分析部１４が、パーティション分析が行われたＤＳＭ表を用いて、ＱＦＤ表に変換する（Ｓ０４）。この変換は、ユーザが分析結果を容易に判断することができるようにするためである。ユーザにとっては、全ての要件が同一に並んでいるＤＳＭ表よりも、階層毎に要件が並んでいるＱＦＤ表の方が見やすいからである。ＤＳＭ表からＱＦＤ表への変換は、元のＱＦＤ表（図４に示すもの）を、Ｓ０３の処理によりＤＳＭ表により並べ替えられた、モジュール機能要件及びモジュール設計要素の順位によって並べ替えることにより行う。また、Ｓ０３の処理により得られたループチェインの情報を、ＱＦＤ表に転記する。変換されたＱＦＤ表を図１６に示す。この表の情報は、入出力インターフェース１１に出力される。

続いて、入出力インターフェースでは、Ｓ０４において変換されたＱＦＤ表を出力する（Ｓ０５）。図１６に示したものが、出力のイメージでもある。ユーザは、出力されたものを参照して、適宜、製品開発プロセスに利用する。

変換された分析後のＱＦＤ表は、分析後のＤＳＭ表で得られた、各モジュール機能要件及びモジュール設計要素の優先順位、及びＤＳＭ表で識別されたループチェインの情報を反映したものである。この表が示す意味は、以下のようなものである。各モジュール設計要素の設計条件を固めていく基本的順位は、表の左から右への順序である。各モジュール設計要素において、そのモジュール設計要素よりも左に位置しているものは、そのモジュール設計要素よりも先に固めることが必要となる（左側のモジュール設計要素は、右側のその他のモジュール設計要素の前提となる。即ち、右側のモジュール設計要素は左側のモジュール設計要素に対する依存関係がある）。また、各モジュール機能要件において、そのモジュール機能要件において、そのモジュール機能要件よりも上に位置しているものは、そのモジュール機能要件の達成の前に、達成の確認をされることが必要となる（上側のモジュール機能要件は、下側のその他のモジュール機能要件の前提となる。即ち、下側のモジュール機能要件は上側のモジュール機能要件に対する依存関係がある）。

また、モジュール機能要件及びモジュール設計要素のループチェインの内側のものほど強いループであり、そのループ内での試行錯誤を効率的に進める必要がある。例えば、内側のループのものに対してはシミュレーション等のより効率的な機能検証の手段を使うべきである。例えば、ループで識別された複数のモジュール設計要素と複数のモジュール機能要件の検証の作業は、同時期（コンカレント）に進めて、擦り合わせをとりながら行なわれるべきである。より具体的に言えば、ループチェインの情報に従って開発フェーズを切り分けて、各フェーズで固定すべき設計条件や機能確認を行う項目のガイドラインとすることもできる。

上述したように、本実施形態によれば、ＱＦＤ表という容易に入力できる情報から、ＤＳＭ表という同一の階層に属する任意の２つの要素間の依存関係を含む情報を導出することができる。従って、この依存関係を参照して、無駄な繰り返し作業を避けるように、製品開発プロセスにおいて考慮すべき要件に関しての決定を行うことができる。これにより、複雑な製品を開発する過程における無駄な繰り返し作業を、容易に低減することができる。本実施形態では、ＤＳＭ表に従って方向性のある依存関係を示す情報を導出しており、また、同一階層の要素間の依存関係でなく隣接する階層の要素間の依存関係も方向性のある依存関係を示す情報を導出しているので、より詳細な分析が可能になる。

なお、本実施形態において、ＤＳＭ表の依存関係を示す情報を入力しようとすると、ＱＦＤ表の依存関係を示す情報の約４倍の数値の入力を行なう必要がある。通常、多くの情報を入力しようとする場合の方が情報の不整合が出やすく、その点においても従来の分析手法と比較して、本実施形態が優れている。

また、本実施形態のように、ＱＦＤ表から導出されたＤＳＭ表に対してパーティション分析を行なうことにより、無駄な繰り返し作業を防止するという点で、望ましい順序及び区分で製品開発プロセスにおける要件に関しての決定を行うことができる。

また、本実施形態のように、ＱＦＤ表及びＤＳＭ表に従った処理を行なうことによって、ＱＦＤ手法やＤＳＭ手法の分析手法を本実施形態による方法と併せて適用することができ、またこれらの分析手法に係る従来のソフトウェアを利用することもでき、より確実かつ容易に本実施形態を実施することができる。

上述した実施形態は、図２における範囲２１で示す部分の依存関係、即ち２階層の要件の依存関係を分析するものである。引き続いて、図２における範囲２２で示す製品開発プロセス全体の各要件の依存関係、即ち３階層の要件の依存関係を分析するものを説明する。３階層の場合も、処理内容は基本的に上述した２階層のものと同様であるが、階層の重ね合わせのための追加処理がある。

まず、図３のフローチャートのＳ０１における、入力受付部１２によるＱＦＤ表による情報入力の受付は、隣接する階層毎に行なわれる。即ち、本実施形態では、システム要件とモジュール機能要件との間の依存関係を示す情報（図２における範囲２３）と、モジュールＡ機能要件とモジュールＡ設計要素との間の依存関係を示す情報（図２における範囲２１、上述した２階層のものと同様）、モジュールＢ機能要件とモジュールＢ設計要素との間の依存関係を示す情報（図２における範囲２４）をそれぞれ別のＱＦＤ表による入力を受け付ける。システム要件とモジュール機能要件との間の依存関係を示す情報（図２における範囲２３）に対応するＱＦＤ表（“ＱＦＤ１”とよぶ）を図１７（ａ）に示す。モジュールＢ機能要件とモジュールＢ設計要素との間の依存関係を示す情報（図２における範囲２４）に対応するＱＦＤ表（“ＱＦＤ３”とよぶ）を図１７（ｂ）に示す。なお、モジュールＡ機能要件とモジュールＡ設計要素との間の依存関係を示す情報（図２における範囲２１）に対応するＱＦＤ表（“ＱＦＤ２”とよぶ）は、上述したもの（図４に示したもの）と同様である。

続いて、図３のフローチャートのＳ０２おける、依存関係導出部１３によるＤＳＭ表での依存関係の導出は、それら個々のＱＦＤ表からそれぞれのＤＳＭ表を生成して行なわれる。導出の方法は上述した実施形態と同様である。階層の違いにより、影響度の名称が異なっている部分があるが、処理としては同様に行なわれる。“ＱＦＤ１”に対応するＤＳＭ表（“ＤＳＭ１”とよぶ）を図１８に示す。“ＱＦＤ３”に対応するＤＳＭ表（“ＤＳＭ３”とよぶ）を図１９に示す。“ＱＦＤ２”に対応するＤＳＭ表（“ＤＳＭ２”とよぶ）は、上述したもの（図６に示したもの）と同様である。

続いて、依存関係導出部１３が、図３のフローチャートにおけるＳ０３のパーティション分析の前に、“ＤＳＭ１〜３”を統合したＤＳＭ表（“ＤＳＭ４”とよぶ）を生成する。まず、図２０に示すような、システム要件、モジュール機能要件及びモジュール設計要素の全ての項目を行列の各要素とした、“ＤＳＭ４”の枠組みを生成する。生成された“ＤＳＭ４”の枠組みに、“ＤＳＭ１”、“ＤＳＭ２”、“ＤＳＭ３”の各数値を順番に入力していく。なお、重複する範囲は、後に入力するもので上書きする。図２１に、数値が入力された“ＤＳＭ４”を示す。図２１の“ＤＳＭ４”において、範囲５１の数値は、“ＤＳＭ１”の数値に対応している。“ＤＳＭ４”において、範囲５２の数値は、“ＤＳＭ２”の数値に対応している。範囲５３の数値は、“ＤＳＭ３”の数値に対応している。

続いて、図３のフローチャートのＳ０３おける、分析部１４によるＤＳＭ表でのパーティション分析は、図２１に示した、“ＤＳＭ１〜３”を統合した“ＤＳＭ４”を用いて行なわれる。パーティション分析自体は、上述した実施形態の方法と同様に行なわれる。図２２に、パーティション分析後の“ＤＳＭ４”を示す。

続いて、分析部１４は、パーティション分析後の“ＤＳＭ４”をＱＦＤ表に変換する。図２３に変換されるＱＦＤ表を示す。その際のＱＦＤ表では、縦方向にシステム要件及びモジュール機能要件の各項目が記載されている（範囲６１、各行データに対応している）。また、横方向にモジュール設計要素の各項目が記載されている（範囲６２、各列データに対応している）。ＱＦＤ表のマトリックスには、“ＱＦＤ１〜３”のそれぞれ対応する数値が入力される。但し、２階層離れたシステム要件とモジュール設計要素との間の依存関係は入力されていないので、その部分（例えば、図２３に示す行６３）は空欄となっている。このようなＱＦＤ表のフォーマットに対して、“ＤＳＭ４”から、上述したＱＦＤ表への変換の処理を行なうことにより、図２２に示す変換後のＱＦＤ表を得ることができる。

このように、３階層以上の要因を有する製品開発プロセスにも、本発明を適用することができ、上述したような効果を得ることができる。

本発明の実施形態に係る製品開発プロセス支援システムの構成図である。 実施形態での製品開発プロセスにおける要件の階層を示した図である。 本発明の実施形態に係る製品開発プロセス支援方法を示すフローチャートである。 実施形態での入力のフォームとなるＱＦＤ表を示した図である。 依存関係の度合を示す数値を説明した図である。 実施形態での処理におけるＤＳＭ表を示した図である。 モジュール設計要素に対するモジュール設計要素の依存関係を模式的に示した図である。 モジュール機能要件に対するモジュール設計要素の依存関係を模式的に示した図である。 モジュール機能要件に対するモジュール機能要件の依存関係を模式的に示した図である。 モジュール設計要素に対するモジュール機能要件の依存関係を模式的に示した図である。 パーティション分析を説明するために用いるサンプルのＤＳＭ表を示した図である。 パーティション分析の処理を示したフローチャートである。 パーティション分析におけるＤＳＭ表の推移を示した図である。 サンプルのＤＳＭ表に対応するパーティション分析後のＤＳＭ表を示した図である。 実施形態のＤＳＭ表に対応するパーティション分析後のＤＳＭ表を示した図である。 パーティション分析後のＤＳＭ表を用いて変換されたＱＦＤ表を示した図である。 階層が３段階になっている場合の、各ＱＦＤ表を示した図である。 階層が３段階になっている場合の、各ＤＳＭ表を示した図である。 階層が３段階になっている場合の、各ＤＳＭ表を示した図である。 階層が３段階になっている場合の、統合したＤＳＭ表の枠組みを示した図である。 階層が３段階になっている場合の、パーティション分析前のＤＳＭ表を示した図である。 階層が３段階になっている場合の、パーティション分析後のＤＳＭ表を示した図である。 階層が３段階になっている場合の、パーティション分析後のＤＳＭ表を用いて変換されたＱＦＤ表を示した図である。

符号の説明

１０…製品開発プロセス支援システム、１１…入出力インターフェース、１２…入力受付部、１３…依存関係導出部、１４…分析部。

Claims (4)

1. 複数の階層の何れかに属する、製品開発プロセスにおける複数の要件間の依存関係を分析する製品開発プロセス支援システムであって、
   それぞれ隣接した前記階層に属する２つの前記要件間の依存関係を示す情報、及び前記要件の製品開発に対する影響度を示す情報の入力を受け付ける入力受付手段と、
   同一の前記階層に属する任意の２つの前記要件間の依存関係を、前記入力受付手段により受け付けられた当該２つの要件とそれ以外の要件との依存関係を示す情報及び当該２つの要件の前記影響度を示す情報から、予め設定された依存関係導出ルールに基づいて導出する依存関係導出手段と、
   を備える製品開発プロセス支援システム。
2. 前記依存関係導出手段により導出された前記依存関係から、予め設定された分析ルールに基づいて、前記製品開発プロセスにおける同一の前記階層に属する要件の優先順位を決定すると共に、当該要件をパーティション分けする分析手段を更に備える請求項１に記載の製品開発プロセス支援システム。
3. 前記入力受付手段は、ＱＦＤ表の形式での前記依存関係を示す情報の入力を受け付け、
   前記依存関係導出手段は、ＤＳＭ表に従って、前記依存関係を導出する、
   ことを特徴とする請求項１又は２に記載の製品開発プロセス支援システム。
4. 複数の階層の何れかに属する、製品開発プロセスにおける複数の要件間の依存関係を分析する製品開発プロセス支援方法であって、
   それぞれ隣接した前記階層に属する２つの前記要件間の依存関係を示す情報、及び前記要件の製品開発に対する影響度を示す情報の入力を受け付ける入力受付ステップと、
   同一の階層に属する任意の２つの前記要件間の依存関係を、前記入力受付ステップにおいて受け付けられた当該２つの要件とそれ以外の要件との依存関係を示す情報及び当該２つの要件の前記影響度を示す情報から、予め設定された依存関係導出ルールに基づいて導出する依存関係導出ステップと、
   を有する製品開発プロセス支援方法。

Images