(57)【要約】【課題】情報システムを構成するソフトウエアコンポーネントが妥当であるかを第三者の目で評価することを可能にする。【解決手段】演算装置と記憶装置とを有し、記憶装置は、情報システムに対する顧客の要求と、要求を実現するために必要とされるソフトウエア部品の機能又は性能とを対応付ける第１情報と、複数のソフトウエア部品の各々に関する、複数の評価項目の評価の情報を含む第２情報と、を保持し、第２情報は、複数の評価項目の評価の情報として、各ソフトウエア部品と、各ソフトウエア部品が有する機能又は性能とを対応付ける情報を含み、演算装置は、情報システムに対する顧客の要求の入力を受けると、第１情報に基づいて、入力された顧客の要求に対応するソフトウエア部品の機能又は性能を特定し、第２情報に基づいて、各ソフトウエア部品が特定された機能又は性能を有するか否かを判定する。【選択図】図３
2017027278.tif 000002
【特許請求の範囲】
【請求項１】
情報システムの構成を検証する構成検証装置であって、
前記構成検証装置は、演算装置と、前記演算装置に接続される記憶装置と、を有し、
前記記憶装置は、前記情報システムに対する顧客の要求と、前記要求を実現するために必要とされる、前記情報システムで使用されるソフトウエアコンポーネントの機能又は性能とを対応付ける第１情報と、複数のソフトウエアコンポーネントの各々に関する、複数の評価項目の評価の情報を含む第２情報と、を保持し、
前記第２情報は、前記複数の評価項目の評価の情報として、前記各ソフトウエアコンポーネントと、前記各ソフトウエアコンポーネントが有する機能又は性能とを対応付ける情報を含み、
前記演算装置は、
前記情報システムに対する顧客の要求の入力を受けると、前記第１情報に基づいて、入力された前記顧客の要求に対応する前記ソフトウエアコンポーネントの機能又は性能を特定し、
前記第２情報に基づいて、前記各ソフトウエアコンポーネントが前記特定された機能又は性能を有するか否かを判定することを特徴とする構成検証装置。
【請求項２】
請求項１に記載の構成検証装置であって、
前記第１情報は、前記情報システムに対する顧客の要求と、前記顧客の要求を実現するために前記情報システムに必要とされる機能又は性能とを対応付ける第３情報と、前記情報システムの機能又は性能と、前記情報システムの機能又は性能を実現するために必要とされる前記ソフトウエアコンポーネントの機能又は性能とを対応付ける第４情報と、を含み、
前記演算装置は、
前記第３情報に基づいて、前記入力された情報システムに対する顧客の要求に対応する前記情報システムの機能又は性能を特定し、
前記第４情報に基づいて、前記特定された前記情報システムの機能又は性能に対応する前記ソフトウエアコンポーネントの機能又は性能を特定することを特徴とする構成検証装置。
【請求項３】
請求項２に記載の構成検証装置であって、
前記演算装置は、特定された対応関係を表示する画面の情報を出力することを特徴とする構成検証装置。
【請求項４】
請求項３に記載の構成検証装置であって、
前記第２情報は、前記複数の評価項目の評価の情報として、前記各ソフトウエアコンポーネントのベンダを示す情報、前記各ソフトウエアコンポーネントの提供形態を示す情報、前記各ソフトウエアコンポーネントの流通状況を示す情報、及び、前記各ソフトウエアコンポーネントの利用実績を示す情報の少なくとも一つをさらに含み、
前記記憶装置は、前記複数の評価項目のうち、前記ソフトウエアコンポーネントの妥当性を評価するために有効な評価項目を指定する第５情報をさらに保持し、
前記演算装置は、前記第２情報及び前記第５情報に基づいて、前記各ソフトウエアコンポーネントの妥当性を評価し、その結果を出力することを特徴とする構成検証装置。
【請求項５】
請求項４に記載の構成検証装置であって、
前記ソフトウエアコンポーネントの妥当性を評価するために有効な評価項目は、少なくとも、前記ソフトウエアコンポーネントを採用することによる前記情報システムの開発コストの低減の程度、前記ソフトウエアコンポーネントを採用することに関する前記情報システムの発注者の意思決定の支援の程度、他の情報システムへの前記ソフトウエアコンポーネントの流用の容易性、および、前記ソフトウエアコンポーネントの保守の容易性、の少なくともいずれかを評価するために有効な評価項目であることを特徴とする構成検証装置。
【請求項６】
請求項４に記載の構成検証装置であって、
前記演算装置は、前記第２情報及び前記第５情報に基づいて、前記各ソフトウエアコンポーネントが該当する評価項目の数を計数し、その結果を出力することを特徴とする構成検証装置。
【請求項７】
請求項６に記載の構成検証装置であって、
前記演算装置は、前記各ソフトウエアコンポーネントが該当する評価項目の数を、前記各評価項目に予め付与された優先順位に従って重み付けをして計数することを特徴とする構成検証装置。
【請求項８】
計算機が実行する情報システムの構成検証方法であって、
前記計算機は、演算装置と、前記演算装置に接続される記憶装置と、を有し、
前記記憶装置は、前記情報システムに対する顧客の要求と、前記要求を実現するために必要とされる、前記情報システムで使用されるソフトウエアコンポーネントの機能又は性能とを対応付ける第１情報と、複数のソフトウエアコンポーネントの各々に関する、複数の評価項目の評価の情報を含む第２情報と、を保持し、
前記第２情報は、前記複数の評価項目の評価の情報として、前記各ソフトウエアコンポーネントと、前記各ソフトウエアコンポーネントが有する機能又は性能とを対応付ける情報を含み、
前記構成検証方法は、
前記演算装置が、前記情報システムに対する顧客の要求の入力を受ける第１手順と、
前記演算装置が、前記第１情報に基づいて、入力された前記顧客の要求に対応する前記ソフトウエアコンポーネントの機能又は性能を特定する第２手順と、
前記演算装置が、前記第２情報に基づいて、前記各ソフトウエアコンポーネントが前記特定された機能又は性能を有するか否かを判定する第３手順と、を含むことを特徴とする構成検証方法。
【請求項９】
請求項８に記載の構成検証方法であって、
前記第１情報は、前記情報システムに対する顧客の要求と、前記顧客の要求を実現するために前記情報システムに必要とされる機能又は性能とを対応付ける第３情報と、前記情報システムの機能又は性能と、前記情報システムの機能又は性能を実現するために必要とされる前記ソフトウエアコンポーネントの機能又は性能とを対応付ける第４情報と、を含み、
前記第２手順は、
前記演算装置が、前記第３情報に基づいて、前記入力された情報システムに対する顧客の要求に対応する前記情報システムの機能又は性能を特定する第４手順と、
前記演算装置が、前記第４情報に基づいて、前記特定された前記情報システムの機能又は性能に対応する前記ソフトウエアコンポーネントの機能又は性能を特定する第５手順と、を含むことを特徴とする構成検証方法。
【請求項１０】
請求項９に記載の構成検証方法であって、
前記演算装置は、前記第２手順から前記第５手順の少なくとも一つにおいて、特定された対応関係を表示する画面の情報を出力することを特徴とする構成検証方法。
【請求項１１】
請求項１０に記載の構成検証方法であって、
前記第２情報は、前記複数の評価項目の評価の情報として、前記各ソフトウエアコンポーネントのベンダを示す情報、前記各ソフトウエアコンポーネントの提供形態を示す情報、前記各ソフトウエアコンポーネントの流通状況を示す情報、及び、前記各ソフトウエアコンポーネントの利用実績を示す情報の少なくとも一つをさらに含み、
前記記憶装置は、前記複数の評価項目のうち、前記ソフトウエアコンポーネントの妥当性を評価するために有効な評価項目を指定する第５情報をさらに保持し、
前記構成検証方法は、前記演算装置が、前記第２情報及び前記第５情報に基づいて、前記各ソフトウエアコンポーネントの妥当性を評価し、その結果を出力する第６手順をさらに含むことを特徴とする構成検証方法。
【請求項１２】
請求項１１に記載の構成検証方法であって、
前記ソフトウエアコンポーネントの妥当性を評価するために有効な評価項目は、少なくとも、前記ソフトウエアコンポーネントを採用することによる前記情報システムの開発コストの低減の程度、前記ソフトウエアコンポーネントを採用することに関する前記情報システムの発注者の意思決定の支援の程度、他の情報システムへの前記ソフトウエアコンポーネントの流用の容易性、および、前記ソフトウエアコンポーネントの保守の容易性、の少なくともいずれかを評価するために有効な評価項目であることを特徴とする構成検証方法。
【請求項１３】
請求項１１に記載の構成検証方法であって、
前記第６手順において、前記演算装置は、前記第２情報及び前記第５情報に基づいて、前記各ソフトウエアコンポーネントが該当する評価項目の数を計数し、その結果を出力することを特徴とする構成検証方法。
【請求項１４】
請求項１３に記載の構成検証方法であって、
前記第６手順において、前記演算装置は、前記各ソフトウエアコンポーネントが該当する評価項目の数を、前記各評価項目に予め付与された優先順位に従って重み付けをして計数することを特徴とする構成検証方法。
【請求項１５】
計算機が情報システムの構成を検証するために実行するプログラムであって、
前記計算機は、演算装置と、前記演算装置に接続される記憶装置と、を有し、
前記記憶装置は、前記情報システムに対する顧客の要求と、前記要求を実現するために必要とされる、前記情報システムで使用されるソフトウエアコンポーネントの機能又は性能とを対応付ける第１情報と、複数のソフトウエアコンポーネントの各々に関する、複数の評価項目の評価の情報を含む第２情報と、を保持し、
前記第２情報は、前記複数の評価項目の評価の情報として、前記各ソフトウエアコンポーネントと、前記各ソフトウエアコンポーネントが有する機能又は性能とを対応付ける情報を含み、
前記プログラムは、
前記情報システムに対する顧客の要求の入力を受ける第１手順と、
前記第１情報に基づいて、入力された前記顧客の要求に対応する前記ソフトウエアコンポーネントの機能又は性能を特定する第２手順と、
前記第２情報に基づいて、前記各ソフトウエアコンポーネントが前記特定された機能又は性能を有するか否かを判定する第３手順と、を前記演算装置に実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報システムを構成するソフトウエアコンポーネントの評価に関する。
【背景技術】
【０００２】
情報システムの構築に関して、品質の妥当性を評価する技術として、特開２００４−１１８５７１号公報（特許文献１）に記載の技術がある。特許文献１には、「プロジェクトの遂行に影響を与える因子となる情報である影響因子情報を取得する影響因子情報取得部と、プロジェクトを遂行するために、プロジェクト遂行者が遂行すべき行為の指針となる情報である業務遂行情報を、影響因子情報に関連づけて蓄積する業務遂行情報蓄積部と、前記影響因子情報取得部で取得された影響因子情報に基づいて前記プロジェクトを遂行するために、前記業務遂行情報蓄積部から業務遂行情報の一又は、二以上の組合せを出力する業務遂行情報出力部と、を有するプロジェクト設計装置」が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−１１８５７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
Ｓｙｓｔｅｍ  Ｅｎｇｉｎｅｅｒ（以降、ＳＥ）は、顧客の要望する情報処理システムの要件（システム要件および制約条件など）を基に、まず対象となるハードウエア、ソフトウエアの製品を調査・選択し、技術的な接続可否等を、各種ハードウエア／ソフトウエアの仕様、過去の接続事例およびシステム構成事例等に基づいて調査・確認の後、システム要件および制約条件に合致する代替案を含むシステム構成案を作成する。次に、代替案を含むシステム構成案におけるソフトウエアの開発規模を、ＳＥのノウハウに基づき算出し、システム構成案と開発規模を勘案し、顧客の満足する情報処理システム構成を決定する、という手順をとる。このとき、ＳＥのソフトウエア製品の構成検討は担当ＳＥの知識と経験に依存することが多く、必ずしも顧客要件および開発時の要件に合ったソフトウエア製品を選択できているとは限らない。
【０００５】
特許文献１には、製品、サービスを提供するまでの業務プロセスを管理し、結果として提供される製品やサービスの品質を検証するための仕組みが記載されている。製品の企画の段階からサービス運用までの全工程に対しての評価項目が定義されているが、提供するサービスの品質を確認する項目は、方式設計書や基本設計書などの設計書レベルの評価項目となり、顧客要件に対して妥当なソフトウエアの設計書になっているか否かを評価することはできない。
【０００６】
しかしながら、情報システムの構築において、そのソフトウエアを選択した理由などはノウハウに依存する部分が多く、具体的な理由をＳＥにヒアリングしても、かつて使ったことがあるからといった理由が多く、明確な採用理由などを明文化することが難しい。また、情報システムは顧客要件以外にも、開発コスト削減、他の案件に利用できるなどの開発投資の最適化、および保守容易性など、様々な要件を考慮する必要があり、それらの要件に対して現在の情報システムのソフトウエア構成が妥当であるかを第三者の目から評価することが困難であった。
【０００７】
本発明は、これまでＳＥの構築ノウハウである部分を文書化することで、その情報システムがなぜそのシステム構成になったかを第三者の目で確認可能にすることを目的とする。
【課題を解決するための手段】
【０００８】
上記の課題を解決するために、本発明の一形態は、情報システムの構成を検証する構成検証装置であって、前記構成検証装置は、演算装置と、前記演算装置に接続される記憶装置と、を有し、前記記憶装置は、前記情報システムに対する顧客の要求と、前記要求を実現するために必要とされる、前記情報システムで使用されるソフトウエアコンポーネントの機能又は性能とを対応付ける第１情報と、複数のソフトウエアコンポーネントの各々に関する、複数の評価項目の評価の情報を含む第２情報と、を保持し、前記第２情報は、前記複数の評価項目の評価の情報として、前記各ソフトウエアコンポーネントと、前記各ソフトウエアコンポーネントが有する機能又は性能とを対応付ける情報を含み、前記演算装置は、前記情報システムに対する顧客の要求の入力を受けると、前記第１情報に基づいて、入力された前記顧客の要求に対応する前記ソフトウエアコンポーネントの機能又は性能を特定し、前記第２情報に基づいて、前記各ソフトウエアコンポーネントが前記特定された機能又は性能を有するか否かを判定することを特徴とする。
【発明の効果】
【０００９】
本発明の一形態によれば、情報システム設計時に組み合わせたソフトウエアコンポーネントに対して顧客要件などの妥当性を評価することができる。上記した以外の課題、構成、および効果は、以下の実施形態の説明によって明らかにされる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施例１のシステム構成検証システムの構成を示すブロック図である。
【図２】本発明の実施例１のシステム構成検証システムのハードウエア構成を示すブロック図である。
【図３】本発明の実施例１のシステム構成検証サーバのソフトウエア構成を示すブロック図である。
【図４】本発明の実施例１のシステム構成検証サーバがソフトウエア構成を導出する処理を示すフローチャートである。
【図５】本発明の実施例１のシステム構成検証サーバが保持するヒアリング情報の説明図である。
【図６】本発明の実施例１のヒアリング情報の一例であるヒアリング情報例の説明図である。
【図７】本発明の実施例１のシステム構成検証サーバが保持する要件対応情報の説明図である。
【図８】本発明の実施例１の要件対応情報の一例である要件対応情報例の説明図である。
【図９】本発明の実施例１のシステム構成検証サーバが保持する機能対応情報の説明図である。
【図１０】本発明の実施例１の機能対応情報の一例である機能対応情報例の説明図である。
【図１１】本発明の実施例１のシステム構成検証サーバが保持する製品対応情報の説明図である。
【図１２】本発明の実施例１の製品対応情報の一例である製品対応情報例の説明図である。
【図１３】本発明の実施例２のシステム構成検証サーバが保持する妥当性評価情報の説明図である。
【図１４】本発明の実施例２のシステム構成検証サーバが保持する開発コスト低減評価情報の説明図である。
【図１５】本発明の実施例２の開発コスト低減情報の一例である妥当性評価例（開発コスト低減）の説明図である。
【図１６】本発明の実施例３の妥当性評価情報に含まれる意思決定評価情報の評価項目の説明図である。
【図１７】本発明の実施例３の意思決定評価情報の一例である妥当性評価例（意思決定）の説明図である。
【図１８】本発明の実施例４の妥当性評価情報に含まれる横展開容易性価情報の評価項目の説明図である。
【図１９】本発明の実施例４の横展開容易性評価情報の一例である妥当性評価例（横展開容易評価情報）の説明図である。
【図２０】本発明の実施例２のシステム構成検証サーバが製品セットの妥当性を評価する処理を示すフローチャートである。
【発明を実施するための形態】
【実施例１】
【００１１】
本発明の実施例について以下に示す。本実施例では、システムエンジニア（以下ＳＥ）がシステムを構築する際に、開発効率化等を目的として既存のソフトウエア製品を活用する。活用するソフトウエアはこれまでＳＥの経験や勘で選択することが多く、第３者の目から見て、選択したものが妥当か否か、どのような観点で選ばれたかなど不明点が残る。このことは、顧客要件に対して適切か否かを判断することを難しくし、開発者側にとっては、選択したソフトウエアをベースにしたユーザプログラム開発および当該ソフトウエアのカスタマイズにかかる投資が適切であるのかの判断をも難しくする。そこで、ＳＥがシステムを構築するときの過程を文書化することによって、選択したソフトウエアが選ばれた理由を容易に見て取れるようにし、システムへの要件が変更された場合でも、すぐに現在の構成で問題がないかを確認することができ、加えて、ソフトウエア構成の変更を容易にすることが可能になる。
【００１２】
なお、以下の説明においてソフトウエア製品とは、既に作成され、利用可能なソフトウエアコンポーネントである限り、市販されているか否か、及びその流通の態様を問わず、いかなる種類のものであってもよい。
【００１３】
以下、図１から図１２を使って具体的に内容を説明する。まず、図の説明を行う。
【００１４】
図１は、本発明の実施例１のシステム構成検証システムの構成を示すブロック図である。
【００１５】
図１のシステム構成検証システムは蓄積サーバ１０１とシステム構成検証サーバ１０２とクライアント端末１０３と、其々の装置を接続するネットワーク１０４とによって構成されている。システム構成検証システムを利用するには、システムエンジニア（ＳＥ）が、クライアント端末１０３を利用して情報を入力し、入力した情報は、ネットワーク１０４を介してシステム構成検証サーバ１０２に入力され、蓄積サーバ１０１内にあるデータを利用して、システム構成検証サーバ１０２が処理をし、クライアント端末１０３に応答する。
【００１６】
図２は、本発明の実施例１のシステム構成検証システムのハードウエア構成を示すブロック図である。
【００１７】
蓄積サーバ１０１は、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）に代表される一時的にデータを蓄積する主記憶装置２００と、主記憶装置２００に存在するデータを読み取り、情報処理を行う中央演算装置２０１と、モニタ画面など、処理結果を表示することができる出力装置２０２と、キーボードなど情報を装置に入力することができる入力装置２０３と、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）などデータを蓄積することができる蓄積部と、ネットワークを介して他の装置とデータのやり取りを行うネットワークインタフェース部２０５と、を有し、主記憶装置２００からネットワークインタフェース部２０５までの装置はバス２０６によって接続されている。
【００１８】
図中のシステム構成検証サーバ１０２及びクライアント端末１０３の構成も同様である。すなわち、システム構成検証サーバ１０２の主記憶装置２１０からバス２１６及びクライアント端末１０３の主記憶装置２２０からバス２２６までの各部はそれぞれ蓄積サーバ１０１の主記憶装置２００からバス２０６までの各部と同様である。蓄積サーバ１０１、システム構成検証サーバ１０２及びクライアント端末１０３は、ネットワーク１０４を介して相互にデータをやり取りすることができる。
【００１９】
なお、図２には蓄積サーバ１０１、システム構成検証サーバ１０２及びクライアント端末１０３がそれぞれ独立した計算機によって実現される例を示したが、これらのうち任意の二つ又は全部が一つの計算機によって実現されてもよいし、それぞれが複数の計算機によって実現されてもよい。また、それぞれの計算機は、物理的に独立した計算機であってもよいし、物理的な計算機の資源の一部を割り当てることによって構成された仮想的な計算機であってもよい。
【００２０】
図３は、本発明の実施例１のシステム構成検証サーバ１０２のソフトウエア構成を示すブロック図である。
【００２１】
システム構成検証サーバ１０２は、外部の装置とデータをやり取りする通信部３００と、顧客要件からソフトウエア構成を導出する変換処理部３０２と、導出されたソフトウエア構成について、その妥当性を評価する妥当性評価部３０１と、によって構成される。これらの各部の機能は、中央演算装置２１１が主記憶装置２１０に格納されたプログラムに従って後述する処理を実行することによって実現される。すなわち、以下の説明において上記の各部が実行する処理は、実際には中央演算装置２１１によって実行される。
【００２２】
例えば、主記憶装置２１０に、通信部３００に対応する通信プログラム、妥当性評価部３０１に対応する妥当性評価プログラム、及び変換処理部３０２に対応する変換処理プログラムが格納され、中央演算装置２１１がこれらを実行してもよい。その場合、以下の説明において通信部３００、妥当性評価部３０１及び変換処理部３０２が実行する処理は、中央演算装置２１１が上記のプログラムに従って、必要に応じて出力装置２２２〜ネットワークインタフェース部２２５等を制御することによって実行する。
【００２３】
さらに、システム構成検証サーバ１０２は、顧客要件を抽出するためのヒアリング項目蓄積部３０８と、ヒアリング項目から要件に変換する表を蓄積する要件対応表蓄積部３０７と、要件から機能や性能の言葉に変換する表を蓄積する機能対応表蓄積部３０６と、機能や性能言葉から製品を抽出する製品対応表蓄積部３０５と、変換処理部３０２によって生成した顧客要件に合致したソフトウエア構成を蓄積するソフトウエア構成情報蓄積部３０４と、生成したソフトウエア構成の妥当性を評価するための評価軸を蓄積する妥当性評価項目蓄積部３０３によって構成されている。なお、妥当性評価項目蓄積部３０３からヒアリング項目蓄積部３０８の元データは蓄積サーバ１０１に蓄積され、それらの一部又は全部が必要に応じてシステム構成検証サーバ１０２の蓄積部２１４にコピーされ、さらに必要に応じて主記憶装置２２０にコピーされ、妥当性評価部３０１又は変換処理部３０２によって参照される。
【００２４】
図４は、本発明の実施例１のシステム構成検証サーバ１０２がソフトウエア構成を導出する処理を示すフローチャートである。
【００２５】
処理フローの最初のステップであるステップ４００は、顧客の要件を抽出するステップである。ＳＥはクライアント端末１０３を操作し、システム構成検証サーバ１０２に問い合わせを行い、ヒアリング項目画面を取得する。そして、ＳＥはクライアント端末１０３を操作してヒアリング項目を入力し、顧客要件をシステムに入力する。さらに、ＳＥはクライアント端末１０３の入力装置２２３を利用し、出力装置２２２に表示されたヒアリング項目に回答する。ＳＥが回答したヒアリング項目は、システム構成検証サーバ１０２に送られ、ヒアリング項目蓄積部３０８に蓄積される。
【００２６】
ステップ４０１では、システム構成検証サーバ１０２の変換処理部３０２が、ヒアリング項目蓄積部３０８にデータが入力されたことを検出し、ヒアリング項目に対する機能要件及びシステム要件がマッピングされた要件対応表を蓄積サーバ１０１から取得し、ヒアリング項目蓄積部３０８に蓄積された情報と突き合わせ、回答されたヒアリング項目に対する要件を抽出し、要件対応表蓄積部３０７に登録する。
【００２７】
ステップ４０２では、システム構成検証サーバ１０２の変換処理部３０２が、要件対応表蓄積部３０７にデータが入力されたことを検出し、機能要件及びシステム要件に対するソフトウエア製品の機能・性能項目がマッピングされた機能対応表を蓄積サーバ１０１から取得し、要件対応表蓄積部３０７に蓄積された情報と突き合わせ、機能要件及びシステム要件に対する機能・性能項目を抽出し、機能対応表蓄積部３０６に登録する。
【００２８】
ステップ４０３では、システム構成検証サーバ１０２の変換処理部３０２が、機能対応表蓄積部３０６にデータが入力されたことを検出し、機能・性能項目に対する製品がマッピングされた製品対応表を蓄積サーバ１０１から取得し、機能対応表蓄積部３０６に蓄積された情報と突き合わせ、機能・性能項目に対する製品を抽出し、製品対応表蓄積部３０５に登録する。製品対応表蓄積部３０５に登録された製品一覧は、それぞれの製品がすべての顧客要件を満たすわけではなく、顧客要件の一部分あるいはすべてを満たす可能性のあるパーツがリストアップされたものである。変換処理部３０２は、このパーツの組み合わせ（セット）を作成し、ソフトウエア構成情報蓄積部３０４に登録する。
【００２９】
変換処理部３０２は、ソフトウエア構成情報蓄積部３０４に蓄積された情報をクライアント端末１０３に送信し、クライアント端末１０３は出力装置２２２を介してＳＥに結果を表示する。
【００３０】
例えば、変換処理部３０２は、ステップ４０１で抽出したヒアリング項目と要件との対応関係を表示するための画像データ、例えば後述する図８に示すような要件対応情報を表示する画像データを作成し、クライアント端末１０３に送信してもよい。また、変換処理部３０２は、ステップ４０２で抽出した機能要件及びシステム要件と機能・性能項目との対応関係を表示するための画像データ、例えば後述する図１０に示すような機能対応情報を表示する画像データを作成し、クライアント端末１０３に送信してもよい。さらに、変換処理部３０２は、ステップ４０３で抽出した機能・性能項目とソフトウエア製品との対応関係を表示するための画像データ、例えば後述する図１２に示すような製品対応情報を表示する画像データを作成し、クライアント端末１０３に送信してもよい。クライアント端末１０３は、それらの全ての画像、又は必要に応じていずれかを表示してもよい。
【００３１】
図５は、本発明の実施例１のシステム構成検証サーバ１０２が保持するヒアリング情報５００の説明図である。
【００３２】
ヒアリング情報５００は、図４のステップ４００で使用するヒアリング項目によって構成され、ヒアリング項目蓄積部３０８に蓄積される情報である。ヒアリング情報５００は業務課題情報５０１及び性能条件情報５０２によって構成される。業務課題情報５０１は、顧客の業務において現在抱えている課題を分類したものである。性能条件情報５０２は、現在の業務課題において、必要とされる性能情報である。現在課題を抱える業務がどのくらいのシステムサイクルで動作しているかを理解することで、ＳＥが提供する情報システムの性能要件を把握することができる。
【００３３】
図６は、本発明の実施例１のヒアリング情報５００の一例であるヒアリング情報例６００の説明図である。
【００３４】
図６に示すヒアリング情報例６００は、分類６０１、ヒアリング項目６０２、ヒアリング内容６０３及び回答欄６０４を含む。分類６０１は、ヒアリング項目６０２の分類であり、例えば「可視化」又は「リアルタイム異常判定」等である。ヒアリング項目６０２は、顧客に対するヒアリングの項目であり、例えば「異常発生の通知」又は「異常ルールの手動作成」等である。この例において、「異常発生の通知」は「可視化」に、「異常ルールの手動作成」は「リアルタイム異常判定」に分類される。ヒアリング内容６０３は、各ヒアリング項目の具体的な内容であり、例えば「異常発生の通知」に対応するヒアリング内容６０３は、「設備で生じた異常をリアルタイムに通知するか？」である。回答欄６０４には、各項目のヒアリング内容６０３に対する回答（チェック結果）が入力される。
【００３５】
この例において、「可視化」に分類されるヒアリング項目は、図５の業務課題情報５０１に該当し、「リアルタイム異常判定」に分類されるヒアリング項目は、性能条件情報５０２に該当する。図６には例として２分類５項目のヒアリング項目のみを示しているが、実際には、業務課題情報５０１及び性能条件情報５０２のそれぞれに該当する多くの分類が存在し、それぞれの分類に該当する多くのヒアリング項目がヒアリング情報５００に含まれる。     
【００３６】
ヒアリング情報例６００のうち、分類６０１からヒアリング内容６０３までは予め作成され、蓄積サーバ１０１に格納されている。システム構成検証サーバ１０２は、必要に応じて蓄積サーバ１０１からこれらを読み出して、クライアント端末１０３を介してユーザ（例えばＳＥ）に提示し、ユーザから入力された回答を回答欄６０４に追加して、ヒアリング項目蓄積部３０８に蓄積する。
【００３７】
顧客が所有する工場などの現場システムにおいて、製造ライン等の状態を把握したい場合、例えば顧客に対するヒアリングを行った営業担当者又はフロントＳＥが、ヒアリングの結果に従って、「可視化」に分類されたヒアリング項目に該当する項目がないかを判定し、回答欄にチェックを行う。
【００３８】
例えば、営業担当者が顧客に対するヒアリングを行った結果、顧客が「設備で生じた異常をリアルタイムで通知する」ことをシステムに要求していると判断した場合、営業担当者は、ヒアリング項目６０２「異常発生の通知」に対応する回答欄６０４にチェックを行う（すなわち当該ヒアリング項目が顧客の要求に該当することを示す値を入力する）。
【００３９】
図７は、本発明の実施例１のシステム構成検証サーバ１０２が保持する要件対応情報７００の説明図である。
【００４０】
要件対応情報７００は、図４のステップ４０１において、ヒアリング項目に対応する要件を抽出するために参照される情報であり、ヒアリング項目と要件項目とを対応付ける情報を含む。具体的には、要件対応情報７００は、ヒアリング情報７０１と要件情報７０２とによって構成されている。ヒアリング情報７０１は、図４のヒアリング情報５００に相当する。
【００４１】
要件情報７０２は、業務アプリケーション要件情報７０３、業務共通アプリケーション要件情報７０４、インフラ関連要件情報７０５、システム・デバイス要件情報７０６、蓄積・処理要件情報７０７、収集・配信要件情報７０８、セキュリティ要件情報７０９、及び運用管理要件情報７１０によって構成されている。要件対応情報７００は、ヒアリング項目を、それに対応する要件を表現する言葉に変換する表である。言い換えると、要件対応情報７００は、顧客の情報システムに対する要求と、その要求を実現するために情報システムに必要とされる機能又は性能とを対応付ける情報を含む。ヒアリング情報５００にあてはまらない、顧客業務特有の要件がある場合には、そのような要件は業務アプリケーション要件情報７０３に分類される。ここに分類される要件に関しては、多くの場合、ユーザプログラムとして開発される。
【００４２】
業務共通アプリケーション要件情報７０４は、様々な業務に共通する機能を有したアプリケーションの要件を抽出し、分類したものである。例えば、顧客の現場システムにおける人や物を管理するＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ  Ｒｅｓｏｕｒｃｅ  Ｐｌａｎｎｉｎｇ）などを利用する場合には、そのための要件は、業務共通アプリケーション要件情報７０４に分類される項目のいずれかに該当することになる。インフラ関連要件情報７０５としては、提供する情報システムがクラウドで提供されるのか、オンプレミスで提供されるのか、現場システムとクラウドを接続するネットワークは広域網なのか専用線なのか、等を判断する要件一覧が記載されている。
【００４３】
システム・デバイス要件情報７０６としては、顧客の現場システムに関する要件である。現場システムの状況を可視化するなどのサービスを提供する場合、対象とする現場システムの装置から稼働データを収集できるのか、センサを設置する必要があるのか、どのようなセンサを設置すべきか、現場システムにネットワークを構築できるか、などの要件が記載されている。蓄積・処理要件情報７０７としては、現場システムから稼働データを取得した際に、どのような形式で蓄積すべきか、その情報は変換すべきかなど、データ蓄積及びフォーマットに関する要件が記載されている。
【００４４】
収集・配信要件情報７０８としては、現場システムから稼働データを取得するときに必要なタイミング又はプロトコルなどに関する要件が記載されている。セキュリティ要件情報７０９としては、提供する情報システム全体のセキュリティに関する要件が記載されている。例えば、ヒアリング情報５００から現場システムから取得するデータの重要性をもとに、広域網を経由してクラウド送信するときのリスクなどを鑑みて、必要とされるセキュリティの要件が記載されている。運用管理要件情報７１０としては、提供する情報システム全体の運用管理に関する要件が記載されている。
【００４５】
上記のような要件情報７０２に含まれる各要件は、ヒアリング情報５００のヒアリング項目の各々に事前にマッピングされている。ヒアリング項目に対する要件情報のマッピングは、システム構築に携わった様々なＳＥへのレビューを重ね、ベストプラクティスとされた情報システムの構成を分析し、マッピングに対する妥当性を確認した結果に基づいて行う必要がある。
【００４６】
図８は、本発明の実施例１の要件対応情報７００の一例である要件対応情報例８００の説明図である。
【００４７】
要件対応情報例８００では、要件情報７０２にとして、業務共通アプリケーション要件情報７０４に分類される要件のみを記載し、それ以外の要件は省略しているが、実際には、業務アプリケーション要件情報７０３、インフラ関連要件情報７０５〜運用管理要件情報７１０のそれぞれに分類される要件も記載される。要件対応情報例８００では、業務共通アプリケーション要件情報７０４に分類される複数の要件が事前に抽出され、さらに、それぞれの要件が各ヒアリング項目に該当する場合にはそのことを示す情報（図８の例では○印）が記載されている。ユーザによる図６の回答欄６０４へのチェックと、要件対応情報例８００とを参照することで、顧客の要求に該当するヒアリング項目が要件情報７０２の中のどの要件に該当するのかを特定することができる。変換処理部３０２は、図８の表に基づいて、ヒアリング項目をそれに対応する要件を表現する言葉に変換する。
【００４８】
図８の例では、業務共通アプリケーション要件情報７０４のうち、「現在の事象を検索できること」及び「故障を予兆できること」と、ヒアリング項目「異常発生の通知」との対応に○印が付けられている。これは、顧客が「設備で生じた異常をリアルタイムに通知する」ことをシステムに要求している（例えば図６のヒアリング項目「異常発生の通知」に対応する回答欄６０４がチェックされている）場合、システムの性能又は機能として「現在の事象を検索できること」及び「故障を予知できること」が要求されることを示している。このような対応関係は、上記のように、ＳＥへのレビュー等に基づいて予め設定されているものである。
【００４９】
変換処理部３０２は、例えば図６のヒアリング項目「異常発生の通知」に対応する回答欄６０４がチェックされている場合、システムの性能又は機能として「現在の事象を検索できること」及び「故障を予知できること」が必要であることを知ることができる。このように、要件対応情報７００によって、顧客のシステムに対する各要求と、それを実現するためにシステムに求められる一つ以上の機能又は性能とが、システムの機能又は性能の分類ごとに、対応付けられる。
【００５０】
図９は、本発明の実施例１のシステム構成検証サーバ１０２が保持する機能対応情報９００の説明図である。
【００５１】
機能対応情報９００は、図４のステップ４０２で利用される。機能対応情報９００は、要件情報９０１と機能・性能情報９０２とによって構成されている。要件情報９０１は、図７の要件情報７０２と同様の要件を含んでもよいし、図７の要件情報７０２のうち、図４のステップ４０１で抽出された要件のみを含んでもよい。
【００５２】
機能・性能情報９０２は、業務共通アプリケーション機能情報９０４と、業務共通アプリケーション性能情報９０８と、インフラ関連機能情報９０５と、インフラ関連性能情報９０９と、システム・デバイス機能情報９０６と、システム・デバイス性能情報９１０と、蓄積・処理機能情報９１１と、蓄積・処理性能情報９１５と、収集・配信機能情報９１２と、収集・配信性能情報９１６と、セキュリティ機能情報９１３と、セキュリティ性能情報９１７と、運用管理機能情報９１４と、運用管理性能情報９１８と、によって構成されている。機能・性能情報９０２は、要件情報７０２に含まれる各要件を満足するシステムを構築するために必要な機能又は性能を有するソフトウエア製品を抽出できるように、各ソフトウエア製品で利用する機能及び性能に関する情報を分析し、統一的な言葉で整理したものである。業界特有な表現を避け、どの業界のＳＥでも理解しやすいような機能又は性能を表現する言葉を使用することで、製品抽出の妥当性を向上させることができる。
【００５３】
図１０は、本発明の実施例１の機能対応情報９００の一例である機能対応情報例１０００の説明図である。
【００５４】
図１０に示す機能対応情報例１０００の表の縦軸が要件情報９０１（すなわち要件情報７０２）を指し、横軸が機能・性能情報９０２に対応する。言い換えると、表の１行が要件の１項目に、１列が機能又は性能の１項目に対応する。ここでは縦軸に業務共通アプリケーション要件情報７０４に分類される要件の項目の一部のみを記載し、横軸に業務共通アプリケーション性能情報９０８及び蓄積・処理性能情報９１５に分類される機能又は性能の項目のみを記載する。機能対応情報例１０００は、各要件と、それを実現するためにソフトウエア製品に要求される機能又は性能を表現する言葉とを対応付ける対応表であり、これによって要件を実現するためにはどのような機能や性能が必要かを一目で理解することができる。
【００５５】
具体的には、各要件の行と機能又は性能の各項目の列とが交差するセルに、当該要件と当該機能又は性能とが対応することを示す「○」又は対応しないことを示す「×」が記載され、これを参照することで、各要件を、それを実現するためにソフトウエア製品に要求される機能又は性能を表現する言葉に変換することができる。
【００５６】
図１０に示す対応関係の一例を挙げると、システムの要件「設備を管理できること」には、業務共通アプリケーション性能情報９０８のうち「性能効率性」及び「アプリケーション処理タイプ」に分類される性能として、「リアルタイム処理」及び「オンライン分析」が対応し、「定期処理」及び「オフライン分析」は対応せず、業務共通アプリケーション性能情報９０８のうち「互換性」及び「市場成熟度」に分類される性能として、「デファクト標準規格」及び「標準規格対応無し」が対応し、「デジュール標準規格」は対応しない。これは、システムの要件「設備を管理できること」を実現するためのソフトウエア製品が、リアルタイム処理及びオンライン分析を実行できる必要があるが、定期処理及びオフライン分析を実行できる必要はなく、また、互換性に関して、デジュール標準規格に準拠している必要がないことを示している。
【００５７】
図１０に示した具体的な項目は一例であり、実際にはそれぞれの分類がさらに多くの項目を含んでもよいし、他の分類の項目についても同様の対応関係情報が保持される。
【００５８】
図１１は、本発明の実施例１のシステム構成検証サーバ１０２が保持する製品対応情報１１００の説明図である。
【００５９】
製品対応情報１１００は、図４のステップ４０３で利用される。この情報は、ＳＥが利用する価値のあるソフトウエアを事前に選定し、図９の機能対応情報９００の機能・性能項目においてどの機能や性能を提供しているのかを事前に評価しておくことによって作成される。ステップ４０３では、ステップ４０２までで生成したヒアリング項目から導出した機能・性能情報に対して該当する製品を抽出するために製品対応情報１１００が利用される。
【００６０】
製品対応情報１１００は、機能・性能情報１１０１と、製品情報１１０２とによって構成されている。機能・性能情報１１０１は、ヒアリング項目から導出した機能・性能情報との比較によって、該当する製品を抽出するときに利用される。製品情報１１０２は、ベンダ情報１１０３と、提供形態情報１１０４と、商流情報１１０５と、実績情報１１０６と、によって構成されている。製品情報１１０２は選択した製品の妥当性を評価するときに利用される。ベンダ情報１１０３としては製品ベンダに関する情報、例えば、ベンダの名称、取引実績、所在地、資本金等の情報が登録される。提供形態情報１１０４としては製品の提供形態における情報が登録される。例えば、クラウドでの利用について、マルチテナントでの利用で、顧客間で情報の漏えいがないか、障害が波及しないか、顧客ごとのカスタマイズは可能かなど、当該製品がどのように提供されることを想定しているかを考慮する必要がある。商流情報１１０５は、ＳＥが構築する情報システムにおいて、国外に提供することを考えたとき、提供先の国で保守体制があるのか、製品は現地のＯＳで動作実績があるか、マニュアルは英語化されているか、といった、製品の流通状況を特定する情報を含む。このような情報が製品の選定理由になることがある。実績情報１１０６は、対象となる製品の利用実績を示す情報であり、例えば、対象となる製品のベンダが提供するサービス又は製品をこれまでに利用したことがあるか、対象となる製品をこれまでに利用したことがあるか、利用実績があるとすると、利用したことがある開発者を集めることができるか、などを特定する情報を含む。これらが考慮すべき点になる。
【００６１】
図１２は、本発明の実施例１の製品対応情報１１００の一例である製品対応情報例１２００の説明図である。
【００６２】
図１２に示す製品対応情報例１２００の表の縦軸が評価対象となる製品のリスト１２０１であり、横軸が製品情報１１０２に加え、製品の機能・性能情報１１０１である。言い換えると、表の１行が各ソフトウエア製品に対応し、１列が製品の性能・機能といった製品の評価項目に対応する。縦軸の各製品は扱う可能性がある製品であり、図１２では４製品のみを示すが、実際にはさらに多くの製品が含まれる。また、図１２の例では、横軸には、製品情報１１０２として提供形態情報１１０４及び商流情報１１０５に分類される項目の一部を示すが、実際にはベンダ情報１１０３及び実績情報１１０６に分類される項目も含まれる。同様に、機能・性能情報１１０１も、実際には、図９の機能・性能情報９０２と同様の各種の項目を含む。
【００６３】
製品対応情報例１２００は、各製品と、製品の機能・性能といった評価項目とを対応付ける対応表である。図１０と同様に、各製品の行と各評価項目の列とが交差するセルに、当該製品が当該評価項目に該当する（例えばその評価項目が特定の機能又は性能である場合、当該製品が当該機能又は性能を有する）ことを示す「○」又は有しないことを示す「×」が記載される。これを参照して、ヒアリング項目から導出される機能・性能情報９０２と製品とのマッチングをとることによって、顧客要件に該当する製品を抽出することができる。
【００６４】
図４のステップ４０３において抽出された該当製品は、１製品で顧客要件をすべて満たしていることはほとんどないため、顧客要件に対する対応の抜け・もれが存在する。ステップ４０３では複数の製品が抽出されており、その中には顧客要件の一部のみしか対応していない製品も含まれる。ステップ４０３において、変換処理部３０２は、いくつかの製品を組み合わせることで顧客要件を満たせる場合は、組み合わせた結果、顧客要件に合致する項目が多くなる組み合せを製品セットとして図３のシステム構成検証サーバ１０２のソフトウエア構成情報蓄積部３０４に登録する。
【００６５】
例えば、「リアルタイム異常判定」に分類されるヒアリング項目「フィールドでの異常検知」がチェックされた場合、顧客から現場設備で異常検知を実施することが求められており（図６）、その要求を満たすために、構築される情報システムには、業務共通アプリケーション要件情報７０４に分類される「設備を管理できること」及び「保守計画を立てられること」という要件が求められる（図８）。これらのうち、要件「設備を管理できること」に注目すると、この要件を実現するために、ソフトウエア製品には、業務共通アプリケーション性能情報９０８のうち、さらに性能効率性に関するアプリケーション処理タイプに分類される性能として「リアルタイム処理」及び「オンライン分析」ができることが求められる（図１０）。
【００６６】
図１２によれば、製品のリスト１２０１に含まれる複数のソフトウエア製品のうち、業務アプリケーション製品Ａ及び業務アプリケーション製品Ｃは、オンライン分析はできるがリアルタイム処理はできない。一方、業務アプリケーション製品Ｂは、リアルタイム処理はできるがオンライン分析はできない。このため、これらの性能の項目については、業務アプリケーション製品Ａ〜Ｃの顧客要件（すなわちヒアリング項目）に合致する項目の数は「１」となる。
【００６７】
システム構成検証サーバ１０２は、上記と同様の処理を、業務共通アプリケーション性能情報９０８に分類される他の性能の項目、及び、業務共通アプリケーション性能情報９０８以外の分類に属する機能・性能の項目についても実行する。さらに、システム構成検証サーバ１０２は、業務共通アプリケーション要件情報７０４に分類されるもう一つの該当要件「保守計画を立てられること」についても上記と同様の処理を実行する。
【００６８】
システム構成検証サーバ１０２は、業務共通アプリケーション要件情報７０４以外の分類に属する情報システムの要件の項目についても、ヒアリング項目「フィールドでの異常検知」に該当するものがある場合にはそれらの項目について上記と同様の処理を行い、さらに、「フィールドでの異常検知」以外のヒアリング項目がチェックされている場合には、それらのヒアリング項目に対応する情報システムの要件及びそれらに対応する機能・性能の項目についても上記と同様の処理を行う。例えば、システム構成検証サーバ１０２は、上記の処理によって、チェックされたヒアリング項目に対応する機能・性能の全ての項目のうち、各ソフトウエア製品が有しているものの数を、各ソフトウエア製品を評価するスコアとして計算し、スコアが最も高い製品を、顧客の要求に最も合致する製品として出力してもよい。
【００６９】
このとき、ユーザが予め各評価項目に評価の優先順位を設定してもよい。その場合、システム構成検証サーバ１０２は、各ソフトウエア製品について、顧客要件に該当する機能・性能の項目の数を単に集計するのではなく、優先順位に応じた重み付けをして集計する。例えば、ヒアリング項目の分類「リアルタイム異常判定」に、「可視化」より高い優先順位が設定されている場合、システム構成検証サーバ１０２は、各ソフトウエア製品が有している機能・性能の項目の数を集計するときに、「リアルタイム異常判定」に分類されるヒアリング項目に対応する機能・性能の項目の数に、「可視化」に対応する項目の数より大きい重みを付けて集計する。
【００７０】
同様に、要件情報７０２に含まれる要件の分類（例えば業務共通アプリケーション要件情報７０４等）に優先順位が設定されてもよいし、機能・性能情報９０２に含まれる機能・性能の分類（例えば業務共通アプリケーション性能情報９０８等）に優先順位が設定されてもよい。
【００７１】
上記の例はソフトウエア製品ごとの評価について説明しているが、複数の製品からなる製品セットについて評価する場合は、顧客要件に対応する機能又は性能を、製品セットを構成する複数の製品のいずれかが有しているか、いずれも有していないか、を判定することによって、上記と同様の処理を実行することができる。
【００７２】
以上の本発明の実施例１によれば、営業またはフロントＳＥ等が実施する顧客へのヒアリングによって、顧客の要求を実現するための情報システムの要件が抽出され、さらに抽出された要件があるルールに基づいて機能／性能項目に変換され、機能／性能項目に置き換えられた各項目に該当するソフトウエアコンポーネントが割り当てられる。ソフトウエアコンポーネントは顧客要件から変換した機能／性能項目と同じ項目を用いて評価される。顧客要件から変換された機能／性能項目を各ソフトウエアコンポーネントが有するか否かを検証することによって、顧客要件に該当するソフトウエアコンポーネントが割り当てられる。これらの手順を行うことによって、ソフトウエアコンポーネントの導出過程が可視化され、第三者の目にもなぜそのソフトウエアコンポーネントが選択されたかを確認することができる。
【００７３】
このとき、顧客へのヒアリングによって特定された顧客の要求が、直接、ソフトウエアコンポーネントの機能／性能に対応付けられてもよいが、情報システムの要件を介して対応付けることで、ソフトウエアコンポーネントの選択の妥当性をより的確かつ容易に判断することが可能になる。
【実施例２】
【００７４】
次に、本発明の実施例２について、図２０の処理フローおよび図１３、図１４、図１５を参照して説明する。以下に説明する相違点を除き、実施例２のシステムの各部は、図１〜図１２に示された実施例１の同一の符号を付された各部と同一の機能を有するため、それらの説明は省略する。
【００７５】
実施例１では、顧客要件のみに基づいて、ソフトウエア構成が抽出される。しかし、実際のシステム構築の場面では、顧客要件だけでなく、情報システムに関係する様々なステークホルダの要件を満たすことが重要になる。ここで言うステークホルダは、当該情報システムを企画した営業担当者、フロントＳＥ、情報システムを開発するＳＥ、および情報システムの保守・運用を行う保守作業員である。営業担当者およびフロントＳＥに関しては、利益率を上げたいために開発コスト低減が要件であり、開発した情報システムが他の顧客にも活用できるようにＮ倍化ができるかなども要件になる。また、ＳＥに関しては故障件数低減が要件として考えられる。保守作業員に関しては、保守容易性の観点から、各ソフトウエアコンポーネントが同じルールに則ってログを出力すること、提供するソフトウエアの拡張性および更改管理などが要件となる。顧客要件だけが考慮され、開発工期、人件費、作りやすさなど開発側の立場による評価がされない場合には、開発コストの増大といった影響が現れる可能性がある。実施例２では実施例１で選択したソフトウエア構成の複数のセットについてさらに開発コスト低減の観点において妥当性を評価する。
【００７６】
図１３は、本発明の実施例２のシステム構成検証サーバ１０２が保持する妥当性評価情報１３００の説明図である。
【００７７】
妥当性評価情報１３００は、提案する情報システムのステークホルダによる要件をそれぞれ評価することによって妥当性の評価を行うための評価項目を含む。具体的には、妥当性評価情報１３００は、開発コスト低減評価情報１３０１と、意思決定評価情報１３０２と、横展開容易性評価情報１３０３と、保守容易性評価情報１３０４とで構成されている。ＳＥが提案する情報システムのステークホルダとして、顧客要件を定義する顧客以外に、開発を行うＳＥ又は保守を行う作業員が挙げられる。妥当性評価情報１３００は、これらのステークホルダの観点で評価軸を設定しているほか、情報システムを活用する顧客の経営層に関する評価観点も考慮に入れている。各評価情報は実施例３以降で説明する。
【００７８】
図１４は、本発明の実施例２のシステム構成検証サーバ１０２が保持する開発コスト低減評価情報１３０１の説明図である。
【００７９】
開発コスト低減評価情報１３０１は、情報システムを開発するＳＥの要件（すなわち顧客ではなくシステムの開発者の立場で、例えばシステムの開発しやすさ等の観点でシステムに要求する項目）を考慮に入れている。顧客要件だけに基づいてソフトウエアを選択した場合、選択されたソフトウエアが開発部隊の持っているスキルセットに合わず、開発工数が増すなど弊害を及ぼす可能性がある。そこで顧客要件によって抽出した製品セットを上記のようなＳＥの要件を考慮に入れた評価軸で評価することによって、開発者の立場での妥当な製品セットを選択することができる。
【００８０】
開発コスト低減評価情報１３０１は、利用実績評価項目１４０１と、インタフェース評価項目１４０２と、商流評価項目１４０３と、を含む。利用実績評価項目１４０１は、開発対象の情報システムの開発部隊において各ソフトウエア製品又は製品セットの利用実績があるか否か、言い換えると、その開発部隊にそれらのソフトウエア製品を利用した経験のある開発者がいるか否かを評価する項目である。製品セットを以前利用して、使ったことがある開発者が開発部隊にいるだけでも、マニュアルを読んで理解利用できるまでのコストが削減される。
【００８１】
インタフェース評価項目１４０２は、利用されるインタフェースに起因する開発コストの削減を評価する項目である。例えば、標準化されたインタフェースが利用される場合、開発工数が削減するなどの効果がある。商流評価項目１４０３は、図１１の商流情報１１０５と同様の観点で、国外に情報システムを提供した場合の保守の容易性、発生するコスト等を評価する項目である。
【００８２】
図１５は、本発明の実施例２の開発コスト低減情報１４００の一例である妥当性評価例（開発コスト低減）１５０１の説明図である。
【００８３】
図１５に示す妥当性評価例（開発コスト低減）１５０１は、評価項目を分類するカテゴリ１５０２、評価項目に相当する項目１５０３、各評価項目が顧客要件に該当するか否かを示す顧客要件該当１５０４、及び、各製品セットが各評価項目を満たすか否かを示す製品セット情報（図１５の例では製品セットＡ１５０５〜製品セットＣ１５０７）を含む。図１５の「過去の利用実績」のように、一つの項目が一つのカテゴリをなす場合もある。項目１５０３として登録される各評価項目が、製品対応情報１１００に含まれる製品の各評価項目に対応する。
【００８４】
妥当性評価例（開発コスト低減）１５０１の表の中で顧客重要項目として枠で囲んである個所（図１５の例では、評価項目「英語ＯＳでの動作」、「顧客管理機能」、「構造データ蓄積機能」、「規格対応通信プロトコル機能」及び「通信機能」）は、顧客要件に該当する部分、すなわち、実施例１の処理によってヒアリング項目から特定された、顧客の情報システムに対する要求に対応する項目である。一方、ハッチングした個所（図１５の例では、評価項目「過去の利用実績」及び「規格対応通信プロトコル機能」）は、妥当性評価軸重要項目として、開発コスト低減評価情報１３０１をもとに選択した（すなわち開発コストの低減に寄与する製品セットを選択するために有効な評価項目としてＳＥによって選択された）項目である。図１５は、後述する図２０のステップ２００１で製品セットＡ、製品セットＢ及び製品セットＣが選択され、妥当性評価情報の開発コスト低減評価情報１３０１を利用し、各製品セットの評価を行った例を示す。
【００８５】
図１５に示す評価項目「過去の利用実績」が、図１４の利用実績評価項目１４０１に該当する。図１５の例では、選択された製品セットのうち、製品セットＡと製品セットＢは、過去の利用実績がある。また、インタフェース評価項目１４０２に該当するのは、評価項目「規格対応通信プロトコル機能」であり、これに該当する（すなわち規格対応通信プロトコル機能を有する）製品セットは製品セットＢと製品セットＣである。よって、妥当性評価情報１３００の開発コスト低減評価情報１３０１を使った評価結果として、利用実績評価項目１４０１には製品セットＡ及び製品セットＢが該当し、インタフェース評価項目１４０２には製品セットＢ及び製品セットＣが該当している。すなわち、この例では製品セットＢのみが利用実績評価項目１４０１及びインタフェース評価項目１４０２の両方に該当することから、ここでの評価方法では製品セットＢが一番妥当であると判断できる。
【００８６】
一方、各製品セットが該当する顧客要件の数を比較すると、製品セットＢが最も多くの顧客要件に該当することから、妥当性評価例（開発コスト低減）１５０１の例において、最も妥当性が高い製品セットは製品セットＢという結論になる。
【００８７】
以上の図１３、図１４、図１５を利用して、図２０のフローを説明する。
【００８８】
図２０は、本発明の実施例２のシステム構成検証サーバ１０２が製品セットの妥当性を評価する処理を示すフローチャートである。
【００８９】
ステップ２００１において、ユーザ（例えばＳＥ）は、該当する製品セットを選択する。実施例１で作成した製品セットがシステム構成検証サーバ１０２のソフトウエア構成情報蓄積部３０４に蓄積されているため、クライアント端末１０３を操作するＳＥが製品セットをクライアント端末１０３の出力装置２２２に表示させる。
【００９０】
次に、ステップ２００２では、ＳＥの操作に応じて、クライアント端末１０３が妥当性評価情報１３００を選択する画面を表示する際に、システム構成検証サーバ１０２の妥当性評価項目蓄積部３０３に蓄積された妥当性評価情報１３００の各評価情報を取得し、クライアント端末１０３の出力装置２２２に表示する。ＳＥは出力装置２２２に表示された妥当性評価情報１３００の中から、開発コスト低減評価情報１３０１に該当する評価項目を選択する。
【００９１】
ステップ２００３において、妥当性評価部３０１は、妥当性評価の処理を行う。ＳＥが妥当性評価情報を選択した後、クライアント端末１０３は、システム構成検証サーバ１０２に選択された情報を送信し、システム構成検証サーバ１０２の妥当性評価部３０１において検証処理を開始する。妥当性評価部３０１は、製品セット群が蓄積されているソフトウエア構成情報蓄積部３０４から製品セットを取得し、さらに、クライアント端末１０３から送信されてきた開発コスト低減評価情報１３０１をもとに妥当性評価項目蓄積部３０３にある開発コスト低減評価情報１３０１の評価項目である利用実績評価項目１４０１とインタフェース評価項目１４０２を取得し、評価を実施する。妥当性評価部３０１は、評価が完了すると、通信部３００を介して、クライアント端末１０３へ評価結果を送信する。
【００９２】
ステップ２００４において、評価結果がＳＥに対して表示され、ＳＥがそれを確認する。具体的には、クライアント端末１０３は、ステップ２００３で作成された評価結果をシステム構成検証サーバ１０２から取得し、出力装置２２２へ表示する。この結果（すなわち表示される画面の例）が図１５の妥当性評価例（開発コスト低減）である。図１５を参照して説明したように、この例では、顧客要件及び開発コスト低減における適切な製品セットを抽出した結果、製品セットＢが最も妥当性が高い製品セットであると評価される。
【実施例３】
【００９３】
次に、本発明の実施例３について、図１６及び図１７を参照して説明する。以下に説明する相違点を除き、実施例３のシステムの各部は、図１〜図１５及び図２０に示された実施例１又は２の同一の符号を付された各部と同一の機能を有するため、それらの説明は省略する。
【００９４】
実施例３では、実施例２で評価した開発コスト低減の観点の代わりに、意思決定の評価軸を用いてソフトウエア構成の妥当性を評価する。ここで言う意思決定とは、顧客会社の経営層が会社の課題に対してなんらかの判断を行うことを指している。この意思決定を行う上での判断材料が、実施例１で選択したソフトウエア構成を利用した情報システムから生成される情報である場合、その情報の確度及び信頼性が重要になる。とりわけ、例えば構築される情報システムが広域網を利用する場合、送受信のデータがロスする可能性もあり、ソフトウエア側での対策が必要になる。そこで、実施例１で選択されたソフトウエア構成のいくつかのセットの中から、経営層の意思決定において、十分な情報を提供できるソフトウエア構成になっているか否かを示す妥当性を評価する。
【００９５】
評価を行う処理手順に関しては実施例２で説明したので割愛する（図２０参照）。
【００９６】
図１６は、本発明の実施例３の妥当性評価情報１３００に含まれる意思決定評価情報１３０２の評価項目の説明図である。
【００９７】
ＳＥが提供する情報システムによって提供される情報が経営層の意思決定をする際の判断材料として適切な情報であるかが評価の観点になる。よって、データ品質評価項目１６０１及び実績評価項目１６０２が意思決定評価情報１３０２の要素になる。まず、データ品質評価項目１６０１について説明する。例えば、通信における再送制御機能及び暗号化通信、データベースのアクセス制御が、データ品質評価項目１６０１に相当する。
【００９８】
ＳＥが提供する情報システムを構築する環境において、データの品質を下げるいくつかの要因が存在する。たとえば、ＳＥが構築する情報システムが生成する情報は、顧客の現場システムから取得したデータをもとに生成され、インターネットを経由して、クラウドで分析され、その結果が経営層に提供されているとする。この前提において、インターネットを介在したことによって、収集したデータのいくつかは改ざんされている可能性があるかもしれないし、広域網を利用しているため、パケットロスが発生し、必要なデータがいくつか欠損している可能性もある。このように情報システムが置かれる環境において、データの信頼性を揺るがすリスクを抱えている場合、その対策をとっていなければ、そのデータの信頼性、ひいては、経営層に提供する情報の信頼性は十分でなくなってしまう可能性がある。
【００９９】
このデータの信頼性を獲得するには、インターネットを経由する場合にはセキュリティ対策を施し、データ欠損の可能性があれば、通信に再送制御機能を搭載するなどの対策が必要になる。ＳＥが提供する情報システムにおいて、とりわけ情報システムを構成するソフトウエア構成においては、その対策がなされているものを選択しているかが重要な評価観点となる。
【０１００】
次に実績評価項目１６０２を説明する。これは開発コスト低減評価情報１３０１の利用実績評価項目１４０１と同じ情報である。これを意思決定評価情報１３０２の評価項目としているのは、選択するソフトウエア自体の信頼性を評価するためである。採用実績が高ければ、それまで内在していたソフトウエアの問題が既に取り除かれている可能性が高く、そのソフトウエアの障害リスクが減少することを示すためである。この評価項目は、意思決定においてソフトウエアが生成する情報の信頼性に影響する。
【０１０１】
図１７は、本発明の実施例３の意思決定評価情報１３０２の一例である妥当性評価例（意思決定）１７０１の説明図である。
【０１０２】
図１７の妥当性評価例（意思決定）１７０１に含まれるカテゴリ１７０２、項目１７０３、顧客要件該当１７０４及び製品セットＡ１７０５〜製品セットＣ１７０７は、それぞれ図１５のカテゴリ１５０２、項目１５０３、顧客要件該当１５０４及び製品セットＡ１５０５〜製品セットＣ１５０７と同様であるため、説明を省略する。
【０１０３】
妥当性評価例（意思決定）１７０１の表の中で顧客重要項目として枠で囲んである個所（図１７の例では、評価項目「英語ＯＳでの動作」、「顧客管理機能」、「構造データ蓄積機能」、「規格対応通信プロトコル機能」及び「通信機能」）が、顧客要件に該当する部分であり、ハッチングした個所（図１７の例では、評価項目「過去の利用実績」及び「再送制御機能」）が妥当性評価軸重要項目として、意思決定評価情報１３０２をもとに選択した（すなわち意思決定に寄与する製品セットを選択するために有効な評価項目としてＳＥによって選択された）項目である。図１７は、図２０のステップ２００１で製品セットＡ、製品セットＢ及び製品セットＣが選択され、妥当性評価情報の意思決定評価情報１３０２を利用し、各製品セットの評価を行った例を示す。
【０１０４】
図１５に示す評価項目「過去の利用実績」が、図１４の実績評価項目１６０２に該当する。図１７の例では、選択された製品セットのうち、製品セットＡと製品セットＢは、過去の利用実績がある。また、データ品質評価項目１６０１に該当するのは、評価項目「再送制御機能」であり、これに該当する（すなわち再送制御機能を有する）製品セットは製品セットＡ、製品セットＢ及び製品セットＣである。よって、妥当性評価情報１３００の意思決定評価情報１３０２を使った評価結果として、実績評価項目１６０２には製品セットＡ及び製品セットＢが該当し、データ品質評価項目１６０１には製品セットＡ、製品セットＢ及び製品セットＣが該当している。すなわち、この例では製品セットＡ及び製品セットＢが利用実績評価項目１４０１及びインタフェース評価項目１４０２の両方に該当することから、ここでの評価方法では製品セットＡ及び製品セットＢが妥当であると判断できる。
【０１０５】
一方、各製品セットが該当する顧客要件の数を比較すると、製品セットＢが最も多くの顧客要件に該当することから、妥当性評価例（意思決定）１７０１の例において、最も妥当性が高い製品セットは製品セットＢという結論になる。
【実施例４】
【０１０６】
次に、本発明の実施例４について、図１８及び図１９を参照して説明する。以下に説明する相違点を除き、実施例４のシステムの各部は、図１〜図１７及び図２０に示された実施例１〜３の同一の符号を付された各部と同一の機能を有するため、それらの説明は省略する。
【０１０７】
実施例４では、実施例２における妥当性の評価軸を、横展開容易性として実施例１で抽出したソフトウエア構成のセットの妥当性を評価する。ここで、横展開とは、ある情報システムに適用されたソフトウエア製品を他の情報システムに（変更なしで、又は必要最小限の変更を加えたうえで）適用することである。例えば、他の情報システムに適用するための変更が容易であるほど横展開が容易であると判定してもよい。
【０１０８】
評価を行う処理手順に関しては実施例２で説明したので割愛する（図２０参照）。
【０１０９】
図１８は、本発明の実施例４の妥当性評価情報１３００に含まれる横展開容易性評価情報１３０３の評価項目の説明図である。
【０１１０】
ある顧客へ提供した情報システムをサービス化し、収益のＮ倍化を想定した場合、構築した情報システムが、様々な国へ提供可能なのか、業種が変わっても対応可能か、クラウド化が可能かなどの観点で情報システムの評価が必要になる。よって、横展開容易性評価情報１３０３は、商流評価項目１８０１、インタフェース評価項目１８０２及び提供形態評価項目１８０３という要素を含む。
【０１１１】
まず、商流評価項目１８０１について説明する。商流評価項目１８０１は、選択するソフトウエアの商流について評価する項目である。提供先の国における保守体制や提供実績、現地環境での動作確認実績などが評価項目となる。次に、インタフェース評価項目１８０２について説明する。横展開を考えたときに、提供先顧客がこれまで情報システムを提供していた顧客と同業種であれば、多少のカスタマイズを行った上で提供できる可能性があるが、他業種で同じ課題を解決したい場合、モニタする対象が変わり、データの収集方法も変わる可能性がある。このときインタフェースの変更が容易であれば、他業種への横展開も容易である。機能としてはマルチプロトコルに対応している場合及び標準化に対応している場合などが、肯定的な評価の対象となる。
【０１１２】
次に提供形態評価項目１８０３について説明する。Ｎ倍化を考えたときに、個別のシステムインテグレーション（以下ＳＩ）を実施するのではなく、クラウド化してサービスとして提供する方が望ましい。そのため提供形態評価項目１８０３では、製品がクラウド化可能であるかの判断基準が評価項目となる。
【０１１３】
次に、図１９の妥当性評価例（横展開容易性評価情報）１９０１について説明する。
【０１１４】
図１９は、本発明の実施例４の横展開容易性評価情報１３０３の一例である妥当性評価例（横展開容易性評価情報）１９０１の説明図である。
【０１１５】
図１９の妥当性評価例（横展開容易性評価情報）１９０１に含まれるカテゴリ１９０２、項目１９０３、顧客要件該当１９０４及び製品セットＡ１９０５〜製品セットＣ１９０７は、それぞれ図１５のカテゴリ１５０２、項目１５０３、顧客要件該当１５０４及び製品セットＡ１５０５〜製品セットＣ１５０７と同様であるため、説明を省略する。
【０１１６】
妥当性評価例（横展開容易性評価情報）１９０１の表の中で顧客重要項目として枠で囲んである個所（図１９の例では、評価項目「クラウド対応可能」、「英語ＯＳでの動作」、「顧客管理機能」、「構造データ蓄積機能」、「規格対応通信プロトコル機能」及び「通信機能」）が、顧客要件に該当する部分であり、ハッチングした個所（図１９の例では、評価項目「クラウド対応可能」、「顧客間で障害が波及無」、「マニュアルの英語化」、「英語ＯＳでの動作」及び「規格対応通信プロトコル機能」）が妥当性評価軸重要項目として、横展開容易性評価情報１３０３をもとに選択した（すなわち横展開を容易性に寄与する製品セットを選択するために有効な評価項目としてＳＥによって選択された）項目である。図１９は、図２０のステップ２００１で製品セットＡ、製品セットＢ及び製品セットＣが選択され、妥当性評価情報の横展開容易性評価情報１３０３を利用し、各製品セットの評価を行った例を示す。
【０１１７】
図１９の例では、評価項目「マニュアルの英語化」及び「英語ＯＳでの動作」が商流評価項目１８０１に相当し、製品セットＡ及び製品セットＢがこれに該当する。また、インタフェース評価項目１８０２に該当するのは、図１９の評価項目「規格対応通信プロトコル機能」であり、製品セットＢ及び製品セットＣがこれに該当する。また、評価項目「クラウド対応可能」及び「顧客間で障害が波及無」は提供形態評価項目１８０３に相当し、これに該当するのは、製品セットＢ及び製品セットＣである。よって、ここでの評価方法では、最も多くの妥当性評価項目に該当する製品セットＢが妥当であると判断できる。
【０１１８】
一方、各製品セットが該当する顧客要件の数を比較すると、製品セットＢが最も多くの顧客要件に該当することから、妥当性評価例（横展開容易性評価情報）１９０１の例において、最も妥当性が高い製品セットは製品セットＢという結論になる。
【０１１９】
上記の実施例２〜４では、複数のソフトウエア製品からなる製品セットを評価する例を示したが、同様の方法で各ソフトウエア製品を評価することもできる。
【０１２０】
上記の実施例２〜４では、システム構成検証サーバ１０２は、各製品セットが該当する顧客重要項目及び妥当性評価軸重要項目の数を計数し、その結果を出力している（ステップ２００４）。その数が大きい製品セットほど妥当であると判定することができる。このとき、システム構成検証サーバ１０２は、単に該当する項目の数を計数するのではなく、該当する項目の数に、予め定められた優先順位に基づいて重み付けをして、それを計数してもよい。顧客重要項目の重み付けは、実施例１において説明した通りである。
【０１２１】
妥当性評価軸重要項目への重み付けは、各項目を対象として行われてもよいし、項目の分類ごとに行われてもよい。例えば図１９の例では、５個の妥当性評価軸重要項目が、商流評価項目１８０１、インタフェース評価項目１８０２及び提供形態評価項目１８０３に分類される。例えばＳＥが商流評価項目１８０１を最重要視している場合には、それに分類される評価項目「マニュアルの英語化」及び「英語ＯＳでの動作」に高い優先順位が付与され、それに応じた重み付けをして該当する項目数が計数される。
【０１２２】
このように、高い優先順位が付与された評価項目に該当する製品セットにより高いスコアが与えられることとなり、情報システムに採用されやすくなる。予め重視する評価項目に高い優先順位を付与しておくことで、適切な製品セットを選択することが容易になる。
【０１２３】
妥当性評価情報１３００は、実施例１から４までで説明した評価情報だけでなく、詳細な説明は省略するが、保守観点なども存在する。それぞれ評価項目を決定し、製品セットを評価することによって、様々な観点で評価することが可能になる。また、さらに各評価情報による製品セットの評価を一度に表示することによって、ＳＥがソフトウエア構成を検証するのが容易になる。
【０１２４】
以上の本発明の実施例２〜４によれば、構築される情報システムのソフトウエアコンポーネントのセットが、種々のステークホルダの要件に対して妥当であるか否かを判断するために、構成するソフトウエアコンポーネントが同じ評価軸で評価される。これによって、それぞれの評価項目の中で上記の様々なステークホルダの要件がどの項目に該当するかが具体化され、各要件の妥当性を評価することが可能になる。
【０１２５】
なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【０１２６】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によってハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによってソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。
【０１２７】
また、制御線及び情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【０１２８】
１０１  蓄積サーバ
１０２  システム構成検証サーバ
１０３  クライアント端末
１０４  ネットワーク
２００、２１０、２２０  主記憶装置
２０１、２１１、２２１  中央演算装置
２０２、２１２、２２２  出力装置
２０３、２１３、２２３  入力装置
２０４、２１４、２２４  蓄積部
２０５、２１５、２２５  ネットワークインタフェース部
２０６、２１６、２２６  バス
３００  通信部
３０１  妥当性評価部
３０２  変換処理部
３０３  妥当性評価項目蓄積部
３０４  ソフトウエア構成情報蓄積部
３０５  製品対応表蓄積部
３０６  機能対応表蓄積部
３０７  要件対応表蓄積部
３０８  ヒアリング項目蓄積部
【図１】
2017027278.tif 000003
【図２】
2017027278.tif 000004
【図３】
2017027278.tif 000005
【図４】
2017027278.tif 000006
【図５】
2017027278.tif 000007
【図６】
2017027278.tif 000008
【図７】
2017027278.tif 000009
【図８】
2017027278.tif 000010
【図９】
2017027278.tif 000011
【図１０】
2017027278.tif 000012
【図１１】
2017027278.tif 000013
【図１２】
2017027278.tif 000014
【図１３】
2017027278.tif 000015
【図１４】
2017027278.tif 000016
【図１５】
2017027278.tif 000017
【図１６】
2017027278.tif 000018
【図１７】
2017027278.tif 000019
【図１８】
2017027278.tif 000020
【図１９】
2017027278.tif 000021
【図２０】
2017027278.tif 000022