(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024002830
(43)【公開日】2024-01-11
(54)【発明の名称】装置、システム、プログラムおよび方法
(51)【国際特許分類】
G06Q 50/10 20120101AFI20231228BHJP
【FI】
G06Q50/10
【審査請求】未請求
【請求項の数】30
【出願形態】OL
(21)【出願番号】P 2022102272
(22)【出願日】2022-06-24
(71)【出願人】
【識別番号】520496235
【氏名又は名称】株式会社World Life Mapping
(74)【代理人】
【識別番号】100128886
【弁理士】
【氏名又は名称】横田 裕弘
(72)【発明者】
【氏名】下田 彬
(72)【発明者】
【氏名】ガニエ マーク智也
(72)【発明者】
【氏名】河又 正樹
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049CC11
(57)【要約】
【課題】ユーザからの信頼を高めることが可能なサーバ装置等を提供する。
【解決手段】本発明の装置は、第1ユーザおよび第2ユーザが互いを理解している程度についての情報である相互理解情報を取得する理解情報取得手段と、前記第1ユーザおよび前記第2ユーザが互いに対して行う言動についての情報である言動情報を取得する言動情報取得手段と、前記理解情報および前記言動情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力する出力手段と、を備える。
【選択図】
図6
【特許請求の範囲】
【請求項1】
第1ユーザおよび第2ユーザが互いを理解している程度についての情報である相互理解情報を取得する理解情報取得手段と、
前記第1ユーザおよび前記第2ユーザが互いに対して行う言動についての情報である言動情報を取得する言動情報取得手段と、
前記理解情報および前記言動情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力する出力手段と、
を備える、装置。
【請求項2】
前記理解情報取得手段は、
前記第1ユーザのユーザ情報であって、前記第2ユーザに提示することを可能とする情報である提示可能情報を前記第1ユーザから取得し、
前記第2ユーザによる前記提示可能情報の理解の程度を示す理解情報を前記第2ユーザから取得する
請求項1記載の装置。
【請求項3】
前記提示可能情報は、前記第2ユーザが行う行動であって前記第1ユーザが禁止したいと考える言動である禁止言動情報と、前記第1ユーザが行う言動であって前記第2ユーザに容認して欲しいと前記第1ユーザが考える言動である容認言動情報とを含む
請求項2記載の装置。
【請求項4】
前記理解情報取得手段は、
前記第1ユーザおよび前記第2ユーザのユーザ情報を取得し、
前記第1ユーザおよび前記第2ユーザのユーザ情報に基づいて、前記第1ユーザおよび前記第2ユーザの共通点を示す情報である共通点情報と、前記第1ユーザおよび前記第2ユーザの相違点を示す情報である相違点情報とを出力する
請求項1乃至3のいずれか1項記載の装置。
【請求項5】
前記理解情報取得手段は、
前記第1ユーザが他者を受容できる程度である他者受容度の情報を取得し、
前記他者受容度が低い場合に、前記第1ユーザに対して前記相違点情報を出力しない
請求項4記載の装置。
【請求項6】
前記理解情報取得手段は、
前記第1ユーザのユーザ情報を取得し、
前記第1ユーザのユーザ情報のうち前記第2ユーザからみて尊敬点となり得る潜在尊敬点の情報を出力する
請求項1記載の装置。
【請求項7】
前記言動情報取得手段は、
前記第1ユーザが前記第2ユーザに対して行う言動であって、前記2ユーザの存在を肯定する言動である肯定言動の情報と、前記第2ユーザの存在を否定する言動である否定言動の情報とを取得し、
前記第1ユーザが前記第2ユーザに対して行う言動において、前記肯定言動が占める割合を増加することを促す情報である肯定言動促進情報を出力する
請求項1記載の装置。
【請求項8】
前記言動情報取得手段は、
前記第1ユーザの言動であって、前記第2ユーザの存在を無視する言動である無視言動の情報を取得し、
前記無視言動を抑制することを促す情報である無視言動抑制情報を出力する
請求項7記載の装置。
【請求項9】
前記言動情報取得手段は、
他者に対して行う言動についての前記第1ユーザの意識の情報である言動意識情報を取得し、
前記言動意識情報に基づいて、前記第1ユーザによる前記言動意識を高める情報である意識高化情報を出力する
請求項7または8記載の装置。
【請求項10】
前記第1ユーザによる前記第2ユーザとの関係性の評価の情報である関係性情報を取得する関係性評価取得手段を備え、
前記出力手段は、前記関係性情報に基づいて前記支援情報を出力する
請求項1記載の装置。
【請求項11】
前記出力手段は、前記関係性情報に基づく前記支援情報を、前記理解情報および前記言動情報に基づく前記支援情報よりも優先して出力する
請求項10記載の装置。
【請求項12】
前記関係性評価は、前記第2ユーザとの関係性を前記第1ユーザがどのように評価するかを示す第1情報と、前記第2ユーザが前記関係性をどのように評価すると前記第1ユーザが考えるかを示す第2情報とを含む
請求項10または11記載の装置。
【請求項13】
前記関係性評価取得手段は、前記関係性情報を取得する際に、前記第1ユーザが前記関係性情報を入力する環境に応じて、前記第2ユーザとの関係性が悪化する可能性が相対的に高い高確率情報を取得する場合と、前記可能性が相対的に低い低確率情報を取得する場合とを切り替える
請求項10記載の装置。
【請求項14】
前記関係性評価取得手段は、前記第1ユーザおよび前記第2ユーザの関係におけるわだかまりの情報を取得し、
前記出力手段は、前記支援情報に前記わだかまりを解消するための情報を含める
請求項10記載の装置。
【請求項15】
前記第1ユーザおよび前記第2ユーザのユーザ情報に基づいて、前記第1ユーザおよび前記第2ユーザの相性を取得する相性取得手段と、
前記出力手段は、前記相性に基づいて前記第1ユーザおよび前記第2ユーザの関係性が将来悪化する可能性を抑制する悪化抑制情報を出力する
請求項1記載の装置。
【請求項16】
前記第1ユーザおよび前記第2ユーザが相互に援助する相互援助についての理解度である相互援助理解度の情報を前記第1ユーザから取得する相互援助情報取得手段を備え、
前記出力手段は、前記支援情報に前記相互援助理解度を高める情報を含める
請求項1記載の装置。
【請求項17】
前記第1ユーザおよび前記第2ユーザはチームの構成員であり、
前記理解情報取得手段は、前記チームの構成員同士における前記理解情報を取得し、
前記言動情報取得手段は、前記チームの構成員同士における前記言動情報を取得し、
前記出力手段は、前記チームにおける他の構成員と比較して前記第1ユーザの前記関係性が悪い場合に、前記他の構成員よりも優先して前記第1ユーザの前記支援情報を出力する
請求項1記載の装置。
【請求項18】
前記チームが形成された時期であるチーム形成時期の情報を取得する形成時期取得手段を備え、
前記出力手段は、前記チーム形成時期からの経過時間に応じて前記支援情報を切り替える
請求項17記載の装置。
【請求項19】
前記出力手段は、前記第2ユーザが前記関係性を悪化させる言動を行う可能性がある場合に、前記支援情報において前記悪化させる言動を行う可能性を示す情報とともに、前記悪化させる言動を前記第1ユーザが肯定的に理解することを促す理解促進情報を出力する
請求項1記載の装置。
【請求項20】
前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する前記支援情報を前記第1ユーザおよび前記第2ユーザに対して出力する場合に、前記支援情報が前記第1ユーザおよび前記第2ユーザに提示されるタイミングを揃える
請求項1記載の装置。
【請求項21】
前記第1ユーザおよび前記第2ユーザが所属する組織における前記第1ユーザおよび前記第2ユーザの職位の情報である職位情報を取得する職位情報取得手段を備え、
前記出力手段は、前記職位情報に基づいて、前記支援情報を切り替える
請求項1記載の装置。
【請求項22】
前記第1ユーザおよび前記第2ユーザが家族であることを示す情報を取得する家族情報取得手段を備え、
前記出力手段は、前記家族情報取得手段が前記家族であることを示す情報を取得する場合に、前記支援情報として前記第1ユーザおよび前記第2ユーザの一方の忙しさ、ストレス値、家族における作業負担のうちの少なくともいずれか1つを含めて、前記第1ユーザおよび前記第2ユーザの他方に出力する
請求項1記載の装置。
【請求項23】
前記第1ユーザの精神状態を示す情報である精神情報を取得する精神情報取得手段を有し、
前記精神情報が前記第1ユーザの精神状態が所定状態よりも悪化している場合に、前記第1ユーザに対して出力される前記支援情報は、前記第2ユーザに対して否定的な言動を行わないよう前記第1ユーザを促す情報を含む
請求項1記載の装置。
【請求項24】
第1ユーザおよび第2ユーザが互いを理解している程度についての情報である相互理解情報を取得する理解情報取得手段と、
前記理解情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力する出力手段と、
を備える、装置。
【請求項25】
第1ユーザおよび第2ユーザが互いに対して行う言動についての情報である言動情報を取得する言動情報取得手段と、
前記言動情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力する出力手段と、
を備える、装置。
【請求項26】
ユーザ自身が他のユーザとの関係性を評価した関係性評価を取得する第1取得手段と、
前記関係性に影響を与える要因の評価である要因評価を取得する第2取得手段と、
前記関係性評価および前記要因評価に基づいて、前記関係性を改善または維持する支援情報を出力する出力手段と、
を備える、装置。
【請求項27】
前記出力手段は、
前記関係性評価に基づく第1支援情報を前記ユーザに出力し、
前記要因評価に基づく第2支援情報を前記ユーザに出力し、
前記第1支援情報を出力することにともない、前記第2支援情報の出力を制限する
請求項26記載の装置。
【請求項28】
端末と、装置と、を備えるシステムであって、
前記装置は、
第1ユーザおよび第2ユーザが互いを理解している程度についての情報である相互理解情報を取得する理解情報取得手段と、
前記第1ユーザおよび前記第2ユーザが互いに対して行う言動についての情報である言動情報を取得する言動情報取得手段と、
前記理解情報および前記言動情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力する出力手段と、
を備える、システム。
【請求項29】
第1ユーザおよび第2ユーザが互いを理解している程度についての情報である相互理解情報を取得するステップと、
前記第1ユーザおよび前記第2ユーザが互いに対して行う言動についての情報である言動情報を取得するステップと、
前記理解情報および前記言動情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力するステップと、
をコンピュータに実行させる、プログラム。
【請求項30】
第1ユーザおよび第2ユーザが互いを理解している程度についての情報である相互理解情報を取得し、
前記第1ユーザおよび前記第2ユーザが互いに対して行う言動についての情報である言動情報を取得し、
前記理解情報および前記言動情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力する、方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、装置、システム、プログラムおよび方法に関する。
【背景技術】
【0002】
特許文献1には、ユーザの状態に応じて効率的かつ適切なアドバイスを提示することが可能な健康管理システムが開示されている。この健康管理システムにおいて、問診提示モジュールは定期的にユーザ端末に問診を提示する。アドバイス選択モジュールは、生理量データおよび問診回答と個人設定値とに基づいてアルゴリズムデータベースに登録された複数のアドバイスアルゴリズムのいずれかを選択し、ユーザ端末に自動アドバイスとして提示し、自動アドバイスを提示できない場合には、医師端末に判断依頼を行う。医師端末は、個別アドバイスモジュールの個人掲示板を介して個別アドバイスをユーザ端末に提示する。アドバイス構成モジュールは、Q&A履歴データベースからQ&A履歴を抽出し、アドバイスアルゴリズムを生成する。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1に記載の技術においては、ユーザの問診情報を取得した際に自動でアドバイスを生成する。このアドバイスの表示は、ユーザの問診情報に基づき、さらに問診情報の取得時に行われる。そのため、ユーザがアドバイスの表示が機械的であるという印象を受け、このシステムに対するユーザからの信頼が高められない。
【0005】
そこで、本発明では、ユーザからの信頼を高めることが可能な装置等を提供することを目的とする。
【課題を解決するための手段】
【0006】
かかる目的のもと、本明細書に開示される技術は、第1ユーザおよび第2ユーザが互いを理解している程度についての情報である相互理解情報を取得する理解情報取得手段と、前記第1ユーザおよび前記第2ユーザが互いに対して行う言動についての情報である言動情報を取得する言動情報取得手段と、前記理解情報および前記言動情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力する出力手段と、を備える、装置である。
【0007】
また、前記理解情報取得手段は、前記第1ユーザのユーザ情報であって、前記第2ユーザに提示することを可能とする情報である提示可能情報を前記第1ユーザから取得し、前記第2ユーザによる前記提示可能情報の理解の程度を示す理解情報を前記第2ユーザから取得するとよい。
また、前記提示可能情報は、前記第2ユーザが行う行動であって前記第1ユーザが禁止したいと考える言動である禁止言動情報と、前記第1ユーザが行う言動であって前記第2ユーザに容認して欲しいと前記第1ユーザが考える言動である容認言動情報とを含むとよい。
また、前記理解情報取得手段は、前記第1ユーザおよび前記第2ユーザのユーザ情報を取得し、前記第1ユーザおよび前記第2ユーザのユーザ情報に基づいて、前記第1ユーザおよび前記第2ユーザの共通点を示す情報である共通点情報と、前記第1ユーザおよび前記第2ユーザの相違点を示す情報である相違点情報とを出力するとよい。
また、前記理解情報取得手段は、前記第1ユーザが他者を受容できる程度である他者受容度の情報を取得し、前記他者受容度が低い場合に、前記第1ユーザに対して前記相違点情報を出力しないとよい。
また、前記理解情報取得手段は、前記第1ユーザのユーザ情報を取得し、前記第1ユーザのユーザ情報のうち前記第2ユーザからみて尊敬点となり得る潜在尊敬点の情報を出力するとよい。
また、前記言動情報取得手段は、前記第1ユーザが前記第2ユーザに対して行う言動であって、前記2ユーザの存在を肯定する言動である肯定言動の情報と、前記第2ユーザの存在を否定する言動である否定言動の情報とを取得し、前記第1ユーザが前記第2ユーザに対して行う言動において、前記肯定言動が占める割合を増加することを促す情報である肯定言動促進情報を出力するとよい。
また、前記言動情報取得手段は、前記第1ユーザの言動であって、前記第2ユーザの存在を無視する言動である無視言動の情報を取得し、前記無視言動を抑制することを促す情報である無視言動抑制情報を出力するとよい。
また、前記言動情報取得手段は、他者に対して行う言動についての前記第1ユーザの意識の情報である言動意識情報を取得し、前記言動意識情報に基づいて、前記第1ユーザによる前記言動意識を高める情報である意識高化情報を出力するとよい。
【0008】
また、前記第1ユーザによる前記第2ユーザとの関係性の評価の情報である関係性情報を取得する関係性評価取得手段を備え、前記出力手段は、前記関係性情報に基づいて前記支援情報を出力するとよい。
また、前記出力手段は、前記関係性情報に基づく前記支援情報を、前記理解情報および前記言動情報に基づく前記支援情報よりも優先して出力するとよい。
また、前記関係性評価は、前記第2ユーザとの関係性を前記第1ユーザがどのように評価するかを示す第1情報と、前記第2ユーザが前記関係性をどのように評価すると前記第1ユーザが考えるかを示す第2情報とを含むとよい。
また、前記関係性評価取得手段は、前記関係性情報を取得する際に、前記第1ユーザが前記関係性情報を入力する環境に応じて、前記第2ユーザとの関係性が悪化する可能性が相対的に高い高確率情報を取得する場合と、前記可能性が相対的に低い低確率情報を取得する場合とを切り替えるとよい。
また、前記関係性評価取得手段は、前記第1ユーザおよび前記第2ユーザの関係におけるわだかまりの情報を取得し、前記出力手段は、前記支援情報に前記わだかまりを解消するための情報を含めるとよい。
【0009】
また、前記第1ユーザおよび前記第2ユーザのユーザ情報に基づいて、前記第1ユーザおよび前記第2ユーザの相性を取得する相性取得手段と、前記出力手段は、前記相性に基づいて前記第1ユーザおよび前記第2ユーザの関係性が将来悪化する可能性を抑制する悪化抑制情報を出力するとよい。
また、前記第1ユーザおよび前記第2ユーザが相互に援助する相互援助についての理解度である相互援助理解度の情報を前記第1ユーザから取得する相互援助情報取得手段を備え、前記出力手段は、前記支援情報に前記相互援助理解度を高める情報を含めるとよい。
また、前記第1ユーザおよび前記第2ユーザはチームの構成員であり、前記理解情報取得手段は、前記チームの構成員同士における前記理解情報を取得し、前記言動情報取得手段は、前記チームの構成員同士における前記言動情報を取得し、前記出力手段は、前記チームにおける他の構成員と比較して前記第1ユーザの前記関係性が悪い場合に、前記他の構成員よりも優先して前記第1ユーザの前記支援情報を出力するとよい。
また、前記チームが形成された時期であるチーム形成時期の情報を取得する形成時期取得手段を備え、前記出力手段は、前記チーム形成時期からの経過時間に応じて前記支援情報を切り替えるとよい。
また、前記出力手段は、前記第2ユーザが前記関係性を悪化させる言動を行う可能性がある場合に、前記支援情報において前記悪化させる言動を行う可能性を示す情報とともに、前記悪化させる言動を前記第1ユーザが肯定的に理解することを促す理解促進情報を出力するとよい。
また、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する前記支援情報を前記第1ユーザおよび前記第2ユーザに対して出力する場合に、前記支援情報が前記第1ユーザおよび前記第2ユーザに提示されるタイミングを揃えるとよい。
また、前記第1ユーザおよび前記第2ユーザが所属する組織における前記第1ユーザおよび前記第2ユーザの職位の情報である職位情報を取得する職位情報取得手段を備え、前記出力手段は、前記職位情報に基づいて、前記支援情報を切り替えるとよい。
また、前記第1ユーザおよび前記第2ユーザが家族であることを示す情報を取得する家族情報取得手段を備え、前記出力手段は、前記家族情報取得手段が前記家族であることを示す情報を取得する場合に、前記支援情報として前記第1ユーザおよび前記第2ユーザの一方の忙しさ、ストレス値、家族における作業負担のうちの少なくともいずれか1つを含めて、前記第1ユーザおよび前記第2ユーザの他方に出力するとよい。
また、前記第1ユーザの精神状態を示す情報である精神情報を取得する精神情報取得手段を有し、前記精神情報が前記第1ユーザの精神状態が所定状態よりも悪化している場合に、前記第1ユーザに対して出力される前記支援情報は、前記第2ユーザに対して否定的な言動を行わないよう前記第1ユーザを促す情報を含むとよい。
【0010】
さらに他の観点から捉えると、本明細書に開示される技術は、第1ユーザおよび第2ユーザが互いを理解している程度についての情報である相互理解情報を取得する理解情報取得手段と、前記理解情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力する出力手段と、を備える、装置である。
【0011】
さらに他の観点から捉えると、本明細書に開示される技術は、第1ユーザおよび第2ユーザが互いに対して行う言動についての情報である言動情報を取得する言動情報取得手段と、前記言動情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力する出力手段と、を備える、装置である。
【0012】
さらに他の観点から捉えると、本明細書に開示される技術は、ユーザ自身が他のユーザとの関係性を評価した関係性評価を取得する第1取得手段と、前記関係性に影響を与える要因の評価である要因評価を取得する第2取得手段と、前記関係性評価および前記要因評価に基づいて、前記関係性を改善または維持する支援情報を出力する出力手段と、を備える、装置である。
また、前記出力手段は、前記関係性評価に基づく第1支援情報を前記ユーザに出力し、前記要因評価に基づく第2支援情報を前記ユーザに出力し、前記第1支援情報を出力することにともない、前記第2支援情報の出力を制限するとよい。
【0013】
さらに他の観点から捉えると、本明細書に開示される技術は、端末と、装置と、を備えるシステムであって、前記装置は、第1ユーザおよび第2ユーザが互いを理解している程度についての情報である相互理解情報を取得する理解情報取得手段と、前記第1ユーザおよび前記第2ユーザが互いに対して行う言動についての情報である言動情報を取得する言動情報取得手段と、前記理解情報および前記言動情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力する出力手段と、を備える、システムである。
【0014】
さらに他の観点から捉えると、本明細書に開示される技術は、第1ユーザおよび第2ユーザが互いを理解している程度についての情報である相互理解情報を取得するステップと、前記第1ユーザおよび前記第2ユーザが互いに対して行う言動についての情報である言動情報を取得するステップと、前記理解情報および前記言動情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力するステップと、をコンピュータに実行させる、プログラムである。
【0015】
さらに他の観点から捉えると、本明細書に開示される技術は、第1ユーザおよび第2ユーザが互いを理解している程度についての情報である相互理解情報を取得し、前記第1ユーザおよび前記第2ユーザが互いに対して行う言動についての情報である言動情報を取得し、前記理解情報および前記言動情報に基づいて、前記第1ユーザおよび前記第2ユーザの関係性を改善または維持する支援情報を出力する、方法である。
【発明の効果】
【0016】
本発明によれば、ユーザからの信頼を高めることが可能な装置等が提供される。
【図面の簡単な説明】
【0017】
【
図1】本実施の形態が適用される情報処理システムの全体構成例を示した図である。
【
図2】管理装置の構成例を説明するための図である。
【
図3】(A)はユーザ情報TBの一例を示す図であり、(B)はコンテンツTBの一例を示す図であり、(C)はコンテンツTBに含まれる関係性支援コンテンツの詳細を示す図である。
【
図4】情報処理システムの動作を示すフローチャートである。
【
図5】管理装置の登録処理を示すフローチャートである。
【
図6】情報処理システムの支援処理を示すフローチャートである。
【
図7】表象関係管理部によって実行される表象関係管理処理を示すフローチャートである。
【
図8】表象関係管理部によって実行されるわだかまり解消処理を示すフローチャートである。
【
図9】相互理解管理部によって実行される相互理解処理を示すフローチャートである。
【
図10】相互理解管理部によって実行される相互理解基本処理を示すフローチャートである。
【
図11】相互理解管理部によって実行される共通点処理を示すフローチャートである。
【
図12】相互理解管理部によって実行される相違点処理を示すフローチャートである。
【
図13】相互理解管理部によって実行される尊敬点処理を示すフローチャートである。
【
図14】ストローク管理部によって実行されるストローク処理を示すフローチャートである。
【
図15】潜在的相性管理部によって実行される潜在的相性処理を示すフローチャートである。
【
図16】相互援助管理部によって実行される潜在的相性処理を示すフローチャートである。
【
図17】支援実行部によって実行されるチーム形成処理を示すフローチャートである。
【
図18】ユーザ情報管理部によって出力される数値入力画像を説明する図である。
【
図19】支援実行部によって出力されるストローク確認画像を説明する図である。
【
図20】支援実行部によって出力される他のストローク確認画像を説明する図である。
【
図21】支援実行部によって出力される相互理解促進画像を示す図である。
【
図22】支援実行部によって出力される他の相互理解促進画像を説明する図である。
【
図23】支援実行部によって出力される根本的実態画像を示す図である。
【
図24】支援実行部によって実行されるカリキュラム処理を示すフローチャートである。
【
図25】支援実行部によって出力されるカリキュラム要望受付画像を示す図である。
【
図26】支援実行部によって実行される家族関係処理を示すフローチャートである。
【
図27】支援実行部によって出力される親子関係支援画像を示す図である。
【
図28】支援実行部によって実行される職場関係処理を示すフローチャートである。
【
図29】支支援実行部によって実行されるストローク介入処理を示すフローチャートである。
【
図30】管理装置のハードウェア構成例を示した図である。
【発明を実施するための形態】
【0018】
以下、添付図面を参照して、本発明の他の実施の形態について説明する。
<情報処理システム1>
図1は、本実施の形態が適用される情報処理システム1の全体構成例を示した図である。
図1に示すように、情報処理システム1は、端末100、200、300と、管理装置500とを有する。端末100、200、300および管理装置500は、ネットワークNWを介して互いに接続されている。
【0019】
端末100、200、300の各々は、スマートフォン、ノート型コンピュータ、デスクトップ型コンピュータ、タブレット型コンピュータ、ウェアラブルデバイス、あるいは携帯電話等のコンピュータ装置によって構成される。端末100、200、300は、情報処理システム1におけるクライアントとして機能する。なお、以下の説明においては、端末100、200、300の各々を区別しないときは、端末100等ということがある。
【0020】
ここで、端末100、200、300は、それぞれ情報処理システム1のユーザによって操作される。なお、図示の例においては、3つの端末100、200、300が示されているが、その数は特に限定されず、端末100、200、300以外の端末を含んでもよい。
【0021】
管理装置500は、コンピュータ装置によって構成される。この管理装置500は、情報処理システム1におけるサーバとして機能する。本実施の形態の管理装置500は、端末100、200、300を操作するユーザを支援するために必要な各種制御を実行する。
【0022】
ネットワークNWは、装置間のデータ交換に用いられる通信ネットワークである。図示のネットワークNWは、インターネットにより構成されるが、特に限定されない。ネットワークNWは、例えばLAN(Local Area Network)、WAN(Wide Area Network)であってもよい。また、ネットワークNWの通信回線は、有線か無線かを問わず、これらを併用してもよい。
【0023】
情報処理システム1は、管理装置500が特定のサービスを提供することにより、端末100等を操作するユーザがそのサービスを利用することを可能とする。さらに説明すると、情報処理システム1は、管理装置500がユーザ情報に基づき、当該ユーザの心身状態を改善または維持する支援情報をユーザに通知することにより、ユーザを支援する。ここで、情報処理システム1はユーザ支援の一例として、ユーザ同士の関係性を改善または維持するようユーザの支援を行う。さらに説明をすると、情報処理システム1の管理装置500は、ユーザ情報に基づきユーザ同士の関係性を支援する支援情報をユーザに通知することにより、ユーザを支援する。
【0024】
ここで、支援情報とは、ユーザを支援するための情報である。この支援情報は、例えば精神状態および身体状態の少なくとも一方を改善または維持するための情報である。また、支援情報は、例えばユーザ同士の関係性を改善または維持するための情報である。ユーザ同士の関係性とは、ユーザ同士が行うコミュニケーションョンの良好さである。付言すると、ユーザ同士の関係性がよいとは、対象とするユーザが他のユーザとコミュニケーションをとる際に感じる心理的なストレスが少ないことをいう。言い替えると、ユーザ同士の関係性がよいとは、ユーザ同士が互いをよく認識していること、すなわちユーザ同士の認識が良好であることや、ユーザ同士が互いをよく理解していること、すなわちユーザ同士の理解が良好であることや、ユーザ同士が互いをよく援助すること、すなわちユーザ同士の援助の状態が良好であることなどをいう。
【0025】
なお、ユーザに対してどの支援情報を提示するかについての情報処理システム1による決定は、ユーザの要望に基づいて行ってもよい。例えば、ユーザに対して希望する支援情報の種別を質問し、得られた回答に基づいて支援情報を提示してもよい。
【0026】
<管理装置500>
図2は、管理装置500の構成例を説明するための図である。
次に、
図1および
図2を参照しながら管理装置500の構成例について説明をする。
【0027】
管理装置500は、ユーザ情報管理部510と、コンテンツ管理部520と、チャット実行部530と、出力管理部550とを有する。なお、ユーザ情報管理部510、コンテンツ管理部520、チャット実行部530および出力管理部550の各々は、情報処理システム1のサブシステムとして捉えることができる。
【0028】
ユーザ情報管理部510は、ユーザに関する情報であるユーザ情報(ユーザデータ)を端末100等から取得し登録する。ユーザ情報管理部510は、取得したユーザ情報に基づいて、ユーザごとにアカウントを作成する。ユーザ情報管理部510は、ユーザ情報TB(table)511を記憶する。
【0029】
コンテンツ管理部520は、ユーザの思想変容および行動変容を促す情報であるコンテンツを取得し登録する。このコンテンツ管理部520が出力するコンテンツは、ユーザ同士の関係性を支援するための関係性支援コンテンツ(関係性支援情報)を含む。コンテンツ管理部520は、コンテンツTB521を記憶する。
【0030】
チャット実行部530は、ユーザ同士のチャットを実行するための処理(チャット処理)を行う。ここで、チャットとは、ネットワークNWを通じて、端末100等における個々の端末間でメッセージ等をリアルタイムにやり取りするコミュニケーションを含む。コミュニケーションの手段としては、テキスト(文字)、音声、画像(静止画像、動画像)等を用いることができる。さらに説明をすると、チャット実行部530は、端末100等を操作することでユーザによって入力されたチャットのテキストデータ、音声データ、画像データ等を取得し、相手ユーザの端末100等に取得されたデータを出力することで、チャットを実行する。
【0031】
出力管理部550は、ユーザ同士の関係性を維持または改善するための処理を行う。図示の出力管理部550は、表象関係を管理する表象関係管理部551と、相互理解を管理する相互理解管理部553と、ストロークを管理するストローク管理部555と、潜在的相性を管理する潜在的相性管理部557と、相互援助を管理する相互援助管理部559と、ユーザに対して支援を実行する支援実行部561とを有する。
【0032】
(表象関係)
表象関係とは、表象に現れたユーザ同士の関係である。言い替えると、表象関係とはユーザ同士の関係の実態であり、ユーザ同士が互いにもつ感情や思考によって評価可能なものである。この表象関係は、ユーザ自身が他のユーザとの関係を感覚的に評価する表象評価により判定される。付言すると、表象関係は、対象とするユーザが他のユーザをどう思っているかを示す情報と、他のユーザから対象とするユーザがどう思われていると自分で感じるかを示す情報とを含んでもよい。また、表象関係は、対象とするユーザによる関係性評価を示す第1情報と、他のユーザによる関係性評価を示す第2情報とを含んでもよい。さらに、表象関係は、対象とするユーザが他のユーザをどう思っているかおよび他のユーザからどう思われていると感じるかとともに、他のユーザが自分をどう思っているかおよび他のユーザが自分にどう思われていると感じるかを示す情報の少なくとも一方を含んでもよい。
【0033】
なお、表象関係の取得方法は、例えば次のような態様でもよい。すなわち、表象関係の取得方法は、ユーザAおよびユーザBの関係性をユーザCに質問するなど、表象関係の対象となるユーザ(この例におけるユーザAおよびユーザB)以外の第三者(この例におけるユーザC)から取得する態様でもよい。また、表象関係の取得方法は、例えばユーザAに対して、ユーザAが所属するチームメンバー全員との関係性はどうかを質問してもよい。なお、この質問は、チーム全体、すなわちチームメンバーの各々に対して行ってもよい。また、表象関係の取得方法は、例えば後述する侵襲性に基づいて質問群を分けてもよい。そして、チームの状態に基づいて、どの質問群で表象関係を取得するか切り替える態様でもよい。さらに説明をすると、EQ、心理的安全性、あるいはストロークの実態等に基づいて、侵襲性の程度が異なる複数の質問群からいずれかの質問群を選択する態様でもよい。また、表象関係の取得は、ユーザから評価を直接取得することに替えて、あるいは直接取得することともに、ユーザの行動履歴などから推定するなどユーザの行動履歴に基づいて判断する態様であってもよい。さらに説明をすると、表象関係の取得は、他のユーザに関連する情報(総合情報)から推定する態様でもよい。
【0034】
(根本的実体)
表象関係は、上記のようにユーザ同士の表象に現れた実態である。一方、ユーザ同士の関係の実態のうち、表象に現れていない、あるいは表象関係と比較してユーザが認識し難い関係の実態を、根本的実体とする。根本的実体は、種々の要因により評価され得る。根本的実体は、例えば相互理解、ストローク、潜在的相性および相互援助によって評価される。なお、以下においては、相互理解およびストロークを基礎要因と呼ぶことがある。また、潜在的相性および相互援助を補助要因と呼ぶことがある。
【0035】
(相互理解)
相互理解とは、ユーザ同士における互いについての理解(お互いのりかい)である。言い替えると、相互理解は、対象とするユーザが他のユーザに関して認識している知識の量によって評価可能なものである。相互理解は、対象とするユーザに関する情報であって、かつ対象とするユーザが他のユーザと共有している情報である。言い替えると、相互理解は、他のユーザの脳内における認識や評価により定まる。相互理解は、ユーザ同士の分かり合いとして捉えることができる。この相互理解は、各ユーザの属性の共通点、相違点および尊敬点によって判定される。ここで、共通点は、各ユーザの属性のうち対象とするユーザ同士で共通する属性である。相違点は、各ユーザの属性のうち対象とするユーザ同士で相違する属性である。尊敬点は、対象とするユーザの属性のうち、対象とするユーザの長所となり得る属性である。言い替えると、尊敬点は、対象とするユーザの特徴点である。ここで、尊敬点は、少なくとも対象とするユーザ以外のユーザが実際に認識している尊敬点と、対象とするユーザおよび他のユーザのいずれも認識していない潜在尊敬点とを含む。なお、潜在尊敬点は、他のユーザからみて尊敬点となり得るユーザの特徴点として捉えることができる。
【0036】
なお、相互理解は、ユーザ同士がお互いをどう好きか、ユーザ同士がお互いをどう思っているか、ユーザが他のユーザをどう思っているか、ユーザ同士の信頼関係、他のユーザに行ってほしくない言動、他のユーザに行われると嬉しい言動、他のユーザに感謝できる言動、他のユーザの好みなどの理解を含む。この相互理解は、ユーザから取得され、ユーザ同士で共有できるよう、各ユーザに出力される態様でもよい。
【0037】
ここで、相互理解は、ユーザによる認知として捉えることができる。付言すると、例えばユーザの行動などユーザによる認知以外の事象は、ユーザのストロークとして捉えることができる。すなわち、ユーザによる認知ではないもの、あるいはユーザの外に出てくるものは全てストロークとして捉えることができる。
【0038】
(ストローク)
ストローク(stroke)とは、対象とするユーザの言動であって、他のユーザに関して行う言動である。さらに説明をすると、ストロークは、対象とするユーザの他のユーザに対する振る舞い、すなわち他のユーザに対する言動である。言い替えると、ストロークは、対象とするユーザの他のユーザに対する態度である。さらに言い替えると、ストロークは、対象とするユーザの動作であって、かつ他のユーザによって認識可能な動作である。また、ストロークは、対象とするユーザと他のユーザとの関わり(かかわり)として捉えることができる。ストロークの例としては、他のユーザへの声掛けや、挨拶、アイコンタクトなどがある。また、ストロークの他の例としては、他のユーザを褒めるアドバイスである「ほめアドバイス」、他のユーザを叱る「しかりアドバイス」、また他のユーザを褒めるとともに叱るアドバイスである「ほめしかりアドバイス」などがある。上述のように、ストロークは、ユーザによる認知以外の事象として捉えることができる。また、ストロークは、ユーザ同士が互いに関係する全ての行動として捉えることができる。
【0039】
ストロークは、他のユーザの存在を肯定する言動である肯定ストロークと、他のユーザの存在を否定する言動である否定ストロークとを含む。また、ストロークは、無条件で行うストロークである無条件ストロークと、他のユーザが特定の言動をしたなどの条件付きで行うストロークである条件付きストロークとを含む。また、ストロークは、ストローク自体を全くしない、すなわち他のユーザに対してなんら言動を行わないノンストロークを含む。付言すると、ノンストロークは、他のユーザの存在を認めない言動、すなわち他のユーザを無視する態度として捉えることができる。
【0040】
以下の説明におけるストロークは、複数の種別を含むものとする。具体的には、以下、ストロークは、無条件肯定ストローク、条件付き肯定ストローク、条件付き否定ストローク、無条件否定ストロークおよびノンストロークを含むものとする。
【0041】
ここで、無条件肯定ストロークは、無条件で他のユーザを肯定するストロークである。無条件肯定ストロークは、他のユーザの存在そのものを受容する行為である。いわば、無条件肯定ストロークは、無償の愛である。この無条件肯定ストロークの例としては、例えば他のユーザに対して生まれてきてくれてありがとうと伝えること、他のユーザに対して挨拶をすること、他のユーザがケーキを好きなことを知っている場合に他のユーザのためにケーキを買ってくることなどが含まれる。
【0042】
また、条件付肯定ストロークは、特定の行動を他のユーザが行ったことなど条件付きで他のユーザを肯定するストロークである。言い替えると、条件付肯定ストロークは、他のユーザが条件を満たす場合に行う他のユーザを受容する行為である。条件付肯定ストロークは、例えばこの前のあの仕事よくできていた、他のユーザは温厚な性格だからいいなどを他のユーザに対して伝えることである。また、条件付肯定ストロークは、採血が上手だねなど、他のユーザを褒めるの発言も含まれる。
【0043】
また、条件付否定ストロークは、特定の行動を他のユーザが行ったことなど条件付きで他のユーザを否定するストロークである。言い替えると、条件付否定ストロークは、他のユーザが条件を満たす場合に行う他のユーザに対する攻撃である。条件付否定ストロークは、例えば作成した資料の記載が不正確でいまいちであった、受験した試験における点数が不十分でよくなかったなどを他のユーザに対して伝えることである。また、条件付否定ストロークは、バカなのかなど、他のユーザを侮辱する発言も含まれる。
【0044】
また、無条件否定ストロークは、無条件で他のユーザを否定するストロークである。無条件否定ストロークは、他のユーザの存在そのものを否定する他のユーザに対する行為である。いわば、無条件否定ストロークは、他のユーザの存在価値を否定する他のユーザへの攻撃である。いわば、無条件否定ストロークは、人格否定である。無条件否定ストロークは、例えばお前はダメな奴だ、お前なんかいなければいいのになどの発言、あるいは相手に対する嘲笑である。なお、無条件ストロークは、条件付否定ストロークよりもより攻撃的な言動として捉えることができる。
【0045】
また、ノンストロークは、上記のように他のユーザに対してなんら言動を行わないことである。ノンストロークは、他のユーザの存在を否定し他のユーザに対する言動を放棄することである。いわば、ノンストロークは、他のユーザに対して無関心な状態である。ノンストロークは、例えば無視すること、挨拶をしないなどが含まれる。
【0046】
ここで、無条件肯定ストロークは、成果に関わらずポジティブな印象を与えるかかわり方として捉えることができる。条件付き肯定ストロークは、成果を残した時などに相手のことをほめたり認めたりするかかわり方として捉えることができる。条件付き否定ストロークは、ミスなどの悪いことをしてしまった時、怒るなどの否定をするかかわり方として捉えることができる。無条件否定ストロークは、成果に関わらずネガティブな印象を与えるかかわり方として捉えることができる。ノンストロークは、そもそもかかわらないという態度として捉えることができる。なお、肯定ストロークは、ポジティブなかかわりや前向きなかかわりとして捉えることができる。また、否定ストロークは、ネガティブなかかわりや後ろ向きなかかわりとして捉えることができる。
【0047】
また、無条件肯定ストローク、条件付き肯定ストローク、条件付き否定ストローク、無条件否定ストロークおよびノンストロークは、例えばこの順でユーザ同士の関係において好ましいものである。さらに説明をすると、ユーザ同士の関係において、無条件肯定ストロークおよび条件付き肯定ストロークは増加させることが好ましい。また、ユーザ同士の関係において、条件付き否定ストロークおよび無条件否定ストロークは減少させることが好ましい。また、ユーザ同士の関係において、ノンストロークは無くすことが好ましい。さらに説明をすると、ノンストロークは不要なストロークである。本システムは、ストローク全体における無条件肯定ストロークの量および条件付き肯定ストロークの量の占める割合が増加するよう制御する。例えば、無条件肯定ストロークの量および条件付き肯定ストロークの量が、条件付き否定ストロークの量および無条件否定ストロークの量より多くなるよう制御する。また、本システムは、ノンストロークを無くすよう制御する。
【0048】
なお、ストロークは、対象とするユーザが他のユーザに対して行う言動である能動ストロークと、対象とするユーザが他のユーザから受ける言動である受動ストロークとを含む。また、ストロークの内容は、対象とするユーザの心身の状態に応じて変化することがある。例えば、対象とするユーザが感じるストレスが高い場合に、対象とするユーザの能動ストロークおよび受動ストロークの内容が変化し得る。能動ストロークに関連する変化としては、例えば、対象とするユーザが他のユーザを怒鳴りやすくなる、他のユーザから顔を背けやすくなる、真剣に他のユーザの話を聞けなくなることなどがある。また、受動ストロークに関連する変化としては、対象とするユーザが他のユーザの言動により傷つきやすくなる、言葉により敏感に反応するようになることなどがある。
【0049】
ここで、対象とするユーザが行うストロークは、ユーザの心身の状態に応じて変化することがある。例えば、低気圧が近づいてきて精神的に落ち込むとき、寝不足のとき、忙しいときなどには、対象とするユーザが他のユーザと会話する際に口調がきつくなるなど、対象とするユーザのストロークが相対的に悪化することがある。そこで、本システムは、対象とするユーザのストロークが悪化する所定の条件を満たす場合は、他のユーザに対して対象とするユーザの心身の状態が良好でないことを通知してもよい。また、このようなストロークが悪化する所定の条件を満たすと、対象とするユーザのストロークが悪化する(変化する)可能性があることを、他のユーザに対して通知してもよい。また、対象とするユーザの心身の状態が所定の条件を満たすと、対象とするユーザのストロークが悪化する傾向がある(可能性がある)ことを他のユーザに通知してもよい。また、対象とするユーザのストロークが悪化する可能性や傾向を通知するとともに、対象とするユーザのストロークが悪化した場合でも対象とするユーザを受け入れて欲しいというメッセージを出力してもよい。
【0050】
さて、対象とするユーザがストロークを認知するモデル(態様)であるストローク認知モデルとして、ストローク受動認知モデルと、ストローク能動認知モデルがある。ストローク受動認知モデルは、対象とするユーザがストロークを受ける際にどのような心理的な状態となるか、すなわち対象とするユーザが他のユーザからのストロークを受けた際にどのような心理的な反応が起こるかを示す。付言すると、ストローク受動認知モデルは、ストロークを受けたユーザが、受けたストロークを肯定ストロークおよび否定ストロークのいずれと捉えるかを示す。また、ストローク能動認知モデルは、対象とするユーザがストロークを行う際にどのような心理的な状態でそのストロークを行うのかを示す。付言すると、ストローク能動認知モデルは、ストロークを行うユーザが、自身が行うストロークを肯定ストロークおよび否定ストロークのいずれと捉えるかを示す。
【0051】
ここで、本システムにおいてストローク受動認知モデルおよびストローク能動認知モデルを利用することによって、ユーザに対して出力されるアドバイスの質が向上し得る。例えば、ストローク受動認知モデルによって、職場のユーザに対して出力されるアドバイスがより適切となり得る。さらに説明をすると、職場のユーザから、その職場において肯定ストロークと認知されているストロークを予め特定し、その特定されたストロークが職場における肯定ストロークなのでより多く行うよう促すアドバイスを職場の全ユーザに出力してもよい。なお、特定されたストロークを多く行うことを促さない態様でもよく、例えば特定されたストロークが職場において肯定ストロークとして認知されていることを通知する態様でもよい。
【0052】
また、ストローク受動認知モデルおよびストローク能動認知モデルは、各ユーザが対象とする言動を肯定ストロークおよび否定ストロークのいずれと捉えているかを示す。本システムにおいて、ストローク受動認知モデルとして、対象とするユーザが肯定ストロークとして捉える言動、あるいは否定ストロークとして捉える言動を、他のユーザに対して出力してもよい。例えば、対象とするユーザにとっての肯定ストロークおよび否定ストロークにあたる言動のリストを、他のユーザに出力してもよい。このように、各ユーザが対象とするストローク(言動)をどのように捉えているのかをユーザ同士が共有することで、ユーザ同士のコミュニケーションの質が向上し得る。
【0053】
(潜在的相性)
潜在的相性とは、ユーザ同士の相性の一例である。さらに説明をすると、この潜在的相性は、表象化しておりユーザ自身が認識可能な相性に加えて、表象化しておらずユーザ自身が認識していない相性を含む。この潜在的相性が良い場合は、ユーザ間において衝突が発生する可能性が低い。また、潜在的相性が悪い場合は、ユーザ間において衝突が発生する可能性が高い。したがって、潜在的相性は、ユーザ間において衝突が発生する確率を示すものとして捉えることができる。また、潜在的相性は、現時点でユーザ同士が相性が良いと感じていない場合であっても、将来ユーザ同士が相性が良いと感じる確率を示すものとして捉えることができる。いわば、潜在的相性は、ユーザ同士の相性が良くなることの期待値である。以下の例における管理装置500は、潜在的相性の要素である相性要素として、性格傾向、趣味、価値観、および実体情報の各要素によって評価する。
【0054】
なお、この相性要素で評価される相性とは、ユーザ同士の性格や調子などの合い方である。対象とする相性要素の内容が、ユーザ同士で一致するまたは類似すると相性がよいと判断される。なお、対象とする相性要素が一致しない場合であっても、例えば性格傾向が外向的と内向的であるなど特定の関係性がある場合には、相性がよいと判断されることがある。
【0055】
ここで、潜在的相性としては、ユーザ同士の関係性を示すユーザ間相性度と、チームにおける相性度のバランス(偏り)を示すチーム内相性度とを含む。さらに説明すると、ユーザ間相性度において、ユーザ同士の関係性は、性格傾向、趣味、価値観、および実体情報の要素で判断される。また、チーム内相性度において、性格傾向、趣味、価値観および実体情報の要素で判断されるユーザ同士の関係性が、チーム内における偏りで判断される。
【0056】
(相互援助)
相互援助とは、ユーザ同士が相互に助け合う、すなわち相互に援助することをいう。相互援助は、ユーザ同士の助け合いとして捉えることができる。さらに説明をすると、相互援助は、ユーザ同士の関係において、何らかの要因で対象とするユーザが不調である場合に、他のユーザが不調であるユーザに対して実行する援助をいう。相互援助は、ユーザ同士の助け合いとして捉えることができる。相互援助は、対象とするユーザの不調時の落ち込みを抑制するための他のユーザの行為として捉えることができる。ここで、不調とは、対象とするユーザの心身の調子(状態)が良好でないことをいう。この不調の具体例としては、低気圧など気象による不調、何かショックな出来事があったゆえの心理的な落ち込みに関する不調、プライベートの要因による不調、職場でタスクが積まれすぎるなどの業務上の不調などがある。また、援助とは、不調であるユーザの心身の状態を改善するまたは維持する言動である。援助の具体例としては、不調であるユーザに対して声をかける、不調であるユーザに休憩を取ることを促す、不調であるユーザと話すときに穏やかな表情で話す、タスクの一部を行うなどがある。
【0057】
ここで管理装置500は、相互援助として、ユーザが相互に援助することの必要性をユーザに理解させること(必要性理解)、ユーザが相互に援助を必要とする場面等を相互に理解させること(場面理解)、およびユーザが相互に援助を求めることがより容易になるよう相互援助を促すこと、あるいは特定のユーザが援助を必要としているかもしれない状況を推定し特定のユーザ以外の他のユーザに援助を促すこと(援助促進)によって、介入を行ってもよい。特定のユーザが援助を必要としている状況と推定される例としては、例えば、以下のものがある。すなわち、忙しさ情報を取得して忙しいと判定されるとき、心理的に落ち込んでいるなど心のエネルギーが低いとき、体調不良など体のエネルギーが低いとき、営業成績がよくないなどパフォーマンス状態が低いときなどは、特定のユーザが援助を必要としている状況と推定される。
【0058】
(関係性支援処理)
管理装置500によって実行される支援処理のうちの一つである関係性支援処理の概略は以下の通りである。まず、管理装置500は、ユーザ同士が所定期間(例えば1週間)でどの程度(例えば回数、時間)雑談をするかなどユーザ同士の関係性の実態を示す情報を取得して、その実態が、ユーザ同士が円滑に動いていくために良好な状態となるよう介入をする。さらに説明をすると、例えばユーザが職場などの集団(チーム)に属する場合、そのチーム内におけるユーザ同士の関係性が良好な状態となるような支援を実行する。
【0059】
ここで、関係性の実態が良好である場合、管理装置500はそのチームに適した介入を行い、関係性が良好である状態を維持することを支援する。また、全体として関係性の実態が良好であるが、関係性として不足している部分がある場合、管理装置500は不足している部分が解消し、関係性がより良好となる支援をする。
【0060】
また、関係性の実態が良好な状態でない場合、管理装置500が関係性の実態を改善する方法は2つある。1つは、関係性の実態そのものを改善する直接的な支援である。2つめは、関係性の実態そのものではなく、関係性の実態に直接関係していない状態を変容させる間接的な支援である。間接的な支援は、例えば直接的な支援による改善が不可能な場合、あるいは直接的な支援による改善が困難な場合に実行されてもよい。言い替えると、間接的な支援は、直接的な支援による実行では支援が不十分であることを条件として実行されてもよい。間接的な支援としては、例えば関係性の実態で改善すべきと判断された事項とは関係なく、例えばユーザ同士の会話やチャット実行部530を介したチャットなどのコミュニケーションが促進される処理を管理装置500が実行する。
【0061】
本実施の形態における関係性支援処理は、表象関係処理、相互理解処理、ストローク処理、潜在的相性処理および相互援助処理の各処理を含む。なお、関係性支援処理に含まれる各処理の詳細については後述する。また、以下の説明においては、対象とするユーザが職場における3人以上のメンバー(ユーザ)で構成されたチームに所属し、このチームにおけるユーザ同士の関係性を維持または改善する支援を例に説明する。このチームは、新たに形成されたチームではなく、形成されてから所定時間(例えば3週間)が経過したチームである。したがって、チームを構成するユーザ同士においては、なんらかの関係性が発生しているものとする。なお、以下で説明するチームを構成するユーザの数は3人以上に限定されず、2人であってもよい。
【0062】
(優先度)
管理装置500によってユーザに対して出力される支援情報は1つであっても複数であってもよい。ここで、出力される支援情報は、優先度(優先順位)に応じて選択される。さらに説明をすると、まず、ユーザに対して出力される支援情報が多くなると、例えばユーザがどの支援情報を実行すべきかで悩むなど、ユーザが使いづらさを感じることがある。このことを抑制するため、管理装置500は支援情報を選択して出力する。
【0063】
例えば、複数のユーザからなるチームにおいては、チームを構成するメンバーである各ユーザの情報を取得し、出力する支援情報に優先度をつけ、優先度が高いものから優先的に支援情報を出力する。なお、優先的に支援情報を出力することの具体例としては、優先度が所定の順位(例えば1番目)までの支援情報を出力すること、優先度の順に時間差で支援情報を出力すること、優先度の順位が高いものほど情報量が多くなるよう支援情報を出力することなどが含まれる。
【0064】
付言すると、以下で説明をする支援処理においては、根本的実体の処理を基準として、表象関係の処理をより高い優先度とする。さらに説明をすると、表象関係処理によって出力される支援情報の量に応じて、根本的実体の処理によって出力される支援情報の量を低減させる。このことにより、表象関係の処理を根本的実体の処理よりも優先させることができ、表象関係の管理がより確実に実行される。
【0065】
また、管理装置500は、根本的実体の処理、すなわち相互理解処理、ストローク処理、潜在的相性処理および相互援助処理のうち、相互理解処理およびストローク処理を、潜在的相性処理および相互援助処理よりも高い優先度とする。このことにより、ユーザに対して出力される支援情報を制限しながら、ユーザに対する支援をより効率よく実行し得る。
【0066】
<テーブルの構成>
図3(A)はユーザ情報TB511の一例を示す図であり、
図3(B)はコンテンツTB521の一例を示す図であり、
図3(C)はコンテンツTB521に含まれる関係性支援コンテンツの詳細を示す図である。
【0067】
ユーザ情報TB511およびコンテンツTB521は、各ユーザが端末100等を介して入力した情報に基づいて生成された情報などを記憶する。以下、各テーブルについて説明する。
【0068】
<ユーザ情報TB511>
ユーザ情報TB511は、各ユーザに関するユーザ情報をユーザごとに管理する。この例においては、ユーザ情報として、ユーザの属性に関する情報を記憶する。
【0069】
図3(A)に示すように、ユーザ情報TB511におけるユーザ情報は、ユーザの属性に関する属性情報と、ユーザの思考に関する思考情報と、ユーザの心身の状態に関する心身状態情報と、ユーザの他者との関係性に関する他者関係性情報とを含む。図示の例において、属性情報は、対象とするユーザのユーザ名、年齢、性別、家族構成、趣味、職種、職位、所属チームを含む。また、思考情報は、対象とするユーザの性格傾向、思考・価値観、将来像、思考力、忘却特性を含む。また、心身状態情報は、対象とするユーザの精神状態、生理情報、忙しさ、タスクの割合を含む。また、他者関係性情報は、相互理解情報、ストローク情報、潜在的相性情報、相互援助情報を含む。
【0070】
ユーザ情報は、対象とするユーザが情報処理システム1を初めて利用するタイミング、および所定期間(例えば2か月)ごとなどの所定のタイミングで実行される登録処理(後述)において、端末100等を介してユーザから指示を受け付けるなどして、ユーザ情報TB511に記憶される。
【0071】
ここで、属性情報のユーザ名、年齢、性別、家族構成、趣味、職種、職位、所属チームは、端末100等においてユーザからの入力を受け付けることで取得される。この属性情報は、ユーザの実情を示す実情情報として捉えることができる。
【0072】
属性情報に含まれる家族構成は、ユーザの家族の構成を示す。ここでの家族構成は、例えば「配偶者の有無」、「子供の有無」、「要介護者の有無」などである。趣味は、ユーザの趣味の種別を示す。趣味は、例えば「野球観戦」、「キャンプ」、「読書」、「旅行」などである。職種は、ユーザの仕事の種別を示す。ここでの職種は、例えば「営業職」、「デザイナー職」、「開発職」などである。職位は、ユーザが所属する会社組織における地位を示す。職位は、例えば「部長」、「課長」、「平社員」などである。なお、職位は会社におけるユーザの立場の一例として捉えることができる。ここで、会社における立場の他の例としては、会社における権限の有無(例えば、決裁権や人事権など)や、会社における社歴(1年、10年など)などがある。所属チームは、ユーザの会社内におけるユーザが所属するチームである。この所属チームの例としては、「新製品開発チーム」や「営業部第1課」などである。なお、属性情報はこれらに限定されない。例えば、属性情報は、学生時代にやっていたスポーツや、ユーザの人生に影響を与えた経験など他の情報を含んでもよい。
【0073】
性格傾向は、ユーザの性格、より具体的にはユーザの物の見方や感じ方を示す。性格傾向は、端末100等において実行されるビッグファイブ(Big Five personality traits)、MBTI(Myers-Briggs Type Indicator)、NEO-FFI、NEO-PI-R、エニアグラム、エゴグラム、ホランドの理論等のテストにより取得される。また、性格傾向は、原体験情報や人間関係価値観情報などに関するテスト(質問)により取得される。性格傾向は、例えば協調性、神経症的傾向、開放性、誠実性、外向性の各項目において6段階の数値(1乃至6)で評価される。なお、各数値が高いほど、対象項目の要素を満たしていることを示す。
【0074】
思考・価値観は、ユーザの思考および価値観を示す。思考・価値観は、ユーザ自身の欲求、対象とするユーザにとって重要なもの、自我関与度が高いものとして捉えることができる。思考・価値観は、端末100等においてユーザに対して質問を表示し、ユーザからの入力を受け付けることで取得される。思考・価値観は、例えばキャリアアンカー、健康、寿命、美容、物欲、異性などからもてたい、お金、趣味、家族と仲良くしたい、他人と仲良くなりたい、動物を飼いたいなどのうちから、ユーザが自身にとって重要な項目や個人の欲求を選択することにより取得される。
【0075】
なお、キャリアアンカーは、端末100等において例えば40個の質問がユーザに対して出力される。この質問は、それぞれ、キャリアの中で大切にしている価値観のカテゴリーのいずれにユーザが分類されるかを判断するための、カテゴライズがなされている。そして、全ての質問の8個用意された、キャリアにおいて大事にしているもの(例えば、管理職として働く)の数値で評価される。さらに説明をすると、8個のうち数値が高かった上位3つが、ユーザのキャリアアンカーとして選択される。このキャリアアンカーは仕事についての価値観として捉えることができる。
【0076】
将来像は、ユーザが将来なりたい理想の姿を示す。将来像は、「社長」、「お金持ち」、「元気な100歳」、「よき父(母)」、「海外移住者」などである。将来像は、端末100等においてユーザからの入力を受け付けることで取得される。
【0077】
思考力は、ユーザの思考する能力を示す。思考力は、端末100等においてIQ(Intelligence Quotient)、EQ(Emotional Intelligence Quotient)、GMAT(Graduate Management Admission Test)、SAT(Scholastic Aptitude Test)、SPI(Synthetic Personality Inventory)、特定の分野における資格取得の試験(例えば司法試験)等のテストが実行され、テスト結果(スコア)が6段階の数値(1乃至6)で評価されている。なお、この思考力の数値が高いほど、思考力が高いことを示す。また、端末100等においてテストを実行せず、ユーザが自身で過去に受けたテストの結果であるIQ等のスコアをユーザから受け付け、思考力を示す情報としてもよい。
【0078】
忘却特性は、ユーザの物事の記憶に関する能力(特性)を示す。忘却特性は、物事の記憶に対する適性の高低などにより評価される。なお、忘却特性は、端末100等においてユーザに対して質問を表示し、ユーザからの入力を受け付けることで取得される。付言すると、忘却特性は、所謂忘却曲線と呼ばれる、記憶した内容が時間の経過にともない忘却されていく態様を示すグラフ等を用いて算出してもよい。
【0079】
精神状態は、ユーザの精神の状態を示す情報である。端末100等に質問を表示し、ユーザから自身の精神状態の良好さについて回答を受け付けることで取得される。精神状態は、例えばユーザ自身による判断によって6段階の数値(1乃至6)で評価されている。なお、精神状態の数値が高いほど、ユーザの精神状態が良好であることを示す。
【0080】
生理情報は、ユーザの身体の状態を示す情報である。生理情報は、例えば、心拍数、体温、皮膚温、発汗量、血圧、脳波、呼吸の頻度、睡眠時間、睡眠の質、声、表情、視線、まばたきの頻度などである。生理情報は、端末100等に設けられたセンサ(不図示)によって取得された生体情報(心拍数、体温、発汗量など)の分析結果や、マイク(不図示)によって取得されたユーザの声の分析結果、カメラ(不図示)によって取得された身体の特徴データである顔画像(表情、視線など)の分析結果等から算出される。また、生理情報は、端末100等に質問を表示し、ユーザからの回答を受け付けることで取得される。また、生理情報の情報は、所定期間ごとに(例えば毎日)、あるいは所定のタイミングで(例えばユーザがシステムを利用開始する際の操作時)、端末100等を介してユーザから受け付けられる。
【0081】
なお、ユーザの生理情報は、カメラによって取得された身振り、手振り、貧乏ゆすりなどユーザの体の動き(体動)を示す体動情報の分析結果から算出してもよい。また、ユーザの生理情報は、光トポグラフィーを用いて脳活動状態の分析結果から算出してもよい。また、ユーザの生理情報は、ユーザの発話やテキストメッセージや、勤務先である会社の勤怠記録などの分析結果から算出してもよい。
【0082】
忙しさは、ユーザの忙しさの程度を示す。忙しさは、端末100等に質問を表示し、ユーザからの回答を受け付けることで取得される。忙しさは、例えばユーザ自身による判断により6段階の数値(1乃至6)で評価されている。なお、忙しさの数値が高いほど、ユーザが忙しい、すなわちユーザの心身に負荷がかかる状態であることを示す。
【0083】
なお、忙しさの情報は、ユーザからの回答に基づいて特定をするが、ユーザ情報管理部510がユーザのスケジュールを取得することで算出してもよい。さらに説明をすると、忙しさの情報は、ユーザ情報管理部510が、ユーザが利用するスケジュール帳(手帳)の画像を読み込むことで取得してもよいし、端末100等において利用されるタスク管理ツールやプロジェクト管理ツールからスケジュールデータを取得してもよい。また、忙しさの情報は、ユーザ情報管理部510が、ユーザが端末100等を介して送受信するメールの件数に基づいて算出してもよいし、メールの文面の自然言語処理で算出してもよい。付言すると、例えば、所定の期間において予定が入っている時間帯の割合などに基づいて、ユーザ情報管理部510がユーザの忙しさの情報を算出することにより、ユーザ自身が回答する負担が軽減されるとともに、ユーザ自身が自身の忙しさを自覚していない状態であっても、ユーザの心身に負担がかかっている状態を検知することができる。なお、忙しさの情報は、生体情報(心拍数、体温、発汗量など)から算出してもよい。例えば、心拍数が通常よりも高い場合は、心身に負荷がかかっている状態であるため、忙しいと判断される。
【0084】
タスクの割合は、ユーザの業務におけるタスクの状態を示す。言い替えると、タスクの割合は、ユーザが現在行っている業務で実行が求められる要素の割合を示す情報である。ここでのタスクの割合は、端末100等に質問を表示し、ユーザからの回答を受け付けることで取得される。さらに説明をすると、例えば「新しいものを作る」、「何かを継続してやる」、「リスクヘッジをする」、「コミュニケーションをとる」、「エンジニアリング」、「部下を管理する」、「新規顧客を開拓する」、「広報文章を書く」、「市場分析をする」の各項目について、ユーザ自身の判断により6段階の数値(1乃至6)で取得し、全数値の総和における各項目が占める割合をタスクの割合として算出してもよい。
【0085】
なお、ユーザ情報は、上記各項目に限定されない。例えば、ユーザ情報は、レジリエンス(resilience)、心理的安全性、ストレス値、ウェルビーイングポイントなどを含んでもよい。
【0086】
ここで、レジリエンスは、外環境の変化やストレス環境の変化に対するユーザの心理的な耐性を示す。レジリエンスは、端末100等において実行されるテストにより評価される。レジリエンスは、「自分の軸」、「しなやかな思考」、「対応力」、「人とのつながり」、「セルフコントロール」、「ライフスタイル」の各項目を6段階の数値(1乃至6)で評価されている。なお、各数値が高いほど、対象項目の要素を満たしていることを示す。
【0087】
心理的安全性は、ユーザが所属する集団(例えば会社)で自分の考えを自由に発言したり行動に移したりできると考える心理状態を示す。言い替えると、心理的安全性は、集団における素直な雰囲気(スナオなふんいき)として捉えることができる。心理的安全性は、端末100等において実行されるテストにより評価される。心理的安全性は、6段階の数値(1乃至6)で評価されている。なお、数値が高いほど、心理的安全性が高いことを示す。
【0088】
ストレス値は、ユーザ自身が感じているストレスの程度を示す。ストレス値は、端末100等において実行されるストレスチェック、あるいは気分や心の健康度に関する質問等、メンタル状態に関する質問に対する各ユーザの回答から算出される。ストレス値は、例えば6段階の数値(1乃至6)を端末100等において受け付けて評価されている。なお、数値が高いほど、ストレスが高い、すなわち対象とするユーザが強いストレスを感じていることを示す。また、ストレス値は、例えば、端末100等に設けられたセンサによって取得されたユーザ情報(心拍数、血圧、脳波、体温、呼吸頻度、まばたきの頻度、睡眠時間、生活習慣、悩み度等)の分析結果から算出されてもよいし、画像認識によって得られた表情、身振り、手振りを含む身体の特徴データ等の分析結果から算出されてもよい。
【0089】
ウェルビーイングポイントは、ユーザが身体的、心理的、社会的に良好な状態であることの程度を示す。ウェルビーイングポイントは、端末100等において実行されるテスト、あるいは端末100等に設けられたセンサによって取得されたユーザ情報(心拍数、血圧、脳波、体温、呼吸頻度、まばたきの頻度、睡眠時間、生活習慣、悩み度等)の分析結果から算出されてもよい。なお、ウェルビーイングポイントの数値が高いほど、ユーザが良好な状態であることを示す。
【0090】
さて、ユーザ情報の取得方法として、既にユーザの年齢やキャリアアンカーなどを取得しているユーザ情報に基づいて、そのユーザに質問を実行する態様でもよい。例えば、対象としているユーザの年齢を既に取得している場合に、その年齢と同じ年代のユーザに人気がある、言い替えると同年代のユーザが好きな芸能人の情報を取得する。この芸能人情報を、対象とするユーザが好きな芸能人と推定する。そして、対象とするユーザに対して、推定された芸能人のことを好きであるか質問し、回答を受け付けてもよい。既に取得しているユーザ情報に基づいて、対象とするユーザに質問をすることで、ユーザがユーザ情報を入力する負担が低減され得る。
【0091】
(相互理解情報)
相互理解情報は、対象とするユーザと他のユーザとの相互理解に関する情報である。この例において相互理解情報は、他者提示可能情報と、相互理解度と、他者受容度と、自己受容度とを含む。相互理解情報は、端末100等においてユーザからの入力を受け付けることで取得される。
【0092】
また、相互理解情報は、ユーザに他のユーザに関する質問をしてその回答に基づいて取得する態様、すなわち理解度に基づいて取得してもよいし、理解度以外に基づいて取得(推定)してもよい。例えば、相互理解の情報は、ユーザ同士の会話の実態、ユーザ同士の関係性、ユーザ同士の潜在的な相性の一部または全部に基づいて習得してもよい。さらに説明をすると、相互理解の情報は、ユーザ同士の会話の頻度や時間を取得して、頻度が高い場合や時間が長い場合に、相互理解が進んでいる状態として推定してもよい。
【0093】
(他者提示可能情報)
他者提示可能情報は、対象とするユーザのユーザ情報であって、他のユーザに対して提示することが可能と考える情報である。他者提示可能情報は、対象とするユーザがチーム内で開示されることを許容するユーザ情報として捉えることができる。
【0094】
他者提示可能情報としては、例えばユーザの性格傾向や自身のルーツなどユーザを理解するための理解情報、遅刻するなどチーム内の他のユーザ(メンバー)がすると許せない言動、すなわち他のユーザが行うことを禁止したい言動の情報である禁止情報、早口で話すなど自身がやってしまう言動で他のユーザに許して欲しい言動の情報である許容情報、お金など自身がとても重要だと思っていること、すなわち自身が重視していることの情報である重視情報などを含む。なお、ここでは、他者提示可能情報が、理解情報、禁止情報、許容情報および重視情報を含むことを説明したが、これに限定されない。例えば、他者提示可能情報が、理解情報、禁止情報、許容情報および重視情報の一部のみを含む態様でもよい。付言すると、他者提示可能情報が、禁止情報および許容情報の少なくともいずれか一方を含むことで、ユーザ同士の関係性が悪化することが抑制され得る。
【0095】
なお、他者提示可能情報は、ユーザの性格傾向など時間経過にともなう変化が相対的に小さい情報と、ユーザが好きな芸能人など時間経過にともなう変化が相対的に大きい情報とを含む。そこで、時間経過にともなう変化が相対的に大きい情報は、小さい情報と比較して、情報取得の頻度が高くなるよう設定してもよい。さらに説明をすると、時間経過にともなう変化が相対的に大きい情報は、所定期間ごとに情報取得を行い更新し、相対的に小さい情報は、より長い期間ごとに更新する態様でもよい。また、時間経過にともなう変化が相対的に小さい情報は、ユーザ登録時などに取得した情報など、1度取得した後で更新をしない態様でもよい。
【0096】
(相互理解度)
相互理解度は、ユーザ同士が互いを理解している程度を示す情報である。相互理解度は、対象とするユーザがもつ他のユーザについての知識量として捉えることができる。相互理解度の取得は、例えば対象とするユーザに対して以下のような質問をすることによって取得してもよい。具体的には、「XXさんをどのくらい知っていると感じますか」という質問をユーザに対して出力してもよい。この質問に対する回答は、「全然知らない」、「少し知っている」、「まあ知っている」、「多少知っている」、「よく知っている」、「かなり知っている」の6段階のいずれであるかを数値(1乃至6)で受け付けるなどしてもよい。
【0097】
ここで、相互理解度としては、より詳細な項目ごとにユーザから取得してもよい。例えば、ユーザ同士の共通点についての相互の理解度である共通点理解度、ユーザ同士の相違点についての相互の理解度である相違点理解度、および尊敬点についての相互の理解度である尊敬点理解度などをユーザから取得する態様であってもよい。また、例えばユーザ同士の互いの主観に関して、相手の生い立ち、大切にしていること、好きなものおよび嫌なことなどの理解度を質問してもよい。そして、質問に対する各項目の回答を得て正答率などを数値化し、総合理解度として出力してもよい。また、この総合理解度に基づいて各ユーザにアドバイスを出力してもよい。
【0098】
(他者受容度)
他者受容度は、ユーザが他者を受容できる程度を示す情報である。他者受容度は、対象とするユーザがもつ心理的な余裕として捉えることができる。他者受容度の取得は、例えば以下のような質問をすることによって取得してもよい。具体的には、「他人の行動や基準が自分のものと矛盾しているように見えても、それを否定したり、嫌ったり、裁いたりしない」、「他人を支配しようとはしない」、「他人のために責任を取ろうとはしない」、「他人の価値や、自分との人間としての平等を否定しない。これは、特定の業績に関して平等であることを意味するものではない。自分が出会った人を上にも下にも感じない」、「人のために奉仕したいという気持ちがある。」という質問をユーザに対して出力してもよい。この質問に対する回答は、「全く当てはまらない」、「ほぼ当てはまらない」、「少し当てはまらない」、「少し当てはまる」、「ほぼ当てはまる」、「全て当てはまる」の6段階のいずれであるかを数値(1乃至6)で受け付けるなどしてもよい。なお、取得した他者受容度が低い場合、他者受容度を高めるようなコンテンツをユーザに提示してもよい。このことにより、ユーザ同士の関係性が向上し得る。
【0099】
(自己受容度)
自己受容度は、ユーザが自分自身を受容できる程度を示す情報である。この自己受容度は、自己肯定感と言い替えることができる。自己受容度の取得は、例えば以下のような質問をすることによって取得してもよい。具体的には、「外部からの圧力に頼るのではなく、主に内在する価値観や基準を指針とする」、「人生に対処する自分の能力を信じている」、「自分の行動に責任を持ち、その結果を受け入れることができる」、「他人からの賞賛や批判を素直に受け入れることができる」、「自分の中にある感情、動機、限界、能力、好ましい性質を否定したり、歪めたりしようとせず、むしろ自分を責めることなくすべてを受け入れる」という質問をユーザに対して出力してもよい。この質問に対する回答は、「全く当てはまらない」、「ほぼ当てはまらない」、「少し当てはまらない」、「少し当てはまる」、「ほぼ当てはまる」、「全て当てはまる」の6段階のいずれであるかを数値(1乃至6)で受け付けるなどしてもよい。なお、取得した自己受容度が低い場合、自己受容度を高めるようなコンテンツをユーザに提示してもよい。このことにより、ユーザ同士の関係性が向上し得る。
【0100】
(ストローク情報)
ストローク情報は、対象とするユーザと他のユーザの間との間で行われるストロークに関する情報である。この例においてストローク情報は、ストローク実情情報と、ストローク意識情報と、相互承認表明情報とを含む。ストローク情報は、端末100等においてユーザからの入力を受け付けることで取得される。
【0101】
(ストローク実情情報)
ストローク実情情報は、ユーザが行っているストロークに関する情報である。ストローク実情情報は、ユーザ同士が実際に行っている言動の評価を示す情報として捉えることができる。ストローク実情情報は、ユーザに対して自身が行っているストロークおよび他のユーザが行っているストロークについての質問をし、それに対する回答を受け付けることで取得される。具体的には、ストロークの種別(無条件肯定ストローク、条件付き肯定ストローク、条件付き否定ストローク、無条件否定ストロークおよびノンストローク)ごとに、ユーザに対して、ユーザ自身がどの程度そのストロークを行っているかを質問し、その回答を受け付ける。同様に、ストロークの種別ごとに、ユーザに対して、他のユーザがどの程度そのストロークを行っているかを質問し、その回答を受け付ける。
【0102】
例えば、無条件肯定ストロークに関して、ユーザ自身がどの程度そのストロークを行っているかに関する質問として、以下の質問をする。すなわち「何か成果を残したなどの条件無しでその人の存在そのものを認めるような関わり、具体的には、「自分からあいさつをする」、「相手の名前を呼んで話しかける」、非言語の肯定的ストロークの代表例は「うなずく」、「笑顔をおくる」などが挙げられます。あなたはどれくらいこれらの行為をしていると感じますか?」という質問をする。そして、この質問に対して、「ほとんどしない」、「まれにする」、「時々する」、「よくする」、「たいていする」、「いつもする」のいずれかをユーザが6段階の数値(1乃至6)で入力することで受け付ける。
【0103】
なお、ストロークは、ユーザの心身の状態によって態様が変化し得る。さらに説明をすると、ユーザの心身の状態が良好であるときや各ユーザが時間的に余裕のあるときなど平常の状態(平常状態)と、心身の状態が良好でないときや忙しいときなどユーザに所謂負荷がかかっている状態(負荷状態)とで、実行されるストロークが変化し得る。そこで、ストローク実情情報は、平常状態と負荷状態とでそれぞれ取得してもよい。例えば、実行される全ストロークにおいて各ストロークをどの程度実行しているかを示すストローク割合を、平常状態および負荷状態に分けてユーザから取得してもよい。付言すると、負荷状態の例として、ユーザが忙しいとき、あるいはストレスが溜まっているときのストロークの態様(モデル)を取得してもよい。
【0104】
また、平常状態のストロークと負荷状態のストロークとを比較することにより、対象とするユーザに負荷がかかるとストロークがどのように変化するかを把握し、支援情報に利用することができる。さらに説明をすると、例えば負荷状態における否定ストロークの割合が、平常状態と比較して大きくなる場合には、ユーザが負荷状態になったことを検知することにともない、否定ストロークが増えないよう注意を促す支援情報を対象とするユーザに対して出力してもよい。また、対象とするユーザ以外のユーザに対して、対象とするユーザの否定ストロークが増える可能性がある点と、否定ストロークが増えるのは対象とするユーザに負荷がかかっているためであり理解して欲しい点などを示す情報を出力してもよい。
【0105】
なお、ストロークの実情情報は、チームの全員に対して、メンバーを特定せず、他のユーザのストロークはどのような態様であるかの質問をし、得られた回答の全体スコアから推定する態様であってもよい。また、ストロークの実情情報は、チームの全員に対して、メンバーを特定する形で、上記質問をして、得られた回答の全体スコアから推定する態様であってもよい。また、ストロークの実情情報は、ユーザからの質問に対する回答を受け付けることに替えて、あるいは回答を受け付けることともに、ユーザの忙しさ情報や性格傾向から推定してもよい。
【0106】
(ストローク意識情報)
ストローク意識情報は、ユーザのストロークに関する意識(理解)を示す情報である。このストローク意識情報は、ユーザが他者に対してストロークを適切に行うことの意義についての理解を示す情報を含む。さらに説明をすると、ストローク意識情報は、各ユーザが行うストロークによって、他のユーザあるいはチームに影響があることの理解の程度を示す情報として捉えることができる。いわば、ストローク意識情報は、ストロークの重要性をユーザが承認している程度を示す情報となる。例えば、ストローク意識情報は、各ユーザが良好なストロークを行うことにより、チーム内における信頼関係、各ユーザの自己肯定感、エンゲージメント、またそれに付随するチームパフォーマンス、組織全体パフォーマンスが好ましい状態となることを認識しているかの情報となる。ストローク意識情報は、ユーザに対して自身が行っているストロークおよび他のユーザが行っているストロークについての重要性について質問をし、それに対する回答を受け付けることで取得される。
【0107】
なお、ストローク意識情報は、対象とするユーザがどのようなストロークを肯定ストロークあるいは否定ストロークと捉えているのかを含んでもよい。また、ストローク意識情報は、対象とするユーザが、各種別のストロークを他のユーザからされることにより、どのような感情的な反応をするか(例えば傷つくや嬉しいなど、どのような感情となるか)を示す情報を含んでもよい。例えば、対象とするユーザが、否定ストローク(条件付き否定ストロークおよび無条件否定ストローク)を他のユーザからされることによってどの程度心理的に傷つくかなど、否定ストロークの受動的な反応についての情報(否定的反応情報)を含んでもよい。また、対象とするユーザが、肯定ストローク(無条件肯定ストロークおよび条件付き肯定ストローク)を他のユーザからされることによって、どの程度嬉しいと感じるかなど、肯定ストロークの受動的な反応についての情報(肯定的反応情報)を含んでもよい。さらに説明をすると、これらの否定的反応情報および肯定的反応情報に基づいて、対象とするユーザに出力される支援情報が変化してもよい。例えば、否定的反応情報が否定ストロークに対して心理的に傷つく程度が大きい場合、対象とするユーザに深刻に考えすぎないようアドバイスする支援情報を出力してもよい。また、この場合に、対象とするユーザにアドバイスするとともに、あるいはこのアドバイスに替えて、他のユーザに対して対象とするユーザへの言動に注意するようアドバイスする支援情報を出力してもよい。
【0108】
ここで、ユーザ同士の関係性が良好である場合、例えば所謂冗談や愛情表現の一つとして、疑否定ストロークを行うことがある。この疑否定ストロークは、他者から見ると否定ストロークと捉えられる可能性があるが、ユーザ同士においては肯定ストロークと捉えられる言動である。そして、疑否定ストロークを受けたとしても、関係性が良好であれば対象とするユーザが心理的に傷つくのではなく、むしろ嬉しいと感じることがある。そこで、肯定的反応情報としては、特定のユーザからは特定の否定ストロークを受けることで嬉しいと感じてその特定の否定ストロークを受け入れられるかなどの情報(疑否定ストローク許容情報)を含めてもよい。そして、ユーザ同士の相互理解度が所定値以上であるなど、ユーザ同士の関係性が良好であることを条件として、疑否定ストローク許容情報をユーザから取得してもよい。この疑否定ストローク許容情報に基づいて、特定のユーザ同士が無条件否定ストロークあるいは条件付否定ストロークを行った場合であっても、ユーザに対して深刻に考えすぎないようにするアドバイスなどを出力しない、所謂禁則処理を行ってもよい。一方で、チームにおける他のユーザは、例え関係性が良好であるユーザ同士であってもチーム内で無条件否定ストロークを好ましくないと思うことがある。このようなユーザがいる場合には、良好な関係にあるユーザに対して、他のチームメンバーが否定的な感情を持つことがあるので、無条件否定ストロークはやめるようアドバイスをしてもよい。
【0109】
(相互承認表明情報)
まず、相互承認表明について説明をする。上記のように、ストロークは、対象とするユーザの他のユーザに対する言動である。ここで、ストロークに含まれるユーザの言動の一態様として、相互承認表明がある。この相互承認表明とは、例えばユーザ同士が互いに感謝を伝えることである。ここでの感謝とは、他のユーザの行動に対して、肯定的な感情(プラスの感情)を抱くことである。なお、相互承認表明をユーザに実行させるため、他のユーザが行った行動で感謝していることを、その行動を行った他のユーザに伝えるよう促してもよい。
【0110】
ここで、ユーザが他のユーザに対して感謝を表明している程度(状況)である感謝表明状況をユーザから取得してもよい。あるいは対象とするユーザの感謝表明状況を他のユーザに質問し、他のユーザから回答を受け付けることで取得してもよい。この感謝表明状況は、例えばありがとうと発言することや、感謝を伝えるメッセージを送信することの回数に基づいて判断される。さらに説明をすると、例えば所定期間内にありがとうと発言したあるいはメッセージを送信した回数が所定値を超える場合、感謝表明状況は良好である。
【0111】
また、感謝表明状況に基づいて、他のユーザに感謝を伝えるよう対象とするユーザにアドバイスしてもよい。例えば、感謝表明状況が悪い、すなわち感謝を伝えることができていないユーザに対して、感謝を伝えるよう促すワークを多く出力してもよい。例えば、通常のユーザに対して、感謝を伝えるよう促すワークを基準回数(例えば2週間に1回)出力するものとする。一方、感謝表明状況が悪いユーザに対しては、基準回数よりも多い提示回数(例えば1週間に3回)出力してもよい。
【0112】
なお、感謝表明状況が悪い状態は、感謝を伝えるべき相手である他のユーザと関係性が悪い場合や、感謝を伝えるべき相手である他のユーザ自身が周囲に対して感謝を伝えられていない場合になり得る。したがって、例えばチーム内において互いに関係性が悪いチームメンバーがいること、あるいはチーム内に感謝表明状況が悪いユーザがいることを検知した場合に、感謝を伝えるよう促すワークをチームメンバーにより多く出力してもよい。
【0113】
また、相互承認表明は、ユーザ同士が互いの存在を認めていることを言動で表出することである。さらに説明をすると、相互承認表明は、ユーザの相互理解の基本情報、共通点共感(共通点に関する相互の理解)、多様性承認(相違点に関する相互の理解)を通した相互承認を行動や態度として表出させることを含む。
【0114】
この相互承認表明の情報である相互承認表明情報は、ユーザに対して、ユーザ自身がどの程度相互承認表明を行っているかを質問しユーザ自身から回答を受け付けること、あるいは対象とするユーザが相互承認表明をどの程度行っているかを他のユーザに質問し、他のユーザから回答を受け付けることで取得される。例えば、他のユーザから相互承認表明に関する回答を受け付ける例としては、チームに所属する他のメンバーに対して、「XXさんから褒められることがありますか?」という質問をし、「ほとんど褒められない」、「まれに褒められる」、「時々褒められる」、「よく褒められる」、「たいてい褒められる」、「いつも褒められる」のいずれかを他のユーザが6段階の数値(1乃至6)で入力することで受け付ける。
【0115】
(潜在的相性情報)
潜在的相性情報は、対象とするユーザと他のユーザとの潜在的相性に関する情報である。この例において潜在的相性情報は、性格傾向、趣味、価値観、および実体情報などの相性要素を含む。潜在的相性情報は、端末100等においてユーザからの入力を受け付けることで取得される。
【0116】
(相互援助情報)
相互援助情報は、対象とするユーザと他のユーザの間との間で行われる相互援助に関する情報である。この例において相互援助情報は、相互援助認識情報と、相互援助共有度とを含む。相互援助情報は、端末100等においてユーザからの入力を受け付けることで取得される。
【0117】
(相互援助認識情報)
相互援助認識情報は、対象とするユーザの相互援助に関する意識(理解)を示す情報である。相互援助認識情報は、ユーザが相互援助を適切に行うことの意義についての理解の程度を示す情報を含む。さらに説明をすると、相互援助認識情報は、各ユーザが行う相互援助によって、各ユーザあるいはチームに影響があることの理解の程度を示す情報である。いわば、相互援助認識情報は、相互援助の重要性を承認しているかを示す情報となる。この相互援助認識情報は、ユーザの相互支援に対する主観認識として捉えることができる。
【0118】
(相互援助共有度)
相互援助共有度は、各ユーザが相互援助を必要とする場面のユーザ同士の理解度である。例えば、相互援助共有度は、気圧が低くなると心身の状態が悪化するなど、対象とするユーザが相互援助を必要とする特定の場面を、他のユーザがどの程度理解しているかを示す情報である。
【0119】
<コンテンツTB521>
コンテンツTB521は、ユーザに対して出力されるコンテンツを記憶する。
図3(B)に示すように、この例におけるコンテンツTB521は、コンテンツに関する情報として、登録時コンテンツと支援コンテンツとを含む。
【0120】
登録時コンテンツ出力処理(後述する
図4のS403参照)や、支援コンテンツ出力処理(後述する
図4のS406参照)などにおいて、上記コンテンツのいずれかが選択され、端末100等を介してユーザに対して出力される。なお、以下の説明においては、ユーザに対して出力されるコンテンツは、主として端末100等において表示される文字を含む画像として説明をする。例えば、端末100等にプッシュ通知としてコンテンツが表示されてもよい。ここで、プッシュ通知とは、端末100等の画面の一部領域(例えば上端など)にメッセージウィンドウ(表示領域)を表示させながら文字列などの画像を表示することである。このプッシュ通知は、ユーザによって本システムの機能を提供するプログラムが起動されていない場合でも通知を表示することが可能である。なお、コンテンツの出力態様は、ユーザがコンテンツの内容を把握可能であれば特に限定されず、音楽を含む音声、匂い、振動、あるいは三次元画像を記録した所謂ホログラムなどであってもよい。
【0121】
支援コンテンツは、支援情報の一例である。図示の例における支援コンテンツは、ユーザを支援するための一般的なコンテンツである一般支援コンテンツと、ユーザ同士の関係性を支援するための関係性支援コンテンツとを含む。
【0122】
ここで、一般支援コンテンツは、支援コンテンツにおける関係性支援以外の支援情報として捉えることができる。一般支援情報は、例えばユーザの怒りの感情をコントロールするアドバイスであるアンガーマネージメント、ユーザの思考様式や心理状態等を切り替えるためのアドバイスであるマインド切替え、ユーザの行動をねぎらうメッセージを出力するねぎらいメッセージ、ユーザにスケジュールを立てて行動を実行するアドバイスであるアクションプランなどを含む。
【0123】
ここで、アドバイスの表示は、ポップアップで行ってもよい。ここで、ポップアップとは、本システムを使用していないときに、端末100などの表示領域において最前面にウィンドウなどの表示要素を表示することである。そして、このウィンドウ内にアドバイス内容を示す画像が表示される。例えば、アクションプランを実行する時間の直前(例えば30分前)に、アクションプランを実行するタイミングであることを示す画像がポップアップで表示される。
【0124】
また、アクションプランの実行態様に応じて、次回のアクションプランを表示する態様を切り替えてもよい。例えば、今回のアクションプランを行わなかった場合、実行されなかった今回のアクションプランすなわち、未達成アクションプランをホーム画面に表示し続けてもよい。この未達成アクションプランの表示により、ユーザによるアクションプランの実行が促される。
【0125】
また、アクションプランは、例えば目を見て挨拶をする、名前を呼んでから挨拶する、1対1で1時間話をする、チームメンバーの頑張っていることを褒める、意見をしっかり聞く、助かったことに対して感謝を伝える、内容や行動に対して注意をするなどを含む。ここで、例えば目を見て挨拶をすることや、名前を呼んでから挨拶することなどユーザが実行することに心理的な抵抗が小さいものと、例えば1対1で1時間話すなど実行することに心理的な抵抗が大きいものとを含む。そこで、アクションプランのうち、ユーザの心理的な抵抗が大きいものは、特定の条件でのみ出力されるようにしてもよい。特定の条件としては、例えばユーザの心理的な抵抗が小さいものが実行された後であることや、ユーザ同士の関係性が良いこと、心理的安全性が高いことなどがある。心理的な抵抗が大きいものを特定の条件でのみ出力することにより、ユーザがアクションプランを実行しないことが回避され得る。
【0126】
ここで、ユーザに対してアクションプランを出力する際に、ユーザが出力されたアクションプランを回避する操作を受け付けてもよい。例えば初めてコミュニケーションをとる他のユーザとのアクションプランとして、1対1の対面での会話が出力される場合がある。ここで、1対1の対面での会話は、心理的な抵抗が相対的に大きいアクションである。したがって、このように心理的な抵抗が相対的に大きいアクションプランに関しては、他のアクションプランをユーザが選択可能としてもよい。例えば、1対1の対面での会話のアクションプランを出力するとともに、心理的抵抗が相対的に小さいアクションプランを選択するアイコン(例えば、「互いのことをよく知る」ボタン)を表示してもよい。このように、心理的な抵抗が異なる他のアクションプランを選択可能とすることにより、ユーザによってアクションプランが実行される可能性が高まる。
【0127】
また、アクションプランにおいては、ユーザが感じる心理的な抵抗を抑制するためのアドバイスが出力されてもよい。例えば、1対1の対面での会話をするアクションプランにおいては、会話を開始する際に、お互いに対するポジティブな評価を出してもよい。また、会話を開始する際に、お互いに日頃感じている感謝の気持ちを表明することを促してもよい。これらのことにより、ユーザが感じる心理的な抵抗が抑制され、ユーザ同士が肯定的な心理状態で1対1の会話が開始されることになり、ユーザ同士の会話が活発となり得る。
【0128】
ここで、アクションプランは、ユーザの勤務形態などユーザ情報に基づいて表示態様が切り替えられてもよい。例えば、ユーザが会社内ではなく、自宅やサテライトオフィスなどで所謂リモートワークにより業務を行っているかに応じて、アクションプランの提示内容を変更させてもよい。さらに説明をすると、ユーザにアクションプランを表示する前(例えば30分前)に、「あなたの勤務形態についてお聞かせください」というメッセージを出力し、「会社に出勤している」、「リモートワーク」、「二つを併用」のいずれかをユーザに選択させてもよい。また、アクションプランを表示する前に、チャットツールの種別またはオンライン会議ツールの種別を取得する。そして、リモートワークの場合、予め種別を取得していたチャットツールでメッセージを送ること、あるいは予め種別を取得していた会議ツールで会議をすることをユーザにアドバイスしてもよい。例えば、勤務形態が「リモートワーク」であるユーザに対しては、「現在リモートワーク中かと思いますのでユーザBさんに話しかけるとしたらチャットツールになるかと思います。忘れないように「今」メッセージを送りましょう」という文字列をユーザに出力してもよい。このとき、ユーザが確実にメッセージを送るよう、例えば30秒間のカウントダウン表示とともに、砂時計の画像を表示してもよい。このカウントダウン表示をすることで、所謂締め切り効果が得られ、ユーザがアクションプランに従った行動をとる可能性が高まる。
【0129】
関係性支援コンテンツは、表象関係コンテンツと、わだかまり解消コンテンツと、相互理解基本コンテンツと、共通点コンテンツと、相違点コンテンツと、尊敬点コンテンツと、ストロークコンテンツと、潜在的相性コンテンツと、相互援助基本コンテンツと、援助実行コンテンツとを含む。
【0130】
図示の例における表象関係コンテンツは、メンバー間関係性、チーム全体関係性およびチーム内偏りごとに互いに異なる内容のコンテンツが設定されている。共通点コンテンツおよび相違点コンテンツは、それぞれメンバー間関係性、チーム全体関係性およびチーム内偏りごとに、互いに異なる内容のコンテンツが予め設定されている。
【0131】
わだかまり解消コンテンツは、わだかまり理由である「意見の不一致」、「喧嘩などの特定の出来事」、「細かな気になる点の積み重ね」などわだかまり理由ごとに、わだかまり理由を解消するためのコンテンツが予め設定されている。
【0132】
相互理解基本コンテンツは、メンバー間理解度ごとにコンテンツが設定されている。相互理解基本コンテンツは、例えば、メンバー間理解度が高い、標準、および低いなどメンバー間理解度ごとに、互いに異なる複数のコンテンツが予め設定されている。
【0133】
尊敬点コンテンツは、尊敬点基本コンテンツと潜在尊敬点コンテンツとを含む。尊敬点基本コンテンツおよび潜在尊敬点コンテンツは、各々尊敬点ごとにコンテンツが設定されている。尊敬点基本コンテンツおよび潜在尊敬点コンテンツは、例えば、歌がうまいことや、プライベートで油絵を描いていることや、向上心があることや、営業成績が良いことなどユーザの尊敬点となり得る項目ごとに複数のコンテンツが予め設定されている。
【0134】
ストロークコンテンツは、ストローク実情、ストローク意識、相互承認表明ごとにコンテンツが設定されている。ストロークコンテンツは、ストロークの種別ごとにどの程度ストロークを行っているか、ストロークが重要であると認識しているか、相互承認表明をどの程度行っているかのそれぞれの場合に応じた複数のコンテンツが含まれる。
【0135】
潜在的相性コンテンツは、相性要素、メンバー間相性度、チーム内相性度ごとにコンテンツが設定されている。潜在的相性コンテンツは、例えば性格傾向や趣味などの相性要素の種別、メンバー間相性が良好であるか否か、チーム内での相性が良好であるか否か、それぞれの組み合わせに応じた複数のコンテンツが含まれる。
【0136】
相互援助基本コンテンツは、相互援助認識、相互援助共有度ごとにコンテンツが設定されている。相互援助基本コンテンツは、例えば相互援助が重要であると認識しているか否か、および相互援助が必要な場面を理解している程度のそれぞれの組み合わせに応じた複数のコンテンツが含まれる。
【0137】
援助実行コンテンツは、ユーザが不調となる原因ごとにコンテンツが設定されている。援助実行コンテンツは、例えば低気圧やタスクが多いなどの不調原因に応じて複数のコンテンツが含まれる。
【0138】
<情報処理システム1の動作>
図4は、情報処理システム1の動作を示すフローチャートである。
次に、
図4を参照しながら、情報処理システム1の動作について説明をする。なお、
図4に示す情報処理システム1の動作の順番は、特に限定されない。すなわち、
図4は各ステップの順が入れ替わる構成を排除するものではない。同様に、他の図などを含む本開示の処理手順などの記載は、ステップや手順が入れ替わる構成を排除するものではない。
【0139】
まず、ユーザからの操作に応じて、端末100が登録開始指示を出力する(S401)。登録開始指示を受け付けた管理装置500は、ユーザ情報を登録する登録処理を実行する(S402)。そして、端末100が登録時コンテンツをユーザに対して出力する(S403)。
【0140】
次に、ユーザからの操作に応じて、端末100が支援開始指示を出力する(S404)。支援開始指示を受け付けた管理装置500は、ユーザに対する支援情報を出力する支援処理を実行する(S405)。そして、端末100が支援コンテンツをユーザに対して出力する(S406)。
【0141】
上記のように、情報処理システム1における管理装置500は、登録処理および支援処理を実行する。なお、この例における登録処理は、ユーザが情報処理システム1を初めて使用するタイミング(初回登録タイミング)、および所定期間(例えば1か月)ごとに設定されたタイミング(更新登録タイミング)において実行される。このことにより、例えばユーザの職場での所属が変わるなど、ユーザ情報が変化した場合であっても、情報処理システム1によるユーザの支援をより適切に出力し得る。
以下、登録処理および支援処理の各々について順に説明する。
【0142】
<登録処理>
図5は、管理装置500の登録処理を示すフローチャートである。
次に、
図4および
図5を参照しながら、管理装置500において実行される登録処理について説明をする。なお、登録処理は、上記のように端末100からの登録開始指示(
図4のS401参照)を受け付けることにより開始される。
【0143】
まず、管理装置500のユーザ情報管理部510が、端末100において入力画像(不図示)を表示しユーザからユーザ情報を取得する(S501)そして、ユーザ情報管理部510は、受け付けたユーザ情報をユーザ情報TB511(
図3参照)に登録する(S502)。そして、支援実行部561が登録時のコンテンツである登録時コンテンツを出力する登録時出力指示を端末100に対して出力する(S503)。なお、登録時出力指示を受け付けた端末100は、登録時コンテンツをユーザに対して出力する(
図4のS403参照)。
【0144】
<支援処理>
図6は、情報処理システム1の支援処理を示すフローチャートである。
次に、
図4および
図6を参照しながら、管理装置500において実行される支援処理について説明をする。なお、支援処理は、上記のように端末100からの支援開始指示(
図4のS404参照)を受け付けることにより開始される。
【0145】
まず、支援実行部561は、例えば1週間に1回など予め定められた関係性支援実行タイミングであるかを判断する(S601)。関係性支援実行タイミングである場合(S601でYES)、支援実行部561はユーザ情報TB511からユーザ情報を取得する(S602)。そして、支援実行部561は、ユーザが所定の基準よりも忙しくないか、具体的には、ユーザ情報に含まれる忙しさが閾値より小さいかを判断する(S603)。
【0146】
ユーザの忙しさが閾値より小さい場合(S603でYES)、表象関係管理部551は表象関係処理を実行する(S604)。そして、支援実行部561は、表象関係処理が実行されたか否かを判断する(S605)。表象関係処理を実行していない場合(S605でNO)、相互理解管理部553は相互理解処理を実行する(S606)。そして、ストローク管理部555は、ストローク処理を実行する(S607)。
【0147】
次に、支援実行部561は、基礎要因についての処理が実行されたか否か、すなわち相互理解処理(S606参照)およびストローク処理(S607参照)の少なくとも一方が実行されたかを判断する(S608)。基礎要因処理を実行していない場合(S608でNO)、潜在的相性管理部557は、潜在的相性処理を実行する(S609)。そして、相互援助管理部559は、相互援助処理を実行する(S610)。
【0148】
一方、ユーザの忙しさが閾値以上である場合(S603でNO)、支援実行部561は支援処理を終了する。このことにより、ユーザが忙しい、すなわちユーザの心身に負荷がかかっている状態において、他のユーザとの関係についての支援情報が出力され、既に心身に負荷がかかっているユーザが更なる負荷を感じることが抑制される。
【0149】
また、表象関係処理が実行された場合(S605でYES)、支援実行部561は支援処理を終了する。同様に、基礎要因処理が実行された場合(S608でYES)、支援実行部561は支援処理を終了する。このことにより、出力される支援情報が多くなり、ユーザが煩わしさを感じることが抑制される。
【0150】
上記のように、本実施の形態の関係性支援処理においては、予め設定された関係性支援実行タイミングとなる度に、根本的実体(相互理解、ストローク、潜在的相性および相互援助)に対する支援処理(相互理解処理、ストローク処理、潜在的相性処理および相互援助処理)が繰り返し実行され得る。また、関係性支援実行タイミングにおいて、表象関係に対する支援である表象関係処理が必要となった場合には、優先的に表象関係処理を行う。このことにより、相対的に短い期間においてはユーザ同士の表象に現れた関係性に対処しながら、相対的に長い期間においてユーザ同士の表象に現れない関係性に対処することが可能となる。
【0151】
なお、予め設定された関係性支援実行タイミングとしては、提示コンテンツが提示されておらず提示することが必要な場合や、ユーザの心身の状態が低調である(ユーザの状態が落ちている)ことの原因がチームの人間関係である場合などを含む。
【0152】
また、ここでは関係性支援処理において、相互理解処理やストローク処理など複数の処理を実行することを説明するが、一部の処理を実行する態様でもよい。例えば、相互処理およびストローク処理のいずれか一方のみを実行する態様でもよい。さらに説明をすると、相互処理を実行した後、基礎要因についての処理が実行されたか否か、すなわち相互理解処理(S606参照)が実行されたかを判断してもよい(S608参照)。また、ストローク処理を実行した後、基礎要因についての処理が実行されたか否か、すなわちストローク処理(S607参照)が実行されたかを判断してもよい(S608参照)。あるいは、S608に対応する処理を行わず、相互処理およびストローク処理のいずれかを単独で実行してもよい。
【0153】
<表象関係処理>
(表象関係処理の概略)
表象関係管理部551によって実行される表象関係を管理する処理(表象関係)の概略は以下の通りである。まず、表象関係管理部551は、表象関係を示す情報を取得して、表象関係の実態が良好であるかを判断する。そして、表象関係の実態が良好ではないと判断された場合、対象とするユーザと他のユーザとの間においてコミュニケーションをとることについての心理的な障害があるかを判断する。すなわち、対象とするユーザと他のユーザとの間において、わだかまり、確執、不和、気掛かりな点など(以下、単にわだかまりという)があり、対象とするユーザが他のユーザを嫌うなど関係性が悪化しているかを判断する。
【0154】
そして、わだかまりがある場合には、表象関係管理部551は、わだかまりの原因についてユーザ同士で話し合いをさせるなど、その原因に基づいてわだかまりを解消する処理を実行する。また、わだかまりがあっても、そのわだかまりが解消できないと判断した場合には、表象関係管理部551は、わだかまりを解消する処理を実行せず(すなわち禁則処理を実行し)、ユーザ同士の共通点や好きなものを提示するなどによりユーザ同士の会話などのコミュニケーションが促進される処理を実行する。なお、このコミュニケーションの促進は、上記間接的な支援の一例として捉えることができる。また、わだかまりの判定方法は、特に限定されないが、例えばユーザ同士の関係性を示す数値がわだかまりの閾値を超えた場合に、表象関係管理部551はわだかまりがあると判定してもよい。また、わだかまりがあるかをユーザに対して質問し、その質問に対する回答に基づいて判定してもよい。なお、ユーザ同士のEQが低い場合に、わだかまりがあると判定してもよい。
【0155】
(入力環境)
ここで、表象関係処理においては、ユーザが端末100などを操作する環境、すなわちユーザがユーザデータを入力する環境である入力環境に応じて、ユーザから受け付ける情報を切り替える。具体的には表象関係処理において、入力環境が特定環境であるかの情報を取得し、その情報に応じて、ユーザから受け付ける情報を切り替える。この特定環境とは、例えばユーザが端末100などを操作する環境がユーザの自宅などの所謂プライベートな環境であり、ユーザが安心できる環境である。付言すると、特定環境は、ユーザが入力する内容を他のユーザに知られる可能性が相対的に低い環境である。すなわち、特定環境は、第三者が存在しない環境である。別の観点から捉えると、特定環境は、ユーザがストレスを感じること無く(あるいは相対的に少なく)入力を行える環境である。
【0156】
入力環境を示す入力環境情報は、ユーザから入力を受け付けることで取得される。具体的には、ユーザが操作する端末100に「今、自宅でこの画面を見ていますか?」などの質問画像を出力することで、ユーザからの入力を受け付ける。なお、入力環境情報は、ユーザからの入力を受け付けることに替えて、例えばGPS情報などの位置情報や、端末100が接続しているネットワークNWの情報などを利用してもよい。位置情報などを利用することにより、ユーザによる操作の負担を軽減し得る。
【0157】
ここで、入力環境が特定環境であるかに応じて、ユーザから受け付ける情報を切り替える態様としては、例えば以下のものがある。すなわち、入力環境が特定環境である場合には、回答をすることで他のユーザとの関係性が将来悪化する可能性、すなわち他のユーザとの関係に侵襲性があり得る質問(侵襲性質問)をし、ユーザからその質問に対する入力(回答)を受け付ける。一方で、入力環境が特定環境でない場合には、侵襲性質問は実行せず(制限し)、侵襲性のないもの、あるいは侵襲性の相対的に低い質問(非侵襲性質問)をし、ユーザからの入力を受け付ける。このように、特定環境であるかに応じて、ユーザに対する質問およびユーザから受け付ける回答の種別を切り替えることで、他のユーザとの関係性が将来悪化することが抑制される。さらに説明をすると、侵襲性質問は、原則使わない態様とすることで、ユーザがユーザ情報を入力する際に感じる不安感を低減することができる。
【0158】
なお、侵襲性が高い質問とは、その質問をすることによって、チーム内で他のメンバーを疑うなど、いわば疑心暗鬼のような状態になり、ユーザ同士の人間関係がかえって悪化してしまう質問である。さらに説明をすると、侵襲性が高い質問は、例えばチームの人間関係やチームの雰囲気等についての質問である。また、侵襲性が低い質問としては、例えばチーム内で「気軽に話すことができるか」という質問である。
【0159】
また、侵襲性質問の回答としてユーザから受け付ける情報は、以下において特定主観情報ということがある。ここで、特定主観情報は、例えば以下のような侵襲性質問をすることによって取得される。すなわち、「XXさんは自分を好んでいると思う」、「XXさんは自分に対して思いやっていると感じる」、「XXさんは自分を見下していると感じる」、「XXさんは自分のことを嫌っている」などの侵襲性質問をすることによって、上記特定主観情報が取得される。なお、これらの質問に対する回答は、「強くそう思う」、「そう思う」、「どちらかといえばそう思う」、「どちらかといえばそう思わない」、「そう思わない」、「強くそう思わない」の6段階のいずれであるかを数値(1乃至6)で受け付けるなどしてもよい。
【0160】
また、侵襲性の相対的に低い質問に関してユーザから受け付ける情報は、以下において基本主観情報ということがある。この基本主観情報は、いわば、特定環境でない場合に受け付ける差し障りのない情報である。基本主観情報としては、例えば以下のような非侵襲性質問をすることによって取得してもよい。すなわち、「XXさんの存在を認めているか」、「XXさんは自分の存在を認めてくれていると思うか」、「XXさんは会話の時にどれくらい笑っているか」、「XXさんに本音を言えるか」、「XXさんは話しやすいか」、「XXさんを信頼しているか」などの非侵襲性質問をすることによって、上記基本主観情報を取得してもよい。なお、これらの質問に対する回答は、「強くそう思う」、「そう思う」、「どちらかといえばそう思う」、「どちらかといえばそう思わない」、「そう思わない」、「強くそう思わない」の6段階のいずれであるかを数値で受け付けるなどしてもよい。
【0161】
ここで、対象とするユーザおよび他のユーザの関係性を判断する場合において、対象とするユーザおよび他のユーザの両者から、特定主観情報または基本主観情報を取得してもよい。両者のユーザから情報を取得することにより、ユーザ同士の関係性の実態をより正確に把握することが可能となる。
【0162】
また、特定主観情報および基本主観情報は、チームを構成するメンバー(ユーザ)全てから取得してもよい。チームを構成するメンバー全てから情報を取得することにより、チーム全体の関係性の実態をより確実に把握することが可能となる。さらに説明をすると、特定のユーザがチームにおける他のユーザ全てとの関係性が良好でなく、チーム内において孤立しているなど、チーム内における関係性に偏りがあるかを把握することが可能となる。さらに説明をすると、この孤立しているユーザに関して関係性支援情報を重点的(優先的)に出力することで、孤立したユーザに対して他のユーザが不適切な対応(所謂仲間はずれなど)を行うことを抑制し得る。
【0163】
なお、特定主観情報および基本主観情報を取得する処理は、自分が相手との関係性をどのように認識しているかの情報を取得する処理、自分が相手から自分についてどのように認識されていると考えているかの情報を取得する処理、相手に自分についてどのように認識しているかの情報を取得する処理、および相手について自分がどのように認識しているかの情報を取得する処理を含むように設定してもよい。これら4つの観点の情報を取得することにより、対象とするユーザと他のユーザとの関係性をより正確に把握することが可能となる。
【0164】
また、特定主観情報および基本主観情報を取得する処理において、ユーザから直接取得する、第三者から取得する、チーム全体から取得するなど、情報取得の態様は、侵襲性の高さに基づいて変更してもよい。また、侵襲性の高さに基づいて情報取得の方法を変更することに替えて、あるいは侵襲性の高さに基づいて変更するとともに、ユーザのEQや心理的安全性に基づいて、情報取得の方法を変更してもよい。さらに説明をすると、心理的安全性が高い場合は、ユーザ同士の人間関係が悪化してしまう可能性が相対的に低いため、侵襲性が一定以上の方法で情報取得を行ってもよい。なお、特定主観情報および基本主観情報を取得する処理は、客観情報を取得する処理としてもいい。例えば、ユーザAから見て、ユーザBとユーザCの関係性はどのように見えるかの情報を優先的に取得する処理としてもよい。
【0165】
(表象関係処理のフロー)
図7は、表象関係管理部551によって実行される表象関係管理処理を示すフローチャートである。
次に、
図7を参照しながら表象関係管理部551によって実行される表象関係処理について説明をする。
【0166】
まず、表象関係管理部551は、入力環境情報を取得する(S701)。そして、表象関係管理部551は、入力環境が特定環境であるかを判断する(S702)。入力環境が特定環境である場合(S702でYES)、表象関係管理部551は、特定主観情報を取得する(S703)。一方、入力環境が特定環境でない場合(S702でNO)、表象関係管理部551は、基本主観情報を取得する(S709)。
【0167】
次に、表象関係管理部551は、メンバー間関係性判定の処理を実行する(S704)。また、表象関係管理部551は、チーム全体関係性判定の処理を実行する(S705)。また、表象関係管理部551は、チーム内偏りを判定する(S706)。
【0168】
そして、表象関係管理部551は、わだかまりがあるか否かを判断する(S707)。わだかまりがある場合(S707でYES)、表象関係管理部551はわだかまり解消処理を実行する(S708)。また、わだかまりがない場合(S707でNO)、表象関係管理部551は表象関係コンテンツを出力する(S710)。
【0169】
(メンバー間関係性判定)
ここで、メンバー間関係性判定(S704参照)について説明をする。メンバー間関係性判定は、チームに所属するメンバー間の関係性を判定する処理である。メンバー間関係性判定は、ユーザから受け付けた特定主観情報(S703参照)または基本主観情報(S709参照)に基づいて実行される。メンバー間関係性判定の処理は、特に限定されないが、例えばユーザから受け付けた数値に基づいて判定される。例えば、複数の質問に対してユーザから受け付けた回答としての数値の合計値と閾値とを比較してもよい。具体的には、数値の合計値が第1基準値以上である場合には関係性が良好であると判断し、数値の合計値が第1基準値より小さく第2基準値(<第1基準値)以上である場合には関係性が標準であると判断し、数値の合計値が第2基準値値より小さい場合には、関係性が不良であると判断してもよい。
【0170】
(チーム全体関係性判定)
ここで、チーム全体関係性判定(S705参照)について説明をする。チーム全体関係性判定は、チーム全体の関係性を判定する処理である。チーム全体関係性判定は、ユーザから受け付けた特定主観情報(S703参照)または基本主観情報(S709参照)に基づいて実行される。メンバー間関係性判定の処理は、特に限定されないが、例えばユーザから受け付けた数値に基づいて判定される。例えば、各メンバー間の関係性の数値を算出し、チーム内において特定のユーザの数値が低い場合に、特定のユーザの関係性が悪いと判断してもよい。
【0171】
(チーム内偏り判定)
ここで、チーム内偏り判定(S706参照)について説明をする。チーム内偏り判定は、チーム内におけるメンバー間の関係性の偏りを判定する処理である。チーム全体関係性判定は、ユーザから受け付けた特定主観情報(S703参照)または基本主観情報(S709参照)に基づいて実行される。メンバー間関係性判定の処理は、特に限定されないが、例えばユーザから受け付けた数値に基づいて判定される。チーム内偏り判定は、チームに所属する全メンバー間の関係性の数値を算出することで、特定のメンバーがチームのいずれのメンバーとも関係性が悪く孤立しているかを把握することが可能となる。また、チーム内偏り判定は、関係性が良好なメンバーの集団がチーム内に複数あり、かつ異なる集団に属するメンバー間は関係性が不良である状態(所謂派閥が形成された状態)を把握することが可能となる。
【0172】
(表象関係コンテンツ)
ここで、表象関係コンテンツ(S710参照)について説明をする。表象関係コンテンツは、表象関係を維持または改善するためのコンテンツである。表象関係コンテンツは、メンバー間関係性判定、チーム全体関係性判定およびチーム内偏り判定各々の判定結果に応じて切り替えられる。
【0173】
例えば、表象関係コンテンツは、表象関係の良好さに応じて切り替えてもよい。具体的には、関係性が良好である場合にその関係を維持するためのコンテンツを提示し、関係性が標準である場合に関係性を良好にするためのコンテンツを提示し、関係性が不良である場合に関係性を標準以上に改善するためのコンテンツ提示をしてもよい。なお、図示の例とは異なり、関係性が標準である場合および関係性が不良である場合に関係性を改善するコンテンツを提示することに加えて、後述するわだかまり処理を実行してもよい。
【0174】
また、特定主観情報(S703参照)または基本主観情報(S709参照)の取得にともない対象とするユーザに対して質問をする際に、他のユーザがどのような行動をすると関係性が良好になるかを質問してもよい。そして、その質問に対する回答として受け付けた情報に基づいて、他のユーザに対して他のユーザの行動を変容させる情報を表象関係コンテンツとして出力してもよい。具体的に説明をすると、対象とするユーザに対して、「あなたはなぜ、XXさんから認められていないと感じるのですか?そのように感じた場面を思い出し、理由を入力しましょう。」という質問をし、その回答を受け付ける。ここでは、対象とするユーザからの回答が「自分と話しているときに、XXさんが笑っていない」であったとする。この受け付けた回答に基づいて、対象とするユーザが回答内容の行動して欲しいと考えていることを、他のユーザに対して提示してもよい。具体的に説明をすると、他のユーザに対して、対象とするユーザとの関係性が良好でないことを出力するとともに「YYさんと話すときに、笑顔であることを意識してみましょう」という、対象とするユーザの回答に基づいた対応策を示すコンテンツ(表象関係コンテンツ)を出力してもよい。
【0175】
なお、他のユーザに対して対応策を示す表象関係コンテンツを出力する際に、他のユーザが関係性を悪化させている原因を認識(自覚)していることを条件としてもよい。さらに説明をすると、上記の例においては、上記対応策を出力する前に、「自分(対象とするユーザ)と話しているときに、笑っていない」ことを他のユーザ自身が認識しているかを、他のユーザに事前に質問してもよい。そして、他のユーザが認識していないことを条件に、上記対応策を出力するようにしてもよい。他のユーザの認識(自覚)の内容に応じて対応策を出力することで、他のユーザに不要な心理的負担を与えることが回避される。なお、この事前質問の具体例としては、例えば「あなたはYYさんと話しているときに笑っていないことの自覚がありますか。また、何か心当たりがありますか。」というものであってもよい。
【0176】
ここで、表象関係コンテンツは、対象とするユーザおよび他のユーザとに対して、コミュニケーションをとることを促すコンテンツであってもよい。例えば、チャット実行部530によって実行されるチャットや、対面での会話などチャット実行部530以外のコミュニケーションにおいて、互いに直して欲しいところ、すなわち改善点について話をすることを促してもよい。また、この改善点の話をする前に、ユーザ同士が互いの好きなところや長所などについて話をすることを促してもよい。各ユーザにとってポジティブな話題を経てから改善点を話題とすることにより、各ユーザが改善点についての指摘を受け入れる可能性が高まる。
【0177】
また、表象関係コンテンツは、対象とするユーザ、すなわち関係性支援が必要なユーザに出力することに加えて、あるいは関係性支援が必要なユーザに出力することに替えて、他のユーザに出力してもよい。
【0178】
また、対象とするユーザと他のユーザとの関係性の判断において、それぞれのユーザから取得した数値に所定値以上の差があるなど、ユーザごとの関係性の認知に差があることがある。この関係性の認知に差が発生していることを条件として、表象関係コンテンツを出力してもよい。さらに説明をすると、対象とするユーザと他のユーザとの関係性の認知に所定値以上の差があることを条件として、対象とするユーザと他のユーザとに表象関係コンテンツを出力してもよい。
【0179】
また、上記の説明においては、入力環境が特定環境でない場合(S702でNO)、表象関係管理部551は基本主観情報を取得する(S709)ことを説明したが、これに限定されない。例えば、基本主観情報を取得することに替えて、対象とするユーザ同士以外のユーザに対象ユーザ間の関係性について質問(客観質問)をし、周囲、すなわち第3者からの客観評価として客観情報を受け付けてもよい。例えば、第3者であるユーザに対して「XXさんとYYさんは仲がいいと思うか」という質問をして、その回答を客観情報としてもよい。そして、この客観情報に基づいて表象関係コンテンツを出力してもよい。付言すると、このように入力環境が特定環境でない場合(S702でNO)に、質問を出力する対象者を対象とするユーザ以外に切り替えることで、対象とするユーザと他のユーザとの関係性をより正確に把握し得る。
【0180】
<わだかまり解消処理>
図8は、表象関係管理部551によって実行されるわだかまり解消処理を示すフローチャートである。
次に、
図8を参照しながら、表象関係管理部551によって実行されるわだかまり解消処理を説明する。
【0181】
まず、表象関係管理部551は、わだかまり理由を取得する(S801)。そして、表象関係管理部551は、取得したわだかまり理由に基づいて、わだかまり解消コンテンツを出力する(S802)。そして、表象関係管理部551は、潜在的相性を取得する(S803)。
【0182】
次に、表象関係管理部551は、潜在的相性が良好であるかを判断する(S804)。潜在的相性が良好である場合(S804でYES)、表象関係管理部551は解消可能性コンテンツを出力する(S805)。一方、潜在的相性が良好でない場合(S805でNO)、表象関係管理部551はわだかまり解消処理を終了する。このようにわだかまりを解消する処理を実行することで、表象関係を効率よく改善し得る。
【0183】
(わだかまり理由)
ここで、わだかまり理由とは、わだかまりの原因となった事象である。わだかまりの理由は、例えば、「意見の不一致」である。このわだかまり理由は、例えばユーザに対して「わだかまりは、意見の不一致が原因ですか」という質問をして、その回答を受け付けることで取得可能である。
【0184】
(わだかまり解消コンテンツ)
わだかまり解消コンテンツは、わだかまりを解消するための情報である。わだかまり解消コンテンツは、わだかまりを解消するため、ユーザ同士がコミュニケーションをとることを促すための情報である。このわだかまり解消コンテンツは、わだかまりの原因を直接解消するための情報に限定されず、わだかまりを間接的に解消するための情報を含む。さらに説明をすると、わだかまり解消コンテンツは、ユーザに対して、もし嫌なところがあっても最低限のコミュニケーションがあることが、グループが良い状態であるという観点には必要であることなど、わだかまりを間接的に解消するための情報であってもよい。
【0185】
ここで、わだかまり解消コンテンツは、わだかまり理由の種別に応じて切り替えてもよい。例えば、わだかまり理由が「意見の不一致」であった場合、わだかまり解消コンテンツは、例えばユーザ同士に互いの事情を理解させる情報を含むとよい。具体的には、わだかまり解消コンテンツは、ユーザ同士の価値観の相違やその意見を持つ背景、例えば過去のなんらかの経験に由来しているか、ユーザが重視しているものは何か、ユーザが尊敬している人物は誰かなど、ユーザ同士がコミュニケーションをとることを促すための情報を含むとよい。
【0186】
また、わだかまり理由が「喧嘩などの過去における特定の出来事」であった場合、わだかまり解消コンテンツは、特定の出来事が発生したときの、お互いの忙しさ、精神状態、肉体状態がどのような状態であったか、なぜ出来事が発生する起因となる行動をしたのかについて、ユーザ同士がコミュニケーションをとることを促すための情報を含むとよい。
【0187】
また、わだかまり理由が「細かな気になる点の積み重ね」であった場合、わだかまり解消コンテンツは、具体的にどのようなところが嫌だと感じるのか、ユーザに言語化(入力)させ、その原因に応じて、双方のユーザに処理を行うための情報であってもよい。さらに説明をすると、わだかまり理由が他のユーザが早口である場合、わだかまり解消コンテンツは、早口であることを話題としながら、ユーザ同士がコミュニケーションをとることを促すための情報を含むとよい。
【0188】
なお、わだかまり解消コンテンツの出力は、早口であることがどうしても許せないことであるのかを示す情報を対象とするユーザから取得し、許せないことであるという回答を得たことを条件として他のユーザ(早口である他のユーザ)に出力してもよい。このわだかまり解消コンテンツは、早口である他のユーザに対して、早口を改善することを意識する(ゆっくり話すよう心掛ける)よう促すための情報となる。付言すると、この早口の改善を意識するための情報は、早口を直すことが早口であるユーザの価値観と相違しないことを条件として出力してもよい。このことにより、早口である他のユーザの尊厳を損なうことなく、ユーザ同士の関係性を改善することが可能となる。
【0189】
わだかまり解消コンテンツは、例えばユーザ同士の関係性を悪化させる可能性があるため、一度の関係性支援実行タイミング(参照S601)で出力されるタイミングを制限してもよい。例えば、関係性支援実行タイミング(参照S601)ごとに例えば1回など回数を制限してもよい。さらに説明をすると、わだかまり判定処理において判定を行うのは、各質問項目および関係性全体判定で1回としてもよい。
【0190】
(解消可能性コンテンツ)
解消可能性コンテンツは、わだかまり解消コンテンツの一例であり、わだかまりを解消する可能性があることを示す情報である。例えば、解消可能性コンテンツは、わだかまりを容易に改善できるかもしれない、解消後はいい関係を築けるかもしれないというような、わだかまりが解消することに関する肯定的な内容の情報を含む。この解消可能性コンテンツは、潜在的相性が良好であることを条件に出力される(S804参照)。潜在的相性が良好であることを条件として解消可能性コンテンツを出力することにより、無条件に解消可能性コンテンツを出力する場合と比較して、ユーザ同士がコミュニケーションをとることでユーザ同士の関係が悪化することが回避され得る。
【0191】
なお、わだかまり解消コンテンツは、例えばユーザ同士の共通点を提示するものであってもよい。例えば、対象とするユーザに対して、「あなたとAさんは、スポーツ観戦が好きである点や好奇心が強い点等の共通点があり、互いに分かり合える部分があるはずです。」という画像を表示する態様でもよい。また、解消コンテンツや、相性の良さを示す相違点を提示するものであってもよい。例えば、「あなたとAさんは、16personalityにおいてESFPとINTPで、考え方の相性はとても相性が良いです。」など、性格診断における相性の良さを示す画像を表示する態様でもよい。
【0192】
<相互理解処理>
(相互理解処理の概略)
相互理解管理部553によって実行される相互理解を管理する処理(相互理解処理)の概略は以下の通りである。まず、相互理解管理部553は、ユーザの属性を示す情報であるユーザ情報を取得して、相互理解度が所定値以上となるよう管理する。具体的には、相互理解管理部553は、相互理解度が所定値以上となるよう、共通点、相違点および尊敬点に関する情報をユーザに提示し、ユーザ同士の会話などのコミュニケーションが促進される処理を実行する。なお、相互理解処理においては、ユーザ同士の相互理解を進めるとともに、相互理解の必要性や重要性についても各ユーザが理解している状態にすることが好ましい。なお、ここでは共通点、相違点および尊敬点に関する情報をユーザに提示することを説明するが、これに限定されない。例えば、共通点、相違点および尊敬点の一部のみをユーザに提示する態様であってもよい。
【0193】
なお、共通点、相違点および尊敬点以外のユーザ同士の情報をユーザに提示する態様であってもよい。例えば、ユーザ同士の情報として、「一番好きな映画は何ですか?」や「100万円あったら何に使いますか?」、「夏休みはどこかに行きますか?」などの質問をユーザに対して出力し、その回答を他のユーザに対して出力する(共有する)態様でもよい。また、ユーザ同士の情報として、「他人に何をされたら嫌ですか?」、「他人の気になる言動はなんですか?」など、対象とするユーザが他のユーザの言動をどのように感じるかを質問し、得られた回答を他のユーザに対して出力する態様でもよい。いわば、対象とするユーザが他のユーザの言動をどう判断するかの判断基準(価値観)をユーザ同士で共有してもよい。付言すると、ユーザ同士の情報としては、後述する理解情報、禁止情報、許容情報、重視情報など、種々の情報を用いることができる。
【0194】
なお、相互理解においては、互いの価値観が共有される。そして、価値観が共有されることで、ユーザの行動(例えば話し方などの普段の行動)から生じる誤解を防ぐことができる。例えば、キャリアを選択していく上で絶対に譲れない価値観であるキャリアアンカーを各ユーザから取得する。そして、このキャリアアンカーをチームメンバー同士で共有することで、ユーザ同士に生じ得る誤解を抑制することができる。なお、キャリアンカーの共有は、他のユーザに提示しても良いと対象とするユーザが判断したキャリアアンカーのみを共有するようにしてもよい。このことにより、共有を望まないユーザのキャリアアンカーが強制的に共有されることが開始される。なお、キャリアンカーなどの価値観そのものを共有することに加えて、あるいは替えて、どのようなときに価値観のずれを感じることがあるかなど、価値観に関連する情報を共有してもよい。
【0195】
また、価値観をチームメンバーなど複数のユーザ同士で共有する場合は、1回につき1人の価値観を提示してもよいし、1回につき複数人の価値観を提示してもよい。また、所定の優先順に従って、価値観を提示してもよい。この優先順位としては、例えば価値観の一致度に応じて決定される。具体的には、価値観が大きく異なる(反対)のユーザ(例えば安定志向と挑戦志向)、価値観が一致するユーザ(例えば安定志向同士)、およびどちらでもないユーザの順で価値観を共有してもよい。価値観が大きくなるユーザ同士は、互いの価値観が異なることを予め認識しておくことで、ユーザ同士の衝突が抑制され得る。また、価値観が一致するユーザ同士は、互いの価値観が一致することを予め認識しておくことで、ユーザ同士のコミュニケーションが円滑になり得る。これらのことから、価値観が大きく異なるユーザおよび価値観が一致するユーザは、それ以外のユーザよりも優先して価値観を共有するとよい。
【0196】
(相互理解処理のフロー)
図9は、相互理解管理部553によって実行される相互理解処理を示すフローチャートである。
次に、
図9を参照しながら、相互理解管理部553によって実行される相互理解処理について説明をする。
【0197】
まず、相互理解管理部553は、相互理解基本処理を実行する(S901)。そして、相互理解管理部553は、共通点処理を実行する(S902)。そして、相互理解管理部553は、相違点処理を実行する(S903)。そして、相互理解管理部553は、尊敬点処理を実行する(S904)。
【0198】
なお、相互理解においては、ユーザ同士が感謝を認知するとよい。したがって、上記の相互理解処理において、ユーザに対して感謝の認知を促す処理を実行してもよい。
【0199】
(相互理解基本処理)
図10は、相互理解管理部553によって実行される相互理解基本処理を示すフローチャートである。
次に、
図10を参照しながら相互理解管理部553によって実行される相互理解基本処理について説明する。
【0200】
まず、相互理解管理部553は、相互理解基本処理タイミングであるかを判断する(S1001)。そして、相互理解基本処理タイミングである場合(S1001でYES)、相互理解管理部553は、チーム内におけるメンバー(ユーザ)間の他者開示可能情報の理解度を判定する(S1002)。そして。相互理解管理部553は、他者開示可能情報のチーム全体の理解度を判定する(S1003)。そして、相互理解管理部553は、チーム内において他者開示可能情報の理解に偏り(チーム内)がないかを判定する(S1004)。そして、相互理解管理部553は、これらの判定結果(S1002、S1003、S1004参照)に基づいて、相互理解基本コンテンツを出力する(S1005)。
【0201】
(相互理解基本処理タイミング)
相互理解基本処理タイミングは、特に限定されないが、例えば1週間に1度など所定の期間ごとに設定されてもよい。この相互理解基本処理タイミングは、例えば、前回取得した相互理解度の平均値が閾値よりも低い(例えば数値が2以下)場合には、相互理解度の平均値が閾値以上である場合よりも、頻度が高くなるように設定してもよい。
【0202】
(メンバー間理解度判定)
メンバー間理解度(S1002参照)は、各メンバー間の他者提示可能情報についての理解度である。メンバー間理解度判定は、メンバー間で他者提示可能情報をどの程度理解しているかで判定される。例えば、メンバー間理解度判定において、メンバー同士の理解において重要であり知っておいて欲しい自身の情報(理解情報)、他のメンバーがやると許せないこと(禁止情報)、ユーザ自身がやってしまうが他のメンバーに許して欲しいこと(許容情報)、ユーザ自身がとても重要だと思っていること(重視情報)から、それぞれ最大2個ずつサンプリングを行い、最大8個について、理解しているかを質問してもよい。そして、その質問に対する回答の正答率、すなわち他者提示可能情報の把握度によって、理解度を算出する。
【0203】
なお、上述のように、メンバー間理解度に応じて、相互理解基本コンテンツは変更される。例えば、メンバー間理解度が高い(75%以上)場合は、相互理解基本コンテンツとして、メンバー間の理解が進んでいるということをユーザに提示してもよい。理解が進んでいることを提示することで、ユーザ同士が安心してコミュニケーションをとり得る。また、メンバー間理解度が標準(50乃至75%)の場合は、相互理解基本コンテンツとして、他のメンバーの他者提示可能情報の項目を所定数(例えば2つ)、ユーザに表示するようにしてもよい。他者提示可能情報が表示されることにより、メンバー間理解度が高まる。また、メンバー間理解度が低い(50%未満)場合は、相互理解基本コンテンツとして、他のメンバーの他者提示可能情報の項目を標準よりも多い項目数(例えば4つ)、ユーザに対して表示するようにしてもよい。メンバー間理解度が標準の場合よりも多くの他者提示可能情報が表示されることにより、メンバー間理解度がさらに高まる。
【0204】
なお、ここでは相互理解基本コンテンツを、メンバー間理解度に応じて変更することを説明したが、メンバー間理解度に応じて相互理解基本コンテンツを出力する頻度を変更する態様であってもよい。例えば、メンバー間理解度が基準値よりも低い場合に、相互理解基本コンテンツを出力する頻度が高くなるようにしてもよい。
【0205】
また、相互理解度の他の例としては、チームにおける他のユーザについてどの程度知っているか、あるいは他のメンバーからどの程度知られているかという質問をし、回答として6段階の指標を得ることで、相互理解度の状況を取得してもよい。
【0206】
(チーム全体理解度判定)
チーム全体理解度(S1003参照)は、チーム全体の他者開示情報についての理解度である。チーム全体理解度判定は、チーム全体で他者提示可能情報をどの程度理解しているかで判定される。例えば、チーム全体理解度判定において、メンバー間理解度判定と同様、上記メンバー同士の理解において重要な自分の知っておいて欲しい情報、他のメンバーがやると許せないこと、やってしまうけど許して欲しいこと、とても重要と思っていることから、それぞれ最大2個ずつサンプリングを行い、最大8個について、理解しているか質問をしてもよい。そして、例えば(相互理解のための基本情報の数)x(チームを構成するメンバーの数)x(自身を除く他のメンバーの数)x(把握度)から、チーム全体理解度を算出する。なお、メンバー間理解度と同様に、チーム全体理解度に応じて、相互理解基本コンテンツの内容は変更される。また、チーム全体理解度に応じて、相互理解基本コンテンツを出力する頻度を変更する態様であってもよい。
【0207】
(チーム内偏り判定)
チーム内偏り(S1004参照)は、チームの他者開示可能情報の理解における偏りである。チーム内偏り判定は、特定のメンバーの他者開示可能情報の理解度が、他のメンバーと比較して低い場合や、チーム内に他者開示可能情報の理解度が高いメンバーの集団が複数ありかつ異なる集団に属するメンバー間は他者開示可能情報の理解度が低い場合は、偏りがある状態と判断する。
【0208】
なお、上述のように、チーム内偏りに応じて、相互理解基本コンテンツは変更される。例えば、チーム内偏りが大きい場合、他のメンバーからの理解がなされていないメンバー、すなわち他のメンバーによる他者開示可能情報の理解度が低いメンバーの他者開示可能情報が表示されることにより、メンバー間理解度が高まる。また、相互理解基本コンテンツとしては、チーム内偏りが大きい場合、小さい場合よりもチーム内の偏りを解消する相互理解基本コンテンツの情報量が多くなってもよい。また、チーム内偏りが大きい場合、小さい場合よりも相互理解基本コンテンツの出力頻度が増加してもよい。
【0209】
(相互理解基本コンテンツ)
相互理解基本コンテンツ(S1004参照)は、上述のように、各ユーザが重要と思っていること、各ユーザが他者にしてほしくないこと、各ユーザが他者にしてしまうかもしれないけど、許して欲しいことなどの情報を含む。また、相互理解基本コンテンツ(S1004参照)は、上述のように、各ユーザが他者に知ってほしい情報、各ユーザ自身があまりしたくないことの情報などを含む。
【0210】
(共通点処理のフロー)
図11は、相互理解管理部553によって実行される共通点処理を示すフローチャートである。
次に、
図11参照しながら、相互理解管理部553によって実行される共通点処理について説明をする。この共通点処理のフローは、上記の相互理解基本処理のフローと同様である。
【0211】
まず、相互理解管理部553は、共通点処理タイミングであるかを判断する(S1101)。そして、共通点処理タイミングである場合(S1101でYES)、相互理解管理部553は、チーム内におけるメンバー(ユーザ)間の共通点に関する理解度を判定する(S1102)。そして、相互理解管理部553は、チーム全体の共通点に関する理解度を判定する(S1103)。そして、相互理解管理部553は、チーム内において共通点に関する理解に偏り(チーム内)がないかを判定する(S1104)。そして、相互理解管理部553は、これらの判定結果(S1102、S1103、S1104参照)に基づいて共通点コンテンツを出力する(S1105)。
【0212】
(共通点処理タイミング)
共通点処理タイミングは、特に限定されないが、例えば1週間に1度など所定の期間ごとに設定されてもよい。この共通点処理タイミングは、例えば、前回取得した相互理解度の平均値が閾値よりも低い(例えば数値が2以下)場合には、相互理解度の平均値が閾値以上である場合よりも、共通点処理タイミングの頻度が高くなるように設定してもよい。このことにより、共通点処理によって相互理解度の向上をより確実に実行し得る。
【0213】
(共通点コンテンツ)
共通点コンテンツ(S1105参照)は、性格傾向、価値観、実情情報などの共通点に関する情報を含む。共通点コンテンツは、上記相互理解基本コンテンツと同様、メンバー間理解度(S1102参照)、チーム全体理解度(S1103参照)、チーム内偏り(S1104参照)に応じての内容が変更される。
【0214】
また、共通点コンテンツが提示されることにより、ユーザが互いの共通点についての理解を深めることができる。また、共通点コンテンツは、対象とするユーザに提示されることに加えて、対象とするユーザとの共通点をもつ他のユーザにおいても提示される。対象とするユーザおよび他のユーザの両者に共通点コンテンツを提示することで、相互理解度が高まる。なお、共通点コンテンツは、チームに所属する各メンバーと共通する点をチームメンバー全員に提示されるものであってもよい。このことにより、チームにおけるユーザ同士の関係性が向上し得る。
【0215】
また、共通点コンテンツは、共通点に関する情報に加えて、他のユーザとの関係において共通点が存在することから、互いに理解し合える(分かり合える)という他のユーザとの関係性についての肯定的な情報を含んでもよい。すなわち、共通点コンテンツは、他のユーザとの関係がより改善される可能性があることを示唆する情報を含んでもよい。このことにより、対象とするユーザと他のユーザとを共感させ、互いに信頼し合わせることが可能となる。すなわち、ユーザ同士の関係において相互共通点を共感すること(相互共通点共感)が可能となる。
【0216】
(相違点処理)
図12は、相互理解管理部553によって実行される相違点処理を示すフローチャートである。
次に、
図12を参照しながら、相互理解管理部553によって実行される相違点処理について説明する。
【0217】
まず、相互理解管理部553は、相違点処理タイミングであるかを判断する(S1201)。相違点処理タイミングである場合(S1201でYES)、相互理解管理部553は、他者受容度を取得する(S1202)。そして、相互理解管理部553は、他者受容度が閾値より大きいかを判断する(S1203)。他者受容度が閾値より大きい場合(S1203でYES)、相互理解管理部553は、自己受容度を取得する(S1204)。そして、相互理解管理部553は、チーム内におけるメンバー(ユーザ)間の相違点に関する理解度を判定する(S1205)。そして、相互理解管理部553は、チーム全体の相違点に関する理解度を判定する(S1206)。そして、相互理解管理部553は、チーム内において相違点に関する理解に偏り(チーム内)がないかを判定する(S1207)。そして、相互理解管理部553は、これらの判定結果(S1205、S1206、S1207参照)に基づいて相違点コンテンツを出力する(S1208)。
【0218】
(相違点処理タイミング)
相違点処理タイミングは、特に限定されないが、例えば1週間に1度など所定の期間ごとに設定されてもよい。この相違点処理タイミングは、例えば、前回取得した相互理解度の平均値が閾値よりも高い(例えば数値が4以上)場合には、相互理解度の平均値が閾値以下である場合よりも、共通点処理タイミングの頻度が高くなるように設定してもよい。共通点処理を優先的に実行しユーザ同士の関係性が良好となった後で、相違点処理を実行することで、相違点処理がより効率よく実行され得る。
【0219】
(他者受容度)
ここで、他者受容度が低いユーザは、他者受容度が高いユーザとの比較において、他のユーザとの相違点を知ると、他のユーザとの間で対立を発生させ、結果としてユーザ同士の関係性が悪化してしまうことがある。そこで、図示の例においては、他者受容性が閾値より大きいことを条件(S1203参照)として、相違点コンテンツを出力する。このことにより、ユーザ同士の相違点を開示することにともないユーザ同士の関係性が悪化することが抑制される。なお、他者受容度は、他の項目から取得(推定)する態様でもよい。また、他者受容度が閾値よりも低い場合に、特定の処理を実行してもよい。例えば、他者受容度が閾値よりも低い場合に、対象とするユーザの共感性を上げるコンテンツを提示してもよいし、対象とするユーザの他者受容性を向上させるコンテンツを提示してもよい。例えば、価値観の多様性を受け入れていきましょうなどのアドバイスを出力してもよい。
【0220】
(自己受容度)
自己受容度が高いユーザは、自己受容度が低いユーザとの比較において、他のユーザとの相違点を知った際に、その相違点を受け入れられる可能性が相対的に高い。そこで、本実施の形態においては、ユーザに対して自己受容度が高まるような内容の相違点コンテンツを出力する。例えば、対象とするユーザ自身が短所と思っている点を受け付け、その短所の見方を変えて長所として提示するコンテンツや、他のメンバーに当該メンバーの長所を質問し、その回答を誰が入力したかとともに提示するコンテンツを相違点コンテンツとして出力してもよい。
【0221】
(相違点コンテンツ)
相違点コンテンツ(S1208参照)は、性格傾向、価値観、実情情報などの相違点に関する情報を含む。相違点コンテンツは、上記相互理解基本コンテンツと同様、メンバー間理解度(S1102参照)、チーム全体理解度(S1103参照)、チーム内偏り(S1104参照)に応じての内容が変更される。
【0222】
また、相違点コンテンツが提示されることにより、対象ユーザが互いの相違点についての理解を深めることができる。また、相違点コンテンツは、共通点コンテンツと同様、対象とするユーザに提示されることに加えて、対象とするユーザとの相違点をもつ他のユーザにおいても提示される。対象とするユーザおよび他のユーザの両者に相違点コンテンツを提示することで、相互理解度が高まる。なお、相違点コンテンツは、チームに所属する各メンバーと相違する点を全員に提示されるものであってもよい。このことにより、チームにおけるユーザ同士の関係性が向上し得る。
【0223】
また、相違点コンテンツは、相違点に関する情報に加えて、他のユーザとの関係において相違点が存在することからさまざまな視点で考えることができるというポジティブな情報を含んでもよい。すなわち、相違点コンテンツは、ユーザ自身にとって有益である(メリットがある)ことを示唆する情報を含んでもよい。このことにより、対象とするユーザと他のユーザとが相違点を互いに認め合い、多様性を享受することが可能となる。すなわち、ユーザ同士の関係において、多様性を承認すること(相互多様性承認)が可能となる。なお、ここでは相違点が存在することのメリットを表示することを説明したが、各ユーザが相違点を受け入れる(承認)ことを促す情報であれば、これに限定されない。例えば、相違点コンテンツは、人間同士は必ず何か相違点があるなど、ユーザが相違点の存在を自然と受け入れる思考を持つよう促す情報を含んでもよい。
【0224】
(尊敬点処理)
図13は、相互理解管理部553によって実行される尊敬点処理を示すフローチャートである。
次に、
図13を参照しながら、相互理解管理部553によって実行される尊敬点処理について説明をする。
【0225】
まず、相互理解管理部553は、尊敬点基本処理タイミングであるかを判断する(S1301)。尊敬点基本処理タイミングである場合(S1301でYES)、相互理解管理部553は尊敬点の情報を取得する(S1302)。そして、相互理解管理部553は、取得した尊敬点情報に基づいて尊敬点基本コンテンツを出力する(S1303)。
【0226】
次に、相互理解管理部553は、潜在尊敬点処理タイミングであるかを判断する(S1304)。潜在尊敬点処理タイミングである場合(S1304でYES)、相互理解管理部553は潜在尊敬点の情報を取得する(S1305)。相互理解管理部553は、取得した潜在尊敬点に基づいて潜在尊敬点コンテンツを出力する(S1306)。
【0227】
(尊敬点基本処理タイミングおよび潜在尊敬点処理タイミング)
尊敬点基本処理タイミングおよび潜在尊敬点処理タイミングは、特に限定されないが、例えば1週間に1度など所定の期間ごとに設定されてもよい。また、尊敬点基本処理タイミングおよび潜在尊敬点処理タイミングを互いにずらすことにより、ユーザに出力される支援情報の情報量を抑制することができる。
【0228】
また、尊敬点基本処理タイミングおよび潜在尊敬点処理タイミングは、例えば、前回取得した相互理解度の平均値が閾値よりも低い(例えば数値が2以下)場合には、相互理解度の平均値が閾値以上である場合よりも、尊敬点基本処理タイミングおよび潜在尊敬点処理タイミングの頻度が高くなるように設定してもよい。このことにより、尊敬点基本処理および潜在尊敬点処理によって相互理解度の向上をより確実に実行し得る。
【0229】
付言すると、ユーザが所属するチームの形成タイミングとの関係で、尊敬点基本処理タイミングおよび潜在尊敬点処理タイミングを設定してもよい。例えば、チームを形成してから所定期間(例えば3週間)までのチーム形成期でユーザ同士の関係性が不十分である場合には、尊敬点基本処理タイミングを潜在尊敬点処理タイミングよりも多く設定してもよい。このことにより、ユーザの相互理解度をより効率よく向上させることができる。また、チーム形成期以降は、潜在尊敬点処理タイミングを尊敬点基本処理タイミングよりも多く設定してもよい。このことにより、ユーザ同士が気が付いていない潜在的尊敬点の情報を出力し、相互理解度を向上させることができる。
【0230】
(尊敬点取得処理)
尊敬点取得処理(S1302参照)は、他のユーザの尊敬点の情報を取得する処理である。この尊敬点取得処理は、例えば「XXさんを尊敬している点、すごいなと思う点、頑張っているなと思う点があるか」という質問をし、質問に対するユーザの入力を受け付ける処理である。
【0231】
(潜在尊敬点取得処理)
潜在尊敬点取得処理(S1305参照)は、ユーザ同士が認識していないユーザの尊敬点である潜在尊敬点の情報を取得する処理である。この潜在尊敬点取得処理は、例えばユーザの得意なこと(職務、プライベート)、性格傾向、振る舞い情報(言動情報)、努力情報(職務、プライベート)を各ユーザに対して質問し、質問に対するユーザの入力を受け付ける。そして、受け付けた回答に基づいて、各ユーザの長所を判別取得する。この取得された長所を潜在尊敬点として取り扱う。言い替えると、ユーザの属性のうち長所となり得るものが潜在尊敬点である。
【0232】
(尊敬点基本コンテンツおよび潜在尊敬点コンテンツ)
尊敬点基本コンテンツ(S1303参照)および潜在尊敬点コンテンツ(S1306参照)は、尊敬点となり得る性格傾向、価値観、実情情報などに関する情報を含む。尊敬点基本コンテンツおよび潜在尊敬点コンテンツが提示されることにより、対象ユーザが互いに対して敬意をもつことができる。
【0233】
ここで、尊敬点基本コンテンツは、他のユーザが対象とするユーザを実際に尊敬している点を示す情報である。また、潜在尊敬点コンテンツは、現在は尊敬している点ではないが、今後尊敬点となり得る点を示す情報である。尊敬点基本コンテンツだけでなく、潜在尊敬点コンテンツも示すことで、ユーザ同士の関係性がより向上し得る。
【0234】
また、尊敬点基本コンテンツおよび潜在尊敬点コンテンツは、対象とするユーザおよび他のユーザの両者に提示することで、相互理解度が高まる。なお、尊敬点基本コンテンツおよび潜在尊敬点コンテンツは、チームに所属する各メンバーと相違点する点をチームメンバー全員に示す情報であってもよい。このことにより、チームにおけるユーザ同士の関係性が向上し得る。
【0235】
また、尊敬点基本コンテンツおよび潜在尊敬点コンテンツは、尊敬点に関する情報に加えて、他のユーザとの関係において尊敬点が存在することから他のユーザに敬意をもつことができ、他のユーザとの関係性が良好となるというポジティブな情報を含む。また、尊敬点基本コンテンツおよび潜在尊敬点コンテンツは、人間はそれぞれ長所をもつということともに、他人の長所を認めることで自分もその他人から大切に扱われるというポジティブな情報を含んでもよい。すなわち、尊敬点基本コンテンツおよび潜在尊敬点コンテンツは、ユーザ自身にとって有益である(メリットがある)ことを示唆する情報を含む。このことにより、対象とするユーザと他のユーザとが相互に尊敬し合うこと(相互尊敬)が可能となる。
【0236】
(尊敬点処理の変形例)
尊敬点処理において出力される尊敬点基本コンテンツおよび潜在尊敬点コンテンツは、各メンバーの尊敬点を発見するように意識づけるような情報を含んでもよい。例えば、各メンバーに他のメンバーそれぞれの長所を所定期間(例えば1日)で探すよう提示し、所定期間経過後に探した長所を入力(記入)させてもよい。なお、その入力内容を該当メンバーに表示してもよい。
【0237】
また、尊敬点基本コンテンツおよび潜在尊敬点コンテンツは、それぞれのメンバーの評価軸のフラット化、もしくは評価軸のフラット化の理解を促進する情報を含んでもよい。この場合においては、各メンバーの尊敬点をそれぞれが知りフラットになることが重要であることを示す情報を含んでもよい。
【0238】
ここで、評価軸のフラット化は、各ユーザが複数の評価軸を持つことで実現され得る。ここで、ユーザが持つ評価軸の数が増加すると、他のユーザの尊敬点など、他のユーザの特徴点を発見することが容易となる。そこで、各ユーザが持つ評価軸を増やすアドバイスをユーザに対して出力してもよい。さらに説明をすると、ユーザに対してどのような評価軸で他人を見ているかを質問し、それ以外の評価軸を持つことを促すアドバイスを出力してもよい。例えば、「仕事が正確であるか?」、「気遣いができるか?」、「集中力があるか?」、「積極性があるか?」など複数の価値観(評価軸)を選択させる画像を、対象とするユーザに対して出力する。そして、出力された価値観のうち、ユーザ自身が他のユーザを評価する際の現在の価値観に近いものを選択させる。そして、選択されたもの以外の価値観を持つことの効果(有効性)を、対象とするユーザに出力してもよい。また、対象とするユーザに選択されたもの以外の価値観のうち、いずれの価値観を出力するかは、他のユーザのユーザ情報に応じて決定してもよい。例えば、他のユーザのユーザ情報において、特定の価値観で評価をすると評価が高くなる情報が含まれていることがある。具体的には、職場における他のユーザが積極的であるという性格傾向を持つ場合、「積極性があるか」という価値観で評価すると、このユーザの評価は高くなる。付言すると、いずれの価値観を出力するかは、他のユーザが肯定的に評価される価値観であるかによって決定されてもよい。他のユーザが肯定的に評価される価値観は、他のユーザのユーザ情報に含まれる他のユーザの得意なことや優れていることに関連する価値観として捉えることができる。
【0239】
また、評価軸のフラット化は、例えば職場における評価軸の多様化により実現される。職場における評価軸の多様化させると、例えば職場におけるエンゲージメントを変化させ得る。さらに説明をすると、所謂2:6:2の法則と呼ばれる、意欲的に働く上位20%、普通に働く中位60%、怠け者の20%に分かれるという一般的な割合を変化させることができる。
【0240】
さらに説明をすると、例えば、会社の業績にどれだけ貢献しているかという軸のみでチームメンバー(社員)が評価されると、他の分野では秀でた素質がある社員が、能動的に働く気持ち(モチベーション)を下げてしまうことがある。本システムにより評価軸を多様化させることで、会社の業績への直接の貢献以外も評価されるようになるため、各社員の居心地が向上し労働意欲も向上し得る。
【0241】
評価軸の多様化を行うための本システム処理は例えば以下の通りである。まず、現在、どのような観点でチームでの序列が決まっているかユーザに質問し回答を得る。この質問は、侵襲性が高いことから、入力環境に応じて、質問をするか否かを切り替えてもよい。また、この質問をすることを、ユーザの心理的安全性が高いなど、ユーザが回答することに心理的な抵抗が小さいことを条件としてもよい。なお、チームでの序列がどのように決まっているかを回答することは、ユーザの深層の意識に関係することから、心理的な抵抗が小さいなどユーザが回答しやすい入力環境であることを条件とすることで、より精度よくユーザからの回答を得ることが可能となる。
【0242】
そして、チームのメンバーの得意なことや長所を取得する。そして、得意なことや長所が、チームの評価軸の一つになることを促す情報をシステムが出力してもよい。例えば、チーム内において、歌が上手いチームメンバーや、穏やかな性格であるチームメンバーがいるものとする。この場合、営業成績以外に、歌が上手いことや、穏やかな性格であることなどが評価軸の一つとなるよう、歌がうまいことや穏やかな性格であることで得られる利益を各チームメンバーに理解させる情報を出力してもよい。
【0243】
ここで、ユーザの価値観に基づいて定まる評価軸の情報を各ユーザから取得し、チーム内の全メンバーの潜在的尊敬点が、各ユーザの評価軸においてどのように重要と位置づけられるかを推測してもよい。また、他のユーザが重要ではないと考えると推測される場合や、他のユーザにおける評価軸で重要度が低いことが明らかな場合、その重要性がフラットに考えるとどうなるかを尊敬点基本コンテンツおよび潜在尊敬点コンテンツにおいて当該ユーザに提示してもよい。さらに説明をすると、尊敬点基本コンテンツおよび潜在尊敬点コンテンツにおいて、評価軸は絶対のものではなく、複数あり、その複数ある評価軸をチーム内で全員が認められることが各メンバーにとって有益である(メリットがある)ことを示唆する情報を出力してもよい。
【0244】
また、尊敬点処理においては、チーム全体での理解度を処理する際に、チーム内での尊敬点理解に偏りが生じていないか判定してもよい。その判定に基づいて、どのような処理、コンテンツ提示を行うかを決定する。そして、相対的に尊敬点理解が低いユーザに関して、コンテンツの情報量を多くするなどして尊敬点理解をより促進してもよい。また、尊敬点理解が低いユーザの組み合わせに関して、尊敬点理解に替えて、共通点理解、相違点理解をより促進してもよい。同様に、相違点量や共通点量の潜在的偏り発生に対する優先度処理を行う場合に、理解度と潜在的相性の両方に基づいて処理を切り替えてもよい。さらに説明をすると、理解度と潜在的相性の両方を数値とし総和を取るなどの処理で総合スコアを算出し、それに応じてスコアの小さい組み合わせを優先するという処理の形態であっても良い。理解度については、ユーザ同士が互いにどの程度理解していると思うかといった主観質問でもいいし、具体的に共通点があることを知っているかと問う形態であっても良い。
【0245】
また、尊敬点の取得(S1302参照)において、尊敬点そのものの情報を取得することに加えて、あるいは替えて、他のユーザをどの程度尊敬しているか、という質問の6段階指標で状況を取得してもよい。また、例えばチーム内におけるどのユーザをより尊敬しているかという情報を取得してもよい。また、ユーザが尊敬している他のユーザは誰と考えるかをチーム内における第3者に質問して、その回答を尊敬点の情報として取得してもよい。
【0246】
ここで、特定のユーザから他のユーザへの尊敬点が少ない(尊敬度が低い)と認定された場合、優先的に、他のユーザの思考傾向や性格傾向から潜在的尊敬点をこの特定のユーザに提示してもよい。また、その後の処理における、評価軸に関連する処理は全員を対象としてもよい。
【0247】
<ストローク処理>
(ストローク処理の概略)
ストローク管理部555によって実行されるストロークを管理する処理(ストローク処理)の概略は以下の通りである。まず、ストローク管理部555は、ストロークを示す情報を取得して、ストロークの実態が良好であるかを判断する。そして、ストロークの実態が良好でない場合、ストローク管理部555は、ストロークにおける改善方法、すなわちユーザに対する関係性の支援情報を提示する。
【0248】
なお、ストロークとしては、例えば、他のユーザと目があった時に嬉しそうにするというものがある。このストロークは、他のユーザとのコミュニケーションにおいて実行することが理想であるものの、他のユーザとの関係が良くないときなどにおいて、ユーザが単独で実行することが難しいストロークの1つである。本実施の形態においては、このようにストロークを単独で実行する、すなわちストロークの実態を改善することが難しい場合、ストロークそのものを改善する処理を実行せず(あるいは改善する処理とともに)、ユーザ同士の共通点や好きなものを提示することなどユーザ同士の会話が促進される処理を実行する。なお、上記のユーザが単独で実行することが難しいストロークは、相互理解などが促進されるなど他のユーザとの関係性が改善した後に、促進される処理を実行してもよい。
【0249】
(ストローク処理のフロー)
図14は、ストローク管理部555によって実行されるストローク処理を示すフローチャートである。
次に、
図14を参照しながらストローク管理部555によって実行されるストローク処理について説明をする。
【0250】
まず、ストローク管理部555は、ストローク処理タイミングであるかを判断する(S1401)。出力処理タイミングである場合(S1401でYES)、ストローク管理部555は、ストローク実情情報を取得する(S1402)。そして、ストローク管理部555は、ストローク意識情報を取得する(S1403)。そして、ストローク管理部555は、相互承認情報を取得する(S1404)。そして、ストローク管理部555は、ストロークコンテンツを出力する(S1405)。
【0251】
(ストロークコンテンツ)
ストロークコンテンツ(S1405参照)は、上述のように、ストロークが良好に実行されるための情報を含む。このストロークコンテンツは、ストローク実情情報、ストローク意識情報、相互承認表明に基づいて切り替えられる。例えば、ストロークコンテンツは、ストローク実情情報に基づいて、肯定ストロークのストローク量が、否定ストロークのストローク量よりも少ないと判定された場合に、肯定ストロークが多くなるアドバイスを含んでもよい。また、ストロークコンテンツは、全ストロークにおける肯定ストロークの割合が所定値以上となるように、各種別のストロークを増減させるアドバイスを含んでもよい。
【0252】
ここで、例えば肯定ストロークは、例えば以下のものがある。すなわち、「成功失敗に関わらず努力を認める」、「あいさつする」、「相手の意見をしっかり傾聴する」、「目があったときに嬉しそうにする」、「互いの存在を認める声かけなどを行う」というものである。これらのストロークのうちユーザが十分実行できていないものを、取得したストローク実情情報(S1402参照)に基づいて選択し、選択されたストロークを実行するアドバイスをユーザに対して出力してもよい。
【0253】
具体的には、「あいさつする」というストロークが不十分であった場合、ストロークコンテンツ(S1405参照)としては「毎朝、意識してチームメンバーへあいさつをしましょう」という情報を出力してもよい。付言すると、「あいさつする」というストロークが十分実行できていないという判断は、対象とするユーザ自身からの回答に基づいて行ってもよいし、対象とするユーザ以外の他のユーザからの回答(評価)に基づいて行ってもよい。
【0254】
また、ストロークコンテンツは、ストーク意識情報に基づいて、ストロークを適切に行うことの意義の理解度が低いと判定されることを条件に、ストロークを適切に行うことの重要さを示す情報を含んでもよい。また、ストロークコンテンツは、相互承認が所定値以下であることを条件に、相互承認の表明を促すアドバイスを含んでもよい。また、ストロークコンテンツは、ユーザのストロークを改善するアドバイスとともに、ユーザにストレスを解消するアドバイスを出力してもよい。付言すると、ユーザが自身のストロークを改善する、すなわち自身の行動を変容させることは、ユーザに心理的な負担がかかる。そこで、ユーザにストレス解消を促すことで、ストロークの改善がより確実に実行され得る。
【0255】
また、ストローク実情情報、ストローク意識情報、相互承認表明に基づいて、出力するストロークコンテンツを決定する際に、予め定められた順位に従って、ストロークコンテンツを出力してもよい。例えば、ストローク実情情報に基づいて出力するコンテンツは、ストローク意識情報および相互承認表明に基づいて出力されるコンテンツよりも優先するように設定してもよい。このことにより、ユーザに出力されるコンテンツの量が抑制され、ユーザが煩わしく感じることが回避される。
【0256】
ここで、ストロークコンテンツは、対象とするユーザあるいは他のユーザのユーザ情報(例えば性格傾向や忙しさ情報など)に基づいて変更されてもよい。例えば、ストロークコンテンツは、対象とするユーザが忙しいときに、無条件肯定ストロークが少なくなることがあるので、対象とするユーザにその旨を伝え、対象とするユーザにできるだけ無条件肯定の実行を心がけるように促すものでもよい。また、例えば他のユーザの性格傾向において神経性的傾向が強い場合に、対象とするユーザのストロークコンテンツが、神経性的傾向が強い他のユーザに対する肯定ストロークを増加させることを促す情報を含んでもよい。
【0257】
なお、ストロークコンテンツは、対象とするユーザが他のユーザの行動で感謝していることを、その他のユーザに伝えるよう対象とするユーザに促すコンテンツを含んでもよい。また、ストロークコンテンツは、対象とするユーザが他のユーザから受けたい肯定ストローク、他のユーザから受けたくない否定ストローク、他のユーザから受けてもよい否定ストロークを対象とするユーザから予め取得し、支援情報としてストロークコンテンツの設定をしてもよい。
【0258】
また、例えば職場における職位に応じて、ストロークの支援情報の内容や頻度を変化させる態様でもよい。例えば、職位が上位であるユーザ(上司)には、条件付きストロークに関する注意点を提示する態様でもよい。また、上司に提示される条件付ストロークに関する注意点の提示頻度を、職位が下位であるユーザ(部下)よりも高くする態様でもよい。
【0259】
また、ストロークコンテンツは、例えば好ましくないストロークを他のユーザに対して実行したユーザに対して、その他のユーザに対して行うべき事項のコンテンツを含んでもよい。例えば、ストロークコンテンツは、対象とするユーザが無条件否定ストロークやノンストロークを実行した後の処理(後処理、所謂フォロー)として、他のユーザに謝罪をするコンテンツや、他のユーザに肯定ストロークを実行するコンテンツ、あるいは対象とするユーザ自身がそのストロークをするに至った理由や事情(例えば、忙しくて行ってしまった)を、その他のユーザに説明することを対象とするユーザに促すコンテンツを含んでもよい。
【0260】
また、ストロークコンテンツは、ユーザの状況、すなわちユーザ情報に基づいて、ストロークの支援情報の内容を変化させる態様でもよい。例えば、ユーザの性格傾向において外向性が低い場合には、ストロークを過度に増やすようなストロークコンテンツを出力しないようにしてもよい。
【0261】
(コンテンツ提示タイミング)
さて、ストロークコンテンツの内容に応じて、ストロークコンテンツをユーザに提示するタイミングを変更してもよい。例えば、特定の2人のユーザが互いに対して行うストロークがノンストロークである場合に、この2人のユーザにストロークコンテンツを提示するタイミングを揃える態様でもよい。
【0262】
ここで、提示するタイミングを揃えるとは、各ユーザに提示されるタイミングが互いに関連していればよい。すなわち、一方のユーザに出力するタイミングと、他方のユーザに出力するタイミングが同時であってもよいし、互いにずれていてもよい。提示するタイミングを揃えるとは、例えば、1時間や1日など所定期間までの時間差を許容してもよい。また、提示するタイミングを揃えるとは、各ユーザが情報処理システム1を次回利用するタイミングや、各ユーザが情報処理システム1を同時に利用するタイミングでユーザに提示する態様でもよい。
【0263】
各ユーザに提示するタイミングを揃えることにより、一方のみにストロークコンテンツが提示される態様において生じ得る、ユーザ同士のわだかまりを低減し得る。この例におけるわだかまりとは、既にストロークコンテンツが提示されたユーザが、コンテンツの提示を受けて、ストロークを改善するよう心掛けているにもかかわらず、まだストロークコンテンツが提示されていない他のユーザのストロークが変化しないことにともなって、ストロークコンテンツが提示されたユーザが不快感を持つことなどである。なお、ここではストロークコンテンツを提示することを説明したが、表象関係コンテンツなど他のコンテンツを提示する際に、コンテンツを提示するタイミングを揃える態様でもよい。
【0264】
<潜在的相性処理>
(潜在的相性処理の概略)
潜在的相性管理部557によって実行される、潜在的相性を管理する処理(潜在的相性処理)の概略は以下の通りである。まず、潜在的相性管理部557は、性格傾向など潜在的相性の要因を示す情報を取得して、ユーザ同士における潜在的相性が良好であるかを判断する。潜在的相性が良好でない場合、潜在的相性の不良により予測される不和を事前に解消すべく、総合的に相性が悪くとも関係性がよくなる処理を実行する。また、関係性がよくなる処理とともに、あるいは関係がよくなる処理に替えて、お互いの相違点を受け入れることやストロークを良好とすることなどにより、ユーザ同士のコミュニケーションが促進される処理を実行してもよい。
【0265】
(潜在的相性処理のフロー)
図15は、潜在的相性管理部557によって実行される潜在的相性処理を示すフローチャートである。
次に、
図15を参照しながら潜在的相性処理について説明をする。
【0266】
まず、潜在的相性管理部557は、潜在的相性処理タイミングであるかを判断する(S1501)。潜在的相性処理タイミングである場合(S1501でYES)、潜在的相性管理部557は、相性要素情報を取得する(S1502)。そして、潜在的相性管理部557は、メンバー間相性度を判定する(S1503)。そして、潜在的相性管理部557は、チーム内相性度を判定する(S1504)。そして、潜在的相性管理部557は、潜在的相性コンテンツを出力する(S1505)。
【0267】
(メンバー間相性度の判定)
ユーザ間相性度の判定(S1503)においては、上記のように性格傾向、趣味、価値観および実体情報の各相性要素で潜在的相性が判断される。
【0268】
ここで、例えば性格傾向においては、エゴグラムで取得した情報(例えばCP、NP、A、FC、ACの各評価)をスコア化して、スコアの算出結果に基づいて、潜在的相性の良好さを判断してもよい。さらに説明をすると、例えばスコアの傾向が互いに一致している場合に、潜在的相性が良好であると判断してもよい。
【0269】
また、趣味においては、同一の趣味を持つユーザは潜在的相性が良好であると判断する。また、全く同一の趣味ではなくとも、関連分野の趣味を持っている場合も相性が良好と判断する。例えば、野球観戦が好きなユーザと野球観戦が好きなユーザ、あるいは野球観戦が好きなユーザと草野球をやっているユーザは、同一の趣味をもち、潜在的相性が良好であると判断される。また、野球観戦が好きなユーザとサッカー観戦が好きなユーザとは、関連分野(スポーツ観戦)の趣味をもち、潜在的相性が良好であると判断される。同様に、キャンプが好きなユーザと釣りが好きなユーザとは、関連分野(アウトドア)の趣味をもち、潜在的相性が良好であると判断される。さらに説明をすると、予め趣味を分野ごとに分類し、同一の分野に分類される趣味を持っていた場合、趣味に関する潜在的相性が良好であると判定してもよい。
【0270】
また、価値観においては、キャリアアンカー、健康、寿命、美容などのうち、同一の項目を重要と考えるユーザは、潜在的相性が良好であると判断する。なお、価値観による潜在的相性の判定を行う場合は、職場のチームや、学校のクラスなど集団の種別ごとに価値観の優先処理を行う。例えば、集団の一例である職場のチームにおいては、仕事への価値観(例えばキャリアアンカー)を最も優先順位を高くする。そして、このキャリアアンカーの価値観が一致する場合、他の項目(例えば美容)で一致する場合と比較して、潜在的相性が良好と判断するようにしてもよい。
【0271】
また、実体情報においては、家族構成や過去の経験などのうち、同一の項目を持つユーザは、潜在的相性が良好であると判断する。例えば、家族構成として子供がいるユーザ同士は、潜在的相性が良好であると判断する。
【0272】
なお、性格傾向、趣味、価値観、実体情報の潜在的相性をもとにしたメンバー間の総合的潜在的相性は、各項目についてのスコアの総和など、各項目についてのスコアに基づいて判断される。
【0273】
(チーム内相性度の判定)
チーム内相性度の判定(S1504参照)においては、メンバーの潜在的相性の関係性により判定される。チーム内相性度の判定は、特定のメンバーの潜在的相性度が、他のメンバーと比較して低い場合や、チーム内に潜在的相性が互いに高いメンバーの集団が複数あり、かつ異なる集団に属するメンバー間は潜在的相性が低いである状態である場合は、チーム内相性度が低いと判断される。
【0274】
(潜在的相性コンテンツ)
潜在的相性コンテンツ(S1505)は、上述のように、潜在的相性の不良により不和が発生しないための情報を含む。この潜在的相性コンテンツは、ユーザ同士のコミュニケーションをとることを促すコンテンツであってもよい。例えば、チャット実行部530によって実行されるチャットや、日常の会話などチャット実行部530以外のコミュニケーションにおいて、ユーザ同士がコミュニケーションをとること促してもよい。
【0275】
また、潜在的相性コンテンツ、ユーザの状況、すなわちユーザ情報に基づいて、潜在的相性コンテンツの内容を変化させる態様でもよい。例えば、ユーザ同士の潜在的相性に基づいて、ストロークと相互理解と相互援助の提示の割合を変更するようにしてもよい。このとき、そのコンテンツが出力される趣旨、すなわちそのコンテンツが選択された理由などをコンテンツとともに出力してもよい。このように趣旨がコンテンツとともに出力されることにより、ユーザがコンテンツを受け入れやすくなる。
【0276】
<相互援助処理>
(相互援助処理の概略)
相互援助管理部559によって実行される相互援助を管理する処理(相互援助処理)の概略は以下の通りである。まず、相互援助管理部559は、相互援助についての理解の程度を示す相互援助認識情報を取得して、相互援助の理解度が高いか、言い替えると理解度が良好であるかを判断する。相互援助の理解度が良好でない場合、相互援助管理部559は、相互援助や相互援助文化の必要性を示すなど、相互援助の理解度が所定値以上となるよう管理する。また、相互援助管理部559は、ユーザ同士のコミュニケーションにおいて、相互援助の文化が話題となるように促し、相互援助の理解度が所定値以上となるよう管理する。
【0277】
(相互援助処理のフロー)
図16は、相互援助管理部559によって実行される潜在的相性処理を示すフローチャートである。
次に、
図16を参照しながら相互援助管理部559によって実行される相互援助処理について説明をする。
【0278】
まず、相互援助管理部559は、相互援助基本処理タイミングであるかを判断する(S1601)。そして、相互援助管理部559は、相互援助認識情報を取得する(S1602)。そして、相互援助管理部559は、相互援助の共有度情報を取得する(S1603)。そして、相互援助管理部559は、相互援助基本コンテンツを出力する(S1604)。そして、相互援助管理部559は、不調情報を取得する(S1605)。そして、相互援助管理部559は、援助実行タイミングであるかを判断する(S1606)。そして、相互援助管理部559は、援助実行コンテンツを出力する(S1607)。
【0279】
なお、相互援助実行タイミングであるかの判断(S1606)は、相互援助実情情報に基づいて行ってもよい。この相互援助実情情報は、ユーザが行っている相互援助に関する情報である。相互援助情報は、他のユーザを援助することができているか(能動援助情報)、他のユーザに援助を求めることができているか(援助要請情報)、援助の実行や援助の要請が行いやすい環境であるか(援助環境情報)に基づいて行ってもよい。さらに説明をすると、例えば、能動援助情報、援助要請情報、援助環境情報のいずれかが基準値よりも低い場合は、高い場合よりも援助実行コンテンツが出力されやすくしてもよい。
【0280】
また、援助を求める回数が閾値よりも多い、あるいは援助を求める頻度が閾値よりも高いユーザには、援助を求めることを抑えるよう提示してもよい。すなわち援助を求める態様に応じて、援助を求めることを抑制する支援情報を出力してもよい。また、あるユーザが所定期間(例えば2週間)以上不調である状態が続いた場合、緊急介入を行うべく、緊急度が高いことを示す特別な支援実行コンテンツを出力してもよい。この特別な支援実行コンテンツにおいては、ハラスメントの有無を確認する確認情報を支援実行コンテンツに含めてもよい。また、この例における不調情報取得は、相互援助処理の一部として実行することを説明したが、不調情報取得を独立して行う態様でもよい。
【0281】
(不調情報取得)
不調情報の取得(S1605参照)においては、ユーザが不調となる原因(不調原因)の情報を取得する。この不調原因情報の取得は、例えば対象とするユーザに不調となる原因が現在あるかどうか(タスクの大変さ、精神状態)を質問しその回答を得ることによって実行される。また、不調原因情報の取得は、ネットワークNWを介した外部情報(気象データなど)を取得することによって実行されてもよい。なお、ここでは現在の不調原因を質問することを説明したが、過去に不調になったことがある際の原因、すなわち過去の不調原因を質問する態様でもよい。
【0282】
なお、ユーザの不調情報を取得し、不調だった場合、その理由を示す理由情報をユーザから取得してもよい。そして、理由情報において示される理由がチームの人間関係だった場合、原因解消コンテンツを提示する態様でもよい。このとき提示される原因解消コンテンツは、理由情報において示される理由に応じて設定されてもよい。例えば、理由情報において示される理由が、無条件否定が多いというものである場合は、原因解消コンテンツとして、無条件否定をやめるよう促す態様でもよい。
【0283】
また、例えば理由情報において示される理由が、職場における人間関係である場合、原因解消コンテンツとして関係性構築のためのアドバイスを提示してもよい。例えば、上司および部下の関係にある2人のユーザのうち、上司のユーザに出力する原因解消コンテンツは、部下に助けを求めるようアドバイスし、かつアクションプランを作成する内容であってもよい。また、部下のユーザに出力する原因解消コンテンツは、周囲に助けを求めるようアドバイスし、かつアクションプランを作成する内容であってもよい。
【0284】
(援助実行コンテンツ出力)
援助実行コンテンツの出力(S1607)においては、不調原因があるユーザを援助する指示である援助実行コンテンツを他のユーザに出力する処理である。ここで、援助実行を促す対象である他のユーザをユーザ情報に基づいて選択してもよい。例えば、協働性が高いユーザや、忙しさが低く時間的に余裕のあるユーザをユーザ情報に基づいて選択して、選択されたユーザに援助実行コンテンツを出力してもよい。また、選択されたユーザに出力される援助実行コンテンツは、不調原因があるユーザを援助することを促すことに加えて、そのコンテンツが選択されたユーザに出力されている理由(協働性が高いなど)を含んでもよい。この理由が出力されていることにより、例えば選択されたユーザの自己肯定感が高まり、選択されたユーザによる不調ユーザの援助が確実に実行され得る。また、援助実行コンテンツは、上司が弱みを打ち明けるなどで他の態様であってもよい。
【0285】
なお、相互援助の支援情報には、例えば直接介入と、間接介入である関係性構築促進との2つの種別がある。ここで、直接介入は、対象とするユーザに困ったことがあるかを質問し、ユーザの回答が困ったことがあることを示す場合、他のメンバーに相談させるよう促すものである。この直接介入の提示条件としては、例えば対象とするユーザが援助を必要とするときがある。また、関係性構築促進は、援助を求めやすいような関係性を作るためにアドバイスを行うものである。この関係性構築促進の提示条件としては、例えばカリキュラム(後述)作成時に提示日を決定し、その決定された提示日に到達したときがある。
【0286】
また、上記相互理解やインタラクションのコンテンツ提示で、相互援助のコンテンツを提示してもよい。例えば、インタラクションなどの画像において、最近困っていることがないかを話題とするよう示してもよい。
【0287】
また、相互援助実行コンテンツは、他の全員のメンバーに対して平等に相互援助を行うことができているかを質問し、その回答に基づいて出力する態様でもよい。さらに説明をすると、ユーザからの回答が相互援助を行えていないことを示す場合、相互援助実行コンテンツとして平等に相互援助を行うよう促す態様でもよい。
【0288】
また、相互援助実行コンテンツは、他の態様であってもよい。例えば、部下であるユーザの精神状態が所定期間(例えば2週間)閾値以下になった場合、その部下に対して、上司と話し合いの場を設けるように促す態様でもよい。また、ユーザが所属する部署全体が忙しい場合などチームメンバーの多く(例えば全員)が困っている場合、上司にそのことを伝えるようチームメンバーに促す態様でもよい。また、チームメンバーを介して上司に、あるいは上司に直接、上司がチームメンバー以外の補助者(ヘルパー)を要請することを促してもよい。
【0289】
<チーム形成処理>
(チーム形成処理の概略)
さて、上記の説明においては、既に存在するチームにおいてメンバー同士の関係性を良好とするための処理(既存チーム処理)を説明した。ここで、チームにおける関係性支援において、チームが既に形成されることは必須ではなく、チームを新たに形成する段階、すなわちチーム形成段階においても、本実施の形態は対応可能である。付言すると、情報処理システム1において、既存のチームに適用するか、新たに形成されるチームに適用するかの指示を予めユーザから受け付け、その受け付けた指示に従って、関係性支援のための各処理を切り替えてもよい。
【0290】
また、例えば、支援実行部561が、チームが形成された日などのチーム形成時期の情報を受け付け、チーム形成時期からの経過時間に応じて、処理を切り替えてもよい。さらに説明をすると、チーム形成日から所定の期間(例えば3週間)までは新たに形成されるチームの処理(チーム形成処理)とし、所定期間経過後は既存チームの処理(既存チーム処理)とするよう、切り替える制御を行ってもよい。
【0291】
さらに説明をすると、チーム形成日からの経過時間に替えて、チームにおけるユーザ同士の関係性を示す情報に基づいて、処理を切り替える態様であってもよい。すなわち、各ユーザから取得する表象関係やストロークに関する情報に従って、チーム形成処理と既存チーム処理とを切り替えてもよい。具体的には、相互理解の状態に基づいて、チーム形成処理から既存チーム処理に移行してもよい。また、表象関係の状態に基づいて、チーム形成処理から既存チーム処理に移行してもよい。また、ストロークの状態に基づいて、チーム形成処理から既存チーム処理に移行してもよい。
【0292】
さらに説明をすると、例えばチームの結成からの経過時間に応じて、ストローク状態などの情報取得の方法を変更してもよい。具体的には、他のチームメンバーのストローク状態の取得において、チームの結成からの経過時間が閾値よりも長ければ、特定のメンバーのストローク状態を直接取得してもよい。経過時間が短い場合、すなわちチーム結成の初期段階においては、相互理解等を通じてユーザ同士を険悪にさせないことを優先してもよい。また、経過時間が長くなり、初期段階を過ぎた後は、関係性をよくするためのコンテンツ提示を行ってもよい。すなわち、チーム内の関係性が成立していることを条件に、特定のコンテンツ提示を行ってもよい。この特定のコンテンツは、例えばユーザ同士が感謝を伝え合うことを促すものである。なお、チーム形成からの経過時間以外に、例えば本システムの利用開始からの経過時間に応じて、ストローク状態などの情報取得の方法を変更してもよい。付言すると、チーム形成からの経過時間や、本システムの利用開始からの経過時間に応じて、情報取得の方法を変更することに加えて、あるいは替えて、例えばシステムを説明する文言の量など、コンテンツが切り替わる態様であってもよい。具体的には、本システムの利用を開始してから所定期間が経過するまでは、システムの利用方法の説明や、用語の解説、アドバイスを出力する趣旨など、出力される情報の量(例えば文字数)が、所定期間後よりも多くなるようにしてもよい。このことにより、本システムの利用開始時にユーザが戸惑うことが回避され得る。
【0293】
(チーム形成処理のフロー)
図17は、支援実行部561によって実行されるチーム形成処理を示すフローチャートである。
次に、
図17を参照しながら、支援実行部561によって実行されるチーム形成処理について説明をする。
【0294】
まず、支援実行部561は、共通スコアを算出する(S1701)。そして、支援実行部561は、偏りが閾値よりも大きいかを判断する(S1702)。偏りが閾値よりも大きい場合(S1702でYES)、支援実行部561は、他者受容度および自己受容度で示される受容性が閾値よりも大きいかを判断する(S1703)。受容性が閾値よりも大きい場合(S1703でYES)、支援実行部561は全体促進処理を実行する(S1704)。一方、偏りが閾値以下である場合(S1702でNO)あるいは受容性が閾値以下である場合(S1703でNO)、支援実行部561は部分促進処理を実行する(S1705)。
【0295】
(共通スコア)
共通スコアは、性格傾向、趣味、価値観、および実体情報などにおけるユーザ同士におけるユーザ情報の一致点および相違点に基づいて算出した数値(スコア)である。例えば共通スコアは、一致点が多いほど数値が大きくなり、相違点が多いほど数値が小さくなる。
【0296】
(全体促進処理)
上記のように偏りが閾値よりも小さく(S1702でYES)、かつユーザの受容性が閾値よりも高い場合(S1703でYES)に、全体促進処理(S1704)が実行される。ここで、全体促進処理は、チーム全体におけるユーザ同士の関係性を向上させる処理である。例えば、チームを構成する全てのユーザにおける共通点や相違点の提示を行うことや、チーム全体において共通点や相違点について話し合うことを促す処理であってもよい。
【0297】
(部分促進処理)
上記のように偏りが閾値以上である場合(S1702でNO)や、ユーザの受容性が閾値以下である場合(S1703でNO)に、部分促進処理(S1705)が実行される。ここで、部分促進処理は、チームにおける一部のユーザ同士の関係性を向上させる処理である。例えば、チームを構成するユーザのうち、他のユーザとの共通スコアが低いなど偏りが生じている場合に、そのユーザの共通点や相違点の提示を行うことや、そのユーザとの共通点や相違点について話し合うことを促す処理であってもよい。一部のユーザ同士の関係性を向上させることで、チーム全体における関係性の向上がより効率よく実行される。
【0298】
<数値入力処理>
図18は、ユーザ情報管理部510によって出力される数値入力画像を説明する図である。
次に、
図18を参照しながら、ユーザ情報管理部510によって出力される数値入力画像を説明する。
【0299】
上記の例においては、思考・価値観などをユーザから取得する際に、ユーザが端末100を介して各スコアの数値を入力することで受け付けることを説明したがこの入力態様は、特に限定されない。例えば、
図18(A)および(B)に示すように、端末100に表示される数値入力画像を介して、各数値のスコアの入力を受け付けてもよい。この入力された数値情報に基づいて、ユーザ情報が取得され、上記ストロークコンテンツを含む関係性支援コンテンツなどが出力される。
【0300】
具体的には、まず、思考・価値観などの思考情報をユーザから取得する際に、個人の欲求のデータテーブルとして、元から情報処理システム1が記憶(用意)していたもの、および過去に対象とするユーザが記述で答えたもの、1~百数十個(αとする)のリストとし、このリストの中からユーザが重要と考えるものを複数個(例えば8個)選択させる。なお、このとき選択においては、ユーザが複数個を選ぶ処理をすることなく、α全てについてそれぞれ以下の重要度を質問してもよい。例えば、「あなたはプライベートと仕事の両立をどの程度重要視していますか」(0乃至6の数値で評価)のような質問でスコア化をしてもよい。このスコアは、自我関与度として捉えることができる。
【0301】
そして、スコア化された結果を
図18(A)のようにグラフとして表示する。より具体的には
図18(A)な第1スコア画像IM1が、端末100の表示領域(不図示)に表示される。この第1スコア画像IM1は、ユーザが入力した結果を知覚可能なデータとして表現した円グラフIM10を含む。
【0302】
次に、ユーザが重要と考えたものについて、ユーザに以下の操作をさせる。具体的には、まず
図17(B)に示すようにポインタ画像IM21が表示される。このポインタ画像IM21は、例えばマウスなどを介してユーザが指示することにともない、端末100の表示領域(不図示)において移動する。そして、ポインタ画像IM21の位置が移動することにともない、円グラフIM20を構成する各部分の表示領域の大きさが切り替わる。このことにより、円グラフIM20の表示をユーザの実感に合うように切り替えることが可能となる。そして、ユーザによって切り替えられた各部分の表示領域の大きさが、各数値のスコアとして処理される。
【0303】
なお、図示の例とは異なり仕事自体の重要度をユーザから取得してもよい。ユーザから取得した重要度に基づいて、仕事の意義を欲求よりも多く出す場合や、少なく出す場合を切り替えてもいいし、仕事を欲求の一部概念として、その中に、仕事のタスクの種類情報を入れていてもいい。さらに説明をすると、仕事と欲求が分かれている態様であっても、欲求の中に仕事が含まれている場合であってもよい。
【0304】
また、思考・価値観などの思考情報をユーザから取得する際に、発達学や心理学に基づいて、間接的にユーザの思考情報を取得してもよい。例えば、特定の画像をユーザに対して表示し、その特定の画像をユーザが見て嬉しいと感じたか否かでユーザの思考・価値観を推測してもよい。また、例えば特定の画像をユーザに見せた際、あるいは特定の音をユーザに聞かせた際の、ユーザの心拍など生理情報の変移に基づいて、ユーザの思考・価値観を推測してもよい。また、マズローの欲求5段階説に基づいたユーザの欲求段階から、ユーザの思考・価値観を推測してもよい。ここで、マズローの欲求5段階説は、人間の欲求は「生理的欲求」、「安全の欲求」、「社会的欲求」、「承認欲求」、「自己実現欲求」の5段階のピラミッドのように構成されているとする心理学理論である。そして、上記思考・価値観などの思考情報をユーザから取得する際に、ユーザの欲求に関する情報が上記5段階のうちのいずれに応じるかを判断し、その段階に対応する思考・価値観を判断結果としてもよい。例えば、ユーザの欲求段階が「承認欲求」に当たる場合は、対象とするユーザの思考・価値観が、多くの人に好かれたいなどの欲求であると判断してもよい。
【0305】
また、ユーザの肉体および精神の状態によって、ユーザの思考・価値観は変化することがある。そこで、ユーザの生理情報を含む心身状態情報に基づいて、ユーザの肉体および精神の状態を判断し、ユーザの思考・価値観の内容を推定してもよい。ここでの思考・価値観の内容とは、思考・価値観の対象となるもの、例えばユーザが重要と考えるものの種別や割合などである。
【0306】
<ストローク確認画像>
図19は、支援実行部561によって出力されるストローク確認画像を説明する図である。
次に、
図19を参照しながら、支援実行部561によって出力されるストローク確認画像を説明する。
【0307】
上記のように、支援実行部561は、各ユーザが自身のストロークを把握することの支援を実行する。例えば、
図19(A)および(B)に示すように、端末100に表示されるストローク確認用の画像を介して、ユーザ自身が行うストロークを把握することを容易にしてもよい。
【0308】
具体的には、
図19(A)に示す第1ストローク画像IM3を、ストロークコンテンツ(
図14のS1405参照)として端末100に表示してもよい。この第1ストローク画像IM3は、対象とするユーザが実行する全ストロークにおけるストロークの種別ごとの割合を表示する円グラフIM30と、注釈画像IM31とを含む。
【0309】
図示の例における円グラフIM30は、無条件肯定ストローク、条件付き肯定ストローク、無条件否定ストロークおよび条件付き否定ストロークの全ストロークにおける各割合を数値(45%など)とともに示す。この第1ストローク画像IM3により、ユーザ自身が行うストロークの傾向を視覚的に把握することが可能となる。ここで、本システムは、ストロークの傾向、すなわち対象とするユーザが行うストロークの態様に応じて、ユーザに対してアドバイスを出力してもよい。例えば、無条件否定ストロークが含まれる場合に、無条件否定を止めるように促すアドバイスを出力してもよい。また、条件付否定ストロークが基準よりも多い場合には、条件付肯定ストロークを多くするようアドバイスを出力してもよい。また、条件付肯定ストロークが基準よりも多い場合には、無条件肯定ストロークを多くするようアドバイスを出力してもよい。なお、詳細は省略するが、上記
図18で説明した円グラフIM10と同様に、円グラフIM30を構成する各部分の表示領域の大きさを切り替える操作にともない、ストロークの割合を変更してもよい。
【0310】
また、
図19(B)に示すように、第2ストローク画像IM5を端末100に表示してもよい。第2ストローク画像IM5は、対象とするユーザが実行するノンストロークの数を示す棒グラフIM50と、許容されるノンストロークの基準値を示す基準線IM51とを含む。第2ストローク画像IM5により、ユーザが実行するノンストロークの実情を視覚的に把握することが可能となる。また、棒グラフIM50とともに基準線IM51を表示することにより、ユーザが実行するノンストロークの実情をより客観的に把握することが可能となる。
【0311】
ここで、上記のようにノンストロークは無くすことが好ましいストロークである。そこで、
図19(A)および(B)に示す例においては、ノンストロークは、他のストローク(無条件肯定ストローク、条件付き肯定ストローク、無条件否定ストロークおよび条件付き否定ストローク)とは別の画像として表示される。ノンストロークを他のストロークとは別の画像として表示することで、無くすべき対象であるノンストロークの実態を、ユーザがより明確に把握することが可能となる。
【0312】
また、条件付肯定ストロークおよび条件付否定ストロークにおける条件は、対象とするユーザが行った言動の過程(プロセス)を条件する場合と、その過程の結果もたらされる結果を条件とする場合とがある。例えば条件付否定ストロークを行う際に、過程を条件とする場合と結果を条件とする場合との割合を出力してもよい。例えば、職場における上司のユーザが、所定期間において部下のユーザに対して行った条件付否定ストロークのデータを所得する。そして、部下のユーザに対して行った条件付否定ストロークのうち、過程を条件とするストロークと結果を条件とするストロークとの割合を画像として出力してもよい。このとき、その職場における上司として実現することが望まれる割合を基準として表示してもよい。この基準が表示されることにより、上司のユーザに自身のストロークを変更することを促すことができる。さらに説明をすると、上司が実際に行ったストロークの割合と、基準との比較に応じて、出力されるアドバイスを切り替えてもよい。
【0313】
なお、この割合の表示は、条件付肯定ストロークおよび条件付否定ストローク以外の他のストロークの種別も含めて算出してもよい。例えば、無条件否定ストロークと条件付否定ストロークとを合わせた否定ストロークがストローク全体において占める割合を算出し出力してもよい。ここで、例えば対象とするユーザが、他のユーザの存在を否定する無条件否定ストロークを行うことがある。このユーザに対しては、他のユーザの存在を否定するストロークと、過程を条件とするストロークと、結果を条件とするストロークとの割合を出力してもよい。そして、この割合に応じて、ユーザに出力されるアドバイスを切り替えてもよい。
【0314】
図20は、支援実行部561によって出力される他のストローク確認画像を説明する図である。
次に、
図20を参照しながら、支援実行部561によって出力される他のストローク確認画像を説明する。
【0315】
上記のように
図19(A)および(B)を参照しながら、第1ストローク確認画像IM3および第2ストローク画像IM5を端末100に表示することを説明したが、これに限定されない。例えば
図20に示すように、第3ストローク確認画像IM6を端末100に表示してもよい。
【0316】
ここで、第3ストローク確認画像IM6は、第3ストローク確認画像IM6が示す内容を説明する説明画像IM61と、対象とするユーザが実行する肯定ストロークと否定ストロークの割合を画像で表示する棒グラフIM63と、肯定ストロークと否定ストロークの割合を文字で表示する文字画像IM65と、肯定ストロークと否定ストロークとの割合50%を示す基準線IM67とを含む。
【0317】
この例においては、無条件肯定ストロークおよび条件付き肯定ストロークを肯定ストロークで合算し、無条件否定ストロークおよび条件付き否定ストロークを否定ストロークで合算し、棒グラフIM63および文字画像IM65として表示される。このことにより、ユーザが自身のストロークの傾向をより容易に把握することが可能となる。
【0318】
なお、
図20に示す第3ストローク確認画像IM6と、
図19(A)に示す第1ストローク確認画像IM3とを組み合わせて表示させてもよい。例えば、第3ストローク確認画像IM6において、詳細情報を表示させる切替アイコン(不図示)を表示し、そのアイコンをユーザが操作することに伴い第1ストローク確認画像IM3を表示させてもよい。このことにより、ユーザの要求に応じてユーザ自身のストロークについての情報の詳細度を切り替えることが可能となる。
【0319】
<相互理解促進画像>
図21は、支援実行部561によって出力される相互理解促進画像を示す図である。
次に、
図21を参照しながら支援実行部561によって出力される相互理解促進画像について説明をする。
【0320】
上記のように、支援実行部561は、ユーザ同士の関係性を支援するコンテンツとして、複数のユーザに支援情報を出力することがある。すなわち、共通の支援を実行する場合において、2人以上のユーザに支援情報を出力することがある。この支援情報は、全ユーザで同一のものであってもよいし、ユーザごとに異なるものであってもよい。
【0321】
図21に示す例においては、ユーザAとユーザBとの関係性を向上させる支援を実行する。そして、この例においては、ユーザAとユーザBとに異なる支援情報が出力される。具体的に説明をすると、支援実行部561は、ユーザAが操作する端末100と、ユーザBが操作する端末200とに、各ユーザへの行動変容を促すようなアドバイを含む相互理解促進画像を表示させる。この例においては、相互理解促進画像として、第1相互理解促進画像IM7および第2相互理解促進画像IM9が、それぞれ端末100および端末200に表示される。
【0322】
第1相互理解促進画像IM7は、上記のようにユーザAが操作する端末100に表示される。この第1相互理解促進画像IM7は、「断定的な口調にならないようにしましょう。」という文字列を含むユーザAに対するアドバイスである。また、第2相互理解促進画像IM9は、ユーザBが操作する端末200に表示される。この第2相互理解促進画像IM9は、「Aさんは、もしかしたらあなたとの会話で断定的な口調になるかもしれません。」という文字列を含み、ユーザBに対するアドバイスとなる第2アドバイス画像IM91と、「しかし、それはAさんが自信をもって仕事に取り組んでいるという良い性質の裏返しと考えることもできます。」という文字列を含む第3アドバイス画像IM93とを含む。
【0323】
ここで、図示の例においては、第2アドバイス画像IM91において他のユーザ(ユーザA)がしてしまうこと(断定的な口調になること)の情報を示すとともに、第3アドバイス画像IM93において他のユーザがその言動を行う原因を肯定的な表現で提示する。いわば、第2アドバイス画像91で実体的な情報を示すとともに、第3アドバイス画像IM93において、実体的な情報が肯定的に理解されることを促す補足情報を示す。このことにより、第2アドバイス画像IM91が表示されるユーザBが、ユーザAの行動をより肯定的に受け止めやすくなる。このことにより、ユーザAとユーザBとの関係性がより良好になり得る。
【0324】
なお、ここでは第1相互理解促進画像IM7および第2相互理解促進画像IM9を例に、肯定的な理解を促すための補足情報を出力することを説明したが、対象とするユーザを支援するための支援情報として他のユーザの属性情報を表示する情報であれば、特に限定されない。例えば、他のユーザ(図示の例においてはユーザA)がしてしまうこと(図示の例においては断定的な口調になること)の情報を示すとともに、そのような行動をとる背景(例えば、タスクが多く心理的な余裕がない)などの情報を出力してもよい。
【0325】
図22は、支援実行部561によって出力される他の相互理解促進画像を説明する図である。
次に、
図22を参照しながら、支援実行部561によって出力される他の相互理解促進画像を説明する。
【0326】
上記のように
図21を参照しながら、第1相互理解促進画像IM7および第2相互理解促進画像IM9を表示することを説明したが、これに限定されない。例えば
図22に示すように、第3相互理解促進画像IM8を端末100に表示してもよい。
【0327】
ここで、第3相互理解促進画像IM8は、タイトル画像IM81と、対象とするユーザにおける他のメンバーへの理解度を画像で表示する棒グラフIM83とを含む。この例においては、棒グラフIM83は、対象とするユーザが所属するチームのチームメンバーであるユーザA乃至ユーザE各々についての理解度が、理解度の順位に従って表示されている。
【0328】
第3相互理解促進画像IM8によって、チームメンバーへの理解度をユーザがより明確に把握することが可能となる。なお、理解度が低いユーザ(図示の例においてはユーザE)が視覚的に強調されて表示されることで、ユーザが理解度を増すことが必要なユーザをより確実に把握できるようにしてもよい。
【0329】
なお、チームメンバー各々の理解度についてより詳細な情報が表示されてもよい。例えば、ユーザAについての相互理解における具体的な項目、例えば、共通点、相違点、尊敬点、好きなもの、価値観などの各々において6段階の数値(1乃至6)で評価し、その結果を画像として表示してもよい。なお、各数値が高いほど、対象項目についてよく理解していることを示す。なお、各項目の評価の結果は、
図22に示すような棒グラフや、
図23に示すレーダーチャートのように周知のグラフにより表示されてもよい。グラフにより表示されることで、ユーザ自身がより理解を含めるべき項目を把握することが容易となる。
【0330】
<根本的実体画像>
図23は、支援実行部561によって出力される根本的実態画像を示す図である。
次に、
図23を参照しながら支援実行部561によって出力される根本的実体画像について説明をする。
【0331】
支援実行部561は、例えば登録時コンテンツの出力(
図4のS403参照)において、対象とするユーザと他のユーザとの関係性を示す画像を出力してもよい。具体的には、例えば
図23に示すように、根本的実体画像IM40をユーザに表示してもよい。
【0332】
この根本的実体画像IM40は、対象とするユーザと他のユーザとの関係性、すなわち人間関係の土台となる状態として、根本的情報を可視化した人間関係グラフIM41を含む。また、根本的実体画像IM40は、人間関係グラフIM41で示される各項目の重要性を示す説明画像である相互理解説明画像IM43と、相互援助説明画像IM45と、ストローク説明画像IM47とを含む。また、根本的実体画像IM40は、情報処理システム1が現在改善しようとしている対象の項目を示す改善対象画像IM49を含む。この改善対象画像IM49が対象ユーザに表示されることにより、対象ユーザ自身が改善すべき項目を把握することができ、対象ユーザの行動変容をより促し得る。
【0333】
この例における根本的実体画像IM40は、「相互理解説明」、「相互援助」および「ストローク」の3つの項目を含むが、これに限定されない。例えばこれらの3つのうちの一部であってもよい。また、根本的実体画像IM40は、潜在的相性など他の項目とともに、上記3つの項目の全部または一部が表示されてもよい。
【0334】
<カリキュラム処理>
(カリキュラム処理の概略)
さて、上記の説明においては、ユーザ情報に基づいて関係性支援コンテンツを出力することを説明した。ここで、関係性支援コンテンツを決定する処理は、上記の説明に限定されない。例えば、支援実行部561が、ユーザ同士の関係性などのユーザ情報を簡易に情報取得(簡易情報取得)し、関係性が悪いと判断される項目について詳細な情報を取得(詳細情報取得)してもよい。すなわち、情報の詳細度が異なる複数の段階で、ユーザ情報を取得してもよい。そして、支援実行部561が、取得した詳細な情報に基づいて、関係性支援コンテンツを決定してもよい。
【0335】
ここで、1段階目における簡易なユーザ情報の取得をした後に、関係性支援コンテンツのカリキュラムを設定してもよい。そして、カリキュラムが設定された後に、2段階目における詳細なユーザ情報の取得をし、ユーザに提示する関係性支援コンテンツを決定してもよい。
【0336】
(簡易情報取得)
簡易情報取得は、ユーザ同士の関係性に関する質問をユーザに対して出力し、その回答を得ることで実行される。例えば、ストローク、相互理解、相互援助の各項目についてそれぞれ2問、合計6問の質問を行い、回答を取得してもよい。各項目の状態を取得する質問は、主観情報および客観情報を含むとよい。例えば、主観情報および客観情報を取得する質問を1問ずつ行ってもよい。なお、主観情報は、ユーザ自身がどのような状態であるかを示す情報である。また、客観情報は、対象とするユーザが他のユーザの状態をどのように感じるかを示す情報である。ここで、ユーザAの客観情報としては、他のユーザであるユーザB、ユーザC、ユーザDの状態をユーザAがどのように感じているかを示す情報を含む。
【0337】
ここで、簡易情報取得は、所定期間(例えば1カ月)ごとに行うことを原則とする。また、上記の例で説明をすると、ストローク、相互理解、相互援助のいずれかまたは全部の項目が閾値を超えている場合、すなわち状態が悪い場合は、より短い期間(頻度を高く)して情報所得を行ってもよい。
【0338】
(カリキュラム)
カリキュラムとは、複数の関係性支援コンテンツを出力するタイミングを設定するものである。さらに説明をすると、カリキュラムとは、複数の関係性支援コンテンツの出力回数を決定するものである。そして、カリキュラムに基づいて、出力する関係性支援コンテンツが決定される。このカリキュラムは、例えば支援実行部561によって記憶される。また、カリキュラムを用いて支援内容を決定する処理をカリキュラム処理と呼ぶ。カリキュラム処理においては、例えば関係性支援コンテンツの出力回数と支援コンテンツの内容を同時に決定する処理と比較して、処理の負担が軽減され得る。
【0339】
カリキュラムは、例えば、簡易情報に基づいて、関係性支援コンテンツの合計の出力回数(総アドバイス回数)と、相互理解、相互援助、ストロークの各項目のアドバイス回数(項目アドバイス回数)とを決定する。なお、この例においては、項目アドバイス回数の総和が総アドバイス回数となる。
【0340】
付言すると、カリキュラムは、簡易情報に基づいて、関係性支援コンテンツの項目ごとの実行割合を決定する。なお、カリキュラムの決定は、上記の例における主観情報および客観情報に基づいて実行される。
【0341】
例えば項目アドバイス回数は、ユーザやユーザが所属するチームの要望に基づいて調整してもいい。例えば、項目アドバイス回数は、ユーザが改善したい項目、またはユーザが改善できそうな項目の項目アドバイス回数を増やすなどの調整をしてもよい。
【0342】
また、チームに所属するユーザ全員に、どのようなチームになりたいかを質問し、得られた情報(チーム欲望情報)に基づいて、関係性支援コンテンツの提示内容や提示頻度を変更してもいい。このチーム欲望情報の取得は、各ユーザから得られた質問に対する回答を集計して算出する。例えば、チーム欲望情報は、所謂選挙のように、各ユーザに対して「相互援助が当たり前のチームにしたい」、「お互いに理解しあっているチームにしたい」などの項目のうちから所定数を選択させ、選択された数が多い項目を集計結果として決定してもよい。
【0343】
また、総アドバイス回数および項目アドバイス回数を決定する方法は、例えば以下の2通りの方法であってもよい。
第1の方法は、主観情報と客観情報を一定の割合で統合して、主観・客観統合情報に基づき、決定する方法である。例えば、主観情報を80%および客観情報を20%として、統合スコアを算出する。この統合スコアに基づき、総合アドバイス回数を決定してもよい。また、例えば主観情報を「5」および客観情報を「3」として、統合スコアを4.6が算出され、結果として総アドバイス回数を3回として設定してもよい。
【0344】
第2の方法は、主観情報に基づく提示回数、および客観情報に基づく提示回数をそれぞれ予め設定して、それぞれの提示回数を合算して総アドバイス回数とする方法である。例えば、主観情報を「5」、および客観情報を「3」とする。そして、提示回数を、主観情報で「1回」、客観情報で「3回」が算出され、結果として総アドバイス回数を「4回」として設定してもよい。
【0345】
なお、所定期間(例えば6カ月)のカリキュラムを設定する態様として、1回で所定期間における全期間における各項目アドバイス回数を決定する態様(シングル設定)としてもいいし、複数回に分けて各項目アドバイス回数を繰り返し決定する態様(ループ設定)としてもいい。また、ループ設定において2回目以降のカリキュラム決定においては、前回までの詳細情報に基づいて、各項目アドバイス回数を決定してもよい。例えば、所定期間として6カ月の期間において、所定間隔として1カ月ごとに項目アドバイス回数を決定する態様でもよい。そして、所定期間の開始から1カ月、すなわち2ヶ月目のカリキュラム決定時に、1ヶ月目の詳細情報を利用する。このことにより、よりユーザ情報に沿ったコンテンツの提示が可能となる。
【0346】
なお、カリキュラムは、ストローク、相互理解および相互援助の一部または全部のバランスに基づいて決定される。例えば、相互理解のスコアが、ストロークおよび相互援助のスコアよりも低い場合は、相互理解のアドバイス回数が多くなるように設定される。また、ストロークのスコアが、相互理解および相互援助よりも高い場合は、ストロークのアドバイス回数が少なくなるように設定される。このとき、ストロークのアドバイス回数をゼロとしてもよい。
【0347】
また、カリキュラムによって決定されたアドバイスに従って実行することを促す画像などを、ユーザに対して出力してもよい。例えば、所定期間(例えば1週間)ごとに、対象とする期間において達成すべき目標を出力してもよい。この目標の出力としては、例えば「今週1週間はチームメンバーの意見をしっかりきくことをこころがけましょう」などの文字を含む画像の出力がある。このように目標がユーザに通知されることで、ユーザのモチベーションを高めることが可能となり、結果としてユーザがアドバイスを実行する可能性が高まる。また、所定期間(例えば1月間)ごとに対象とする期間において出力されるアドバイス(カリキュラム)の概略を通知してもよい。このように予め概略がユーザに通知されることで、アドバイスを受けた際に感じるユーザの抵抗感が抑制され、ユーザがアドバイスを実行する可能性が高まる。
【0348】
(詳細情報取得)
詳細情報取得とは、ユーザ同士の関係性において、どの状態が悪いのかを具体的に判定するための情報を取得することである。例えば、ストロークにおいては、無条件肯定の項目が相対的に悪いのか、無条件否定の項目が相対的に悪いのかなどが詳細情報として取得される。そして、取得された詳細情報に基づいて、実行するアドバイスの判定がなされる。すなわち、詳細情報は、どのアドバイス(支援情報)を実行するかを決定する際の判断を行うための情報である。
【0349】
この詳細情報取得においては、主観情報だけでなく、客観情報を取得することもある。この客観情報の取得としては、例えばユーザAに対して、他のユーザであるユーザBが無条件肯定ストロークの中でどの行動ができていないかを質問し、その回答をユーザAから得てもよい。なお、詳細情報取得を実行するタイミングは、例えばカリキュラム作成時から所定期間(1カ月以内)などとして予め設定してもよい。この予め設定されたタイミングになると、詳細情報取得のため、ユーザに質問等がなされる。
【0350】
(アドバイス提示)
アドバイス提示は、詳細情報に基づいてどのアドバイスを提示するかを決定する処理である。この決定されたアドバイスをユーザに提示するタイミングは、特に決定されない。例えば、詳細情報の取得にともない、アドバイスを提示してもよい。さらに説明をすると、詳細情報を取得した日と同日、さらに説明をすると、詳細情報を取得した直後にアドバイスを提示してもよい。また、詳細情報を取得した日の後(後日)にアドバイスを提示してもよい。
【0351】
(カリキュラム処理のフロー)
図24は、支援実行部561によって実行されるカリキュラム処理を示すフローチャートである。
次に、
図24を参照しながら、支援実行部561によって実行されるカリキュラム処理について説明をする。
【0352】
まず、支援実行部561は、簡易情報を取得する(S2201)。そして、支援実行部561は、取得した簡易情報に基づいてカリキュラムを決定する(S2202)。そして、支援実行部561は、詳細情報を取得する(S2203)。そして、支援実行部561は、取得した詳細情報およびカリキュラムに基づいて、提示コンテンツを決定する(S2204)。そして、支援実行部561は、カリキュラムで設定されたタイミングで、コンテンツを出力する(S2205)。
【0353】
<カリキュラム要望受付画像>
図25は、支援実行部561によって出力されるカリキュラム要望受付画像IM60を示す図である。
次に、
図25を参照しながら、カリキュラム処理において出力されるカリキュラム要望受付画像IM60について説明をする。
【0354】
まず、上記カリキュラム決定処理においては、カリキュラムについてのユーザの要望を参照してもよい。例えば、ユーザから、関係性支援コンテンツの項目ごとの実行割合の希望を受け付けて、その希望に基づいてカリキュラムを決定してもよい。言い替えると、各項目アドバイス回数の希望をユーザから受け付け、その希望に基づいてカリキュラムを決定してもよい。
【0355】
例えば、
図25に示すように、カリキュラム要望受付画像IM60が、ユーザAが操作する端末100に表示される。このカリキュラム要望受付画像IM60は、カリキュラムについてのユーザによる調整や確認を行う質問画像IM61と、ユーザからの入力を受け付ける受付画像IM63と、ユーザの要望を受け付けることの趣旨を説明する説明画像IM67と、ユーザによる入力データの決定を受け付ける決定画像IM69を有する。
【0356】
図示の例における受付画像IM63は、ユーザがその表示位置を調整可能な第1スライダ画像IM64および第2スライダIM66を有する。この第1スライダ画像IM64および第2スライダIM66の表示位置を調整することによって、ユーザは各項目の実行割合を変更することができる。さらに説明をすると、図示の例においては、第1スライダ画像IM64および第2スライダIM66がスライド移動することによって、「伸ばす分野」における「職場での人間関係」、「支えてくれている人」、および「職場以外での人間関係」の各項目のアドバイスを実行する割合(項目アドバイス回数)が変更される。
【0357】
さて、ここでは簡易情報および詳細情報に基づいてカリキュラムおよび出力されるコンテンツを決定することを説明したが、これに限定されない。ユーザ情報に応じてカリキュラムおよび出力されるコンテンツの少なくとも一方が決定されればよい。例えば、ユーザの心身状態情報に応じて、カリキュラムおよび出力されるコンテンツが切り替えられてもよい。
【0358】
さらに説明をすると、例えばユーザの忙しさあるいはユーザが属するチームの忙しさに応じて、カリキュラムを変更してもよい。例えば、所定期間(1週間、1月)ごとに、ユーザに対して忙しさの程度を質問するなどして、忙しさ情報を取得する。そして、ユーザが忙しい場合には、忙しくない場合と比較して、関係性支援コンテンツの合計の出力回数(総アドバイス回数)を低減させてもよい。このとき、ユーザの忙しさの程度に応じてアドバイスの出力回数が低減された旨をユーザに対して出力してもよい。例えば、「今週は忙しいようなので、本来3回出すべきアドバイスを1回に変更しました。」というような画像をユーザに対して出力してもよい。このような出力をすることにより、ユーザが自身の状況を踏まえてアドバイスが得られるという安心感を得ることができる。
【0359】
また、ユーザが本システムを利用し始めてからの時間(利用期間)に応じて、カリキュラムおよび出力されるコンテンツの少なくとも一方が決定されてもよい。例えば、利用期間が2週間(所定期間)を経過するまでは、2週間を経過した後と比較して、関係性支援コンテンツの合計の出力回数(総アドバイス回数)を増加させてもよい。このことにより、本システムの利用に関する心理的な抵抗感が低減され、所謂本システムに慣れた状態となる。その結果、本システムの利用頻度が高まることや、アドバイスが受け入れられる可能性が高まる。なお、利用期間に応じてアドバイスの出力回数が増加する旨をユーザに対して出力してもよい。例えば、「本システムの利用を開始された直後なので、まずは本システムに慣れていただくため、出力回数が増えています。」というような画像をユーザに対して出力してもよい。このことにより、ユーザが出力されるアドバイスが多すぎると感じ、本システムの利用を停止することが抑制され回避され得る。
【0360】
<家族関係処理>
(家族関係処理の概略)
次に、家族関係処理について説明をする。
まず、上記の情報処理システム1が支援するユーザが所属する集団は、複数人により構成されるものであれば特に限定されない。例えば夫婦などの家族における人間関係において上記システムを利用してもよい。
【0361】
家族関係を支援する処理である家族関係支援処理においては、家族の関係性を示す家族関係情報に基づいて、家族の関係性を維持または向上させるための関係支援コンテンツ(家族関係コンテンツ)を提示する。
【0362】
(家族関係情報)
家族関係情報は、家族関係、現在の関係性状態、関係性の継続時間、過去の関係性状態を含む。家族関係は、夫婦、親子などユーザ同士の関係を示す。現在の関係性状態は、家族(夫婦)の現在の関係性を示し、良好、標準、不良に分類される。この現在の関係性情報は、特に限定されないが、ユーザに質問をし得られる回答から取得してもよいし、日常のユーザ同士の関係情報(一日に会話した回数及び時間、ストロークの状態、理解度の情報)などから推測してもよい。関係性の継続時間は、夫婦になってからの期間や、ユーザの子供が誕生してからの期間などである。過去の関係性状態は、夫婦の関係性が良好であった時期や良好さの程度などである。
【0363】
(家族関係コンテンツ)
家族関係コンテンツは、家族の関係性を維持または向上するための情報であれば特に限定されない。また、例えば夫婦の関係性が不良である場合には、家族関係コンテンツにおける意識変容のためのコンテンツの提示回数が増えるなど、家族関係コンテンツの出力態様が切り替えられてもよい。
【0364】
また、図示の例においては、ユーザに出力される家族関係コンテンツは、イベント情報、忙しさ情報、分担情報に基づいて切り替えられる。
ここで、イベント情報は、家族における過去の楽しい出来事、過去の好きだったこと、過去の感謝していることを示す情報である。このイベント情報は、ユーザ登録などの所定のタイミングにおいて、ユーザが入力するワークを行うことにより取得される。なお、このイベント情報は、家族関係情報として取得されてもよい。
【0365】
忙しさ情報は、上記のようにユーザの忙しさの程度を示す情報である。なお、家族関係コンテンツにおける忙しさ情報としては、ユーザの仕事(例えば、労働)における忙しさや、ユーザが仕事を行っているとき以外(例えば、家事、育児)の忙しさ、および仕事に関係せずにユーザが心理的に感じる忙しさを含む。
【0366】
分担情報は、ユーザが家庭内で行うべき家事等のタスクの分担を示す情報である。言い替えると、分担情報は、家族が家事や育児をどのように分担しているかを示す情報である。この分担情報は、家事や育児の分担に対するユーザの満足度を含んでもよい。また、分担情報は、夫婦に家の外での必要な活動時間(例:労働)、家の中での必要な活動時間(例:家事、育児)を取得し、その活動時間に応じた、夫婦の負担スコアとして算出される。ここで、負担スコアの算出においては、ユーザの性格傾向や価値観に基づいて負担スコアを調整してもよい。例えば、ユーザが現在行っている仕事に対してユーザ自身が非常に意義を感じていた場合、仕事に意義を感じていない場合よりも、負担スコアを低くしてもよい。また、例えば、夫婦における妻が掃除を全て行い、かつ夫の誠実性が低い場合、誠実性が高い場合よりも妻の負担スコアを高くしてもよい。
【0367】
家族関係コンテンツは、イベント情報、忙しさ情報、分担情報の一部または全部に基づいて切り替えられる。例えば、夫婦の関係性情報が不良だった場合、イベント情報を、相手に対して伝えるよう促すコンテンツを出力してもよい。また、夫婦の関係性情報が不良だった場合、相手のユーザの関係支援コンテンツとして、相手に対してイベント情報を出力する態様でもよい。また、対象とするユーザが忙しい場合、相手のユーザの関係支援コンテンツとして、余裕のある範囲で、ストレス値が高い、または忙しいユーザの家の中でのタスクを他のユーザが代わりに行うよう促すコンテンツを出力する態様でもよい。また、ユーザの満足度が所定値よりも低い場合に、家事の分担について話し合うよう促すコンテンツを出力する態様でもよい。
【0368】
ここで、ユーザの満足度が所定値よりも低い場合に、夫婦である各ユーザのユーザ情報を互いに見せ合うアドバイスしてもよい。また、一方のユーザのユーザ情報を他方のユーザに出力し、他方のユーザに対して一方のユーザの状況を理解するよう促すアドバイスを出力してもよい。例えば、ユーザ情報としては、対象とするユーザの忙しさ、ストレス値、家事や育児の分担(作業負担)のいずれかが少なくとも含まれる。これらのユーザ情報は、家族間であることを条件に互いに開示されることで、個人情報の開示を管理しながら互いの相互理解を深めることが可能となる。
【0369】
(家族関係処理のフロー)
図26は、支援実行部561によって実行される家族関係処理を示すフローチャートである。
次に、
図26を参照しながら、支援実行部561によって実行される家族関係処理について説明をする。
【0370】
まず、支援実行部561は家族関係情報を取得する(S2401)。そして、支援実行部561は、取得した家族関係情報に基づいて、関係性が良好であるかを判断する(S2402)。
【0371】
関係性が良好であった場合(S2402でYES)、支援実行部561はイベント情報を取得する(S2403)。また、支援実行部561は忙しさ情報を取得する(S2404)。また、支援実行部561は分担情報を取得する(S2405)。そして、支援実行部561は、取得した情報に基づいてコンテンツを出力する(S2406)。
【0372】
(親子関係支援処理)
家族関係処理は、その一例として親子関係処理を含む。この親子関係処理においては、子供の個人特性情報に基づいて、家族関係コンテンツが出力される。例えば、子供の年齢や子供自己肯定感を示す自己肯定感スコアなど子供のユーザ情報に基づいて、家族関係コンテンツを切り替えてもよい。例えば、子供の自己肯定感スコアが低いときに、両親に対する家族関係コンテンツとして、無条件肯定ストロークを増やすよう促すコンテンツを出力してもよい。
【0373】
また、親のユーザ情報および子供のユーザ情報に基づいて、家族関係コンテンツを切り替えてもよい。例えば、親の価値観および子供の価値観の差に基づいて、家族関係コンテンツが決定されてもよい。
【0374】
(親子関係支援画像IM80)
図27は、支援実行部561によって出力される親子関係支援画像IM80を示す図である。
【0375】
次に、
図27を参照しながら、親子関係支援処理において支援実行部561によって出力される親子関係支援画像IM80について説明をする。この親子関係支援画像IM80は、親の価値観および子供の価値観の差が大きい(乖離している)場合に出力される家族関係コンテンツの一例である。
【0376】
図27に示すように、親子関係支援画像IM80は、ユーザAが操作する端末100に表示される。この親子関係支援画像IM80は、親であるユーザに子供の価値観を受けいれることを促す価値観変容画像IM81と、コンテンツを表示する理由を示す理由画像IM83、IM85とを有する。この理由画像IM83、IM85が表示されることにより、ユーザAが子供の価値観を受け入れやすくなる。
【0377】
<職場関係処理>
(職場関係処理の概略)
次に、職場関係処理について説明をする。
【0378】
職場におけるユーザ同士の関係を支援する処理である職場関係支援処理においては、職場の関係性を示す職場関係情報に基づいて、職場における関係性を維持または向上のための関係支援コンテンツ(職場関係コンテンツ)を提示する。
【0379】
(職場関係情報)
職場関係情報は、心理的安全性、チームストレスおよびエンゲージメントを含む。心理的安全性は、上記のように職場で自分の考えを自由に行動できると考える心理状態を示す。チームストレスは、職場のチームのメンバーが感じるストレスを示す。このチームストレスは、チーム情報の一例である。エンゲージメントは、職場に貢献したいと考える意欲を示す。
【0380】
なお、エンゲージメントは、例えば、成長性、関連性、自主性の3つの要素についてそれぞれスコア化される。成長性は、会社やチームで仕事をすることで成長できるとユーザが感じられることを示す。関連性は、チームの人間関係を示し、ストローク状態や相互理解状態などが含まれる。自主性は、ユーザが感じる仕事の意義を示す。
【0381】
(職場関係コンテンツ)
職場関係コンテンツは、職場における関係性を維持または向上するための情報であれば特に限定されない。また、職場における関係性が不良である場合には、職場関係コンテンツにおける意識変容のためのコンテンツの提示回数が増えるなど、職場関係コンテンツの出力態様が切り替えられてもよい。
【0382】
なお、職場関係コンテンツは、ユーザの職種に応じて切り替えられてもよい。例えば、ユーザが看護師の場合、心身に負荷がかかる職種であるため、ユーザ同士が互いに精神的なケアをするように促すコンテンツが優先的に出力されてもよい。また、ユーザが営業担当の場合、他のユーザとの関係がライバルであると考えられる傾向があるため、他のユーザは敵ではなく、良きライバルとして接するよう促すコンテンツが優先的に出力されてもよい。また、ユーザがエンジニアの場合、他のユーザとコミュニケーションを取らずに業務を行う傾向があるため、趣味などの基本情報を他のユーザと共有することを促すコンテンツが優先的に出力されてもよい。また、ユーザがバックオフィス担当の場合、ミスが許されないという価値観のもと業務を行う傾向があるため、例えばミスをした人がいたとしても、その人のことを責めないように促すコンテンツが優先的に出力されてもよい。
【0383】
(職場関係処理のフロー)
図28は、支援実行部561によって実行される職場関係処理を示すフローチャートである。
次に、
図28を参照しながら、支援実行部561によって実行される職場関係処理について説明をする。
図28に示す例においては、職場関係情報として、心理的安全性を用いて職場関係コンテンツを切り替える。
【0384】
図28に示すように、まず、支援実行部561は職場関係情報として、心理的安全性総合情報を取得する(S2601)。そして、支援実行部561は、取得した心理的安全性総合情報に基づいて、心理的安全性総合スコアを算出する(S2602)。そして、支援実行部561は、心理的安全性総合スコアが閾値以下、すなわち総合スコアが不良であるかを判断する(S2603)。
【0385】
総合スコアが不良であった場合(S2603でYES)、支援実行部561は特定不良スコアが有るかを判断する(S2604)。そして、特定不良スコアが有る場合(S2604でYES)、支援実行部561は、特定項目情報を取得する(S2605)。そして、支援実行部561は、取得した特定項目情報に基づいて、特定項目スコアを算出する(S2606)。そして、支援実行部561は、取得した情報に基づいてコンテンツを出力する(S2607)。
【0386】
ここで、心理的安全性総合情報は、上記簡易情報の一例である。そして、心理的安全性総合情報を取得するステップ(S2601参照)においては、例えば心理的安全性を計測するのに標準的に用いられている7つの質問をチームメンバーであるユーザ全員に出力する。そして、この回答に基づいて、心理的安全性総合スコアが算出される(S2602参照)。
【0387】
また、特定項目情報は、上記詳細情報の一例である。そして、特定項目情報を取得する(S2605参照)においては、例えば「自分が考えている意見やアイデアを同僚や上司に伝えることができているか」、「分からないことを同僚や上司に聞くことができるか」、「困っているときに上司や同僚に助けを求めることができるか」、「悪い報告(例えば、ミス、売上予測が悪いなど)を上司や部下、チーム全員にすることができるか」、「新しいことに挑戦することができるか」などの質問をチームメンバーであるユーザ全員に出力する。そして、この回答に基づいて、特定項目スコアが算出される(S2606参照)。
【0388】
このように、全体の状況を示す心理的安全性総合情報を取得した後に、必要に応じてより詳細な特定項目情報を取得する。このことにより、職場関係コンテンツを出力するためにユーザが入力すべき情報の量が抑制され得る。
【0389】
なお、心理的安全性総合スコアは、各コンテンツとともにユーザに出力されてもよい。心理的安全性総合スコアが出力されることにより、ユーザがスコアを改善するモチベーションが発生し、結果として職場におけるユーザ同士の関係性が良好となり得る。付言すると、心理的安全性総合スコアが閾値よりも低い場合には、閾値より高い場合とは異なり、心理的安全性が低いことを示す情報をユーザに出力しない処理を行ってもよい。例えば、心理的安全性総合スコアが閾値よりも低い場合には、閾値より高い場合に出力される心理的安全性総合スコアをユーザに出力しない処理を行ってもよい。心理的安全性総合スコアが低いことをユーザが認識することにともない、例えばユーザが所属する集団に対して失望してユーザのモチベーションが下がり、結果としてユーザが集団から離脱する(例えば、退職する)など、不利益が生じることが回避される。
【0390】
また、例えば、心理的安全性総合スコアが閾値よりも低い場合には、閾値より高い場合に出力される心理的安全性に関する画像(例えばグラフ)をユーザに出力しない処理を行ってもよい。具体的には、心理的安全性に関するグラフとして、心理的安全性を計測するために標準的に用いられている7つの項目をレーダーチャートで表示することがある。このレーダーチャートの表示を、心理的安全性総合スコアが閾値よりも低いことを条件として、表示しない(出力しない)処理を行ってもよい。レーダーチャートを表示しないことにより、ユーザが集団から離脱するなどの不利益が回避され得る。ここで、レーダーチャートを表示しないことに替えて、レーダーチャートの評価項目の表示を切り替えるなどレーダーチャートの態様を変化させてもよい。具体的には、心理的安全性総合スコアが閾値よりも高い場合には、レーダーチャートの各評価軸の数値を表示し、評価項目の評価を絶対値(絶対評価)で表示する。一方、心理的安全性総合スコアが閾値よりも低い場合には、レーダーチャートの各評価軸の数値を表示せず(消し)、レーダーチャートの評価項目同士の比較での評価(相対評価)を表示する処理を行ってもよい。このように相対評価を表示することにより、ユーザが所属する集団の改善すべき評価項目にユーザの意識が向かい、ユーザが集団から離脱することなどが回避される。
【0391】
なお、ここでは心理的安全性総合スコアについて説明したが、心理的安全性の各評価項目、ストローク、相互理解、相互援助など、ユーザ情報に関する他の処理においても、集団の評価が好ましくない場合に、評価の数値を出力しない、グラフを出力しない、あるいは出力するグラフの表示態様を変化させるなど、出力態様を切り替える処理を行ってもよい。
【0392】
(ラインケア)
職場関係コンテンツとして、上司であるユーザに対して、部下であるユーザのケアを行う所謂ラインケアを行うアドバイスを出力してもよい。例えば、チームの状態が悪い場合において、上司であるユーザに対して、部下とのミーティングを持ちストレスを軽減させるためにどうするかのアドバイスを出力してもよい。
【0393】
なお、一般的に、上司であるユーザの言動が、部下であるユーザの心理状態に与える影響は大きい。したがって、上司であるユーザのストロークの傾向を、部下であるユーザに通知することで、部下の心理的安全性などが向上することがある。そこで、本システムにおいて、上司であるユーザのストロークの傾向を取得し、部下であるユーザにその傾向を通知する態様としてもよい。例えば、上司であるユーザは、低気圧が近づくと否定ストロークが増える傾向があるとする。この場合において、天気予報などにより気圧の低下が予測されるなど所定条件を満たす場合に、部下であるユーザに対して、気圧の低下にともない上司であるユーザのストロークが悪化する可能性があることを通知してもよい。部下であるユーザがこの通知を受け取ることにより、実際に上司であるユーザのストロークが悪化した場合に感じる心理的負担が軽減され得る。なお、この通知は、部下であるユーザとともに、上司であるユーザにも出力されてもよい。また、ここでは上司であるユーザのストロークの傾向を取得し、部下である他のユーザに通知することを説明したが、これに限定されない。例えば、相互理解、相互援助など、他の処理においても、上司であるユーザの対象項目に関する傾向(情報)を取得し、部下に通知する処理を行ってもよい。
【0394】
さらに説明をすると、チーム全体のストレス状態が高い場合に、職場関係コンテンツとしてストレスを低減するためチーム全体のミーティングを実施するよう促してもよい。この職場関係コンテンツにおいては、ミーティングで話すべき話題(例えば、葛藤の整理)、ミーティングを行う時間帯やタイミング(例えば、業務終了後)、意義や狙い(例えば、ユーザの悩みを解消してから帰宅してもらう)などの情報が含まれてもよい。
【0395】
また、心理的安全性を計測するために標準的に用いられている7つの項目のうち、評価が低い項目について、その項目の評価を向上させるようアドバイスを出力してもよい。また、このアドバイスは、対象とするユーザが部下である場合には、対象とするユーザに加えて上司であるユーザに対して、アドバイスを出力してもよい。さらに説明をすると、部下であるユーザに対しては、対象とする項目の内容を向上するためのアドバイスを出力する。また、上司であるユーザに対しては、対象とする項目の内容を部下が向上させるための方策を部下と話し合うなど、部下の行動を促進するためのアドバイスを出力する。
【0396】
(インタラクションコンテンツ)
職場関係コンテンツとして、チームメンバーであるユーザ同士で、チャットや対面での会話などのコミュニケーション、言い替えるとインタラクションを促すコンテンツであるインタラクションコンテンツを含んでもよい。インタラクションコンテンツの内容は、ユーザ情報に基づいて変更してもよい。具体的には、ユーザ情報に含まれる性格傾向やユーザの好みに応じて、コンテンツにおいて実行が促されるインタラクションの種別、回数、頻度など、インタラクションの態様が変更されてもよい。ここで、インタラクションは、チームの実態に基づいて態様を変更してもよい。具体的には、普段の雑談が少ないチームには、雑談の意義や注意事項を上司から部下に対して行うオリエンテーションという形で、インタラクションを実施してもよい。
【0397】
インタラクションの種別としては、チャットなど情報処理システム1内において実行されるインタラクションと、対面など情報処理システム1外において実行されるインタラクションとがある。そして、例えば、チャットを促すインタラクションにおいては、インタラクションの態様を切り替える項目として、チャットを行う日時を指定するか否か、チャットにおける話題の提示の有無とを切り替えてもよい。なお、例えばチームの実態によっては、上司に対して、チームメンバーが会話を行う時間を1週間で10分程度設けて、インタラクションを行うことを促してもよい。具体的には、今まで雑談を行っていなかったチームや、リモートワーク中であるチームに、上記の提示を行ってもよい。また、インタラクションは、3名以上で行ってもよい。例えば、会話を行わせたい2人のユーザの関係性が悪いと判定された場合に、この2人のユーザ各々と関係性の良い他のメンバーを加えて、会話を行うよう促してもよい。関係性が良い他のメンバーを加えることにより、関係性が悪いユーザ同士のインタラクションが促進され得る。
【0398】
インタラクションコンテンツの提示は、所定期間におけるユーザ同士の会話の実態情報に基づいて切り替えてもよい。この実態情報としては、例えば、ユーザに対して「あなたはチームの他の各メンバーと1週間の間で何分くらい業務に関する以外の話をしますか?」という質問をし、その回答から取得してもよい。なお、この質問は、例えば1カ月に1度など定期的に行うことにより、ユーザの実態情報がより精度よく取得できる。
【0399】
ここで、例えば実体情報において、会話が少ないユーザに対して、インタラクションコンテンツが優先的に出力される。そして、インタラクションコンテンツにおいては、会話がない2人のユーザに対して、例えば1週間に1度など所定の頻度で会話をすることが促される。
【0400】
さらに、上記の実施の形態において説明した、ストローク、相互理解、相互援助のアドバイスで所定期間内に話しかけていたなど、所定の条件を満たす場合は、インタラクションの提示を行わなくてもよい。ここで、具体例として、ユーザAとの会話実体がないユーザBについて説明をする。この例において、ユーザBに対して、ユーザAとの会話を促す相互理解コンテンツが出力され、ユーザBがユーザAと話を行っていたものとする。この場合においては、相互理解のアドバイスを出力したタイミングから所定期間内(例えば、1週間以内や4月第1週目)は、ユーザBと話すことを促すインタラクションコンテンツを提示しない処理を行ってもよい。
【0401】
また、チャットにおいて提示される話題の種類は特に限定されない。話題の種類としては、例えば仕事に関する話題(例えば、過去の職歴、今後のキャリアパス)やプライベートに関する話題(例えば、趣味、家族、休日の過ごし方)が含まれる。ここで、話題の決定方法としては、支援実行部561がユーザ情報(例えば、趣味、性格傾向)に基づいて決定してもよいし、ユーザ同士で決定してもよい。また、ユーザ同士に話題を決定させる態様においても、話題の大枠は支援実行部561が決定し、詳細をユーザ同士が決定してもよい。なお、システムが話題の推奨を行ってもよい。具体的には、相互理解が悪いユーザ同士の場合、天気の話、好きな食べ物の話など所謂当たり障りのない話題について会話を行ってもらい、関係性を深めさせてもよい。所謂当たり障りのない話題を提示することにより、例えばよく知らない人と話すことに心理的な抵抗が高い話題(例えば価値観)を提示することと比較して、ユーザ同士の会話がより促進され得る。さらに説明をすると、ユーザに対して無理のあるアドバイスを行うことを防ぐことができる。
【0402】
なお、オフィスなどの職場において、ユーザAがユーザBの近くを通りがかるなど、所定の条件を満たす場合に、インタラクションコンテンツを出力してもよい。ここで、例えば端末100および端末200がスマートフォンである場合を例に説明をする。この例においては、端末100および端末200が、近距離無線通信を用いることで、ユーザ同士が物理的に接近していることが感知可能である。そして、ユーザ同士が物理的に接近したことを契機として、インタラクションコンテンツを出力してもよい。このインタラクションコンテンツにおいては、ユーザ同士に会話することのみを促してもよいし、会話することを促すとともに会話の話題を提示してもよい。
【0403】
<ストローク介入処理>
図29は、支援実行部561によって実行されるストローク介入処理を示すフローチャートである。
次に、ストローク介入処理について説明をする。
家族や職場のメンバーであるユーザの精神状態が悪化すると、他のユーザとの関係性に影響が出る場合がある。このような精神状態が悪化したユーザのストロークを支援実行部561が矯正をする処理を行ってもよい。すなわち、支援実行部561によってユーザのストロークに介入するストローク介入処理を行ってもよい。
【0404】
図29に示すように、まず、支援実行部561は、対象とするチームを構成するチームメンバーのユーザ情報として各ユーザの精神状態を示す精神状態情報を所得する(S2901)。そして、支援実行部561は、取得した精神状態情報に基づいて、精神状態が悪化している特定精神状態のユーザが存在するかを判断する(S2902)。
【0405】
特定精神状態のユーザが存在する場合(S2902でYES)、支援実行部561は、特定精神状態のユーザのストローク情報を取得する(S2903)。そして、支援実行部561は、取得したストローク情報に基づいて、特定精神状態のユーザが無条件否定ストロークを行っているかを判断する(S2904)。そして、無条件否定ストロークを行っている場合(S2904でYES)、支援実行部561は、特定精神状態のユーザに対して無条件否定ストロークをやめることを促すコンテンツを出力する(S2905)。
【0406】
このように、ユーザの精神状態が特定精神状態である、すなわち所定条件を満たす場合、そのユーザのストロークを示す情報を取得し、ユーザのストロークを変更するアドバイスを出力する。このことにより、特定精神状態のユーザと他のユーザとの関係性が悪化することが予防され得る。なお、このアドバイスの出力態様は、特定精神状態のユーザの性格傾向や精神状態が悪化している程度に応じて切り替えてもよい。例えば、ユーザの性格傾向が内向的である場合、アドバイスを出力することで精神状態がさらに悪化することがある。したがって、この場合はアドバイスを出力しない処理を行ってもよい。また、ユーザの精神状態が所定の基準よりも悪い場合、精神状態がさらに悪化することがある。したがって、この場合もアドバイスを出力しない処理を行ってもよい。
【0407】
ここで、上記の説明においては、特定精神状態のユーザに対してコンテンツを出力することを説明したが、これに限定されない。例えば、特定精神状態のユーザに替えて、あるいは特定精神状態のユーザとともに、他のユーザに対して、チーム内に不調なチームメンバーがいるから、チームメンバーの言動がもし好ましくない場合でも受け入れるよう促すコンテンツ(受容促進コンテンツ)を出力してもよい。なお、この受容促進コンテンツにおいては、チーム内に存在する特定精神状態のユーザが1人である場合にも、「チーム内に不調なチームメンバーが複数いる」ものとして需要促進コンテンツを出力してもよい。複数のチームメンバーが不調であるという内容とすることで、特定精神状態のユーザが特定されることが回避され得る。
【0408】
<管理装置500のハードウェア構成>
図30は、管理装置500のハードウェア構成例を示した図である。
図30に示すように、管理装置500は、CPU501と、RAM(Random Access Memory)502と、ROM(Read Only Memory)503と、HDD(Hard Disk Drive)504と、通信I/F505とを備える。
【0409】
CPU501は、ROM503等に記憶された各種プログラムをRAM502にロードして実行することにより、管理装置500の上記各機能を実現する。
RAM502は、CPU501の作業用メモリ等として用いられるメモリである。
ROM503は、CPU501が実行する各種プログラム等を記憶するメモリである。
HDD504は、ユーザ情報等を記憶する例えば磁気ディスク装置である。
通信I/F505は、ネットワークNW(
図1参照)を介して他の装置との間で各種情報の送受信を行う。
【0410】
ここで、CPU501によって実行されるプログラムは、半導体メモリ等のコンピュータが読取可能な記録媒体に記憶した状態で、管理装置500へ提供し得る。また、CPU501によって実行されるプログラムは、管理装置500を介して端末100等へダウンロードしてもよい。例えば、管理装置500の上記各機能を実現するプログラムを、アプリケーションソフトウェアとして端末100等へダウンロードしてもよい。そして、ユーザは、端末100等にて、ダウンロードしたアプリケーションソフトウェアをインストールして、上記サービスの利用を開始する。
【0411】
<変形例>
上記の説明においては、ユーザが使いづらさを感じることを抑制するため、管理装置500が支援情報を選択して出力する例として、表象関係処理を根本的実体処理よりも優先すること、言い替えると、処理の種別によって支援情報の選択をすることを説明した。しかしながら、支援情報を選択する態様はこれに限定されない。例えば、各支援情報に予め優先順位を付与し、優先順位が上位の支援情報から順に出力する態様であってもよい。また、表象関係および根本的実体のいずれかにおいて緊急で対応すべきことがある場合、緊急度が高いものの優先度を高めることで、支援情報を選択して出力してもよい。
【0412】
また、チームを構成するメンバー(ユーザ)において、優先度を設定してもよい。例えば、メンバーごとに、他のメンバーとの関係性の評価をスコア化し、スコアが低いメンバーの優先度を高く設定する。そして、優先度に従って、関係性支援を実行するようにしてもよい。さらに説明をすると、スコアが低いメンバーに関する支援情報が複数ある場合には、優先順位が上位の支援情報から順に重点的に出力する態様であってもよい。このようにチーム内におけるユーザ同士の関係性のいずれに対する処理を行うかを、優先度を付与して実行することで、関係性支援を効率的に実行し得る。
【0413】
また、チームに新たなメンバーが追加される場合に、新メンバーの優先度を高くし、優先的に関係性支援を実行するようにしてもよい。さらに説明をすると、新メンバーの他のメンバーとの関係性の評価と、他のメンバーの評価との差が所定値以下となるまで、あるいは新メンバーが追加されてから所定期間が経過するまで、新メンバーの関係性支援を重点的に出力する態様であってもよい。
【0414】
また、上記の説明においては、関係性支援処理が、相互理解処理、ストローク処理、潜在的相性処理および相互援助処理を含むことを説明したが、これに限定されない。例えば、関係性支援処理は、相互理解処理、ストローク処理、潜在的相性処理および相互援助処理の一部のみを実行するものであってもよい。
【0415】
また、関係性支援処理は相互理解処理、ストローク処理、潜在的相性処理および相互援助処理のうち、優先順位をつけて処理する態様であってもよい。例えば、いずれかの処理を実行する条件として、他の処理が実行されたことを条件としてもよい。
【0416】
さらに説明をすると、例えば相互援助処理は、相互理解処理、ストローク処理および潜在的相性処理の一部または全部が実行されたことを条件としてもよい。例えば、相互理解処理、ストローク処理および潜在的相性処理が実行され、相互理解、ストローク、潜在的相性への対処が一定以上に改善されている状態である場合に、相互援助処理が実行されてもよい。
【0417】
付言すると、ユーザ同士の関係性が良好でないと、ユーザが相互援助を実行することが困難となることがある。したがって、相互理解、ストローク、潜在的相性への対処が一定以上に改善されていることを条件とすることで、相互援助処理がより効率よく実行され得る。なお、相互理解処理、ストローク処理および潜在的相性の良好度などの評価の合計値や平均値などを、相互援助処理を実行する条件としてもよい。また、これらの合計値や平均値などの評価が良好になるに従い、相互援助処理を実行する頻度を高めてもよい。
【0418】
上記の説明においては、潜在的相性が良好でない場合、総合的に相性が悪くとも関係性がよくなる処理を実行することを説明した。ここで、潜在的相性が良好でない場合、ユーザ同士で共通点を作り出すような支援を実行してもよい。具体的には、潜在的相性管理部557が、同一のテレビ番組を見るなど、共通の行動をとることを促す情報を、各ユーザに対して出力してもよい。共通の行動を実行する、すなわち共通の経験をもつことにより、ユーザ同士の関係性が向上し得る。ここで、共通の行動を実行することを促す情報を受けた全ユーザが、話し合いをすることで1つの行動を決定し、決定した行動を実行する態様としてもよい。この共通の行動を決定あるいは実行する際、各ユーザの価値観の違いなどにより、各ユーザの意見が割れること、すなわち意見が一致しないこともあり得る。この意見が一致しないという経験を通して、各ユーザが互いの相違点を受け入れられるようになり、ユーザ同士の関係性が向上し得る。
【0419】
また、上記の説明においては、他者受容度に応じて、相違点処理などを行うことを説明した。ここで、ユーザ同士の潜在的相性が良好でなく、かつ各ユーザの他者受容度が低い場合も想定され得る。この場合、関係性を向上させることが困難となり得る。そこで、各ユーザの他者受容度が低い場合、他者受容度を増加させるようなワークをユーザに実行させる支援を行ってもよい。なお、他者受容度を増加させるようなワークとしては、対人関係療法、アサーティブのワーク、講習を受けるよう促すことなどが含まれる。
【0420】
ここで、他者受容度に応じて、支援情報を出力する頻度(有無)や支援情報の内容を変更してもよい。例えば、他者受容度が相対的に高いユーザに対しては、他者受容度が低いユーザと比較して、支援情報を出力する頻度が高くなるようにしてもよい。また、他者受容度が高いユーザに対しては、他者受容度が低いユーザと比較して、支援情報に含まれる情報の量(例えば相違点の項目数)を多くするようにしてもよい。
【0421】
また、相違点の種別をポジティブな相違点とネガティブな相違点に分類するなど、相違点の属性ごとに所謂タグ付けするなど予め区分けし、他者受容度に応じてユーザに通知する相違点の属性を切り替えてもよい。例えば、他者受容度が高いユーザに対しては、他者受容度が低いユーザと比較して、支援情報に含まれるネガティブな相違点を多くするようにしてもよい。
【0422】
また、上記の説明においては、ユーザ情報に含まれる忙しさに応じて(
図6のS603参照)、支援情報の出力を切り替えたがこれに限定されない。例えば、精神状態や生理情報に基づいて、支援情報を出力するか否かを切り替えたり、支援情報の出力内容を切り替えたりしてもよい。例えば、対象とするユーザの精神状態の数値が低い場合には、支援情報の出力を制限するようにしてもよい。同様に、対象とするユーザのストレス値が高い場合には、支援情報の出力を制限するようにしてもよい。
【0423】
上記の説明の表象関係処理においては、特定環境であるか否かに応じて、ユーザから受け付ける情報を切り替えることを説明した(
図7のS702参照)が、これに限定されない。例えば、チームにおけるユーザ同士の関係性に応じて、受け付ける情報を切り替えてもよい。例えば、チームにおける信頼関係、相互理解度、あるいは心理的安全性などに基づき、特定主観情報を受け付けるか否かを切り替えてもよい。
【0424】
さらに説明をすると、例えばチームにおける心理的安全性の評価値を取得し、この評価値に基づき心理的安全性が高いと判断された場合は、侵襲性質問をする態様でもよい。心理的安全性が高い場合は、心理的安全性が低い場合と比較して、侵襲性質問をすることにともなってユーザ同士の関係性が悪化する可能性が低いためである。一方、心理的安全性が低い場合は、対象とするユーザに侵襲性質問あるいは非侵襲性質問をすることに替えて、対象とするユーザ以外の第3者から情報を受け付ける態様としてもよい。
【0425】
なお、上記の説明の表象関係処理においては、特定環境でない場合、ユーザから基本主観情報を取得すること、あるいは第3者から客観情報を受け付けることを説明した。ここで、例えばチームにおける心理的安全性が高い場合、基本主観情報および客観情報に加えて、特定主観情報を受け付ける態様でもよい。また、心理的安全性が低い場合、基本主観情報に替えて、第3者情報のみを受け付ける態様でもよい。
【0426】
ここで、対象とするユーザと他のユーザとの表象関係に関する情報を取得する場合において、対象とするユーザから取得する情報(対象ユーザの基本主観情報および特定主観情報)と、他のユーザから取得する情報(他のユーザの基本主観情報および特定主観情報)とが一致しないことがある。すなわち、対象とするユーザと他のユーザとで表象関係についての評価が異なる場合がある。この相互の評価が大きく異なる場合には、一方が他方にハラスメント等を行っていることや、一方が事実と異なる嘘の評価をしていることがある。そこで、対象とするユーザと他のユーザとで表象関係についての評価の差が閾値よりも大きいなど所定の場合に、評価の差を低減する支援情報を出力する態様でもよい。また、対象とするユーザと他のユーザとで表象関係についての評価の差が閾値よりも大きいなど所定の場合に、対象とするユーザの上司や、対象とするユーザが所属する会社の代表などに通知する態様であってもよい。
【0427】
また、特定環境であるかに応じて、わだかまりがあるかをユーザに質問をするか否かを切り替えてもよい。すなわち、特定環境であるか否かを判断し、特定環境である場合にわだかまりの有無を質問する態様としてもよい。また、特定環境であることに替えて、あるいは特定環境であることに加えて、心理的安全性が高いことを条件として、わだかまりの有無を質問する態様としてもよい。
【0428】
また、上記の説明においては、相違点処理において、対象とするユーザの他者受容度が低い場合に、相違点処理を終了することを説明した。このように他者受容度に応じた処理は、関係性支援における他の処理において実行してもよい。例えば、ストローク処理などにおいて、対象とするユーザの他者受容度が低い場合に、ストローク処理を終了させる処理を行ってもよい。なお、他者受容度が所定の数値(閾値)よりも低い場合には、対象とするユーザの上司や、対象とするユーザが所属する会社の代表、ユーザが所属する会社の産業医、保健士、カウンセラー、外来担当医、EAPコンサルタント、キャリアカウンセラー、ユーザの配偶者など、チームメンバー以外に通知がなされる態様であってもよい。
【0429】
また、上記の説明においては、ストローク処理について説明をしたが、例えばストロークの種別ごとに異なる処理を実行してもよい。さらに説明をすると、無条件肯定ストロークに関して、以下のような処理を実行してもよい。すなわち、対象とするユーザの精神状態が良好でない場合や、心理的な余裕がない場合などに、対象とするユーザに出力される無条件肯定ストロークを増やす指示を低減する。このことにより、対象とするユーザが心理的な負荷を感じながら無条件肯定ストロークを実行することが抑制される。また、他のユーザに対しては、対象とするユーザに精神的な余裕がないため、無条件肯定ストロークを行えないのは仕方がないと提示する。このことにより、無条件肯定ストロークが実行されないことで対象とするユーザの関係性が悪化することが抑制される。
【0430】
同様に、ユーザの思考傾向に応じて、無条件肯定ストロークに関する情報の出力を変化させてもよい。例えば、性格傾向が内向性であるユーザに対しては、無条件肯定ストロークを増やす指示を低減する。また、この例における他のユーザに対しては、対象とするユーザの性格傾向が内向的であるため、無条件肯定ストロークを行えないのは仕方がないと提示する。また、他の例としては、自己肯定感が低いユーザに対して、無条件肯定ストロークを増やす指示を低減する。この他の例における他のユーザに対しては、対象とするユーザの自己肯定感が低いため、無条件肯定ストロークを行えないのは仕方がないと提示するとともに、対象とするユーザに対する肯定ストロークを増やすよう提示する。
【0431】
また、ユーザの思考傾向に応じて、無条件否定ストロークに関する情報の出力を変化させてもよい。例えば、性格傾向において攻撃性が相対的に高いユーザに対して、無条件否定ストロークを行わないようにアドバイスする場合において、このアドバイスを提示する回数を、攻撃性が相対的に低いユーザと比較して増加させてもよい。
【0432】
また、ユーザの思考傾向に応じて、条件付き肯定ストロークや条件付き否定ストロークに関する情報の出力を変化させてもよい。例えば、性格傾向が内向性であるユーザに対して、条件付き肯定ストロークを増やすようアドバイスする場合において、このアドバイスを提示する回数を、性格傾向が外向性であるユーザと比較して低減させてもよい。
【0433】
ここで、各ユーザの性格傾向に応じて、受ける否定ストロークの回数や頻度などの限界量を推定してもよい。そして、推定された限界量(閾値)を超えないように、否定ストロークを行うよう促す態様でもよい。例えば、回数の閾値に達した場合には、それ以降の否定ストロークをしないよう促すアドバイスを出力してもよい。
【0434】
ここで、他のユーザから送られてきたメールやメッセージに対して返信をしない行動は、メールやメッセージを送信した他のユーザを無視する行為、すなわちノンストロークとして捉えることができる。一方で、性格傾向や忙しさなどの要因により、メールやメッセージの返信をしないことが多いユーザもいる。そこで相互理解処理において、メールやメッセージに対して返信する割合(返信率)に関する情報を所得してもよい。そして、メールやメッセージの返信をしないことが多いユーザがいる場合に、そのユーザは返信率が低いことを他のユーザに対して通知してもよい。この通知により、ユーザ同士の関係性が悪化することが抑制され得る。
【0435】
また、支援情報を提示するのは、支援が必要である、あるいは支援が必要と推定される当該ユーザに限らない。支援情報を提示する対象は、当該ユーザ以外の他のユーザでもよい。例えば、内向性が高いユーザAが、周囲に誤解されるのを防ぐために、ユーザA以外のユーザBに対してアドバイスを出力する態様でもよい。このユーザBに対して出力されるアドバイスは、ユーザAは内向性が高いため、ストロークをあまり行わないことがあるという情報を含むものでもよい。
【0436】
また、チーム全体の忙しさ、ストレス、精神状態に基づいて無条件肯定ストロークに関する情報の出力を変化させてもよい。例えば、ストレスに応じてチームにおける無条件肯定ストロークがどのように変化するかの情報を予め取得する。そして、取得した情報に基づいて、チーム全体が忙しい場合や、ストレスが溜まる場合に、無条件肯定ストロークが低減しても、無条件肯定ストロークが行えないのは忙しさやストレスが原因であることを提示してもよい。ここで、他のメンバーに対して提示することを明示する態様でもよい。さらに説明をすると、対象とするユーザには、意識して無条件肯定ストロークを増やし、無条件否定をやめましょうという提示をしてもよい。また、他のユーザに対して、対象とするユーザのストレスが上がっているから、対象とするユーザの言動を受け入れてあげるようにしましょうという提示をしてもよい。これらのことにより、無条件肯定ストロークが行われないことが、ノンストロークだと誤解されることを抑制し得る。
【0437】
ここで、条件付き肯定ストローク特有の処理を実行してもよい。例えば、無条件肯定ストロークに比べ、条件付き肯定ストロークが多くなりすぎないように制御してもよい。これは、条件付き肯定ストロークばかりを受けることで、対象とするユーザが自身の存在が認められていないと感じ、結果として自己肯定感が下がる可能性があるためである。そこで、例えば、無条件肯定ストロークが、条件付き肯定ストロークよりも多くなるように制御してもよい。
【0438】
また、否定ストローク特有の処理を実行してもよい。例えば、無条件否定ストロークを受けることが多いと対象とするユーザが感じた場合、無条件否定ストロークを実行したユーザ(実行ユーザ)からその意図を示す情報を取得する。すなわち、無条件否定ストロークと受け取られたストロークが、無条件否定ストロークを意図して実行されたのか、条件付き否定ストロークを意図して実行されたのかを示す情報を、実行ユーザから取得する。そして、無条件否定ストロークを意図して実行されていた場合は、実行ユーザに無条件否定ストロークをなくすことを促す情報を出力する。また、条件付き否定ストロークを意図して実行されていた場合は、実行ユーザに、条件付き否定ストロークを行う際は、その条件を明確に伝えることを促す情報を出力する。このことにより、条件付き否定ストロークを意図していたものが、無条件否定ストロークと誤解されることが抑制される。なお、上記条件を明確に伝えることを促す情報は、実行ユーザの性格傾向などに応じて、情報量や頻度を変化させてもよい。また、上記条件を明確に伝えることを促す情報とともに、あるいはこの情報に替えて、無条件肯定ストロークを実行することを促す情報を出力してもよい。また、上記条件を明確に伝えることを促す情報とともに、あるいはこの情報に替えて、否定ストロークを減少させることを促す情報を出力してもよい。例えば、否定ストロークを減少させるため、ストレス解消法を実行することを促してもよい。
【0439】
また、無条件否定ストロークおよびノンストロークにおいて特有の処理を実行してもよい。上記のように、無条件否定ストロークおよびノンストロークは、実行回数を低減することが好ましく、実行回数がゼロとなることが理想である。そこで、無条件否定ストロークおよびノンストロークをやめるよう、ユーザに出力し、所定期間が経過しても改善されない場合は、対象とするユーザの上司や、対象とするユーザが所属する会社の代表、人事部に通知することや、これらの担当者からの指示を受け付けるようにしてもよい。また、無条件否定ストロークおよびノンストロークの状況が改善されない場合に、上記わだかまり処理を実行する態様でもよい。なお、無条件否定ストロークを減少させることを促す情報を出力してもよい。例えば、無条件否定ストロークを減少させるため、そのストロークを行う理由、すなわちストロークの条件を明確にして、条件付き否定ストロークにするよう促してもよい。また、ノンストロークを減少させることを促す情報を出力してもよい。例えば、ノンストロークを減少させるため、無条件肯定ストロークを行うよう促してもよい。
【0440】
また、思考・価値観は、上記のように思考・価値観に関するユーザの入力を受け付けることに加えて、あるいは替えて、ユーザの属性やユーザの行動履歴などから推測する態様であってもよい。例えば、ユーザの年齢に基づいてユーザの思考・価値観を推定してもよい。さらに説明をすると、ユーザの年齢から精神成熟度の度合いを判断し、ユーザの思考・価値観を推定してもよい。例えば10代~20代の年齢は青年期・成人期前期であることから、ユーザにとっては人間関係の構築が重要であり、例えば恋愛が重要であると推定してもよい。また、例えば50代~60代の年齢は熟年時期であることから、ユーザにとって健康が重要であると推定してもよい。また、SNS(Social Networking Service)におけるメッセージ送信機能において、「好き」、「告白」、「別れ」、「浮気」など恋愛に関する文言の出現頻度が高い場合に、恋愛が重要であると推定してもよい。
【0441】
また、個人の実態に基づいて、アドバイスの提示内容を変更してもよい。
例えば、ユーザのコミュニケーションのスタイル(態様)に基づいて、提示内容を変更する。具体的には、まず、事前の質問によって、ユーザのコミュニケーションのスタイルを取得する。そして、インタラクションや、相互理解の処理において他のユーザに話しかけるように促す際に、ユーザのコミュニケーションスタイルに応じた提示をする。具体的には、以下の提示を行う。例えば、自己主張が強いユーザには、相手にも話をしてもらうために自己主張を控えるように促す。また、相手の意見を尊重しがちなユーザには、自身のことを分かってもらうために、自己主張を行うように促す。具体的には、「あなたは、相手の意見を尊重するのが得意です。会話の相手にもっと会話を楽しんでもらうために、余裕があれば、自分の意見を主張してみるとよいかもしれません。また、「それいいでいいですね。私は、こう思います。」と相手の話に賛同してからあなたの話をすると効果的です。」というメッセージを出力してもよい。
【0442】
また、会話をする2人のコミュニケーションのスタイルに基づいて、アドバイス内容を変更しても良い。具体的には、2人のコミュニケーションスタイルの組み合わせに応じて、アドバイスの内容が切り替えられる。例えば、会話をする2人のユーザのうち、第1のユーザが自分の意見を尊重するタイプであり、第2のユーザが自分の意見を尊重しながら適切に自己主張をすることができるタイプの組み合わせの場合、第2のユーザに「相手は、自分の意見を主張するのがあまり得意ではないので、意見を引き出してあげるといいかもしれません」と提示してもよい。
【0443】
また、対象とするユーザに対して過去に提示したアドバイスの内容を、新たなアドバイス提示を行う前に提示してもよい。その際、過去のアドバイスによって生じたユーザの変化を提示してもよい。このことによって、ユーザがシステムの効果を実感し、ユーザが新たなアドバイスに従う可能性が高まる。
【0444】
また、チームの実態に応じて、コンテンツの提示の内容を変更してもよい。例えば、チームメンバー同士の間に競争があることを条件として、以下のような態様でコンテンツが提示されてもよい。例えば、(1)他のユーザに話しかけるよう促す際に、「余裕があれば、良きライバルとして接するといいかもしれません」という情報を追加提示してもよい。また、(2)他のチームメンバーの尊敬点や良い点を入力させ、対象とするメンバーに提示する頻度を多くしてもよい。また、(3)ノンストロークの状態取得、改善アドバイスの提示回数を多くしてもよい。また、(4)条件付き肯定ストロークである「他のメンバーのいいところを伝える」の提示回数を多くしてもよい。また、上記(2)乃至(4)を行う意義を、競争があるチーム特有のものとして提示してもよい。上記(2)乃至(4)により、チーム内に競争がある状態ながらメンバー同士が尊敬し合う状態を形成することができる。
【0445】
また、チームの実態に応じて、コンテンツの提示の内容を変更する他の例としては、看護師や目標値の高い営業などのように、業務に伴う蓄積ストレスが高く、各ユーザが自身の発言に気を使うことができていない場合に、コンテンツの提示の内容を変更してもよい。例えば、(1)他のチームメンバーの良いところや尊敬点の取得と、対象とするメンバーへの提示の提示回数を増やしてもよい。また、(2)無条件否定ストロークを行っていないかの状態取得を定期的に実施してもよい。なお、無条件否定ストロークを行っていた場合、余裕があれば、無条件否定ストロークとなる言動を控えるように促す提示を行う。また、無条件否定ストロークを行っていた場合、事後対処を促す提示を行う。また、上記(1)により、厳しい言葉によって揺らぎがちなメンバーの自己肯定感を維持することが可能になる。また、上記(2)により、他のメンバーを傷つける関わりを未然に防ぐことが可能になる。
【0446】
ここで、チームの実態に応じて、コンテンツの提示の内容を変更する他の例としては、怒っているチームメンバーがいることを検知した場合に、コンテンツの提示の内容を変更してもよい。例えば、対象とするユーザの発言などに基づいて怒っているユーザがいることを検知し、怒っているユーザに対して提示するコンテンツを変更してもよい。ここで、怒っているユーザの他の特定方法としては、直接ユーザに質問をする直接取得と、忙しさ情報、ストレス値、あるいは性格傾向などのユーザ情報から推定する間接取得とがある。また、提示コンテンツの変更態様としては、他のメンバーと話す際に他のメンバーに対して気遣いをするよう促すコンテンツの回数を多くしてもよい。また、怒っているユーザに対して、他のメンバーへの感謝点、尊敬点を伝えさせるコンテンツの提示回数を多くしてもよい。また、対象とするユーザのストレス値が高く怒っている状態と推定される場合に、「口調に注意しましょう」というアドバイスの提示を行ってもよい。
【0447】
ここで、チームの実態に応じて、コンテンツの提示の内容を変更する他の例としては、チームメンバーの性格傾向に応じて、コンテンツの提示の内容を変更してもよい。例えば、チームメンバーの他者受容度など、ユーザの性格傾向を示す数値の代表値(例えば、平均値)に応じて、コンテンツの提示の内容を変更してもよい。具体的には、チームを構成するチームメンバーの他者受容度の平均値が閾値よりも低い場合に、心理的安全性に関するコンテンツを多く出力するようにしてもよい。
【0448】
ここで、チームにおける関係性の良好さは、チームアセットとして捉えることができる。このチームアセットは、例えばチームワークやチーム力などと言い替えることができる。
【0449】
ここで、チームの実態に応じて、コンテンツの提示の内容を変更する他の例としては、チームにおける関係性(ユーザ同士の関係性)が良好であるかに応じて、コンテンツの提示の内容を変更してもよい。例えば、チームメンバーの心理的安全性が所定値よりも高い場合には、心理的安全性が所定値よりも低い、すなわち関係性が良好でない場合と比較して、ユーザが実行することに心理的に抵抗があるアドバイスをより多く出力してもよい。具体的には、目を見て挨拶をするというアドバイスの出力頻度を低め、1対1で1時間話すことを促すアドバイスの出力頻度を高めてもよい。
【0450】
また、ユーザ同士の関係性が良好である場合には、関係性が良好でない場合には出力しないアドバイスを出力してもよい。例えば、ユーザ同士の相互理解が所定値以上である場合には、条件付否定ストロークや無条件否定ストロークを許容するようなアドバイスを出力してもよい。具体的には、「言葉遣いを気にせずに、感じていることをそのまま相手に伝えてみましょう」などのアドバイスを出力してもよい。なお、ユーザ同士の相互理解が所定値以上であることに加えて、他のユーザの性格傾向における神経症的傾向が低いなど、ユーザの性格傾向を条件としてもよい。
【0451】
また、ユーザ同士の関係性が良好である場合には、関係性が良好でない場合には出力しない条件で、アドバイスを出力してもよい。例えば、関係性が良好でない場合にはユーザが忙しい場合にアドバイスを出力しない(
図6のS603参照)のに対して、関係性が良好である場合にはユーザが忙しい場合であってもアドバイスを出力してもよい。
【0452】
また、ユーザ同士の関係が良好である場合には、ゲームをするや、好きなことを自由にしゃべるなど、所謂娯楽のアドバイスを出力してもよい。さらに、ユーザ同士の関係性が良好である場合には、アドバイスの出力頻度を低減する態様や、アドバイスを出力しない態様でもよい。
【0453】
ここで、チームにおけるストロークの状態などチームの実態を示す画像を、チームメンバー、チームリーダ、チームが所属する会社の取締役などの管理者、あるいは管理装置500(
図1参照)の管理者などの一部または全部に対して表示する態様でもよい。チームの実態が画像として表示されることにより、チームの実態の把握が容易となり、チームメンバーの支援がより確実に実行され得る。また、チームの実態を示す画像の背景など画像の色彩を、チームの実態に応じて切り替えてもよい。例えば、相互理解が不十分なチームの実態を示す場合には青などの寒色系の色彩を主として採用し、相互理解が十分なチームの実態を示す場合には赤などの暖色系の色彩を主として採用してもよい。このように画像の色彩を切り替えることにより、チームの実態の把握が容易となる。
【0454】
本システムが支援(介入)したことによる効果は、Work place outcome Suite(WOS)、Work Limitations Questionnaire(WLQ)、プレゼンティーズムなど、周知の従業員支援プログラムの効果測定手法を用いて評価してもよい。この効果の評価は、例えばアドバイスを提示したことによる変化に基づくとよい。
【0455】
ここで、会社(職場)に行くことが楽しくないというユーザがチームメンバーにいた場合、そのユーザに対して、例えば会社に行くのが楽しくなるためにどのチームメンバーとの人間関係を改善させたらよいと考えるかという質問(提示)をし、その回答を得てもよい。そして、その回答で特定されたチームメンバーとの関係性が良好となるよう、インタラクションなどの頻度が高くなるようにしてもよい。
【0456】
また、会社に行くのが楽しくないユーザに対して、どのようにしたら会社に行くことが楽しくなるのか質問をし、その回答を得てもよい。例えば、他のユーザとの会話を増やしたいなどを選択した場合「どのチームメンバーと話をしたいですか?」と質問し、質問の回答内容に該当するメンバーとインタラクションを行わせてもよい。
【0457】
また、会社に行くことが楽しくないユーザに対して、なぜ会社に行くのが楽しくないのか質問をし、その回答を得てもよい。例えば、ユーザからの回答が、チームメンバー同士が異質すぎてつまらないという場合、通常業務を共同で行うチーム以外のユーザ、すなわちチームの範囲を広く捉えて、会社の中における他のチームの同質の人とインタラクションを促してもよい。また、ユーザからの回答が、チームメンバー同士が同質すぎてつまらないという場合、グループを広く捉えて、会社の中の他のチームの異質の人とインタラクションを促してもよい。なお、同質か異質かの判定は、趣味、関係性、性格、価値観(キャリアアンカー)などユーザ情報に基づいて判定されてもよい。
【0458】
また、上記の各種コンテンツを出力する際に、そのコンテンツがユーザに対して出力される理由(趣旨)をコンテンツとともに出力してもよい。例えば、対象とするユーザの他者受容度が高くない場合において、他者受容度を高めるコンテンツとともに理由を出力してもよい。例えば「あなたは、今、他人の価値観を受け入れることが少し難しい状況のようなので、このようなアドバイスをしています。」という文字列を含む画像をコンテンツとともに出力してもよい。また、例えばユーザ同士の相互理解度が低い場合に、相互理解度を高めるコンテンツとともに、以下のような理由を出力してもよい。例えば、「もう少しお互いをよく知ることが有効と判断されたので、このアドバイスを出しています。」という文字列を含む画像をコンテンツとともに出力してもよい。
【0459】
上記の説明においては、
図4および
図6を参照しながら、支援処理について説明をした。ここで、チームに所属する各チームメンバーを支援する場合に、ユーザごとに本システムの利用状況が異なることがある。すなわち、他のチームメンバーと比較して、一部のチームメンバーの利用頻度が低いことや、一部のチームメンバーによって入力される情報が不十分となることがある。そして、例えば支援情報を出力するために、他のチームメンバーによる入力情報が必要な場合、利用状況が不十分なチームメンバーがいると、それ以外のチームメンバーの支援処理が実行できない可能性がある。そこで、チームに所属するチームメンバーのうちの所定の割合(人数)から入力情報を取得することを条件として支援処理を進めてもよい。例えば、心理的安全性について、チームに所属するチームメンバーのうち、7割のユーザが入力することを条件として、次の支援情報を出力する処理を実行するようにしてもよい。なお、既に入力したユーザに対しては、次の支援情報を出力する処理が実行されるまでは、相互理解やストロークなどの他のアドバイスを出力する態様としてもよい。また、ここでは心理的安全性の入力を例に説明したが、ストロークなど他の事項に関する入力についても同様である。また、チームに所属するチームメンバーのうち入力したユーザの割合(人数)に応じて、支援情報を切り替えてもよい。例えば、心理的安全性に関して入力したユーザの割合が低い場合に、心理的安全性に関するアドバイスに替えて、相互理解に関するアドバイスなど他のアドバイスを出力してもよい。
【0460】
また、ユーザが情報を入力した量、ユーザがアドバイスを確認した回数、ユーザがアクションプランを実行した回数など、ユーザの使用態様に応じて、支援情報を切り替えてもよい。例えば、ユーザがアドバイスを確認した回数が所定値となることを条件として、相互理解処理おいて心理的安全性に関するアドバイスを出力する態様としてもよい。
【0461】
また、ユーザのストロークを取得し、所定期間内に心理的安全性が低下するストローク(例えば否定ストローク)を所定回数以上実行している場合に、これ以上否定ストロークを行うと、心理的安全性が低下し過ぎるなどの警告を出力してもよい。
【0462】
上記の説明においては、
図19および
図20などを参照しながら、各ユーザが自身で行うストロークを確認する画像を出力することを説明した。ここで、ストローク確認用の画像としては、例えば各ユーザが自身で行う能動ストロークと、他のユーザから受ける受動ストロークとを表示する態様でもよい。このとき、1カ月前など過去と、現在とを重ねて表示する態様でもよい。さらに説明をすると、過去と現在における「否定肯定バランス」、「前向きな関わり」、「指摘の的確さ」、「関わりの有無」の各項目を数値化し、レーダーチャートしながら、過去と現在とを比較可能となるよう重ねて表示してもよい。また、能動ストロークと受動ストロークの各項目について、重ねて表示する態様でもよい。付言すると、ここではストロークを確認する画像として説明をしたが、心理的安全性、相互理解、あるいは相互援助など、他の項目を確認する画像を出力してもよい。
【0463】
上記の説明においては、ユーザ同士の関係性を向上させる支援情報を出力することを説明した。ここで、支援情報は、一時的に悪化するものであってもよい。すなわち、短期的にはユーザ同士の関係性が悪化するものであっても、中長期的にはユーザ同士の関係性が向上すればよい。したがって、支援情報は、例えば、心理的安全性が一時的に低下するものの、その後に心理的安全性が向上し得るアクションプランを含んでもよい。この処理において、心理的安全性が所定値以上であることを条件として、心理的安全性が一時的に悪化する支援情報を出力するようにしてもよい。このことにより、心理的安全性が向上しないほどユーザ同士の関係性が悪化することが抑制される。
【0464】
さて、会社などの集団においては、事業の継続性や、商品・サービスの品質を維持することなど、集団にとって優先すべき事項(優先事項)がある。一方で、このような優先事項に対処することによって、集団を構成するチームメンバーの心理的安全性が低下することがある。いわば、集団全体の利益を確保することにともない、集団を構成するチームメンバーの心理的安全性が低下することを回避できないことがある。このとき、心理的安全性の低下が大きくなりすぎると、チームメンバーであるユーザが集団から離脱するなどの不利益が生じ得る。そこで、例えば心理的安全性が閾値よりも大きいことを条件として、集団全体の利益を優先すべきアクションプランを出力するようにしてもよい。また、集団が許容できる心理的安全性が低下する程度(許容低下度)ごとに、アクションプランを切り替えてもよい。例えば、心理的安全性が第1閾値よりも高い(集団に余力がある)場合には、集団の許容低下度が大きい。したがって、心理的安全性が大きく低下する可能性があるが、集団全体の利益が相対的に大きく確保されるアクションプランを出力可能とする。また、心理的安全性が第1閾値よりも低く第2閾値(<第1閾値)よりも高い(集団にやや余力がある)場合には、心理的安全性が小さく低下する可能性があるが、集団全体の利益が相対的に小さく確保されるアクションプランを出力する。また、心理的安全性が第2閾値よりも低い(集団に余力がない)場合には、集団の許容低下度が小さい。したがって、心理的安全性が低下するアクションプランを出力しない。なお、集団全体の利益を増加させるため、心理的安全性が低下する可能性があるアクションプランが複数あり、集団の現在の心理的安全性および/または現在の集団全体の利益に応じて、アクションプランを切り替えてもよい。例えば、集団として必ず実行すべき項目については、心理的安全性が低い場合であっても、集団全体の利益を確保するアクションプランを出力する態様でもよい。
【0465】
なお、上記では種々の実施形態および変形例を説明したが、これらの実施形態や変形例同士を組み合わせて構成してももちろんよい。
また、本開示は上記の実施形態に何ら限定されるものではなく、本開示の要旨を逸脱しない範囲で種々の形態で実施することができる。
【0466】
情報処理システム1は、システムの一例である。管理装置500は、装置の一例である。相互理解管理553は、理解情報取得手段の一例である。ストローク管理部555は、言動情報取得手段および第2取得手段の一例である。支援実行部561は、出力手段、形成時期取得手段、精神情報取得手段の一例である。表象関係管理部551は、関係性評価取得手段および第1取得手段の一例である。潜在的相性管理部557は、相性取得手段の一例である。第3アドバイス画像IM93は、理解促進情報の一例である。
【0467】
また、ストローク情報は、言動情報の一例である。他者提示可能情報は、提示可能情報の一例である。他者提示可能情報の把握度は、理解情報の一例である。禁止情報は禁止言動情報の一例である。許容情報は、容認言動情報の一例である。肯定ストロークは、肯定言動の一例である。否定ストロークは、否定言動の一例である。ストロークコンテンツは、肯定言動促進情報、無視言動抑制情報、意識高化情報の一例である。ノンストロークは、無視言動の一例である。ストローク意識情報は、言動意識情報の一例である。表象評価は、関係性評価の一例である。侵襲性質問の回答は、高確率情報の一例である。非侵襲性質問の回答は、低確率情報の一例である。潜在的相性コンテンツは、悪化抑制情報の一例である。表象関係コンテンツは、第1支援情報の一例である。ストロークコンテンツは、第2支援情報の一例である。
【符号の説明】
【0468】
1…情報処理システム、500…管理装置、510…ユーザ情報管理部、550…出力管理部、551…表象関係管理部、553…ストロークコンテンツ、555…ストローク管理部、557…潜在的相性管理部、561…支援実行部