特開 2024-151811 ナレッジ蓄積・活用支援システム、ナレッジ蓄積・活用支援方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024151811

(43)【公開日】2024-10-25

(54)【発明の名称】ナレッジ蓄積・活用支援システム、ナレッジ蓄積・活用支援方法

(51)【国際特許分類】

   G06F 8/36 20180101AFI20241018BHJP

   G06Q 50/10 20120101ALI20241018BHJP

【ＦＩ】

G06F8/36

G06Q50/10

【審査請求】未請求

【請求項の数】13

【出願形態】ＯＬ

(21)【出願番号】P 2023065533

(22)【出願日】2023-04-13

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110000350

【氏名又は名称】ポレール弁理士法人

(72)【発明者】

【氏名】西田 武央

(72)【発明者】

【氏名】小牧 大輔

(72)【発明者】

【氏名】野村 健一郎

(72)【発明者】

【氏名】相川 慎

【テーマコード（参考）】

5B376

5L049

5L050

【Ｆターム（参考）】

5B376BC07

5B376BC13

5B376BC14

5B376BC23

5B376BC38

5B376BC80

5L049CC11

5L050CC11

(57)【要約】      （修正有）

【課題】保有しているナレッジを効果的に活用し、顧客のニーズにマッチしたソリューションを迅速に構成することができるナレッジ蓄積・活用支援システム及び方法を提供する。
【解決手段】ナレッジ蓄積・活用支援システムは、少なくとも顧客ニーズ、顧客提案及びモジュールを含む複数の階層毎に要素をノード、各層間のノードの関連性をリレーションとして管理するモジュールパス保管部と、モジュール間の入出力関係を登録したモジュール入出力関係保管部と、を備える。モジュールパス保管部に登録されるモジュールと、モジュール入出力関係保管部に登録されるモジュールとは、一対一に対応する。モジュールとは、１つ以上の機能を持つソフトウェアモジュールだけではなく、サーバや制御対象などのハードウェア、顧客、顧客管理のシステム、顧客ニーズを満たすための目的関数やデータなどのソリューションの流れを示す一連のものをモジュールとして含む。
【選択図】図１

【特許請求の範囲】

【請求項1】

顧客ニーズとソリューション、及び前記ソリューションとモジュールの関係性を登録したモジュールパス保管部と、
前記モジュール間の入出力関係を登録したモジュール入出力関係保管部と、を備え、
前記モジュールパス保管部に登録されるモジュールと、前記モジュール入出力関係保管部に登録されるモジュールが一対一対応することを特徴とするナレッジ蓄積・活用支援システム。

【請求項2】

請求項１に記載のナレッジ蓄積・活用支援システムであって、
参照部をさらに備え、
前記モジュールパス保管部に登録された全ノードを層毎に表示し、上下階層のノード間の関係の有無を表示することを特徴とするナレッジ蓄積・活用支援システム。

【請求項3】

請求項２に記載のナレッジ蓄積・活用支援システムであって、
前記参照部は、前記モジュール入出力関係保管部に登録されたモジュールに関するノード間の入出力の内容を表示することを特徴とするナレッジ蓄積・活用支援システム。

【請求項4】

請求項３に記載のナレッジ蓄積・活用支援システムであって、
前記参照部は、キーワード検索または、ユーザーによるノードの選択、ノードが持つグルーピングの属性の選択、ノードが持つタグの属性の選択のいずれかにより、表示する対象を絞り込むことを特徴とするナレッジ蓄積・活用支援システム。

【請求項5】

請求項１に記載のナレッジ蓄積・活用支援システムであって、
整合性管理部をさらに備え、
前記整合性管理部は、前記モジュールパス保管部に登録されたパス、前記モジュール入出力関係保管部に登録されたモジュール間の入出力関係、前記モジュールパス保管部及び前記モジュール入出力関係保管部にそれぞれ登録されたモジュールの対応関係を比較し、いずれかに不足がある場合は警告を出力することを特徴とするナレッジ蓄積・活用支援システム。

【請求項6】

請求項１に記載のナレッジ蓄積・活用支援システムであって、
前記モジュールパス保管部に新たなモジュールが登録されたときに、前記モジュール入出力関係保管部に当該モジュールの項目を作成することを特徴とするナレッジ蓄積・活用支援システム。

【請求項7】

請求項１に記載のナレッジ蓄積・活用支援システムであって、
前記モジュール入出力関係保管部に新たなモジュール項目が登録されたときに、前記モジュールパス保管部のモジュール層に当該モジュールのノードを作成することを特徴とするナレッジ蓄積・活用支援システム。

【請求項8】

請求項１に記載のナレッジ蓄積・活用支援システムであって、
前記モジュールパス保管部と前記モジュール入出力関係保管部で管理されるデータを１つのデータとして統合し、同一のデータ構造で管理することを特徴とするナレッジ蓄積・活用支援システム。

【請求項9】

以下のステップを含むナレッジ蓄積・活用支援方法；
（ａ）ソリューションを構成する標準化されたモジュールを作成するステップ、
（ｂ）前記（ａ）ステップで作成したモジュール間の入出力関係を登録するステップ、
（ｃ）顧客ニーズとソリューション、及び前記モジュールの関係性をパスとして登録するステップ、
（ｄ）前記パスを参照することにより顧客に適したソリューション及びモジュールを特定するステップ。

【請求項10】

請求項９に記載のナレッジ蓄積・活用支援方法であって、
（ｅ）前記（ｂ）ステップにおいて登録された全ノードを層毎に表示し、上下階層のノード間の関係の有無を表示するステップ、
をさらに有するナレッジ蓄積・活用支援方法。

【請求項11】

請求項１０に記載のナレッジ蓄積・活用支援方法であって、
前記（ｅ）ステップにおいて、さらに、登録されたモジュールに関するノード間の入出力の内容を表示するナレッジ蓄積・活用支援方法。

【請求項12】

請求項１１に記載のナレッジ蓄積・活用支援方法であって、
（ｆ）キーワード検索または、ユーザーによるノードの選択、ノードが持つグルーピングの属性の選択、ノードが持つタグの属性の選択のいずれかにより、表示する対象を絞り込むステップ、
をさらに有するナレッジ蓄積・活用支援方法。

【請求項13】

請求項９に記載のナレッジ蓄積・活用支援方法であって、
（ｇ）前記（ｂ）ステップ及び前記（ｃ）ステップにおいて登録されたパス、モジュール間の入出力関係、モジュールの対応関係を比較し、いずれかに不足がある場合は警告を出力するステップ、
をさらに有するナレッジ蓄積・活用支援方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、業務支援システムの構成とその方法に係り、特に、ソリューションビジネスにおけるナレッジ蓄積・活用支援システム及びナレッジ蓄積・活用支援方法に適用して有効な技術に関する。

【背景技術】

【0002】

顧客が抱える問題や課題を解決することを目的として製品やサービスを提供するソリューションビジネスにおいては、低コストで迅速なソリューションの提供が求められる。また、解決すべき問題や課題は多岐に渡り、どのような課題をどのように解決するのか、顧客のニーズにマッチした最適なソリューションの提供も重要な課題である。

【0003】

本技術分野の背景技術として、例えば、特許文献１のような技術がある。特許文献１には、「遠隔地に配置された端末装置において、サービス機能を構成するソフトウェアモジュールのダウンロードおよびアップデートを迅速に行うことを可能にするためのソフトウェア更新システム」が開示されている。

【0004】

また、特許文献２には、「ソリューションサービス契約をユーザのニーズに合致したものに内容選択可能なソリューション契約支援システム」が開示されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０２１－０２６２５２号公報

【特許文献2】特開２００５－２２７９０５号公報

【発明の概要】

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

【0006】

ところで、顧客の困りごとに対して、半完成品を組み合わせて提供するソリューションビジネスや、ソリューションビジネスのアップグレードにおいては、ある顧客のニーズが別の顧客には当てはまらないケースがあるため、より多くの顧客に対してソリューションを使いまわすためには、顧客のニーズを定型化する必要がある。

【0007】

また、顧客の要求は変容するため、アジャイル（迅速）にソリューションを修正していく必要が生じる。このときに、顧客のニーズを把握するだけでは対応できず、ソリューションを構成する、半完成品であるモジュール間の関係性を把握する必要がある。

【0008】

上記特許文献１では、モジュールの依存関係の有無とモジュールのダウンロード順序、及びバージョンが依存関係データベースに保持されているが、モジュール間の入出力関係を保持することが想定されていない。そのため、ソリューションの更新時に、アップデートするモジュールとその順序を特定できるといった効果に留まる。

【0009】

また、上記特許文献２では、ソリューションの価格見積もりのためにソリューションが細分化され、モジュールと紐づけられているが、そのモジュールの入出力関係やソリューションの構造、また顧客ニーズとソリューション、モジュールの関係性の保持が想定されていない。そのため、既存のソリューションに対応できるモジュールを特定できるといった効果に留まる。

【0010】

そこで、本発明の目的は、保有しているナレッジを効果的に活用し、顧客のニーズにマッチしたソリューションを迅速に構成することができるナレッジ蓄積・活用支援システム及びナレッジ蓄積・活用支援方法を提供することにある。

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

【0011】

上記課題を解決するために、本発明は、顧客ニーズとソリューション、及び前記ソリューションとモジュールの関係性を登録したモジュールパス保管部と、前記モジュール間の入出力関係を登録したモジュール入出力関係保管部と、を備え、前記モジュールパス保管部に登録されるモジュールと、前記モジュール入出力関係保管部に登録されるモジュールが一対一対応することを特徴とする。

【0012】

また、本発明は、（ａ）ソリューションを構成する標準化されたモジュールを作成するステップ、（ｂ）前記（ａ）ステップで作成したモジュール間の入出力関係を登録するステップ、（ｃ）顧客ニーズとソリューション、及び前記モジュールの関係性をパスとして登録するステップ、（ｄ）前記パスを参照することにより顧客に適したソリューション及びモジュールを特定するステップ、を含むことを特徴とする。

【発明の効果】

【0013】

本発明によれば、保有しているナレッジを効果的に活用し、顧客のニーズにマッチしたソリューションを迅速に構成することができるナレッジ蓄積・活用支援システム及びナレッジ蓄積・活用支援方法を実現することができる。

【0014】

これにより、ソリューションをアジャイル（迅速）に開発し、継続的に深化させることが可能となる。

【0015】

上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

【図面の簡単な説明】

【0016】

【図1】本発明の実施例１に係るナレッジ蓄積・活用支援システムの概略構成を示すブロック図である。

【図2】図１のモジュールパス保管部１１で管理されるノードとリレーションの一例を示す図である。

【図3】本発明の実施例１に係るノードのデータ構造を示す図である。

【図4】本発明の実施例１に係る属性値のデータ構造を示す図である。

【図5A】本発明の実施例１に係るＧｒｏｕｐ属性及びＴａｇｓ属性による表示の例を示す図である。

【図5B】本発明の実施例１に係るＧｒｏｕｐ属性及びＴａｇｓ属性による表示の例を示す図である。

【図6】図１のモジュール入出力関係保管部１２で管理される入出力関係の一例を示す図である。

【図7】図６の入出力関係例から把握可能なシステム構成の一例を示す図である。

【図8】本発明の実施例１に係る入出力関係を保持するデータ構造を示す図である。

【図9】本発明の実施例１に係るＩＯ属性値のデータ構造を示す図である。

【図10】本発明の実施例１に係る入出力情報のデータ構造を示す図である。

【図11】図１の参照部１６の挙動の例を示すフローチャートである。

【図12】図１の整合性管理部１７におけるノード生成及びモジュール項目生成の挙動の例を示すフローチャートである。

【図13】本発明の実施例２に係るモジュールパス保管部１１で管理されるノードとリレーションの一例を示す図である。

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

【0017】

以下、図面を用いて本発明の実施例を説明する。なお、各図面において同一の構成については同一の符号を付し、重複する部分についてはその詳細な説明は省略する。

【実施例0018】

図１から図１２を参照して、本発明の実施例１に係るナレッジ蓄積・活用支援システム及びナレッジ蓄積・活用支援方法について説明する。

【0019】

図１は、本実施例のナレッジ蓄積・活用支援システム１の概略構成を示すブロック図である。

【0020】

図１に示すように、本実施例のナレッジ蓄積・活用支援システム１は、主要な構成として、モジュールパス保管部１１と、モジュール入出力関係保管部１２と、モジュール保管部１３と、ドキュメント保管部１４と、登録・更新部１５と、参照部１６と、整合性管理部１７とを備えている。

【0021】

なお、上記の各部は、一部又は全部を、ソフトウェアで実現してもよい。また、ハードウェアで実現する場合は、例えば、モジュールパス保管部１１とモジュール入出力関係保管部１２とモジュール保管部１３とドキュメント保管部１４を、半導体メモリやハードディスク、SSD（Solid State Drive）等の記録装置で構成し、登録・更新部１５と参照部１６と整合性管理部１７を、ＣＰＵ（Central Processing Unit：中央演算処理装置）で構成してもよい。

【0022】

モジュールパス保管部１１では、少なくとも顧客ニーズ、顧客提案、及びモジュールを含む複数の階層毎に要素をノード、各層間のノードの関連性をリレーションとして管理する。

【0023】

図２は、図１のモジュールパス保管部１１で管理されるノードとリレーションの一例を示す図である。

【0024】

顧客ニーズ層には、社会変化から考え得るペインポイント（顧客の抱えている悩みや問題）に基づく顧客ニーズ、もしくは顧客からの直接または間接的なヒアリングによって得られた顧客ニーズがノードとして管理される。その例がａ１からａ３である。

【0025】

顧客提案層には、上記の顧客ニーズ層で管理される顧客ニーズに応えるための既存の顧客提案、または顧客ニーズに応えるために必要な顧客提案がノードとして管理される。その例がｂ１～ｂ３である。なお、顧客提案としているが、顧客課題層や提案ソリューション層といった名前でも良い。

【0026】

モジュール層には、上記の顧客提案層で管理される顧客提案を構成する既存のモジュール名、または顧客提案を構成するために必要なモジュール名がノードとして管理される。その例がｃ１～ｃ３である。

【0027】

ここで、「モジュール」とは、１つ以上の機能を持つソフトウェアモジュールだけではなく、サーバや制御対象などのハードウェア、顧客、顧客管理のシステム、顧客ニーズを満たすための目的関数やデータなどのソリューションの流れを示す一連のものをモジュールとして含む。

【0028】

各層間のノードの関連性が管理され、ある層のノードに対して、上位または下位の層の別のノードとの関係性の有無（リレーション）を管理する。その例がｒ１である。

【0029】

これにより、顧客ニーズに対応できる顧客提案が何であるか、また、その顧客提案を構築するためのモジュールが何であるかを、リレーションに基づきパスを辿ることによって特定できる。

【0030】

例えば、ノードａ２の「設備の故障を避けたい」といった顧客ニーズの場合に、提案できる顧客提案の例は、ｂ２の「設備を過酷運転しない」や、ｂ３の「経費の見通しを示す」といったものであり、これらの提案を構成するモジュールはｃ１の「太陽光発電モデル」、ｃ２の「電力需要予測」、ｃ３の「ＯＰＥＸ計算」であることが容易に特定できる。

【0031】

なお、上記の例では、各層でそれぞれ３つのノードを持っているが、各層におけるノード数は特に制限のあるものではなく、必要なものすべてが登録される。１つの顧客ニーズに対して応えられる提案が複数あれば、顧客提案層のノードと、それに伴うモジュール層のノード数が増え、複雑な提案があれば、モジュール層のノード数が増える。

【0032】

図３は、図２で示したノードとリレーションの関係を管理するためのデータ構造の一例である。

【0033】

各ノードは、図のように、少なくともｉｄ、ｌａｙｅｒ＿ｎａｍｅ、ａｔｔｒｉｂｕｔｅｓの３つのデータ項目を持つ。ｉｄは、各層のノードを一意に識別するＩＤである。ｌａｙｅｒ＿ｎａｍｅは、各ノードがどの層のノードであるかを示す文字列であり、「顧客ニーズ層」などの文字列や、各層名を便宜上省略し、第１層を「Ｌ１層」などとしてもよい。また、「Ｌ１層」と表現するルールの場合は、データ型をｉｎｔとして、番号のみを保持するようにしてもよい。ａｔｔｒｉｂｕｔｅｓは属性リストを格納する項目であり、詳細は図４を用いて説明する。

【0034】

図４は、図３のａｔｔｒｉｂｕｔｅｓを表現するためのＡｔｔｒｉｂｕｔｅ型のデータ構造の一例である。

【0035】

各属性は、少なくともｋｅｙ、ｖｔｙｐｅ、ｖａｌｕｅの３つのデータ項目を持つ。ｋｅｙは、属性名を示す文字列である。ｖｔｙｐｅは、ｋｅｙとなる属性の値であるｖａｌｕｅの型を示す文字列である。ｖａｌｕｅは、ｋｅｙとなる属性の、ｖｔｙｐｅで設定された型の値を示すものである。

【0036】

ここで、「属性」とは、各ノードの特徴を示すものであり、ｋｅｙの例として、ｎａｍｅ、ｐａｒｅｎｔｓ、ｃｈｉｌｄｒｅｎ、ｄｅｔａｉｌなどが挙げられる。

【0037】

ｎａｍｅは、ノード名を指すものであり、この時のｖｔｙｐｅはｓｔｒｉｎｇ型、ｖａｌｕｅが具体的なノード名であり、図２の例では、ａ２の「設備の故障を避けたい」や、ｃ３の「ＯＰＥＸ計算」といった文言が該当する。

【0038】

ｐａｒｅｎｔｓは、当該ノードが含まれる層の上位層の関連するノードのリストを示すものであり、この時のｖｔｙｐｅはｓｔｒｉｎｇ型のリスト、ｖａｌｕｅは上位層の関連ノードのＩＤのリストが含まれる。なお、最上位層においては、ｐａｒｅｎｔｓのｖａｌｕｅは空のリストとなる。ｐａｒｅｎｔ属性を持つことにより、あるノードから見たときの上位層における関連ノードを辿ることができる。

【0039】

ｃｈｉｌｄｌｅｎは、当該ノードが含まれる層の下位層の関連するノードのリストを示すものであり、この時のｖｔｙｐｅはｓｔｒｉｎｇ型のリスト、ｖａｌｕｅは下位層の関連ノードのＩＤのリストが含まれる。なお、最下位層であるモジュール層においては、ｃｈｉｌｄｒｅｎのｖａｌｕｅは空のリストとなる。ｃｈｉｌｄｌｅｎ属性を持つことにより、あるノードから見たときの下位層における関連ノードを辿ることができる。

【0040】

ｄｅｔａｉｌは、当該ノードの詳細情報を示すものであり、この時のｖｔｙｐｅはｌｉｎｋ型やｓｔｒｉｎｇ型となり、ｖａｌｕｅは詳細情報を示すＵＲＬや関連データやモジュールへのファイルパス、もしくはノード名を補足するような文字列情報が該当する。ｄｅｔａｉｌ属性を持つことにより、あるノードに対する補足や、ドキュメントへのリンクを紐づけることができるようになる。

【0041】

例えば、顧客ニーズ層のノードであれば、ドキュメント保管部１４に保管された顧客とのやり取りのエビデンスや市場調査データ、インターネット上に公開された資料へのリンクなど、顧客提案層のノードであれば、ドキュメント保管部１４に保管された提案資料などへのリンクなど、モジュール層のノードでれば、ドキュメント保管部１４に保管されたモジュールのマニュアルや、モジュール保管部１３で保管されたモジュールへのリンクを持つことで、蓄積したナレッジを活用することができる。

【0042】

さらに、属性のｋｅｙとして、ＧｒｏｕｐやＴａｇｓを持たせることができる。

【0043】

Ｇｒｏｕｐは、各層のノードで共通するものをグループとして登録するための属性であり、この時のｖｔｙｐｅはｓｔｒｉｎｇ型となり、ｖａｌｕｅはグルーピングするためのグループ名が該当する。ノードがＧｒｏｕｐ属性を持つ場合、同じｖａｌｕｅを持つノードのグループのみをまとめて表示することなどができるようになる。

【0044】

Ｔａｇｓは、各ノードの特徴をタグとして登録するための属性であり、この時のｖｔｙｐｅはｓｔｒｉｎｇ型のリストとなり、valueは予め登録したタグのＩＤのリストが該当する。ノードがＴａｇｓ属性を持つ場合、各ノードに登録されたタグを表示して視覚的に表示したり、特定のタグを持つノードのみをまとめて表示したりすることなどができるようになる。

【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】

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、SSD（Solid State Drive）等の記録装置、または、ICカード、SDカード、DVD等の記録媒体に置くことができる。