(57)【要約】【課題】サービス開発において、ユーザの要求からサービス機能を設計し、機能実装および提供するまでを標準的な枠組みで手順化し、効率よくサービス開発を行う方法を提供すること。【解決手段】サービス設計を組織ドメイン、役割ドメイン、リソースドメインの設計領域に分け、設計過程に沿って連続するドメイン間においてパラメータの転写行う段階と、設計行列および設計パラメータベクトルを用いて設計制約を抽出する段階と、から成る公理的サービス設計方法を提供する。【選択図】図３
2011221782.tif 000002
【特許請求の範囲】
【請求項１】
サービスに関する設計ドメイン指標を設定、選択する設計ドメイン指標選択段階と、前記設計ドメイン指標を保管する設計ドメイン指標保管段階と、前記設計ドメイン指標を用いて、設計情報の妥当性を判定する設計情報判定段階と、前記設計情報の妥当性が認められない場合、設計制約を表示する設計制約表示段階と、を備えることを特徴とする公理的サービス設計方法。
【請求項２】
前記設計ドメイン指標選択段階は、サービスに対する要求から要求を実現する機能に展開するまでの過程に沿って、組織ドメイン、役割ドメイン、リソースドメインを含む設計ドメインに分離し、前記設計情報判定段階は、各々のドメインは指標の候補を備え、ドメイン間の指標の紐付けする機能を備えることを特徴とする請求項１の公理的サービス設計方法。
【請求項３】
前記設計情報判定段階は、前記設計情報として、設計行列及び設計パラメータベクトルを構築する機能を構築する機能を備え、これらの構築によって設計制約となる項目を抽出する機能を備え、これによって、前記設計情報の妥当性を判定することを特徴とする請求項１の公理的サービス設計方法。
【請求項４】
サービスに関する設計ドメイン指標を設定する設計ドメイン指標設定部と、前記設計ドメイン指標を選択する設計ドメイン指標選択部と、前記設計ドメイン指標を保管する設計ドメイン指標保管部と、前記設計ドメイン指標を用いて設計情報の妥当性を判定する設計情報判定部と、前記設計情報の妥当性が認められない場合、設計制約を表示する設計制約表示部、を備えていることを特徴とする公理的サービス設計装置。
【請求項５】
前記設計ドメイン指標選択部は、サービスに対する要求から要求を実現する機能に展開するまでの過程に沿って、組織ドメイン、役割ドメイン、リソースドメインを含む設計ドメインに分離し、前記設計情報判定部は、各々のドメインは指標の候補を備え、ドメイン間の指標の紐付けする機能を備えることを特徴とする請求項４の公理的サービス設計装置。
【請求項６】
前記設計情報判定部は、前記設計情報として、設計行列及び設計パラメータベクトルを構築する機能を備え、これらの構築によって設計制約となる項目を抽出する機能を備え、これによって、前記設計情報の妥当性を判定することを特徴とする請求項４の公理的サービス設計装置
【請求項７】
コンピュータに、サービスに関する設計ドメイン指標を設定、選択する設計ドメイン指標選択段階と、前記設計ドメイン指標を保管する設計ドメイン指標保管段階と、前記設計ドメイン指標を用いて、設計情報の妥当性を判定する設計情報判定段階と、前記設計情報の妥当性が認められない場合、設計制約を表示する設計制約表示段階と、を実行させることを特徴とする公理的サービス設計プログラム。
【請求項８】
前記設計ドメイン指標選択段階では、サービスに対する要求から要求を実現する機能に展開するまでの過程に沿って、組織ドメイン、役割ドメイン、リソースドメインを含む設計ドメインに分離するステップを行わせ、且つ、前記設計情報判定段階では、各々のドメインは指標の候補を備え、ドメイン間の指標の紐付けるステップを、コンピュータに実行させることを特徴とする請求項７の公理的サービス設計プログラム
【請求項９】
前記設計情報判定段階では、コンピュータに、設計行列及び設計パラメータベクトルを構築する機能と、これらの構築によって設計制約となる項目を抽出する機能を実行させることを特徴とする請求項８の公理的サービス設計プログラム。
【請求項１０】
前記設計情報判定段階では、前記設計行列として、前記設計ドメインに対する機能要求と、当該機能要求に対するプロセス変数との間の行列を作成し、当該行列が対角行列か、三角行列かを判定することによって、干渉設計か否かをコンピュータに判定させ、且つ、前記設計ドメインに対する機能要求に対するプロセス変数が対応関係に無い場合、機能制約と判定することを特徴とする請求項９の公理的サービス設計プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はサービス設計システム、サービス設計方法およびサービス設計用プログラムに関し、特に、設計公理に基づくサービス設計システム、サービス設計方法およびサービス設計用プログラムに関する。
【背景技術】
【０００２】
非特許文献１では、ユーザの要求から設計情報へ変換する手順の概念として、主に機械工学の分野で、公理的設計（ＡＸＩＯＭＡＴＩＣ  ＤＥＳＩＧＮ）の基礎概念が提案されている。この基礎概念は、顧客ニーズを知り、ニーズを満たすために解決しなければならない問題を設定し、統合を通して解を概念化し、解の最適化のため分析を実行し、設計解を確認する、といった設計行為に共通する項目に対し、それぞれの行為を写像関係で表現している。顧客ニーズ（ＣＵＳＴＯＭＥＲ  ＡＴＴＲＩＢＵＴＥ：ＣＡ）は機能要求（ＦＵＮＣＴＩＯＮＡＬ  ＲＥＱＵＩＲＥＭＥＮＴＳ：ＦＲ）に転写され、ＦＲは設計パラメータ（ＤＥＳＩＧＮ  ＰＡＲＡＭＥＴＥＲ：ＤＰ）に転写され、ＤＰはプロセス変数（ＰＲＯＣＥＳＳ  ＶＡＲＩＡＢＬＥ：ＰＶ）に転写される（図１）。
【０００３】
この基礎概念では、二つの公理を確認している。公理１は独立公理（ＩＮＤＥＰＥＮＤＥＮＣＥ  ＡＸＩＯＭ）と呼ばれ、要求機能（ＦＲ）は設計目標を記述する「最小個数の独立した必要条件」として定義され、ＦＲの独立性は常に保たれる。公理２は、情報公理（ＩＮＦＯＲＭＡＴＩＯＮ  ＡＸＩＯＭ）と呼ばれ、独立公理を満たす設計の中で最小の必要情報量をもつものを最良の設計とする。
【０００４】
この基礎概念は、ソフトウェア、構造物、大型システム、物質・材料など、物質・製品（プロダクト）を対象に設計方法への適用が図られている。しかしながら、公理的設計概念をサービスの設計に適用することは行われていないのが実情である。
【０００５】
公理に基づく設計として、特許文献１がある。特許文献１では、ＵＭＬ(Unified Modeling Language)のような図式表記で表現された製品のＵＩ(User Interface)挙動仕様を自動的に検証できるＵＩ設計検証装置を提供することを目的としている。表明変換用公理、検証用公理を備えている。特許文献１はＵＩを対象としたもので、非特許文献１と同様に物質・製品を対象としており、オペレータなど人間系の行為として表現される機能を検証することは困難である。また、特許文献１は、機能設計された後の設計情報を、公理を用いて検証するものであり、公理を用いて設計の過程を検証することは困難である。
【０００６】
サービス設計プロセスの方法として、特許文献２で提案された方法がある。特許文献２は、サービスのユーザの振る舞いを基点に、サービス提供者から提供されるべき物理的な機能やオペレータなど人間系で提供される機能を同定する設計方法を記載している。この方法は、サービス設計においてサービスを機能展開する方法を示し、ユーザに対する機能およびその品質を最適化できる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００６−２８５６２６
【特許文献２】特願２００９−０７８３０８
【非特許文献】
【０００８】
【非特許文献１】Ｎａｍ  Ｐ．Ｓｈｕ，Ａｘｉｏｍａｔｉｃ  Ｄｅｓｉｇｎ  Ｔｈｅｏｒｙ  ｆｏｒ  Ｓｙｓｔｅｍｓ，Ｒｅｓｅａｒｃｈ  ｉｎ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｄｅｓｉｇｎ，ｐｐ．１８９−２０９，１９９８
【発明の開示】
【発明が解決しようとする課題】
【０００９】
特許文献２では、設計された機能をサービス提供者内のリソースを鑑みて提供プロセスを最適化することについては、何等、考慮されていない。更に、特許文献２は、特定の時点における設計情報をスタティックに評価しており、異なる時点で出される要求をダイナミックに取り込む場合における対処方法については記載されていない。
【００１０】
更に、非特許文献１に記載された公理的設計をサービス設計に適用しようとしても、公理的設計概念で用いられるＦＲ、ＤＰ、ＰＶなど個々のパラメータが製品機能にマップされているため、サービスの設計に適用することは困難であった。その理由は、オペレータなど人間系の行為は目に見える機能でなく、表現方法が規定されないため、パラメータ化することなどが困難なためである。
【００１１】
他方、新サービスの開発における問題は、一般に、設計フェーズおよび実装フェーズの開発プロセスを予定通りに実行することがしばしば困難になることである。その理由は、新サービス開発時点において、通常、現行のサービスを提供しており、この現行サービス提供と共存するためである。また、新サービス開発は、現行サービスに関わるステークホルダやプロセス、リソースから要求や制約を受けているためである。
【課題を解決するための手段】
【００１２】
上記した点を考慮して、本発明は、一般のサービス開発において、ユーザの要求からサービス機能を設計し提供するまでの時間的な過程を段階的に即ちダイナミックに規定し、また設計段階で生じる制約を形式化することで、設計工程で効率良く行うサービス開発方法を提案する。
【００１３】
即ち、本発明の基本的概念は、新サービスの開発において、ユーザ要求から機能設計や機能実装までの設計プロセスを、サービス開発一般に共通する過程で標準的に細分化し、設計パラメータや設計制約の判定を標準的に示すことで、サービス設計過程間の遷移を容易にし、サービス設計プロセスの管理を容易にするシステムを提供することにある。
【００１４】
図２を参照して、本発明の概念的な構成を説明する。サービスの設計の段階、即ち、フェーズは、（１）ユーザの要求やサービス提供者の要求を捉え、要求の実現にあたり、（２）サービス提供者内の役割が担う機能を設計する。このため、本発明は、サービス提供者をその内部の組織として認識する。この場合、図２の上部に示すように、サービス提供者内の組織は、概念的に、ユーザ及びサービス提供者の要求に応える組織ドメイン１として認識することができ、且つ、この組織ドメイン１は、個人ドメイン２、役割ドメイン３、及び、リソースドメイン４に細分化でき、各ドメインに応じた機能をユーザ及びサービス提供者の要求を対応させ、設計された機能が得られる。更に、（３）設計された機能を物質資源や人的資源を用いて実装する、といった過程をとる（図２の下部）。（１）〜（２）に遷移する際、全体の組織目標は、現業があるため個別の役割に必ずしも展開できず、制約が生じる（即ち、個人或いは役割ドメイン２、又は３に、衝突、矛盾が生じる）。また、（２）〜（３）に遷移する際、個々の設計情報は、現業に使われる資金や資源量があるため、必ずしも必要十分なリソースが確保できず制約が生じる（即ち、リソースドメインに衝突、矛盾が生じる）。
【００１５】
即ち、本発明の概念は、サービスに関する設計ドメイン指標を要求事項として設定し、当該要求事項に応じてサービス機能、及び、サービスリソースを関連付けると共に、リソースに関する制約の有無を判断することにある。
【００１６】
より具体的に説明すると、サービスの開発プロセスの各フェーズで、サービスに関する機能要求項目、設計パラメータ、リソース項目等を定義しておき、次のフェーズに移行する際に、前のフェーズで定義された項目を次のフェーズに規定する項目に転写するステップを繰り返している。この手法は、公理的設計手法を使用しているが、本発明は、転写の過程で生じる転写できない要素が出てきた場合に、当該非転写要素を設計上生じ得る制約として定義し、この場合における指標群及び判定機構を規定している点を特徴としている。このように、本発明は、順次転写を行うことにより時間軸に沿ったダイナミックなサービス設計方法を実現している点で、特許文献２と相違している。
【００１７】
このような概念を実現する本発明の一形態に係る公理的サービス設計方法は、サービスに関する設計ドメイン指標を設定、選択する設計ドメイン指標選択段階と、前記設計ドメイン指標を保管する設計ドメイン指標保管段階と、前記設計ドメイン指標を用いて、設計情報の妥当性を判定する設計情報判定段階と、前記設計情報の妥当性が認められない場合、設計制約を表示する設計制約表示段階と、を備えることを特徴とする公理的サービス設計方法が得られる。
【００１８】
また、本発明の他の形態である、公理的サービス設計装置は、サービスに関する設計ドメイン指標を選択する選択部と、設計ドメイン指標を保管する保管部と、設計情報判定部と、設計制約表示部と、から成る。
【００１９】
本発明の更に他の形態である、公理的サービス設計プログラムは、コンピュータを、設計ドメイン指標選択手段と、設計ドメイン指標保管手段と、設計情報判定手段と、設計制約表示手段として、動作させる。
【発明の効果】
【００２０】
第一の効果は、サービス設計行為が標準的になり、機械的なサービス生産が可能になることである。
【００２１】
その理由は、サービス設計行為を、要求事項と、要求を実現するサービス機能、また機能を実現するリソースに分解し、それぞれの各項目を関係付けることと規定したためである。また、設計行列および設計パラメータベクトルにより、設計上の制約条件を形式的に捉えることが可能になるためである。
【００２２】
第二の効果は、サービス開発におけるコンカレントエンジニアリングが可能になり、設計段階において生産検討の開始判断ができることである。
【００２３】
製品設計では、新しい設備の資本投資を最小限に抑えるために既存のプロセスを利用しなければならないとき、既存のプロセス変数（ＰＶ）を使用するので、デザインパラメータ（ＤＰ）を選択する際にはそれらが制約として働く。製品開発では、製品設計とプロセス設計は同時に考慮する必要があり、これをコンカレントエンジニアリングと呼ぶ。この場合、
｛ＦＲ｝＝［Ａ］｛ＤＰ｝が示す製品設計と
｛ＤＰ｝＝［Ｂ］｛ＰＶ｝が示すプロセス設計との
両者が独立公理を満たす必要がある。
【００２４】
このとき独立公理を満たす条件は、行列［Ｃ］＝［Ａ］［Ｂ］の積は対角か三角である。
【００２５】
第二の効果が得られる理由は、前記製品開発と同様にコンカレントエンジニアリングの実行性を判断できるためである。換言すれば、対角或いは三角行列［Ｃ］が得られれば、サービス開発においてコンカレントエンジニアリングが可能となる。
【図面の簡単な説明】
【００２６】
【図１】設計領域を示す図である。
【図２】公理的サービス設計領域を示す図である。
【図３】公理的サービス設計装置を示す図である。
【図４】組織ドメイン指標の構成要素の一例を示す図である。
【図５】役割ドメイン指標の構成要素の一例を示す図である。
【図６】リソースドメイン指標の構成要素の一例を示す図である。
【図７】設計行列の一例を示す図である。
【図８】設計パラメータベクトルの一例を示す図である。
【図９】公理的サービス設計装置１００の動作を説明するフローチャートである。
【図１０】教育サービスの構成の一例を示す図である。
【図１１】教育サービスの設計行列の一例を示す図である。
【図１２】教育サービスの設計パラメータベクトルの一例を示す図である。
【発明を実施するための形態】
【００２７】
本発明の一実施形態に係る公理的サービス設計装置１００について、図３、図４、図５、図６、図７、及び、図８を用いて説明する。
【００２８】
図３に示す公理的サービス設計装置１００は、サービス設計ドメイン指標１１０と、ドメイン情報編集部１２０と、ドメイン情報保管部１３０と、設計情報判定部１４０と、設計制約表示部１５０と、から成る。
【００２９】
図示されたサービス設計ドメイン指標１１０は、組織ドメイン指標１１１と、役割ドメイン指標１１２と、リソースドメイン指標１１３、とから成り、ハードウェア的には、組織ドメイン指標１１１、役割ドメイン指標１１２、及びリソースドメイン指標１１３を格納するメモリによって構成されている。また、ドメイン情報編集部１２０及び設計情報判定部１４０は、ＣＰＵによって実行されるソフトウェアであっても良いし、ハードウェア回路によって構成されても良い。更に、ドメイン情報保管部１３０はメインメモリによって構成され、設計制約表示部１５０はディスプレイ装置によって構成される。
【００３０】
図示された設計情報判定部１４０は、設計行列管理部１４１と設計パラメータベクトル管理部１４２を持っている。
【００３１】
組織ドメイン指標１１１は、サービス提供企業の事業部やサービス提供事業者の要求項目である。図４に組織ドメイン指標１１１の例を示す。組織ドメイン指標１１１には、ユーザがサービス提供者に対して期待する機能や品質に関する要求事項と、売上高や従業員などサービス提供者内の要求事項が要素として含まれる。即ち、組織ドメイン指標１１１は、サービス提供企業の事業部、サービス提供事業者の要求項目を数値化したものである。
【００３２】
役割ドメイン指標１１２は、組織ドメイン指標１１１を達成するために、組織ドメインの要求を実行するサービス提供者内の小組織の要求項目である。この小組織は、配送部門やオペレータ部門など分担された役割を担う。図５に役割ドメイン指標１１２の例を示す。役割ドメイン指標１１２には、生産計画達成率や保守品質など前記小組織の役割によって目標設定される指標が要素として含まれる。
【００３３】
リソースドメイン指標１１３は、役割ドメイン指標１１２を達成するために、サービス開発上、必要とされるリソースを示す。図６にリソースドメイン指標１１３の例を示す。リソースドメイン指標１１３には、原材料費、設備費、労働力などの指標（数値）が要素として含まれる。
【００３４】
図７は、設計行列を示し、図７では、機能要求ＦＲ１〜７と、設計パラメータＤＰ１〜９との関係が例示されている。図７は、ＦＲ５に対応したＤＰが存在しない場合（ＤＰ５、ＤＰ８、及びＤＰ９が０）を示しており、設計制約がある場合が示されている。ここで、設計制約は、機能制約と、リソース制約のいずれかとなる。
【００３５】
図８は、ナレッジ、プロセス、及びマネジメントをそれぞれ３次元座標のｘ，ｙ，ｚ軸に対応させた場合における設計パラメータベクトルを示す。図８では、理想とされる設計リソース（組織ゴールベクトル）と、３つの役割ゴールベクトルによって定まる現実のリソースとの間の差異がベクトルのずれとなり、そのずれが制約の程度を示す。
【００３６】
次に、図３に示された公理的サービス設計装置１００の動作について、説明する。ここでは、図９を用いて、本発明の一形態を説明する。組織ドメイン指標１１１を用いて組織ドメインをドメイン情報編集部１２０に記述する（ステップＳ１１１）。この段階は、サービス設計ドメイン指標１１０を選択する設計ドメイン指標選択段階であり、ドメイン情報編集部１２０は設計ドメイン指標選択部を構成している。
【００３７】
次に、役割ドメイン指標１１２を用いて役割ドメインをドメイン情報編集部１２０に記述する（ステップＳ１１２）。これらの情報は、ドメイン情報保管部１３０に蓄積される。この蓄積段階は、設計ドメイン指標保管段階であり、ドメイン情報保管部１３０は設計ドメイン指標保管部を構成している。
【００３８】
設計情報判定部１４０は、ドメイン情報保管部１３０に蓄積された情報を読み取り、設計行列を作成し、設計行列を用いて設計の妥当性を判断する（ステップＳ１１３）。このように、設計情報判定部１４０は設計情報判定段階を実行する。
【００３９】
設計情報判定段階で、干渉設計があると判定された場合、ステップＳ１１１に戻り、干渉設計が少なくなるように設計を見直す。冗長設計があると判定された場合も同様に、ステップＳ１１１に戻り、干渉設計が少なくなるように設計を見直す。ここで、図７に示すように、設計行列の縦軸にあるＦＲと対応関係にない、横軸のＤＰ項目を機能制約とする。機能制約は、設計制約表示部１５０に表示される。
【００４０】
干渉設計がないと判断された場合、設計情報判定部１４０は、ステップＳ１１２で設計された役割ドメイン記述に対応する、現状保有する役割ドメイン（ＡｓＩｓ役割ドメイン）を記述する（ステップＳ１２１）。次に、組織ドメインと役割ドメインの項目を設計行列により比較し、機能制約を抽出する（ステップＳ１２２）。また、このとき、設計パラメータベクトル管理部１４２の設計パラメータベクトルを用いて、ステップＳ１１２で設計された役割ドメインと、ステップＳ１２１で記述した現状の役割ドメインの項目の属性値量を比較し、差異を詳細に抽出してもよい。
【００４１】
また、設計情報判定部１４０は、ステップＳ１２１と独立したプロセスで、役割ドメインに対応するリソースドメインを記述する（ステップＳ１３１）。更に、ステップＳ１２１と同様に、現状保有するリソースドメイン（ＡｓＩｓリソースドメイン）を記述する（ステップＳ１３２）。次に、設計行列管理部１４１の設計行列を用いて、役割ドメインとリソースドメインの項目を比較し、リソース制約を抽出する（ステップＳ１３３）。また、このとき設計パラメータベクトルを用いて、ステップＳ１３１で設計されたリソースドメインと、ステップＳ１３２で記述した現状のリソースドメインの項目の属性値量を比較し、差異を詳細に比較しても良い（ステップＳ１３３）。ステップＳ１２２およびＳ１３３で用いた設計行列を用い、準独立・独立設計判断を行う（ステップＳ１４1)。準独立・独立設計の場合、機能設計を詳細化していくのと並行して、リソースの準備を開始してよい。
【実施例】
【００４２】
次に、第一の実施形態に基づく、実施例を図１０、図１１、図１２を用いて更に具体的に説明する。
【００４３】
図１０は、Ｅラーニングサービス事業者が、ユーザ企業に対してサービスを提供する場合のステークホルダの関係を示したものである。サービス提供側（例えば、図９のシステムベンダ）とサービス利用側（例えば、クライエント会社）の二者関係は、教育コンテンツ作成者、ラーニングシステム運用者、教育コース計画策定者、教育コース運営者、人事教育担当者、受講者といったステークホルダの関係に分解される。サービスを構成する人間系が提供される行為も機能と扱うことで、これらのステークホルダからのサービスに対する要求（ＦＲ）と、要求を実現する機能（ＤＰ）と、機能を実現するプロセス変数（ＰＶ）は、図１１のように整理される。
【００４４】
具体的に説明すると、図１０に示された例の場合、ステークホルダからのサービス要求は、コース編成要求ＦＲ１、システム動作設計要求ＦＲ２、構成要素作成要求ＦＲ３、Ｅ−ラーニングコンテンツ開発要求ＦＲ４、コース報知要求ＦＲ５、ラーニング進捗状況確認要求ＦＲ６、学生サポート要求ＦＲ７、レポート提出要求ＦＲ８、及びコース評価要求ＦＲ９に区分されている。このうち、ＦＲ１で示されたサービス要求であるコース編成要求は、コース提案作成要求ＦＲ１１及びグループトレーニング編成要求ＦＲ１２に細分化されている。また、システム動作設計要求ＦＲ２は、システム安全確保要求ＦＲ２１、システムサポート要求ＦＲ２２、及び動作役割決定要求ＦＲ２３に細分化されており、更に、Ｅ−ラーニングコンテンツ開発要求ＦＲ４は、論理及び物理設計要求ＦＲ４１及びコンテンツをサーバにアップロードするアップロード要求ＦＲ４２に細分化されている。
【００４５】
更に、ラーニング進捗状況確認要求ＦＲ６は、ラーニング状態管理要求ＦＲ６１及びラーニング状態報告要求ＦＲ６２に分けられ、レポート提出要求ＦＲ８は完了状態報告要求ＦＲ８１及びアンケート回収要求ＦＲ８２に分けられている。また、コース評価要求ＦＲ９は、目的達成度評価要求ＦＲ９１及びコースに対するユーザ要求を反映させる反映要求ＦＲ９２に分けられている。
【００４６】
図１１には、上記した要求ＦＲ１１〜ＦＲ９２を実現する機能ＤＰ１１〜ＤＰ９２が記載されており、更に、機能ＤＰ１１〜ＤＰ９２を実現するプロセス変数（ＰＶ）ＰＶ１１〜ＰＶ９２、即ち、リソースの容量等が定められている。
【００４７】
図１２ではＦＲとＰＶの各項目の対応関係を、設計行列を用いて評価している。図示された設計行列では、×印で示されるＦＲとＰＶの対応する箇所が対角線上にあり、独立性が保たれていると判定できる。即ち、図１２には、各ドメイン間の指標の関連付け、即ち、紐付けを行った結果が示されている。
【００４８】
各ＰＶの属性を更に比較する場合、ＦＲから期待されるＰＶ属性と、現実リソースのＰＶ属性を、ベクトルを用いて比較し、その程度のずれを詳細に定量化することもできる。
【産業上の利用可能性】
【００４９】
本発明によれば、機能制約が形式的に抽出可能になることで、サービス提供事業者が新サービスを開発する際に、サービス開発過程で生じる品質低下要因を判断することが可能になる。また、リソース制約が形式的に抽出可能になることで、新サービスを開発する際にサービス設計者は現在提供中のサービス運用リソースを考慮することが可能になる。
【符号の説明】
【００５０】
１００  公理的サービス設計装置
１１０  サービス設計ドメイン指標
１１１  組織ドメイン指標
１１２  役割ドメイン指標
１１３  リソースドメイン指標
１２０  ドメイン情報編集部
１３０  ドメイン情報保管部
１４０  設計情報判定部
１４１  設計行列管理部
１４２  設計パラメータベクトル管理部
１５０  設計制約表示部
【図１】
2011221782.tif 000003
【図２】
2011221782.tif 000004
【図３】
2011221782.tif 000005
【図４】
2011221782.tif 000006
【図５】
2011221782.tif 000007
【図６】
2011221782.tif 000008
【図７】
2011221782.tif 000009
【図８】
2011221782.tif 000010
【図９】
2011221782.tif 000011
【図１０】
2011221782.tif 000012
【図１１】
2011221782.tif 000013
【図１２】
2011221782.tif 000014