JP2021060883A - コンピュータプログラム、送信方法及び送信装置 - Google Patents

Abstract

【課題】企業情報と過去の事例とに基づき、企業の問題・課題を特定し出力するコンピュータプログラム等を提供することである。または、企業の問題・課題及び当該問題・修正に関連する解決事例を出力するコンピュータプログラム等を提供することである。【解決手段】コンピュータプログラムは、企業の情報を取得し、前記企業の情報に基づき、問題・課題を記憶する記憶部を参照して前記企業の問題・課題を特定し、特定した前記問題・課題を出力する処理をコンピュータに行わせる。【選択図】図２０

Description

本発明は、企業の問題・課題を出力するコンピュータプログラム等に関する。

企業の健全な発展に資するために、企業が抱える問題・課題や問題に関する提案を行う経営支援システムが提案されている（特許文献１）。一方、銀行等の金融機関においては、顧客企業の発展を促すために、行員が、顧客企業に対して経営改善等に必要な融資やコンサルティング、専門家や製品等を紹介するビジネスマッチングを行っている。

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

しかしながら、特許文献１に記載の技術では、行員のみコンサルティングは行えず、コンサルタントの工数を必要とする。また、行員が適切なコンサルティングやビジネスマッチングを行うためには、十分な知識や経験が必要であり、全行員が一定品質でコンサルティングやビジネスマッチングを提供することは困難である。また、それらを提供するためには、対象顧客企業の調査や分析、営業提案、他社事例の研究など多くの工数を必要とする。

本発明は斯かる事情によりなされたものである。その目的は、企業情報と過去の事例とに基づき、企業の問題・課題を特定し出力するコンピュータプログラム等の提供である。本発明の他の目的は、企業の問題・課題及び当該問題・修正に関連する解決事例を出力するコンピュータプログラム等の提供である。

本発明に係るコンピュータプログラムは、企業の情報を取得し、前記企業の情報に基づき、問題・課題を記憶する記憶部を参照して前記企業の問題・課題を特定し、特定した前記問題・課題を出力する処理をコンピュータに行わせることを特徴とする。

本発明にあっては、企業の情報に基づき、企業の問題・課題を特定し出力するので、経験や知識の乏しいユーザでも、顧客企業の問題・課題を把握することが可能となる。

提供システムの構成例を示す説明図である。 提供サーバのハードウェア構成例を示す説明図である。 ユーザ端末のハードウェア構成例を示すブロック図である。 業者端末のハードウェア構成例を示すブロック図である。 ユーザＤＢの例を示す説明図である。 ユーザ企業ＤＢの例を示す説明図である。 対象企業ＤＢの例を示す説明図である。 課題類型ＤＢの例を示す説明図である。 典型課題ＤＢの例を示す説明図である。 検索履歴ＤＢの例を示す説明図である。 事例ＤＢの例を示す説明図である。 依頼ＤＢの例を示す説明図である。 商材ＤＢの例を示す説明図である。 商材実績ＤＢの例を示す説明図である。 商材評価ＤＢの例を示す説明図である。 登録商材ＤＢの例を示す説明図である。 閲覧履歴ＤＢの例を示す説明図である。 ブックマークＤＢの例を示す説明図である。 業者ＤＢの例を示す説明図である。 業務処理の手順例を示すフローチャートである。 ブックマーク登録処理の手順例を示すフローチャートである。 企業情報入力画面の例を示す説明図である。 企業情報入力画面の例を示す説明図である。 企業情報入力画面の例を示す説明図である。 課題選択画面の例を示す説明図である。 事例一覧画面の例を示す説明図である。 事例詳細画面の例を示す説明図である。 事例詳細画面の例を示す説明図である。 依頼入力画面の例を示す説明図である。 依頼入力画面の例を示す説明図である。 通知メールの例を示す説明図である。 事例登録処理の手順例を示すフローチャートである。 事例登録画面の例を示す説明図である。 事例登録画面の例を示す説明図である。 課題判定処理の手順例を示すフローチャートである。 課題判定ＤＢの例を示す説明図である。 判定モデル生成処理に関する説明図である。 判定モデル生成処理の手順例を示すフローチャートである。 提案書作成処理の手順例を示すフローチャートである。 提案書の例を示す説明図である。 提案書の例を示す説明図である。 利用登録処理の手順例を示すフローチャートである。 商材一覧画面の例を示す説明図である。 商材詳細画面の例を示す説明図である。 通知ポイントＤＢの例を示す説明図である。 通知処理の手順例を示すフローチャートである。 アンケート収集処理の手順例を示すフローチャートである。 管理画面の例を示す説明図である。 管理画面の例を示す説明図である。 シナリオＤＢの例を示す説明図である。 共有設定ＤＢの例を示す説明図である。 シナリオ表示画面の例を示す説明図である。

以下実施の形態を、図面を参照して説明する。以下の説明において、ユーザは主として金融機関の職員、特に銀行で融資、コンサルティング、ビジネスマッチングを担当し、顧客企業に対して種々の提案を行っている行員を想定している。ユーザ企業はユーザが所属する企業である。業者は主として企業向けに問題・課題解決のためのソリューションを提供している企業を想定している。顧客はエンドユーザを想定している。顧客は上記ユーザから見た顧客である。以下の説明において、「問題」は、企業が目標とするものと、現状との間にあるギャップのことであり、目標達成のために、解決しなければならない事柄を示す。「課題」は、目標と現状とのギャップを埋めるために、やるべきことを示す。

（実施の形態１）
図１は提供システムの構成例を示す説明図である。提供システム１００は提供サーバ１、ユーザ端末２、業者端末３及び顧客端末４を含む。提供サーバ１、ユーザ端末２、業者端末３及び顧客端末４は、ネットワークＮにより、互いに通信可能に接続されている。図１ではユーザ端末２、業者端末３及び顧客端末４は１台ずつしか記載されていないが、それぞれが２台以上であってもよい。

図２は提供サーバのハードウェア構成例を示す説明図である。提供サーバ１（出力装置）はサーバコンピュータ、ワークステーション、ブレードサーバ等で構成する。提供サーバ１を複数のコンピュータからなるマルチコンピュータ、ソフトウェアによって仮想的に構築された仮想マシン又は量子コンピュータで構成しても良い。また、提供サーバ１の機能をクラウドサービスにより提供してもよい。

提供サーバ１は制御部１１、主記憶部１２、補助記憶部１３、通信部１４及び読み取り部１５を含む。制御部１１、主記憶部１２、補助記憶部１３、通信部１４及び読み取り部１５はバスＢにより接続されている。

制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有する。制御部１１は、補助記憶部１３に記憶された制御プログラム１Ｐ（コンピュータプログラム）を読み出して実行することにより、提供サーバ１に係る種々の情報処理、制御処理等を行う機能部（取得部、特定部、出力部）として、機能する。

主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等である。主記憶部１２は主として制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。

補助記憶部１３はハードディスク又はＳＳＤ（Solid State Drive）等であり、制御部１１が処理を実行するために必要な制御プログラム１Ｐや各種ＤＢ（Database）を記憶する。補助記憶部１３は、ユーザＤＢ１３１、ユーザ企業ＤＢ１３２、対象企業ＤＢ１３３、課題類型ＤＢ１３４、典型課題ＤＢ１３５、検索履歴ＤＢ１３６、事例ＤＢ１３７、依頼ＤＢ１３８、商材ＤＢ１３９、商材実績ＤＢ１３Ａ、商材評価ＤＢ１３Ｂ、登録商材ＤＢ１３Ｃ、閲覧履歴ＤＢ１３Ｄ、ブックマークＤＢ１３Ｅ及び業者ＤＢ１３Ｆ等を記憶する。補助記憶部１３は提供サーバ１に内蔵されるのではなく、提供サーバ１に接続された外部記憶装置であってもよい。補助記憶部１３に記憶する各種ＤＢ等を、データベースサーバやクラウドストレージに記憶してもよい。

通信部１４はネットワークＮを介して、ユーザ端末２、業者端末３及び顧客端末４と通信を行う。また、制御部１１が通信部１４を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム１Ｐをダウンロードし、補助記憶部１３に記憶してもよい。

読み取り部１５はＣＤ（Compact Disc）−ＲＯＭ及びＤＶＤ（Digital Versatile Disc）−ＲＯＭを含む可搬型記憶媒体１ａを読み取る。制御部１１が読み取り部１５を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、補助記憶部１３に記憶してもよい。また、半導体メモリ１ｂから、制御部１１が制御プログラム１Ｐを読み込んでもよい。

図３はユーザ端末のハードウェア構成例を示すブロック図である。ユーザ端末２はノートパソコン、パネルコンピュータ、タブレットコンピュータ、スマートフォン等で構成する。ユーザ端末２は制御部２１、主記憶部２２、補助記憶部２３、通信部２４、入力部２５及び表示部２６を含む。各構成はバスＢで接続されている。

制御部２１は、一又は複数のＣＰＵ、ＭＰＵ、ＧＰＵ等の演算処理装置を有する。制御部２１は、補助記憶部２３に記憶された制御プログラム２Ｐを読み出して実行することにより、種々の情報処理、制御処理等を行う。

主記憶部２２は、ＳＲＡＭ、ＤＲＡＭ、フラッシュメモリ等である。主記憶部２２は主として制御部２１が演算処理を実行するために必要なデータを一時的に記憶する。

補助記憶部２３はハードディスク又はＳＳＤ等であり、制御部２１が処理を実行するために必要な制御プログラム２Ｐ等を記憶する。

通信部２４はネットワークＮを介して、提供サーバ１と通信を行う。また、制御部２１が通信部２４を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム２Ｐをダウンロードし、補助記憶部２３に記憶してもよい。

入力部２５はキーボードやマウス等である。表示部２６は液晶表示パネル等を含む。表示部２６は提供サーバ１が出力した顧客が抱えていると予想される問題・課題やその解決事例などを表示する。また、表示部２６は入力部２５と一体化したタッチパネルディスプレイでもよい。なお、ユーザ端末２は外部の表示装置に表示を行ってもよい。

図４は業者端末のハードウェア構成例を示すブロック図である。業者端末３はノートパソコン、パネルコンピュータ、タブレットコンピュータ、スマートフォン等で構成する。業者端末３は制御部３１、主記憶部３２、補助記憶部３３、通信部３４、入力部３５及び表示部３６を含む。各構成はバスＢで接続されている。制御部３１、主記憶部３２、補助記憶部３３、通信部３４、入力部３５及び表示部３６はそれぞれ、ユーザ端末２の制御部２１、主記憶部２２、補助記憶部２３、通信部２４、入力部２５及び表示部２６と同様であるから説明を省略する。さらに顧客端末４もユーザ端末２とハードウェア構成が同様であるから、図示及び説明を省略する。

次に提供システム１００が用いるデータベースについて説明する。図５はユーザＤＢの例を示す説明図である。ユーザＤＢ１３１はユーザの情報を記憶する。ユーザＤＢ１３１はユーザＩＤ列、氏名列、氏名カナ列、企業ＩＤ列、部署名列、役職列、メールアドレス列、及び電話番号列を含む。ユーザＩＤ列はユーザを特定するＩＤを記憶する。氏名列はユーザの氏名を記憶する。氏名カナ列はユーザの氏名のカタカナ表記を記憶する。企業ＩＤ列はユーザが所属している企業（ユーザ企業）の企業ＩＤを記憶する。部署名列はユーザが所属する部署名を記憶する。役職列はユーザの役職を記憶する。ユーザが役職を持たない場合、「なし」空白、又は空の文字列を記憶する。メールアドレス列はユーザのメールアドレスを記憶する。電話番号列はユーザの連絡先電話番号を記憶する。なお、ユーザＩＤでユーザ一意に特定可能であることが望ましいが、ユーザＩＤ及び企業ＩＤでユーザを一意に特定可能であってもよい。

図６はユーザ企業ＤＢの例を示す説明図である。ユーザ企業ＤＢ１３２はユーザ企業の情報を記憶する。ユーザ企業ＤＢ１３２は企業ＩＤ列、企業名列、法人番号列及び金融機関コード列を含む。企業ＩＤ列はユーザ企業を一意に特定可能であるＩＤを記憶する。企業名列はユーザ企業の名称を記憶する。法人番号列は企業に付与された法人番号を記憶する。金融機関コード列は企業が金融機関であって、金融機関コードを付与されている場合に当該金融機関コードを記憶する。

図７は対象企業ＤＢの例を示す説明図である。対象企業ＤＢ１３３はユーザがコンサルティングの対象として企業の情報を記憶する。対象企業ＤＢ１３３はユーザがコンサルティングを行う対象と選定し、提供システム１００にデータを入力した際に、レコードの追加を行う。同一企業に複数回コンサルティングを行った場合、各回、対象企業ＤＢ１３３にレコードが追加される。各コンサルティングはそれぞれケースと呼ぶ。したがって、対象企業ＤＢ１３３が記憶する企業の情報は、同一企業であってもケースＩＤが発番される毎に追加されるので、トランザクションデータである。対象企業ＤＢ１３３はケースＩＤ列、企業名列、法人番号列、業種列、売上規模列、所在地列、従業員数列、創業年数列、業績傾向列及び登録日列を含む。ケースＩＤ列は各ケースを一意に特定可能なＩＤを記憶する。ケースＩＤは対象企業ＤＢ１３３にレコードを追加する際に発行される。企業名列は企業の名称を記憶する。法人番号列は企業に付与された法人番号を記憶する。業種列は企業の業種を記憶する。売上規模列は企業の売上規模を記憶する。図７に示す例では、売上規模列の値はランク分けした値としている。所在地列は対象企業の所在地を記憶する。図７に示す例では、所在地列の値は都道府県名としている。従業員数列は対象企業の従業員数を記憶する。図７に示す例では、従業員数列の値はランク分けした値としている。創業年数列は対象企業の創業年数を記憶する。図７に示す例では、創業年数列の値はランク分けした値としている。業績傾向列は対象企業の業績傾向を記憶する。業績傾向列は値を正規化するため、複数の選択肢の中から選択された値を記憶する。選択肢は例えば、「激増傾向」、「増加傾向」、「横ばい」、「激増傾向」及び「激減傾向」である。登録日列はレコードが追加された日付を記憶する。

図８は課題類型ＤＢの例を示す説明図である。課題類型ＤＢ１３４は企業が抱える問題・課題をテーマ毎に類型化した各類型を記憶する。課題類型ＤＢ１３４はテーマ列、番号列及び課題列を含む。テーマ列は複数の類型を束ねうる共通のテーマを記憶する。番号列は各問題・課題を識別する番号を記憶する。課題列は問題・課題の内容を記憶する。

図９は典型課題ＤＢの例を示す説明図である。典型課題ＤＢ１３５は業種、従業員数、売上規模など企業の基本的属性に対応して、典型的に発生する問題・課題についての情報を記憶する。典型課題ＤＢ１３５は業種列、売上規模列、従業員数列、創業年数列、業績傾向列、テーマ列、課題列を含む。業種列、売上規模列、従業員数列、創業年数列及び業績傾向列はそれぞれ問題・課題と対応する業種、売上規模、従業員数、創業年数、業績傾向を記憶する。これらの値は、対象企業ＤＢ１３３が記憶する値と同様な値とする。テーマ列は問題・課題のテーマを記憶する。課題列は問題・課題に付された番号を記憶する。テーマ列及び課題列の値は、課題類型ＤＢのテーマ列及び番号列と対応が取れる値とする。

図１０は検索履歴ＤＢの例を示す説明図である。検索履歴ＤＢ１３６はユーザが事例（過去のケース）を検索した場合のその履歴を記憶する。検索履歴ＤＢ１３６はケースＩＤ列、テーマ列、課題列及び検索日時列を含む。ケースＩＤ列はケースＩＤを記憶する。テーマ列は検索条件とした問題・課題のテーマを記憶する。課題列は検索条件とした問題・課題の番号を記憶する。検索日時列は検索日時を記憶する。

図１１は事例ＤＢの例を示す説明図である。事例ＤＢ１３７は過去のコンサルティングの事例を記憶する。事例ＤＢ１３７はケースＩＤ列、業者ＩＤ列、テーマ列、課題列、効果要約列、リード文列、課題１＿見出し列、課題１＿説明文列、課題２＿見出し列、課題２＿説明文列、課題３_見出し列、課題３＿説明文列、背景列、解決策列、画像列、選定理由列、効果列、費用列、期間列及び取材日列を含む。ケースＩＤ列はケースＩＤを記憶する。業者ＩＤ列はケースを担当した業者の業者ＩＤを記憶する。テーマ列は解決した問題・課題のテーマを記憶する。課題列は解決した問題・課題に対応する課題番号を記憶する。効果要約列は問題・課題が解決したことにより得た効果の要約を記憶する。リード文列は事例内容を端的に表現した文を記憶する。課題１＿見出し列、課題２＿見出し列及び課題３_見出し列はそれぞれ解決した問題・課題を説明する見出しを記憶する。課題１＿説明文列、課題２＿説明文列及び課題３＿説明文列は解決した問題・課題についての説明文を記憶する。解決した問題・課題が１つの場合、課題２＿見出し列及び課題２＿説明文列、並びに、課題３_見出し列及び課題３＿説明文列の値は空文字列とする。解決した問題・課題が２つの場合、課題３_見出し列及び課題３＿説明文列の値は空文字列とする。背景列は問題・課題が発生した背景を記憶する。解決策列は課題を解決するために採用した策を記憶する。解決策として業務システムや業務サービス等の商材を導入した場合、それらの情報も解決策列に記憶する。画像列はケースを説明するための画像を記憶する。画像データを記憶するのではなく、画像データを記憶しているファイルの名称を記憶してもよい。選定理由列は解決策を選定した理由を記憶する。効果列は解決策を採用して得られた効果を記憶する。費用列は問題・課題解決のために費やした費用を記憶する。期間列は問題・課題解決に要した期間を記憶する。取材日列は当該ケースの内容を取得した日付を記憶する。

図１２は依頼ＤＢの例を示す説明図である。依頼ＤＢ１３８はユーザから業者に対する依頼の内容を記憶する。依頼は、ユーザが顧客企業の問題・課題を解決するために、業者に対して顧客との面談依頼などである。依頼ＤＢ１３８は選択事例列、依頼内容列、ケースＩＤ列、ユーザＩＤ列、企業ＩＤ列、及びステータス列を含む。選択事例列は依頼を行うに際して、ユーザが参照した過去の事例のケースＩＤを記憶する。依頼内容列はユーザから業者への依頼の内容を記憶する。ケースＩＤ列はケースＩＤを記憶する。ユーザＩＤ列はユーザＩＤを記憶する。企業ＩＤ列はコンサルティングを受けている企業のＩＤを記憶する。ステータス列はケースの状況を記憶する。

図１３は商材ＤＢの例を示す説明図である。商材ＤＢ１３９は業者が販売する商材の情報を記憶する。商材ＤＢ１３９は商材ＩＤ列、商材名列、業者ＩＤ列、テーマ列及び課題列を含む。商材ＩＤ列は商材を一意に特定可能なＩＤを記憶する。商材名列は商材の名称を記憶する。業者ＩＤ列は商材を提供している業者の業者ＩＤを記憶する。テーマ列及び課題列は商材の導入により解決につながる問題・課題のテーマと課題の番号を記憶する。なお、商材ＤＢ１３９が記憶する商材については、ユーザ企業が販売代理店となることを希望すれば、業者の承認なく、提供システム１００が販売代理権を付与する仕組みとなっている。

図１４は商材実績ＤＢの例を示す説明図である。商材実績ＤＢ１３Ａは商材の採用実績を記憶する。商材実績ＤＢ１３ＡはケースＩＤ列及び商材ＩＤ列を含む。ケースＩＤ列はケースＩＤを記憶する。商材ＩＤ列はケースＩＤに対応した事例において採用された商材の商材ＩＤを記憶する。

図１５は商材評価ＤＢの例を示す説明図である。商材評価ＤＢ１３Ｂは商材に対する評価を記憶する。商材評価ＤＢ１３Ｂは商材ＩＤ列、評価列、利用者数列、価格帯列、顧客層列、商材画像列、説明テキスト列及び動画列を含む。商材ＩＤ列は商材ＩＤを記憶する。評価列は商材に対するユーザ又は顧客からの評価値を記憶する。例えば、評価値は５点満点として、各ユーザ又は各顧客からの評価点の平均値を評価値とする。利用者数列は商材を利用している顧客の数を記憶する。価格帯列は商材の価格帯を記憶する。顧客層列は商材の顧客層を記憶する。商材画像列は商材のロゴ等を記憶する。説明テキスト列は商材につての説明文を記憶する。動画列が商材についての説明動画を記憶する。動画列は動画データを記憶するのではなく、動画データを記憶したファイルのファイル名を記憶してもよい。

図１６は登録商材ＤＢの例を示す説明図である。登録商材ＤＢ１３Ｃはユーザ企業が販売代理契約を結んでいる商材を記憶する。登録商材ＤＢ１３Ｃは企業ＩＤ列及び商材ＩＤ列を含む。企業ＩＤ列は企業ＩＤを記憶する。商材ＩＤ列は販売代理契約を結んでいる商材の商材ＩＤを記憶する。

図１７は閲覧履歴ＤＢの例を示す説明図である。閲覧履歴ＤＢ１３Ｄはユーザが閲覧した事例を記憶する。閲覧履歴ＤＢ１３ＤはケースＩＤ列、ユーザＩＤ列、閲覧事例列、閲覧日時列及び滞在時間列を含む。ケースＩＤ列は対応するケースのケースＩＤを記憶する。ユーザＩＤ列は閲覧したユーザのユーザＩＤを記憶する。閲覧事例列はユーザが閲覧した事例のケースＩＤを記憶する。閲覧日時列はユーザが閲覧した日時を記憶する。滞在時間列は事例の詳細情報を表示するページをユーザが表示していた時間を記憶する。

図１８はブックマークＤＢの例を示す説明図である。ブックマークＤＢ１３Ｅは事例をブックマークとして記憶する。ブックマークを用いることで、ユーザは過去に閲覧した事例を容易に読み出すことが可能となる。ブックマークＤＢ１３ＥはユーザＩＤ列、ケースＩＤ列、メモ列及び登録日時列を記憶する。ユーザＩＤ列はブックマークを関するユーザのユーザＩＤを記憶する。ケースＩＤ列はブックマークしている事例のケースＩＤを記憶する。メモ列はユーザが記入したメモを記憶する。登録日時列はブックマークが登録された日時を記憶する。

図１９は業者ＤＢの例を示す説明図である。業者ＤＢ１３Ｆは商材を提供している業者の情報を記憶する。業者ＤＢ１３Ｆは業者ＩＤ列、名称列、住所列、電話番号列、電子メール列及び担当者名列を含む。業者ＩＤ列は業者を一意に特定するＩＤを記憶する。名称列は業者の名称を記憶する。住所列は業者の所在地住所を記憶する。電話番号列は業者の連絡先電話番号を記憶する。電子メール列は業者の連絡先電子メールアドレスを記憶する。担当者名列は業者の連絡先担当者名を記憶する。

次に、提供システム１００が行う処理について説明する。図２０は業務処理の手順例を示すフローチャートである。ユーザはコンサルティングを予定している顧客企業の企業情報をユーザ端末２に入力する。ユーザ端末２の制御部２１は企業情報を取得し、提供サーバ１へ送信する（ステップＳ１）。提供サーバ１の制御部１１は企業情報を受信する（ステップＳ２）。この際、制御部１１は新たなケースＩＤを発番し、当該ケースＩＤと受信した企業情報とを対応付けて、対象企業ＤＢ１３３に記憶する。制御部１１は企業情報に基づいて、当該企業が抱えていると予想される問題・課題を抽出し、ユーザ端末２へ送信する（ステップＳ３）。制御部１１は企業情報に含まれる業種、売上規模、従業員数、創業年数、業績傾向と、典型課題ＤＢ１３５に記憶されているこれらの情報とを対照し、値が一致するレコードを抽出する。５項目全てが一致するレコードだけでなく、４項目、３項目が一致するレコードを抽出してもよい。制御部１１は抽出したレコードのテーマ及び課題番号を取得する。制御部１１は課題番号に対応付けられた問題・課題を課題類型ＤＢ１３４から取得する。制御部１１はテーマを含む問題・課題をユーザ端末２へ送信する。ユーザ端末２の制御部２１は問題・課題を受信し表示する（ステップＳ４）。制御部２１は検索対象にする問題・課題を受け付け、提供サーバ１へ送信する（ステップＳ５）。提供サーバ１の制御部１１はテーマを含む問題・課題を受信する（ステップＳ６）。制御部１１はテーマと問題・課題とをキーに事例ＤＢ１３７を検索する（ステップＳ７）。この際、制御部１１は検索履歴をテーマ、問題・課題、ケースＩＤを対応付けて、検索履歴ＤＢ１３６に記憶する。制御部１１は検索結果をユーザ端末２へ送信する（ステップＳ８）。ユーザ端末２の制御部２１は検索結果を受信し、表示部２６に表示する（ステップＳ９）。検索結果は事例の一覧である。ユーザは事例一覧から顧客企業に適合しそうな事例を選択し、詳細表示を指示する。制御部２１は詳細要求を送信する（ステップＳ１０）。提供サーバ１の制御部１１は詳細要求を受信する（ステップＳ１１）。制御部１１は選択された事例についての履歴を閲覧履歴ＤＢ１３Ｄに記憶する（ステップＳ１２）。制御部１１は閲覧履歴ＤＢにケースＩＤ、ユーザＩＤ及び参照された事例のケースＩＤを対応付けて記憶する。制御部１１は選択された事例についての詳細画面を作成し、ユーザ端末２へ送信する（ステップＳ１３）。ユーザ端末２の制御部２１は詳細画面を受信し、表示部２６に表示する（ステップＳ１４）。ユーザは事例の詳細情報を確認し、顧客企業に適合するか否かを検討する。この際、ユーザは顧客企業にも当てはまると予想される事例についての提案書を作成し、顧客企業に提案を行ってもよい。ユーザは一覧画面と詳細画面とを行き来し、事例を１つ選択する。ユーザは選択した事例の詳細画面で、事例を掲載した業者への依頼（マッチング依頼）を行う。なお、事例を複数選択し、複数の業者へ依頼を行ってもよい。すなわち、制御部２１は事例に掲載された問題・課題を解決に導いた業者への依頼を提供サーバ１へ送信する（ステップＳ１５）。提供サーバ１の制御部１１は依頼を受信し、依頼先の業者端末３へ送信する（ステップＳ１６）。業者端末３の制御部３１は依頼を受信、表示部３６に表示する（ステップＳ１７）。業者は依頼を元に提案内容を検討し、提案の送信を業者端末３に指示をする。ここで、業者への依頼は提案を求めるものだけでなく、提案に向けての打ち合わせの依頼等でもよい。ユーザ及び顧客企業と業者とのやり取りは数度、行われてもよい。ユーザ又は顧客企業と業者とのやり取りが煮詰まった段階で、業者はユーザ及び顧客企業へ提案を行う。制御部３１は提案を提供サーバ１へ送信する（ステップＳ１８）。提供サーバ１の制御部１１は提案を受信し、ユーザ端末２へ送信する（ステップＳ１９）。ユーザ端末２の制御部２１は提案を受信し、表示部２６に表示する（ステップＳ２０）。ユーザは顧客企業ともに提案内容の確認を行い、提案に基づく発注を行う。この際に、必要な経費を調達するために、ユーザが所属する銀行から顧客企業に対して、融資を行ってもよい。制御部２１は発注する旨を提供サーバ１へ送信する（ステップＳ２１）。提供サーバ１の制御部１１は発注する旨を受信し、発注されたことを業者端末３へ通知する（ステップＳ２２）。業者端末３の制御部３１は通知を受信し表示する（ステップＳ２３）。業者は発注に基づき、顧客企業に対して商材の導入やコンサルティングを行い。問題・課題の解決を行う。業者は業務の完了後、当該業務を事例として登録する。業者は解決策等を業者端末３に入力する。業者端末３の制御部３１は事例を提供サーバ１へ送信する（ステップＳ２４）。提供サーバ１の制御部１１は事例を受信し、事例ＤＢ１３７に記憶する（ステップＳ２５）。ユーザから業者への依頼や発注、業者からユーザへの提案等は、両者が自発的に提供サーバ１にアクセスしなくとも迅速に伝達できるように、提供サーバ１がユーザ及び業者へ電子メールを送信することが望ましい。電子メールは依頼を受信した旨のみの内容でもよいし、依頼内容を含めたものでもよい。

ユーザは検索の結果として得られた事例を後に迅速に読み出せるように記憶することが可能である。図２１はブックマーク登録処理の手順例を示すフローチャートである。ユーザは事例の詳細画面において、ブックマーク登録を選択する。ユーザ端末２の制御部２１は登録指示を受け付ける（ステップＳ１２７）。制御部２１はブックマークに付加するコメント入力画面を表示する（ステップＳ１２８）。ユーザは必要に応じてコメントを入力し、送信を指示する。制御部２１は、ケースＩＤとユーザＩＤとコメントとを含む登録要求を提供サーバ１へ送信する（ステップＳ１２９）。提供サーバ１の制御部１１は登録要求を受信する（ステップＳ１３０）。制御部１１は登録要求に基づき、ブックマークＤＢ１３ＥにユーザＩＤ、事例ＩＤ、及びコメントが対応付けられたブックマークを登録する（ステップＳ１３１）。なお、コメントはなくともよい。制御部１１は完了をユーザ端末２へ送信する（ステップＳ１３２）。ユーザ端末２の制御部２１は完了を受信し、表示部２６に表示する（ステップＳ１３３）。制御部２１は処理を終了する。

続いて、業務処理において使用する画面について、説明する。図２２から図２４は企業情報入力画面の例を示す説明図である。企業情報入力画面ｄ０１は図２０のステップＳ１で使用される画面である。企業情報入力画面ｄ０１は会社名入力欄ｄ０１１、業種設定ボタンｄ０１２、その他業種リンクｄ０１３、売上規模設定ボタンｄ０１４、その他売上規模リンクｄ０１５、詳細入力ボタンｄ０１６及び課題検索ボタンｄ０１７を含む。会社名入力欄ｄ０１１は顧客企業の名称を入力する欄である。業種設定ボタンｄ０１２は顧客企業の業種を入力するボタンである。表示している業種に該当するものがない場合は、その他業種リンクｄ０１３を選択すると図２３に示すように業種設定ボタンｄ０１２の数が増える。業種設定ボタンｄ０１２の並び順、その他業種リンクｄ０１３を選択する前に表示する業種はユーザ毎、ユーザの所属部署毎に設定可能としてもよい。売上規模設定ボタンｄ０１４は顧客企業の売上規模を入力するボタンである。表示している金額に該当するものがない場合は、その他売上規模リンクｄ０１５を選択すると図２３に示すように売上規模設定ボタンｄ０１４の数が増える。売上規模設定ボタンｄ０１４の並び順、その他売上規模リンクｄ０１５を選択する前に表示する金額はユーザ毎、ユーザの所属部署毎に設定可能としてもよい。詳細入力ボタンｄ０１６は上述した情報以外の顧客企業情報を入力する場合に選択する。詳細入力ボタンｄ０１６を選択すると図２４に示す従業員数選択ボタンｄ０１９、創業年数選択ボタンｄ０１ａ、業績傾向選択ボタンｄ０１ｂが表示される。従業員数選択ボタンｄ０１９により顧客企業の従業員数を設定する。創業年数選択ボタンｄ０１ａにより顧客企業の創業年数を設定する。業績傾向選択ボタンｄ０１ｂにより顧客企業の業績傾向を設定する。課題検索ボタンｄ０１７を選択すると、企業情報に基づいて想定される問題・課題が表示される。

図２５は課題選択画面の例を示す説明図である。課題選択画面ｄ０２は図２０のステップＳ５で使用される画面である。課題選択画面ｄ０２は企業情報欄ｄ０２１、課題選択ボタンｄ０２２及び事例検索ボタンｄ０２３を含む。企業情報欄ｄ０２１は企業情報入力画面ｄ０１により設定した企業情報を表示する。課題選択ボタンｄ０２２は顧客企業が抱えている問題・課題を入力するボタンである。事例検索ボタンｄ０２３は選択された問題・課題を解決した過去の事例を検索し、一覧表示する。

図２６は事例一覧画面の例を示す説明図である。事例一覧画面ｄ０３は図２０のステップＳ９で表示される画面である。事例一覧画面ｄ０３は事例表示欄ｄ０３１及びページ制御ボタンｄ０３２を含む。事例表示欄ｄ０３１は課題表示欄ｄ０３１１、企業情報欄ｄ０３１２、テーマ表示アイコンｄ０３１３、効果表示欄ｄ０３１４及び詳細表示リンクｄ０３１５を含む。課題表示欄ｄ０３１１は解決した問題・課題の概要を表示する。課題表示欄ｄ０３１１に表示する内容は、事例ＤＢ１３７の課題１＿見出し列、課題２＿見出し列及び課題３＿見出し列の値に基づく。企業情報欄ｄ０３１２は対象となった企業の情報を表示する。企業情報欄ｄ０３１２に表示する内容は、対象企業ＤＢ１３３に記憶している値に基づく。企業情報は問題・課題が解決する前の情報である。テーマ表示アイコンｄ０３１３は解決した問題・課題のテーマを表示する。テーマ表示アイコンｄ０３１３は事例ＤＢ１３７のテーマ列の値に基づいて表示する。効果表示欄ｄ０３１４は問題・課題解決により得られた効果を表示する。効果表示欄ｄ０３１４に表示する内容は、事例ＤＢ１３７の効果要約列に記憶している値に基づく。詳細表示リンクｄ０３１５を選択する事例の詳細を表示する事例詳細画面に遷移する。ページ制御ボタンｄ０３２は一覧が複数ページにわたる場合にページ遷移を行うための複数のボタンを含む。各ボタンによる制御は公知であるから説明を省略する。

図２７及び図２８は事例詳細画面の例を示す説明図である。事例詳細画面ｄ０４は図２０のステップＳ１４で表示される画面である。事例詳細画面ｄ０４は効果表示欄ｄ０４１、効果リード文欄ｄ０４２、課題見出し欄ｄ０４３、課題説明欄ｄ０４４、背景表示ボタンｄ０４５、解決策欄ｄ０４６、選定理由表示ボタンｄ０４７、効果説明欄ｄ０４８、取材日表示欄ｄ０４９、企業情報表示欄ｄ０４ａ、依頼ボタンｄ０４ｂ及びブックマークアイコンｄ０４ｃを含む。効果表示欄ｄ０４１は、は問題・課題解決により得られた効果を表示する。効果表示欄ｄ０４１に表示する内容は、事例ＤＢ１３７の効果要約列に記憶している値に基づく。効果リード文欄ｄ０４２は効果について簡単な説明文を表示する。効果リード文欄ｄ０４２に表示する内容は、事例ＤＢ１３７のリード文列に記憶している値に基づく。課題見出し欄ｄ０４３は解決した問題・課題の概要を表示する。課題見出し欄ｄ０４３に表示する内容は、事例ＤＢ１３７の課題１＿見出し列、課題２＿見出し列及び課題３＿見出し列の値に基づく。課題説明欄ｄ０４４は問題・課題の内容を表示する。課題説明欄ｄ０４４に表示する内容は、事例ＤＢ１３７の課題１＿説明文列、課題２＿説明文列及び課題３＿説明文列の値に基づく。背景表示ボタンｄ０４５は背景を表示するボタンである。背景表示ボタンｄ０４５を選択すると、背景表示ボタンｄ０４５は非表示となり、図２８Ａで示すように検討の背景についての説明文が表示される。当該説明文は事例ＤＢ１３７の背景列の値に基づく。解決策欄ｄ０４６は解決策を表示する。解決策欄ｄ０４６の表示内容は、事例ＤＢ１３７の解決策列の値に基づく。選定理由表示ボタンｄ０４７は解決策の選定理由を表示するボタンである。選定理由表示ボタンｄ０４７を選択すると、選定理由表示ボタンｄ０４７は非表示となり、図２８Ｂで示すように選定の理由についての説明文が表示される。当該説明文は事例ＤＢ１３７の選定理由列の値に基づく。効果説明欄ｄ０４８は得られた効果を表示する。効果説明欄ｄ０４８の表示内容は事例ＤＢ１３７の効果列の値に基づく。取材日表示欄ｄ０４９は事例の内容を取得した日付を表示する。取材日表示欄ｄ０４９の表示内容は事例ＤＢ１３７の取材日列の値に基づく。企業情報表示欄ｄ０４ａは企業情報を選択する。企業情報表示欄ｄ０４ａの表示内容は、対象企業ＤＢ１３３に記憶している値に基づく。依頼ボタンｄ０４ｂを選択すると依頼入力画面に遷移する。ブックマークアイコンｄ０４ｃを選択すると、表示している事例がブックマークとして保存される。

図２９及び図３０は依頼入力画面の例を示す説明図である。依頼入力画面ｄ０５は選択事例表示欄ｄ０５１、種別選択ボタンｄ０５２、依頼内容入力欄ｄ０５３、企業情報表示欄ｄ０５４、担当者入力欄ｄ０５５及び確認ボタンｄ０５６を含む。選択事例表示欄ｄ０５１は選択した事例を表示する。依頼入力画面ｄ０５は事例詳細画面ｄ０４から遷移するので、依頼入力画面ｄ０５において、事例の変更はできない。種別選択ボタンｄ０５２は依頼の種別を選択するボタンである。依頼内容入力欄ｄ０５３は依頼の具体的内容を入力する欄である。企業情報表示欄ｄ０５４は顧客企業の情報を表示する。顧客企業の情報は、事例検索時に企業情報入力画面ｄ０１にて入力しているので、その内容を引き継ぐ。依頼入力画面ｄ０５において、企業情報入力画面ｄ０１において未入力であった項目を追加入力したり、入力済みの項目を変更したりしてもよい。担当者入力欄ｄ０５５はユーザの情報を入力する欄である。ユーザは提供システム１００にログインしている場合、ユーザＤＢ１３１に記憶している値が、担当者入力欄ｄ０５５に入力された状態で依頼入力画面ｄ０５が表示される。金融機関名はユーザＤＢ１３１の企業ＩＤ列の値に基づき、ユーザ企業ＤＢ１３２を検索し、ヒットしたレコードの企業名列の値が入力される。確認ボタンｄ０５６は依頼内容を確定し、確認画面に遷移するためのボタンである。

確認画面は図示を省略するが、表示内容は依頼入力画面ｄ０５と同様である。確認画面では確認ボタンｄ０５６はなく、修正ボタン及び依頼ボタンが表示される。修正ボタンを選択すると、確認画面から依頼入力画面ｄ０５へ戻る。依頼ボタンが選択すると、依頼内容が提供サーバ１へ送信され記憶される。そして、提供サーバ１は業者の電子メールアドレス宛（送信先）へ電子メールを送信する。電子メールアドレスは業者ＩＤを検索キーにより業者ＤＢ１３Ｆを検索し習得する。例えば、依頼内容が電子メールで送信される。または、依頼内容が送信された旨の電子メールが送信され、メールを表示している業者端末３において、メールに含まれるリンクを選択すると、業者端末３が提供システム１００に接続され、依頼内容が業者端末３に表示されるようにしてもよい。

図３１は通知メールの例を示す説明図である。図３１に示す例は、依頼内容がメールにすべて含まれている例である。メールに含まれるＵＲＬ３１１は過去の事例を表示するためのＵＲＬであり、当該ＵＲＬ３１１を選択することにより、提供システム１００に登録した事例が表示されるので、業者は過去のどのような事例に基づいて、依頼がされたことを把握することが可能となる。

業者が依頼内容を受け取った後、顧客企業と業者とは打ち合わせやＷｅｂ会議の日程調整を行う。業者が行うコンサルティングの内容、導入する商材、総費用について、双方が同意すれば受発注が行われる。その後、業者がソリューションを提供し、問題・課題が解決されて、ケースは終了する。これらの業務に関して、提供システム１００がサービスを提供するが、これらについては、公知のワークフローシステム、プロジェクト管理システムなどで実現可能であるので、ここでは説明を省略する。提供システム１００がサービスを提供するのではなく、ワークフローシステム、プロジェクト管理システムなどと連携してもよい。他のシステムと連携する場合でも、ケースの最新の状態（最新の状況）を提供システム１００が取得し、依頼ＤＢ１３８のステータス列が最新のステータスを記憶していることが望ましい。

続いて、事例登録機能について述べる。終了したケースは事例として登録する。図３２は事例登録処理の手順例を示すフローチャートである。事例登録処理はバッチ処理により、繰り返し実行する。または、各ケースのステータスを管理している依頼ＤＢ１３８が更新されたら実行する。提供サーバ１の制御部１１は完了ケースがあるか否かを判定する（ステップＳ３１）。制御部１１は依頼ＤＢ１３８を検索し、ステータスが完了となっているケースがあるか否かを判定する。例えば、ステータス列の値が「完了」であるケースである。制御部１１は完了ケースがないと判定した場合（ステップＳ３１でＮＯ）、処理を終了する。制御部１１は完了ケースがあると判定した場合（ステップＳ３１でＹＥＳ）、依頼メールを業者宛に送信する（ステップＳ３２）。業者端末３の制御部３１は依頼メールを受信する（ステップＳ３３）。依頼メールを読んだ業者は作業を開始する。制御部３１は登録画面の要求を提供サーバ１へ送信する（ステップＳ３４）。登録画面の要求は例えばＨＴＴＰリクエストである。提供サーバ１の制御部１１は要求を受信する（ステップＳ３５）。制御部１１は登録画面を生成し業者端末３へ送信する（ステップＳ３６）。前記要求にはケースを特定するケースＩＤが含まれており、対象企業ＤＢ１３３に記憶されている企業情報など既に既知の項目については、生成した登録画面において、入力済みとなっていることが望ましい。業者端末３の制御部３１は登録画面を受信し、表示部３６に表示する（ステップＳ３７）。業者は登録画面に事例情報を入力し、送信を指示する。制御部３１は事例情報を受け付け、提供サーバ１へ送信する（ステップＳ３８）。提供サーバ１の制御部１１は事例情報を受信し、事例ＤＢ１３７に記憶する（ステップＳ３９）。制御部１１はケースのステータスを、事例が登録されたことを示す登録済に変更し、処理を終了する（ステップＳ４０）。

図３３及び図３４は事例登録画面の例を示す説明図である。事例登録画面ｄ０６は概要セクションｄ０６１、課題セクションｄ０６２、解決策セクションｄ０６３、効果セクションｄ０６４、その他セクションｄ０６５及び企業セクションｄ０６６、並びに、確認ボタンｄ０６７を含む。概要セクションｄ０６１には事例の概要を入力する。概要セクションｄ０６１は項目としてテーマ、効果及びリード文を含む。テーマはプルダウンメニューにより最適なテーマを選択する。課題セクションｄ０６２には問題・課題の内容を入力する。課題セクションｄ０６２は項目として、見出し１〜３、見出しについての説明、背景及び検索タグを含む。検索タグは問題・課題の類型を付与する。検索タグの付与は、プルダウンメニューで表示される選択肢の中から問題・課題に対応したものを選択することで行う。選択肢の内容は課題類型ＤＢ１３４に基づく。解決策セクションｄ０６３には問題・課題に対して採用した解決策を入力する。解決策セクションｄ０６３は項目として説明、画像及び選定の理由を含む。解決策セクションｄ０６３では画像の登録が可能である。設定された画像のサムネイルｄ０６３１が表示される。設定ボタンｄ０６３２を選択することにより、登録する画像ファイルを設定する。削除ボタンｄ０６３３を選択することにより、画像ファイルの設定をクリアする。解決策セクションｄ０６３は項目として説明を含む。効果セクションｄ０６４には対象企業が得た効果を入力する。その他セクションｄ０６５にはその他の情報を入力する。その他セクションｄ０６５は項目として、費用、期間、取材日を含む。なお、取材日は完了後に業者が対象企業に対してヒアリングを行った日付、事例情報を入力した日等を入力する。確認ボタンｄ０６７を選択すると、入力内容を確認する確認画面へ遷移する。確認画面において確定ボタンを選択すると、入力内容が事例ＤＢ１３７に記憶される。

上述では、提供システム１００を通じて発生したケースが完了した場合での事例登録としたが、提供システム１００とは別のルートで発生したケースも事例登録画面ｄ０６を用いて事例ＤＢ１３７に登録してもよい。この場合、対象企業ＤＢ１３３にもレコードを追加する。

本実施の形態においては、コンサルティングの対象とする企業の基本的情報を入力すると、当該企業が抱えていると予想される問題・課題が得られる。また、問題・課題を選択すると、過去の事例から同様な問題・課題を解決した事例を検索することが可能となる。さらに、参照した事例に含まれる問題・課題を解決した業者に連絡が可能である。以上により、コンサルティングに不慣れなユーザであっても、企業に的確なコンサルティングが行なえ、業者と協力して顧客企業の問題・課題を解決することが可能となる。特にユーザが銀行等の行員である場合は、コンサルティングに伴い、顧客企業に対しての融資が可能となる。また、過去の事例に基づいて問題・課題解決を行うので、顧客企業は着実に効果を得られる可能性が高くので、融資が焦げ付くことなく回収することが期待される。また、ユーザは提供システム１００を利用することで、課題解決のためのコンサルティングを提供する業者や、課題解決に役立つ商品等の外部リソースを用いた幅広いコンサルティングを行うことが可能となる。ユーザは顧客企業と業者とを結びつけるビジネスマッチングを行うことにより、両者の発展に寄与するだけでなく、マッチングについての手数料収入を得ることが可能となる。提供システム１００は顧客企業、金融機関及び業者の三者が協力して、当該顧客企業が抱える問題・課題を解決するので、問題解決プラットホームとも称すべきものと言える。

（実施の形態２）
本実施の形態は顧客企業の問題・課題を、他システムのデータに基づいて特定する形態に関する。本実施の形態において、システム構成、提供サーバ１のハードウェア構成等は実施の形態１と同様である。以下の説明においては、主として実施の形態１と異なる点について説明する。

ここで、他システムは予約システム、ＰＯＳ（Point of sale system）システム、勤怠システム、会計システム、給与システム、受発注システム、日報システム、ＳＮＳ（Social Networking Service）を含む。予約システムは医療機関の診察予約、飲食店の座席予約、貸会議室に関する施設予約、旅行に関するツアー予約、交通機関に関する切符予約、語学学習に関するレッスン予約、エステサロン・ネールサロンに関する施術予約など、種々の予約を行うシステムを含む。ＰＯＳシステムは物品販売の売上実績を単品単位で集計する一般的なシステム以外に、サービス業におけるサービスの売上実績をサービスメニュー単位で集計するものも含む。勤怠システムは正社員、契約社員、パートタイマーなどを含む従業員の勤怠を管理するシステムである。会計システムは管理会計システム、財務会計システム等である。給与システムは従業員に支払うべき給与を計算するとともに給与支払いの履歴を保存するシステムである。受発注システムは商品やサービスの受注及び発注を行うためのシステムである。日報システムは社員が就業日毎に作成する日報を作成、記憶するシステムである。

図３５は課題判定処理の手順例を示すフローチャートである。ユーザは問題・課題を特定したい企業の識別情報（会社名、法人番号等）を提供サーバ１へ送信する。提供サーバ１の制御部１１は対象企業の識別情報を取得する（ステップＳ５１）。制御部１１は他システムから対象企業の情報を取得する（ステップＳ５２）。制御部１１は取得した情報の変化傾向を解析する（ステップＳ５３）。例えば、売上の変化、離職状況、受注状況を解析する。制御部１１は解析内容より課題を特定する（ステップＳ５４）。課題の特定については後述する。制御部１１は特定した課題を出力する（ステップＳ５５）。ユーザは特定された課題に基づき、事例検索等を行う。以降の処理は実施の形態１と同様であるから、省略する。

図３６は課題判定ＤＢの例を示す説明図である。図３６に示すように、課題判定ＤＢ１３Ｇは複数のテーブルから構成されていてもよい。課題判定ＤＢ１３Ｇはシステム列、項目列、傾向列及び課題列を含む。システム列は情報源となる他システムの識別子、例えばシステムの略称を記憶する。項目列は解析対象の識別子、例えば項目名を記憶する。傾向列は解析対象の値の傾向を記憶する。課題列は予想される問題・課題を記憶する。図３６Ａは対象企業が飲食業の場合の例である。例えば、ＰＯＳシステムから売上（ＰＯＳ情報の一例）を取得し、前後する所定期間での変化が、１０％減少であった場合、売上減少を解決すべき問題・課題と判定する。また、日報システムから日々の日報で使われている特定の語を検索する。例えばクレームという語が増加傾向にある場合、人員不足による業務負荷増を解決すべき問題・課題と判定する。この場合、勤怠システムから得た人員数（人財情報の一例）の傾向も見ることにより、業務負荷増の原因は人員不足であると確定する。図３６Ｂは取引形態がＢ ｔｏ Ｂの企業向けである。例えば、営業情報システムから得た受注率（会計情報の一例）の傾向が、低下傾向であった場合、営業力低下を解決すべき問題・課題と判定する。

図３５のステップＳ５３で行う解析は、課題判定ＤＢ１３Ｇに特定されているレコードに合わせて行ってもよい。それにより、解析処理を最低限の処理量とすることができる。

（実施の形態３）
本実施の形態は顧客企業の問題・課題を、他システムのデータに基づいて特定する形態に関する。本実施の形態において、システム構成、提供サーバ１のハードウェア構成等は実施の形態１と同様である。以下の説明においては、主として実施の形態１と異なる点について説明する。実施の形態２においては予め判定ロジックを決め、当該判定ロジックを記憶した課題判定ＤＢ１３Ｇを用意する必要があったが、本実施の形態においては機械学習により得た判定モデル（学習モデル）を用いて判定することにより、判定ロジックの検討が不要となる。

図３７は判定モデル生成処理に関する説明図である。図３７機械学習を行って判定モデル１６を生成する処理を概念的に示している。判定モデル１６は補助記憶部１３に記憶する。

提供サーバ１は、判定モデル１６として、定量データ及び定性データ並びに問題・課題を含む教師データとして、ディープラーニングを行う。それによって、定量データ及び定性データを入力とし、問題・課題を出力とするニューラルネットワークを生成する。ニューラルネットワークは例えばＣＮＮ（Convolution Neural Network）であり、対象企業に対する定量データ及び定性データの入力を受け付ける入力層と、対象企業が抱えている問題・課題を出力する出力層と、定量データ及び定性データの特徴量を抽出する中間層とを有する。

定量データは、ＰＯＳ、請求システム、予約データ、会計データ、勤怠データ、社員のモチベーションデータ、ＣＲＭ（Customer Relationship Management）やＳＦＡ（Sales Force Automation）から得られる営業情報等である。定性データは、電子メール、社内ＳＮＳ、従業員アンケートの回答結果、日報、コールセンターにおける対応履歴、Ｗｅｂページにより収集した問い合わせデータ、顧客アンケートの回答データ、ＳＮＳの口コミ、スコア、ソーシャルリスニングツールから得たデータ等である。

入力層は、定量データ及び定性データに含まれる各種データの入力を受け付ける複数のニューロンを有し、入力された各種データを中間層に受け渡す。中間層は複数のニューロンを有し、定量データ及び定性データの特徴量を抽出して出力層に受け渡す。例えば判定モデル１６がＣＮＮである場合、中間層は、入力層から入力された各種データを畳み込むコンボリューション層と、コンボリューション層で畳み込んだ定量データ及び定性データをマッピングするプーリング層とが交互に連結された構成を有し、定量データ及び定性データの特徴量を抽出する。出力層は判定器であり、問題・課題を出力する一又は複数のニューロンを有し、中間層から出力された特徴量に基づいて、問題・課題を判定する。本実施の形態では判定モデル１６がＣＮＮであるものとして説明するが、判定モデル１６はＣＮＮに限定されず、ＣＮＮ以外のニューラルネットワーク、ベイジアンネットワーク、決定木など、他の学習アルゴリズムで構築された学習済みモデルであってよい。

提供サーバ１は、定量データ及び定性データと、問題・課題の正解値とが対応付けられた教師データを用いて学習を行う。例えば図３７に示すように、教師データは、定量データ及び定性データと問題・課題とがラベル付けされたデータである。

提供サーバ１は、教師データである定量データ及び定性データを入力層に入力し、中間層での演算処理を経て、出力層から問題・課題を取得する。提供サーバ１は、出力層から出力された結果を、教師データにおいて定量データ及び定性データに対しラベル付けされた問題・課題、すなわち正解値と比較し、出力層からの出力値が正解値に近づくように、中間層での演算処理に用いるパラメータを最適化する。当該パラメータは、例えばニューロン間の重み（結合係数）、各ニューロンで用いられる活性化関数の係数などである。パラメータの最適化の方法は特に限定されないが、例えば提供サーバ１は誤差逆伝播法を用いて各種パラメータの最適化を行う。

図３８は判定モデル生成処理の手順例を示すフローチャートである。図３８に基づき、教師データから判定モデル１６を生成する機械学習処理の内容について説明する。提供サーバ１の制御部１１は過去の事例を収集する（ステップＳ６１）。制御部１１は処理対象とする事例を選択する（ステップＳ６２）。制御部１１は事例の対象となった企業の情報を収集する（ステップＳ６３）。収集する情報は、事例のおける問題・課題が解決する以前の定量データ及び定性データである。制御部１１は収集した定量データ及び定性データ、並びに事例に含まれる解決した問題・課題より教師データを作成する（ステップＳ６４）。制御部１１は教師データにより学習を行う（ステップＳ６５）。制御部１１は未処理の事例があるか否かを判定する（ステップＳ６６）。制御部１１は未処理の事例があると判定した場合（ステップＳ６６でＹＥＳ）、処理をステップＳ６２へ戻し、未処理の事例についての処理を行う。制御部１１は未処理の事例がないと判定した場合（ステップＳ６６でＮＯ）、判定モデル１６についてのパラメータ等を記憶し（ステップＳ６７）、処理を終了する。

判定モデル１６を用いた課題判定処理について説明する。図３５に示した処理手順の一部が異なる。図３５のステップＳ５３は不要である。ステップＳ５４及びステップＳ５５は次のように変更する。制御部１１はステップＳ５２で取得した情報を判定モデル１６に入力し、出力として予測される問題・課題を取得する。制御部１１は取得した問題・課題を出力する。

本実施の形態においては、企業の問題・課題が含まれた過去の事例と、事例の対象となった企業についての種々の情報とに基づいて、学習を行った判定モデル１６を用いる。ユーザは、コンサルティング対象の企業についての情報を収集し、判定モデル１６に入力することで、対象の企業が抱えていると予想される問題・課題を得ることが可能となる。

本実施の形態において、判定モデル１６としてＲＮＮ（Recurrent Neural Network）を採用し、定性データ及び定量データを時系列データとし、各時系列データと問題・課題とを対応付けた教師データで、判定モデル１６の学習を行ってもよい。判定モデル１６で問題・課題を判定する際には、定性データ及び定量データの時系列データを判定モデル１６に入力し、判定モデル１６に出力として、問題・課題を習得する。

（実施の形態４）
本実施の形態は、事例から顧客企業向けの提案書を作成する機能に関する。当該機能は、上述の実施の形態１から３に追加されるものである。本実施の形態において、システム構成、提供サーバ１のハードウェア構成等は実施の形態１と同様である。

図３９は提案書作成処理の手順例を示すフローチャートである。ユーザは提案書の作成対象とするケースを選択する。例えば、対象企業ＤＢ１３３に基づいて作成した顧客企業の一覧から１つの顧客企業を選択する。選択情報はユーザ端末２から提供サーバ１へ送信される。制御部１１は選択された顧客企業に対応するケースＩＤを取得する（ステップＳ８１）。制御部１１は顧客企業が抱えていると予想されるテーマ及び問題・課題を取得する（ステップＳ８２）。制御部１１はケースＩＤをキーに検索履歴ＤＢ１３６を検索し、ヒットしたレコードのテーマ列の値、課題列に記憶してある課題番号を取得する。さらに、課題番号に対応した問題・課題を、課題類型ＤＢ１３４の課題列から取得する。制御部１１は事例を取得する（ステップＳ８３）。ユーザが閲覧した事例については、閲覧履歴ＤＢ１３Ｄの閲覧事例列に記憶してあるケースＩＤを取得し、当該ケースＩＤに対応付いた事例情報を事例ＤＢ１３７から取得する。閲覧履歴に加えて、ブックマークしている事例を取得してもよい。ブックマークＤＢ１３ＥのケースＩＤ列に記憶してあるケースＩＤを取得し、当該ケースＩＤに対応付いた事例情報を事例ＤＢ１３７から取得する。制御部１１は取得した事例をユーザ端末２へ送信し、ユーザ端末２は取得した事例を表示する。ユーザは提案書に含める事例を選択する。事例の選択情報はユーザ端末２から提供サーバ１へ送信される。制御部１１は事例の選択情報を取得する（ステップＳ８４）。制御部１１は選択された事例に対応した商材及び業者の情報を取得する（ステップＳ８５）。制御部１１はケースＩＤを検索キーにして商材実績ＤＢ１３Ａを検索し、各事例で採用された商材の商材ＩＤを取得する。取得した商材ＩＤを検索キーに商材ＤＢ１３９を検索し、商材の情報を取得する。また、制御部１１は事例情報に対応した業者ＩＤを検索キーに業者ＤＢ１３Ｆを検索し、業者の情報を取得する。制御部１１は上記で取得した情報を元に提案書を作成する（ステップＳ８６）。提案書は例えばＰＤＦ形式とする。制御部１１は作成した提案書を出力し（ステップＳ８７）、処理を終了する。

図２０で示したステップＳ１４とステップＳ１５との間で提案書を提案書作成処理により、作成することが可能である。すなわち、ユーザは、検索結果として得た事例の一覧から、顧客企業に適合しそうな事例を選択し、詳細を確認する。ユーザは事例の詳細情報を確認し、顧客企業に適合する事例を選択する。ユーザは選択した事例に基づく提案書の作成を指示する。図３９のステップＳ８５以降が実行され、提案書が作成される。

図４０及び図４１は提案書の例を示す説明図である。図４０Ａは表紙ページの例を示す。表紙ページは宛名４０１、ロゴ４０２及びタイトル４０３を含む。タイトル４０３は選択した事例等に基づき作成する。または、ユーザの入力による。宛名４０１はケースの対象となっている顧客企業の名称が入力される。当該名称は対象企業ＤＢ１３３の企業名列から取得する。ロゴ４０２はユーザ企業のロゴマークである。ロゴマークは例えばユーザ企業ＤＢ１３２に記憶しておく。図４０Ｂは問題・課題の表示ページである。当該ページは、顧客企業が抱えていると予想される経営課題のテーマ、問題及び課題をノードで示し、互いの関係をリンクで表現したグラフ図４０４を含む。グラフ図４０４は事例を検索する際に指定した問題・課題や、選択した事例に基づき作成される。図４０Ｃは解決事例ページの例を示す。例えば、ユーザが選択した課題が３つであり、各課題についての事例が１つずつ選択したのであれば、解決事例ページは３つの事例を含む。解決事例ページに記載される内容は、図２７及び図２８に示した事例詳細画面ｄ０４の表示内容と同様である。図４１Ａは企業・商品の紹介ページである。選択した事例に対応付けられた商品の情報や、事例を登録した業者の情報が表示される。図４１Ｂはその他ページの例を示す。その他ページは事例に対応付いた補足情報が記載される。提案書のフォーマットはユーザ企業毎に用意され、ユーザの所属するユーザ企業のフォーマットを制御部１１は選択して、提案書を作成する。

本実施の形態においては、提案書作成に不慣れなユーザであっても、顧客企業向けの提案書を簡単かつ迅速に作成可能である。

（実施の形態５）
上述したように、商材ＤＢ１３９が記憶する商材については、ユーザ企業が販売代理店となることを希望すれば、業者の承認なく、提供システム１００が販売代理権を付与する仕組みとなっている。本実施の形態は当該業務を支援する機能に関する。当該機能は、上述の実施の形態１から４に追加されるものである。本実施の形態において、システム構成、提供サーバ１のハードウェア構成等は実施の形態１と同様である。

提供システム１００の運営会社（管理者）は、商材を販売する業者と包括的な販売契約を行い、提供システム１００のユーザであれば、運営会社は業者の許可なく、ユーザに商材の販売代理権を付与できるものとする。業者は対象とする商材を商材ＤＢ１３９に登録する。

一方、ユーザは商材ＤＢ１３９に登録してある商材を提供システム１００で利用登録することで、顧客企業へ販売することが許可される。図４２は利用登録処理の手順例を示すフローチャートである。ユーザはユーザ端末２の表示部２６に表示された機能一覧から商材の利用登録を選択する。ユーザ端末２の制御部２１は商材一覧要求を提供サーバ１へ送信する（ステップＳ１０１）。提供サーバ１の制御部１１は商材一覧要求を受信する（ステップＳ１０２）。制御部１１は一覧を作成し、ユーザ端末２へ送信する（ステップＳ１０３）。ユーザ端末２の制御部２１は一覧を受信し、表示部２６に表示する（ステップＳ１０４）。ユーザは一覧から登録したい商材を選択する。制御部２１は選択情報を取得し、提供サーバ１へ送信する（ステップＳ１０５）。提供サーバ１の制御部１１は選択情報を受信する（ステップＳ１０６）。制御部１１は選択された商材の詳細画面を作成し、ユーザ端末２へ送信する（ステップＳ１０７）。ユーザ端末２の制御部２１は詳細画面を受信し、表示部２６に表示する（ステップＳ１０８）。ユーザ端末２は処理を選択する。制御部２１は選択された処理が登録であるか否かを判定する（ステップＳ１０９）。制御部２１は選択された処理が登録であると判定した場合（ステップＳ１０９でＹＥＳ）、登録要求を提供サーバ１へ送信する（ステップＳ１１０）。提供サーバ１の制御部１１は登録要求を受信する（ステップＳ１１１）。制御部１１は登録を行う（ステップＳ１１２）。制御部１１はユーザＩＤに対応付いている企業ＩＤと、選択されている商材の商材ＩＤとを対応付けて、登録商材ＤＢ１３Ｃに記憶する。制御部１１は登録完了をユーザ端末２へ送信する（ステップＳ１１３）。ユーザ端末２は完了を受信し、表示部２６に表示した（ステップＳ１１４）後に、処理を終了する。制御部２１は選択された処理が登録であると判定しなかった場合（ステップＳ１０９でＮＯ）、選択された処理が戻るであるか否かを判定する（ステップＳ１１５）。制御部１１は選択された処理が戻るであると判定した場合（ステップＳ１１５でＹＥＳ）、処理をステップＳ１０１へ戻す。制御部１１は選択された処理が戻るでないと判定した場合（ステップＳ１１５でＮＯ）、処理を終了する。

図４３は商材一覧画面の例を示す説明図である。商材一覧画面ｄ０７は図４２のステップＳ１０４で表示される画面である。商材一覧画面ｄ０７は商材画像ｄ０７１、商品概要ｄ０７２及び属性アイコンｄ０７３並びに切替タブｄ０７４を含む。商材画像ｄ０７１は商材のロゴ画像等である。商品概要ｄ０７２は商材の名称、評価、利用者数を含む。属性アイコンｄ０７３は商材の属性を表すアイコンを含む。属性は価格、機能、ユーザ層などである。切替タブｄ０７４は商材グループを切り替えるためのタブである。グループは、おすすめ、ランキング、カテゴリ、高収益、新着などである。

図４４は商材詳細画面の例を示す説明図である。商材詳細画面ｄ０８は図４２のステップＳ１０８で表示される画面である。商材詳細画面ｄ０８は商材画像ｄ０８１、商材概要ｄ０８２、動画ｄ０８３、詳細説明ｄ０８４、登録ボタンｄ０８５及び戻るボタンｄ０８６を含む。商材画像ｄ０８１は商材のロゴ画像等である。商材概要ｄ０８２は商材の名称、評価、利用者数を含む。動画ｄ０８３は商材を紹介する動画である。詳細説明ｄ０８４は商材の説明文章である。登録ボタンｄ０８５を選択すると、登録の指示が送信される。戻るボタンｄ０８６を選択すると、商材一覧画面ｄ０７へ戻る。

本実施の形態にあっては、ユーザは契約手続の手間を掛けることなく、新たな商材の販売代理権を習得することが可能となる。

（実施の形態６）
上述の実施の形態では、提供システムのユーザは顧客企業に提案を行う金融機関の行員を想定していたが、それに限らず顧客企業の社員、業者の社員等をユーザに含めてもよい。本実施の形態において、システム構成、提供サーバ１のハードウェア構成等は実施の形態１と同様である。以下、金融機関の行員を銀行ユーザ、顧客企業の社員等を企業ユーザ、業者の社員等を業者ユーザと呼ぶ。銀行ユーザ、企業ユーザ及び業者ユーザの情報は、ユーザＤＢ１３１に記憶する。ユーザＤＢ１３１に例えば、種別列を追加し、種別列の値で銀行ユーザ、企業ユーザ又は業者ユーザの区別が行えるようにする。また、顧客企業、業者についての情報はユーザ企業ＤＢ１３２に記憶する。それに伴い列を追加し、記憶できるデータ項目を増やしてもよい。例えば、ユーザ企業ＤＢ１３２に、顧客企業を担当する金融機関の銀行ユーザのユーザＩＤを記憶してもよい。

本実施の形態は、企業ユーザの閲覧履歴が所定の条件を満たす場合、銀行ユーザへ通知を行う形態に関する。企業ユーザの閲覧履歴から、顧客企業が抱えている問題・課題が浮き彫りになった場合に、当該企業を担当する銀行ユーザに通知する。企業ユーザが特定の問題・課題に対する検索を行っている場合、当該問題・課題を企業が抱えている可能性が高いと想定する。また、企業ユーザが特定の事例を短期間に繰り返し参照している場合、事例と同じ問題・課題を抱え、同様な解決手段を求めている可能性が高いと想定する。

図４５は通知ポイントＤＢの例を示す説明図である。通知ポイントＤＢ１３Ｈは閲覧履歴を点数化するための情報を記憶する。通知ポイントＤＢ１３Ｈは条件列及びポイント列を含む。条件列はポイントを付与する条件を記憶する。ポイント列は閲覧履歴が条件にマッチした場合に付与するポイントを記憶する。

図４６は通知処理の手順例を示すフローチャートである。通知処理はバッチ処理等により繰り返し実行する。提供サーバ１の制御部１１は処理対象とする企業を選択する（ステップＳ１３１）。制御部１１は企業に所属する企業ユーザの閲覧履歴を取得する（ステップＳ１３２）。制御部１１は通知ポイントＤＢ１３Ｈと閲覧履歴とを対照し、通知ポイントＤＢ１３Ｈの条件列に適合する履歴に基づき、事例毎にポイントを合算したスコア算出する（ステップＳ１３３）。制御部１１はスコアが閾値を超えているか否かを判定する（ステップＳ１３４）。閾値は予め設定しておく。制御部１１はスコアが閾値を超えていると判定した場合（ステップＳ１３４でＹＥＳ）、アラートを送信する（ステップＳ１３５）。アラートは例えば電子メールよる通知である。電子メールの宛先は企業を担当する銀行ユーザである。企業と銀行ユーザとの対応関係は、ユーザ企業ＤＢ１３２に予め記憶しておく。担当する銀行ユーザの電子メールアドレスはユーザＤＢ１３１のメールアドレス列から取得する。制御部１１はスコアが閾値を超えていないと判定した場合（ステップＳ１３４でＮＯ）、処理をステップＳ１３６へ移す。制御部１１は未処理の企業があるか否かを判定する（ステップＳ１３６）。制御部１１は未処理の企業があると判定した場合（ステップＳ１３６でＹＥＳ）、処理をステップＳ１３１へ戻し、未処理の企業に対する処理を行う。制御部１１は未処理の企業がないと判定した場合（ステップＳ１３６でＮＯ）、処理を終了する。

本実施の形態においては、企業ユーザの閲覧履歴から、顧客企業が抱えている問題・課題が浮き彫りになった場合に、当該企業を担当する銀行ユーザに通知するので、銀行ユーザは通知に基づき、顧客企業への提案を行うことが可能となる。

（実施の形態７）
本実施の形態は顧客企業へのアンケートを行う形態に関する。本実施の形態において、システム構成、提供サーバ１のハードウェア構成等は実施の形態１と同様である。以下の説明において、企業端末は上述のユーザ端末２と同様である。

図４７はアンケート収集処理の手順例を示すフローチャートである。アンケート収集処理はバッチ処理により、繰り返し実行する。または、各ケースのステータスを管理している依頼ＤＢ１３８が更新されたら実行する。提供サーバ１の制御部１１は完了ケースがあるか否かを判定する（ステップＳ１５１）。制御部１１は依頼ＤＢ１３８を検索し、ステータスが完了となっているケースがあるか否かを判定する。例えば、ステータス列の値が「完了」であるケースである。制御部１１は完了ケースがないと判定した場合（ステップＳ１５１でＮＯ）、処理を終了する。制御部１１は完了ケースがあると判定した場合（ステップＳ１５１でＹＥＳ）、依頼メールを企業端末宛に送信する（ステップＳ１５２）。企業端末は依頼メールを受信する（ステップＳ１５３）。依頼メールを読んだ企業ユーザは作業を開始する。企業端末はアンケート画面の要求を提供サーバ１へ送信する（ステップＳ１５４）。登録画面の要求は例えばＨＴＴＰリクエストである。提供サーバ１の制御部１１は要求を受信する（ステップＳ１５５）。制御部１１はアンケート画面を生成し企業端末へ送信する（ステップＳ１５６）。企業端末はアンケート画面を受信し、表示部に表示する（ステップＳ１５７）。企業ユーザはアンケート画面に表示された質問を読み、回答を入力し、送信を指示する。企業端末は回答を受け付け、提供サーバ１へ送信する（ステップＳ１５８）。提供サーバ１の制御部１１は回答を受信し、補助記憶部１３に記憶する（ステップＳ１５９）。制御部１１はケースのステータスを更新する（ステップＳ１６０）。ステータスが「完了」であれば、「完了・アンケート済」とする。ステータスが「登録済」であれば、「登録済・アンケート済」とする。それに伴い、事例登録処理のステップＳ４０の処理内容を適宜変更する。制御部１１はアンケート結果に基づき、業者の評価、商材の評価、参照された事例の評価等を更新し（ステップＳ１６１）、処理を終了する。

アンケートにより収集する項目としては、ＮＰＳ（登録商標）（Net Promoter Score）、満足度、改善点、現在困っていること等である。ＮＰＳは、コンサルティングを受けた業者に対して、どれくらいの愛着や信頼があるかを数値化する指標である。ＮＰＳは、「今回、コンサルティングを受けた業者や購入した商材を同僚や他部署に薦めたいと考えますか？０〜１０の１１段階でお答えください。」、「その理由を教えてください。」等の質問により、他者への推奨度を数値化した指標である。満足度はコンサルティングの満足度や購入した商材に対する満足度である。改善点はコンサルティングや商材に対して改善すべき点である。現在困っていることはコンサルティング受けた後、商材を購入した後に新たなに発生又は気づいた業務上の問題である。購入した商材に対する評価については数値評価（５点満点で何点か）を収集してもよい。

（管理画面）
次に提供システム１００の管理機能について説明する。管理機能はユーザ種別により異なる。図４８及び図４９は管理画面の例を示す説明図である。図４８Ａは企業ユーザ向けの管理画面の例を示す。管理画面ｄ０９はメニュー一覧ｄ０９１及び戻るボタンｄ０９２を含む。メニュー一覧ｄ０９１に含むメニューは例えば、メニュー１「ビジネスマッチング案件管理」、メニュー２「お気に入り事例、商品管理」、メニュー３「キャンペーン等お知らせ」である。メニュー１は問題・課題を解決するための依頼を、業者に送信した案件を一覧表示したり、各案件の状況を確認したりする機能を提供するメニューである。メニュー２は事例のブックマークを参照したり、提供システム１００を介して購入した商品を参照したりする機能を提供するメニューである。メニュー３はキャンペーンのお知らせ等の提供システム１００からの通知を表示する機能を提供するメニューである。戻るボタンｄ０９２はホーム画面等に戻るためのボタンである。

図４８Ｂは銀行ユーザ向けの管理画面の例を示す。管理画面ｄ１０はメニュー一覧ｄ１０１及び戻るボタンｄ１０２を含む。メニュー一覧ｄ１０１に含むメニューは例えば、メニュー１「ビジネスマッチング実績集計、レポート作成」、メニュー２「ビジネスマッチングの傾向分析、予測」、メニュー３「ビジネスマッチング商品の追加」、メニュー４「ビジネスマッチングの案件管理」である。メニュー１は提供システム１００を利用して、ユーザ企業に業者を紹介した案件の実績を集計したり、実績についてのレポートを作成したりする機能を提供するメニューである。当該メニューにより、銀行ユーザは例えば、マッチング件数、閲覧履歴、売上高、手数料、満足度、ＮＰＳ、成約率、提案数、成約リードタイム、及び売れ筋等の指標を参照することが可能である。これらの指標は、行員別、エリア別、商材別に算出した値を参照することも可能である。メニュー２はビジネスマッチングの傾向分析、予測を提供するメニューである。ビジネスマッチングの傾向は、閲覧履歴から、成約した案件に多く引用されている事例の傾向等を分析する。予測機能は実施の形態３で述べた判定モデル１６を用いた顧客企業の問題・課題の予測である。メニュー３はビジネスマッチング商品を追加する機能を提供するメニューである。当該機能は、実施の形態５で述べた商材の利用登録機能である。メニュー４はビジネスマッチングの案件管理機能である。当該機能は、企業ユーザ向けの管理画面ｄ０９のメニュー１で提供する機能と同様である。戻るボタンｄ１０２はホーム画面等に戻るためのボタンである。

図４９Ａは業者ユーザ向けの管理画面の例を示す。管理画面ｄ１１はメニュー一覧ｄ１１１及び戻るボタンｄ１１２を含む。メニュー一覧ｄ１１１に含むメニューは例えば、メニュー１「ビジネスマッチング実績集計、レポート作成」、メニュー２「ビジネスマッチングの傾向分析、予測」、メニュー３「ビジネスマッチング商品の編集」、メニュー４「キャンペーン管理」、メニュー５「ビジネスマッチングの案件管理」、メニュー６「事例管理」である。メニュー１及びメニュー２で提供する機能は、銀行ユーザ向けの管理画面ｄ１０のメニュー１及びメニュー２で提案される機能と同様である。メニュー３は提供している商品の情報を編集する機能を提供する。メニュー４はコンサルティングや商品の販促などのキャンペーン情報の追加、編集等の機能を提供する。メニュー５で提供する機能は、銀行ユーザ向けの管理画面ｄ１０のメニュー４で提供する機能と同様である。メニュー６は業者が過去に担当した案件を事例として登録したり、登録した事例を修正したりする機能を提供する。戻るボタンｄ１１２はホーム画面等に戻るためのボタンである。

図４９Ｂは提供システム１００の運用者向けの管理画面の例を示す。管理画面ｄ１２はメニュー一覧ｄ１２１及び戻るボタンｄ１２２を含む。メニュー一覧ｄ１２１に含むメニューは例えば、メニュー１「ビジネスマッチング実績集計、レポート作成」、メニュー２「ビジネスマッチングの傾向分析、予測」、メニュー３「事例管理」、メニュー４「商品管理」である。メニュー１、メニュー２及びメニュー３で提供する機能は、業者ユーザ向けの管理画面ｄ１１のメニュー１、メニュー２及びメニュー６で提供する機能と同様である。戻るボタンｄ１２２はホーム画面等に戻るためのボタンである。なお、企業ユーザ、銀行ユーザ、業者ユーザ、運用者により、参照及び変更するデータの範囲は異なる。そのため、同様な機能であっても、各ユーザが扱えるデータの範囲は異なる。

（実施の形態８）
本実施の形態は教育機能に関する。提供システム１００を用いることにより、銀行ユーザや業者ユーザは顧客企業の問題・課題を予測し、当該問題・課題を解決した過去の事例を含む提案書を作成することが可能である。しかし、提案活動にはプレゼンテーションが必要なことが多い。プレゼンテーションの技能は、経験の蓄積により向上する。しかし、効果的なプレゼンテーションの例を見て学ぶことから、ある程度の技能向上は期待される。本実施の形態は、プレゼンテーションの技能向上を目指した教育機能に関する。より具体手には優秀な営業員のプレゼンテーションの内容が分かるシナリオを提供する。営業員とは銀行ユーザ又は業者ユーザであり、顧客企業においてプレゼンテーションを行う者である。

本実施の形態において、システムの全体構成は実施の形態１等と同様であるが、動画コンテンツを作成する際に、営業員が使用するユーザ端末２又は業者端末３に求められる構成が異なる。以下、営業員が使用するユーザ端末２又は業者端末３を営業員端末と呼ぶ。営業員端末はカメラやマイクを備えており、営業員がプレゼンテーションしている様子を動画として記憶可能としてある。それと同時に、プレゼンテーションで使用したスライド又はスライドを表示した画面を画像として時間データと対応付けて記憶することが可能である。

図５０はシナリオＤＢの例を示す説明図である。シナリオＤＢ１３Ｉは、過去に営業員が行ったプレゼンテーションについてのシナリオを記憶する。シナリオＤＢ１３Ｉは提供サーバ１の補助記憶部１３等に記憶する。シナリオＤＢ１３ＩはシナリオＩＤ列、ユーザＩＤ列、ケースＩＤ列、顧客企業ＩＤ列、番号列、配分列、利用画面列、トーク列及び音声列を含む。シナリオＩＤ列はシナリオを一意に特定可能なシナリオＩＤを記憶する。ユーザＩＤ列はプレゼンテーションを行ったユーザのユーザＩＤを記憶する。ケースＩＤ列はプレゼンテーションに対応するケースがある場合に当該ケースのケースＩＤを記憶する。顧客企業ＩＤ列はプレゼンテーションの対象となった顧客企業の企業ＩＤを記憶する。番号列はプレゼンテーションの場面を示す順番号を記憶する。配分列は各場面の所要時間を記憶する。利用画面列はプレゼンテーションに使用されたスライド画像を記憶する。利用画面列は画像データを保存するのではなく、画像データを記憶した画像ファイルのファイル名を記憶してもよい。トーク列はプレゼンテーションにおける営業員の音声をテキストに起こしたものを記憶する。音声列はプレゼンテーションにおける営業員の音声を記憶する。音声列は音声データを保存するのではなく、音声データを記憶した音声ファイルのファイル名を記憶してもよい。

図５１は共有設定ＤＢの例を示す説明図である。共有設定ＤＢ１３ＪはシナリオＤＢ１３Ｉに記憶しているシナリオの共有範囲、シナリオを参照できるユーザの条件を記憶する。共有設定ＤＢ１３Ｊは提供サーバ１の補助記憶部１３等に記憶する。共有設定ＤＢ１３ＪはシナリオＩＤ列、企業ＩＤ列、エリア列、支店列及びユーザＩＤ列を記憶する。シナリオＩＤ列はシナリオＩＤを記憶する。企業ＩＤ列はシナリオが参照可能な企業の企業ＩＤを記憶する。エリア列はシナリオが参照可能なエリアを記憶する。支店列はシナリオが参照可能な支店を記憶する。ユーザＩＤ列はシナリオが参照可能なユーザを記憶する。

共有設定ＤＢ１３Ｊの値設定は例えば次のように行う。所定企業の所属する全てのユーザがシナリオを参照可能とする場合、企業ＩＤ列の値を設定し、エリア列、支店列及びユーザＩＤ列には値を設定しない。所定企業の所定エリアに所在する支店所属のユーザがシナリオを参照可能とする場合、企業ＩＤ列及びエリア列の値を設定し、支店列及びユーザＩＤ列には値を設定しない。所定企業の所定の支店所属のユーザがシナリオを参照可能とする場合、企業ＩＤ列及び支店列の値を設定し、エリア列及びユーザＩＤ列には値を設定しない。所定企業の所定のユーザがシナリオを参照可能とする場合、企業ＩＤ列及びユーザＩＤ列の値を設定し、エリア列、支店列及びユーザＩＤ列には値を設定しない。

図５２はシナリオ表示画面の例を示す説明図である。シナリオ表示画面ｄ１３はシナリオＤＢ１３Ｉに記憶しているシナリオを表示する。シナリオ表示画面ｄ１３は時間配分領域ｄ１３１、画面表示領域ｄ１３２、テキスト表示領域ｄ１３３、音声提供領域ｄ１３４及び戻るボタンｄ１３５を含む。時間配分領域ｄ１３１は各場面における所要時間を表示する。画面表示領域ｄ１３２は各シーンで表示された画面を表示する。テキスト表示領域ｄ１３３は各シーンで営業員が話したことをテキスト化したものを表示する。音声提供領域ｄ１３４は各シーンで営業員が話した音声を提供する。各シーンに表示されているボタンを選択すると音声の再生が開始する。戻るボタンｄ１３５はホーム画面等に戻るためのボタンである。

本実施の形態においては、経験の浅い営業員に、効果的なプレゼンテーションの例を視聴できる動画シナリオを提供することで、プレゼンテーション技能の向上を図ることが可能となる。

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

１００ 提供システム
１ 提供サーバ
１１ 制御部
１２ 主記憶部
１３ 補助記憶部
１３１ ユーザＤＢ
１３２ ユーザ企業ＤＢ
１３３ 対象企業ＤＢ
１３４ 課題類型ＤＢ
１３５ 典型課題ＤＢ
１３６ 検索履歴ＤＢ
１３７ 事例ＤＢ
１３８ 依頼ＤＢ
１３９ 商材ＤＢ
１３Ａ 商材実績ＤＢ
１３Ｂ 商材評価ＤＢ
１３Ｃ 登録商材ＤＢ
１３Ｄ 閲覧履歴ＤＢ
１３Ｅ ブックマークＤＢ
１３Ｆ 業者ＤＢ
１３Ｇ 課題判定ＤＢ
１４ 通信部
１５ 読み取り部
１６ 判定モデル
１Ｐ 制御プログラム
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
２ ユーザ端末
２１ 制御部
２２ 主記憶部
２３ 補助記憶部
２４ 通信部
２５ 入力部
２６ 表示部
２Ｐ 制御プログラム
３ 業者端末
３１ 制御部
３２ 主記憶部
３３ 補助記憶部
３４ 通信部
３５ 入力部
３６ 表示部
４ 顧客端末

本発明に係るコンピュータプログラムは、企業の情報を取得し、前記企業の情報に基づき、問題・課題を記憶する記憶部を参照して前記企業の問題・課題を特定し、特定した前記問題・課題を出力し、特定した前記問題・課題、前記企業の情報に基づき、前記問題・課題に関連する事例を特定し、特定した前記事例を選択可能に一覧出力し、選択された前記事例の識別情報を含むマッチング依頼を受け付け、前記事例の識別情報に対応付けられた業者の識別情報を取得し、取得した前記業者の前記識別情報に対応付けられた送信先へ前記マッチング依頼を送信する処理をコンピュータに行わせることを特徴とする。

Claims (13)

1. 企業の情報を取得し、
   前記企業の情報に基づき、問題・課題を記憶する記憶部を参照して前記企業の問題・課題を特定し、
   特定した前記問題・課題を出力する
   処理をコンピュータに行わせることを特徴とするコンピュータプログラム。
2. 特定した前記問題・課題、前記企業の情報に基づき、前記問題・課題に関連する事例を特定し、
   特定した前記事例を選択可能に一覧出力する
   ことを特徴とする請求項１に記載のコンピュータプログラム。
3. 前記企業の情報は会計情報、ＰＯＳ情報及び人財情報に基づき、前記企業の問題・課題を特定する
   ことを特徴とする請求項１又は請求項２に記載のコンピュータプログラム。
4. 前記企業の会計情報及びＰＯＳ情報を含む定量データ、並びに、前記企業において送受信される電子メールを含む定性データを取得し、
   企業の定量データ及び定性データ並びに問題・課題を教師データにより学習した学習モデルに、取得した前記企業の定量データ及び定性データを入力し、
   前記学習モデルが出力した問題・課題を出力する
   ことを特徴とする請求項１から請求項３のいずれか１項に記載のコンピュータプログラム。
5. 前記事例を選択し、マッチング依頼又はブックマークへの登録指示を受け付ける
   ことを特徴とする請求項２に記載のコンピュータプログラム。
6. 前記マッチング依頼は、選択された前記事例の識別情報を含み、
   前記事例の識別情報に対応付けられた業者の識別情報を取得し、
   取得した前記業者の前記識別情報に対応付けられた送信先を取得し、
   取得した送信先へ前記マッチング依頼を送信する
   ことを特徴とする請求項５に記載のコンピュータプログラム。
7. 問題・課題と該問題・課題の解決策と業者の識別情報とを対応付けた事例を取得し、
   取得した事例を記憶する
   ことを特徴とする請求項２から請求項６のいずれか１項に記載のコンピュータプログラム。
8. 前記問題・課題と、該問題・課題に対応付けられた前記事例の閲覧履歴とに基づいて、前記問題・課題と前記事例とを含む提案書を作成する
   ことを特徴とする請求項２から請求項７のいずれか１項に記載のコンピュータプログラム。
9. 前記企業のユーザが閲覧した前記事例についての閲覧履歴に基づいて、前記ユーザに関する前記事例についてのスコアを算出し、
   算出したスコアが所定の閾値を超えた場合に、前記企業と対応付けられた他の企業のユーザへ通知を送信する
   ことを特徴とする請求項２から請求項７のいずれか１項に記載のコンピュータプログラム。
10. 管理者が販売代理権を有し、前記問題・課題又は前記事例と対応付けられた商材の識別情報と、該商材の販売を希望する金融機関の識別情報とを取得し、
    取得した商材の識別情報と金融機関の識別情報とを対応付けて記憶する
    ことを特徴とする請求項２から請求項７のいずれか１項に記載のコンピュータプログラム。
11. 記憶部にアクセス可能なコンピュータが、
    企業の情報を取得し、
    前記企業の情報に基づき、問題・課題を記憶する前記記憶部を参照して前記企業の問題・課題を特定し、
    特定した前記問題・課題を出力する
    処理を行うことを特徴とする出力方法。
12. 企業の情報を取得する取得部と、
    前記企業の情報に基づき、問題・課題を記憶する記憶部を参照して前記企業の問題・課題を特定する特定部と、
    特定した前記問題・課題を出力する出力部と
    を備えることを特徴とする出力装置。
13. 企業の情報を受け付け、
    受け付けた前記企業の情報を送信し、
    前記企業の情報に基づき特定された前記企業の問題・課題を受信し、
    取得した前記問題・課題を表示する
    処理をコンピュータに行わせることを特徴とする表示プログラム。

Images