JP2019215748A - コンピュータプログラム、出力装置及び出力方法 - Google Patents

Abstract

【課題】金融機関が参照可能な評価情報と共に、協業先候補である事業体に対して、課題解決力評価を行うと共に、協業適格性評価情報を出力可能なコンピュータプログラム、出力装置及び出力方法を提供する。【解決手段】コンピュータプログラムは、事業体が自己申告した事業体情報及び事業を構成する部品の部品情報を取得し、前記部品の課題解決力評価情報及び金融機関が参照可能な前記事業体の協業性適格性評価情報を取得し、ビジネスモデルの要件を定義する要件定義情報を取得し、前記部品情報及び前記要件定義情報を参照し、取得した前記要件定義情報に対応する部品情報を選択し、選択した前記部品情報及び前記部品情報に対応付けられた課題解決力評価情報、並びに前記部品情報に対応付けられた事業体の事業情報及び協業性適格性情報を出力する処理をコンピュータに実行させる。【選択図】図２

Description

本発明は、協業先候補となる事業体を出力するコンピュータプログラム等に関する。

近年、複数の事業体（例えば企業）が業務提携を行い、新規事業を単独ではなく複数の事業体で遂行することが行われている。それに対して、協業先候補を検索、紹介するシステムが提案されている（例えば、特許文献１）。

特開２００７−２１３５６４号公報

企業が新規事業に開始するため協業先を探す際、銀行等の金融機関に紹介を依頼することがある。金融機関は協業先を紹介するに当たっては、候補となる企業（「提案企業」という。）について、次の２つの評価が求められる。１つ目は、協業先を探している企業（「探索企業」という。）が抱えている課題を解決するための能力を有しているか否かの評価（「課題解決力評価」）である。２つ目は、信用力の評価などに基づく、適格性の評価（「協業適格性評価」）である。

本発明は係る事情に鑑みてなされたものである。その目的は、協業先候補である事業体に対して、課題解決力評価を行うと共に、協業適格性評価情報を出力可能なコンピュータプログラム等を提供することである。

本発明に係るコンピュータプログラムは、事業体が自己申告した事業体情報及び事業を構成する部品の部品情報を取得し、前記部品の課題解決力評価情報及び金融機関が参照可能な前記事業体の協業適格性評価情報を取得し、ビジネスモデルの要件を定義する要件定義情報を取得し、前記部品情報及び前記要件定義情報を参照し、取得した前記要件定義情報に対応する部品情報を選択し、選択した前記部品情報及び前記部品情報に対応付けられた課題解決力評価情報、並びに前記部品情報に対応付けられた事業体の事業体情報及び協業適格性評価情報を出力する処理をコンピュータに実行させることを特徴とする。

本発明にあっては、協業先候補である事業体に対する課題解決力評価、及び協業適格性評価情報を出力するので、協業先候補となる事業体を金融機関が適切に選定可能となる。

ビジネスモデル開発システムの構成例を示す説明図である。 メインサーバのハードウェア構成例を示すブロック図である。 行内サーバのハードウェア構成例を示すブロック図である。 金融機関端末のハードウェア構成例を示すブロック図である。 企業ＤＢの例を示す説明図である。 事業ＤＢの例を示す説明図である。 品目ＤＢの例を示す説明図である。 品目ＤＢの第１階層列の例を示す説明図である。 品目ＤＢの第２階層列の例を示す説明図である。 品目ＤＢの第３階層列の例を示す説明図である。 品目管理ＤＢの例を示す説明図である。 探索ニーズＤＢの例を示す説明図である。 応募登録ＤＢの例を示す説明図である。 募集テーマＤＢの例を示す説明図である。 アイデア応募ＤＢの例を示す説明図である。 評価ＤＢの例を示す説明図である。 開示設定ＤＢの例を示す説明図である。 限定グループＤＢの例を示す説明図である。 経営資源調達型のプロセス例を示すシーケンス図である。 企業情報登録画面の例を示す説明図である。 企業情報登録画面の例を示す説明図である。 探索ニーズ登録画面の例を示す説明図である。 技術内容画面の例を示す説明図である。 探索ニーズ確認画面の例を示す説明図である。 レシピ登録画面の例を示す説明図である。 第１階層登録領域の例を示す説明図である。 第２階層登録領域の例を示す説明図である。 第３階層登録領域の例を示す説明図である。 モデルチャート登録画面の例を示す説明図である。 応募登録画面の例を示す説明図である。 評価画面の内容を示す説明図である。 モデルチャート表示画面の例を示す説明図である。 アイデア募集型のプロセス例を示すシーケンス図である。 募集テーマ登録画面の例を示す説明図である。 アイデア登録画面の例を示す説明図である。 モデルチャート登録画面の例を示す説明図である。 評価画面の内容を示す説明図である 企業情報登録処理の手順例を示すフローチャートである。 探索ニーズ登録処理の手順例を示すフローチャートである。 ロングリスト作成処理の手順例を示すフローチャートである。 応募登録処理の手順例を示すフローチャートである。 「強み」情報更新処理の手順例を示すフローチャートである。 「強み」情報更新処理の手順例を示すフローチャートである。 ショートリスト作成処理の手順例を示すフローチャートである。 成約処理の手順例を示すフローチャートである。 部品の分割と部品の統合の例を示す説明図である。 企業選定処理の手順例を示すフローチャートである。 企業選定処理の例を示す説明図である。 企業選定処理の例を示す説明図である。 企業選定処理の例を示す説明図である。

以下、図面を参照しつつ、本開示に係る実施の形態を説明する。

以下の説明では実施の形態として、ビジネスモデルファクトリについて説明する。ビジネスモデルファクトリは、製造業におけるＢＯＭ（Ｂｉｌｌ Ｏｆ Ｍａｔｅｒｉａｌ：部品表）を用いた設計・製造システムに発想を得たビジネスモデルの製造システムである。金融機関は、ビジネスモデルファクトリを用いて、ビジネスモデルの設計図に基づき、顧客である事業体の「強み」を部品として調達し、組み立て、完成させることが、可能となる。すなわち、ビジネスモデルファクトリでは、「強み」を持つ複数の事業体を集め、協業させることにより、新たなビジネスモデルを創出することができる。「強み」とは、他社との差別化を図れるものであって、例えば、特許権を取得している技術や独自ノウハウである。「強み」はそれらに限らず、物流網や代理店網なども含む。ここでは、「強み」は、いわゆる経営資源要素とほぼ同等である。なお、以下の説明において、金融機関は銀行、事業体は企業として、説明する。

以下において、探索企業とは新たなビジネスモデルについての事業を実行するために、協業相手となる企業を探している企業である。提案企業とは探索企業の協業相手の候補となる企業である。いずれの企業もケースによって、探索企業にもなり得るし、提案企業にもなり得る。運営組織とは、探索企業と提案企業との橋渡しを行う組織である。ここで、運営組織は銀行とする。

更に、ビジネスモデルを統一的に扱えるようにするため、ビジネスモデルの構成を３階層からなる木構造で定義するものとする。第１階層はビジネスモデルに対応する。第１階層をビジネスモデル提供価値定義（提供価値定義情報）という。第１階層は木構造のルートノードである。第２階層は価値を提供するためのスキーム（提供の仕組み）に対応する。第２階層は木構造の中間ノードである。第２階層を価値提供スキーム（プロセス情報）という。第３階層は価値提供スキームを実現するために必要とする経営資源に対応する。第３階層は木構造のリーフノードである。第３階層をキーとなる経営資源（固有技術、経営資源情報）という。木構造を視覚的に表現したものを、ビジネスモデルチャートという。ビジネスモデルチャートを単にモデルチャートともいう。

図１はビジネスモデル開発システム１００の構成例を示す説明図である。ビジネスモデル開発システム１００は、上述のビジネスモデルファクトリに係る実施の形態の一例である。

ビジネスモデル開発システム１００はメインサーバ１、行内サーバ２、金融機関端末３、探索企業端末４及び提案企業端末５を含む。メインサーバ１はビジネスモデル開発システム１００を運用するために必要なデータを記憶し、各種処理を行う。行内サーバ２は銀行のみが用いるサーバである。行内サーバ２は外部には公開しない顧客企業の与信情報などを記憶している。ネットワークＮ１は公衆網である。ネットワークＮ２は、ファイアウォール等で、銀行外部から遮断されているネットワークである。

図２はメインサーバ１のハードウェア構成例を示すブロック図である。メインサーバ１はサーバコンピュータ等で構成する。メインサーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、通信部１４、大容量記憶部１５及び読み取り部１６を含む。各構成はバスＢで接続されている。

ＣＰＵ１１はＲＯＭ１２に記憶された制御プログラム１Ｐにしたがい、ハードウェア各部を制御する。ＲＡＭ１３は例えばＳＲＡＭ（Ｓｔａｔｉｃ ＲＡＭ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ ＲＡＭ）又はフラッシュメモリである。ＲＡＭ１３はＣＰＵ１１によるプログラムの実行時に発生するデータを一時的に記憶する。

通信部１４は第１通信部１４１及び第２通信部１４２を含む。第１通信部１４１はネットワークＮ１を介して、探索企業端末４及び提案企業端末５と通信を行う。第２通信部１４２は、ネットワークＮ２を介して、行内サーバ２及び金融機関端末３と通信を行う。

大容量記憶部１５は、例えばハードディスク又はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などである。大容量記憶部１５は各種データベース（ＤＢ：ＤａｔａＢａｓｅ）を記憶する。大容量記憶部１５は各種を記憶する。また、制御プログラム１Ｐを大容量記憶部１５に記憶してもよい。各種ＤＢは、メインサーバ１以外に記憶してもよい。例えばデータベースサーバに記憶してもよい。

読み取り部１６はＣＤ−ＲＯＭ及びＤＶＤ−ＲＯＭを含む可搬型記憶媒体１ａを読み取る。ＣＰＵ１１が読み取り部１６を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、大容量記憶部１５に記憶してもよい。また、ＣＰＵ１１が通信部１４を用い、ネットワークＮ１等を介して他のコンピュータから制御プログラム１Ｐをダウンロードし、大容量記憶部１５に記憶してもよい。なお、メインサーバ１の機能をクラウドサービスにより提供してもよい。更にまた、半導体メモリ１ｂから、ＣＰＵ１１が制御プログラム１Ｐを読み込んでもよい。

図３は行内サーバ２のハードウェア構成例を示すブロック図である。行内サーバ２は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、通信部２４、大容量記憶部２５を含む。各構成はバスＢで接続されている。ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３及び通信部２４は、それぞれメインサーバ１のＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３及び通信部１４と同様であるから説明を省略する。大容量記憶部２５は、例えばハードディスク又はＳＳＤなどである。大容量記憶部２５は顧客ＤＢ２５１及び企業情報ＤＢ２５２を記憶する。また、制御プログラム２Ｐを大容量記憶部２５に記憶してもよい。顧客ＤＢ２５１及び企業情報ＤＢ２５２は、行内サーバ２以外に記憶してもよい。例えばデータベースサーバに記憶してもよい。セキュリティや運用安定性が十分確保できるのであれば、クラウドストレージに顧客ＤＢ２５１及び企業情報ＤＢ２５２を記憶してもよい。

顧客ＤＢ２５１は銀行が保有している顧客の情報を記憶する。顧客ＤＢ２５１には、顧客名称、代表者名、所在地、取引支店、口座番号、口座残高等を記憶する。企業情報ＤＢ２５２は顧客である企業についての様々な情報を記憶する。企業情報は例えば、財務情報、ＩＲ（Ｉｎｖｅｓｔｏｒ Ｒｅｌａｔｉｏｎｓ）情報及び財務分析情報、格付情報、与信情報及び信用リスク情報・劣化リスク情報、反社会勢力関連性情報、並びに人材情報（経営者、中核人材）、業界調査レポート及び企業調査レポートである。これらの企業情報は銀行が独自に収集、蓄積したものでもよいし、格付機関、シンクタンク、信用調査機関などの外部から取得したものでもよい。企業情報ＤＢ２５２に記憶している情報は、協業適格性情報の例である。なお、顧客ＤＢ２５１と企業情報ＤＢ２５２とを、単一のデータベースとしてもよい。

図４は金融機関端末３のハードウェア構成例を示すブロック図である。金融機関端末３はＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、通信部３４、入力部３５、表示部３６及び大容量記憶部３７を含む。各構成はバスＢで接続されている。ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、通信部３４及び大容量記憶部３７は、それぞれメインサーバ１のＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、通信部１４及び大容量記憶部１５と同様であるから説明を省略する。

入力部３５はキーボードやマウスである。表示部３６は液晶表示装置である。表示部３６はデータ処理の結果などを表示する。また、入力部３５は表示部３６と一体化したタッチパネルでもよい。なお、金融機関端末３は外部の表示装置に表示を行ってもよい。

探索企業端末４及び提案企業端末５は、金融機関端末３と同様な構成である。したがって、探索企業端末４及び提案企業端末５の構成の図示や詳しい説明は省略する。

次に、メインサーバ１が記憶するデータベースについて、説明する。図５は企業ＤＢ１５１の例を示す説明図である。企業ＤＢ１５１は企業の基本情報（事業体情報）を記憶するデータベースである。企業ＤＢ１５１は会社ＩＤ列、名称列、法人番号列、ＵＲＬ列、本社住所列、代表者列、設立年月日列、資本金列、売上高列、決算期列、従業員数列、業界・業種列及び主要事業列を含む。会社ＩＤ列は会社を一意に特定可能な会社ＩＤを記憶する。名称列は会社の名称を記憶する。法人番号列は企業に付与された１３桁の法人番号を記憶する。ＵＲＬ列は会社に関するインターネットホームページのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を記憶する。本社住所列は会社の本社所在地の住所を記憶する。代表者列は会社代表者、例えば代表取締役の氏名を記憶する。設立年月日列は会社が設立された日を記憶する。資本金列は会社の資本金額を記憶する。売上高列は会社の売上高の金額を記憶する。決算期列は会社の決算期を記憶する。従業員数列は会社の従業員数を記憶する。業界・業種列は会社が属する業界・業種を記憶する。主要事業列は企業の主要事業を記憶する。

図６は事業ＤＢ１５２の例を示す説明図である。事業ＤＢ１５２は企業が行っている事業についての情報を記憶するデータベースである。事業ＤＢ１５２は会社ＩＤ列、事業ＩＤ列、事業列、提供する価値列、主力商品・サービス列、主要顧客列、主な得意先列、主な仕入先列、競合他社列、拠点列、提供可能資源要素列及び品目Ｎｏ．列を含む。会社ＩＤ列は会社ＩＤ（事業体の識別情報）を記憶する。事業ＩＤ列は事業を一意に特定可能な品目番号を記憶する。事業列は事業の名称を記憶する。提供する価値列は、会社が事業により顧客に提供する価値を記憶する。主力商品・サービス列は、事業における主な商品やサービスを記憶する。主要顧客列は事業の主な顧客を記憶する。主な得意先列は事業における主要な得意先を記憶する。主な仕入先列は事業における主要な仕入れ先を記憶する。競合他社列は事業における競合他社を記憶する。拠点列は事業における拠点を記憶する。拠点列は研究開発列、生産列、販売列及び物流列を含む。研究開発列は事業における研究開発拠点の情報を記憶する。生産列は事業における生産拠点の情報を記憶する。販売列は事業における販売拠点の情報を記憶する。物流列は事業における物流拠点の情報を記憶する。提供可能資源要素列は事業を行うために有している経営資源のうち、他社に提供可能な経営資源要素を記憶する。品目Ｎｏ．列は提供可能資源要素列に記憶する各経営資源要素に対応した品目番号を記憶する。

図７は品目ＤＢの例を示す説明図である。品目ＤＢ１５３はビジネスモデルの構成要素となる部品の情報（部品情報）を記憶する。図８は品目ＤＢの第１階層列の例を示す説明図である。図９は品目ＤＢの第２階層列の例を示す説明図である。図１０は品目ＤＢの第３階層列の例を示す説明図である。品目ＤＢ１５３は品目Ｎｏ．列、名称列、区分列、第１階層列、第２階層列、第３階層列及び企業ＩＤ列を含む。品目Ｎｏ．列は品目を一意に特定可能な品目番号を記憶する。名称列は品目の名称を記憶する。区分列は品目の区分を記憶する。区分が１は、品目が第１階層に属すること、ビジネスモデル提供価値定義であることを示す。区分が２は、品目が第２階層に属すること、価値提供スキームであることを示す。区分が３は、品目が第３階層に属すること、経営資源要素であることを示す。第１階層列は、品目が第１階層に属する場合に、品目の内容を記憶する。第２階層列は、品目が第２階層に属する場合に、品目の内容を記憶する。第３階層列は、品目が第３階層に属する場合に、品目の内容を記憶する。第１階層列、第２階層列及び第３階層列は、１つのレコード内では区分に応じた１列のみに具体的な内容が記憶され、残りの２列は空白が記憶されるか空である。企業ＩＤ列は品目を保有する企業の企業ＩＤを記憶する。

品目ＤＢ１５３の第１階層列は図８に示すように、事業コンセプト概要列、顧客へ提供する価値列、価値提供スキーム列及び収益モデル列を含む。図８に示す品目Ｎｏ．列は、図７との対照がしやすいように示している。事業コンセプト概要列は事業コンセプト（ビジネスモデル）の概要を記憶する。顧客へ提供する価値列は事業が顧客に提供する価値を記憶する。価値提供スキーム列は価値を提供するためのスキームを記憶する。収益モデル列は事業が収益を生む仕組み（収益モデル）を記憶する。

品目ＤＢ１５３の第２階層列は図９に示すように、機能・プロセス区分列、プロセス定義列及び経営資源要素列を含む。図９に示す品目Ｎｏ．列は、図７との対照がしやすいように示している。機能・プロセス区分列はその品目が属する機能・プロセス区分を記憶する。プロセス定義列はその品目の内容を記憶する。経営資源要素列はその品目がユニークな機能を発揮する上で、コアとなっている経営資源要素を記憶する。機能・プロセス区分は、例えば「研究開発」、「商品・サービス企画」、「営業・受注」、「設計・試作」、「調達」、「生産」、「販売」、「物流」、「サービス」、「情報収集・蓄積」、「分析・予測」、「請求・回収」及び「その他」である。

品目ＤＢ１５３の第３階層列は図１０に示すように、品目分類列、現在の活用領域（用途）列、解決できる課題列、スペック・特長列及び検索キーワード列を含む。品目分類列は品目の分類を記憶する。品目の分類は、例えば「技術・ノウハウ」、「市場調査・マーケティング」、「調達価格交渉力」、「品質（歩留まり）・コスト（製造原価）・スピード（リードタイム）」、「生産体制・外注ネットワーク・生産設備・生産能力」、「販売体制とセールスフォース・販売チャネル」、「基盤顧客・市場地位・シェア」、「情報の収集・蓄積・活用」、「ブランド」及び「人材（質・量）」である。現在の活用領域（用途）列は品目の用途、現在の活用領域を記憶する。解決できる課題列は、品目により解決できる課題を記憶する。スペック・特長列は品目のスペックや特長を記憶する。検索キーワード列は品目を検索するためのキーワードを記憶する。

図１１は品目管理ＤＢの例を示す説明図である。品目管理ＤＢ１５４は従来のＢＯＭに相当するものである。品目管理ＤＢ１５４はビジネスモデルを構成する品目の一覧を記憶する。品目管理ＤＢ１５４は上位層列、中位層列及び下位層列を含む。上位層列は主としてビジネスモデル提供価値定義の品目番号を記憶する。中位層列は主として価値提供スキームの品目番号を記憶する。下位層列は主として経営資源の品目番号を記憶する。中位層列には価値提供スキーム以外の品目番号を記憶してもよい。また、下位層列に経営資源以外の品目番号を記憶してもよい。複数のビジネスモデルを融合させて、新たなビジネスモデルを創造する場合、新たなビジネスモデルの価値提供スキームは、複数のビジネスモデルとして、表現されるからである。このように、品目管理ＤＢ１５４は品目同士の関係を記憶するデータベースである。

図１２は探索ニーズＤＢの例を示す説明図である。探索ニーズＤＢ１５５は経営資源調達型における探索ニーズを記憶する。探索ニーズＤＢ１５５は探索Ｎｏ．列、募集企業列、探索目的列、探索対象技術列、従来技術列、問題状況列、要求スペック列、除外技術列、キーワード列及びチャート列を含む。探索Ｎｏ．列は探索ニーズを一意に特定可能な探索番号を記憶する。探索番号は新規にレコードが作られたときに発番される。募集企業列はニーズに合致するものを探索、あるいは募集している企業の企業ＩＤを記憶する。探索目的列は探索の目的を記憶する。探索対象技術列は探索対象とする技術、探索ニーズに適合する技術を端的に表したものを記憶する。従来技術列は探索対象とする技術に関係する従来技術を記憶する。問題状況列は従来技術の問題状況を記憶する。要求スペック列は探索対象とする技術に要求するスペックを記憶する。除外技術列は探索するに当たり除外する技術を記入する。キーワード列は探索対象とする技術を検索するためのキーワードを入力する。チャート列は探索ニーズを必要としているビジネスモデルを表現するモデルチャートの第１階層の品目番号を記憶する。

図１３は応募登録ＤＢの例を示す説明図である。応募登録ＤＢ１５６は探索ニーズに対する応募のデータを記憶する。応募登録ＤＢ１５６は探索Ｎｏ．列、応募Ｎｏ．列、枝Ｎｏ．列、区分列、第３階層列、第２階層列及び企業ＩＤ列を含む。探索Ｎｏ．列は探索ニーズを特定するための探索番号を記憶する。応募Ｎｏ．列は応募データを特定するための応募番号を記憶する。ここでは応募番号は探索番号と同一としてある。枝Ｎｏ．列は列内で一意の枝番号を記憶する。枝番号は新規にレコードが作られたときに発番される。応募番号と枝番号とを合わせることにより、応募のデータを一意に特定可能となる。区分列は応募データが第２階層（価値提供スキーム）又は第３階層（キーとなる経営資源（固有技術））に属することを示す値を記憶する。応募データが第２階層の場合は２を、応募データが第３階層の場合は３を記憶する。第３階層列は分類列、用途列、解決できる課題列、スペック・特長列、添付ファイル列及びキーワード列を含む。第３階層列に含まれる各列は、区分列の値が３であるときに、データを記憶する。分類列は、応募に係る経営資源の分類を記憶する。用途列は応募に係る経営資源の用途、現在の活用領域を記憶する。解決できる課題列は応募に係る経営資源が解決できる課題を記憶する。スペック・特長列は応募に係る経営資源のスペックや特長を記憶する。添付ファイル列は応募に係る経営資源に関する資料ファイルの名称等を記憶する。資料ファイルの実体は品目番号と紐付けられ、大容量記憶部１５に記憶される。キーワード列は、応募に係る経営資源に対する検索キーワードを記憶する。第２階層列は機能・プロセス区分列、プロセス定義列、経営資源列を含む。第２階層列に含まれる各列は、区分列の値が２であるときに、データを記憶する。機能・プロセス区分列は応募に係る提供価値スキームを示す機能・プロセスの区分を記憶する。プロセス定義列は応募に係る提供価値スキームの機能又はプロセスの内容を記憶する。経営資源列は応募に係る提供価値スキームの機能又はプロセスの有効性や競争優位性を形成しているコアとなる経営資源要素を記憶する。企業ＩＤ列は応募を行う企業の企業ＩＤを記憶する。応募登録ＤＢ１５６に応募のデータが登録される際には、第２階層列又は第３階層列のデータに対して品目番号が発番され、品目ＤＢ１５３に記憶される。

図１４は募集テーマＤＢ１５７の例を示す説明図である。募集テーマＤＢ１５７はアイデア募集型における募集するアイデアのテーマを記憶する。募集テーマＤＢ１５７は企業ＩＤ列、募集Ｎｏ．列、テーマ列、前提条件列、評価基準列及び経営資源列を含む。企業ＩＤ列はアイデアを募集する企業（募集企業）の企業ＩＤを記憶する。募集Ｎｏ．列はアイデアの募集テーマを一意に特定する募集番号を記憶する。募集番号は新規にレコードを追加するときに発番される。テーマ列は募集を行うテーマを記憶する。前提条件列は募集テーマに関するアイデアを考える上で、前提とする条件を記憶する。評価基準列はアイデアに対する評価の基準を記憶する。経営資源列はアイデアの募集に当たり、募集企業が提供可能な経営資源を記憶する。経営資源列は品目Ｎｏ．列、概要列、及び添付資料列を記憶する。品目Ｎｏ．列は経営資源に対応する品目番号を記憶する。概要列は経営資源の概要を記憶する。添付資料列は経営資源に関する添付資料のファイル内容を記憶する。添付資料列に、ファイル名及びファイル形式を記憶してもよい。また、添付資料列にはファイル名のみを記憶し、ファイルの実体を品目番号に紐付けて大容量記憶部１５に記憶してもよい。

図１５はアイデア応募ＤＢの例を示す説明図である。アイデア応募ＤＢ１５８はアイデア募集に対する応募のデータを記憶する。アイデア応募ＤＢ１５８は企業ＩＤ列、募集Ｎｏ．列、応募Ｎｏ．列、枝番列、ビジネスモデル名列、概要列、提供価値列、スキーム列、添付資料列及びレシピ列を含む。企業ＩＤ列は応募している企業の企業ＩＤを記憶する。募集Ｎｏ．列はどの募集テーマに対する応募であるかを示す募集テーマの募集番号を記憶する。応募Ｎｏ．列は応募を特定するための応募番号を記憶する。ここでは、応募番号は募集番号と同一としてある。枝番列は列内で一意の枝番号を記憶する。枝番号は新規にレコードが作られたときに発番される。応募番号と枝番号とを合わせることにより、応募のデータを一意に特定可能となる。ビジネスモデル名列は応募するアイデア（ビジネスモデル）の名称を記憶する。概要列はビジネスモデルのコンセプト概要を記憶する。提供価値列はビジネスモデルが顧客に提供する価値を記憶する。スキーム列は顧客へ価値をどのような仕組みで提供するかを示す提供スキームを記憶する。添付資料列は資料として添付された添付資料のファイル内容を設定する。添付資料列に、ファイル名及びファイル形式を記憶してもよい。また、添付資料列にはファイル名のみを記憶し、ファイルの実体は大容量記憶部１５に記憶してもよい。レシピ列はビジネスモデルに対応するビジネスモデルチャートを特定する品目番号を記憶する。アイデア応募ＤＢ１５８に応募のデータが登録される際には、ビジネスモデル名列、概要列、提供価値列、スキーム列の内容が品目番号と対応付けられて、品目ＤＢ１５３に記憶される。

図１６は評価ＤＢの例を示す説明図である。評価ＤＢ１５９は案件別評価実績と品目別評価実績とを含む。案件別評価実績はその案件において各品目がどのような評価をされたかの記録である。案件別評価実績には協業適格性評価を含む。品目別評価実績はその品目がどれだけ関心を集め、どのような案件で採用候補にあがり、実際に採用され活用されたかなどを含む。図1６に示すのは評価ＤＢ１５９のうち、品目別評価実績の例である。案件とは経営資源調達型、及びアイデア募集型を含む、個々のビジネスモデル開発プロセスである。評価ＤＢ１５９は品目Ｎｏ．列、被検索履歴列、閲覧履歴列、ロングリスト履歴列、課題解決力評価点列、ショートリスト履歴列、最終選定・成約実績列、事業化後の業績列、及び上位階層での評価の波及列を含む。品目Ｎｏ．列は品目Ｎｏ．を記憶する。被検索履歴列は検索に対してヒットした履歴を記憶する。検索された日時、検索者、検索に使用されたキーワードなどを記憶する。閲覧履歴列は閲覧された履歴を記憶する。閲覧された日時、閲覧者、検索に使用されたキーワードなどを記憶する。ロングリスト履歴列はロングリストに抽出された回数、抽出された案件のＩＤ（探索Ｎｏ．や募集Ｎｏ．）等を記憶する。課題解決力評価点列は課題解決力評価についての評価点を記憶する。課題解決力評価における各評価項目の平均点、又は合計点を記憶する。ショートリスト履歴列は、ショートリストに抽出された回数、抽出された案件のＩＤ（探索Ｎｏ．や募集Ｎｏ．）等を記憶する。最終選定・成約実績列は開発プロセス（開発案件）において最終選定に残った場合、成約に至った場合の履歴を記憶する。事業化後の業績列は品目が第１階層の場合、ビジネスモデルを事業化した後の事業実績を記憶する。例えば、事業化後３年経過時点の業績を４段階評価した結果の数値を記憶する。上位階層での評価の波及列は、品目が第２階層又は第３階層の場合、上位層での評価を波及させた評価を記憶する。上位層の評価と階層の評価とを連動させる。

図１７は開示設定ＤＢの例を示す説明図である。開示設定ＤＢ１５Ａは各品目の各項目についての開示設定を記憶する。開示設定ＤＢ１５Ａは品目Ｎｏ．列、区分列、第１階層列、第２階層列、第３階層列及び企業ＩＤ列を含む。品目Ｎｏ．列は設定対象の品目番号を記憶する。区分列は品目の区分を記憶する。品目が第１階層の場合、区分列は１を記憶する。品目が第２階層の場合、区分列は２を記憶する。品目が第３階層の場合、区分列は３を記憶する。第１階層列、第２階層列及び第３階層列の各列は、該当する階層の開示設定を記憶する。企業ＩＤ列は品目を所有する企業の企業ＩＤを記憶する。

第１階層列は更に、概要列、提供価値列、スキーム列及び収益列を含む。概要列は概要（事業コンセプト概要）に対する開示設定を記憶する。提供価値列は顧客へ提供する価値に対する開示設定を記憶する。スキーム列は価値提供スキームに対する開示設定を記憶する。収益列は収益モデルに対する開示設定を記憶する。第２階層列は更に、区分列、定義列及び経営資源列を含む。区分列には品目の機能・プロセス区分に対する開示設定を記憶する。定義列にはプロセス定義に対する開示設定を記憶する。経営資源列はコアとなる経営資源要素に対する開示設定を記憶する。第３階層列は更に、品目分類列、活用領域列、解決課題列、スペック列及びキーワード列を含む。品目分類列は品目分類に対する開示設定を記憶する。活用領域列は現在の活用領域に対する開示設定を記憶する。解決課題列は解決できる課題に対する開示設定を記憶する。スペック列はスペック・特長に対する開示設定を記憶する。キーワード列は検索キーワードに対する開示設定を記憶する。

例えば、開示設定は「開示」、「限定開示」、「非開示」の３種類である。「開示」は全てのユーザが参照可能である。「限定開示」は一部のユーザが参照可能である。「非開示」は所有するユーザ以外は参照不可である。なお、運営組織に属するユーザは開示設定に関わらず、全品目の全項目が参照可能である。また、ビジネスモデル開発プロセスの進行状況によって、メインサーバ１が更新する他、運営組織のユーザが進行状況に合わせて、更新する。更にまた、開示設定ＤＢ１５Ａの内容として、更新日時及び更新者のＩＤ（企業の場合は企業ＩＤ、運営組織の場合は各ユーザのＩＤ）を記憶してもよい。

図１８は限定グループＤＢの例を示す説明図である。限定グループＤＢ１５Ｂは限定開示に設定された品目の参照権限を記憶する。限定グループＤＢ１５Ｂは品目Ｎｏ．列、探索Ｎｏ．列、応募Ｎｏ．列、成約Ｎｏ．列及び企業ＩＤ列を含む。品目Ｎｏ．列は設定対象の品目番号を記憶する。探索Ｎｏ．列は参照権限が経営資源調達型開発プロセスに関連している場合、当該開発プロセスに振られた探索番号を記憶する。応募Ｎｏ．列は参照権限がアイデア募集型開発プロセスに関連している場合、当該開発プロセスに振られた応募番号を記憶する。成約Ｎｏ．は開発プロセスが成約に至った場合に振られた当該成約を特定する成約番号を記憶する。企業ＩＤ列は参照が許可された企業の企業ＩＤを記憶する。限定グループＤＢ１５Ｂの設定にしたがい、各品目の評価情報の参照権限も制御可能である。

限定グループＤＢ１５Ｂは探索番号又は応募番号に対応付けて、参照権限を設定可能であるので、ビジネスモデル開発プロセス毎に設定可能である。それにより、同一の企業が複数の開発プロセスに、探索企業、提案企業として参加し、当該複数の開発プロセスに共通する要素があったとしても、プロセス毎の権限が混ざり合うことなく、設定可能である。また、運営組織のユーザが設定を行う場合、例えば、ロングリスト、ショートリストの内容に合わせて、企業ＩＤ列に記憶する内容を変更するよう、メインサーバ１に指示すればよいので、容易に設定可能である。開示設定ＤＢ１５Ａ及び限定グループＤＢ１５Ｂにより、許可情報が構成されている。

次に、ビジネスモデル開発システム１００の運用イメージについて説明する。ここでは、ビジネスモデルを完成する手順（プロセス）として、２つのプロセスを挙げる。２つのプロセスは、経営資源調達型ビジネス創造プロセス（以下、「経営資源調達型」ともいう。）及びアイデア募集型ビジネス創造プロセス（以下、「アイデア募集型」ともいう。）である。経営資源調達型はビジネスモデルのアイデアはあるが、完成させるための部品が不足している企業が採用するプロセスである。アイデア募集型は、ビジネスモデルを構成するであろう部品を一部保有しているが、ビジネスモデルのアイデアを見出だせていない企業が採用するプロセスである。

図１９は経営資源調達型のプロセス例を示すシーケンス図である。図１９において、探索企業、提案企業及び運営組織の列は、それぞれが行う作業を示している。ビジネスモデル開発システム１００の列は、ビジネスモデル開発システム１００において行われる処理を示す。

探索企業は自らの企業情報を登録する（ステップＳ１）。企業がビジネスモデル開発システム１００のユーザとなるには、自らの企業情報を登録することが必須となっている。企業情報を登録すると、運営者からビジネスモデル開発システム１００にアクセスするためのＩＤとパスワードが付与される。

図２０及び図２１は企業情報登録画面の例を示す説明図である。図２０は基本情報入力画面ｄ０１の一例を示す説明図である。図２１は事業情報入力画面ｄ０２の一例を示す説明図である。企業情報登録画面は、基本情報入力画面ｄ０１及び事業情報入力画面ｄ０２を含む。

基本情報入力画面ｄ０１は入力欄ｄ０１１、詳細ボタンｄ０１２、登録ボタンｄ０１３、クリアボタンｄ０１４及びキャンセルボタンｄ０１５を含む。入力欄ｄ０１１は会社名、法人番号、ホームページのＵＲＬ、本社住所など、会社の基本情報を文字入力する欄である。詳細ボタンｄ０１２は事業情報入力画面を呼び出すためのボタンである。登録ボタンｄ０１３は内容を確定し、企業ＤＢ１５１に登録するためのボタンである。クリアボタンｄ０１４は入力欄ｄ０１１全てをクリアするためのボタンである。キャンセルボタンｄ０１５は基本情報の登録をキャンセルするためのボタンである。

事業情報入力画面ｄ０２は入力欄ｄ０２１、ライブラリ表示ボタンｄ０２２、登録ボタンｄ０２３、クリアボタンｄ０２４及びキャンセルボタンｄ０２５を含む。入力欄ｄ０２１は顧客へ提供する価値、主力商品・サービスなど、事業に関する情報を文字入力する欄である。ライブラリ表示ボタンｄ０２２はビジネスモデル価値提供プロセスライブラリを呼び出すためのボタンである。登録ボタンｄ０２３は内容を確定し、事業ＤＢ１５２等に登録するためのボタンである。クリアボタンｄ０２４は入力欄ｄ０２１全てをクリアするためのボタンである。キャンセルボタンｄ０２５は事業情報の登録をキャンセルするためのボタンである。なお、入力欄ｄ０２１において、被検索キーワードは必須入力である。被検索キーワードを入力されていなければ、他社による検索にヒットすることが困難になるからである。被検索キーワードは、他社が自社の強みを検索すると想定した場合に、入力されるであろうキーワードを入力する。例えば、要求仕様を表す用語である。

ユーザがライブラリ表示ボタンｄ０２２を操作すると、ビジネスモデル価値提供プロセスライブラリ画面（図示しない）が表示される。当該画面において、自社の事業（ビジネスモデル）が当てはまりそうなパターンをユーザは選択する。ユーザが選択すると、階層構造化された既存ビジネスモデルが自動生成される。ユーザが自動生成された既存ビジネスモデルを加筆修正により自社のビジネスモデルについての階層構造化された表現（階層構造化データ）を完成させることが可能である。

例えば、図２１に示す株式会社ＢＭＦの「生産管理システム開発」事業については、価値提供プロセスライブラリから「システム導入」のパターンを選択する。すると、ビジネスモデルの要素として、（１）引合・提案・受注、（２）業務設計、（３）システム設計・開発、（４）初期データ入力、（５）システム運用が表示される。（２）（３）をそれぞれ「生産管理業務設計・要件定義」「生産管理システム設計・開発」に修正し、提供可能な経営資源要素をこれらと関連付けることにより、ビジネスモデルについての階層構造化された表現が完成する。

探索企業が事業情報入力画面ｄ０２を用いて、事業（ビジネスモデル）の情報を登録することは、ビジネスモデル開発システム１００においては、探索企業が提供可能な経営資源要素の登録となる（ステップＳ２１）。すなわち、ビジネスモデル開発システム１００において新たな部品が調達可能となったことを示す。更に、探索企業がビジネスモデル価値提供プロセスライブラリ画面を用いて作成した階層構造化データを登録したことは、ビジネスモデル開発システム１００においては、探索企業が既に実行しているビジネスモデルのレシピの登録となる（ステップＳ２２）。それに伴いレシピを構成する部品の中で新規なものが品目登録される（ステップＳ２３）。すなわち、新たな部品が品目ＤＢ１５３に登録される。

事業情報入力画面ｄ０２は入力欄ｄ０２１において、提供可能な経営資源要素を適切に記入してもらうことが、重要である。図２１に示す例において、提供可能な経営資源要素（内容欄）のうち、何らかの記入が望ましい。記入されない場合は「経営資源１」、「経営資源２」などの定型の文字列をビジネスモデル開発システム１００が自動記入してもよい。又は、当該企業を担当する銀行員が、ヒアリングして記入してもよい。分類１欄及び分類２欄は、バリューチェーンの主活動及び支援活動を選択肢として表示し、その中で提供可能な活動をチェックボックスやプルダウンメニューで選択させてもよい。被検索キーワードは必須項目であるが、企業担当者が後日、代理入力するという付帯条件つきで、空欄としてもよい。なお、経営資源要素を、ビジネスモデル開発システム１００がクローリングにより収集してもよい。クローリングにより収集した情報の中から、テンプレートマッチングで抽出する。又は、ディープラーニングなどのＡＩ技術により抽出する。

探索企業は探索ニーズを登録する（ステップＳ２）。ここで、探索ニーズとは探索企業が構想した（又は設計した）新たなビジネスモデルの中で、調達の見込みが立っていない要素（部品）についての情報を登録することである。図２２は探索ニーズ登録画面の例を示す説明図である。探索ニーズ登録画面ｄ０３は探索企業欄ｄ０３１、探索目的欄ｄ０３２、探索技術欄ｄ０３３、詳細ボタンｄ０３４、ビジネスモデル設計図登録ボタンｄ０３５、確認ボタンｄ０３６、クリアボタンｄ０３７、及びキャンセルボタンｄ０３８を含む。探索企業欄ｄ０３１は探索企業の名称が表示される。探索目的欄ｄ０３２は探索を行う目的を記入する。探索の目的は新たなビジネスモデルの概要を端的に表す内容とすることが望ましい。探索の目的は必須入力である。探索目的欄に探索の目的が入力できないということは、新たなビジネスモデルの内容が固まっていない可能性が高いため、探索ニーズの登録はすべきではないからである。探索技術欄ｄ０３３は探索対象とする技術を記入する。探索技術欄ｄ０３３は３つであるが、それに限らない。２つ以下でもよいし、４つ以上でもよい。また、ユーザが探索技術欄ｄ０３３の数を設定させてもよい。詳細ボタンｄ０３４は技術内容画面を開くためのボタンである。ビジネスモデル設計図登録ボタンｄ０３５は、レシピ登録画面を開くためのボタンである。確認ボタンｄ０３６は登録内容を確認するための確認画面に遷移するためのボタンである。クリアボタンｄ０３７は記入内容をクリアするためのボタンである。キャンセルボタンｄ０３８は入力を中止するためのボタンである。

図２３は技術内容画面の例を示す説明図である。技術内容画面ｄ０４は探索対象技術の内容を記入するための画面である。技術内容画面ｄ０４は探索Ｎｏ欄ｄ０４１、探索技術欄ｄ０４２、従来技術欄ｄ０４３、問題状況欄ｄ０４４、スペック欄ｄ０４５、除外技術欄ｄ０４６、キーワード欄ｄ０４７、確認ボタンｄ０４８、クリアボタンｄ０４９及びキャンセルボタンｄ０４Ａを含む。探索Ｎｏ欄ｄ０４１は探索ニーズを特定するための探索番号が表示される。探索番号は自動的に発番される番号である。探索番号をユーザは入力することはできない。探索技術欄ｄ０４２は探索ニーズ登録画面ｄ０３の探索技術欄ｄ０３３に記入された探索対象とする技術のうちの１つが表示される。従来技術欄ｄ０４３は探索対象とする技術に関係する従来技術の内容を記入する。問題状況欄ｄ０４４は従来技術の問題状況を記入する。スペック欄ｄ０４５は探索対象とする技術に要求するスペックを記入する。スペックは探索条件ともいえる。除外技術欄ｄ０４６は探索するに当たり除外する技術を記入する。除外技術欄ｄ０４６には探索条件の内容では適合しそうだが、問題を解決できないことを、探索企業が既知の場合などに記入する。キーワード欄ｄ０４７は探索対象とする技術を検索するためのキーワードを入力する。他社が検索すると想定した場合に、入力されるであろうキーワードを想定して入力することが望ましい。確認ボタンｄ０４８は登録内容を確認するための確認画面に遷移するためのボタンである。クリアボタンｄ０４９は記入内容をクリアするためのボタンである。キャンセルボタンｄ０４Ａは入力を中止するためのボタンである。

図２４は探索ニーズ確認画面の例を示す説明図である。探索ニーズ確認画面ｄ０５は探索ニーズ登録画面ｄ０３及び技術内容画面ｄ０４で入力した内容確認するための画面である。また、探索ニーズ確認画面ｄ０５は開示設定を行うための画面である。探索ニーズ確認画面ｄ０５は内容表示欄ｄ０５１、開示設定欄ｄ０５２、登録ボタンｄ０５３、戻るボタンｄ０５４及びキャンセルボタンｄ０５５を含む。内容表示欄ｄ０５１は探索ニーズ登録画面ｄ０３及び技術内容画面ｄ０４で入力した内容表示を表示する。開示設定欄ｄ０５２は各項目の開示設定を行うための欄である。開示に設定された項目は全てのユーザに開示される。しかし、開示に設定されているが、限定にバツ印が入っている場合は、限定したユーザのみに開示される。例えば、後述するロングリストに掲載された企業のみ開示される。非開示は他のユーザには開示されない。しかし、非開示であっても、運営組織のユーザには開示される。登録ボタンｄ０５３は探索ニーズを登録するためのボタンである。戻るボタンｄ０５４は、前画面に戻るためのボタンである。キャンセルボタンｄ０５５は登録を中止するためのボタンである。

図２５はレシピ登録画面の例を示す説明図である。レシピ登録画面ｄ０６は第１階層登録領域ｄ０６１、第２、３階層登録領域ｄ０６２、ｄ０６３、モデルチャートボタンｄ０６４、領域増減ボタンｄ０６５、ｄ０６６、確認ボタンｄ０６７及びキャンセルボタンｄ０６８を含む。第１階層登録領域ｄ０６１はビジネスモデルの内容を登録するための領域である。第２、３階層登録領域ｄ０６２、ｄ０６３はビジネスモデルを構成するスキーム、経営資源要素を登録するための領域である。モデルチャートボタンｄ０６４はモデルチャート登録画面を開くためのボタンである。領域増減ボタンｄ０６５、ｄ０６６はそれぞれ第２、３階層登録領域の追加・削除するためのボタンである。領域増減ボタンｄ０６５の＋ボタンを操作すると、第２、３階層登録領域ｄ０６２の下に新たな第２、３階層登録領域が追加される。領域増減ボタンｄ０６５の−ボタンを操作すると、第２、３階層登録領域ｄ０６２が削除される。確認ボタンｄ０６７は登録内容を確認するための図示しない確認画面に遷移するためのボタンである。確認画面では、探索ニーズ確認画面ｄ０５と同様に、登録内容を確認すると共に、各項目に対する開示設定をする。キャンセルボタンｄ０６８は入力を中止するためのボタンである。

なお、領域増減ボタンｄ０６５、ｄ０６６の＋ボタンを操作すると新規追加、引用追加を含む選択メニューを表示してもよい。新規追加が選択された場合は第２、３階層登録領域を追加する。引用追加が選択された場合は既に登録してある部品を取り込むことが可能である。既に部品登録がなされている場合には、重複登録とならないように引用追加を用いるようにする。重複登録を防ぐために、新規追加の場合、既登録の部品との類似判定を行い、類似度の高い部品が既登録の場合は、警告を発するようにしてもよい。

図２６は第１階層登録領域の例を示す説明図である。第１階層登録領域ｄ０６１は品目Ｎｏ．欄ｄ０６１１、名称欄ｄ０６１２、品目区分プルダウンｄ０６１３、概要欄ｄ０６１４、提供価値欄ｄ０６１５、スキーム欄ｄ０６１６、収益欄ｄ０６１７及び記入者欄ｄ０６１８を含む。品目Ｎｏ．欄ｄ０６１１は品目を特定するための品目番号が表示される。品目番号は自動的に発番される番号である。品目番号をユーザは入力することはできない。名称欄ｄ０６１２は品目の名称を記入するための欄である。品目区分プルダウンｄ０６１３は品目区分を設定するためのプルダウンメニューである。しかし、経営資源調達型の場合は、第１階層は必須で、１つである。そのため、品目区分プルダウンｄ０６１３は変更不可となっている。概要欄ｄ０６１４は事業コンセプト（ビジネスモデル）の概要を記入するための欄である。提供価値欄ｄ０６１５は顧客へ提供する価値を入力するための欄である。スキーム欄ｄ０６１６は価値を提供するためのスキームを記入するための欄である。収益欄ｄ０６１７は事業が収益を生むための仕組み（収益モデル）を入力するための欄である。記入者欄ｄ０６１８は登録を行う企業名が記入される。記入者欄ｄ０６１８はログインユーザを判断し、自動的に記入される。運営組織が代理で入力する場合は、別途表示される設定画面で企業を指定する。なお、複数のビジネスモデルを組み合わせた複合ビジネスモデルを定義する場合は、まず各ビジネスモデルを定義する。更に、複合ビジネスモデルの定義する際に、第１階層を登録すると共に、後述するモデルチャート登録画面を用いて、定義済の各ビジネスモデルを第２階層又は第３階層とすればよい。

図２７は第２階層登録領域の例を示す説明図である。第２階層登録領域ｄ０６２は品目Ｎｏ．欄ｄ０６２１、名称欄ｄ０６２２、品目区分プルダウンｄ０６２３、機能・プロセス区分プルダウンｄ０６２４、定義欄ｄ０６２５、コア欄ｄ０６２６及び記入者欄ｄ０６２７を含む。品目Ｎｏ．欄ｄ０６２１は品目を特定するための品目番号が表示される。品目番号は自動的に発番される番号である。品目番号をユーザは入力することはできない。名称欄ｄ０６２２は品目の名称を記入するための欄である。品目区分プルダウンｄ０６２３は品目区分を設定するためのプルダウンメニューである。登録する品目が提供価値スキーム（第２階層）であるか、又は経営資源要素（第３階層）であるかを設定する。品目区分プルダウンｄ０６２３の選択内容によって、品目区分プルダウンｄ０６２３の下に表示される欄の内容が変化する。機能・プロセス区分プルダウンｄ０６２４は機能・プロセス区分を設定するためのプルダウンメニューである。品目を示す機能・プロセスをプルダウンメニューから選択する。定義欄ｄ０６２５は機能又はプロセスの内容を記入するための欄である。コア欄ｄ０６２６はコアとなる経営資源要素を記入するための欄である。記入者欄ｄ０６２７は登録を行う企業名が記入される。記入者欄ｄ０６２７はログインユーザを判断し、自動的に記入される。運営組織が代理で入力する場合は、別途表示される設定画面で企業を指定する。

機能・プロセス区分プルダウンｄ０６２４で選択可能な区分は、品目ＤＢ１５３を説明した際に例示した１３区分である。図２７では定義欄ｄ０６２５には「プロセス定義」とあるが、機能・プロセス区分プルダウンｄ０６２４の選択内容によって、「機能定義」などに切り替わるようにしてもよい。

図２８は第３階層登録領域の例を示す説明図である。第３階層登録領域ｄ０６３は品目Ｎｏ．欄ｄ０６３１、名称欄ｄ０６３２、品目区分プルダウンｄ０６３３、品目分類プルダウンｄ０６３４、用途欄ｄ０６３５、課題欄ｄ０６３６、スペック・特長欄ｄ０６３７、検索キーワード欄ｄ０６３８及び記入者欄ｄ０６３９を含む。品目Ｎｏ．欄ｄ０６３１は品目を特定するための品目番号が表示される。品目番号は自動的に発番される番号である。品目番号をユーザは入力することはできない。名称欄ｄ０６３２は品目の名称を記入するための欄である。品目区分プルダウンｄ０６３３は品目区分を設定するためのプルダウンメニューである。登録する品目が提供価値スキーム（第２階層）であるか、又は経営資源要素（第３階層）であるかを設定する。品目区分プルダウンｄ０６３３の選択内容によって、品目区分プルダウンｄ０６３３の下に表示される欄の内容が変化する。品目分類プルダウンｄ０６３４は品目の分類を設定するためのプルダウンメニューである。用途欄ｄ０６３５は品目の用途、現在の活用領域を記入するための欄である。課題欄ｄ０６３６は品目により、解決できる課題を記入するための欄である。スペック・特長欄ｄ０６３７は品目のスペックや特長を記入するための欄である。検索キーワード欄ｄ０６３８は当該品目を検索するためのキーワードを入力する。他社が検索すると想定した場合に、入力されるであろうキーワードを想定して入力することが望ましい。記入者欄ｄ０６３９は登録を行う企業名が記入される。記入者欄ｄ０６３９はログインユーザを判断し、自動的に記入される。運営組織が代理で入力する場合は、別途表示される設定画面で企業を指定する。

図２９はモデルチャート登録画面の例を示す説明図である。モデルチャート登録画面ｄ０７は価値列ｄ０７１、スキーム列ｄ０７２、経営資源列ｄ０７３、保存ボタンｄ０７４、及びキャンセルボタンｄ０７５を含む。モデルチャート登録画面ｄ０７には、レシピ登録画面ｄ０６で入力した第１階層、第２階層及び第３階層の品目（部品）が表示される。価値列ｄ０７１にはビジネスモデルを示す第１階層の部品が表示される。スキーム列ｄ０７２には価値スキームを示す第２階層の部品が表示される。経営資源列ｄ０７３には経営資源要素を示す第３階層の部品が表示される。モデルチャート登録画面ｄ０７において、それぞれの部品をマウス等でクリックするとその内容（図２６、図２７で設定した内容）が表示される。それぞれの部品同士を、マウス等を用いて線でつなぐと、部品同士を階層構造として関連付けることが可能である。図２９に示す例では、探索しようとしている技術（探索１０００１１、１０００１２）以外の部品は全て株式会社ＢＭＦが保有している。保存ボタンｄ０７４は作成・編集したモデルチャートを記憶するためのボタンである。モデルチャートを記憶し、モデルチャート登録画面ｄ０７は閉じられ、前の画面に戻る。キャンセルボタンｄ０７５は、モデルチャートを作成・編集した内容を破棄し、前画面に戻るためのボタンである。

図１９に戻る。ここまでで、探索企業は探索ニーズの登録が完了する。登録後、探索企業は探索ニーズの選定基準を設定する（ステップＳ３）。選定基準の設定は、ビジネスモデル開発システム１００においては、要求仕様の登録となる（ステップＳ２４）。これについては後述する。図２６から図２８で示した入力フォームにより入力されたデータは、案件別にトランザクションデータとして記憶されると共に、マスタデータとして品目ＤＢ１５３にも登録されることになる。既にマスタデータとして登録済みの第２、３階層の部品を活用する場合には、品目ＤＢ１５３から情報を取得し、追記（入力）する。

この段階で、ビジネスモデル開発システム１００は、探索ニーズ及び要求仕様に基づきロングリストの作成を行う（ステップＳ２５）。作成されたロングリストに基づき、運営組織は受注候補企業の選定を行う（ステップＳ４）。運営組織は候補企業に対して、応募の勧誘を行う。それに応じた企業であって、ビジネスモデル開発システム１００の既存ユーザでない企業は自らの企業情報を登録する（ステップＳ５）。企業情報の登録は、探索企業の場合と同じであるので、省略する。

企業情報を登録した提案企業は、探索企業の募集に対して、応募・提案を行う（ステップＳ６）。図３０は応募登録画面の例を示す説明図である。応募登録画面ｄ０８は探索Ｎｏ．欄ｄ０８１、対象技術欄ｄ０８２、応募Ｎｏ．欄ｄ０８３、品目区分プルダウンｄ０８４、品目分類プルダウンｄ０８５、用途欄ｄ０８６、課題欄ｄ０８７、スペック・特長欄ｄ０８８、添付ファイル欄ｄ０８９、検索キーワード欄ｄ０８Ａ、記入者欄ｄ０８Ｂ、確認ボタンｄ０８Ｃ、クリアボタンｄ０８Ｄ、キャンセルボタンｄ０８Ｅを含む。探索Ｎｏ．欄ｄ０８１は探索ニーズを特定するための探索番号が表示される。探索番号は探索企業が探索ニーズ登録画面ｄ０３を用いて探索ニーズを登録したとき自動的に発番される番号である。提案企業が選択した探索ニーズに対応した探索番号が探索Ｎｏ．欄ｄ０８１に表示される。対象技術欄ｄ０８２は探索対象技術の名称が表示される。応募Ｎｏ．欄ｄ０８３は応募を特定するための応募番号が表示される。応募番号は自動的に発番される番号である。応募番号をユーザは入力することはできない。品目区分プルダウンｄ０８４は品目区分を設定するためのプルダウンメニューである。応募する品目が提供価値スキーム（第２階層）であるか、又は経営資源要素（第３階層）であるかを設定する。品目区分プルダウンｄ０８４の選択内容によって、品目区分プルダウンｄ０８４の下に表示される欄の内容が変化する。品目分類プルダウンｄ０８５は品目の分類を設定するためのプルダウンメニューである。用途欄ｄ０８６は品目の用途、現在の活用領域を記入するための欄である。課題欄ｄ０８７は品目により、解決できる課題を記入するための欄である。スペック・特長欄ｄ０８８は品目のスペックや特長を記入するための欄である。添付ファイル欄ｄ０８９は資料を添付する場合に資料ファイルを貼り付けるための欄である。例えば、添付するファイルを添付ファイル欄ｄ０８９にドラッグ＆ドロップすることにより、添付する資料ファイルを設定する。検索キーワード欄ｄ０８Ａは応募する品目（部品）に対する検索キーワードを記入するための欄である。検索キーワード欄ｄ０８Ａに適切なキーワードを設定しておくことにより、応募で採用されなかったとしても、その後の募集において、候補企業の選定のための検索において抽出される可能性がある。記入者欄ｄ０８Ｂは記入者である企業名称等が表示される。記入者欄ｄ０８Ｂはログインユーザを判断し、自動的に記入される。運営組織が代理で入力する場合は、別途表示される設定画面で企業を指定する。確認ボタンｄ０８Ｃは登録内容を確認するための図示しない確認画面に遷移するためのボタンである。確認画面では、探索ニーズ確認画面ｄ０５と同様に、登録内容を確認すると共に、各項目に対する開示設定をする。クリアボタンｄ０８Ｄは記入内容をクリアするためのボタンである。キャンセルボタンｄ０８Ｅは入力を中止するためのボタンである。

提案企業が応募することにより、ビジネスモデル開発システム１００においては、同時に提案企業が有する強みが新たに登録されることになる（ステップＳ２６）。すなわち、図３０で入力されたデータは、案件別にトランザクションデータとして記憶されると共に、マスタデータとして品目ＤＢ１５３にも登録されることになる。

探索企業は提案企業からの提案内容を精査したり、質疑をしたりする。提案企業は探索企業に対して補足説明をしたり、質疑に対する応答をしたりする。これらのやり取りは、ビジネスモデル開発システム１００を用いなくともよい。提案内容精査及び質疑応答の内容は、提案内容評価を通して、品目＝「強み」の追加情報としてビジネスモデル開発システム１００に記録される。

探索企業は提案企業を絞り込むため、提案内容の評価（第１次選定）を行う（ステップＳ７）。図３１は評価画面ｄ０９の内容を示す説明図である。図３１Ａは評価基準画面に表示される評価基準表の例を示す説明図である。評価項目は課題解決力の評価項目と、協業適格性の評価項目とが設定される。評価基準は企業や事例によって、ばらつきがでないように変更しないことが望ましい。課題解決力評価は探索企業が実施（入力）し、評価ＤＢ１５９に取り込まれる。１次選定において、探索企業が提案内容精査及び質疑応答の内容を入力してもよい。協業適格性の評価は銀行が行内サーバ２に記憶されている与信情報などを用いて実施する。評価結果（協業適格性評価情報）はメインサーバ１の評価ＤＢ１５９に記憶する。

図３１Ｂは評価一覧画面に表示される評価一覧表の例を示す説明図である。協業適格性評価は銀行が行うため、評価一覧画面ｄ１０の評価一覧表には課題解決力評価のみが提示される。探索企業は各提案企業について、評価基準に従って評価を入力する。入力した評価（課題解決力評価情報）はビジネスモデル開発システム１００に送信され、評価ＤＢ１５９に記憶される。銀行が行った協業適格性評価を探索企業に開示するかどうかは、案件毎に銀行が判断する。

ビジネスモデル開発システム１００においては、探索企業による各提案企業の提案の評価が、各提案企業の強みの評価に反映される（ステップＳ２７）。ビジネスモデル開発システム１００は探索企業の評価結果に基づいて、ショートリストを作成する（ステップＳ２８）。作成されたショートリストに基づき、運営組織は面談候補企業の選定を行う（ステップＳ８）。ショートリストの作成又は面談候補先の選定に際しては、運営組織による協業適格性評価が考慮される。

探索企業は運営組織が提示した面談候補先からプレゼンテーションを行ってもらう企業を選択する。選択された提案企業はプレゼンテーションを行う。プレゼンテーションに基づき、探索企業は提案企業の評価を行う（第２次選定）（ステップＳ９）。評価項目は第１次選定と同じでもよいし、異ならせてもよい。第２次選定は第１次選定の見直しと捉えるのであれば、第２次選定の評価項目は第１次選定と同じでよい。第２次選定は第１次選定では評価できない内容を評価するのであれば、第２次選定の評価項目は第１次選定と異なることになる。探索企業はプレゼンテーションを行った各提案企業について、評価基準に従って評価を入力する。入力した評価はビジネスモデル開発システム１００に送信される。ビジネスモデル開発システム１００においては、プレゼンテーションを行った各提案企業の評価が、各提案企業の強みの評価に反映される（ステップＳ２９）。

探索企業は最終的に採用する提案企業を選択し、契約を結ぶ（成約）（ステップＳ１０）。その結果、ビジネスモデルが完成する。その際、成約番号が発番され、限定グループＤＢ１５Ｂの成約Ｎｏ．列（採用情報）に記憶される。それに伴い、ビジネスモデル開発システム１００はレシピを更新する。未完成だったレシピは完成されたビジネスモデルのレシピとして登録される（ステップＳ３０）。ここでの完成とは部品の調達先決定までの完了をいう。図３２はモデルチャート表示画面の例を示す説明図である。選定結果入力がされると、自動的に図３２に示すモデルチャートが生成又は更新される。モデルチャート表示画面ｄ１１は価値列ｄ１１１、スキーム列ｄ１１２、経営資源列ｄ１１３、戻るボタンｄ１１４及び編集ボタンｄ１１５を含む。価値列ｄ１１１、スキーム列ｄ１１２及び経営資源列ｄ１１３はモデルチャート登録画面ｄ０７と同様であるから、説明を省略する。図３２に示す例では、探索していた技術（図２９の探索１０００１１、１０００１２）の募集に対して、固有の品目（ｉ１１００２１、ｉ１１００３２）が選定されたことを示している。戻るボタンｄ１１４はモデルチャート表示画面ｄ１１を閉じて、前の画面に戻るためのボタンである。編集ボタンｄ１１５はビジネスモデルチャートを変更可能な編集モードに変更するためのボタンである。

ビジネスモデル開発システム１００はビジネスモデルの完成に伴い、応募で採用された品目（強み）の評価を行い、更新する（ステップＳ３１）。探索企業と成約した提案企業は協業を行い、ビジネスモデル開発を行い、それ基づく事業を行う（ステップＳ１１）。運営組織は事業の業績をトレースする（ステップＳ１２）。ビジネスモデル開発システム１００は業績に基づきビジネスモデルの評価を行うと共に、ビジネスモデルを構成する部品（強み）の評価を行う（ステップＳ３２）。そして、強みの評価に反映される（ステップＳ３３）。

以上のように、ビジネスモデル開発システム１００は探索企業と提案企業とを結びつけるプロセスを支援する。そして、支援を通じて、各企業の強み（経営資源要素）情報及び強みの評価情報を蓄積する。

図１９のステップＳ２５でロングリストに選定されなかった提案企業、ロングリストには選定されていたがステップＳ２８でショートリストに選定されなかった提案企業、ショートリストには選定されていたがステップＳ３０でビジネスモデルに登録されなかった提案企業には、その旨を通知してもよい。通知をうけた提案企業は、どのような評価基準で選定されなかったのかを把握したり、自社の弱みを把握したりすることができる。また、それぞれのステップで選定を通過するチャンスを増加させるため、提案企業は開示していなかった情報を追加更新することが期待される。その結果、ビジネスモデル開発システム１００において、各企業の情報開示が促される。

図３３はアイデア募集型のプロセス例を示すシーケンス図である。図３３の記載形式は図１９と同様である。探索企業は自らの企業情報を登録する（ステップＳ４１）。登録する趣旨等は、図１９のステップＳ１と同様なので、詳細な説明は省略する。探索企業の企業情報の登録により、ビジネスモデル開発システム１００は提供可能な経営資源要素の登録をする（ステップＳ６１）

次に、探索企業は募集テーマを登録する（ステップＳ４２）。募集とは探索企業が、自社の強みである経営資源要素の活用を図れるビジネスモデルの提案を求めることである。図３４は募集テーマ登録画面の例を示す説明図である。募集テーマ登録画面ｄ１２は募集企業欄ｄ１２１、募集Ｎｏ．欄ｄ１２２、募集テーマ欄ｄ１２３、前提条件欄ｄ１２４、評価基準欄ｄ１２５、経営資源欄ｄ１２６、確認ボタンｄ１２７、クリアボタンｄ１２８及びキャンセルボタンｄ１２９を含む。募集企業欄ｄ１２１は募集を行う探索企業の名称がユーザに応じて表示される。募集Ｎｏ．欄ｄ１２２は募集テーマを特定するための募集番号が表示される。募集番号は自動的に発番される番号である。募集番号をユーザは入力することはできない。募集テーマ欄ｄ１２３は募集を行うテーマを記入するための欄である。テーマは少なくとも技術分野が分かるものであることが望ましい。前提条件欄ｄ１２４は募集テーマの前提条件を入力するための欄である。前提条件は募集テーマに関するアイデアを考える上で、前提とする内容である。評価基準欄ｄ１２５はアイデアを評価する基準を入力するための欄である。応募されたアイデアを探索企業がどのような基準で評価しようと考えているのか、それを端的に表現し記入する。経営資源欄ｄ１２６は提供可能な経営資源を入力するための欄である。提供可能な経営資源とは、探索企業がアイデアを実現の際には、提供したいと考えている経営資源である。確認ボタンｄ１２７は登録内容を確認するための図示しない確認画面に遷移するためのボタンである。確認画面では、探索ニーズ確認画面ｄ０５と同様に、登録内容を確認すると共に、各項目に対する開示設定をする。クリアボタンｄ１２８は記入内容をクリアするためのボタンである。キャンセルボタンｄ１２９は入力を中止するためのボタンである。図３４において、前提条件欄ｄ１２４は３つ、評価基準欄ｄ１２５は７つ、経営資源欄ｄ１２６は３行となっているが、それに限らない。それぞれの数が前後してもよいし、ユーザにそれぞれの数を設定させてもよい。

ここまでで、探索企業は募集テーマの登録が完了する。これにより、ビジネスモデル開発システム１００には新たな品目が登録される（ステップＳ６３）。登録後、探索企業は募集テーマの選定基準を設定する（ステップＳ４３）。アイデア評価基準をもとに、上述の図３１に示した評価基準表と同様なものを作成する。詳細は後述する。

運営組織は募集テーマ及び選定基準を確認した上で、必要な項目を募集要項としてまとめ、提案企業に対する通知及び開示を行う（ステップＳ４４）。募集に応募しようとしている企業であって、ビジネスモデル開発システム１００の既存ユーザでない企業は自らの企業情報を登録する（ステップＳ４５）。企業情報の登録は、探索企業の場合と同じであるので、省略する。

企業情報を登録した提案企業は、探索企業の募集に対して、ビジネスモデル（アイデア）の応募を行う（ステップＳ４６）。図３５はアイデア登録画面の例を示す説明図である。アイデア登録画面ｄ１３は募集企業欄ｄ１３１、募集Ｎｏ．欄ｄ１３２、募集テーマ欄ｄ１３３、応募企業欄ｄ１３４、応募Ｎｏ．欄ｄ１３５、ビジネスモデル名欄ｄ１３６、コンセプト概要欄ｄ１３７、提供価値欄ｄ１３８、提供スキーム欄ｄ１３９、添付ファイル欄ｄ１３Ａ、ビジネスモデル設計図登録ボタンｄ１３Ｂ、確認ボタンｄ１３Ｃ、クリアボタンｄ１３Ｄ及びキャンセルボタンｄ１３Ｅを含む。募集企業欄ｄ１３１には募集企業の名称が表示される。募集Ｎｏ．欄ｄ１３２には募集テーマを特定するための募集番号が表示される。募集番号は探索企業が募集テーマ登録画面ｄ１２を用いて募集テーマを登録したとき、自動的に発番される番号である。提案企業が選択した募集テーマに対応した募集番号が募集Ｎｏ．欄ｄ１３２に表示される。募集テーマ欄ｄ１３３には募集テーマが表示される。応募企業欄ｄ１３４には募集テーマに対して応募する企業の名称が表示される。応募Ｎｏ．欄ｄ１３５には応募を特定するための応募番号が表示される。応募番号は自動的に発番される番号である。応募番号をユーザは入力することはできない。ビジネスモデル名欄ｄ１３６は応募するアイデア（ビジネスモデル）の名称を記入するための欄である。名称はアイデアを具現化した事業の内容を端的に表すものが望ましい。コンセプト概要欄ｄ１３７は事業コンセプトの概要を入力するための欄である。想定する顧客、提供する商品・サービスの概要を記入する。提供価値欄ｄ１３８は事業が顧客に提供する価値の内容を記入する。提供スキーム欄ｄ１３９は顧客へ価値をどのような仕組みで提供するかを記入する。添付ファイル欄ｄ１３Ａは資料としてファイルを添付する場合にファイル名を設定する。ビジネスモデル設計図登録ボタンｄ１３Ｂは、レシピ登録画面を開くためのボタンである。確認ボタンｄ１３Ｃは登録内容を確認するための図示しない確認画面に遷移するためのボタンである。確認画面では、探索ニーズ確認画面ｄ０５と同様に、登録内容を確認すると共に、各項目に対する開示設定をする。クリアボタンｄ１３Ｄは記入内容をクリアするためのボタンである。キャンセルボタンｄ１３Ｅは入力を中止するためのボタンである。

アイデア登録画面ｄ１３において、提案企業は、ビジネスモデル設計図登録ボタンｄ１３Ｂを操作し、レシピ登録画面を開く。開いたレシピ登録画面で、ビジネスモデル設計図を登録する。レシピ登録画面は上述の図２５から図２８で示したものと同様であるから、図示及び説明を省略する。レシピ登録画面より、更に開くモデルチャート登録画面について、説明する。

図３６はモデルチャート登録画面の例を示す説明図である。モデルチャート登録画面ｄ１４は価値列ｄ１４１、スキーム列ｄ１４２、経営資源列ｄ１４３、保存ボタンｄ１４４、及びキャンセルボタンｄ１４５を含む。モデルチャート登録画面ｄ１４において、価値列ｄ１４１にはレシピ登録画面で入力した第１階層の品目が、スキーム列ｄ１４２には第２階層の品目が、経営資源列ｄ１４３には第３階層の品目が表示される。モデルチャート登録画面ｄ１４において、それぞれの部品をマウス等でクリックするとその内容（レシピ登録画面での入力内容）が表示される。それぞれの部品同士を、マウス等を用いて線でつなぐと、部品同士を階層構造として関連付けることが可能である。保存ボタンｄ１４４は作成・編集したモデルチャートを記憶するためのボタンである。モデルチャートを記憶し、モデルチャート登録画面ｄ１４は閉じられ、前の画面に戻る。キャンセルボタンｄ１４５は、モデルチャートを作成・編集した内容を破棄し、前画面に戻るためのボタンである。

図３６は、ＤＥＦ株式会社が行っているアイデア募集に対して、ＧＨＩ株式会社が応募する場合において、作成したモデルチャートを表示している。そのため、ＤＥＦ株式会社及びＧＨＩ株式会社が保有する品目が明示されている。図３６に示す例では、ＧＨＩ株式会社が保有している品目はｉ１１００２１のブロックチェーンによるトレーサビリティであることを示している。また、ＤＥＦ株式会社が保有している品目はｉ１１００４０のＩｏＴプラットフォームであることを示している。そして、これは図３４に示した募集テーマ登録画面に記入されていたＤＥＦ株式会社が指定した提供可能な経営資源となっている。

提案企業が応募を行うことにより、ビジネスモデル開発システム１００は新たなレシピを登録する（ステップＳ６４）。ビジネスモデル開発システム１００は、品目別（主に経営資源要素別）に候補企業リストを作成し、レシピと共に運営組織宛に出力する（ステップＳ６５）。なお、レシピに、探索企業及び提案企業以外の企業の経営資源要素を含んでいる場合には、当該企業の情報も運営組織宛に送付する。新たなレシピ登録は、ビジネスモデル開発システム１００において、新たな品目の登録あるいは品目情報の追加となる（ステップＳ６６）。

探索企業は提案企業からの提案内容を精査したり、質疑をしたりする。提案企業は探索企業に対して補足説明をしたり、質疑に対する応答をしたりする。これらのやり取りは、ビジネスモデル開発システム１００を用いなくともよい。提案内容精査及び質疑応答の内容は、提案内容評価を通して、品目＝「強み」の追加情報としてビジネスモデル開発システム１００に記録される。

探索企業は提案企業を絞り込むため、提案内容の評価（第１次選定）を行う（ステップＳ４７）。図３７は評価画面の内容を示す説明図である。図３７Ａは評価基準画面に表示される評価基準表の例を示す説明図である。探索企業は、募集テーマ登録画面ｄ１２（図３４）のアイデア評価基準ｄ１２５を参照しつつ、評価項目にしたがい評価を行う。１次選定において、探索企業が提案内容精査及び質疑応答の内容を入力してもよい。協業適格性の評価は銀行が行内サーバ２に記憶されている与信情報などを用いて実施する。評価結果はメインサーバ１の評価ＤＢ１５９に記憶する。

図３７Ｂは評価一覧画面に表示される評価一覧表の例を示す説明図である。評価にあたって、運営組織は探索企業に対して、ステップＳ６５で出力されたビジネスモデルの仮説（提案企業のレシピと提供候補企業リスト）に基づいて、情報提供やアドバイスを行ってもよい（ステップＳ４８）。例えばビジネスモデルの各構成要素（部品）の提供候補企業リストにより、当該アイデアの実現可能性を具体例で判断可能となる。

ビジネスモデル開発システム１００においては、探索企業による各提案企業の提案したビジネスモデルの評価が登録される（ステップＳ６７）。そして、各ビジネスモデルの評価は、モデルに含まれる強み（経営資源要素、部品）の評価に反映される。

第１次選定で選択された提案企業はビジネスモデルの設計を詳細に行う（ステップＳ４９）。その結果、ビジネスモデル開発システム１００が記憶しているレシピが更新される（ステップＳ６８）。

提案企業が探索企業に対して、プレゼンテーションを行う。探索企業はプレゼンテーションの内容の評価を行う（第２次選定）（ステップＳ５０）。評価項目は第１次選定と同じでもよいし、異ならせてもよい。第２次選定は第１次選定の見直しと捉えるのであれば、第２次選定の評価項目は第１次選定と同じでよい。第２次選定は第１次選定では評価できない内容を評価するのであれば、第２次選定の評価項目は第１次選定と異なることになる。探索企業はプレゼンテーションを行った各提案企業について、評価基準に従って評価を入力する。入力した評価はビジネスモデル開発システム１００の評価ＤＢ１５９に送信される。ビジネスモデル開発システム１００においては、プレゼンテーションを行った各提案企業の評価が、ビジネスモデルの評価として記憶される（ステップＳ６９）。そして、各ビジネスモデルの評価は、モデルに含まれる強み（経営資源要素、部品）の評価に反映される。

探索企業は最終的に採用する提案企業を選択し、契約を結ぶ（成約）（ステップＳ５１）。成約した提案企業（以下、協業企業）が提案したビジネスモデルは、ビジネスモデル開発システム１００において、仕掛り登録される（ステップＳ７０）。その際、成約番号が発番され、限定グループＤＢ１５Ｂの成約Ｎｏ．列（採用情報）に記憶される。それに伴い、ビジネスモデル開発システム１００はビジネスモデルの評価を更新する（ステップＳ７１）。ビジネスモデルの評価は、モデルに含まれる強み（経営資源要素、部品）の評価に反映される。

探索企業と協業企業とで、ビジネスモデルの開発（事業化）を行う（ステップＳ５２）。開発終了後に、探索企業又は協業企業はビジネスモデルをビジネスモデル開発システム１００に登録する（ステップＳ７２）。それに伴い、ビジネスモデル開発システム１００はビジネスモデルの評価を更新する（ステップＳ７３）。ビジネスモデルの評価は、モデルに含まれる強み（経営資源要素、部品）の評価に反映される。

探索企業及び協業企業は新規事業をスタートアップする（ステップＳ５３）。運営組織はスタートアップした事業の業績をトレースする（ステップＳ５４）。運営組織は業績に基づくビジネスモデルの評価を行い、ビジネスモデル開発システム１００に登録する（ステップＳ７４）。ビジネスモデルの評価は、モデルに含まれる強み（経営資源要素、部品）の評価に反映される。

メインサーバ１等が行う情報処理について、説明する。まず、経営資源要素の収集について、説明する。経営資源要素の収集は、ビジネスモデル開発システム１００に新たな企業が登録される際に行われる（図１９のステップＳ２１、図３３のＳ６１など）。図３８は企業情報登録処理の手順例を示すフローチャートである。メインサーバ１のＣＰＵ１１は基本情報入力画面ｄ０１を出力する（ステップＳ１０１）。ＣＰＵ１１はユーザが事業詳細の入力を選択したか否かを判定する（ステップＳ１０２）。ＣＰＵ１１はユーザが事業詳細の入力を選択したと判定した場合（ステップＳ１０２でＹＥＳ）、事業情報入力画面ｄ０２を出力する（ステップＳ１０３）。ＣＰＵ１１はユーザがデータ登録を選択したか否かを判定する（ステップＳ１０４）。ＣＰＵ１１はユーザがデータ登録を選択していないと判定した場合（ステップＳ１０４でＮＯ）、ライブラリが選択されたか否かを判定する（ステップＳ１０５）。ＣＰＵ１１はライブラリが選択されていないと判定した場合（ステップＳ１０５でＮＯ）、処理をステップＳ１０１へ戻す。ＣＰＵ１１はライブラリが選択されたと判定した場合（ステップＳ１０５でＹＥＳ）、ビジネスモデル価値提供プロセスライブラリ画面を出力する（ステップＳ１０６）。ＣＰＵ１１はライブラリのいずれかのパターンが選択されたか否かを判定する（ステップＳ１０７）。ＣＰＵ１１はライブラリのいずれかのパターンも選択されていないと判定した場合（ステップＳ１０７でＮＯ）、処理をステップＳ１０３に戻す。ＣＰＵ１１はライブラリのいずれかのパターンが選択されたと判定した場合（ステップＳ１０７でＹＥＳ）、選択されたパターンを用いてビジネスモデルチャートを作成するための作成画面を出力する（ステップＳ１０８）。ＣＰＵ１１はビジネスモデルチャートの記憶が指示されたか否かを判定する（ステップＳ１０９）。ＣＰＵ１１はビジネスモデルチャートの記憶が指示されていないと判定した場合（ステップＳ１０９でＮＯ）、処理をステップＳ１０３に戻す。ＣＰＵ１１はビジネスモデルチャートの記憶が指示されていると判定した場合（ステップＳ１０９でＹＥＳ）、ビジネスモデルチャートを記憶する（ステップＳ１１０）。ＣＰＵ１１は、作成画面で設定された品目の接続関係を、品目管理ＤＢ１５４に記憶する。ＣＰＵ１１は処理をステップＳ１０３に戻す。ＣＰＵ１１はユーザがデータ登録を選択したと判定した場合（ステップＳ１０４でＹＥＳ）、ユーザが入力した事業情報をＲＡＭ１３などに設けた一時記憶領域に記憶する（ステップＳ１１１）。ＣＰＵ１１は処理をステップＳ１０１に戻す。ＣＰＵ１１はユーザが事業詳細の入力を選択していないと判定した場合（ステップＳ１０２でＮＯ）、基本情報を記憶する（ステップＳ１１２）。基本情報は企業ＤＢ１５１に記憶する。ＣＰＵ１１は事業情報がＲＡＭ１３などに設けた一時記憶領域に記憶されているか否かを判定する（ステップＳ１１３）。ＣＰＵ１１は事業情報が一時記憶領域に記憶されていると判定した場合（ステップＳ１１３でＹＥＳ）、一時記憶領域に記憶されている事業の詳細情報を記憶し（ステップＳ１１４）、企業情報登録処理を終了する。事業の詳細情報は事業ＤＢ１５２に記憶する。ＣＰＵ１１は事業情報が一時記憶領域に記憶されていないと判定した場合（ステップＳ１１３でＮＯ）、企業情報登録処理を終了する。

次に探索ニーズ登録処理（ステップＳ２）について、説明する。図３９は探索ニーズ登録処理の手順例を示すフローチャートである。ＣＰＵ１１は探索ニーズ登録画面ｄ０３を出力する（ステップＳ１２１）。ＣＰＵ１１は探索ニーズ登録画面ｄ０３において、設計図登録が指示されたか否かを判定する（ステップＳ１２２）。ＣＰＵ１１は設計図登録が指示されたと判定した場合（ステップＳ１２２でＹＥＳ）、レシピ登録画面ｄ０６を出力する（ステップＳ１２３）。ＣＰＵ１１はレシピ登録画面ｄ０６において、チャート作成が指示されたか否かを判定する（ステップＳ１２４）。ＣＰＵ１１はチャートが指示されたと判定した場合（ステップＳ１２４でＹＥＳ）、モデルチャート登録画面ｄ０７を出力する（ステップＳ１２５）。ＣＰＵ１１は確認が指示されたか否かを判定する（ステップＳ１２６）。ＣＰＵ１１は確認が指示されたと判定した場合（ステップＳ１２６でＹＥＳ）、探索ニーズ確認画面ｄ０５を出力する（ステップＳ１２７）。ＣＰＵ１１は登録が指示されたか否か判定する（ステップＳ１２８）。ＣＰＵ１１は登録が指示されたと判定した場合（ステップＳ１２８でＹＥＳ）、探索ニーズ登録を行う（ステップＳ１２９）。探索ニーズ登録画面ｄ０３で設定した内容が、探索ニーズＤＢ１５５に登録される。レシピ登録画面ｄ０６で設定した内容が、品目ＤＢ１５３に登録される。モデルチャート登録画面ｄ０７で設定した内容が、品目管理ＤＢ１５４に登録される。ＣＰＵ１１は探索ニーズ登録処理を終了する。ＣＰＵ１１は登録が指示されていないと判定した場合（ステップＳ１２８でＮＯ）、戻るが指示されたか否かを判定する（ステップＳ１３０）。ＣＰＵ１１は戻るが指示されたと判定した場合（ステップＳ１３０でＹＥＳ）、処理をステップＳ１２１に戻す。ＣＰＵ１１は戻るが指示されていないと判定した場合（ステップＳ１３０でＮＯ）、探索ニーズ登録処理を終了する。ＣＰＵ１１は確認が指示されていないと判定した場合（ステップＳ１２６でＮＯ）、戻るが指示されたか否かを判定する（ステップＳ１３１）。ＣＰＵ１１は戻るが指示されたと判定した場合（ステップＳ１３１でＹＥＳ）、処理をステップＳ１２１に戻す。ＣＰＵ１１は戻るが指示されていないと判定した場合（ステップＳ１３１でＮＯ）、処理をステップＳ１２９に移す。ＣＰＵ１１はチャートが指示されていないと判定した場合（ステップＳ１２４でＮＯ）、ＣＰＵ１１は確認が指示されたか否かを判定する（ステップＳ１３２）。ＣＰＵ１１は確認が指示されたと判定した場合（ステップＳ１３２でＹＥＳ）、処理をステップＳ１２７へ移す。ＣＰＵ１１は確認が指示されていないと判定した場合（ステップＳ１３２でＮＯ）、探索ニーズ登録処理を終了する。ＣＰＵ１１は設計図登録が指示されていないと判定した場合（ステップＳ１２２でＮＯ）、ＣＰＵ１１は確認が指示されたか否かを判定する（ステップＳ１３３）。ＣＰＵ１１は確認が指示されたと判定した場合（ステップＳ１３３でＹＥＳ）、処理をステップＳ１２７へ移す。ＣＰＵ１１は確認が指示されていないと判定した場合（ステップＳ１３３でＮＯ）、クリアが指示されたか否かを判定する（ステップＳ１３４）。ＣＰＵ１１はクリアが指示されたと判定した場合（ステップＳ１３４でＹＥＳ）、設定した内容をクリアし（ステップＳ１３５）、処理をステップＳ１２１へ戻す。ＣＰＵ１１はクリアが指示されていないと判定した場合（ステップＳ１３４でＮＯ）、探索ニーズ登録処理を終了する。

続いて、ロングリスト作成処理（ステップＳ２５）について、説明する。図４０はロングリスト作成処理の手順例を示すフローチャートである。ＣＰＵ１１は探索ニーズ登録処理により登録された探索ニーズなどから、探索すべき部品の要求仕様を取得する（ステップＳ１４１）。ＣＰＵ１１は取得した要求仕様に適合する部品を、品目ＤＢ１５３で検索する（ステップＳ１４２）。ＣＰＵ１１は検索にヒットした各部品について、部品を保有している企業の企業情報を、行内サーバ２の顧客ＤＢ２５１及び企業情報ＤＢ２５２から取得し（ステップＳ１４３）、主に協業適格性の観点から評価を行う。ＣＰＵ１１は評価に基づき、企業の絞り込みを行う（ステップＳ１４４）。ＣＰＵ１１は絞り込んだ結果であるロングリストを出力する（ステップＳ１４５）。ロングリストは大容量記憶部１５などに記憶する。

なお、各データベースにおいて、企業データの突合は法人番号を用いる。その他のコード、東京商工リサーチ（ＴＳＲ：ＴＯＫＹＯ ＳＨＯＫＯ ＲＥＳＥＡＲＣＨ， ＬＴＤ．）が発行するＴＳＲ企業コード、帝国データバンク（ＴＤＢ：Ｔｅｉｋｏｋｕ Ｄａｔａｂａｎｋ， Ｌｔｄ．）が発行するＴＤＢ企業コードなどを使用してもよい。また、各企業の評価を予め行っておき、行内サーバの顧客ＤＢ２５１などに記憶しておいてもよい。

次に、応募・提案の登録（ステップＳ６）、それに付随する「強み」情報の更新（ステップＳ２６等）について説明する。図４１は応募登録処理の手順例を示すフローチャートである。ＣＰＵ１１は応募登録画面ｄ０８を出力する（ステップＳ１５１）。ＣＰＵ１１は確認が指示されたか否かを判定する（ステップＳ１５２）。ＣＰＵ１１は確認が指示されたと判定した場合（ステップＳ１５２でＹＥＳ）、設定された応募情報を応募登録ＤＢ１５６に登録する（ステップＳ１５３）。ＣＰＵ１１は「強み」情報の更新を行い（ステップＳ１５４）、応募登録処理を終了する。ＣＰＵ１１は確認が指示されていないと判定した（ステップＳ１５２でＮＯ）、クリアが指示されたか否か判定する（ステップＳ１５５）。ＣＰＵ１１はクリアが指示されたと判定した場合（ステップＳ１５５でＹＥＳ）、設定をクリアし（ステップＳ１５６）、処理をステップＳ１５１へ戻す。ＣＰＵ１１はクリアが指示されていない判定した場合（ステップＳ１５５でＮＯ）、設定を破棄し応募登録処理を処理する。

「強み」情報更新処理（ステップＳ１５４）について、説明する。「強み」情報更新処理は、上述の応募登録処理から呼び出されるだけでなく、ビジネスモデル開発プロセスの様々な場面で呼び出される。図１９に示したように、経営資源調達型のプロセスでは、ステップＳ２６、Ｓ２７、Ｓ２９、Ｓ３１、Ｓ３３のぞれぞれとして実行される。ステップＳ２６はロングリストが作成された後である。ステップＳ２７は１次選定された後である。ステップＳ２９は２次選定された後である。ステップＳ３１は完成したビジネスモデルが登録された後である。ステップＳ３３は開発されたビジネスモデルが事業化されたら繰り返し行う業績トレースの後である。

図３３に示したように、アイデア募集型のプロセスでは、ビジネスモデルが評価された後に、「強み」情報更新処理が呼び出される。アイデア募集型のプロセスでは、ステップＳ６７、Ｓ６９、Ｓ６８、Ｓ７０、Ｓ７４のそれぞれで、ビジネスモデルの評価がされた後、当該ビジネスモデルを構成する部品である「強み」の情報が更新される。

図４２及び図４３は「強み」情報更新処理の手順例を示すフローチャートである。ＣＰＵ１１は実行しているプロセスが経営資源調達型か否かを判定する（ステップＳ１６１）。プロセスの判定は例えば、呼び出し元からもらった引数を用いて行う。ＣＰＵ１１はプロセスが経営資源調達型と判定した場合（ステップＳ１６１でＹＥＳ）、ＣＰＵ１１は応募登録に伴う呼び出しか否かを判定する（ステップＳ１６２）。ＣＰＵ１１は応募登録に伴う呼び出しであると判定した場合（ステップＳ１６２でＹＥＳ）、作成されたロングリストを取得する（ステップＳ１６３）。ＣＰＵ１１はロングリストに選定された部品（強み）の評価を予め定めたアルゴリズムにて、更新する（ステップＳ１６４）。ＣＰＵ１１は「強み」情報更新処理を終了する。ＣＰＵ１１は応募登録に伴う呼び出しではないと判定した場合（ステップＳ１６２でＮＯ）、１次選定に伴う呼び出しか否かを判定する（ステップＳ１６５）。ＣＰＵ１１は１次選定に伴う呼び出しと判定した場合（ステップＳ１６５でＹＥＳ）、１次評価の結果を取得する（ステップＳ１６６）。ＣＰＵ１１は１次評価結果に基づき、予め定めたアルゴリズムにて部品（強み）の評価を更新する（ステップＳ１６７）。ＣＰＵ１１は１次選定に伴う呼び出しではないと判定した場合（ステップＳ１６５でＮＯ）、２次選定に伴う呼び出しか否かを判定する（ステップＳ１６８）。ＣＰＵ１１は２次選定に伴う呼び出しと判定した場合（ステップＳ１６８でＹＥＳ）、２次評価の結果を取得する（ステップＳ１６９）。また、２次選定後に作成されたショートリストを取得する（ステップＳ１７０）。ＣＰＵ１１は２次評価結果及びショートリストに基づき、予め定めたアルゴリズムにて部品（強み）の評価を更新する（ステップＳ１７１）。例えば、プレゼンテーションの対象になった部品は、ショートリストに選定されたが、プレゼンテーションの対象にならなかった部品よりも高く評価する。ＣＰＵ１１は２次選定に伴う呼び出しではないと判定した場合（ステップＳ１６８でＮＯ）、成約に伴う呼び出しか否かを判定する（ステップＳ１７２）。ＣＰＵ１１は成約に伴う呼び出しと判定した場合（ステップＳ１７２でＹＥＳ）、成約されたビジネスモデルを構成する部品の評価を予め定めたアルゴリズムにて更新する（ステップＳ１７３）。ＣＰＵ１１は成約に伴う呼び出しではないと判定した場合（ステップＳ１７２でＮＯ）、呼び出しの契機となったビジネスモデルの評価を取得する（ステップＳ１７４）。ＣＰＵ１１はビジネスモデルの評価に基づき、予め定めたアルゴリズムにて部品（強み）の評価を更新する（ステップＳ１７５）。

ＣＰＵ１１はプロセスが経営資源調達型ではないと判定した場合（ステップＳ１６１ででＮＯ）、処理を図４３のステップＳ１７６へ移す。以降は、アイデア募集型プロセスにおける処理である。ＣＰＵ１１は１次選定に伴う呼び出しか否かを判定する（ステップＳ１７６）。ＣＰＵ１１は１次選定に伴う呼び出しと判定した場合（ステップＳ１７６でＹＥＳ）、１次選定の対象となったビジネスモデルの評価を取得する（ステップＳ１７７）。ＣＰＵ１１はビジネスモデルの評価に基づき、ビジネスモデルを構成する部品（強み）の評価を、予め定めたアルゴリズムにて更新する（ステップＳ１７８）。ＣＰＵ１１は１次選定に伴う呼び出しではないと判定した場合（ステップＳ１７６でＮＯ）、ＣＰＵ１１は２次選定に伴う呼び出しか否かを判定する（ステップＳ１７９）。ＣＰＵ１１は１次選定に伴う呼び出しと判定した場合（ステップＳ１７９でＹＥＳ）、２次選定の対象となったビジネスモデルの評価を取得する（ステップＳ１８０）。ＣＰＵ１１はビジネスモデルの評価に基づき、ビジネスモデルを構成する部品（強み）の評価を、予め定めたアルゴリズムにて更新する（ステップＳ１８１）。ＣＰＵ１１は２次選定に伴う呼び出しではないと判定した場合（ステップＳ１７９でＮＯ）、成約に伴う呼び出しか否かを判定する（ステップＳ１８２）。ＣＰＵ１１は成約に伴う呼び出しであると判定した場合（ステップＳ１８２でＹＥＳ）、成約に伴う仕掛りビジネスモデルの評価を取得する（ステップＳ１８３）。ＣＰＵ１１は仕掛りビジネスモデルの評価に基づき、ビジネスモデルを構成する部品（強み）の評価を、予め定めたアルゴリズムにて更新する（ステップＳ１８４）。ＣＰＵ１１は成約に伴う呼び出しではないと判定した場合（ステップＳ１８２でＮＯ）、開発完了に伴う呼び出しか否かを判定する（ステップＳ１８５）。ＣＰＵ１１は開発完了に伴う呼び出しと判定した場合（ステップＳ１８５でＹＥＳ）、処理をステップＳ１８３へ移す。ＣＰＵ１１は開発完了に伴う呼び出しではないと判定した場合（ステップＳ１８５でＮＯ）、ビジネスモデルに係る事業の業績トレースに基づく、当該ビジネスモデルの評価を取得する（ステップＳ１８６）。ＣＰＵ１１は事業の業績トレースに基づくビジネスモデルの評価に基づき、ビジネスモデルを構成する部品（強み）の評価を、予め定めたアルゴリズムにて更新する（ステップＳ１８７）。ＣＰＵ１１は評価更新（Ｓ１６４、Ｓ１６７、Ｓ１７１、Ｓ１７５、Ｓ１７８、Ｓ１８１、Ｓ１８４、Ｓ１８７）の後、「強み」情報更新処理を終了する。なお、ステップＳ１６１の分岐はプロセスにより判定したが、「強み」情報の更新対象の品目が第１階層に属するか否かで判定しても良い。更新対象品目が第１階層であれば、ステップＳ１６２以降を実行し、更新対象品目が第１階層でなければ、図４３のステップＳ１７６以降を実行する。

図４３及び図４４で示した評価は、ビジネスモデル開発プロセスにおけるものであったが、それに限らない。それ以外の場面でも評価を更新してもよい。それ以外の場面とは、例えば、ビジネスモデル開発プロセスに入る前などの下調べや技術動向調査などの場面である。このような場面に対応する評価としては、検索ヒット回数、閲覧回数を蓄積する。これらの回数が多いものが高い評価を得ていると考えられる。「強み」情報更新処理を以下のように、実現してもよい。部品情報を更新する必要がある処理と、評価更新のために取得する情報、取得した情報に基づく評価更新アルゴリズムとを、予め対応付けてデータベースに記憶しておく。ＣＰＵ１１は何らかの処理が発生するたびに、部品情報を更新する必要がある処理か否かを判定する。部品情報を更新する必要がある処理と判定した場合、評価更新のための情報を取得し、予め定めた評価更新アルゴリズムにより、部品情報を更新する。

更に、ショートリスト作成について、説明する。図４４はショートリスト作成処理の手順例を示すフローチャートである。ＣＰＵ１１はロングリストを取得する（ステップＳ１９１）。ＣＰＵ１１はロングリストに含まれる部品に関する評価を取得する（ステップＳ１９２）。ここでは、１次選定における探索企業の評価などである。ＣＰＵ１１は取得した評価に基づき、ロングリストを絞り込んだショートリストを作成する（ステップＳ１９３）。ＣＰＵ１１はショートリストを出力する（ステップＳ１９４）。ＣＰＵ１１はショートリスト作成処理を終了する。

図４５は成約処理の手順例を示すフローチャートである。図４５に示す処理は成約時に行われる処理のうち、採用された部品の登録処理である。ＣＰＵ１１は成約になった開発プロセスが経営資源調達型か否か判定する（ステップＳ２０１）。ＣＰＵ１１は成約になった開発プロセスが経営資源調達型であると判定した場合（ステップＳ２０１でＹＥＳ）、成約になった応募データ（部品）を選択する（ステップＳ２０２）。ＣＰＵ１１は新たな品番を発番する（ステップＳ２０３）。ＣＰＵ１１は選択した応募データの内容を応募登録ＤＢ１５６から取得し、当該応募データを新たな品番と対応付けて品目ＤＢ１５３に記憶する（ステップＳ２０４）。ＣＰＵ１１は成約になった応募データで未処理のものがあるか否かを判定する（ステップＳ２０５）。ＣＰＵ１１は成約になった応募データで未処理のものがあると判定した場合（ステップＳ２０５でＹＥＳ）、処理をステップＳ２０２に戻す。ＣＰＵ１１は成約になった応募データで未処理のものがないと判定した場合（ステップＳ２０５でＮＯ）、成約処理を終了する。ＣＰＵ１１は成約になった開発プロセスが経営資源調達型でないと判定した場合（ステップＳ２０１でＮＯ）、成約になったアイデアのデータを選択する（ステップＳ２０６）。ＣＰＵ１１は新たな品番を発番する（ステップＳ２０７）。ＣＰＵ１１は選択したアイデアデータの内容をアイデア応募ＤＢ１５８から取得し、当該アイデアデータを新たな品番と対応付けて品目ＤＢ１５３に記憶する（ステップＳ２０８）。ＣＰＵ１１は当該アイデアデータに関する品目管理ＤＢ１５４のレコードを更新し（ステップＳ２０９）、成約処理を終了する。成約処理により、経営資源調達型開発プロセスで新たに採用された価値提供スキーム、経営資源要素が品目ＤＢ１５３に登録され、以後、調達可能な部品となる。また、成約処理により、アイデア募集型開発プロセスで開発されたビジネスモデル価値定義が、品目ＤＢ１５３に登録され、以後の開発における参考例となると共に、ビジネスモデル自体が新たなビジネスモデルの部品としての活用が可能となる。更にまた、経営資源調達型開発プロセスおいて、採用されなかった部品も全て品目ＤＢ１５３に登録されるので、以後、活用可能となる。採用されなかった部品から、新たなビジネスモデルが創出される可能性もある。一方、アイデア募集型開発プロセスで登録されたビジネスモデル価値定義については、採用されなかったビジネスモデルも、漠然としたアイデアではなくビジネスモデルチャートで表現される設計図（レシピ）がデータとして記憶される。部品が見つからなかったビジネスモデルは必要部品の調達待ちとしておき、条件を満たす部品が登録されたら、調達可能となった旨を通知することが可能である。なお、ステップＳ２０１の分岐はプロセスにより判定したが、成約になった品目が第１階層に属するか否かで判定しても良い。成約品目が第１階層であれば、ステップＳ２０２以降を実行し、更新対象品目が第１階層でなければ、ステップＳ２０６以降を実行する。

以上のように、ビジネスモデル開発システム１００は探索企業と提案企業とを結びつけるプロセスを支援する。ビジネスモデル開発システム１００において、参加企業が増えるたびに、参加企業の行う事業が既存ビジネスモデルとして蓄積される。同時に、当該ビジネスモデルを構成する提供可能資源が蓄積される。ビジネスモデルも提供可能資源も１つの部品として、品目ＤＢ１５３として一元化して記憶される。それにより、経営資源調達型、アイデア募集型の開発プロセスにおいて、登録された部品の活用が図られる。経営資源調達型、アイデア募集型の開発プロセスは、ビジネスモデル開発手法の例であり、他の手法も採用可能である。例えば、運営組織が複数の企業を引き合わせ、引き合わされた企業は自社資源と他社資源とを合わせた新たなビジネスモデルを互いに提案し合い、新たなビジネスモデルを開発する手法である。

また、ビジネスモデル開発プロセスを通じて、更に新たなビジネスモデルや強み（経営資源要素）が蓄積される。更には、経営資源調達型のプロセスにおいては開発プロセスを通じて、提案企業が応募した強みが評価される。アイデア募集型のプロセスにおいては開発プロセスを通じて、提案企業が提案したビジネスモデルの評価が行われる。それに連動して、ビジネスモデルに含まれる強み（経営資源要素）の評価が更新される。

このように、ビジネスモデル開発システム１００はビジネスモデル開発に利用されることにより、データの充実が図られる。そして、充実したデータを活用することにより、さらなるビジネスモデルの開発が行われ、データが拡充されるというスパイラルに成長していくことが可能である。ビジネスモデルのレシピ登録を通して、ビジネスモデル開発システム１００に新たな部品が登録、あるいは既登録部品の追加情報が付加されることになる。
ビジネスモデルの開発案件を通して、部品情報がリッチ化していくプロセスとなっている。

更にまた、ビジネスモデル開発システム１００においては、品目データが蓄積されることにより、ビジネスモデルのレシピ（各経営資源要素の調達先が未定のもの）を入力すれば、各経営資源要素の調達先候補企業リストが即時入手できるようになり、よりスピーディーに具体的な新規事業のデザインが可能となる。また現行のビジネスモデルをレシピとして入力すれば、キーとなる経営資源についての調達可能先リストも入手可能である。これにより、価値提供スキームの組み換えや成長に合わせた調達先追加にも対応可能となる。

また、ビジネスモデル開発システム１００を活用すれば、従来のビジネスマッチングサービスとは一線を画した以下のような事業創造支援サービスが提供できることになる。「設計図」があれば、それぞれの構成要素について、提供候補企業のリストが入手できる。更に協業適格性評価により提供企業の組み合わせの良し悪しの判断を加味していけば、いくつかの「完成図」代替案も入手可能となる。この特徴を活かして、運営組織が主体となって、「設計図」を提供し、必要な「部品」を集めて、新しいビジネスモデルをプロデュースするような事業創造プロセスを提供することが可能となる。このようなビジネスモデルの開発手法をコンソーシアム型事業開発という。コンソーシアム型事業開発については、後述する。このように、上述したアイデア募集型プロセス及び経営資源調達型プロセスはビジネスモデル開発システム１００を用いた開発手法の典型例である。後述するコンソーシアム型事業開発を含めて、他の開発手法にもビジネスモデル開発システム１００は活用可能である。

なお、品目ＤＢ１５３に記憶する部品のデータはユーザである企業が入力するか、銀行員が代行する。それに限らず、クローリングを用いて得た経営資源に関する情報をテキスト分析し、分析結果に基づき、部品情報を生成し品目ＤＢ１５３に登録してもよい。ここで、情報収集する情報は、専門誌・学会論文情報、特許情報、新聞・雑誌情報、技術調査レポートなどである。

上述のビジネスモデル開発プロセスにおいては、キャパシティを考慮することが望ましい。各企業の経営資源要素には、量的な提供限界があるからである。品目ＤＢ１５３に量的なパラメータを含める共に、ビジネスモデルのレシピにも、各構成部品のスペックとして、量的なパラメータ（例えば、現時点での対応能力と対応能力増強の中期的な見通し、等）を含めてもよい。

上述のビジネスモデル開発システム１００において、運営組織は１つの金融機関を想定した記載となっているが、それに限らない。複数の金融機関それぞれが運用するビジネスモデル開発システム１００を連係できるようにしてもよい。その場合、各データに運営組織を特定するコード、例えば、統一金融機関コードを付す。それにより、運営組織毎のデータの切り分けや権限設定を適切に行うことが可能となる。

部品のメンテナンス機能について述べる。経営資源調達型開発プロセス及びアイデア募集型開発プロセスと関係なく、品目ＤＢ１５３に部品情報を登録してもよい。また、品目管理ＤＢ１５４を活用して、同一階層（第１階層、第２階層又は第３階層）の部品を階層的に定義してもよい。図４６は部品の分割と部品の統合の例を示す説明図である。図４６は品目管理ＤＢ１５４の変化を示している。本来、品目管理ＤＢ１５４には品目Ｎｏ．が記憶されるが、説明の簡単化のために名称を記載している。図４６Ａは部品の分割の例を示す。技術Ａという部品が既に登録されているとする。ここで、技術Ａには複数の技術が含まれており、一部の技術を独立して活用することが可能である場合、部品の分割が可能とする。図４６Ａでは技術Ａを技術Ａ１と技術Ａ２とに分割する場合を示している。手順としては、レシピ登録画面ｄ０６（図２５）と同様な画面を用いて、技術Ａ１と技術Ａ２とを品目ＤＢ１５３に登録する。次に、モデルチャート登録画面ｄ０７（図２９）と同様な画面で、技術Ａの下位に技術Ａ１と技術Ａ２とが接続されるツリーを作成する。その結果、図４６Ａの右側に示すように、技術Ａ、技術Ａ１及び技術Ａ２の関係を示すレコードが品目管理ＤＢ１５４に追加される。

図４６Ｂは部品の統合の例を示す。技術Ａ２及び技術Ｂという部品が既に登録されているとする。ここで、技術Ａ２と技術Ｂとを組み合わせることにより、新たな技術課題の解決が可能となった場合、統合した部品を新たな部品、技術Ｄとして登録する。手順としては、レシピ登録画面ｄ０６（図２５）と同様な画面を用いて、技術Ｄを品目ＤＢ１５３に登録する。次に、モデルチャート登録画面ｄ０７（図２９）と同様な画面で、技術Ｄは、技術Ａ２と技術Ｂとで構成されることを示すツリーを作成する。その結果、図４６Ｂの右側に示すように、技術Ｄ、技術Ａ２及び技術Ｂの関係を示すレコードが品目管理ＤＢ１５４に追加される。

上述のビジネスモデル開発においては、経営資源調達型とアイデア募集型との２つ開発プロセスを説明した。企業同士のマッチングとしては、いずれも１対１を主としている。しかしながら、ビジネスモデル開発システム１００においては、多数の企業の多数の部品が蓄積して行くことにより、３社以上の企業が事業開発を行うコンソーシアム型事業開発（以下、「コンソーシアム型」ともいう。）が可能となる。すなわち、以下の２点の特長により、従来のビジネスマッチングサービスとは一線を画した共創による事業創造支援サービスが提供可能である。特長の１点は、「設計図」があれば、それぞれの構成要素について、提供候補企業の「部品」のリストが入手可能となる。更に協業適格性評価により組み合わせの良し悪しの判断を加味した上で、提供企業を選定し、「完成図」が出来上がるという点である。もう１点の特長は、運営組織が主体となって、「設計図」を提供し、必要な「部品」を集めて、新しいビジネスモデルをプロデュースすることが可能となる点である。「設計図」とは各部品の調達先が未定のレシピである。「完成図」とは各部品の調達先が決定しているレシピである。

以下、コンソーシアム型のプロセスにおいて、特に重要な協業組み合わせの最適化について説明する。図４７は企業選定処理の手順例を示すフローチャートである。企業選定処理は設計図を入力すると、設計図に含まれる各部品の調達先企業の選定を行い、完成図を出力する処理である。

ＣＰＵ１１は、ビジネスモデルの設計図を取得する（ステップＳ２２１）。設計図に含まれる経営資源要素（部品）の中で、キーとなる経営資源要素を取得する（ステップＳ２２２）。キーとなる経営資源要素は、ユーザが競争優位を決定づける経営資源要素を選定し、指定する。キーとなる経営資源要素は１つとするのではなく、戦略的重要度による優先順位付けをしてもよい。ＣＰＵ１１は、経営資源要素別に提供可能企業のリストアップを行う（ステップＳ２２３）。ＣＰＵ１１は品目ＤＢ１５９に対して、キーワード検索を行い、ロングリストを生成する。更に、探索目的適合度や要求スペック充足度による絞込みを行ってもよい。ＣＰＵ１１は、経営資源要素別に課題解決力評価による提供可能企業の優先順位設定する（ステップＳ２２４）。各経営資源要素について、第１優先順位の提供候補企業の組み合わせを初期値（パターン）とする。

ＣＰＵ１１は協業適格性評価で適用する評価項目を設定する（ステップＳ２２５）。ここでは、全ての評価項目を適用する。

ＣＰＵ１１は協業組み合わせ評価を行う（ステップＳ２２６）。まず、ステップＳ２２２で取得したキーとなる経営資源について、ステップＳ２２３でリストアップし、ステップＳ２２４で順位付けしたリストの上位企業から協業適格性評価を行う。協業適格性評価の結果が所定の条件を満たせば、当該企業を選定する。条件を満たさない場合は、下位の企業について評価を行い、条件を満たす企業が選定できるまで繰り返す。キーとなる経営資源について、企業が選定できたら、その他の経営資源要素について、協業適格性評価に基づき選定を行う。選定の際、企業同士の相性により選定、非選定を決める場合、キーとなる経営資源についての選定企業を優先的に残す。

ＣＰＵ１１は全ての経営資源要素の中で、企業が未選定のものがあるか否かを判定する（ステップＳ２２７）。ＣＰＵ１１は企業が未選定の経営資源があると判定した場合（ステップＳ２２７でＹＥＳ）、適用する協業適格性評価の項目を更新する（ステップＳ２２８）。例えば、評価項目が全部で４つの場合、適用項目を１つ削り３つにする。協業適格性評価の項目うち、削除する項目をランダムに決定してもよいし、予め削除順を定めてもよい。ＣＰＵ１１は処理をステップＳ２２６へ戻す。ＣＰＵ１１は企業が未選定の経営資源がないと判定した場合（ステップＳ２２７でＮＯ）、完成図を出力する（ステップＳ２２９）。協業適格性評価の評価項目を１つにしても選定できない場合は、課題解決力評価が最も高い企業を選定してもよいし、選定できなかった旨を出力してもよい。

図４８から図５０は企業選定処理の例を示す説明図である。図４８は、設計図欄４８０、第１階層欄４８１、第２階層欄４８２、第３階層欄４８３及び候補企業欄４８４を含む。設計図欄４８０は設計図を示す欄である。設計図欄４８０は第１階層欄４８１、第２階層欄４８２及び第３階層欄４８３を含んでいる。第１階層欄４８１、第２階層欄４８２及び第３階層欄４８３はそれぞれ第１階層、第２階層及び第３階層のノードを表示している。第３階層のノードは、標準工程設計ノウハウ４８３１、リソース・ネットワーク最適化４８３２、ライン稼働予定情報の取得４８３３、スケジューリング最適化４８３４、ブロックチェーンによるトレーサビリティの確保４８３５及びＩｏＴによる稼働状況可視化４８３６である。候補企業欄４８４は第３階層の各ノードに対応して候補企業を表示している。候補企業欄４８４は第１位列４８４１、第２位列４８４２、第３位列４８４３、第４位列４８４４及び第５位列４８４５を含む。第１位列４８４１から第５位列４８４５は各ノードに対応する候補企業の課題解決力評価の順位を示している。例えば、リソース・ネットワーク最適化４８３２に対する候補企業は、第１位がＤ社、第２位がＥ社、第３位がＦ社、第４位がＧ社、第５位がＨ社となっている。また、標準工程設計ノウハウ４８３１は候補企業が３社のみであり、第４位及び第５位は空欄となっている。

図４９は、図４８に表示した第３階層欄４８３及び候補企業欄４８４を再掲している。他に、評価項目採否表４９１及び結果表４９２を表示している。評価項目採否表４９１は協業適格性評価の際に、どの項目を適用したかを示している。図４９は４つ項目全てを適用したことを示している。結果表４９２は協業適格性評価による結果を示す。結果表４９２は評価項目毎に結果を示している。第１行４９２１は財務的健全性評価の結果を示す。ここでは、Ｉ社は財務的なリスクを有することを示している。第２行４９２２は法務的健全性評価の結果を示す。ここでは、Ｌ社は法務的のリスクを有することを示している。第３行４９２３は取組姿勢の評価結果を示す。ここでは、Ｄ社は取組姿勢に問題があることを示している。第４行４９２４は協業障壁評価の結果を示す。ここでは、Ａ社とＫ社とは過去に事故があり、両者を同時に選定することは避けるべきであることを示す。

結果表４９２によれば、Ｉ社、Ｌ社、Ｄ社は選定すべきではない。Ａ社及びＤ社の２社を共に選定すべきではなく、Ａ社を選定するならばＤ社は非選定とすべきであり、Ｄ社を選定するならばＡ社は非選定とすべきである。これらを適用すると、候補企業欄４８４に示したようになる。候補企業の中で、四角で囲まれた企業が選定企業である。

標準工程設計ノウハウ４８３１については、１位のＡ社が選定される。リソース・ネットワーク最適化４８３２及び選定ライン稼働予定情報の取得４８３３については、１位のＤ社は選定すべきではないので、２位のＥ社が選定される。スケジューリング最適化４８３４については、１位のＡ社が選定される。ブロックチェーンによるトレーサビリティの確保４８３５については、１位のＩ社は選定すべきではないので、２位のＪ社が選定される。ＩｏＴによる稼働状況可視化４８３６については、１位のＫ社はＡ社と共に選定すべきではなく、２位のＬ社も選定すべきではないので、３位のＭ社が選定される。ＩｏＴによる稼働状況可視化４８３６において、Ｋ社を選定する場合は、標準工程設計ノウハウ４３１及びスケジューリング最適化４８３４については、Ｂ社が選定となる。Ａ社、Ｋ社のいずれを選定すべきかを、次のように判定する。例えば、Ａ社が担当する予定の標準工程設計ノウハウ４３１及びスケジューリング最適化４８３４と、Ｋ社が担当する予定のＩｏＴによる稼働状況可視化４８３６との重要度に応じて判断する。標準工程設計ノウハウ４３１又はスケジューリング最適化４８３４が、ＩｏＴによる稼働状況可視化４８３６よりも重要度が高ければ、Ａ社選定し、その逆であれば、Ｋ社を採用する。

図５０は、図４９と同様に評価項目採否表４９１、結果表４９２、第３階層欄４８３、及び候補企業欄４８４を表示している。評価項目採否表４９１に示すように、図５０の例では協業適格性評価では全項目を適用するのではなく、法務的健全性及び協業障壁の２項目を適用する。したがって、候補企業を選定する際には、法務的リスクがあるＬ社は選定すべきではない。そして、Ａ社及びＫ社を選定することは避けるべきである。

これらを適用すると、候補企業欄４８４に示したようになる。図４９と同様に、四角で囲まれた企業が選定企業である。標準工程設計ノウハウ４３１については、１位のＡ社が選定される。リソース・ネットワーク最適化４８３２及び選定ライン稼働予定情報の取得４８３３については、１位のＤ社が選定される。スケジューリング最適化４８３４については、１位のＡ社が選定される。ブロックチェーンによるトレーサビリティの確保４８３５については、１位のＩ社が選定される。ＩｏＴによる稼働状況可視化４８３６については、１位のＫ社はＡ社と共に選定すべきではなく、２位のＬ社も選定すべきではないので、３位のＭ社が選定される。Ａ社、Ｋ社のいずれを選定すべきかの判定は、図４９の場合と同様である。

なお、協業適格性評価の際に適用する評価項目は、運営組織が選択してもよい。例えば、全項目の中から、幾つかを選択してもよい。また、適用する評価項目の組み合わせを複数パターン用意しておき、運営組織が指定したパターンで評価してもよい。複数のパターンを運営組織が指定した場合は、それぞれについての選定結果を切り替えて表示できることが望ましい。

行内サーバ２やインターネットからクローリングなどによって、協業適格性評価の評価根拠となる情報を取得し、評価項目と評価根拠を対応付けて、運営組織に提示してもよい。運営組織は提示された内容を参考に、適用評価項目を選択してもよい。協業適格性評価の評価項目は４つに限定されない。３つ以下でも５つ以上でもよい。

コンソーシアム型では、単純に各構成要素の部品提供企業リストを出力するだけにとどまらず、その部品保有企業間の協業適格性の評価・チェックを通して、実現可能性が高い部品組み合わせ案を複数生成することが望まれる。したがって、全ての評価パターンで企業の選定を行い、複数の結果を運営組織が切り替えながら、最終的に選定企業を決定してもよい。

各実施の形態で記載されている技術的特徴（構成要件）はお互いに組み合わせ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態は全ての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内での全ての変更が含まれることが意図される。

１００ ビジネスモデル開発システム
１ メインサーバ
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 通信部
１５ 大容量記憶部
１５１ 企業ＤＢ
１５２ 事業ＤＢ
１５３ 品目ＤＢ
１５４ 品目管理ＤＢ
１５５ 探索ニーズＤＢ
１５６ 応募登録ＤＢ
１５７ 募集テーマＤＢ
１５８ アイデア応募ＤＢ
１５Ａ 開示設定ＤＢ
１５Ｂ 限定グループＤＢ
１６ 読み取り部
１Ｐ 制御プログラム
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
２ 行内サーバ
２Ｐ 制御プログラム
２１ ＣＰＵ
２２ ＲＯＭ
２３ ＲＡＭ
２４ 通信部
２５ 大容量記憶部
２５１ 顧客ＤＢ
２５２ 企業情報ＤＢ
３ 金融機関端末
３１ ＣＰＵ
３２ ＲＯＭ
３３ ＲＡＭ
３４ 通信部
３５ 入力部
３６ 表示部
３７ 大容量記憶部
４ 探索企業端末
５ 提案企業端末

Claims (9)

1. 事業体が自己申告した事業体情報及び事業を構成する部品の部品情報を取得し、
   前記部品の課題解決力評価情報及び金融機関が参照可能な前記事業体の協業適格性評価情報を取得し、
   ビジネスモデルの要件を定義する要件定義情報を取得し、
   前記部品情報及び前記要件定義情報を参照し、取得した前記要件定義情報に対応する部品情報を選択し、
   選択した前記部品情報及び該部品情報に対応付けられた課題解決力評価情報、並びに前記部品情報に対応付けられた事業体の事業体情報及び協業適格性評価情報を出力する
   処理をコンピュータに実行させることを特徴とするコンピュータプログラム。
2. 前記事業体に関する与信情報に基づく、前記事業体の前記協業適格性評価情報を前記金融機関から取得する
   ことを特徴とする請求項１に記載のコンピュータプログラム。
3. 前記要件定義情報は、顧客への提供価値定義情報、及び提供価値の提供の仕組みを定義するプロセス情報、又は前記仕組みを構成するために必要とする経営資源情報を含む
   ことを特徴とする請求項１又は請求項２に記載のコンピュータプログラム。
4. 前記事業体情報及び前記課題解決力評価情報に対応付けられた許可情報を取得し、
   取得した前記許可情報が参照可とする旨の設定がされている場合、前記許可情報に対応する前記事業体情報及び前記課題解決力評価を、前記事業体以外の事業体が参照可能とする
   ことを特徴とする請求項１から請求項３のいずれか１項に記載のコンピュータプログラム。
5. 前記事業体の端末に前記事業体情報及び部品情報を入力するための入力画面を表示させる
   ことを特徴とする請求項１から請求項４のいずれか１項に記載のコンピュータプログラム。
6. 前記事業体の識別情報及び採用情報を前記事業体以外の事業体の端末から取得した場合、前記識別情報に対応付けられた前記事業体の前記課題解決力評価情報を更新する
   ことを特徴とする請求項１から請求項５のいずれか１項に記載のコンピュータプログラム。
7. 事業体が自己申告した事業体情報及び事業を構成する部品の部品情報を取得する第１取得部と、
   前記部品の課題解決力評価情報及び金融機関が参照可能な前記事業体の協業適格性評価情報を取得する第２取得部と、
   ビジネスモデルの要件を定義する要件定義情報を取得する第３取得部と、
   前記部品情報及び前記要件定義情報を参照し、取得した前記要件定義情報に対応する部品情報を選択し、
   選択した前記部品情報及び該部品情報に対応付けられた課題解決力評価情報、並びに前記部品情報に対応付けられた事業体の事業体情報及び協業適格性評価情報を出力する出力部と
   を備えることを特徴とする出力装置。
8. コンピュータが、
   事業体が自己申告した事業体情報及び事業を構成する部品の部品情報を取得し、
   前記部品の課題解決力評価情報及び金融機関が参照可能な前記事業体の協業適格性評価情報を取得し、
   ビジネスモデルの要件を定義する要件定義情報を取得し、
   前記部品情報及び前記要件定義情報を参照し、取得した前記要件定義情報に対応する部品情報選択し、
   選択した前記部品情報及び該部品情報に対応付けられた課題解決力評価情報、並びに前記部品情報に対応付けられた事業体の事業体情報及び協業適格性評価情報を出力する
   ことを特徴とする出力方法。
9. ビジネスモデルを構成するのに必要な部品の要求仕様を取得し、
   取得した前記要求仕様を送信し、
   送信した前記要求仕様にヒットした部品の部品情報及び当該部品の課題解決力評価情報、並びに前記部品を有する事業体の事業体情報及び協業適格性評価情報を受信し、
   受信した前記部品情報及び課題解決力評価情報、並びに事業体情報及び協業適格性評価情報を対応付けて表示出力する
   処理をコンピュータに実行させることを特徴とするコンピュータプログラム。

Images