特許 7565857 設計品質監視装置、設計品質監視方法およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-03

(45)【発行日】2024-10-11

(54)【発明の名称】設計品質監視装置、設計品質監視方法およびプログラム

(51)【国際特許分類】

   G06Q 10/105 20230101AFI20241004BHJP

   G16Y 40/20 20200101ALI20241004BHJP

【ＦＩ】

G06Q10/105

G16Y40/20

【請求項の数】 8

(21)【出願番号】P 2021068743

(22)【出願日】2021-04-15

(65)【公開番号】P2022163737

(43)【公開日】2022-10-27

【審査請求日】2024-01-31

(73)【特許権者】

【識別番号】000006013

【氏名又は名称】三菱電機株式会社

(74)【代理人】

【識別番号】100095407

【弁理士】

【氏名又は名称】木村 満

(74)【代理人】

【識別番号】100131152

【弁理士】

【氏名又は名称】八島 耕司

(74)【代理人】

【識別番号】100147924

【弁理士】

【氏名又は名称】美恵 英樹

(74)【代理人】

【識別番号】100148149

【弁理士】

【氏名又は名称】渡邉 幸男

(74)【代理人】

【識別番号】100181618

【弁理士】

【氏名又は名称】宮脇 良平

(74)【代理人】

【識別番号】100174388

【弁理士】

【氏名又は名称】龍竹 史朗

(72)【発明者】

【氏名】弓場 章広

【審査官】樋口 龍弥

(56)【参考文献】

【文献】特開２０１２－０４３０３０（ＪＰ，Ａ）

【文献】特開２０１９－０３６２０５（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ － ９９／００

Ｇ１６Ｙ ４０／２０

(57)【特許請求の範囲】

【請求項1】

製品を構成するモジュール間のインターフェースの定義に基づいて、前記モジュールの担当者間のコミュニケーションの結合度を示す結合度情報を生成する結合度情報生成部、および、前記モジュールの担当者のスキルを含む属性を示す属性情報を生成する属性情報生成部を有し、前記結合度情報および前記属性情報を含む前記モジュールの担当者間の関係を示す情報を記憶部に記憶させる担当者登録部と、
前記モジュールの担当者間のコミュニケーションに関する情報を前記記憶部に記憶させるコミュニケーション登録部と、
前記モジュールの担当者間の関係を示す情報および前記モジュールの担当者間のコミュニケーションに関する情報に基づいて、前記モジュールの担当者間のコミュニケーションが適正であるか否かを判定するコミュニケーション判定部と、
前記コミュニケーション判定部の判定結果を出力する報知部と、
を備える設計品質監視装置。

【請求項2】

前記コミュニケーション判定部は、
前記モジュールの担当者間の関係を示す情報および前記モジュールの担当者間のコミュニケーションに関する情報に基づいて、前記モジュールの担当者間のコミュニケーションの開始時期が適正であるか否か、および、コミュニケーション量が適正であるか否かを判定する、
請求項１に記載の設計品質監視装置。

【請求項3】

前記コミュニケーション判定部は、
前記モジュールの担当者間のコミュニケーションに関する情報に基づいて、前記モジュールの担当者間のコミュニケーションの密度が適正であるか否かをさらに判定する、
請求項２に記載の設計品質監視装置。

【請求項4】

前記結合度情報生成部は、
前記モジュール間のインターフェースの定義に基づいて、前記モジュール間の相関の強さを算出し、前記モジュール間の相関の強さに変換係数を乗算して、前記モジュールの担当者間のコミュニケーションの結合度を示す結合度情報を生成し、前記記憶部に記憶させる、
請求項１から３のいずれか１項に記載の設計品質監視装置。

【請求項5】

前記属性情報生成部は、
前記モジュールの担当者のスキル、業務経験の年数および業務を行う場所を含む属性を示す前記属性情報を生成し、前記記憶部に記憶させる、
請求項１から４のいずれか１項に記載の設計品質監視装置。

【請求項6】

前記コミュニケーション登録部は、
前記モジュールの担当者が使用する作業端末を介して行われたコミュニケーションを示すコミュニケーションログ情報を生成し、逐次前記記憶部に記憶させるコミュニケーションロギング部と、
前記モジュールの担当者間で直接対話して行われたコミュニケーションを示すコミュニケーション結果情報を生成し、逐次前記記憶部に記憶させるコミュニケーション取得部と、
を備える請求項１から５のいずれか１項に記載の設計品質監視装置。

【請求項7】

設計品質監視装置が実行する、
製品を構成するモジュール間のインターフェースの定義に基づいて、前記モジュールの担当者間のコミュニケーションの結合度を示す結合度情報を生成するステップと、
前記モジュールの担当者のスキルを含む属性を示す属性情報を生成するステップと、
前記結合度情報および前記属性情報を含む前記モジュールの担当者間の関係を示す情報を記憶するステップと、
前記モジュールの担当者間のコミュニケーションに関する情報を記憶するステップと、
前記モジュールの担当者間の関係を示す情報および前記モジュールの担当者間のコミュニケーションに関する情報に基づいて、前記モジュールの担当者間のコミュニケーションが適正であるか否かを判定するステップと、
前記モジュールの担当者間のコミュニケーションが適正であるか否かの判定結果を出力するステップと、
を備える設計品質監視方法。

【請求項8】

コンピュータを、
製品を構成するモジュール間のインターフェースの定義に基づいて、前記モジュールの担当者間のコミュニケーションの結合度を示す結合度情報を生成する結合度情報生成部、および、前記モジュールの担当者のスキルを含む属性を示す属性情報を生成する属性情報生成部を有し、前記結合度情報および前記属性情報を含む前記モジュールの担当者間の関係を示す情報を記憶する担当者登録部、
前記モジュールの担当者間のコミュニケーションに関する情報を記憶するコミュニケーション登録部、
前記モジュールの担当者間の関係を示す情報および前記モジュールの担当者間のコミュニケーションに関する情報に基づいて、前記モジュールの担当者間のコミュニケーションが適正であるか否かを判定するコミュニケーション判定部、ならびに、
前記コミュニケーション判定部の判定結果を出力する報知部、
として機能させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、設計品質監視装置、設計品質監視方法およびプログラムに関する。

【背景技術】

【0002】

製品アーキテクチャーの１つに、インターフェースで連結される複数のモジュールで構成されるモジュール型製品がある。モジュール型製品の設計では、各モジュールの担当者間のコミュニケーションによって、インターフェース仕様書の疑問点、不足している点などを指摘し合いながら設計品質の向上が図られている。

【0003】

特許文献１には、査定回数、工数増減および納期遅延を考慮して解析したシステム開発の予定と実績との差に基づいて予想納期及び予想費用を算出するシステム開発プロジェクト進捗管理システムが開示されている。特許文献１に記載の技術では、査定回数、工数増減および納期遅延を含む各事象数値データを工数換算し、コミュニケーション不足を含む各原因項目に重み付けをして配賦することで、プロジェクトの進捗管理上生じる問題を原因項目ごとに定量的に評価している。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２００４―２１３３８６号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

特許文献１に記載の技術では、モジュール型製品の設計において、各モジュールの担当者間のコミュニケーションが不適正であることに気付くことができる仕組みがないので、設計品質が低下することがある。

【0006】

本開示は、モジュール型製品の設計において、設計品質の低下を防ぐことを目的とする。

【課題を解決するための手段】

【0007】

上記目的を達成するため、本開示に係る設計品質監視装置は、担当者登録部と、コミュニケーション登録部と、記憶部と、コミュニケーション判定部と、報知部とを備える。担当者登録部は、製品を構成するモジュール間のインターフェースの定義に基づいて、モジュールの担当者間のコミュニケーションの結合度を示す結合度情報を生成する結合度情報生成部、および、モジュールの担当者のスキルを含む属性を示す属性情報を生成する属性情報生成部を有し、結合度情報および属性情報を含むモジュールの担当者間の関係を示す情報を記憶部に記憶させる。コミュニケーション登録部は、モジュールの担当者間のコミュニケーションに関する情報を記憶部に記憶させる。コミュニケーション判定部は、モジュールの担当者間の関係を示す情報およびモジュールの担当者間のコミュニケーションに関する情報に基づいて、モジュールの担当者間のコミュニケーションが適正であるか否かを判定する。報知部は、コミュニケーション判定部の判定結果を出力する。

【発明の効果】

【0008】

本開示によれば、モジュール型製品の設計において、モジュールの担当者間のコミュニケーションが適正であるか否かの判定結果を出力することで、設計品質の低下を防ぐことができる。

【図面の簡単な説明】

【0009】

【図1】実施の形態に係る設計品質監視装置の構成例を示す図

【図2】実施の形態に係るランク値を求めるための関数分布の例を示す図

【図3】実施の形態に係るランクポイントを決定する算出表の例を示す図

【図4】実施の形態に係るレベルを決定する算出表の例を示す図

【図5】実施の形態に係る結合度情報の例を示す図

【図6】実施の形態に係る結合度情報を説明するイメージ図

【図7】実施の形態に係るスキル係数ｓを決定する算出表の例を示す図

【図8】実施の形態に係る変換係数ｔおよび補正係数ｈを決定する算出表を示す図

【図9】実施の形態に係るコミュニケーションの開始適正時期の算出方法を説明する図

【図10】実施の形態に係るコミュニケーションが適正である場合のコミュニケーション例を示す図

【図11】実施の形態に係る上位から下位へのコミュニケーションの開始が遅い場合のコミュニケーション例を示す図

【図12】実施の形態に係る下位から上位へのコミュニケーションの開始が遅い場合のコミュニケーション例を示す図

【図13】実施の形態に係る上位から下位へのコミュニケーションが少ない場合のコミュニケーション例を示す図

【図14】実施の形態に係る下位から上位へのコミュニケーションが少ない場合のコミュニケーション例を示す図

【図15】実施の形態に係る上位から下位へのコミュニケーションが多すぎる場合のコミュニケーション例を示す図

【図16】実施の形態に係る下位から上位へのコミュニケーションが多すぎる場合のコミュニケーション例を示す図

【図17】実施の形態に係る上位から下位へのコミュニケーションの密度が低い場合のコミュニケーション例を示す図

【図18】実施の形態に係る下位から上位へのコミュニケーションの密度が低い場合のコミュニケーション例を示す図

【図19】実施の形態に係る結合度情報生成処理を示すフローチャート

【図20】実施の形態に係る属性情報生成処理を示すフローチャート

【図21】実施の形態に係るコミュニケーションロギング処理を示すフローチャート

【図22】実施の形態に係るコミュニケーション取得処理を示すフローチャート

【図23】実施の形態に係るコミュニケーション判定処理を示すフローチャート

【図24】実施の形態に係る設計品質監視装置のハードウェア構成の一例を示す図

【発明を実施するための形態】

【0010】

以下に、本実施の形態に係る設計品質監視装置、設計品質監視方法およびプログラムについて図面を参照して詳細に説明する。なお、図中同一または相当する部分には同じ符号を付す。以下の実施の形態では、ソフトウェアのモジュール型製品を開発するプロジェクトにおいて、モジュールの担当者間のコミュニケーションが適正か否かでモジュールの設計品質を監視する例について説明する。以下の説明では、ソフトウェアのモジュール型製品を単に製品といい、設計品質監視装置を用いてモジュールの設計品質を管理するユーザを管理者という。管理者は、モジュールの担当者であってもよい。

【0011】

実施の形態に係る設計品質監視装置１の構成について、図１を用いて説明する。図１に示すように、設計品質監視装置１は、製品を構成するモジュールの担当者間の関係を示す情報を記憶部１３に記憶させる担当者登録部１１と、製品を構成するモジュールの担当者間のコミュニケーションに関する情報を記憶部１３に記憶させるコミュニケーション登録部１２と、製品を構成するモジュールの担当者間の関係を示す情報および製品を構成するモジュールの担当者間のコミュニケーションに関する情報を記憶する記憶部１３と、記憶部１３が記憶する情報に基づいてモジュールの担当者間のコミュニケーションが適正であるか否かを判定するコミュニケーション判定部１４と、担当者間のコミュニケーションが不適正であることを報知する警告情報を出力する報知部１５とを備える。

【0012】

担当者登録部１１は、モジュールの担当者間のコミュニケーションの結合度を示す結合度情報を生成する結合度情報生成部１１１と、各モジュールの担当者のスキルを示す属性情報を生成する属性情報生成部１１２と、を備える。結合度情報および属性情報は、製品を構成するモジュールの担当者間の関係を示す情報の例である。

【0013】

開発する製品の概要が決定すると簡易的な事前設計が実施される。事前設計において決定される事項には、製品のモジュール構成、モジュール間のインターフェースの定義、開発期間および各モジュールの開発規模比率を含む。製品のモジュールの構成は、階層構造になっており、上位モジュールと下位モジュールとがインターフェースで連結される。モジュール間のインターフェースの定義は、インターフェースの複雑度およびモジュール間で使用される関数の単位時間あたりの呼び出し回数を含む。開発期間は、プロジェクトにおける設計業務の開始から終了までとする。事前設計の実施と共に各モジュールの担当者が決定される。管理者は、事前設計で決定された製品のモジュールの構成、モジュール間のインターフェースの定義、開発期間および各モジュールの開発規模比率を含む事前設計情報と各モジュールの担当者を示す担当者情報とを設計品質監視装置１に入力する。

【0014】

結合度情報生成部１１１は、事前設計情報が入力されると、事前設計情報にて定義されたインターフェースの複雑度と関数の単位時間あたりの呼び出し回数とに基づいて、関数分布図を用いて、モジュール間で使用される関数についてそれぞれランク値を求める。図２に関数分布図の例を示す。図２に示す関数分布図は、縦軸が関数の単位時間あたりの呼び出し回数、横軸がインターフェースの複雑度である。結合度情報生成部１１１は、事前設計情報にて定義されたモジュール間で使用される関数を関数分布図にプロットして、各ランク値を求める。図２の例では、ランク０の関数が１個、ランク１の関数が１個、ランク２の関数が３個、ランク３の関数が１個、ランク４の関数が１個、ランク５の関数が２個ある。関数分布図のランク値は、プロジェクトごとに設定される。

【0015】

結合度情報生成部１１１は、図３に示すように、各ランク値に属する関数の個数に該ランク値に対応する係数を乗算して合計したランクポイントを算出する。各ランク値に対応する係数は、プロジェクトごとに設定される。図３の例では、ランクポイントは２４である。

【0016】

結合度情報生成部１１１は、図４に示すように、算出したランクポイントに基づいて、モジュール間の相関の強さを表すレベルを決定する。図３の例のように、ランクポイントが２４であった場合、結合度情報生成部１１１は、図４の表を参照して、モジュール間の相関の強さをレベル２と決定する。

【0017】

図１に戻り、結合度情報生成部１１１は、モジュール間の相関の強さをモジュールの担当者間のコミュニケーションの結合度に変換する。例えば、モジュール間の相関の強さがレベル２であった場合、上位モジュールの担当者から下位モジュールの担当者へのコミュニケーションの結合度は、レベル２に変換係数ｃ１（＝１）を乗算して結合度２とする。一方、下位モジュールの担当者から上位モジュールの担当者へのコミュニケーションの結合度は、レベル２に変換係数ｃ２（＝０．５）を乗算して結合度１とする。ここでは、上位モジュールから下位モジュールを呼び出すことを前提に、上位モジュールの担当者から下位モジュールの担当者に説明を求めることが増加することを想定して、変換係数ｃ１＞変換係数ｃ２としたが、これに限らない。変換係数を用いずにモジュール間の相関の強さをそのままモジュールの担当者間のコミュニケーションの結合度にしてもよいし、変換係数ｃ１および変換係数ｃ２を、例えば、過去のプロジェクトにおけるコミュニケーション量から算出してもよい。

【0018】

結合度情報生成部１１１は、モジュールの担当者間のコミュニケーションの結合度を示す結合度情報を生成し、記憶部１３に記憶させる。また、結合度情報生成部１１１は、事前設計情報を記憶部１３に記憶させる。

【0019】

属性情報生成部１１２は、担当者情報が入力されると、担当者情報が示す各モジュールの担当者のスキルを入力可能な入力画面を表示する。管理者が入力画面に各モジュールの担当者のスキルを入力すると、属性情報生成部１１２は、各モジュールの担当者のスキルを示す属性情報を生成し、記憶部１３に記憶させる。なお、各モジュールの担当者のスキルは、担当者情報に含まれていてもよい。この場合、属性情報生成部１１２は、入力された担当者情報を属性情報として記憶部１３に記憶させる。

【0020】

コミュニケーション登録部１２は、担当者が使用する作業端末を介して行われたコミュニケーションを記録したコミュニケーションログを取得するコミュニケーションロギング部１２１と、担当者間で直接対話して行われたコミュニケーションの結果の入力を受け付けるコミュニケーション取得部１２２と、を備える。

【0021】

プロジェクトが開始される前に、各担当者の作業端末には作業端末を介して行われたコミュニケーションのログを取得するログツールがインストールされている。作業端末を介して行われるコミュニケーションとは、例えば、メールアプリ、グループウェアなどの他者に対して情報を伝達することができるコミュニケーションアプリを用いたコミュニケーションのことである。ログツールは、各担当者が使用する作業端末を介して行われたコミュニケーションを検知し、コミュニケーションの量を抽出する。メール、文書登録、チャットなどの文章によるコミュニケーションの場合、コミュニケーションの量として文字数を抽出する。音声通話、ビデオ通話などの会話によるコミュニケーションの場合、コミュニケーションの量として時間を抽出する。

【0022】

ログツールは、コミュニケーションの量を抽出すると共に、コミュニケーションの主体および客体を抽出する。メール、文書登録、チャットなどの文章によるコミュニケーションの場合、コミュニケーションの主体および客体としてそれぞれ差出人と受取人を抽出する。音声通話、ビデオ通話などの会話によるコミュニケーションの場合、コミュニケーションの主体および客体としてそれぞれ発信者および受信者を抽出する。

【0023】

ログツールは、コミュニケーションの量およびコミュニケーションの主体および客体を抽出するたびに、コミュニケーションの量およびコミュニケーションの主体および客体を記録したコミュニケーションログをコミュニケーションロギング部１２１に送信する。ログツールは、開発期間中、コミュニケーションの量およびコミュニケーションの主体および客体の抽出を継続して行い、コミュニケーションログをコミュニケーションロギング部１２１に送信し続ける。

【0024】

コミュニケーションロギング部１２１は、各作業端末のログツールからコミュニケーションログを受信する度に、受信したコミュニケーションログと入力された担当者情報とに基づいて、コミュニケーションの量、コミュニケーションの主体および客体、ならびに、コミュニケーションの方向を示すコミュニケーションログ情報を生成し、逐次記憶部１３に記憶させる。コミュニケーションログ情報は、モジュールの担当者間のコミュニケーションに関する情報の例である。コミュニケーションの方向は、上位モジュールの担当者が主体であり下位モジュールの担当者が客体であるコミュニケーションの方向を上→下とする。逆に下位モジュールの担当者が主体であり上位モジュールの担当者が客体であるコミュニケーションの方向を下→上とする。

【0025】

一方、担当者同士の立ち話、会議などの直接対話のコミュニケーションが行われた場合は、コミュニケーションの結果がコミュニケーション取得部１２２に入力される。コミュニケーションの結果は、コミュニケーションの量およびコミュニケーションの主体および客体で入力される。コミュニケーションの結果の入力方法は、例えば、コミュニケーション取得部１２２に直接入力してもよいし、打ち合わせ場所、会議室などに設けられた端末あるいは携帯端末に入力してコミュニケーション取得部１２２に送信される構成にしてもよい。コミュニケーションの結果を入力するのは、コミュニケーションの当事者でもよいし、同席していた人物でもよい。直接対話のコミュニケーションの場合、例えば、コミュニケーションを実施した時間（コミュニケーションの量）と誰から誰へのコミュニケーションであるか（コミュニケーションの主体および客体）とがコミュニケーションの結果としてコミュニケーション取得部１２２に入力される。

【0026】

コミュニケーション取得部１２２は、コミュニケーションの結果が入力される度に、入力されたコミュニケーションの結果と入力された担当者情報とに基づいて、コミュニケーションの量、コミュニケーションの主体および客体、ならびに、コミュニケーションの方向を示すコミュニケーション結果情報を生成し、逐次記憶部１３に記憶させる。コミュニケーション結果情報は、モジュールの担当者間のコミュニケーションに関する情報の例である。

【0027】

コミュニケーション判定部１４は、記憶部１３が記憶する事前設計情報、結合度情報、属性情報、コミュニケーションログ情報およびコミュニケーション結果情報に基づいて、モジュールの担当者間のコミュニケーションが適正か否かを判定する。以下、モジュールの担当者間のコミュニケーションが適正か否かを判定することをコミュニケーション適正判定という。コミュニケーション判定部１４は、記憶部１３が記憶する事前設計情報から開発期間を取得し、開発期間中、コミュニケーション適正判定を複数回実施し、モジュールの設計品質を監視する。プロジェクトの規模によって予め決定される監視回数をＮ回とすると、コミュニケーション判定部１４は、開発期間が始まると開発期間／Ｎごとにコミュニケーション適正判定を行う。

【0028】

コミュニケーション判定部１４は、開発期間が始まってから開発期間／Ｎが経過すると、まず、モジュールの担当者間で必要なコミュニケーション量を算出するために、記憶部１３から図５に示すような結合度情報を取得する。以下、モジュールの担当者間で必要なコミュニケーション量を必要コミュニケーション量という。上述のように、モジュールの担当者間のコミュニケーションの結合度がコミュニケーションの方向によって異なる場合には、必要コミュニケーション量をコミュニケーションの方向ごとに算出する。

【0029】

図５に示す結合度情報の例では、コミュニケーションの主体の担当者から客体の担当者へのコミュニケーションの結合度を表している。例えば、主体担当者Ａから客体担当者Ｂへのコミュニケーションの結合度は５である。逆に、主体担当者Ｂから客体担当者Ａへのコミュニケーションの結合度は３である。

【0030】

図５の結合度情報の例が示す各担当者間の関係のイメージ図を、図６に示す。図６のイメージ図では、矢印の太さは担当者間のコミュニケーションの結合度を表しており、矢印が太いほどコミュニケーションの結合度が高いことを表している。矢印の元がコミュニケーションの主体の担当者であり、矢印の先がコミュニケーションの客体の担当者である。

【0031】

コミュニケーション判定部１４は、モジュールの担当者間のコミュニケーションの結合度を示す結合度情報を取得すると、担当者のスキルによって必要コミュニケーション量を補正するために、記憶部１３から属性情報を取得する。担当者のスキルによる必要コミュニケーション量の補正を行うのは、担当者のスキルによって必要となるコミュニケーションの量が異なるためである。

【0032】

コミュニケーション判定部１４は、属性情報に基づいて、スキル係数ｓを決定する。図７にスキル係数ｓを決定する算出表の例を示す。スキル係数ｓは、モジュール間の担当者のスキルの組み合わせによって決定される。図７の例では、担当者のスキルを有識者であるか非有識者であるかで表現している。原則として、知識が豊富な担当者つまり有識者とのコミュニケーションであれば、コミュニケーション量が増加しないため、スキル係数ｓは小さく設定する。逆に、知識が豊富でない担当者つまり非有識者とのコミュニケーションであれば、コミュニケーション量が増加するため、スキル係数ｓは大きく設定する。図７の例では、有識者の参加が少なくなるほどスキル係数ｓが高くなっている。

【0033】

図７の例では、担当者のスキルを有識者であるか非有識者であるかで表現しているが、担当者の多様性に合わせてスキル係数ｓを決定する算出表のメッシュを細かくするほど、コミュニケーション判定部１４のコミュニケーション適正判定の精度は向上する。

【0034】

コミュニケーション判定部１４は、取得した結合度情報が示す結合度と、スキル係数ｓと、予め決められた係数ｃと以下の数１とを用いて、必要コミュニケーション量を算出する。係数ｃは、例えば、過去のプロジェクトにおけるコミュニケーション量から予め算出しておく。

【0035】

（数１） 結合度×スキル係数ｓ×係数ｃ= 必要コミュニケーション量

【0036】

必要コミュニケーション量の単位は、コミュニケーションログ情報およびコミュニケーション結果情報に含まれるコミュニケーション量と比較可能な単位であれば何でもよいが、ここでは時間単位とする。

【0037】

図１に戻り、コミュニケーション判定部１４は、記憶部１３からコミュニケーションログ情報およびコミュニケーション結果情報を取得する。コミュニケーションログ情報には、直接対話、テレコミュニケーションなどの会話による時間のコミュニケーション量の他に、メール、チャットなどの文字による文字数のコミュニケーション量が含まれる。コミュニケーション判定部１４は、必要コミュニケーション量の単位である時間単位に統一するために、変換係数ｔと以下の数２とを用いて、文字数のコミュニケーション量を時間のコミュニケーション量に変換する。

【0038】

（数２） 文字数のコミュニケーション量÷変換係数ｔ＝時間のコミュニケーション量

【0039】

また、コミュニケーション種別によって情報の伝達効率が異なるため、コミュニケーション種別ごとに予め補正係数ｈが設定されている。コミュニケーション判定部１４は、補正係数ｈと以下の数３を用いて、時間のコミュニケーション量から実質的に行われたとみなすコミュニケーション量を算出する。以下、実質的に行われたとみなすコミュニケーション量を実質コミュニケーション量という。

【0040】

（数３） 時間のコミュニケーション量×補正係数ｈ＝実質コミュニケーション量

【0041】

図８に変換係数ｔおよび補正係数ｈを決定する算出表の例を示す。変換係数ｔおよび補正係数ｈは、コミュニケーション種別によって決定される。例えば、コミュニケーション種別が直接対話である場合は、コミュニケーション量の単位が時間（分）であって、時間単位に変換する必要がないので、変換係数ｔは１である。また直接対話の情報の伝達効率を基準として、補正係数ｈは１に設定されている。コミュニケーション種別がチャットである場合は、コミュニケーション量の単位が文字数であって、時間単位に変換する必要があるので、変換係数ｔは１００に設定されており、補正係数ｈは０．６に設定されている。つまり、チャットでの１００文字のやり取りと直接対話での０．６分のやり取りとが同等のコミュニケーション量であるとみなしている。

【0042】

また、コミュニケーション判定部１４は、製品のモジュールの階層数および各モジュールの開発規模比率に基づいて、モジュールの担当者間のコミュニケーションの開始適正時期を算出する。以下、コミュニケーションの開始適正時期を算出する対象のモジュールを算出対象モジュールという。

【0043】

一般的に、開発期間中に上位モジュールから設計され順次下位モジュールが設計されるため、算出対象モジュールが製品のモジュールの階層の中でどの階層に位置するのかによってコミュニケーションを開始すべき時期が異なる。このため、コミュニケーション判定部１４は、記憶部１３が記憶する事前設計情報から製品のモジュールの階層数Ｘと算出対象モジュールの階層Ｙとを取得する。なお最上位の階層を０とする。

【0044】

コミュニケーション判定部１４は、算出対象モジュールの階層に基づく算出対象モジュールのコミュニケーションの開始時期ＸＴを、以下の数４を用いて算出する。以下、開発期間をＤＴとする。

【0045】

（数４） (開発期間ＤＴ ÷ 階層数Ｘ)×階層Ｙ＝開始時期ＸＴ

【0046】

また、一般的に、モジュールの開発規模が大きいほど設計に時間がかかるため、各モジュールの開発規模比率によってコミュニケーションを開始すべき時期が異なる。このため、コミュニケーション判定部１４は、記憶部１３が記憶する事前設計情報から製品の各モジュールの開発規模比率ｒを取得する。コミュニケーション判定部１４は、開発期間ＤＴを上位モジュールから順に開発規模比率ｒに従って分割する。

【0047】

コミュニケーション判定部１４は、各モジュールの開発規模比率に基づく算出対象モジュールのコミュニケーションの開始時期ＲＴを、以下の数５を用いて算出する。

【0048】

（数５）(開発期間ＤＴ ÷１００) × (ｒ０＋ｒ１＋・・・)＝開始時期ＲＴ

【0049】

数５の(ｒ０＋ｒ１＋・・・)は、算出対象モジュールよりも上位のモジュールの比率の総和である。数５では、(ｒ０＋ｒ１＋・・・)と記載しているが、算出対象モジュールが最上位モジュールである場合は０となり、開発期間が始まった時がコミュニケーションの開始時期ＲＴとなる。コミュニケーション判定部１４は、開始時期ＸＴと開始時期ＲＴとの早い方をコミュニケーションの開始適正時期とする。

【0050】

図９は、コミュニケーションの開始適正時期の算出方法を説明する図である。図９の例では、製品のモジュールの階層数Ｘ＝４である。算出対象モジュールの階層Ｙ＝３とすると、算出対象モジュールの階層に基づくコミュニケーションの開始時期ＸＴは、(開発期間ＤＴ ÷ 階層数４)×階層３となり、開発期間ＤＴの７５％が経過した時点となる。各モジュールの開発規模比率ｒ（ｒ０＝２０，ｒ１＝２０，ｒ２＝４０，ｒ３＝２０）に基づく算出対象モジュールのコミュニケーションの開始時期ＲＴは、(開発期間ＤＴ ÷１００) × (ｒ０＋ｒ１＋ｒ２)となり、開発期間ＤＴの８０％が経過した時点となる。コミュニケーション判定部１４は、開始時期ＸＴと開始時期ＲＴとの早い方、つまり、開始時期ＸＴ（開発期間ＤＴの７５％が経過した時点）をコミュニケーションの開始適正時期とする。一方、算出対象モジュールの階層Ｙ＝１の場合および階層Ｙ＝２のモジュールの場合は、開始時期ＸＴより開始時期ＲＴの方が早いので、開始時期ＲＴをコミュニケーションの開始適正時期とする。開始適正時期を早い方にすることで、下流の工程での遅延を防止すると共にモジュール間の不整合などの問題の見直し時期も確保することができる。

【0051】

図１に戻り、コミュニケーション判定部１４は、記憶部１３から取得したコミュニケーションログ情報およびコミュニケーション結果情報と算出した実質コミュニケーション量、開始適正時期および必要コミュニケーション量とに基づいて、モジュールの担当者間のコミュニケーションが適正であるか否かを判定する。モジュールの担当者間のコミュニケーションが不適正である場合には、報知部１５にモジュールの担当者間のコミュニケーションが不適正であることを報知する警告情報を送る。報知部１５は、受け取った警告情報を出力する。警告情報の出力方法は、例えば、画面表示してもよいし、音声出力してもよいし、管理者が使用する端末に送信してもよい。警告情報が出力されることで、管理者はモジュールの担当者間のコミュニケーションが不適正であることを知ることができる。警告情報は、判定結果の例である。報知部１５が出力する情報は、警告情報に限らず、コミュニケーション判定部１４の判定結果を含む情報であればよい。

【0052】

コミュニケーション判定部１４は、コミュニケーションの開始時期が開始適正時期よりも早い場合は、設計着手よりも前に懸念情報、制約事項などが共有されているものと考え、モジュールの担当者間のコミュニケーションが適正になされていると判定する。ただし、コミュニケーションの開始時期が開始適正時期よりも決められた期間以上早い場合に報知を行うか否は、管理者が設定可能にしてもよい。

【0053】

ここから、図１０～図１７を用いて、様々なパターンのコミュニケーション例について説明する。図１０～図１７は、縦軸を実質コミュニケーション量（単位：１週あたりの合計時間ｈ／Ｗ）、横軸を開発期間（単位：週Ｗ）とする。開発期間を１０Ｗ、コミュニケーション適正判定を行ってモジュールの設計品質を監視する監視タイミングを１Ｗごと（Ｎ＝１０）とする。上→下のコミュニケーションの開始適正時期を３Ｗ、上→下のコミュニケーションの開始時点から１週間以内が下→上のコミュニケーションの開始適正時期とする。次の階層の上→下のコミュニケーションの開始適正時期を８Ｗとする。上→下のコミュニケーションの必要コミュニケーション量を１０ｈ、下→上のコミュニケーションの必要コミュニケーション量を８ｈとする。

【0054】

まず、コミュニケーション判定部１４は、記憶部１３から取得したコミュニケーションログ情報およびコミュニケーション結果情報に基づいて、コミュニケーション適正判定を行うモジュールの担当者間の上→下のコミュニケーションの開始時期および下→上のコミュニケーションの開始時期を特定し、開始適正時期に基づいて、コミュニケーションの開始時期が適正であるか否かを判定する。以下、コミュニケーション適正判定を行う対象のモジュールを判定対象モジュールという。

【0055】

図１０に示すコミュニケーション例では、３Ｗに上→下のコミュニケーションが開始されており、４Ｗに下→上のコミュニケーションが開始されているので、コミュニケーション判定部１４は、コミュニケーションの開始時期が適正であると判定する。図１１に示すコミュニケーション例では、上→下のコミュニケーションの開始が開始適正時期よりも遅くなっているので、コミュニケーション判定部１４は、上→下のコミュニケーションの開始時期が不適正であると判定する。このため、コミュニケーション判定部１４は、３Ｗの監視タイミングで上→下のコミュニケーションの開始適正時期が過ぎていることを報知する警告情報を報知部１５を介して出力する。図１１の例では、下→上のコミュニケーションは省略されている。

【0056】

上→下のコミュニケーションの開始時期が開始適正時期よりも遅れている場合には、例えば、上位モジュールの担当者が設計業務を実施できる状態でない、質問すべき内容がまとまらないなどの問題が推測されるので、警告情報には、そのような問題点を指摘する内容を含んでもよい。

【0057】

図１２に示すコミュニケーション例では、上→下のコミュニケーションの開始時期が３Ｗであるので適正であるが、下→上のコミュニケーションの開始時期が開始適正時期よりも遅くなっているので、コミュニケーション判定部１４は、下→上のコミュニケーションの開始時期が不適正であると判定する。コミュニケーション判定部１４は、４Ｗの監視タイミングで下→上のコミュニケーションの開始適正時期が過ぎていることを報知する警告情報を報知部１５を介して出力する。

【0058】

下→上のコミュニケーションの開始時期が開始適正時期よりも遅れている場合には、例えば、上位モジュールの担当者は設計業務を実施できる状態であるが下位モジュールの担当者は設計業務を実施できる状態でない、上位モジュールの担当者からの質問の内容が分からないなどの問題が推測されるので、警告情報には、そのような問題点を指摘する内容を含んでもよい。

【0059】

続いて、コミュニケーション判定部１４は、判定対象モジュールの担当者間の上→下の実質コミュニケーション量および下→上のコミュニケーション実質コミュニケーション量と必要コミュニケーション量とに基づいて、実質コミュニケーション量が適正であるか否かを判定する。

【0060】

例えば、上→下のコミュニケーションの開始適正時期が３Ｗであって、次の階層のモジュールの上→下のコミュニケーションの開始適正時期が８Ｗであるので、判定対象モジュールの上→下のコミュニケーションをすべき期間を３Ｗから８Ｗの５週間とする。また、下→上のコミュニケーションの開始適正時期が上→下のコミュニケーションの開始時点から１週間以内であって、次の階層のモジュールの上→下のコミュニケーションの開始適正時期が８Ｗであるので、判定対象モジュールの上→下のコミュニケーションをすべき期間は４Ｗから８Ｗの４週間とする。

【0061】

コミュニケーション判定部１４は、判定対象モジュールの上→下のコミュニケーションの必要コミュニケーション量が１０ｈであって、コミュニケーションをすべき期間が５Ｗであるので、最初の監視タイミングでは、１０ｈを５Ｗで除算した２ｈ／Ｗのコミュニケーション量が必要であるものとする。以下、監視タイミングごとに必要なコミュニケーション量を単位必要コミュニケーション量という。２回目以降の監視タイミングでは、コミュニケーション判定部１４は、これまでの監視タイミングで算出された実施済みのコミュニケーション量の合計を必要コミュニケーション量から減算した必要コミュニケーション残量を算出し、必要コミュニケーション残量を残りの上→下のコミュニケーションをすべき期間で除算した値を単位必要コミュニケーション量とする。

【0062】

図１３の例では、上→下のコミュニケーションの開始時期である３Ｗの監視タイミングでは、実質コミュニケーション量が単位必要コミュニケーション量２ｈ／Ｗを満たしているので、コミュニケーション判定部１４は、上→下のコミュニケーション量が適正であると判定する。４Ｗの監視タイミングでは、必要コミュニケーション残量は８ｈで残りの上→下のコミュニケーションをすべき期間は４Ｗであるので、単位必要コミュニケーション量２ｈ／Ｗである。４Ｗにおける実質コミュニケーション量はこれを満たしていないので、コミュニケーション判定部１４は、上→下の実質コミュニケーション量が不適正であると判定する。コミュニケーション判定部１４は、４Ｗの監視タイミングで上→下のコミュニケーション量が不適正であることを報知する警告情報を報知部１５を介して出力する。

【0063】

下→上のコミュニケーションについても同様に、コミュニケーション判定部１４は、判定対象モジュールの下→上のコミュニケーションの必要コミュニケーション量が８ｈであって、コミュニケーションをすべき期間が４Ｗであるので、最初の監視タイミングにおける単位必要コミュニケーション量は、８ｈを４Ｗで除算した２ｈ／Ｗであるものとする。２回目以降の監視タイミングでは、コミュニケーション判定部１４は、これまでの監視タイミングで算出された実施済みのコミュニケーション量の合計を必要コミュニケーション量から減算した必要コミュニケーション残量を算出し、必要コミュニケーション残量を残りの上→下のコミュニケーションをすべき期間で除算した値を単位必要コミュニケーション量とする。

【0064】

図１４の例では、下→上のコミュニケーションの開始時期である４Ｗの監視タイミングで、実質コミュニケーション量が単位必要コミュニケーション量２ｈ／Ｗを満たしていないので、コミュニケーション判定部１４は、下→上の実質コミュニケーション量が不適正であると判定する。コミュニケーション判定部１４は、４Ｗの監視タイミングで下→上のコミュニケーション量が不適正であることを報知する警告情報を報知部１５を介して出力する。

【0065】

上→下または下→上のコミュニケーション量が少ない場合、相互の意思疎通に問題がある可能性がある。年少者から年長者への質問が行いにくい職場環境、担当者のスキル不足による曖昧な理解のためコミュニケーション回数が少なくなっているなどの問題が推測されるので、警告情報には、そのような問題点を指摘する内容を含んでもよい。

【0066】

続いて、実質コミュニケーション量が多すぎる場合について説明する。コミュニケーション判定部１４は、上→下のコミュニケーションについては、例えば、監視タイミングにおける実質コミュニケーション量が単位必要コミュニケーション量の３倍以上である場合に、実質コミュニケーション量が不適正であると判定する。なお、上→下の実質コミュニケーション量が多すぎるか否かの判定は、単位必要コミュニケーション量の３倍以上であるか否かに限らず、例えば、単位必要コミュニケーション量の２倍以上、４倍以上であるか否かでもよいし、単位必要コミュニケーション量よりも閾値以上多いか否かでもよい。

【0067】

図１５の例では、３Ｗの監視タイミングにおける上→下の実質コミュニケーション量が単位必要コミュニケーション量２ｈ／Ｗの３倍である６ｈ／Ｗ未満であるので、コミュニケーション判定部１４は、上→下の実質コミュニケーション量が適正であると判定する。４Ｗの監視タイミングでは、６ｈ／Ｗ以上であるので、上→下の実質コミュニケーション量が不適正であると判定する。コミュニケーション判定部１４は、４Ｗの監視タイミングで上→下のコミュニケーション量が不適正であることを報知する警告情報を報知部１５を介して出力する。

【0068】

上→下の実質コミュニケーション量が多すぎる場合には、初期の設計に不備があって見直しが頻繁に発生している、設計者のスキルが不足している、仕様が曖昧なまま設計を行っているなどの問題が推測されるので、警告情報には、そのような問題点を指摘する内容を含んでもよい。

【0069】

コミュニケーション判定部１４は、下→上のコミュニケーションについては、例えば、監視タイミングにおける実質コミュニケーション量が単位必要コミュニケーション量の２倍以上である場合に、実質コミュニケーション量が不適正であると判定する。なお、下→上の実質コミュニケーション量が多すぎるか否かの判定は、単位必要コミュニケーション量の２倍以上であるか否かに限らず、例えば、単位必要コミュニケーション量の３倍以上、４倍以上であるか否かでもよいし、単位必要コミュニケーション量よりも閾値以上多いか否かでもよい。

【0070】

図１６の例では、４Ｗの監視タイミングにおける下→上の実質コミュニケーション量が単位必要コミュニケーション量２ｈ／Ｗの２倍である４ｈ／Ｗ以上であるので、コミュニケーション判定部１４は、下→上の実質コミュニケーション量が不適正であると判定する。コミュニケーション判定部１４は、４Ｗの監視タイミングで下→上のコミュニケーション量が不適正であることを報知する警告情報を報知部１５を介して出力する。

【0071】

下→上の実質コミュニケーション量が多すぎる場合には、上位モジュールの設計に不備がある、下位設計者からの質問が多発しているなどの問題が推測されるので、警告情報には、そのような問題点を指摘する内容を含んでもよい。

【0072】

コミュニケーション判定部１４は、コミュニケーションの開始時期およびコミュニケーション量の適正を判定するだけでなく、コミュニケーションの密度の適正を判定してもよい。コミュニケーション判定部１４は、例えば、コミュニケーションが開始されてからコミュニケーションが実施されない期間が１Ｗを超えるとコミュニケーションの密度が低いと判定する。なお、コミュニケーションの密度が低いか否かの判定は、コミュニケーションが開始されてからコミュニケーションが実施されない期間が１Ｗを超えるか否かに限らず、例えば、コミュニケーションが開始されてからコミュニケーションが実施されない期間が２Ｗ、３Ｗを超えるか否かでもよいし、コミュニケーションが開始されてから一定期間あたりのコミュニケーションの回数が閾値以下であるか否かでもよい。

【0073】

図１７の例では、上→下のコミュニケーションが３Ｗに開始されてから、４Ｗの監視タイミングにおける実質コミュニケーション量が０ｈ／Ｗであることから、コミュニケーション判定部１４は、コミュニケーションが開始されてからコミュニケーションが実施されない期間が１Ｗを超えるのでコミュニケーションの密度が低いと判定し、４Ｗの監視タイミングで上→下のコミュニケーションの密度が不適正であることを報知する警告情報を報知部１５を介して出力する。

【0074】

図１８の例では、下→上のコミュニケーションが４Ｗに開始されてから、５Ｗの監視タイミングにおける実質コミュニケーション量が０ｈ／Ｗであることから、コミュニケーション判定部１４は、コミュニケーションが開始されてからコミュニケーションが実施されない期間が１Ｗを超えるのでコミュニケーションの密度が低いと判定し、５Ｗの監視タイミングで下→上のコミュニケーションの密度が不適正であることを報知する警告情報を報知部１５を介して出力する。

【0075】

コミュニケーションの密度が低い場合には、担当者が十分な設計時間を確保できていない、事前設計が曖昧で仕様変更が発生している、インターフェースの定義が曖昧で追加の情報が入るたびに更新を行っているといった問題が推測されるので、警告情報には、そのような問題点を指摘する内容を含んでもよい。

【0076】

ここで、設計品質監視装置１が実行する処理の流れについて、図１９～図２３を用いて説明する。図１９に示す結合度情報生成処理は、設計品質監視装置１に事前設計情報が入力されたときに開始する。設計品質監視装置１の担当者登録部１１の結合度情報生成部１１１は、事前設計情報にて定義されたインターフェースの複雑度と関数の単位時間あたりの呼び出し回数とに基づいて、関数分布図を用いて、モジュール間で使用される関数についてそれぞれランク値を求める（ステップＳ１１）。

【0077】

図２に示すように、結合度情報生成部１１１は、事前設計情報にて定義されたモジュール間で使用される関数を関数分布図にプロットして、各ランク値を求める。図２の例では、ランク０の関数が１個、ランク１の関数が１個、ランク２の関数が３個、ランク３の関数が１個、ランク４の関数が１個、ランク５の関数が２個ある。関数分布図のランク値は、プロジェクトごとに設定される。

【0078】

図１９に戻り、結合度情報生成部１１１は、各ランク値に属する関数の個数に該ランク値に対応する係数を乗算して合計したランクポイントを算出する（ステップＳ１２）。各ランク値に対応する係数は、プロジェクトごとに設定される。図３の例では、ランク０～５に対応する係数はそれぞれ０～５であって、ランクポイントは２４である。

【0079】

図１９に戻り、結合度情報生成部１１１は、算出したランクポイントに基づいて、モジュール間の相関の強さを表すレベルを決定する（ステップＳ１３）。例えば、図３に示すように、ランクポイントが２４であった場合、結合度情報生成部１１１は、図４に示すような表を参照して、モジュール間の相関の強さをレベル２と決定する。

【0080】

図１９に戻り、結合度情報生成部１１１は、モジュール間の相関の強さをモジュールの担当者間のコミュニケーションの結合度に変換する（ステップＳ１４）。例えば、モジュール間の相関の強さがレベル２であった場合、上位モジュールの担当者から下位モジュールの担当者へのコミュニケーションの結合度は、レベル２に変換係数ｃ１（＝１）を乗算して結合度２とする。一方、下位モジュールの担当者から上位モジュールの担当者へのコミュニケーションの結合度は、レベル２に変換係数ｃ２（＝０．５）を乗算して結合度１とする。なお、変換係数を用いずにモジュール間の相関の強さをそのままモジュールの担当者間のコミュニケーションの結合度にする場合には、ステップＳ１４は省略する。

【0081】

結合度情報生成部１１１は、モジュールの担当者間のコミュニケーションの結合度を示す結合度情報を生成する（ステップＳ１５）。結合度情報生成部１１１は、生成した結合度情報を記憶部１３に記憶させ（ステップＳ１６）、処理を終了する。

【0082】

図２０に示す属性情報生成処理は、設計品質監視装置１に担当者情報が入力されたときに開始する。設計品質監視装置１の担当者登録部１１の属性情報生成部１１２は、担当者情報が入力されると、担当者情報が示す各モジュールの担当者のスキルを入力可能な入力画面を表示する（ステップＳ２１）。属性情報生成部１１２は、管理者によって入力画面に各モジュールの担当者のスキルが入力されたか否かを判定する（ステップＳ２２）。入力画面に各モジュールの担当者のスキルが入力されていない場合（ステップＳ２２；ＮＯ）、属性情報生成部１１２は、ステップＳ２２を繰り返してスキルの入力を待機する。

【0083】

入力画面に各モジュールの担当者のスキルが入力された場合（ステップＳ２２；ＹＥＳ）、属性情報生成部１１２は、各モジュールの担当者のスキルを示す属性情報を生成する（ステップＳ２３）。属性情報生成部１１２は、生成した属性情報を記憶部１３に記憶させ（ステップＳ２４）、処理を終了する。なお、ステップＳ２２でスキルを入力するのは管理者でなくてもよい。

【0084】

図２１に示すコミュニケーションロギング処理は、開発期間が始まったときに開始する。コミュニケーションロギング部１２１は、各作業端末のログツールからコミュニケーションログを受信したか否かを判定する（ステップＳ３１）。コミュニケーションログを受信していない場合（ステップ３１；ＮＯ）、処理はステップＳ３５に移行する。コミュニケーションログを受信した場合（ステップ３１；ＹＥＳ）、コミュニケーションロギング部１２１は、担当者情報が入力されたか否かを判定する（ステップＳ３２）。担当者情報が入力されていない場合（ステップ３２；ＮＯ）、処理はステップＳ３５に移行する。

【0085】

担当者情報が入力された場合（ステップ３２；ＹＥＳ）、コミュニケーションロギング部１２１は、受信したコミュニケーションログと入力された担当者情報とに基づいて、コミュニケーションの量、コミュニケーションの主体および客体、ならびに、コミュニケーションの方向を示すコミュニケーションログ情報を生成し（ステップＳ３３）、生成した属性情報を記憶部１３に記憶させる（ステップＳ３４）。開発期間が終了していなければ（ステップＳ３５；ＮＯ）、処理はステップＳ３１に戻り、ステップＳ３１～ステップＳ３５を繰り返す。開発期間が終了すると（ステップＳ３５；ＹＥＳ）、処理は終了する。

【0086】

図２２に示すコミュニケーション取得処理は、開発期間が始まったときに開始する。コミュニケーション取得部１２２は、コミュニケーションの結果が入力されたか否かを判定する（ステップＳ４１）。コミュニケーションの結果が入力されていない場合（ステップ４１；ＮＯ）、処理はステップＳ４５に移行する。コミュニケーションの結果が入力された場合（ステップ４１；ＹＥＳ）、コミュニケーション取得部１２２は、担当者情報が入力されたか否かを判定する（ステップＳ４２）。担当者情報が入力されていない場合（ステップ４２；ＮＯ）、処理はステップＳ４５に移行する。

【0087】

担当者情報が入力された場合（ステップ４２；ＹＥＳ）、コミュニケーション取得部１２２は、入力されたコミュニケーションの結果と入力された担当者情報とに基づいて、コミュニケーションの量、コミュニケーションの主体および客体、ならびに、コミュニケーションの方向を示すコミュニケーション結果情報を生成し（ステップＳ４３）、生成した属性情報を記憶部１３に記憶させる（ステップＳ４４）。開発期間が終了していなければ（ステップＳ４５；ＮＯ）、処理はステップＳ４１に戻り、ステップＳ４１～ステップＳ４５を繰り返す。開発期間が終了すると（ステップＳ４５；ＹＥＳ）、処理は終了する。

【0088】

図２３に示すコミュニケーション判定処理は、開発期間が始まったときに開始する。コミュニケーション判定部１４は、開発期間／Ｎが経過したか否かを判定する（ステップＳ５１）。開発期間／Ｎが経過していない場合（ステップＳ５１；ＮＯ）、処理はステップＳ６６に移行する。開発期間／Ｎが経過した場合（ステップＳ５１；ＹＥＳ）、コミュニケーション判定部１４は、まず、必要コミュニケーション量を算出するために、記憶部１３から結合度情報を取得する（ステップＳ５２）。

【0089】

図５に示す結合度情報の例では、コミュニケーションの主体の担当者から客体の担当者へのコミュニケーションの結合度を表で表している。図６のイメージ図では、矢印の太さは担当者間のコミュニケーションの結合度を表しており、矢印が太いほどコミュニケーションの結合度が高いことを表している。矢印の元がコミュニケーションの主体の担当者であり、矢印の先がコミュニケーションの客体の担当者である。

【0090】

図２３に戻り、コミュニケーション判定部１４は、担当者のスキルによって必要コミュニケーション量を補正するために、記憶部１３から属性情報を取得する（ステップＳ５３）。コミュニケーション判定部１４は、属性情報に基づいて、スキル係数ｓを決定する（ステップＳ５４）。

【0091】

図７に示すスキル係数ｓを決定する算出表の例では、担当者のスキルを有識者であるか非有識者であるかで表現しており、有識者の参加が少なくなるほどスキル係数ｓが高くなっている。

【0092】

図２３に戻り、コミュニケーション判定部１４は、取得した結合度情報が示す結合度と、スキル係数ｓと、予め決められた係数ｃと上記の数１とを用いて、必要コミュニケーション量を算出する（ステップＳ５５）。なお、モジュールの担当者間のコミュニケーションの結合度がコミュニケーションの方向によって異なる場合には、ステップＳ５５で必要コミュニケーション量をコミュニケーションの方向ごとに算出する。

【0093】

コミュニケーション判定部１４は、記憶部１３からコミュニケーションログ情報およびコミュニケーション結果情報を取得する（ステップＳ５６）。コミュニケーション判定部１４は、コミュニケーションログ情報に、文字数のコミュニケーション量が含まれるか否かを判定する（ステップＳ５７）。文字数のコミュニケーション量が含まれない場合には（ステップＳ５７；ＮＯ）、処理はステップＳ６０に移行する。

【0094】

文字数のコミュニケーション量が含まれる場合には（ステップＳ５７；ＹＥＳ）、コミュニケーション判定部１４は、必要コミュニケーション量の単位である時間単位に統一するために、変換係数ｔと上記の数２とを用いて、文字数のコミュニケーション量を時間のコミュニケーション量に変換する（ステップＳ５８）。また、コミュニケーション種別によって情報の伝達効率が異なるため、コミュニケーション種別ごとに予め補正係数ｈが設定されている。コミュニケーション判定部１４は、補正係数ｈと上記の数３を用いて、時間のコミュニケーション量から実質コミュニケーション量を算出する（ステップＳ５９）。

【0095】

図８に示す変換係数ｔおよび補正係数ｈを決定する算出表の例では、コミュニケーション種別が直接対話である場合は、コミュニケーション量の単位が時間（分）であって、時間単位に変換する必要がないので、変換係数ｔは１である。また直接対話の情報の伝達効率を基準として、補正係数ｈは１に設定されている。コミュニケーション種別がチャットである場合は、コミュニケーション量の単位が文字数であって、時間単位に変換する必要があるので、変換係数ｔは１００に設定されており、補正係数ｈは０．６に設定されている。つまり、チャットでの１００文字のやり取りと直接対話での０．６分のやり取りとが同等のコミュニケーション量であるとみなしている。

【0096】

図２３に戻り、算出対象モジュールが製品のモジュールの階層の中でどの階層に位置するのかによってコミュニケーションを開始すべき時期が異なるため、コミュニケーション判定部１４は、記憶部１３が記憶する事前設計情報から製品のモジュールの階層数Ｘと算出対象モジュールの階層Ｙとを取得する。なお最上位の階層を０とする。コミュニケーション判定部１４は、上記の数４を用いて、算出対象モジュールの階層に基づくコミュニケーションの開始時期ＸＴを算出する（ステップＳ６０）。

【0097】

また、一般的に、モジュールの開発規模が大きいほど設計に時間がかかるため、各モジュールの開発規模比率によってコミュニケーションを開始すべき時期が異なる。このため、コミュニケーション判定部１４は、記憶部１３が記憶する事前設計情報から製品の各モジュールの開発規模比率ｒを取得する。コミュニケーション判定部１４は、開発期間ＤＴを上位モジュールから順に開発規模比率ｒに従って分割する。コミュニケーション判定部１４は、上記の数５を用いて、各モジュールの開発規模比率に基づく算出対象モジュールのコミュニケーションの開始時期ＲＴを算出する（ステップＳ６１）。コミュニケーション判定部１４は、開始時期ＸＴと開始時期ＲＴとの早い方をコミュニケーションの開始適正時期とする（ステップＳ６２）。

【0098】

図９に示すコミュニケーションの開始適正時期の算出例では、製品のモジュールの階層数Ｘ＝４である。算出対象モジュールの階層Ｙ＝３とすると、算出対象モジュールの階層に基づくコミュニケーションの開始時期ＸＴは、(開発期間ＤＴ ÷ 階層数４)×階層３となり、開発期間ＤＴの７５％が経過した時点となる。各モジュールの開発規模比率ｒ（ｒ０＝２０，ｒ１＝２０，ｒ２＝４０，ｒ３＝２０）に基づく算出対象モジュールのコミュニケーションの開始時期ＲＴは、(開発期間ＤＴ ÷１００) × (ｒ０＋ｒ１＋ｒ２)となり、開発期間ＤＴの８０％が経過した時点となる。コミュニケーション判定部１４は、開始時期ＸＴと開始時期ＲＴとの早い方、つまり、開始時期ＸＴ（開発期間ＤＴの７５％が経過した時点）をコミュニケーションの開始適正時期とする。一方、算出対象モジュールの階層Ｙ＝１の場合および階層Ｙ＝２のモジュールの場合は、開始時期ＸＴより開始時期ＲＴの方が早いので、開始時期ＲＴをコミュニケーションの開始適正時期とする。

【0099】

図２３に戻り、コミュニケーション判定部１４は、記憶部１３から取得したコミュニケーションログ情報およびコミュニケーション結果情報に基づいて、判定対象モジュールの担当者間の上→下のコミュニケーションの開始時期および下→上のコミュニケーションの開始時期を特定し、開始適正時期に基づいて、判定対象モジュールのコミュニケーションの開始時期が適正であるか否かを判定する（ステップＳ６３）。

【0100】

コミュニケーションの開始時期が適正でない場合（ステップＳ６３；ＮＯ）、コミュニケーション判定部１４は、報知部１５にコミュニケーションの開始時期が不適正であることを報知する警告情報を報知部１５を介して出力する（ステップＳ６５）。コミュニケーションの開始時期が不適正であることを報知する警告情報が出力されることで、管理者はモジュールの担当者間のコミュニケーションの開始時期が不適正であることを知ることができる。

【0101】

コミュニケーションの開始時期が適正である場合（ステップＳ６３；ＹＥＳ）、コミュニケーション判定部１４は、判定対象モジュールの担当者間の実質コミュニケーション量と必要コミュニケーション量とに基づいて、コミュニケーション量が適正であるか否かを判定する（ステップＳ６４）。コミュニケーション量が適正である場合（ステップＳ６４；ＹＥＳ）、処理はステップＳ６６に移行する。コミュニケーション量が適正でない場合（ステップＳ６４；ＮＯ）、コミュニケーション判定部１４は、報知部１５にコミュニケーション量が不適正であることを報知する警告情報を報知部１５を介して出力する（ステップＳ６５）。コミュニケーション量が不適正であることを報知する警告情報が出力されることで、管理者はモジュールの担当者間のコミュニケーション量が不適正であることを知ることができる。

【0102】

例えば、図１０に示すコミュニケーション例では、開始適正時期３Ｗに上→下のコミュニケーションが開始されており、開始適正時期４Ｗに下→上のコミュニケーションが開始されているので、コミュニケーション判定部１４は、ステップＳ６３でコミュニケーションの開始時期が適正であると判定する。図１１に示すコミュニケーション例では、上→下のコミュニケーションの開始が開始適正時期３Ｗよりも遅くなっているので、コミュニケーション判定部１４は、ステップＳ６３で上→下のコミュニケーションの開始時期が不適正であると判定する。コミュニケーション判定部１４は、ステップＳ６５で上→下のコミュニケーションの開始時期が不適正であることを報知する警告情報を報知部１５を介して出力する。図１２に示すコミュニケーション例では、上→下のコミュニケーションの開始時期が３Ｗであるので適正であるが、下→上のコミュニケーションの開始時期が開始適正時期４Ｗよりも遅くなっているので、コミュニケーション判定部１４は、ステップＳ６３で下→上のコミュニケーションの開始時期が不適正であると判定する。コミュニケーション判定部１４は、ステップＳ６５で下→上のコミュニケーションの開始時期が不適正であることを報知する警告情報を報知部１５を介して出力する。

【0103】

図１３の例では、上→下のコミュニケーションの開始時期である３Ｗの監視タイミングでは、実質コミュニケーション量が単位必要コミュニケーション量２ｈ／Ｗを満たしているので、コミュニケーション判定部１４は、ステップＳ６４で上→下のコミュニケーション量が適正であると判定する。４Ｗの監視タイミングでは、必要コミュニケーション残量は８ｈで残りの上→下のコミュニケーションをすべき期間は４Ｗであるので、単位必要コミュニケーション量２ｈ／Ｗである。４Ｗにおける実質コミュニケーション量はこれを満たしていないので、コミュニケーション判定部１４は、ステップＳ６４で上→下の実質コミュニケーション量が不適正であると判定する。コミュニケーション判定部１４は、ステップＳ６５で上→下のコミュニケーション量が不適正であることを報知する警告情報を報知部１５を介して出力する。

【0104】

図１４の例では、下→上のコミュニケーションの開始時期である４Ｗの監視タイミングで、実質コミュニケーション量が単位必要コミュニケーション量２ｈ／Ｗを満たしていないので、コミュニケーション判定部１４は、ステップＳ６４で下→上の実質コミュニケーション量が不適正であると判定する。コミュニケーション判定部１４は、ステップＳ６５で下→上のコミュニケーション量が不適正であることを報知する警告情報を報知部１５を介して出力する。
図１５の例では、３Ｗの監視タイミングにおける上→下の実質コミュニケーション量が単位必要コミュニケーション量２ｈ／Ｗの３倍である６ｈ／Ｗ未満であるので、コミュニケーション判定部１４は、上→下の実質コミュニケーション量が適正であると判定する。４Ｗの監視タイミングでは、６ｈ／Ｗ以上であるので、ステップＳ６４で上→下の実質コミュニケーション量が不適正であると判定する。コミュニケーション判定部１４は、ステップＳ６５で上→下のコミュニケーション量が不適正であることを報知する警告情報を報知部１５を介して出力する。

【0105】

図１６の例では、４Ｗの監視タイミングにおける下→上の実質コミュニケーション量が単位必要コミュニケーション量２ｈ／Ｗの２倍である４ｈ／Ｗ以上であるので、コミュニケーション判定部１４は、ステップＳ６４で下→上の実質コミュニケーション量が不適正であると判定する。コミュニケーション判定部１４は、ステップＳ６５で下→上のコミュニケーション量が不適正であることを報知する警告情報を報知部１５を介して出力する。

【0106】

図２３に戻り、開発期間が終了していなければ（ステップＳ６６；ＮＯ）、処理はステップＳ５１に戻り、ステップＳ５１～ステップＳ６６を繰り返す。開発期間が終了すると（ステップＳ６６；ＹＥＳ）、処理は終了する。

【0107】

なお、コミュニケーションの開始時期およびコミュニケーション量の適正を判定するだけでなく、コミュニケーションの密度の適正を判定する場合には、コミュニケーション判定部１４は、例えば、ステップＳ６４がＹＥＳの場合に、コミュニケーションの密度が低いか否かを判定するステップＳ６４’（図示せず）を実行する。コミュニケーションの密度が低くない場合（ステップＳ６４’；ＮＯ）、処理はステップＳ６６に移行する。コミュニケーションの密度が低い場合には（ステップＳ６４’；ＹＥＳ）、コミュニケーション判定部１４は、ステップＳ６５でコミュニケーションの密度が低いことを報知する警告情報を報知部１５を介して出力する。

【0108】

図１７の例では、上→下のコミュニケーションが３Ｗに開始されてから、４Ｗの監視タイミングにおける実質コミュニケーション量が０ｈ／Ｗであることから、コミュニケーションが開始されてからコミュニケーションが実施されない期間が１Ｗを超えるので、コミュニケーション判定部１４はステップＳ６４’でコミュニケーションの密度が低いと判定し、ステップＳ６５で上→下のコミュニケーションの密度が不適正であることを報知する警告情報を報知部１５を介して出力する。

【0109】

図１８の例では、下→上のコミュニケーションが４Ｗに開始されてから、５Ｗの監視タイミングにおける実質コミュニケーション量が０ｈ／Ｗであることから、コミュニケーションが開始されてからコミュニケーションが実施されない期間が１Ｗを超えるので、コミュニケーション判定部１４はステップＳ６４’でコミュニケーションの密度が低いと判定し、ステップＳ６５で下→上のコミュニケーションの密度が不適正であることを報知する警告情報を報知部１５を介して出力する。

【0110】

実施の形態に係る設計品質監視装置１によれば、モジュール型製品の設計において、モジュールの担当者間のコミュニケーションが適正であるか否かの判定結果を出力することで、管理者はモジュールの担当者間のコミュニケーションが不適正であることを知ることができる。これにより、管理者は、モジュールの担当者にコミュニケーションの改善を促し、環境を整えることで、モジュールの設計品質の低下を防ぐことができる。

【0111】

設計品質監視装置１のハードウェア構成について図２４を用いて説明する。図２４に示すように、設計品質監視装置１は、一時記憶部１０１、記憶部１０２、計算部１０３、入力部１０４、送受信部１０５および表示部１０６を備える。一時記憶部１０１、記憶部１０２、入力部１０４、送受信部１０５および表示部１０６はいずれもＢＵＳを介して計算部１０３に接続されている。

【0112】

計算部１０３は、例えばＣＰＵ（Central Processing Unit）である。計算部１０３は、記憶部１０２に記憶されている制御プログラムに従って、担当者登録部１１、コミュニケーション登録部１２およびコミュニケーション判定部１４の処理を実行する。

【0113】

一時記憶部１０１は、例えばＲＡＭ（Random-Access Memory）である。一時記憶部１０１は、記憶部１０２に記憶されている制御プログラムをロードし、計算部１０３の作業領域として用いられる。

【0114】

記憶部１０２は、フラッシュメモリ、ハードディスク、ＤＶＤ－ＲＡＭ（Digital Versatile Disc - Random Access Memory）、ＤＶＤ－ＲＷ（Digital Versatile Disc - ReWritable）などの不揮発性メモリである。記憶部１０２は、設計品質監視装置１の処理を計算部１０３に行わせるためのプログラムを予め記憶し、また、計算部１０３の指示に従って、このプログラムが記憶するデータを計算部１０３に供給し、計算部１０３から供給されたデータを記憶する。記憶部１３は、記憶部１０２に構成される。

【0115】

入力部１０４は、キーボード、ポインティングデバイス、音声入力機器などの入力装置と、入力装置をＢＵＳに接続するインターフェース装置である。入力部１０４を介して、管理者が入力した情報が計算部１０３に供給される。入力部１０４は、結合度情報生成部１１１、属性情報生成部１１２およびコミュニケーション取得部１２２として機能する。

【0116】

送受信部１０５は、ネットワークに接続する網終端装置または無線通信装置、およびそれらと接続するシリアルインターフェースまたはＬＡＮ（Local Area Network）インターフェースである。送受信部１０５は、コミュニケーション取得部１２２として機能する。コミュニケーションの結果が外部の端末からコミュニケーション取得部１２２に送信される構成では、送受信部１０５は、コミュニケーション取得部１２２として機能する。報知部１５が警告情報を管理者が使用する端末に送信する構成では、送受信部１０５は、報知部１５として機能する。

【0117】

表示部１０６は、ＬＣＤ（Liquid Crystal Display）、有機ＥＬ（electroluminescence）ディスプレイなどの表示装置である。属性情報生成部１１２が各モジュールの担当者のスキルの入力画面を表示する構成では、表示部１０６は、属性情報生成部１１２として機能する。報知部１５が警告情報を画面表示する構成では、表示部１０６は、報知部１５として機能する。

【0118】

図１に示す設計品質監視装置１の担当者登録部１１、コミュニケーション登録部１２、記憶部１３、コミュニケーション判定部１４および報知部１５の処理は、制御プログラムが、一時記憶部１０１、計算部１０３、記憶部１０２、入力部１０４、送受信部１０５および表示部１０６などを資源として用いて処理することによって実行する。

【0119】

その他、前記のハードウェア構成およびフローチャートは一例であり、任意に変更および修正が可能である。

【0120】

計算部１０３、一時記憶部１０１、記憶部１０２、入力部１０４、送受信部１０５、表示部１０６などの設計品質監視装置１の処理を行う中心となる部分は、専用のシステムによらず、通常のコンピュータシステムを用いて実現可能である。例えば、前記の動作を実行するためのコンピュータプログラムを、フレキシブルディスク、ＣＤ－ＲＯＭ（Compact Disc - Read Only Memory）、ＤＶＤ－ＲＯＭ（Digital Versatile Disc - Read Only Memory）などのコンピュータが読み取り可能な記録媒体に格納して配布し、当該コンピュータプログラムをコンピュータにインストールすることにより、前記の処理を実行する設計品質監視装置１を構成してもよい。また、インターネットに代表される通信ネットワーク上のサーバ装置が有する記憶装置に当該コンピュータプログラムを格納しておき、通常のコンピュータシステムがダウンロードすることで設計品質監視装置１を構成してもよい。

【0121】

また、設計品質監視装置１の機能を、ＯＳ（Operating System）とアプリケーションプログラムの分担、またはＯＳとアプリケーションプログラムとの協働により実現する場合などには、アプリケーションプログラム部分のみを記録媒体、記憶装置に格納してもよい。

【0122】

また、輸送波にコンピュータプログラムを重畳し、通信ネットワークを介して提供することも可能である。例えば、通信ネットワーク上の掲示板（BBS, Bulletin Board System）に前記コンピュータプログラムを掲示し、通信ネットワークを介して前記コンピュータプログラムを提供してもよい。そして、このコンピュータプログラムを起動し、ＯＳの制御下で、他のアプリケーションプログラムと同様に実行することにより、前記の処理を実行できる構成にしてもよい。

【0123】

上記の実施の形態では、ソフトウェアのモジュール型製品を開発するプロジェクトにおいて、モジュールの担当者間のコミュニケーションが適正か否かでモジュールの設計品質を監視する例について説明したが、これに限らず、ハードウェアのモジュール型製品を開発するプロジェクトにおいて、モジュールの担当者間のコミュニケーションが適正か否かでモジュールの設計品質を監視してもよい。この場合、モジュール間の相関の強さは、例えば、上位モジュールまたは下位モジュールの汎用性に基づいて算出してもよいし、過去に上位モジュールおよび下位モジュールが採用された実績数に基づいて算出してもよい。

【0124】

上記の実施の形態では、コミュニケーションロギング部１２１は、各作業端末にインストールされたログツールからコミュニケーションログを受信していたが、コミュニケーションロギング部１２１が各作業端末のコミュニケーションアプリからコミュニケーションログを収集してもよい。

【0125】

上記の実施の形態では、コミュニケーション判定部１４は、記憶部１３から取得したコミュニケーションログ情報およびコミュニケーション結果情報と必要コミュニケーション量とに基づいて、各種条件を満たすか否かで実質コミュニケーション量が適正であるか否かを判定しているが、上記で挙げた条件は例示である。コミュニケーション判定部１４は、必要コミュニケーション量に基づいて設定された範囲内に実質コミュニケーション量が収まっているか否かでコミュニケーション量が適正であるか否かを判定すればよい。

【0126】

上記の実施の形態では、事前設計が１回しか行われないが、事前設計情報は変更されてもよい。この場合、結合度情報生成部１１１は、変更された事前設計情報に基づいて、改めて結合度情報を生成する。コミュニケーション判定部１４も、変更された事前設計情報に基づいて、モジュールの担当者間のコミュニケーションが適正か否かを判定する。

【0127】

上記の実施の形態では、属性情報生成部１１２は各モジュールの担当者のスキルの入力を受け付けるが、スキルだけでなく、例えば、業務経験の年数および業務を行う場所の入力を受け付けてもよい。この場合、属性情報に、各モジュールの担当者の業務経験の年数および業務を行う場所を含む。あるいは、担当者情報に業務経験の年数および業務を行う場所が含まれていてもよい。この場合、属性情報生成部１１２は、入力された担当者情報を属性情報として記憶部１３に記憶させる。

【0128】

コミュニケーション判定部１４は、記憶部１３から属性情報を取得する。担当者のスキル、業務経験の年数および業務を行う場所による必要コミュニケーション量の補正を行う。コミュニケーション判定部１４は、属性情報に基づいて、スキル係数ｓ、業務経験係数ｅ、および、業務場所係数ｐを決定する。例えば、業務経験の年数が長い担当者との関係であれば、コミュニケーションの量が増加しないため、業務経験係数ｅは小さく設定する。逆に、業務経験の年数が短い担当者との関係であれば、コミュニケーションの量が増加するため、業務経験係数ｅは大きく設定する。例えば、業務を行う場所が同じ担当者同士の関係であれば、共通認識が多く、コミュニケーションの量が増加しないため、業務場所係数ｐは小さく設定する。逆に、業務を行う場所が遠い（例えば海外と国内）担当者同士の関係であれば、共通認識が少なく、コミュニケーションの量が増加するため、業務場所係数ｐは大きく設定する。コミュニケーション判定部１４は、取得した結合度情報が示す結合度と、スキル係数ｓと、業務経験係数ｅと、業務場所係数ｐと、予め決められた係数ｃと以下の数６とを用いて、必要コミュニケーション量を算出する。

【0129】

（数６） 結合度×スキル係数ｓ×業務経験係数ｅ×業務場所係数ｐ×係数ｃ= 必要コミュニケーション量

【0130】

なお、スキル係数ｓ、業務経験係数ｅおよび業務場所係数ｐのうち、どの係数を用いるかは管理者が設定可能にしてもよいし、コミュニケーションの増減に寄与するその他の属性の係数を設定してもよい。

【符号の説明】

【0131】

１ 設計品質監視装置、１１ 担当者登録部、１２ コミュニケーション登録部、１３ 記憶部、１４ コミュニケーション判定部、１５ 報知部、１０１ 一時記憶部、１０２ 記憶部、１０３ 計算部、１０４ 入力部、１０５ 送受信部、１０６ 表示部、１１１ 結合度情報生成部、１１２ 属性情報生成部、１２１ コミュニケーションロギング部、１２２ コミュニケーション取得部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】