IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立ソリューションズの特許一覧

特許7516189ソフトウェア管理システム、ソフトウェア管理方法、及びソフトウェア管理プログラム
<>
  • 特許-ソフトウェア管理システム、ソフトウェア管理方法、及びソフトウェア管理プログラム 図1
  • 特許-ソフトウェア管理システム、ソフトウェア管理方法、及びソフトウェア管理プログラム 図2
  • 特許-ソフトウェア管理システム、ソフトウェア管理方法、及びソフトウェア管理プログラム 図3
  • 特許-ソフトウェア管理システム、ソフトウェア管理方法、及びソフトウェア管理プログラム 図4
  • 特許-ソフトウェア管理システム、ソフトウェア管理方法、及びソフトウェア管理プログラム 図5
  • 特許-ソフトウェア管理システム、ソフトウェア管理方法、及びソフトウェア管理プログラム 図6
  • 特許-ソフトウェア管理システム、ソフトウェア管理方法、及びソフトウェア管理プログラム 図7
  • 特許-ソフトウェア管理システム、ソフトウェア管理方法、及びソフトウェア管理プログラム 図8
  • 特許-ソフトウェア管理システム、ソフトウェア管理方法、及びソフトウェア管理プログラム 図9
  • 特許-ソフトウェア管理システム、ソフトウェア管理方法、及びソフトウェア管理プログラム 図10
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-07-05
(45)【発行日】2024-07-16
(54)【発明の名称】ソフトウェア管理システム、ソフトウェア管理方法、及びソフトウェア管理プログラム
(51)【国際特許分類】
   G06Q 50/10 20120101AFI20240708BHJP
   G06F 8/70 20180101ALI20240708BHJP
【FI】
G06Q50/10
G06F8/70
【請求項の数】 9
(21)【出願番号】P 2020161882
(22)【出願日】2020-09-28
(65)【公開番号】P2022054708
(43)【公開日】2022-04-07
【審査請求日】2023-02-03
(73)【特許権者】
【識別番号】000233055
【氏名又は名称】株式会社日立ソリューションズ
(74)【代理人】
【識別番号】110001678
【氏名又は名称】藤央弁理士法人
(72)【発明者】
【氏名】檜 一平
(72)【発明者】
【氏名】柚山 知之
(72)【発明者】
【氏名】藤原 英哉
(72)【発明者】
【氏名】鈴木 健太郎
(72)【発明者】
【氏名】渡邉 卓摩
(72)【発明者】
【氏名】三部 良太
(72)【発明者】
【氏名】野尻 周平
【審査官】阿部 潤
(56)【参考文献】
【文献】特開2009-199277(JP,A)
【文献】特開2011-65358(JP,A)
【文献】特開2010-170555(JP,A)
【文献】特開2010-272090(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
G06F 8/70
(57)【特許請求の範囲】
【請求項1】
ソフトウェア管理システムであって、
所定の演算処理を実行する演算装置と、前記演算処理に使用される情報が記憶される記憶装置とを備え、
前記記憶装置は、
情報処理システムによって利用者に提供される価値を表す価値情報と、
前記価値が利用者に提供されるまでの時系列の価値発生領域を構成する価値構成要素を表す価値構成要素情報と、
前記価値構成要素を実現する機能を構成するソフトウェアを表す機能情報と、
前記時系列の複数の価値構成要素を含む価値実現情報とを格納し、
前記演算装置は、
前記価値情報の指定を受け付け、
前記情報処理システムが時系列に実行する前記機能を監視した結果である監視情報を取得し、
前記取得した監視情報と前記価値実現情報とを照合して、利用者に提供された価値を判定し、
前記価値構成要素情報及び前記機能情報を参照して、前記指定された価値情報に基づいて、前記機能情報を出力することを特徴とするソフトウェア管理システム。
【請求項2】
請求項1に記載のソフトウェア管理システムであって、
前記演算装置は、
前記取得した監視情報と前記価値実現情報とを照合して、前記情報処理システムが実行した機能によって、前記価値実現情報に含まれる達成された価値構成要素を決定し、
前記価値構成要素の達成度を算出し、
前記算出された達成度に基づいて、前記価値構成要素によって提供される価値を表す情報を出力することを特徴とするソフトウェア管理システム。
【請求項3】
請求項1に記載のソフトウェア管理システムであって、
前記演算装置は、
前記取得した監視情報と前記価値実現情報とを照合して、前記情報処理システムが実行した機能によって、前記価値実現情報に含まれる達成された価値構成要素を決定し、
前記価値構成要素が完了状態でない場合、当該価値構成要素のうち、達成された価値構成要素のみを含む新たな価値実現情報を生成することを特徴とするソフトウェア管理システム。
【請求項4】
ソフトウェア管理システムが実行するソフトウェア管理方法であって、
前記ソフトウェア管理システムは、所定の演算処理を実行する演算装置と、前記演算処理に使用される情報が記憶される記憶装置とを有し、
前記記憶装置は、
情報処理システムによって利用者に提供される価値を表す価値情報と、
前記価値が利用者に提供されるまでの時系列の価値発生領域を構成する価値構成要素を表す価値構成要素情報と、
前記価値構成要素を実現する機能を構成するソフトウェアを表す機能情報と、
前記時系列の複数の価値構成要素を含む価値実現情報とを格納し、
前記ソフトウェア管理方法は、
前記演算装置が、前記価値情報の指定を受け付け、
前記演算装置が、前記情報処理システムが時系列に実行する前記機能を監視した結果である監視情報を取得し、
前記演算装置が、前記取得した監視情報と前記価値実現情報とを照合して、利用者に提供された価値を判定し、
前記演算装置が、前記価値構成要素情報及び前記機能情報を参照して、前記指定された価値情報に基づいて、前記機能情報を出力することを特徴とするソフトウェア管理方法。
【請求項5】
請求項4に記載のソフトウェア管理方法であって、
前記演算装置が、前記取得した監視情報と前記価値実現情報とを照合して、前記情報処理システムが実行した機能によって、前記価値実現情報に含まれる達成された価値構成要素を決定し、
前記演算装置が、前記価値構成要素の達成度を算出し、
前記演算装置が、前記算出された達成度に基づいて、前記価値構成要素によって提供される価値を表す情報を出力することを特徴とするソフトウェア管理方法。
【請求項6】
請求項4に記載のソフトウェア管理方法であって、
前記演算装置が、前記取得した監視情報と前記価値実現情報とを照合して、前記情報処理システムが実行した機能によって、前記価値実現情報に含まれる達成された価値構成要素を決定し、
前記演算装置が、前記価値構成要素が完了状態でない場合、当該価値構成要素のうち、達成された価値構成要素のみを含む新たな価値実現情報を生成することを特徴とするソフトウェア管理方法。
【請求項7】
計算機にソフトウェアを管理させるソフトウェア管理プログラムであって、
前記計算機は、所定の演算処理を実行する演算装置と、前記演算処理に使用される情報が記憶される記憶装置とを有し
前記記憶装置は、
情報処理システムによって利用者に提供される価値を表す価値情報と、
前記価値が利用者に提供されるまでの時系列の価値発生領域を構成する価値構成要素を表す価値構成要素情報と、
前記価値構成要素を実現する機能を構成するソフトウェアを表す機能情報と、
前記時系列の複数の価値構成要素を含む価値実現情報とを格納し、
前記ソフトウェア管理プログラムは、
前記価値情報の指定を受け付ける手順と、
前記情報処理システムが時系列に実行する前記機能を監視した結果である監視情報を取得する手順と、
前記取得した監視情報と前記価値実現情報とを照合して、利用者に提供された価値を判定する手順と、
前記価値構成要素情報及び前記機能情報を参照して、前記指定された価値情報に基づいて、前記機能情報を出力する手順とを、前記演算装置に実行させることを特徴とするソフトウェア管理プログラム。
【請求項8】
請求項7に記載のソフトウェア管理プログラムであって、
前記取得した監視情報と前記価値実現情報とを照合して、前記情報処理システムが実行した機能によって、前記価値実現情報に含まれる達成された価値構成要素を決定する手順と、
前記価値構成要素の達成度を算出する手順と、
前記算出された達成度に基づいて、前記価値構成要素によって提供される価値を表す情報を出力する手順とを、前記演算装置に実行させることを特徴とするソフトウェア管理プログラム。
【請求項9】
請求項7に記載のソフトウェア管理プログラムであって、
前記取得した監視情報と前記価値実現情報とを照合して、前記情報処理システムが実行した機能によって、前記価値実現情報に含まれる達成された価値構成要素を決定する手順と、
前記価値構成要素が完了状態でない場合、当該価値構成要素のうち、達成された価値構成要素のみを含む新たな価値実現情報を生成する手順とを、前記演算装置に実行させることを特徴とするソフトウェア管理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ユーザへ提供される「価値」を主な観点としてデジタルソリューションを設計するためのソフトウェア管理システムに関する。
【背景技術】
【0002】
IoT時代を迎えるにあたり、システムの製造事業者のビジネス形態は、「モノ」売りから、社会課題や顧客課題の解決手段そのものと直結する「コト」売りへと、事業分野に関わらず大きく変化している。例えば、顧客が病院であれば、「モノ」売り時代は、顧客からの「超音波診断装置がほしい」「カルテを電子化したい」など要望に対して、「モノ」自体、言い換えれば、顧客ニーズを技術的に解決した製品を商材として販売する形態が主流であった。しかし「コト」売りの時代においては、「病院の売上を向上させたい」「病院の職員の離職率を低下させたい」などの、「モノ」売り時代に比べてより概念的、抽象的な社会課題や顧客課題から、当該社会課題や顧客課題を解決する「価値」そのものを検討し、当該「価値」を提供するべく、自社や他社の商材等を採用してコンピュータを用いたデジタルソリューションを構築するという形態へと変化しつつある。
【0003】
ここで、「モノ」売り、「コト」売りのどちらの場合でも、一度開発した商材やソリューションを効率的かつ拡散的に他の顧客に対して提供する(以下「N倍化」と称する)場合、コスト低減の観点からも一度開発した技術やソフトウェアを再利用してデジタルソリューションを提供することが望ましい。ここで、N倍化における「効率的」とは、「低コスト及び/又は短い顧客要求リードタイムで」という意味で主に用いており、「拡散的」とは、「同様の価値を所望する、できるだけ沢山の顧客に」という意味で主に用いている。
【0004】
「モノ売り」の場合、例えば家電や自動車等のプロダクツでは、同じ仕様書、図面、設計マニュアル等に基づいて「技術や機能そのもの」を大量生産すればよい。また、顧客ごとのシステムインテグレーション(SI)によって各顧客特有のソフトウェア等を提供する場合は、使用する部品たるソフトウェアを開発者の視点、すなわち技術視点からパッケージ化して再利用する等の方法がある。例えば、特許文献1には、概念を体系化し、各概念(タスク)にソフトウェアを対応させて分類することで、ソフトウェアを再利用しやすくするシステムが記載されている。
【先行技術文献】
【特許文献】
【0005】
【文献】特開2008-112246号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら「コト」売りの場合、顧客にとってN倍化され提供されるのは、前述したように「提供価値」そのもの、言い換えれば、技術やソフトウェア等により構成された「機能」や「タスク」といった技術的要素とは異なる概念である。例えば、前述した病院の例で言えば、A病院において「病院の売上を向上させる」という価値が提供され、当該提供価値を具現化するソリューション(複数の「機能」によって構成された技術要素)がA病院に提供される。A病院に提供された価値は、他の病院(B病院、C病院・・・)にN倍化できるが、他の病院が求める(N倍化されるべき)ものは、「病院の売上を向上させる」とう概念的、抽象的な「価値」そのものであって、当該「価値」を具現化するデジタルソリューションに係るソフトウェア等の「機能」までを含んだ意図での要求ではない。すると、前述したように「コト」売りにおいては「価値」と「機能」とが概念として大きく乖離しているため、例え「価値」が同一でも、各顧客の既存設備や機器、環境等の事情によって適用すべき個別具体的な技術手段たる「機能」は、顧客ごとに異なる場合が多々あり、結局はシステムインテグレーション等の高コストの方法を顧客ごとに用いて「機能」を構築しなければならない。すなわち、幾ら同一の「価値」をN倍化させても、これと連動した「機能」の開発にコストや時間がかかり効率的な開発を実現できず、さらにそのことが他の顧客との商機を逃すことに繋がることため拡散的な開発の弊害にもなる。よって、デジタルソリューションとしてN倍化させることが困難である。
【0007】
また、特許文献1のように「機能」側の観点でソフトウェアが再利用可能なように整理しても、あくまで「機能」側(ソフトウェア側)の事情を考えたソフトウェア設計となるため、「価値」との整合性、連動性は担保しない状態での開発となるため、「価値」のN倍化と整合したデジタルソリューションの提供は困難である。
【0008】
すなわち、「コト」売りにおいて顧客に提供されるデジタルソリューションがN倍化されるということは、「価値」と「機能」とが整合した状態で、連動してN倍化されなければ、効率的、拡散的にデジタルソリューションを顧客に提供できないことが課題である。
【0009】
本発明はこのようなIoT時代におけるデジタルソリューションを活用した「コト」売り特有の課題を解決するものである。
【課題を解決するための手段】
【0010】
本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、ソフトウェア管理システムであって、所定の演算処理を実行する演算装置と、前記演算処理に使用される情報が記憶される記憶装置とを備え、前記記憶装置は、情報処理システムによって利用者に提供される価値を表す価値情報と、前記価値が利用者に提供されるまでの時系列の価値発生領域を構成する価値構成要素を表す価値構成要素情報と、前記価値構成要素を実現する機能を構成するソフトウェアを表す機能情報と、前記時系列の複数の価値構成要素を含む価値実現情報とを格納し、前記演算装置は、前記価値情報の指定を受け付け、前記情報処理システムが時系列に実行する前記機能を監視した結果である監視情報を取得し、前記取得した監視情報と前記価値実現情報とを照合して、利用者に提供された価値を判定し、前記価値構成要素情報及び前記機能情報を参照して、前記指定された価値情報に基づいて、前記機能情報を出力することを特徴とする。
【発明の効果】
【0011】
本発明によれば、顧客へ提供する「価値」のN倍化と連動して、ソフトウェアを中心とした「機能」のN倍化が可能となり、デジタルソリューションを効率的に多数の顧客に拡散できる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。
【図面の簡単な説明】
【0012】
図1】V-Fモデルの概念図である。
図2】V-FモデルのValue層とFunction層との接続部分の構造を示す図である。
図3】エンターテイメント・スポーツ関連デジタルソリューションに当て嵌めたV-Fモデルを示す図である。
図4】V-Fモデルの価値創出原理をデジタルソリューションの例を用いて示す図である。
図5】エンターテイメント・スポーツ関連デジタルソリューションに当て嵌めたV-FモデルのFunction層の構造を示す図である。
図6】ソフトウェア管理システムの物理的な構成を示すブロック図である。
図7】補助記憶装置に記憶されるデータの一例を示す図である。
図8】デジタルソリューションを構築する処理のフローチャートである。
図9】監視処理のフローチャートである。
図10】見積もり作成処理のフローチャートである。
【発明を実施するための形態】
【0013】
<実施例1>
図1は、本発明に係る「価値」と「機能」とを明示的かつ有機的に連結するためのモデルの概念図である。以下、「価値」と「機能」と連結させる概念を表すモデルを「V-Fモデル」と称する。V-Fモデルは階層構造となっており、「価値」に関する概念であるValue層11と「機能」に関する、言い換えれば技術的な概念に関するFunction層12とに大別される。さらに、Value層11は、価値創出原理(V1)と、顧客へ提供される個別具体的な提供価値(V2)の順に連結された階層構造になっている。
【0014】
価値創出原理(V1)は、一つ又は複数のデジタルソリューションによって構成される情報処理システムに内包される複数の異なる提供価値(V2)が共通に有する、価値を創出するための法則である。価値創出原理(V1)は、多岐に渡る提供価値の創出を法則化することによって、業種を跨いだ提供価値のN倍化を可能にすることを目的として設定されている。
【0015】
提供価値(V2)は、対象となるデジタルソリューションによって提供される個別具体的な価値である。提供価値は、価値を享受する者の視点の表現で、かつ享受する価値そのもののみを構成要件として定義されている。提供価値(V2)は、Value層11の最下位でFunction層12と接続される位置、すなわち「Value」と「Function」との境界にあるため、それぞれの「価値」と「機能」との概念が混在しないよう、明確に区別される必要があるためである。特に「機能」は表現方法が多岐にわたるため、提供価値(V2)の概念と混在しやすい傾向がある。例えば、スポーツ観戦等に関するデジタルソリューションにおいて、「試合結果を予想してワクワクしたい」は当該試合の観戦者(価値享受者)が享受する価値そのものにフォーカスした概念として定義されているため提供価値になり得るが、「楽しい試合結果予想ゲーム」は「ゲーム」という「機能」を指しているため、提供価値とは異なる概念である。また、「価値提供者の提供物・ケーパビリティ」そのものが提供価値と混在する場合もある。例えば、「我々(プロバイダ)はITとOTをトータルソリューションで顧客に提供できる」という設定は、そのデジタルソリューションを提供するプロバイダのケーパビリティそのものを定義しているため、顧客が享受する提供価値としての設定ではない。そのため前述したように、提供価値とそれ以外との混在を避けるため、提供価値は享受する「価値」のみによって構成している。
【0016】
一方、Funtion層12は、各提供価値(V2)を直接的に実現する業務等の概念によって構成されるユーザインターフェース(UI)(F2)、各業務を実現する物理的なソフトウェアであるコンポーネントF2によって構成されている。
【0017】
図2は、図1における提供価値(V2)とユーザインターフェース(F2)との接続部分、言い換えればValue層11とFunction層12との接続部分の構造を示す図である。
【0018】
提供価値は、ユーザエクスペリエンス(UX)等を起点とした表現になることが多いため、技術と乖離した概念的な表現となる傾向が高い。一方、ユーザインターフェース(F2)やコンポーネント(F1)は技術的表現となる傾向が高い。そこで、提供価値(V2)とユーザインターフェース(F2)の境界では、ユーザエクスペリエンスと技術とを同時に表現し、両者を接続するために、提供価値(V2)を、ユーザが享受するためのプロセスを時系列に区切って設定されたアクティビティ22と、複数のアクティビティ22によって構成されるフロー21をユーザエクスペリエンス(ユーザ体験)としている。「アクティビティ」の一例としては、「ユーザアクション」、すなわちユーザの体験を基軸に、全ての「機能」が当て嵌まるように設定された時系列の動作ごとに整理し、その動作群を「フロー」として設定すること等がある。
【0019】
以下、図1図2にて説明した概念に対して、デジタルソリューションの一例を当て嵌め、その一部を示した場合の例を説明する。一例として当て嵌めるデジタルソリューションは、野球チームやサッカーチーム等のスポーツ分野や、音楽アーティストが所属する芸能プロダクション、音楽会社等のエンターテイメント分野において、当該球団等の運営者が運営するファンサイトに係るものである。
【0020】
まず、本デジタルソリューションが運営者に提供するコンセプトとしての「価値」は、「ファンの活性化」である。当該コンセプトとしての「価値」に対して、個別具体的な提供価値(V2)を享受するのはファンの人たち自身であるため、例えばファンの人たちが享受する個別価値(V2)として、「ファンサイトで運営している勝敗予想ゲームでワクワクしたい」や「ポイントを貯めて非売品のグッズを獲得したい」といった、「ファンの活性化」というコンセプトの射程内での個別具体的な価値が挙げられる。
【0021】
これらの提供価値などに基づいて、価値創出原理(V1)を検証すると、本デジタルソリューションにおける提供価値(V2)は、図3に示す三つの上位概念のいずれかに該当しており、これらが本デジタルソリューションで提供するコンセプト価値の「ファンの活性化」のファクターになっていることを以下詳述する。
【0022】
まず、ファンは、「今までファンでなかった者」と「既にファンである者」の二つのグループに大別でき、各提供価値(V2)は、この二つの区分のどちらかに対して提供されるものである。さらに「既にファンである者」は、その愛好度合いに段階があり、度合いが高い順に「プレミアム」「コア」「ファン」「ファン候補」の四つのグループに区分でき、愛好度が高い区分ほど、ファンの人数が少なく、且つファン一人当たりの運営者への売上貢献は大きいことが期待される。すなわち本デジタルソリューションでは、上記区分の少なくとも一つに対して価値を提供することによって、各区分内のファンを成長させ、「ファンの活性化」というコンセプトである提供価値を実現している。これらの現象に基づいて、提供価値(V2)は以下の三つに区分される。
【0023】
一つ目の提供価値は「育成」である。これは、「既にファンである者」(図3に示す三角形の内部領域)の運営者側への愛好度を高めることによって、より上位層の区分へと引き上げようとする価値である。
【0024】
二つ目の提供価値は「創生」である。これは「未だファンになっていない者」(図3に示す三角形の外部領域)を、「既にファンである者」に引き上げようとする価値である。
【0025】
三つ目は「維持」である。これは、「既にファンである者」の愛好度が下位層に下がらないようにする価値である。
【0026】
以上の区分化によって、本デジタルソリューションの価値創出原理として、提供価値(V2)が「創生」「育成」「維持」のいずれを実施しようとしているかが分かる。このように、提供価値(V2)の原理化によって、ファンの中でもどのレベルにあるファン(ユーザ)をターゲットにした提供価値であるかが定められ、より、運営者(顧客)が所望する価値の提供が可能となる。
【0027】
図4に、前述した価値創出原理と対応させた状態で、図2に示した提供価値(V2)とユーザインターフェース(F2)との対応関係を示す。図4では説明のための一例として、運営者が野球球団である場合の当該球団のファンサイトとして、ファンへの提供価値(V2)を「ペットと一緒に野球観戦したい」と設定した。当該提供価値は、野球への興味のレベルは低いものの、ペットを飼っている人を対象に、広々とした球場の敷地でペットと過ごせる、という価値を提供して、球場に足を運ばせることを目的とする価値である。すなわち、当該価値と接続される価値創出原理は、三つの区分の中の「創生」である。
【0028】
次に、「フロー」と「アクティビティ」を設定する。本実施例における「フロー」は、ファンが提供価値(V2)を享受するまでの時系列の「ユーザ体験」に基づいて時系列に構成される「アクティビティ」をフローとして設定している。
【0029】
ここで、「フロー」と「アクティビティ」の意義について説明する。前述のように、「価値」が当該価値を享受する「コト」に関する概念であるのに対して、「機能」は技術的概念、ひいては「モノ」に近い概念であり、両者の概念には大きな隔たりがある。そのため、本実施例で達成しようとする「価値」と「機能」とが連動したN倍化を達成するためには、この両者の境界をどのように設計するかという点が要諦となる。
【0030】
本実施例で上記境界として提案する「フロー」は、提供価値が発生するのために必須となる人間の行動や活動の「領域」を定義する概念の一例である。例えば本実施例で説明するエンターテイメントに関するデジタルソリューションにおいては、上記「領域」を、提供価値を享受するまでの人間の行動、すなわち、価値を享受するに至る始点となる「アクティビティ」から、終点となる「アクティビティ」までに発生している全ての「アクティビティ」の集合体として定義している。従来提供されてきたデジタルソリューションに係るシステムや製品は、ソフトウェア等「機能」側のN倍化を起点に構成されているため、「アクティビティ」の単位で構成されるに留まってしまうことが大半であり「価値」とシステムや商材とが1対1で構成されることが困難であることが課題であった。本実施例では、提供価値が発生する「領域」を「フロー」「アクティビティ」といった価値享受者側の概念で規定することによって、「価値」と「機能」と言う異なる概念を接続することを可能としている。
【0031】
本実施例であげた「フロー」「アクティビティ」は、あくまで提供価値が発生する際の価値側の概念を規定する「領域」の一例であり、価値が発生し享受される領域が規定されるのであれば、これに限らず、例えば「フロー」に対応する領域設定として「バリューチェーン」や「サプライチェーン」、「ステークホルダマップ」等の概念を用いてもよい。これに伴い、「アクティビティ」に代わる概念として「工程」や「ステークホルダ」等を用いてもよい。本実施例含め、本明細書では、上記「フロー」等の提供価値が発生する領域を総じて「価値発生領域」と称し、また、上記「アクティビティ」のような、当該「価値発生領域」を網羅する集合体を構成する要素の単位を総じて「価値構成要素」と称することがある。
【0032】
またこのとき、フローに関する情報を収集して効果測定等を行い、後の「ファン化」施策にフィードバックを与える構成として、フローの後に「効果測定」という「アクティビティ」を設けてもよい。これにより、実施例3で課題としている、機能により価値が実現されたか否かや、その度合を計測し、より確実なN倍化の実現を可能としている。
【0033】
最後に、各アクティビティを物理的に実行するために必要な機能を、各「アクティビティ」のいずれかに整理する。その第1ステップとして、ユーザインターフェース(F2)をアクティビティごとに分類する。なお、前述の通り、本実施例における価値享受者がユーザであるため「ユーザインターフェース」としているが、必ずしてもユーザである必要なく、V-Fモデルに基づく他のデジタルソリューションにおいて、インターフェースとしての役割を果たすものであれば必ずしもユーザ用のインターフェースである必要はないことは言うまでもない。
【0034】
図5は、図4に示すユーザインターフェース(F2)を含めたFunction層12の構造を示す。ユーザインターフェース(F2)と、各種ユーザインターフェースを具現化するプログラムによって構成されるコンポーネント(F1)は、明確な対応関係で定義されており、テーブルに格納される。プログラムであるコンポーネント(F1)は、プログラムの実行時にアクセスされるデータベース(データ層)と関連付けられており、必要に応じて外部サービスと連携している。さらに、ユーザインターフェース(F2)とコンポーネント(F1)の間には、「提供価値監視コンポーネント」と称されるコンポ―ネントが設けられてもよい。当該「提供価値監視コンポーネント」は実施例2にて後述する。
【0035】
図6は、本実施例のソフトウェア管理システム1の物理的な構成を示すブロック図である。
【0036】
本実施例のソフトウェア管理システム1は、プロセッサ(CPU)101、メモリ102、補助記憶装置103、通信インターフェース104、入力インターフェース105及び出力インターフェース108を有する計算機によって構成される。
【0037】
プロセッサ101は、メモリ102に格納されたプログラム(演算処理)を実行する演算装置である。プロセッサ101が、各種プログラムを実行することによって、ソフトウェア管理システム1の各種機能が実現される。後述する価値監視コンポ13等におけるプログラムもメモリ102に格納されていることを想定しているが、これらのプログラムが後述する補助記憶装置103や外部の記憶媒体に格納されてもよい。なお、プロセッサ101がプログラムを実行して行う処理の一部を、他の演算装置(例えば、FPGAやASICなどのハードウェアによる演算装置)で実行してもよい。
【0038】
メモリ102は、不揮発性の記憶素子であるROM及び揮発性の記憶素子であるRAMを含む。ROMは、不変のプログラム(例えば、BIOS)などを格納する。RAMは、DRAM(Dynamic Random Access Memory)のような高速かつ揮発性の記憶素子であり、プロセッサ101が実行するプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。
【0039】
補助記憶装置103は、例えば、磁気記憶装置(HDD)、フラッシュメモリ(SSD)等の大容量かつ不揮発性の記憶装置である。また、補助記憶装置103は、プロセッサ101がプログラムの実行時に使用するデータ(例えば、価値情報、アクティビティ情報など)、及びプロセッサ101が実行するプログラム(例えば、会員情報参照・ポイント交換プログラムなど)を格納する。すなわち、プログラムは、補助記憶装置103から読み出されて、メモリ102にロードされて、プロセッサ101によって実行されることによって、ソフトウェア管理システム1の各機能を実現する。
【0040】
通信インターフェース104は、所定のプロトコルに従って、他の装置との通信を制御するネットワークインターフェース装置である。
【0041】
入力インターフェース105は、キーボード106やマウス107などの入力装置が接続され、オペレータからの入力を受けるインターフェースである。出力インターフェース108は、ディスプレイ装置109やプリンタ(図示省略)などの出力装置が接続され、プログラムの実行結果をオペレータが視認可能な形式で出力するインターフェースである。なお、ソフトウェア管理システム1にネットワークを介して接続された端末が入力装置及び出力装置を提供してもよい。
【0042】
プロセッサ101が実行するプログラムは、リムーバブルメディア(CD-ROM、フラッシュメモリなど)又はネットワークを介してソフトウェア管理システム1に提供され、非一時的記憶媒体である不揮発性の補助記憶装置103に格納される。このため、ソフトウェア管理システム1は、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。
【0043】
ソフトウェア管理システム1は、物理的に一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、複数の物理的計算機資源上に構築された仮想計算機上で動作するものでもよい。
【0044】
図7は、図6に示すプロセッサ101が実行するプログラムが使用し、補助記憶装置103に記憶されるデータの一例を示す。補助記憶装置103は、顧客がデジタルソリューションによって実現しようとする価値を創出するための法則である価値創出原理(V1)が記録される価値創出原理データベース31、少なくとも提供価値(V2)が記録される価値データベース32、テンプレートを構成する要素の集合であるアクティビティが、価値を提供するまでのフロー単位で記録されるアクティビティデータベース33、当該アクティビティ夫々を実現せしめるためのユーザインターフェース(F2)の情報が記録されるユーザインターフェースデータベース34、当該ユーザインターフェースを物理的に実行するためのソフトウェアであるコンポーネントの情報が記録されるコンポーネントデータベース35、各コンポーネントが参照するデータが記録されるコンポ参照用データベース36が格納される。コンポ参照用データベース36は、例えば、図5に示すように、会員の情報が記録される会員データベース、各会員が獲得したポイントが記録されるポイント台帳、運営者の情報が記録される運営者データベースなどを含む。
【0045】
価値実現テンプレート37は、後述する実施例2で使用されるデータであり、価値データベース32に記録された提供価値ごとに、前述のフローを構成するアクティビティ、当該アクティビティを構成するユーザインターフェースの情報を少なくとも含むテンプレートである。価値実現モデル達成表38は、後述する実施例2で使用されるデータであり、各価値実現モデルで達成されたプロセスが記録されるテーブルである。価値実現モデル記録部39は、後述する実施例2で使用されるデータであり、各価値実現モデルの達成度が記録される。
【0046】
以下、図3図4に示した、スポーツ分野及びエンターテイメント分野におけるファンサイトというデジタルソリューションを例にして、「価値」と「機能」とを連動させてN倍化を実施する例を示す。ここで、このようなファンサイトは、所謂「B to B to C」ビジネスである旨に留意する。すなわち、プロバイダ(B1)が提供したデジタルソリューションを、当該ファンサイトの運営者(B2)が購入し、さらにこのファンサイトを、ファン(C)が会員として利用する、という構図になっている。以下の実施例の説明では、このような運営者(B2)のことをプロバイダ(B1)から見た「顧客」と呼び、一方ファン(C)のことを「ユーザ」と呼んで、両者を区別して説明することがある。
【0047】
図8に、特定の顧客に既に提供されたデジタルソリューションから、補助記憶装置103に記憶されたデータベース等を参照して、他の顧客に提供するデジタルソリューション構築する処理のフローチャートを示す。
【0048】
<STEP151:運営者の価値の選定>
価値創出原理データベース31には、本例における「創生」「育成」「維持」の三つの価値創出原理が格納されている。顧客が、入力インターフェース105から、この価値創出原理の中から何れかを選択すると、プロセッサ101による演算処理が開始される。価値創出原理に示される価値は、デジタルソリューションを購入する運営者(B2)が享受する価値とも言うことができ、価値創出原理に基づく価値から入ることによって、二つの顕著な効果が得られる。一つは、実際にこのデジタルソリューションのオーナーとして対価を支払う運営者の享受する価値から検討することによって、真に対価に見合った価値を享受できるかを、直接的に確認できる点である。もう一つは、運営者が、その時々の運営者のファンの傾向に合わせた提供価値(V2)を得られるという点である。例えば、そもそもファンもファン候補も乏しい運営者であれば、まずは運営者のファンそのもの、言い換えれば、図3に示すファン層における三角形全体の面積を広げる施策が有効であるため、価値創出原理「創生」に関連付けられた提供価値(V2)が効果的である。一方、ファン層は広いが「コア」ファンを増加したい、言い換えれば、図3の三角形の上位層のファンを増やしたいのであれば、「育成」に関連付けられた提供価値(V2)が効果的である。
【0049】
このように、個別具体的な提供価値の選択の前に、価値創出原理に基づいて、どのような価値を運営者が享受したいかのコンセプトを把握することによって、より効果的にユーザへ提供される価値を選択できる。
【0050】
<STEP152:選択した運営者の価値に該当する「提供価値」の抽出>
図2に示すように、提供価値(V2)は少なくとも一つの価値創出原理(V1)と関連付けられているため、価値創出原理データベース31の創生、育成、維持は、提供価値(V2)の何れかと関連付けられて、テーブル形式で補助記憶装置103に格納されている。プロセッサ101は、STEP151において選択された価値創出原理(V1)と対応する提供価値(V2)を抽出する。この時抽出される提供価値(V2)は、別テーブルによって整理された各提供価値(V2)の傾向や属性や、別途入力インターフェース105から入力された運用者の情報などのパラメータに対応する重み付け係数を定め、各パラメータを重み付け係数で乗じた値の和によって、提供価値(V2)毎のスコアを計算し、計算されたスコアによって抽出の優先度や順位を変えてもよい。例えば、各提供価値に属性情報「業種」を定めておき、運用者が入力した情報から当該運営者の「業種」を定め、相関性が高い提供価値(V2)を優先的して、より運営者及び利用者に効果的である可能性が高い提供価値を抽出してもよい。また、選択された価値創出原理(V1)に対応する提供価値(V2)を提示して、顧客に提供価値の選択を促してもよい。さらに、他の顧客との類似度を用いて、類似する顧客が提供している提供価値(V2)を推薦してもよい。
【0051】
<STEP153:「フロー」「アクティビティ」「UI」の抽出>
提供価値(V2)が定まれば、定められた提供価値(V2)と、Value層11とFunction層12とを接続する「フロー」「アクティビティ」「UI」を、アクティビティデータベース33及びユーザインターフェースデータベース34から取得する。前述したSTEP152と同様に、「フロー」「アクティビティ」「UI」は関連付けられている。前述したように、「フロー」は、本実施例では利用者の「ユーザ体験」、言い換えれば、利用者が提供価値(V2)を享受するまでの時系列に列挙された「アクティビティ」で構成されている。このように、価値を享受するまでの時系列のプロセス(フロー)をアクティビティによって整理することによって、価値を創出するために必要な機能をもれなく設定することが可能となる。
【0052】
<STEP154:コンポーネント選択>
プロセッサ101が、各ユーザインターフェースを実現するコンポ―ネント、言い換えれば、そのデジタルソリューションの具現化に必要なソフトウェアを選択し、決定する。
【0053】
<STEP155:提供(N倍化)する「提供価値」と「コンポーネント」とを出力>
プロセッサ101が、最終的に運営者・利用者に提供される「提供価値」と、それを構成する物理的な「コンポーネント」によるデジタルソリューションを画面に表示するためのデータを生成し、出力する。
【0054】
以上の構成によって、運営者や利用者にとって大きな価値、言い換えれば高利益を生む価値を提供可能なソフトウェアを低コストでN倍化できる。すなわち、STEP151~155によって、概念的な「価値」を連動するように物理的な「機能」を定義し、それぞれの価値において求められる「高利益」、「抵コスト」という要求を両立させた状態で、N倍化ができ、デジタルソリューションやソフトウェアの分野における課題を解決できる。
【0055】
<実施例2>
次に、実施例1にて顧客ごとにN倍化されたデジタルソリューションにおいて、継続的に価値を提供するための実施例について説明する。本実施例のソフトウェア管理システム1によって構築されるデジタルソリューションの個別具体的な目的は、各種の提供価値(V2)を確実にユーザ(例えばファン)に届けることであるが、価値が届いたか否かや、ファンがどの提供価値を所望・選択したか、さらに、そもそも想定した提供価値(V2)を実現するに際し、提供した機能群は正しかった否か、もし正しくなかった場合、その原因は何であるのか等の把握ができなければ、真にN倍化が実現されたとは言い難い。また、ユーザか異なれば同じ価値を提供するに際し、提供する機能群の品ぞろえ(ラインアップ)の一部に変更等が必要となる場合もある。
【0056】
しかしながら、どのユーザインターフェース(F2)やコンポーネント(F1)が動作したか、という単純な情報からではこれらの把握は困難であるという課題がある。さらには、提供価値の効果の度合の測定も行えることが、N倍化のさらなる加速のためには望ましい。そこで本実施例ではこれらの課題を解決すべく、「提供価値監視コンポーネント」(以下「価値監視コンポ」と略称する)13を設け、動作したユーザインターフェース(F2)の種類と、そのユーザインターフェースが使われる順序を時系列に監視することで、提供価値(V2)が確実にユーザに提供されているかを検証する手法等について説明する。
【0057】
図9に、価値監視コンポ13が実行する監視処理のフローチャートを示す。前述した通り、デジタルソリューションにおいてユーザに提供される価値は、単一のユーザインターフェースによって提供されるものではなく、複数のユーザインターフェースとユーザとのインタラクションの連鎖によって提供される。
【0058】
また、これらインタラクションの連鎖は、取引処理のように、必ずしも一つの原子的な機能によって実行されるものだけではなく、1ユーザとのインタラクションに閉じるものでもない。
【0059】
例えば、あるWebシステムへのユーザのエンゲージメントを高めるために、利用ポイントの加算と、利用ポイントに応じた特典商品の交換という価値をユーザに提供することを考える。
【0060】
この際、ある1ユーザへの価値提供が達成されるとは、1.サイト運営者が特典商品を登録し、2.ユーザがその特典商品を認識し、3.ユーザがサイト上で活動しポイントを獲得し、4.ユーザがサイト上で特典商品を選択・交換の登録をし、5.サイト運営者が特典商品の配送を手配し、6.ユーザが特典商品を入手にする。という一連のプロセスを経ることになる。価値を得る者は、主にユーザであるが、システムを使用するサイト運営者が価値を得るように、当該顧客のみにフォーカスされるものではなく、また、単取引処理のように原子的な機能の連鎖だけに閉じるものではない。
【0061】
価値監視コンポ13は、前述のような価値提供プロセスの達成状況を監視する。この価値監視コンポ13の実現方法はいくつか考えられるが、一例として各コンポーネントへの通信を監視することによって各コンポーネントが実行されたか否か(すなわち、発火したか否か)を確認し、これを状態遷移モデルで管理することによって、価値提供の達成状況を算出する方法を示す。
【0062】
<STEP201:価値実現モデルの生成>
まず、価値監視コンポ13は、コンポーネントデータベース35に記録された価値実現テンプレート37を読み込み、ソフトウェア管理システム1を利用する顧客毎の価値実現モデルを生成する。価値実現テンプレート37は、価値データベース32に記録された提供価値ごとに、前述のフローを構成するアクティビティ、当該アクティビティを構成するユーザインターフェースの情報を少なくとも含むテンプレートである。価値実現モデルは、価値実現テンプレート37に含まれる「価値」「アクティビティ」「UI」の情報を少なくとも用いて、これらの関係をモデル化することによって、ユーザインターフェースに含まれる具体的なソフトウェアであるコンポーネントが使用されたことを検知して、最終的にどの「提供価値」が提供されたかを監視するモデルである。ここでは一例として、ある所定の価値において、これらを具体的にユーザ単位の変数を設定してモデル化した例を示す。この場合、例えば、前述の価値提供のプロセスにおける価値実現テンプレート37及び価値実現モデルは、以下のようになる。なお、1が開始状態で、6が完了状態である。また、1から6までシーケンシャルに状態が遷移する。
・価値実現テンプレート
1.サイト運営者、特典商品機能、登録
2.ユーザ、特典商品機能、商品閲覧
3.ユーザ、ポイント管理機能、ポイント付与
4.ユーザ、特典商品機能、商品交換、
5.サイト運営者、配送手配、配送実施
6.ユーザ、配送状況管理、完了
・価値実現モデル
1.ロール:Operator、PrizeManagement、Regist(itemid abc)
2.Customer.id = 11111 、PrizeManagement、getItemInfo()
3.Customer.id = 11111 、PointManagement、addPoint
4.Customer.id = 11111 、PrizeManagement、orderExchange(item_id abc)、
5.ロール:Operator、OrderDelivery、setupDelivery(user 1111, item abc)
6.Customer.id = 11111、DeliveryManagement、isCompleted
【0063】
前述したように、モデルに「価値が提供される対象は誰か」という概念を入れることにより、価値が提供されるターゲットが具体的かつ明確になるため、その価値が提供されたか否かを監視及び確認しやすくなる。ただし、前述はあくまで一例であり、「価値」、当該価値が顧客に提供されるまでの「フロー」、当該フローを構成する「アクティビティ」、当該アクティビティを実現するための物理構成の概念を示す「UI」がテンプレートに含まれており、これらテンプレートから各構成の対応関係が分かるモデルであれば、どのような構成のモデルでもよい。
【0064】
<STEP202:発火情報の取得>
次に、価値監視コンポ13は、各ユーザインターフェースに含まれるコンポーネントの発火情報を取得する。発火情報の取得方法には、コンポーネントへの呼び出しメッセージ通信を監視する方法や、コンポーネントにフレームワークを組み込み、呼び出し情報を価値監視コンポ13に転送させる方法などがある。
【0065】
<STEP203:達成されたプロセスの決定>
次に、価値監視コンポ13は、得られたコンポーネントの発火情報を解析し、価値実現モデルで達成されたプロセスを決定して、価値実現モデル達成表38に格納する。例えば、ユーザID 11111のユーザの当該価値実現モデルが状態2にある場合、当該ユーザにより、PrizeManagemt機能のgetItemInfo()メソッドが発火された場合には、状態3へ進む。もし、状態1において当該ユーザによって、PrizeManagemt機能のgetItemInfo()メソッドが発火されても、当該価値実現モデルは状態1のままである。また、この例では一つの価値実現モデルについてのみ処理をしているが、実際には影響が及ぶ全ての価値実現モデルにおいて、状態を進めるか否かを判定して処理を実行する。
【0066】
<STEP204:価値実現モデルの達成度算出>
次に、価値監視コンポ13は、各価値実現モデルの状態が終了状態の達成度を算出する。達成度の算出方法として、例えば、当該価値実現モデルが完了状態にあるか否かを判定するもの、また、プロセス全体のステップを母数とした達成されたプロセス数の割合、また、プロセス長に対する達成されたステップ数の割合などの方法を用いる。算出された結果をサマリーとして価値実現モデル記録部39に格納する。
【0067】
<STEP205:価値達成状況の通知>
次に、価値監視コンポ13は、価値実現モデル達成表38に格納された達成度の状況をシステムの管理者などに通知する。例えば、価値実現モデルで終了状態になった場合、どのユーザにどの価値が提供されたかをシステム管理者の端末へ出力する等の方法がある。なお、他に適切な方法で出力してもよいことは言うまでもない。
【0068】
また、システム管理者からの問い合わせにより、価値毎、ユーザ毎の達成度を一覧として表示したり、また、達成度に閾値を設け、閾値以下のユーザを一覧として表示したりなど、分析に適する形式でデータを提供してもよい。
【0069】
通常のシステム運用では、稼働しているコンポーネント毎に前述のSTEP202~204を繰り返し実行する。価値実現テンプレート37が変更されたり、ユーザが増えた場合にはSTEP201より再実行するとよい。
【0070】
STEP205は、本実施例のように、価値監視コンポ13が実行する監視処理に組み込んでもよいが、監視処理と並列に実行してもよい。
【0071】
なお、本実施例では、提供される価値をリアルタイムで監視するために各コンポーネントの稼働を監視しているが、日次や週次などのタイミングで監視し、各コンポーネントの稼働ログやデータベースの解析などによって、どのユーザが、いつ、どの機能を発火させたかを取得してもよい。
【0072】
また、価値実現モデルの状態が終了状態とならずに止まっており、その後もユーザが継続して当該デジタルソリューションを使用している場合、当該価値実現モデルの途中でもユーザは価値を得ていると考えられる。このため、ユーザが継続して当該デジタルソリューションを使用しており、状態が終了状態とならずに所定時間状態の変化がない価値実現モデルを検出して、当該価値実現モデルの開始状態から変化がない状態を完了状態にした新しい価値実現モデルを生成してもよい。この際、同じ位置で止まっている価値実現モデルのユーザ数が所定の値より多い場合に、新しい価値実現モデルを生成してもよい。また、新しい価値実現モデルを自動的に生成してもよいが、新しい価値実現モデルの生成をシステム管理者に提案して、システム管理者の操作に従って新しい価値実現モデルを生成してもよい。
【0073】
<実施例3>
次に、実施例1と同様に、N倍化先となる顧客に対し、コンポーネントの品ぞろえに基づく見積もりの出し方の一例を示す。前述したように、デジタルソリューションにおいて顧客は所望するのは「価値」そのものであり、他の顧客に既に同様の「価値」を提供を実施した事例がプロバイダ側にある場合、当然に同様の「機能」が存在しており、円滑なN倍化により開発コストも安くなり、その分顧客に提示される見積もり額も低くなるという期待を持たれることも少なくない。しかし前述の通り、いくら「価値」がN倍化可能であっても、「機能」がどこまでN倍化可能な状態で揃っているかは、そのデジタルソリューションによって異なってくる場合がある。このことが、顧客とプロバイダとの間で大きな認識な齟齬へとつながり、見積りについてのコンセンサスが取れず、商談の大きな妨げとなる場合がある。そこで、本実施例においては、実施例1,2で述べてきた「価値」と対応する「機能」、特に「コンポーネント」の品ぞろえがどの程度整っているかを顧客に対しても明示可能とすることで、顧客に対して納得感の高い見積もりの提示を実現する方法等について述べる。
【0074】
図10に、ソフトウェア管理システム1が実行する見積もり作成プログラムが実行する見積もり作成処理のフローチャートを示す。
【0075】
まず、ソフトウェア管理システム1は、顧客(B2)から要望された価値に基づいて、価値データベース32から取得した価値(V2)、アクティビティデータベース33から取得したアクティビティに基づいて、既に他の顧客(B2)に提供したことのあるソリューション(以下「既存ソリューション」)であるか否かを判定する(S301)。既存ソリューションではない場合、ソリューション全体を新規に開発する必要があるため、高開発コストになる可能性が高いと判定される(S302)。
【0076】
一方、既存ソリューションが存在している場合、ソフトウェア管理システム1は、ユーザインターフェースデータベース34及びコンポーネントデータベース35を参照して、当該機能を実現するためのソフトウェアが開発済みかを判定する(S303)。ソフトウェアが開発済みである場合、既に開発されたソフトウェアが流用可能なので、開発コストは低いと判定される(S304)。一方、ソフトウェアが未開発である場合、既存のソフトウェアのカスタマイズ、あるいは小規模の新規開発により対応できる可能性が高いため、開発コストは中程度と判定される(S305)。前述はあくまで一例であるため、例えばS305での判定において、カスタマイズと小規模の新規開発との間で開発コストの重みづけに差をつけてもよい。また、ソリューション全体での開発コストの算出方法ついては、例えば顧客から要望された価値について、既存ソリューションのみで全て賄えた場合と相対的に比較し、あらかじめコンポーネントの単位ごとに数で判断してもよいし、コンポーネントごとに、開発コストとの対応付けがされた属性情報を付与しておき、当該属性情報を基に開発コストを算出してもよい。
【0077】
最後に、ソフトウェア管理システム1は、算出した開発コストの見積もりを端末等に表示するためのデータを出力する(S306)。
【0078】
前述により、顧客(V2)から要望された「価値」について、すぐに信ぴょう性の高い見積もりを、コンポーネントの品ぞろえに基づく開発コストの根拠理由と共に明示することが可能となるため、顧客にとって納得感の高い見積もりを提示することが可能となる。
【0079】
以上に説明したように、本発明の実施例のソフトウェア管理システムでは、補助記憶装置103が、情報処理システムによって利用者に提供される価値を表す価値情報(価値データベース32)と、価値が利用者に提供されるまでの時系列のアクティビティを表すアクティビティ情報(アクティビティデータベース33)と、アクティビティを実現する機能を構成するソフトウェアを表す機能情報(ユーザインターフェースデータベース34、コンポーネントデータベース35)とを格納し、プロセッサ101は、価値情報の指定を受け付け、アクティビティデータベース33及び機能情報34、35を参照して、指定された価値情報に基づいて、前記機能情報を出力するので、効率的、拡散的に顧客にデジタルソリューションを提供できる。
【0080】
また、補助記憶装置103は、時系列の複数のアクティビティを含む価値実現情報(価値実現テンプレート37)を格納し、プロセッサ101は、情報処理システム(デジタルソリューション)が時系列に実行する前記機能を監視した結果である監視情報を取得し、取得した監視情報と価値実現テンプレート37とを照合して、利用者に提供された価値を判定するので、ユーザに提供された価値を正確に把握できる。
【0081】
また、プロセッサ101は、取得した監視情報と価値実現テンプレート37とを照合して、情報処理システム(デジタルソリューション)が実行した機能によって、価値実現テンプレート37に含まれる達成されたアクティビティを決定し、アクティビティ毎の達成度を算出し、算出された達成度に基づいて、アクティビティによって提供される価値を表す情報を出力するので、ユーザに提供された価値を正確に把握できる。
【0082】
また、プロセッサ101は、取得した監視情報と価値実現テンプレート37とを照合して、情報処理システム(デジタルソリューション)が実行した機能によって、価値実現テンプレート37に含まれる達成されたアクティビティを決定し、アクティビティが完了状態でない場合、当該アクティビティのうち、達成されたアクティビティのみを含む新たな価値実現情報を生成するので、ユーザが満足する新たな価値を検出できる。
【0083】
また、機能情報は、機能を実現する際のユーザの操作に関するユーザインターフェース情報(ユーザインターフェースデータベース34)と、前記機能を実現するために実行されるソフトウェアに関するコンポーネント情報(コンポーネントデータベース35)とを含み、プロセッサ101は、ユーザインターフェースデータベース34及びコンポーネントデータベース35を参照して、所望の機能を実現するためのユーザインターフェース情報及びコンポーネント情報の有無を判定し、判定結果に基づいて、利用者がソフトウェア管理システムによって提供される価値の見積価格を算出するので、顧客に提供されるデジタルソリューションのコストを簡単に算出できる。
【0084】
なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。
【0085】
また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。
【0086】
各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、SSD(Solid State Drive)等の記憶装置、又は、ICカード、SDカード、DVD等の記録媒体に格納することができる。
【0087】
また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。
【符号の説明】
【0088】
1 価値・機能連携システム
11 Value層
12 Function層
13 提供価値監視コンポーネント
21 フロー
22 アクティビティ
31 価値創出原理データベース
32 価値データベース
33 アクティビティデータベース
34 ユーザインターフェースデータベース
35 コンポーネントデータベース
36 コンポ参照用データベース
37 価値実現テンプレート
38 価値実現モデル達成表
39 価値実現モデル記録部
101 プロセッサ
102 メモリ
103 補助記憶装置
104 通信インターフェース
105 入力インターフェース
106 キーボード
107 マウス
108 出力インターフェース
109 ディスプレイ装置
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10