JP7453644B2 - 情報処理装置およびプログラム - Google Patents

Description

本発明は、対話サービスにおける応対者の割り当てを支援する技術に関する。

たとえば外部のコンサルタント会社が、依頼主である企業の従業員に対する意識調査やアドバイスを対話で行う場合、コンサルタント会社の応対者（以下、メンターという。）と従業員の相性が重要になる。信頼できる相手でなければ、従業員は本心を打ち明けにくいからである。

コンサルタント会社が複数のメンターを用意している場合、各従業員にいずれかのメンターを割り振ることになる。このとき、従業員と相性が悪いメンターが割り振られると、その従業員に関して意識調査やアドバイスを円滑に行えない恐れがある。

特開平１０－６５８２１号公報 特開２００４－２８０１５８号公報 特開２００７－６０２２５号公報

しかし、従業員と相性が良いメンターを推測することは難しい面がある。対話サービスを行う前に、従業員の性格や思考など内面を推し量れないので、どのようなタイプのメンターと心が通じるかを予想できない。尚、この例におけるメンターは、対話サービスを提供可能な応対者の例であり、従業員は応対者との対話サービスを利用する利用者の例である。

本発明は、上記課題認識に基づいて完成された発明であり、その主たる目的は、対話サービスの利用者に適した応対者を選定しやすくすることである。

本発明のある態様における情報処理装置は、対話サービスを提供可能な応対者の属性情報を取得する第１取得部と、応対者との対話サービスを利用した第１利用者の属性情報を取得する第２取得部と、応対者が第１利用者へ提供した対話サービスの実績としての評価値である実績評価値を取得する第３取得部と、第１利用者の属性情報と応対者の属性情報を入力変数とし、実績評価値を出力変数とする学習モデルを生成させる学習モデル生成部と、対話サービスを利用予定の第２利用者の属性情報と応対者の属性情報を学習モデルの入力変数とすることにより、第２利用者と応対者との対話サービスに関して予測される評価値として予測評価値を算出する予測評価値算出部と、を備える。

本発明によれば、対話サービスの利用者に適した応対者を選定しやすくなる。

コンサルティングサービスの手順を示すフローチャート図である。 情報処理装置の機能ブロック図である。 メンター属性情報記憶部のデータ構造図である。 従業員属性情報記憶部のデータ構造図である。 対話管理情報記憶部のデータ構造図である。 教師データ記憶部のデータ構造図である。 教師データの準備フェーズにおける手順を示すフローチャート図である。 学習モデルの生成フェーズにおける処理過程を示すフローチャート図である。 適用データの準備フェーズにおける手順を示すフローチャート図である。 従業員属性情報記憶部のデータ構造図である。 学習モデルの利用フェーズにおける処理過程を示すフローチャート図である。 予測評価値情報記憶部のデータ構造図である。 メンターの推薦フェーズにおける処理過程を示すフローチャート図である。 変形例１のメンターの推薦フェーズにおける処理過程を示すフローチャート図である。 変形例２のメンターの推薦フェーズにおける処理過程を示すフローチャート図である。 変形例３のメンターの推薦フェーズにおける処理過程を示すフローチャート図である。 変形例４のメンターの推薦フェーズにおける処理過程を示すフローチャート図である。 変形例５のメンターの推薦フェーズにおける処理過程を示すフローチャート図である。

本実施形態では、企業が第三者のコンサルティングサービスを利用して、従業員に関する調査や助言を受けることを想定する。以下に、企業における問題点、コンサルティングサービスおよびメンターの選定などについて概要を説明する。

［企業における問題点］
企業において業務が円滑に遂行されるためには、従業員の能力が十分に発揮されることが望ましい。実際には、職場において従業員の能力が十分に発揮されているとは限らない。例えば、従業員と上司との間にコミュニケーションギャップが存在すると、お互いの意図を汲み取れずに行き違いが生じることがある。また、従業員のやる気に影響することがある。

経営者がこのような職場の状況まで把握することは、困難である。上司からの報告は、実態に即しているとは限らないからである。そのため、経営者が第三者のコンサルティング会社に依頼し、職場の状況を把握することを想定する。コンサルティング会社に所属するメンターが従業員から聞き取りを行って従業員自身に振り返りを促すとともに、従業員の現状についてレポートするコンサルティングサービスを提供する。コンサルティングサービスを利用すれば、経営者が上司から職場に関する報告を受ける場合のように偏向が生じる心配がないので、経営者は客観的な判断をしやすい。

［コンサルティングサービス］
例えば、６か月のサービス期間が設定され、メンターは１月に１回従業員から聞き取りと相談を行う。この聞き取りと相談は、電話による対話で行われる。サービス期間中、従業員に対して同じメンターが対応するものとする。

［従業員とメンターの相性］
従業員が外部のメンターに、現状を伝え、悩みを打ち明けるためには、信頼関係が重要である。メンターは、サービス期間に行われる６回の対話で担当する従業員と信頼関係を築き、本心を聞き出すように努める。この場合、従業員とメンターの相性が重要になる。メンターの人間性によって、信頼を感じやすい場合と信頼を感じにくい場合がある。信頼を感じにくいタイプのメンターが担当になると、従業員が心を開くことなくサービス期間を終えることになるかも知れない。したがって、コンサルティング会社としては、所属するメンターのうち、どのメンターを各従業員に割り当てるかが重要になる。

［人工知能の活用］
本実施形態では、人工知能を活用して、従業員の属性情報（以下、従業員属性情報ということがある。）とメンターの属性情報（以下、メンター属性情報ということがある。）に応じて適性の高い組み合わせを割り出すようにする。つまり、従業員とメンターとの対話の実績に基づいて、従業員とメンターの相性を判断する学習モデルを生成する。この例では、従業員属性情報とメンター属性情報を入力変数とし、従業員とメンターとの対話に関する評価値を出力変数とする学習モデルを想定する。ここでいう「評価値」とは、対話サービスに対する従業員の満足度を示す数値である。以下、実際の対話の結果に基づいて従業員が自己申告する評価値を「実績評価値」、対話の前に後述の方法により学習モデルが予測する評価値を「予測評価値」とよぶ。また、特に区別しないときには単に「評価値」とよぶ。対話前の従業員とメンターの組み合わせに対して学習モデルから高い予測評価値が出力されれば、その従業員とメンターによる対話は好結果になると予想される。また、対話前の従業員とメンターの組み合わせに対する予測評価値が低いときには、この２人の組み合わせによる対話は避けた方がよいと判断できる。

本実施形態における学習モデルに関わる処理は、学習モデルを生成する「学習フェーズ」と学習モデルを利用する「適用フェーズ」に大別できる。学習フェーズでは、実際に行われた対話に関して、従業員属性情報とメンター属性情報を入力変数とし、対話の実績評価値を出力変数とするサンプルの集合を教師データとする。この教師データを用いて学習を行ない、学習モデルを得る。適用フェーズでは、これから行うコンサルティングサービスにおいて聞き取りと相談の対象となる従業員の属性情報と候補のメンターの属性情報を入力変数に設定し、学習モデルに適用すると、その従業員とメンターとが対話を行ったと想定した場合の予測評価値が出力される。したがって、事前に高い予測評価値が得られるメンターを選んで、従業員に割り当てることができるようになる。

以上のように、複数の従業員と複数のメンターによる対話とその結果として得られる実績評価値を教師データとすることにより学習モデルを生成する。次に、対話前の従業員とメンターの組み合わせに対して学習モデルにより予測評価値を計算することにより、この２人の組み合わせが適切であるか否かを対話前に予測する。本実施形態においては、予測評価値に基づいて従業員ごとに適切なメンターを割り当てる。

［データの収集］
従業員属性情報として、従業員のプロフィールと従業員の特性とを用いる。従業員のプロフィールは、企業から提供される年齢、性別や職歴など従業員の社会的属性を示すデータである。従業員の特性は、従業員に対する意識アンケートによって判定される。そのため、コンサルティング会社は、メンターの割り当てを行う前に各従業員に対して意識アンケートを行う。コンサルティング会社は、そのアンケート結果に基づいて、従業員の特性を判定する。従業員の特性項目は、たとえば健康度、幸福感、適応度、貢献感、成長性、プレッシャー感および惰性感である。従業員の特性はアンケートによって得られる従業員の身体的・心理的傾向を示すデータである。さまざまな質問項目から健康度等のパラメータを算出するためのアンケートは、既知のアンケート手法を応用すればよい。たとえば、
このような意識アンケートとして、世界保健機関などの公的機関や大学などがさまざまなアンケート手法を公開している。

健康度は、従業員の健康状態に関する身体的特性の例である。健康度に関する「毎朝、すっきり起きられますか。」という質問に対してＹＥＳと回答すれば、健康度が高いと判定される。逆に、ＮＯと回答すれば、健康度が低いと判定される。このように、所定数（たとえば１０）の健康度に関する質問を行い、健康度が高いと判定された回答数の偏差値によって健康度のレベルを表す。

幸福感、適応度、貢献感および成長性は、従業員の心理状態に関するポジティブな心理的特性の例である。幸福感に関する「自分の人生に満足していますか。」という質問に対してＹＥＳと回答すれば、幸福感が強いと判定される。逆に、ＮＯと回答すれば、幸福感が弱いと判定される。健康度の場合と同様に所定数の幸福感に関する質問を行い、幸福感が強いと判定された回答数の偏差値によって幸福感のレベルを表す。適応度に関する「新しい仕事を苦にしないですか。」という質問に対してＹＥＳと回答すれば、適応度が高いと判定される。逆に、ＮＯと回答すれば、適応度が低いと判定される。同様に所定数の適応度に関する質問を行い、適応度が高いと判定された回答数の偏差値によって適応度のレベルを表す。貢献感に関する「お客様に喜んでもらえていますか。」という質問に対してＹＥＳと回答すれば、貢献感が強いと判定される。逆に、ＮＯと回答すれば、貢献感が弱いと判定される。同様に所定数の貢献感に関する質問を行い、貢献感が強いと判定された回答数の偏差値によって貢献感のレベルを表す。成長性に関する「何かスキルアップを図っていますか。」という質問に対してＹＥＳと回答すれば、成長性が強いと判定される。逆に、ＮＯと回答すれば、成長性が弱いと判定される。同様に所定数の成長性に関する質問を行い、成長性が強いと判定された回答数の偏差値によって成長性のレベルを表す。

プレッシャー感および惰性感は、従業員の心理状態に関するネガティブな心理的特性の例である。プレッシャー感に関する「自分が頑張るしかないと思いますか。」という質問に対してＹＥＳと回答すれば、プレッシャー感が強いと判定される。逆に、ＮＯと回答すれば、プレッシャー感が弱いと判定される。同様に所定数のプレッシャー感に関する質問を行い、プレッシャー感が強いと判定された回答数の偏差値によってプレッシャー感のレベルを表す。惰性感に関する「今までのやり方であれば問題ないと思いますか。」という質問に対してＹＥＳと回答すれば、惰性感が強いと判定される。逆に、ＮＯと回答すれば、惰性感が弱いと判定される。同様に所定数の惰性感に関する質問を行い、惰性感が強いと判定された回答数の偏差値によって惰性感のレベルを表す。

健康度、幸福感、適応度、貢献感および成長性については、レベルが高い方が健全な状態であることを示す。プレッシャー感および惰性感については、レベルが低い方が健全な状態であることを示す。

メンター属性情報として、メンターのプロフィールとメンターの特性とを用いる。メンターのプロフィールは、コンサルティング会社にて管理されている年齢、性別や職歴などに関するデータである。メンターの特性は、従業員の場合と同様に、意識アンケートによって判定される。特性項目は、従業員の場合と同様である。

従業員とメンターとの対話に関する評価値は、対話の後に従業員が決定し報告するものとする。対話に関する評価値は、たとえば１０段階のレベルで表す。レベルが高い方が、対話における従業員の充実感が強かったことを示す。以上で、概要の説明を終える。

図１は、コンサルティングサービスの手順を示すフローチャート図である。
上述したように、学習モデルに関わる処理は、学習フェーズと適用フェーズに大別される。Ｓ１０（準備フェーズ）およびＳ１２（生成フェーズ）が学習フェーズに対応し、Ｓ１４からＳ１８までが適用フェーズに対応する。教師データの準備フェーズでは、上述した教師データを準備する（Ｓ１０）。学習モデルの生成フェーズでは、教師データを用いて学習エンジンに学習モデルを生成させる（Ｓ１２）。ここまでが、学習エンジンを生成する準備段階である。

ここからは、学習エンジンを利用する実用段階（適用フェーズ）である。準備段階と実用段階は連続するとは限らない。準備段階を終えてしばらく待機してから実用段階に移ることもある。適用フェーズでは、新たにコンサルティングサービスを利用する企業の従業員に関する従業員属性情報を取得する（Ｓ１４）。次に、従業員とメンターの組み合わせ毎に、従業員属性情報とメンター属性情報を学習モデルに入力して、予測評価値を得る（Ｓ１６）。続いて、予測評価値に基づいて、各従業員について推薦するメンターを選定する（Ｓ１８）。各フェーズの詳細については、後述する。

図２は、情報処理装置１００の機能ブロック図である。
自然言語処理装置１００の各構成要素は、ＣＰＵ（Central Processing Unit）および各種コプロセッサなどの演算器、メモリやストレージといった記憶装置、それらを連結する通信線を含むハードウェアと、記憶装置に格納され、演算器に処理命令を供給するソフトウェアによって実現される。コンピュータプログラムは、デバイスドライバ、オペレーティングシステム、それらの上位層に位置する各種アプリケーションプログラム、また、これらのプログラムに共通機能を提供するライブラリによって構成されてもよい。以下に説明する各ブロックは、ハードウェア単位の構成ではなく、機能単位のブロックを示している。

情報処理装置１００は、インターフェース処理部１０２、データ処理部１０４およびデータ格納部１０６を含む。
インターフェース処理部１０２は、キーボードやマウスなどを介してユーザからの操作を受け付けるほか、画像表示や音声出力など、ユーザインターフェースに関する処理を担当する。インターフェース処理部１０２は、さらにネットワークを介する通信や記憶媒体に関するインターフェース処理を担当してもよい。データ処理部１０４は、インターフェース処理部１０２により取得されたデータ、データ格納部１０６に格納されているデータに基づいて各種処理を実行する。データ処理部１０４は、インターフェース処理部１０２およびデータ格納部１０６のインターフェースとしても機能する。データ格納部１０６は各種データを格納する。

インターフェース処理部１０２は、データ入力を受け付ける入力部１１０と、リストのような文字情報のほか、画像や音声等の各種情報を出力する出力部１２０を含む。
入力部１１０は、メンター属性情報取得部１１２、従業員属性情報取得部１１４、予定受付部１１６および報告受付部１１８を含む。メンター属性情報取得部１１２は、メンター属性情報を取得する。従業員属性情報取得部１１４は、従業員属性情報を取得する。予定受付部１１６は、メンターと従業員の対話の予定を受け付ける。報告受付部１１８は、従業員から対話の報告を受け付ける。

出力部１２０は、推薦リスト出力部１２２を含む。推薦リスト出力部１２２は、新たにコンサルティングサービスを利用する企業の各従業員に対して推薦するメンターのリストを出力する。

データ処理部１０４は、教師データ生成部１４０、学習モデル生成部１４２、学習エンジン１４４、予測評価値算出部１４６、学習モデル利用部１４８および推薦メンター選定部１５０を含む。
教師データ生成部１４０は、教師データを生成する。学習モデル生成部１４２は、学習エンジン１４４を用いて学習モデルを生成する。学習モデルの種類は任意であるが、たとえば決定木やニューラルネットワークである。学習モデルが決定木であれば、入力変数である従業員属性情報およびメンター属性情報の各指標が分岐条件として用いられる木構造の判断手順が生成される。木構造の末端には、出力変数である実績評価値が設定される。決定木を利用する場合には、適用データとして用意された入力変数の従業員属性情報およびメンター属性情報の各指標に従って分岐条件の判断を繰り返して末端まで辿れば、出力変数として予測評価値が得られる。また、学習モデルがニューラルネットワークであれば、入力変数である従業員属性情報およびメンター属性情報の各指標に対応する入力ノードと、出力変数である実績評価値に対応する出力ノードと、中間ノードとを備えたニューラルネットワークを使って、ノード間の連結の強さを示す重みデータを生成する。ニューラルネットワークを利用する場合には、適用データとして用意された入力変数の従業員属性情報およびメンター属性情報の各指標の値を、その指標に対応する入力ノードに設定して、重みデータに基づいて出力ノードで得られる予測評価値を求めることになる。

予測評価値算出部１４６は、学習モデルを用いて予測される評価値を算出する。学習モデル利用部１４８は、入力変数を設定して学習モデルを利用し、出力変数を得る。推薦メンター選定部１５０は、従業員毎に推薦するメンターを選定する。

データ格納部１０６は、メンター属性情報記憶部１６０、従業員属性情報記憶部１６２、対話管理情報記憶部１６４、教師データ記憶部１６６、学習モデル記憶部１６８、予測評価値情報記憶部１７０および推薦リスト記憶部１７２を含む。
メンター属性情報記憶部１６０は、コンサルティング会社に所属するメンターの属性情報を記憶する。メンター属性情報記憶部１６０の詳細については、図３に関連して後述する。従業員属性情報記憶部１６２は、コンサルティングサービスを利用する企業の従業員の属性情報を記憶する。従業員属性情報記憶部１６２の詳細については、図４に関連して後述する。対話管理情報記憶部１６４は、対話を管理する情報を記憶する。対話管理情報記憶部１６４の詳細については、図５に関連して後述する。教師データ記憶部１６６は、教師データを記憶する。教師データ記憶部１６６の詳細については、図６に関連して後述する。学習モデル記憶部１６８は、学習モデルを記憶する。予測評価値情報記憶部１７０は、予測評価値の情報を記憶する。予測評価値情報記憶部１７０の詳細については、図１２に関連して後述する。推薦リスト記憶部１７２は、推薦リストを記憶する。

図３は、メンター属性情報記憶部１６０のデータ構造図である。
コンサルタント会社に所属するメンター毎にレコードが設けられる。レコードには、メンターＩＤに対応づけて、健康度、幸福感、適応度、貢献感、成長性、プレッシャー感、惰性感、年齢および性別などの属性値が設定される。第１レコードは、メンターＩＤのＭ００１で識別されるメンターの健康度のレベルが５８であり、幸福感のレベルが６５であり、適応度のレベルが５３であり、貢献感のレベルが５８であり、成長性のレベルが５３であり、プレッシャー感のレベルが４７であり、さらに惰性感のレベルが４３であることを示している。また、このメンターの年齢は、３８歳であり、性別は、女性であることを示している。

図４は、従業員属性情報記憶部１６２のデータ構造図である。
コンサルタントサービスを利用する企業の従業員毎にレコードが設けられる。レコードには、従業員ＩＤに対応づけて、健康度、幸福感、適応度、貢献感、成長性、プレッシャー感、惰性感、年齢および性別などの属性値が設定される。第１レコードは、従業員ＩＤのＥ００１で識別される従業員の健康度のレベルが５０であり、幸福感のレベルが５３であり、適応度のレベルが４７であり、貢献感のレベルが５３であり、成長性のレベルが４７であり、プレッシャー感のレベルが５０であり、さらに惰性感のレベルが４７であることを示している。また、この従業員の年齢は、３３歳であり、性別は、男性であることを示している。

図５は、対話管理情報記憶部１６４のデータ構造図である。
実施された対話毎にレコードが設けられる。レコードには、従業員ＩＤとメンターＩＤの組み合わせに対応づけて、対話日時と評価値が設定される。第１レコードは、従業員ＩＤのＥ００１で識別される従業員とメンターＩＤのＭ００３で識別されるメンターの対話が、２０１９年４月２日の８：３０から９：００の間に行われ、従業員がその対話をレベル７と評価したことを示している。

図６は、教師データ記憶部１６６のデータ構造図である。
実施された対話毎に、レコードが設けられる。レコードには、実際に対話した従業員とメンターそれぞれの従業員属性情報とメンター属性情報、実績評価値が設定される。１つのレコードは、教師データにおける１つのサンプルに相当する。図６の第１レコードは、図５の第１レコードに示した対話実績に関する。図６の第１レコードに設定されている従業員属性情報は、図５の第１レコードに示した従業員ＩＤがＥ００１である従業員に関する。図６の第１レコードに設定されているメンター属性情報は、図５の第１レコードに示したメンターＩＤがＭ００３であるメンターに関する。図６の第１レコードに設定されている評価値は、図５の第１レコードを同じである。

図７は、教師データの準備フェーズにおける手順を示すフローチャート図である。
図７に示す処理は学習モデルの生成前であるため、従業員に対するメンターの割り当ては、コンサルティング会社の管理者が行うものとする。メンター属性情報取得部１１２は、コンサルティング会社が保持するメンター属性情報を取得し、メンター属性情報記憶部１６０に記憶する（Ｓ２０）。メンター属性情報取得部１１２は、たとえばコンサルティング会社の端末から送信されたメンター属性情報を受信する。

従業員属性情報取得部１１４は、コンサルティングサービスを利用する会社の従業員属性情報を取得し、従業員属性情報記憶部１６２に記憶する（Ｓ２２）。従業員属性情報取得部１１４は、たとえばコンサルティング会社の端末から送信された従業員属性情報を受信する。尚、Ｓ２０の処理とＳ２２の処理は連続して行う必要はない。Ｓ２０の処理とＳ２２の処理は、順番が逆でもよい。

管理者は従業員に対してメンターを割り当てる。予定受付部１１６は、メンターの端末から、従業員ＩＤとメンターＩＤと対話日時を含む対話予定を受け付け、対話管理情報記憶部１６４に記憶する（Ｓ２４）。対話日時は、メンターと従業員が連絡をとりあって決められるものとする。対話が行われるまで、この状態で待機する。

対話が行われた後、報告受付部１１８は、従業員の対話報告を受け付ける（Ｓ２６）。報告受付部１１８は、たとえばコンサルティング会社の端末から送信された従業員の対話報告を受信する。対話報告には、従業員が決定した対話に関する実績評価値が含まれる。また、対話報告には従業員ＩＤも含まれるものとする。報告受付部１１８は、従業員ＩＤによって特定される対話管理情報記憶部１６４のレコードに実績評価値を設定する。

このようにして、多数の対話に関する実績データが収集された段階で、教師データ生成部１４０は、教師データを生成する（Ｓ２８）。具体的には、教師データ生成部１４０は、図５の対話管理情報記憶部１６４の各レコードに対応するレコードを図６の教師データ記憶部１６６に設け、対話管理情報記憶部１６４のレコードの評価値を教師データ記憶部１６６のレコードへコピーする。教師データ生成部１４０は、図４の従業員属性情報記憶部１６２から、対話管理情報記憶部１６４のレコードの従業員ＩＤに対応する属性情報を読み取り、教師データ記憶部１６６のレコードへコピーする。さらに、教師データ生成部１４０は、図３のメンター属性情報記憶部１６０から、対話管理情報記憶部１６４のレコードのメンターＩＤに対応する属性情報を読み取り、教師データ記憶部１６６のレコードへコピーする。

図８は、学習モデルの生成フェーズにおける処理過程を示すフローチャート図である。
学習モデル生成部１４２は、教師データ記憶部１６６に記憶されている教師データを入力して、学習エンジン１４４による学習処理を起動する（Ｓ４０）。学習エンジン１４４は学習処理を実行し、学習モデルを生成する（Ｓ４２）。学習モデルは、学習モデル記憶部１６８に記憶される。

図９は、適用データの準備フェーズにおける手順を示すフローチャート図である。
コンサルティング会社に新たなメンターが加わった場合には、メンター属性情報取得部１１２は、新たなメンターの属性情報を取得し、メンター属性情報記憶部１６０に記憶する（Ｓ５０）。つまり、随時メンター属性情報は更新される。

新たにコンサルティングサービスを提供することになった段階で、従業員属性情報取得部１１４は、新たにコンサルティングサービスを利用する会社の従業員の属性情報を取得し、従業員属性情報記憶部１６２に記憶する（Ｓ５２）。

図１０は、新たにコンサルティングサービスを利用する会社の従業員の属性情報を示す教師データ記憶部１６６のデータ構造図である。
別の会社の従業員とも区別できるように、一意の従業員ＩＤを用いる。データの構成は、上述のとおりである。

図１１は、学習モデルの利用フェーズにおける処理過程を示すフローチャート図である。
予測評価値算出部１４６は、従業員とメンターの組み合わせを１つずつ特定する（Ｓ６０）。具体的には、予測評価値算出部１４６は、各従業員に対して順次すべてのメンターを組み合わせる。

学習モデル利用部１４８は、特定した組み合わせに関して、そのメンターの属性情報とその従業員の属性情報を入力変数として、学習モデルに適用する（Ｓ６２）。予測評価値算出部１４６は、学習モデルの出力変数として、特定した組み合わせに関する予測評価値を得る（Ｓ６４）。予測評価値算出部１４６は、従業員とメンターの組み合わせに対応づけて予測評価値を予測評価値情報記憶部１７０に記憶する。予測評価値算出部１４６は、まだ処理していない組み合わせが残っている場合には（Ｓ６６のＮ）、Ｓ６０の処理へ戻る。すべての組み合わせについて処理を終えた場合には（Ｓ６６のＹ）、全体処理を終了する。

図１２は、予測評価値情報記憶部１７０のデータ構造図である。
この例は、最初に従業員ＩＤがＥ１０１である従業員に対して順次すべてのメンターを組み合わせて各予測評価値を求め、次に従業員ＩＤがＥ１０２である従業員に対して順次すべてのメンターを組み合わせて各予測評価値を求め、さらに従業員ＩＤがＥ１０３である従業員に対して順次すべてのメンターを組み合わせて各予測評価値を求めたことを示している。

図１３は、メンターの推薦フェーズにおける処理過程を示すフローチャート図である。
推薦メンター選定部１５０は、従業員ＩＤを１つずつ特定する（Ｓ７０）。推薦メンター選定部１５０は、予測評価値情報記憶部１７０においてその従業員ＩＤを含むレコードを対象として、予測評価値をキーとしてソートを行い、予測評価値の降順にレコードを並びかえる（Ｓ７２）。推薦メンター選定部１５０は、上位から所定数のレコードに設定されているメンターＩＤによって、推薦するメンターを決定する。所定数が３であれば、予測評価値が上位３名のメンターが推薦される。推薦するメンターのメンターＩＤが、従業員ＩＤに対応づけて推薦リスト記憶部１７２に記憶される（Ｓ７４）。

推薦メンター選定部１５０は、まだ処理していない従業員ＩＤが残っている場合には（Ｓ７６のＮ）、Ｓ７０へ戻る。すべての従業員ＩＤについて処理を終えた場合には（Ｓ７６のＹ）、推薦リスト出力部１２２が推薦リストを出力する（Ｓ７８）。推薦リスト出力部１２２は、各従業員を識別する情報（例えば、従業員ＩＤや従業員名）と、その従業員に対して推薦されるメンターを識別する情報（例えば、メンターＩＤやメンター名）を出力する。推薦リスト出力部１２２は、例えば推薦リストをコンサルティング会社の端末へ送信する。推薦リスト出力部１２２は、表示や印刷の形態で推薦リストを出力してもよい。

［変形例１］
メンターが担当する従業員の数に上限を定めている場合に、優先度の高い従業員から順にメンターを割り当てるようにしてもよい。たとえば、新入社員や多忙な従業員など配慮を要する者の優先度を高くしてもよい。図９のＳ５２において、従業員属性情報取得部１１４は、各従業員の優先順位を示すデータを取得し、従業員属性情報記憶部１６２に記憶する。従業員の優先順位を示すデータは、従業員ＩＤを優先度の高い順番に並べたデータであってもよい。

また、図９のＳ５０において、メンター属性情報取得部１１２は、メンターＩＤ毎に、そのメンターが担当する従業員の数の上限（以下、担当上限数という。）を取得し、メンター属性情報記憶部１６０に記憶する。また、メンター属性情報記憶部１６０は、各レコードにおいてそのメンターに割り当てられている従業員の数（以下、担当人数という。）を記憶する。

図１４は、変形例１の推薦フェーズにおける処理過程を示すフローチャート図である。
推薦メンター選定部１５０は、優先順位に従って、従業員ＩＤを１つずつ特定する（Ｓ８０）。推薦メンター選定部１５０は、上述のとおり、予測評価値情報記憶部１７０においてその従業員ＩＤを含むレコードを対象として、予測評価値をキーとしてソートを行い、予測評価値の降順にレコードを並びかえる（Ｓ８２）。推薦メンター選定部１５０は、上位から順にメンターＩＤを１つ特定する（Ｓ８４）。推薦メンター選定部１５０は、メンターＩＤに対応する担当人数が担当上限数に達しているか否かを判定する（Ｓ８６）。メンターＩＤに対応する担当人数が担当上限数に達している場合には、Ｓ８４に戻って次のメンターＩＤを特定して、同様の処理を繰り返す。メンターＩＤに対応する担当人数が担当上限数に達していない場合には、推薦メンター選定部１５０は、対象の従業員ＩＤにそのメンターＩＤを割り当てる（Ｓ８８）。推薦メンター選定部１５０は、従業員ＩＤとメンターＩＤの組み合わせを推薦リスト記憶部１７２に記憶する。

推薦メンター選定部１５０は、まだ処理していない従業員ＩＤが残っている場合には（Ｓ９０のＮ）、Ｓ８０の処理へ戻る。すべての従業員ＩＤについて処理を終えた場合には（Ｓ９０のＹ）、推薦リスト出力部１２２は、推薦リストを出力する（Ｓ９２）。推薦リストの出力形態については、上述のとおりである。

変形例１では、配慮を要する従業員に対して優先的にメンターを割り当てるので、聞き取りや相談を確実に行ってケアを充実させることができる。

［変形例２］
従業員が対話の希望日時を指定する場合に、希望日時に応対可能なメンターを推薦する例について説明する。この例では、入力部１１０に従業員スケジュール取得部（図示せず）を設け、データ格納部１０６に従業員スケジュール記憶部（図示せず）を設ける。図９のＳ５２において、従業員スケジュール取得部は、従業員が対話の希望日時を指定するスケジュールを取得し、従業員スケジュール記憶部に記憶する。変形例１と同様に、従業員属性情報取得部１１４は、従業員の優先順位を示すデータ、例えば従業員ＩＤを優先度の高い順番に並べたデータを取得し、従業員属性情報記憶部１６２に記憶する。

この例では、さらに入力部１１０にメンタースケジュール取得部（図示せず）を設け、データ格納部１０６にメンタースケジュール記憶部（図示せず）を設ける。図９のＳ５０において、メンタースケジュール取得部は、各メンターの空き時間を特定可能なスケジュールを取得し、メンターＩＤに対応づけてメンター属性情報記憶部１６０に記憶する。

図１５は、変形例２のメンターの推薦フェーズにおける処理過程を示すフローチャート図である。
Ｓ１００からＳ１０４の処理については、図１４のＳ８０からＳ８４と同様である。推薦メンター選定部１５０は、Ｓ１００で特定した従業員ＩＤのスケジュールにおいて希望日時が指定されている場合には、Ｓ１０４で特定したメンターＩＤに対応するスケジュールにおいて対応可能であるか否かを判定する。つまり、希望日時においてメンターのスケジュールが空いているか否かを判定する（Ｓ１０６）。メンターのスケジュールが空いてない場合には、Ｓ１０４に戻って次のメンターＩＤを特定して、同様の処理を繰り返す。メンターのスケジュールが空いている場合には、推薦メンター選定部１５０は、対象の従業員ＩＤにそのメンターＩＤを割り当てる（Ｓ１０８）。推薦メンター選定部１５０は、従業員ＩＤとメンターＩＤの組み合わせを推薦リスト記憶部１７２に記憶する。Ｓ１１０およびＳ１１２の処理については、図１４のＳ９０およびＳ９２と同様である。

変形例２によれば、スケジュールが合わないメンターを推薦することがないので、対話の段取りの効率が上がる。

［変形例３］
メンターの推薦フェーズにおける処理過程に関して、従業員からの問い合わせに応じてメンターを推薦してもよい。たとえば、従業員自身がメンターを決めるように運用する場合には、従業員が自身との相性が良さそうなメンターを数人推薦してもらい、推薦されたメンターの中から気に入ったメンターを選ぶことが考えられる。

変形例３では、インターフェース処理部１０２の入力部１１０が問い合わせ受付部（図示せず）を含むものとする。問い合わせ受付部は、従業員の端末（図示せず）からメンター紹介の問い合わせを受け付けて、従業員ＩＤを特定する。また、インターフェース処理部１０２の出力部１２０がメンター情報出力部（図示せず）を含むものとする。メンター情報出力部は、問い合わせ元の従業員に対して推薦するメンターの情報を出力する。

図１６は、変形例３のメンターの推薦フェーズにおける処理過程を示すフローチャート図である。
問い合わせ受付部は、従業員の端末からメンター紹介の問い合わせを受け付けて、従業員ＩＤを特定する（Ｓ１２０）。メンター紹介の問い合わせに従業員ＩＤが付加されている場合には、問い合わせ受付部は、メンター紹介の問い合わせから従業員ＩＤを得る。端末ＩＤと従業員ＩＤの対応関係が定まっている場合に、問い合わせ受付部は、問い合わせ元の端末のＩＤに対応する従業員ＩＤを特定してもよい。

推薦メンター選定部１５０は、予測評価値情報記憶部１７０においてその従業員ＩＤを含むレコードを対象として、予測評価値をキーとしてソートを行い、予測評価値の降順にレコードを並びかえる（Ｓ１２２）。推薦メンター選定部１５０は、上位から所定数のレコードに設定されているメンターＩＤによって、推薦するメンターを決定する（Ｓ１２４）。所定数が３であれば、予測評価値が上位３名のメンターが推薦される。

メンター情報出力部は、問い合わせ元の従業員に対して推薦するメンターの情報を出力する（Ｓ１２６）。推薦するメンターの情報は、メンターを識別する情報（例えば、メンターＩＤやメンター名）を含む。推薦するメンターの情報は、メンターに関するプロフィールを含んでもよい。メンター情報出力部は、メンターの情報を問い合わせ元の従業員の端末へ送信する。メンター情報出力部は、推薦するメンターの情報を表示や印刷の形態で出力してもよい。

推薦フェーズを継続する場合には（Ｓ１２８のＮ）、Ｓ１２０に戻って次の問い合わせを受け付ける。たとえば推薦フェーズとしてメンターを推薦する期間を過ぎた場合には、推薦フェーズの処理を終える（Ｓ１２８のＹ）。

なお、図１１に示した学習モデルの利用フェーズにおける処理を省き、メンター紹介の問い合わせを受け付けた段階で、従業員と各メンターの組み合わせについて、図１１のＳ６２とＳ６４の処理と同様に予測評価値を得るようにしてもよい。

変形例３によれば、随時従業員の要求に応じてメンターを推薦することができる。たとえば、従業員が早い段階で自らに適したメンターの推薦を求めれば、そのメンターを担当として確保しやすくなる。

［変形例４］
従業員からの問い合わせに応じてメンターを推薦する場合に、担当する従業員の数が上限を超えているメンターを推薦対象から除くようにしてもよい。

図１７は、変形例４のメンターの推薦フェーズにおける処理過程を示すフローチャート図である。
変形例３の場合と同様に、問い合わせ受付部は、従業員の端末からメンター紹介の問い合わせを受け付けて、従業員ＩＤを特定する（Ｓ１３０）。さらに変形例３の場合と同様に、推薦メンター選定部１５０は、予測評価値をキーとして、メンターの順をソートする（Ｓ１３２）。

推薦メンター選定部１５０は、上位から順にメンターＩＤを１つ特定する（Ｓ１３４）。推薦メンター選定部１５０は、メンターＩＤに対応する担当人数が担当上限数に達しているか否かを判定する（Ｓ１３６）。メンターＩＤに対応する担当人数が担当上限数に達している場合には、Ｓ１３４に戻って次のメンターＩＤを特定して、同様の処理を繰り返す。メンターＩＤに対応する担当人数が担当上限数に達していない場合には、メンター情報出力部は、Ｓ１３４で特定したメンターＩＤに基づいて、問い合わせ元の従業員に対して推薦するメンターの情報を出力する（Ｓ１３８）。

推薦フェーズを継続する場合には（Ｓ１４０のＮ）、Ｓ１３０に戻って次の問い合わせを受け付ける。たとえば推薦フェーズとしてメンターを推薦する期間を過ぎた場合には、推薦フェーズの処理を終える（Ｓ１４０のＹ）。

変形例３で説明したとおり、図１１に示した学習モデルの利用フェーズにおける処理を省き、メンター紹介の問い合わせを受け付けた段階で、従業員と各メンターの組み合わせについて、図１１のＳ６２とＳ６４の処理と同様に予測評価値を得るようにしてもよい。

なお、メンターＩＤに対応する担当人数は、メンターに対する従業員の割り当てが確定した段階で更新される。たとえば従業者からメンターの割り当て要求を受け付けた場合に、メンターに対する従業員の割り当てを確定させてもよい。あるいは、Ｓ１３６のＮＯルートで、メンターに対する従業員の割り当てを確定させて、担当人数を増やしてもよい。その場合に、メンター情報出力部は、問い合わせ元の従業員に対して割り当てたメンターの情報を出力してもよい。

変形例４によれば、随時担当人数の上限を超過していないメンターのうち適性の高いメンターを推薦することができる。たとえば、従業員が早い段階で自らに適したメンターの推薦を求めれば、担当人数の上限を超えないうちに相性の良いメンターを担当として確保しやすくなる。

［変形例５］
従業員からの問い合わせに応じてメンターを推薦する場合に、スケジュールが合わないメンターを推薦対象から除くようにしてもよい。

図１８は、変形例５のメンターの推薦フェーズにおける処理過程を示すフローチャート図である。
Ｓ１５０からＳ１５４の処理については、図１７のＳ１３０からＳ１３４と同様である。推薦メンター選定部１５０は、Ｓ１５０における問い合わせ元の従業員の希望日時が指定されている場合には、Ｓ１５４で特定したメンターＩＤに対応するスケジュールにおいて対応可能であるか否かを判定する。つまり、希望日時においてメンターのスケジュールが空いているか否かを判定する（Ｓ１５６）。メンターのスケジュールが空いてない場合には、Ｓ１５４に戻って次のメンターＩＤを特定して、同様の処理を繰り返す。メンターのスケジュールが空いている場合には、メンター情報出力部は、Ｓ１５４で特定したメンターＩＤに基づいて、問い合わせ元の従業員に対して推薦するメンターの情報を出力する（Ｓ１５８）。Ｓ１６０の処理については、図１７のＳ１４０と同様である。

なお、メンターのスケジュールは、随時更新されるものとする。対話の予定が入った場合の他に、任意の事情でメンターのスケジュールが変更されることも考えられる。Ｓ１５６のＮＯルートで、メンターに対する従業員の割り当てを確定させて、メンターのスケジュールを更新してもよい。その場合に、メンター情報出力部は、問い合わせ元の従業員に対して割り当てたメンターの情報を出力してもよい。

変形例３で説明したとおり、図１１に示した学習モデルの利用フェーズにおける処理を省き、メンター紹介の問い合わせを受け付けた段階で、従業員と各メンターの組み合わせについて、図１１のＳ６２とＳ６４の処理と同様に予測評価値を得るようにしてもよい。

変形例５によれば、随時スケジュールが合うメンターのうち適性の高いメンターを推薦することができる。たとえば、従業員が早い段階で自らに適したメンターの推薦を求めれば、スケジュールが埋まる前に相性の良いメンターを担当として確保しやすくなる。

［変形例６］
学習モデルの入力変数に、従業員が所属するグループ（たとえば、課や部署などの組織あるいは職種など）の属性情報を含めてもよい。この例では、従業員が所属するグループのメンバー全員の特性（健康度、幸福感、適応度、貢献感、成長性、プレッシャー感、惰性感など）の平均値をグループの特性とする。グループの特性は、グループの属性情報として用いられる。平均値以外の代表値（中央値や最頻値）をグループの特性としてもよい。

図７のＳ２２において、従業員属性情報取得部１１４は、従業員が所属するグループの属性情報（以下、グループ属性情報ということがある）を取得し、従業員属性情報記憶部１６２に記憶する。図７のＳ２８において、教師データ生成部１４０は、図４の従業員属性情報記憶部１６２から、対話管理情報記憶部１６４のレコードの従業員ＩＤに対応するグループ属性情報を読み取り、教師データ記憶部１６６のレコードへコピーする。つまり、図６の教師データ記憶部１６６の各レコードには、グループ属性情報が加えられる。

図８のＳ４０において、学習モデル生成部１４２は、グループ属性情報を含む教師データを入力して、学習エンジン１４４による学習処理を起動する。

図９のＳ５２において、従業員属性情報取得部１１４は、新たにコンサルティングサービスを利用する会社の従業員の属性情報に併せてグループ属性情報を取得し、従業員属性情報記憶部１６２に記憶する。

図１１のＳ６２において、学習モデル利用部１４８は、メンター属性情報、従業員属性情報およびグループ属性情報を入力変数として、学習モデルに適用する。

従業員が所属するグループの属性情報を用いれば、従業員が置かれている環境を考慮して、より正しく評価値を予測できるようになると期待できる。たとえば、従業員が所属するグループにおける貢献感が低い場合と高い場合とでは、従業員が置かれている環境がそもそも異なる。貢献感が低いグループにおいて中程度の貢献感を有する従業員であれば、恵まれない環境において奮闘していると言える。一方、貢献感が高いグループにおいて中程度の貢献感を有する従業員であれば、恵まれた環境においてあまり振るっていないと言える。従業員が所属するグループの属性情報を用いれば、学習モデルにおいてこのような環境の違いも考慮できると考えられる。

［その他の変形例］
学習モデル生成部１４２が学習エンジン１４４を備える例を示したが、学習モデル生成部１４２は外部の学習エンジン１４４を用いてもよい。たとえば情報処理装置１００が接続しているＬＡＮ（Local Area Network）に属するサーバが学習エンジン１４４を有する場合に、学習モデル生成部１４２はそのサーバの学習エンジン１４４を利用してもよい。あるいは、ＷＥＢサーバが学習エンジン１４４を有する場合に、学習モデル生成部１４２はＷＥＢサーバの学習エンジン１４４を利用してもよい。

情報処理装置１００においてメンターのアンケート結果を分析してメンターの特性を判定する処理を行なってもよい。情報処理装置１００において従業員のアンケート結果を分析して従業員の特性を判定する処理を行なってもよい。

上述の実施形態では、健康度が高いと判定された回答数の偏差値によって健康度のレベルを表す例を示したが、健康度が高いと判定された回答数を他の方法で正規化した値によって健康度のレベルを表してもよい。また、健康度が高いと判定された回答数によって健康度のレベルを表してもよい。幸福感、適応度、貢献感、成長性、プレッシャー感および惰性感についても同様である。

図７に示した教師データの準備フェーズにおける手順に関して、Ｓ２４およびＳ２６の処理に代えて、インターフェース処理部１０２の入力部１１０の実績データ取得部（図示せず）において、多数回の対話に関する実績データとして従業員ＩＤとメンターＩＤと実績評価値との組み合わせを一括して取得してもよい。この場合に、教師データ生成部１４０は、一括して取得した実績データに基づいて教師データを生成してもよい。

実施された対話の評価値は、メンターが決定したものであってもよい。

図１１に示したＳ６０の処理において、従業員とメンターの組み合わせを特定するときに、従業員とスケジュールが合わないメンターを組み合わせの対象から除外してもよい。このようにすれば、組み合わせ数が減り、Ｓ６２及びＳ６４の処理回数を減らせる。

なお、本発明は上記実施形態や変形例に限定されるものではなく、要旨を逸脱しない範囲で構成要素を変形して具体化することができる。上記実施形態や変形例に開示されている複数の構成要素を適宜組み合わせることにより種々の発明を形成してもよい。また、上記実施形態や変形例に示される全構成要素からいくつかの構成要素を削除してもよい。

本実施形態では、従業員の属性情報とメンターの属性情報を入力変数として用いて、実績に即した判定ロジックである学習モデルを生成し、利用するので、未知の従業員に対しても、高い適性が期待できるメンターを推薦することができる。

また、従業員に対するメンターの割り当てを管理者が行う場合には、属人的な判断となりやすい。これに対して、学習モデルを利用してメンターの割り当てを行えば、客観的な判断が行われる。また、人が経験の範疇では予見できないような好い相性の割り当てを実現できる可能性もある。

また、従業員が属するグループの属性情報を学習モデルの入力変数として用いるので、従業員が属するグループの特性（たとえば、従業員が所属する組織の雰囲気や組織長の対応など）を加味して、メンターの適性を判定できる。

また、従業員とスケジュールが合うメンターを推薦するので、対話の段取りを効率的に行える。

１００ 情報処理装置、１０２ インターフェース処理部、１０４ データ処理部、１０６ データ格納部、１１０ 入力部、１１２ メンター属性情報取得部、１１４ 従業員属性情報取得部、１１６ 予定受付部、１１８ 報告受付部、１２０ 出力部、１２２ 推薦リスト出力部、１４０ 教師データ生成部、１４２ 学習モデル生成部、１４４ 学習エンジン、１４６ 予測評価値算出部、１４８ 学習モデル利用部、１５０ 推薦メンター選定部、１６０ メンター属性情報記憶部、１６２ 従業員属性情報記憶部、１６４ 対話管理情報記憶部、１６６ 教師データ記憶部、１６８ 学習モデル記憶部、１７０ 予測評価値情報記憶部、１７２ 推薦リスト記憶部

Claims (5)

1. 対話サービスを提供可能な応対者の属性情報を取得する第１取得部と、
   前記応対者との前記対話サービスを利用した第１利用者の属性情報と、前記第１利用者が所属するグループの属性情報とを取得する第２取得部と、
   前記応対者が前記第１利用者へ提供した前記対話サービスの実績としての評価値である実績評価値を取得する第３取得部と、
   前記第１利用者の前記属性情報と、前記第１利用者が所属する前記グループの前記属性情報と、前記応対者の前記属性情報とを入力変数とし、前記実績評価値を出力変数とする学習モデルを生成させる学習モデル生成部と、
   前記対話サービスを利用予定の第２利用者の属性情報と、前記第２利用者が所属するグループの属性情報と、前記応対者の前記属性情報とを前記学習モデルの入力変数とすることにより、前記第２利用者と前記応対者との対話サービスに関して予測される評価値として予測評価値を算出する予測評価値算出部と、を備えることを特徴とする情報処理装置。
2. 前記第１利用者が所属する前記グループの前記属性情報は、前記第１利用者が所属する前記グループに属するメンバーの属性情報に基づき、
   前記第２利用者が所属する前記グループの前記属性情報は、前記第２利用者が所属する前記グループに属するメンバーの属性情報に基づくことを特徴とする請求項１に記載の情報処理装置。
3. 前記第２利用者のスケジュールを取得する第４取得部と、
   前記対話サービスを提供可能な応対候補者のスケジュールを取得する第５取得部と、
   前記第２利用者および複数の応対候補者それぞれについての前記予測評価値と、前記第２利用者および前記複数の応対候補者の前記スケジュールに基づいて、前記複数の応対候補者から応対者を選定する応対者選定部と、を備えることを特徴とする請求項１または２に記載の情報処理装置。
4. 対話サービスを提供可能な第２応対者の属性情報を取得する第１取得部と、
   前記対話サービスを利用予定の第２利用者の属性情報と、前記第２利用者が所属するグループの属性情報とを取得する第２取得部と、
   前記対話サービスを利用した第１利用者の属性情報と、前記第１利用者が所属するグループの属性情報と、前記第１利用者に対話サービスを提供した第１応対者の属性情報とを入力変数とし、前記第１応対者が前記第１利用者へ提供した前記対話サービスの実績としての評価値である実績評価値を出力変数として生成された学習モデルに、前記第２利用者の前記属性情報と、前記第２利用者が所属する前記グループの前記属性情報と、前記第２応対者の前記属性情報とを入力し、前記第２利用者と前記第２応対者との対話サービスに関して予測される評価値として予測評価値を算出する予測評価値算出部と、を備えることを特徴とする情報処理装置。
5. 対話サービスを提供可能な応対者の属性情報を取得する機能と、
   前記応対者との前記対話サービスを利用した第１利用者の属性情報と、前記第１利用者が所属するグループの属性情報とを取得する機能と、
   前記応対者が前記第１利用者へ提供した前記対話サービスの実績としての評価値である実績評価値を取得する機能と、
   前記第１利用者の前記属性情報と、前記第１利用者が所属する前記グループの前記属性情報と、前記応対者の前記属性情報とを入力変数とし、前記実績評価値を出力変数とする学習モデルを生成させる機能と、
   前記対話サービスを利用予定の第２利用者の属性情報と、前記第２利用者が所属するグループの属性情報と、前記応対者の前記属性情報とを前記学習モデルの入力変数とすることにより、前記第２利用者と前記応対者との対話サービスに関して予測される評価値として予測評価値を算出する機能と、をコンピュータに発揮させることを特徴とするプログラム。

Images