(57)【要約】【課題】コミュニケーション情報と進捗情報から、プロジェクトの進捗におけるリスクを判定し、コラボレーション相手の候補として他のプロジェクトを通知することができる情報処理装置を提供する。【解決手段】情報処理装置の取得手段は、複数のユーザーで構成される第１のユーザー群が参加する第１のプロジェクトにおいて、該第１のプロジェクトに関わるコミュニケーション情報と、該第１のプロジェクトの進捗を示す進捗情報を取得し、判定手段は、取得手段によって取得されたコミュニケーション情報と進捗情報から、第１のプロジェクトの進捗におけるリスクの有無の判定をし、通知手段は、判定手段によってリスクが有りと判定された場合に、第１のユーザー群の少なくとも１人以上のユーザーに対して、該第１のユーザー群の少なくとも１人以上が異なる第２のユーザー群が参加する第２のプロジェクトをコラボレーション相手の候補として通知する。【選択図】図１
2020034963.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザーで構成される第１のユーザー群が参加する第１のプロジェクトにおいて、該第１のプロジェクトに関わるコミュニケーション情報と、該第１のプロジェクトの進捗を示す進捗情報を取得する取得手段と、
前記取得手段によって取得された前記コミュニケーション情報と前記進捗情報から、前記第１のプロジェクトの進捗におけるリスクの有無の判定を行う判定手段と、
前記判定手段によってリスクが有りと判定された場合に、前記第１のユーザー群の少なくとも１人以上のユーザーに対して、該第１のユーザー群の少なくとも１人以上が異なる第２のユーザー群が参加する第２のプロジェクトをコラボレーション相手の候補として通知する通知手段
を有する情報処理装置。
【請求項２】
前記第１のプロジェクト以外の他のプロジェクトにおいて、該他のプロジェクトに関わるコミュニケーション情報と、該他のプロジェクトの進捗を示す進捗情報を取得する第２の取得手段
をさらに有し、
前記通知手段は、前記第２の取得手段によって取得された前記コミュニケーション情報と前記進捗情報から、前記第２のプロジェクトを選択する、
請求項１に記載の情報処理装置。
【請求項３】
前記判定手段は、前記第２の取得手段によって取得された前記コミュニケーション情報と前記進捗情報から、前記他のプロジェクトの進捗におけるリスクの有無の判定を行い、
前記通知手段は、前記第１のプロジェクトのリスク有りと判定された項目において、リスク無しと判定された他のプロジェクトを前記第２のプロジェクトとして選択する、
請求項２に記載の情報処理装置。
【請求項４】
前記通知手段は、前記第１のプロジェクトのリスク有りと判定された項目において、過去にリスク有りと判定され、現在はリスク無しと判定された他のプロジェクトを前記第２のプロジェクトとして選択する、
請求項３に記載の情報処理装置。
【請求項５】
前記判定手段は、前記第２の取得手段によって取得された前記コミュニケーション情報と前記進捗情報から、前記他のプロジェクトの進捗におけるリスクの有無の判定を行い、
前記通知手段は、前記第１のプロジェクトのリスク有りと判定された項目とは異なる項目において、リスク有りと判定された他のプロジェクトを前記第２のプロジェクトとして選択する、
請求項２に記載の情報処理装置。
【請求項６】
前記通知手段は、前記第１のプロジェクトのリスク無しと判定された項目において、リスク有りと判定された他のプロジェクトを前記第２のプロジェクトとして選択する、
請求項５に記載の情報処理装置。
【請求項７】
コンピュータを、
複数のユーザーで構成される第１のユーザー群が参加する第１のプロジェクトにおいて、該第１のプロジェクトに関わるコミュニケーション情報と、該第１のプロジェクトの進捗を示す進捗情報を取得する取得手段と、
前記取得手段によって取得された前記コミュニケーション情報と前記進捗情報から、前記第１のプロジェクトの進捗におけるリスクの有無の判定を行う判定手段と、
前記判定手段によってリスクが有りと判定された場合に、前記第１のユーザー群の少なくとも１人以上のユーザーに対して、該第１のユーザー群の少なくとも１人以上が異なる第２のユーザー群が参加する第２のプロジェクトをコラボレーション相手の候補として通知する通知手段
として機能させるための情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及び情報処理プログラムに関する。
【背景技術】
【０００２】
特許文献１には、プロジェクト関係者間のコミュニケーションに関連するプロジェクトリスクの予測を支援することを課題とし、プロジェクト関係者の端末、サーバーがネットワーク上に存在し、サーバーは、発信者識別子と発信日時とを含む情報がメッセージ毎に格納されるコミュニケーション情報蓄積部、演算処理部を有し、演算処理部は、いずれかの端末がメッセージを発信すると、そのメッセージに関するコミュニケーション情報をコミュニケーション情報蓄積部に格納し、また、コミュニケーション情報蓄積部の蓄積情報に基づき、プロジェクト関係者毎に、プロジェクト関係者のメッセージ送信回数を時系列に表す解析情報を出力することが開示されている。
【０００３】
特許文献２には、プロジェクト関係者間のコミュニケーションに関連するプロジェクトリスクの予測を支援することを課題とし、サーバーは、発信者識別子と発信日時と受信者識別子と受信日とを含む情報がメッセージ毎に格納されるコミュニケーション情報蓄積部、演算処理部を有し、演算処理部は、いずれかの端末がメッセージを発信すると、そのメッセージに関するコミュニケーション情報をコミュニケーション情報蓄積部に格納し、また、コミュニケーション情報蓄積部の蓄積情報に基づき、プロジェクト関係者毎に、プロジェクト関係者のメッセージ送信回数を時系列に表す解析情報を出力することが開示されている。
【０００４】
特許文献３には、予め決められたテキストの表現と意図との関係に基づいて、プロジェクトに関連するテキスト文に含まれる発言の意図を判定する意図判定手段と、予め決められたテキスト表現とトピックとの関係に基づいて、前記テキスト文に含まれる発言のトピックを判定するトピック判定手段と、複数の発言の意図及びトピックの出現パターンからなるリスク文抽出条件が記憶された抽出条件記憶手段と、前記意図判定手段により判定された意図及び前記トピック判定手段により判定されたトピックと、前記抽出条件記憶手段に記憶されているリスク文抽出条件とを照合し、前記リスク文抽出条件に合致する意図及びトピックに対応する発言をリスク発言として特定する発言特定手段とを有することが開示されている。
【０００５】
特許文献４には、発言内容の類似度を指標として話題の分布を分析し、特定の話題の変遷を追跡することを課題とし、発言内容分析部は発言を分析してその内容に関するユーザープロファイル（グラフ）を構築し、タスク構造解析部はタスクの登録されているユーザー情報に基づいて各ユーザーのタスクリストを生成し、プロファイル類似度判定部はユーザー間のプロファイル（発言内容）の類似度を計算し、距離計算部は、タスクマップを参照して辿る最短ルートのタスク距離を算出し、類似度集計部は距離毎の類似度（類似発言ユーザー数や平均値）の分布を集計して、分析結果出力部はこれを出力することが開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−０５４６０６号公報
【特許文献２】特開２００４−１２７１４０号公報
【特許文献３】特許第５２１２６０４号公報
【特許文献４】特開２００７−０７２５４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
複数のユーザーで構成されるユーザー群が参加するプロジェクトの進捗において、リスクが発生することがある。特に、プロジェクトに関わるコミュニケーションと、そのプロジェクトの進捗において、その兆候が現れる。また、他のプロジェクトにおいては、同じリスクを解決している場合がある。しかし、その知見を生かすことは困難である。
本発明は、コミュニケーション情報と進捗情報から、プロジェクトの進捗におけるリスクを判定し、コラボレーション相手の候補として他のプロジェクトを通知することができる情報処理装置及び情報処理プログラムを提供することを目的としている。
【課題を解決するための手段】
【０００８】
かかる目的を達成するための本発明の要旨とするところは、次の各項の発明に存する。
請求項１の発明は、複数のユーザーで構成される第１のユーザー群が参加する第１のプロジェクトにおいて、該第１のプロジェクトに関わるコミュニケーション情報と、該第１のプロジェクトの進捗を示す進捗情報を取得する取得手段と、前記取得手段によって取得された前記コミュニケーション情報と前記進捗情報から、前記第１のプロジェクトの進捗におけるリスクの有無の判定を行う判定手段と、前記判定手段によってリスクが有りと判定された場合に、前記第１のユーザー群の少なくとも１人以上のユーザーに対して、該第１のユーザー群の少なくとも１人以上が異なる第２のユーザー群が参加する第２のプロジェクトをコラボレーション相手の候補として通知する通知手段を有する情報処理装置である。
【０００９】
請求項２の発明は、前記第１のプロジェクト以外の他のプロジェクトにおいて、該他のプロジェクトに関わるコミュニケーション情報と、該他のプロジェクトの進捗を示す進捗情報を取得する第２の取得手段をさらに有し、前記通知手段は、前記第２の取得手段によって取得された前記コミュニケーション情報と前記進捗情報から、前記第２のプロジェクトを選択する、請求項１に記載の情報処理装置である。
【００１０】
請求項３の発明は、前記判定手段は、前記第２の取得手段によって取得された前記コミュニケーション情報と前記進捗情報から、前記他のプロジェクトの進捗におけるリスクの有無の判定を行い、前記通知手段は、前記第１のプロジェクトのリスク有りと判定された項目において、リスク無しと判定された他のプロジェクトを前記第２のプロジェクトとして選択する、請求項２に記載の情報処理装置である。
【００１１】
請求項４の発明は、前記通知手段は、前記第１のプロジェクトのリスク有りと判定された項目において、過去にリスク有りと判定され、現在はリスク無しと判定された他のプロジェクトを前記第２のプロジェクトとして選択する、請求項３に記載の情報処理装置である。
【００１２】
請求項５の発明は、前記判定手段は、前記第２の取得手段によって取得された前記コミュニケーション情報と前記進捗情報から、前記他のプロジェクトの進捗におけるリスクの有無の判定を行い、前記通知手段は、前記第１のプロジェクトのリスク有りと判定された項目とは異なる項目において、リスク有りと判定された他のプロジェクトを前記第２のプロジェクトとして選択する、請求項２に記載の情報処理装置である。
【００１３】
請求項６の発明は、前記通知手段は、前記第１のプロジェクトのリスク無しと判定された項目において、リスク有りと判定された他のプロジェクトを前記第２のプロジェクトとして選択する、請求項５に記載の情報処理装置である。
【００１４】
請求項７の発明は、コンピュータを、複数のユーザーで構成される第１のユーザー群が参加する第１のプロジェクトにおいて、該第１のプロジェクトに関わるコミュニケーション情報と、該第１のプロジェクトの進捗を示す進捗情報を取得する取得手段と、前記取得手段によって取得された前記コミュニケーション情報と前記進捗情報から、前記第１のプロジェクトの進捗におけるリスクの有無の判定を行う判定手段と、前記判定手段によってリスクが有りと判定された場合に、前記第１のユーザー群の少なくとも１人以上のユーザーに対して、該第１のユーザー群の少なくとも１人以上が異なる第２のユーザー群が参加する第２のプロジェクトをコラボレーション相手の候補として通知する通知手段として機能させるための情報処理プログラムである。
【発明の効果】
【００１５】
請求項１の情報処理装置によれば、コミュニケーション情報と進捗情報から、プロジェクトの進捗におけるリスクを判定し、コラボレーション相手の候補として他のプロジェクトを通知することができる。
【００１６】
請求項２の情報処理装置によれば、他のプロジェクトのコミュニケーション情報と進捗情報から、コラボレーション相手の候補を選択することができる。
【００１７】
請求項３の情報処理装置によれば、第１のプロジェクトのリスク有りと判定された項目において、リスク無しと判定された他のプロジェクトをコラボレーション相手の候補として選択することができる。
【００１８】
請求項４の情報処理装置によれば、第１のプロジェクトのリスク有りと判定された項目において、過去にリスク有りと判定されたが、現在はリスク無しと判定された他のプロジェクトをコラボレーション相手の候補として選択することができる。
【００１９】
請求項５の情報処理装置によれば、第１のプロジェクトのリスク有りと判定された項目とは異なる項目において、リスク有りと判定された他のプロジェクトをコラボレーション相手の候補として選択することができる。
【００２０】
請求項６の情報処理装置によれば、第１のプロジェクトのリスク無しと判定された項目において、リスク有りと判定された他のプロジェクトをコラボレーション相手の候補として選択することができる。
【００２１】
請求項７の情報処理プログラムによれば、コミュニケーション情報と進捗情報から、プロジェクトの進捗におけるリスクを判定し、コラボレーション相手の候補として他のプロジェクトを通知することができる。
【図面の簡単な説明】
【００２２】
【図１】本実施の形態の構成例についての概念的なモジュール構成図である。
【図２】本実施の形態を利用したシステム構成例を示す説明図である。
【図３】本実施の形態による処理例を示すフローチャートである。
【図４】本実施の形態による処理例を示すフローチャートである。
【図５】スキル情報テーブルのデータ構造例を示す説明図である。
【図６】本実施の形態による処理例を示すフローチャートである。
【図７】本実施の形態による処理例を示すフローチャートである。
【図８】本実施の形態による処理例を示すフローチャートである。
【図９】本実施の形態による処理例を示す説明図である。
【図１０】プロジェクト管理テーブルのデータ構造例を示す説明図である。
【図１１】本実施の形態による処理例を示すフローチャートである。
【図１２】プロジェクト管理テーブルのデータ構造例を示す説明図である。
【図１３】本実施の形態を実現するコンピュータのハードウェア構成例を示すブロック図である。
【発明を実施するための形態】
【００２３】
以下、図面に基づき本発明を実現するにあたっての好適な一実施の形態の例を説明する。
図１は、本実施の形態の構成例についての概念的なモジュール構成図を示している。
なお、モジュールとは、一般的に論理的に分離可能なソフトウェア（コンピュータ・プログラム）、ハードウェア等の部品を指す。したがって、本実施の形態におけるモジュールはコンピュータ・プログラムにおけるモジュールのことだけでなく、ハードウェア構成におけるモジュールも指す。それゆえ、本実施の形態は、それらのモジュールとして機能させるためのコンピュータ・プログラム（コンピュータにそれぞれの手順を実行させるためのプログラム、コンピュータをそれぞれの手段として機能させるためのプログラム、コンピュータにそれぞれの機能を実現させるためのプログラム）、システム及び方法の説明をも兼ねている。ただし、説明の都合上、「記憶する」、「記憶させる」、これらと同等の文言を用いるが、これらの文言は、実施の形態がコンピュータ・プログラムの場合は、記憶装置に記憶させる、又は記憶装置に記憶させるように制御するという意味である。また、モジュールは機能に一対一に対応していてもよいが、実装においては、１モジュールを１プログラムで構成してもよいし、複数モジュールを１プログラムで構成してもよく、逆に１モジュールを複数プログラムで構成してもよい。また、複数モジュールは１コンピュータによって実行されてもよいし、分散又は並列環境におけるコンピュータによって１モジュールが複数コンピュータで実行されてもよい。なお、１つのモジュールに他のモジュールが含まれていてもよい。また、以下、「接続」とは物理的な接続の他、論理的な接続（データの授受、指示、データ間の参照関係、ログイン等）の場合にも用いる。「予め定められた」とは、対象としている処理の前に定まっていることをいい、本実施の形態による処理が始まる前はもちろんのこと、本実施の形態による処理が始まった後であっても、対象としている処理の前であれば、そのときの状況・状態にしたがって、又はそれまでの状況・状態にしたがって定まることの意を含めて用いる。「予め定められた値」が複数ある場合は、それぞれ異なった値であってもよいし、２以上の値（もちろんのことながら、全ての値も含む）が同じであってもよい。また、「Ａである場合、Ｂをする」という記載は、「Ａであるか否かを判断し、Ａであると判断した場合はＢをする」の意味で用いる。ただし、Ａであるか否かの判断が不要である場合を除く。また、「Ａ、Ｂ、Ｃ」等のように事物を列挙した場合は、断りがない限り例示列挙であり、その１つのみを選んでいる場合（例えば、Ａのみ）を含む。
また、システム又は装置とは、複数のコンピュータ、ハードウェア、装置等がネットワーク（一対一対応の通信接続を含む）等の通信手段で接続されて構成されるほか、１つのコンピュータ、ハードウェア、装置等によって実現される場合も含まれる。「装置」と「システム」とは、互いに同義の用語として用いる。もちろんのことながら、「システム」には、人為的な取り決めである社会的な「仕組み」（社会システム）にすぎないものは含まない。
また、各モジュールによる処理毎に又はモジュール内で複数の処理を行う場合はその処理毎に、対象となる情報を記憶装置から読み込み、その処理を行った後に、処理結果を記憶装置に書き出すものである。したがって、処理前の記憶装置からの読み込み、処理後の記憶装置への書き出しについては、説明を省略する場合がある。なお、ここでの記憶装置としては、ハードディスク、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、外部記憶媒体、通信回線を介した記憶装置、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）内のレジスタ等を含んでいてもよい。
【００２４】
本実施の形態である情報処理装置１００は、プロジェクトの進捗管理を行うものであって、図１の例に示すように、取得（Ａ）モジュール１０５、取得（Ｂ）モジュール１１０、リスク判定モジュール１１５、通知モジュール１２０を有している。
ここでのプロジェクトとは、複数のユーザーによって構成される集団によって、特定の期限（以下、納期ともいう）までに何らかの目標を達成するための業務のことをいう。例えば、新しい商品を開発するための商品開発プロジェクト等がある。そして、プロジェクトには、活動フェーズがあり、例えば、企画、設計、開発、テスト、保守等の活動フェーズがある。
【００２５】
取得（Ａ）モジュール１０５は、リスク判定モジュール１１５、プロジェクト（Ａ）管理装置１５０Ａと接続されている。取得（Ａ）モジュール１０５は、プロジェクト（Ａ）管理装置１５０Ａから、複数のユーザーで構成される第１のユーザー群が参加するプロジェクト（Ａ）において、そのプロジェクト（Ａ）に関わるコミュニケーション情報と、そのプロジェクト（Ａ）の進捗を示す進捗情報を取得する。
「コミュニケーション情報」として、例えば、コミュニケーションが行われた日時（年、月、日、時、分、秒、秒以下、又はこれらの組み合わせであってもよい）、そのコミュニケーションを行ったユーザー、そのコミュニケーションの内容等があり、具体的には、そのプロジェクトにおいて参加者であるユーザー間でやり取りされた、メール、投稿、メッセージ、文書等の閲覧、プロジェクト管理装置への報告（例えば、進捗、不具合発見率等の登録）等がある。
「進捗情報」として、そのプロジェクトにおける活動フェーズが含まれる。例えば、そのプロジェクトにおけるＴＯＤＯ等での着手日時、期限、進捗状況等がある。
【００２６】
取得（Ｂ）モジュール１１０は、リスク判定モジュール１１５、プロジェクト（Ｂ）管理装置１５０Ｂ、プロジェクト（Ｃ）管理装置１５０Ｃと接続されている。取得（Ｂ）モジュール１１０は、プロジェクト（Ｂ）管理装置１５０Ｂ、プロジェクト（Ｃ）管理装置１５０Ｃ等から、プロジェクト（Ａ）以外の他のプロジェクトにおいて、他のプロジェクトに関わるコミュニケーション情報と、他のプロジェクトの進捗を示す進捗情報を取得する。
【００２７】
リスク判定モジュール１１５は、取得（Ａ）モジュール１０５、取得（Ｂ）モジュール１１０、通知モジュール１２０と接続されている。リスク判定モジュール１１５は、取得（Ａ）モジュール１０５によって取得されたコミュニケーション情報と進捗情報から、プロジェクト（Ａ）の進捗におけるリスクの有無の判定を行う。つまり、リスク判定モジュール１１５は、リスクの顕在化の判定を行う。この判定は、例えば、定期的に実施する。具体的には、活動フェーズ毎に用意されたルール（規則）にしたがって、リスク有無の判定を行ってもよい。ルールについては、図２の例に示す顕在化ルールとして後述する。
また、リスク判定モジュール１１５は、取得（Ｂ）モジュール１１０によって取得されたコミュニケーション情報と進捗情報から、他のプロジェクトの進捗におけるリスクの有無の判定を行うようにしてもよい。
【００２８】
提案処理モジュール１２５は、提案対象プロジェクトの検索を行う。つまり、提案処理モジュール１２５は、リスク判定モジュール１１５によってリスクが有りと判定された場合に、第１のユーザー群の少なくとも１人以上のユーザーに対して、その第１のユーザー群の少なくとも１人以上が異なる第２のユーザー群が参加する他のプロジェクト（例えば、プロジェクト（Ｂ）、プロジェクト（Ｃ）等）をコラボレーション相手の候補として選択する。
１人のユーザーが複数のプロジェクトに参加することがあり得る。したがって、プロジェクト（Ａ）と他のプロジェクトの両方に参加しているユーザーもあり得る。ただし、他のプロジェクトに参加しているが、プロジェクト（Ａ）に参加していないユーザーもあり得て、そのユーザーがプロジェクト（Ａ）におけるリスクを解決する可能性もある。そこで、「コラボレーション相手の候補となる他のプロジェクト」は、「第１のユーザー群の少なくとも１人以上が異なる第２のユーザー群が参加するプロジェクト」である。もちろんのことながら、プロジェクト（Ａ）に参加しているユーザーと他のプロジェクトに参加しているユーザーが１人もいない場合（プロジェクト（Ａ）と他のプロジェクトとで重複しているユーザーがいない場合、プロジェクト（Ａ）に参加しているユーザーと他のプロジェクトに参加しているユーザーが全て異なる場合）も含む。この場合、プロジェクト（Ａ）では所有していないノウハウを他のプロジェクトが有している可能性が高いので、コラボレーション相手として適している場合がある。
【００２９】
また、提案処理モジュール１２５は、取得（Ｂ）モジュール１１０によって取得されたコミュニケーション情報と進捗情報から、コラボレーション相手の候補となるプロジェクトを選択する。
そして、提案処理モジュール１２５は、プロジェクト（Ａ）のリスク有りと判定された項目において、リスク無しと判定された他のプロジェクトをコラボレーション相手の候補であるプロジェクトとして選択するようにしてもよい。ここで「項目」には、リスク判定モジュール１１５がリスクの判定に用いたルールを含めてもよい。つまり、プロジェクト（Ａ）ではルールＸによってリスク有りと判定されたが、プロジェクト（Ｂ）ではルールＸによってリスク無しと判定された場合が該当することになる。なお、他のプロジェクトについては、現在においてリスク無しと判定されていればよく、過去においてリスク有りと判定されていてもよい。
さらに、具体的には、提案処理モジュール１２５は、プロジェクト（Ａ）のリスク有りと判定された項目において、過去にリスク有りと判定され、現在はリスク無しと判定された他のプロジェクトをコラボレーション相手の候補となるプロジェクトとして選択するようにしてもよい。ここで選択されたプロジェクトは、同じ項目で発生したリスクを解決したことになるので、プロジェクト（Ａ）に対してリスク解決の知見を有していることになる。
より具体的には、提案処理モジュール１２５は、プロジェクト（Ａ）のリスクが発生した活動フェーズと同じ活動フェーズで、プロジェクト（Ａ）のリスクと同様のリスクが発生した他のプロジェクトをコラボレーション相手の候補であるプロジェクトとして提案するようにしてもよい。これによって、プロジェクト（Ａ）は、他のプロジェクトにおける知見を活用して、低工数でよりよい解決が図れるようになる。なお、コラボレーション相手の候補となるプロジェクトの選択処理として、同じ活動フェーズで、プロジェクト（Ａ）のリスクと同様のリスクが顕在化した他のプロジェクトを選択することの他に、以下に示すような選択処理としてもよい。
【００３０】
また、提案処理モジュール１２５は、リスク判定モジュール１１５によってプロジェクト（Ａ）のリスク有りと判定された項目とは異なる項目において、リスク有りと判定された他のプロジェクトをコラボレーション相手の候補であるプロジェクトとして選択するようにしてもよい。これによって、プロジェクト（Ａ）とは異なる側面を有しているプロジェクトとして選択することができるようになる。なお、さらに、プロジェクト（Ａ）のリスク有りと判定された項目と同じ項目ではリスク無しと判定された他のプロジェクトであることが好ましい。
そして、提案処理モジュール１２５は、リスク判定モジュール１１５によって第１のプロジェクトのリスク無しと判定された項目において、リスク有りと判定された他のプロジェクトをコラボレーション相手の候補であるプロジェクトとして選択するようにしてもよい。
【００３１】
通知モジュール１２０は、提案処理モジュール１２５を有しており、リスク判定モジュール１１５、プロジェクト（Ａ）担当ユーザー端末１７０Ａと接続されている。通知モジュール１２０は、リスク判定モジュール１１５によってプロジェクト（Ａ）にリスクが有りと判定された場合に、第１のユーザー群の少なくとも１人以上のユーザー（プロジェクト（Ａ）担当ユーザー端末１７０Ａ又はプロジェクト（Ａ）担当ユーザー端末１７０Ａの利用者であるユーザー）に対して、提案処理モジュール１２５によって選択されたプロジェクトをコラボレーション相手の候補として通知する。ここで通知として、例えば、電子メール、チャット、電子掲示板、ソーシャルメディアを用いた通知、プッシュ通知、自動音声応答による電話発信等があり、電話発信として、例えば、Ｌｙｎｃ（登録商標）等を用いて行えばよい。
【００３２】
プロジェクト（Ａ）管理装置１５０Ａは、プロジェクト（Ａ）活動情報記憶モジュール１５５Ａを有しており、情報処理装置１００の取得（Ａ）モジュール１０５と接続されている。プロジェクト（Ａ）管理装置１５０Ａは、プロジェクト（Ａ）の活動情報を記憶している。活動情報として、少なくとも、コミュニケーション情報と進捗情報スケジュールを含み、その他に、課題、成果物等を記憶していてもよい。
プロジェクト（Ｂ）管理装置１５０Ｂは、プロジェクト（Ｂ）活動情報記憶モジュール１５５Ｂを有しており、情報処理装置１００の取得（Ｂ）モジュール１１０と接続されている。プロジェクト（Ｂ）管理装置１５０Ｂは、プロジェクト（Ｂ）の活動情報を記憶している。
プロジェクト（Ｃ）管理装置１５０Ｃは、プロジェクト（Ｃ）活動情報記憶モジュール１５５Ｃを有しており、情報処理装置１００の取得（Ｂ）モジュール１１０と接続されている。プロジェクト（Ｃ）管理装置１５０Ｃは、プロジェクト（Ｃ）の活動情報を記憶している。
なお、プロジェクト（Ａ）以外の他のプロジェクトとして、プロジェクト（Ｂ）、プロジェクト（Ｃ）を例示しているが、３つ以上のプロジェクトであってもよいし、１つのプロジェクトであってもよい。
【００３３】
プロジェクト（Ａ）担当ユーザー端末１７０Ａは、情報処理装置１００の通知モジュール１２０と接続されている。プロジェクト（Ａ）担当ユーザー端末１７０Ａは、プロジェクト（Ａ）に参画しているユーザー（例えば、プロジェクト（Ａ）のリーダー等）によって用いられており、通信機能を有している。例えば、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ、ノートＰＣ、タブレット型端末等であってもよい）、携帯端末（スマートフォンを含む携帯電話等）、ウェアラブル端末（リストバンド型（腕輪型）、腕時計型、頭に装着するメガネ型）等が該当する。
【００３４】
図２は、本実施の形態を利用したシステム構成例を示す説明図である。
情報処理装置１００、プロジェクト（Ａ）管理装置１５０Ａ、プロジェクト（Ｂ）管理装置１５０Ｂ、プロジェクト（Ｃ）管理装置１５０Ｃ、全プロジェクト管理装置２５０、ユーザー端末２７０Ａ、ユーザー端末２７０Ｂ、ユーザー端末２７０Ｃ、ユーザー端末２７０Ｄ、ユーザー端末２７０Ｅ、ユーザー端末２７０Ｆ、ユーザー端末２７０Ｇ、ユーザー端末２７０Ｈ、ユーザー端末２７０Ｉ、ユーザー端末２７０Ｊ、ユーザー端末２７０Ｋは、通信回線２９０を介してそれぞれ接続されている。通信回線２９０は、無線、有線、これらの組み合わせであってもよく、例えば、通信インフラとしてのインターネット、イントラネット等であってもよい。また、情報処理装置１００、プロジェクト管理装置１５０、全プロジェクト管理装置２５０による機能は、クラウドサービスとして実現してもよい。
【００３５】
全プロジェクト管理装置２５０は、プロジェクトフェーズ情報記憶モジュール２５５、リスク顕在化ルール記憶モジュール２６０、顕在化リスク一覧記憶モジュール２６５を有している。全プロジェクト管理装置２５０は、各プロジェクトの定義処理と管理を行う。
プロジェクトフェーズ情報記憶モジュール２５５は、各プロジェクトのプロジェクト情報（プロジェクトを構成する情報）、活動フェーズ情報（各プロジェクトが取り得る活動フェーズに関する情報）を記憶している。各プロジェクトのリーダーがプロジェクト情報、活動フェーズ情報を入力する。
リスク顕在化ルール記憶モジュール２６０は、各プロジェクトのリスクの顕在化ルールを記憶している。例えば、リスク判定モジュール１１５は、リスク顕在化ルール記憶モジュール２６０に記憶されている顕在化ルールにしたがって、リスクを判定している。各プロジェクトのリーダーが顕在化ルールを入力する。
顕在化ルールとして、例えば、活動フェーズに対応して、コミュニケーション情報で定義されており、具体的には、以下のものがある。
（１）企画フェーズ
（ａ）コミュニケーションに参加していいない（発言のない）メンバーがｘｘ割合以上存在する。
（ｂ）発言に対する返信率がｘｘ％よりも低い。又は、返信までのタイムラグがｘｘ時間より大きい。
（２）設計フェーズ
（ａ）決定事項（成果物）に対し閲覧していないメンバーがｘｘ割合以上存在する。
（ｂ）設計フェーズ終了後に成果物が修正される回数がｘｘ回よりも多い。
（３）開発フェーズ
（ａ）スケジュール通りに着手、完了できていない。
（ｂ）アクション事項に人員をアサインできていない。
（４）テストフェーズ
（ａ）不具合発見率に減少傾向がない。
（５）保守フェーズ
（ａ）問い合わせに対する平均回答時間がｘｘ以上である。
（ｂ）不具合報告数がｘｘ回よりも多い。
【００３６】
顕在化リスク一覧記憶モジュール２６５は、各プロジェクトの顕在化リスクの一覧を記憶している。リスク判定モジュール１１５によって判定された結果を記憶している。過去のプロジェクト（納期が過ぎたプロジェクト）、現在のプロジェクトにおけるリスクを記憶している。取得（Ｂ）モジュール１１０は、他のプロジェクトにおけるリスクを顕在化リスク一覧記憶モジュール２６５から取得するようにしてもよい。その場合、リスク判定モジュール１１５による他のプロジェクトの進捗におけるリスクの有無の判定処理は不要となる。
【００３７】
プロジェクト（Ａ）２１０Ａには、プロジェクト（Ａ）リーダー２７２Ａ、プロジェクトメンバー２７２Ｂ、プロジェクトメンバー２７２Ｃ、プロジェクトメンバー２７２Ｄが参加している。
プロジェクト（Ｂ）２１０Ｂには、プロジェクトメンバー２７２Ｄ、プロジェクトメンバー２７２Ｅ、プロジェクト（Ｂ）リーダー２７２Ｆ、プロジェクトメンバー２７２Ｇ、プロジェクトメンバー２７２Ｈが参加している。
プロジェクト（Ｃ）２１０Ｃには、プロジェクトメンバー２７２Ｈ、プロジェクト（Ｃ）リーダー２７２Ｉ、プロジェクトメンバー２７２Ｊ、プロジェクトメンバー２７２Ｋが参加している。
なお、プロジェクトメンバー２７２Ｄは、プロジェクト（Ａ）２１０Ａとプロジェクト（Ｂ）２１０Ｂの両方に参加しており、プロジェクトメンバー２７２Ｈは、プロジェクト（Ｂ）２１０Ｂとプロジェクト（Ｃ）２１０Ｃの両方に参加している。このように、各プロジェクトには、複数人のユーザーが参加しており、また、一人のユーザーが複数のプロジェクトに参加してもよい。
【００３８】
この例では、複数のユーザーで構成される第１のユーザー群が参加するプロジェクト（Ａ）２１０Ａと、第１のユーザー群とは別のユーザーで構成される第２のユーザー群とが参加するプロジェクト（Ｂ）２１０Ｂ等がある。
例えば、プロジェクト（Ａ）２１０Ａにおいて、プロジェクト２１０Ａのコミュニケーション情報と進捗情報からリスクが発生したことを検知した場合、コラボレーション相手の候補となるプロジェクトを特定する。ここで検知は、潜在リスクを検知（顕在化）することとなる。
また、コラボレーション相手の候補となるプロジェクトは、そのリスクに対し協力して解決、低減させることのできるプロジェクトである。情報処理装置１００は、両プロジェクトに対しコラボレーションを提案する。情報処理装置１００は、異なる側面を持つプロジェクトを提案することで、新たなアイディア、打開策の創発を目指すものである。
【００３９】
図３は、本実施の形態による処理例を示すフローチャートである。
ステップＳ３０２からステップＳ３０６までの処理は、プロジェクトの定義作業に該当する。また、ステップＳ３０８からステップＳ３１４までの処理は、コラボレーション相手となるプロジェクトの提案処理である。
【００４０】
ステップＳ３０２では、リーダーがプロジェクト情報を入力する。
ステップＳ３０４では、リーダーがフェーズを選択する。
ステップＳ３０６では、リーダーがリスクの顕在化ルールの選択、追加、編集、削除等を行う。例えば、リスクの顕在化ルールは、全プロジェクトで共有されており、フェーズの入力のみでリスクの顕在化ルールも指定されるようにしてもよい。また、リーダーがプロジェクト毎に顕在化ルールを選択してもよい。なお、ステップＳ３０６の処理は任意としてもよい。
【００４１】
ステップＳ３０８では、プロジェクトのメンバーによるウェブシステム等の活用を検知することで、スケジュール、進捗、課題、コミュニケーション内容、成果物といった活動情報を蓄える。例えば、ここでウェブシステムは、プロジェクト管理を行うシステムであって、そのプロジェクト管理用のＷｅｂページでの操作をログ情報として検出、蓄積するようにしてもよい。
【００４２】
ステップＳ３１０では、現在のフェーズに応じて、リスクの顕在化ルールの判定を行い、「リスク有り」の場合はステップＳ３１２へ進み、「リスクなし」の場合は処理を終了する（ステップＳ３９９）。
例えば、テストフェーズであれば、顕在化ルール：「不具合発見率に減少傾向がない」の判定を行う。ここで、不具合発見率として、（不具合数／テスト数）を用いてもよい。例えば、テストフェーズ移行直後と現在（テストフェーズ中）とで、不具合発見率の減少率を求める。そして、テスト完了までにクライテリアの達成ができるか推定する。この推定として、予め定められた計算式に適用して、テスト完了までにクライテリアを達成できるか否かを判定してもよい。計算式として、過去の統計値を用いて定めたものであってもよいし、テストフェーズ移行直後と現在の不具合発見率で定まる一次式としてもよい。
また、既に顕在化したリスクに対しても、顕在化ルールの判定を行い、改善がみられるかモニタリングする。改善した場合、潜在化リスクから除外する。悪化した場合、ステップＳ３１２で用いる閾値を下げて、さらなる改善を提案するようにしてもよい。
【００４３】
ステップＳ３１２では、同一の顕在化リスクを持つ（又は、過去に持っていた）他のプロジェクトのうち、提案スコアが閾値以上であるか否かを判断し、「閾値以上である」である場合はステップＳ３１４へ進み、「閾値以上ではない」の場合は処理を終了する（ステップＳ３９９）。なお、同一の顕在化リスクとは、同じフェーズであって同じ規則を適用した場合にリスク有りと判定された場合が該当する。
ステップＳ３１４では、対象プロジェクトに対して、前ステップの他のプロジェクトをコラボレーションプロジェクトとして提案する。例えば、両方のプロジェクトのリーダーに通知するようにしてもよい。また、他のプロジェクトが活動中である場合、プロジェクト双方向の提案スコアを合計し、合計値が高くなる他のプロジェクトを選択することによって、お互いに恩恵にあずかれるプロジェクトをより高く評価するようにしてもよい。
【００４４】
図４は、本実施の形態による処理例を示すフローチャートである。図３の例に示したフローチャートのステップＳ３１２の具体的処理例を示すものである。つまり、提案スコアを異なるスキル数としたものである。
ステップＳ４０２では、対象プロジェクトのスキル情報テーブルを取得する。例えば、スキル情報テーブル５００を取得する。図５は、スキル情報テーブル５００のデータ構造例を示す説明図である。図５（ａ）は、対象としているプロジェクト（Ａ）におけるスキル情報テーブル５００Ａのデータ構造例を示す説明図である。スキル情報テーブル５００Ａは、スキル欄５１０Ａ、スキル評価値欄５２０Ａを有している。スキル欄５１０Ａは、スキルを記憶している。スキル評価値欄５２０Ａは、そのスキルにおける評価値（プロジェクト（Ａ）に参加しているユーザーのスキル評価値の平均値等）を記憶している。
【００４５】
ステップＳ４０４では、他のプロジェクトのスキル情報テーブルを取得する。例えば、他のプロジェクトのスキル情報テーブルとして、図５（ｂ）の例に示すようにプロジェクト（Ｂ）におけるスキル情報テーブル５００Ｂ、図５（ｃ）の例に示すようにプロジェクト（Ｃ）におけるスキル情報テーブル５００Ｃがある。スキル情報テーブル５００Ｂ、スキル情報テーブル５００Ｃは、スキル情報テーブル５００Ａと同等のデータ構造である。
なお、ここでの「他のプロジェクト」として、対象としているプロジェクトと同一の顕在化リスクを有していたが、その顕在化リスクを解決した他のプロジェクトとしてもよい。
また、「他のプロジェクト」として、対象としているプロジェクトのリスク有りと判定された項目とは異なる項目において、リスク有りと判定された他のプロジェクトとしてもよい。さらに、対象としているプロジェクトのリスク無しと判定された項目において、リスク有りと判定された他のプロジェクトとしてもよい。つまり、異なるリスクが発生した場合であって、お互いにそのノウハウを共有することで、双方でリスクの解決を図ることができるようになる。例えば、同一フェーズに対する活動傾向が異なることによって、発生するリスクが異なることがある。具体的には、設計フェーズにおいて、コミュニケーションが活発であるが成果物の量が少ないプロジェクト（プロジェクト（Ａ））と、それとは逆の傾向にあるプロジェクト（プロジェクト（Ｂ））では異なるリスクが存在する可能性が高く、お互いにそのノウハウを共有することで双方の潜在リスクの解決が見込まれる。プロジェクト（Ａ）では、「決定事項やその背景が見つからない」、「説明や情報展開のために多くの工数がかかる」ことによってリスクが発生しているが、プロジェクト（Ｂ）では、「売りとなる機能がない」、「販売が思わしくない」ことによってリスクが発生している場合、リスクが発生していない項目ではノウハウを提供できることになり、双方にメリットがある（いわゆるウィン−ウィンの関係）。
【００４６】
ステップＳ４０６では、両者間で異なるスキル項目の数を算出する。つまり、対象としているプロジェクト（Ａ）とは異なるスキルを保有しているプロジェクトを選択するためである。図５の例では、スキル情報テーブル５００Ｂは４行目の「Ｃ♯」が異なっているので「１」であり、スキル情報テーブル５００Ｃは１行目の「顧客志向」と２行目の「提案能力」が異なっているので「２」である。
【００４７】
ステップＳ４０８では、「異なるスキル項目数≧閾値Ａ」であるか否かを判断し、「異なるスキル項目数≧閾値Ａ」の場合はステップＳ４１０へ進み、それ以外の場合はステップＳ４１２へ進む。例えば、閾値Ａを「２」とした場合は、前述の例では、スキル情報テーブル５００ＣがステップＳ４０８の条件を満たしていることになる。つまり、プロジェクト（Ｃ）の方が提案スコアが高い。この場合、保有するスキルの異なるプロジェクトがコラボレーション相手となるプロジェクトとして有効であるとしており、異なる視点の意見がでることで、打開策につながるからである。
ステップＳ４１０では、コラボレーションプロジェクトリストに含める。前述の例では、プロジェクト（Ｃ）がコラボレーションプロジェクトリストに入れられることになる。
ステップＳ４１２では、比較するプロジェクトがあるか否かを判断し、ある場合はステップＳ４０４へ戻り、それ以外の場合は処理を終了する（ステップＳ４９９）。
【００４８】
図６は、本実施の形態による処理例を示すフローチャートである。図３の例に示したフローチャートのステップＳ３１２の具体的処理例を示すものである。つまり、図４の例に示したフローチャートの別の処理例を示すものである。ステップＳ６０６、ステップＳ６０８以外の処理は、図４の例に示したフローチャートと同等の処理である。
ステップＳ６０２では、対象プロジェクトのスキル情報テーブルを取得する。
ステップＳ６０４では、他のプロジェクトのスキル情報テーブルを取得する。
【００４９】
ステップＳ６０６では、両者間で同じスキル項目であって、対象プロジェクトの方がスキル評価値が高いスキル項目数を算出する。この算出したスキル項目数を、図４の例での提案スコアとしている。
ステップＳ６０８では、「前ステップで算出したスキル項目数≧閾値Ｂ」であるか否かを判断し、「前ステップで算出したスキル項目数≧閾値Ｂ」の場合はステップＳ６１０へ進み、それ以外の場合はステップＳ６１２へ進む。
【００５０】
ステップＳ６１０では、コラボレーションプロジェクトリストに含める。つまり、スキル評価値が低いにもかかわらず、リスクを解決したプロジェクトであるので、リスクを解決するためのノウハウを有している可能性が高いためである。
ステップＳ６１２では、比較するプロジェクトがあるか否かを判断し、ある場合はステップＳ６０４へ戻り、それ以外の場合は処理を終了する（ステップＳ６９９）。
【００５１】
図７は、本実施の形態による処理例を示すフローチャートである。図３の例に示したフローチャートのステップＳ３１２の具体的処理例を示すものである。つまり、図４の例に示したフローチャートの別の処理例を示すものである。ステップＳ７０６、ステップＳ７０８以外の処理は、図４の例に示したフローチャートと同等の処理である。
ステップＳ７０２では、対象プロジェクトのスキル情報テーブルを取得する。
ステップＳ７０４では、他のプロジェクトのスキル情報テーブルを取得する。
【００５２】
ステップＳ７０６では、両者間で同じスキル項目であって、（対象プロジェクトの方がスキル評価値が高いスキル項目数）／（対象プロジェクトの方がスキル評価値が低いスキル項目数）の値を算出する。この算出した値を、図４の例での提案スコアとしている。
ステップＳ７０８では、「前ステップで算出した比率≧閾値Ｃ」であるか否かを判断し、「前ステップで算出した比率≧閾値Ｃ」の場合はステップＳ７１０へ進み、それ以外の場合はステップＳ７１２へ進む。
【００５３】
ステップＳ７１０では、コラボレーションプロジェクトリストに含める。
ステップＳ７１２では、比較するプロジェクトがあるか否かを判断し、ある場合はステップＳ７０４へ戻り、それ以外の場合は処理を終了する（ステップＳ７９９）。
【００５４】
図８は、本実施の形態による処理例を示すフローチャートである。図３の例に示したフローチャートのステップＳ３１２の具体的処理例を示すものである。
ステップＳ８０２では、対象プロジェクトのリスクを抽出する。
ステップＳ８０４では、納期に目標を達成できた他のプロジェクトの過去のリスクを抽出する。
なお、ここでの「他のプロジェクト」として、対象としているプロジェクトのリスク有りと判定された項目とは異なる項目において、リスク有りと判定された他のプロジェクトとしてもよい。さらに、対象としているプロジェクトのリスク無しと判定された項目において、リスク有りと判定された他のプロジェクトとしてもよい。つまり、異なるリスクが発生した場合であって、お互いにそのノウハウを共有することで、双方でリスクの解決を図ることができるようになる。図４の例に示したフローチャート内のステップＳ４０４と同様の理由である。
【００５５】
ステップＳ８０６では、対象プロジェクトと同じリスクを抽出できたか否かを判断し、抽出できた場合はステップＳ８０８へ進み、それ以外の場合はステップＳ８１２へ進む。
ステップＳ８０８では、リスク発生は、スケジュール上、同じ時期であるか否かを判断し、同じ時期の場合はステップＳ８１０へ進み、それ以外の場合はステップＳ８１２へ進む。ここで「同じ時期」として、単にフェーズが同じであることとしてもよいし、フェーズが同じであって、さらに、そのフェーズ内での経過割合（具体的には、そのフェーズ内での経過日数／そのフェーズの期間）が類似していることとしてもよい。なお、ここでの類似とは、両者の経過割合の差が予め定められた値以内であることである。
【００５６】
ステップＳ８１０では、コラボレーションプロジェクトリストに含める。
ステップＳ８１２では、比較するプロジェクトがあるか否かを判断し、ある場合はステップＳ８０４へ戻り、それ以外の場合は処理を終了する（ステップＳ８９９）。
【００５７】
図９は、本実施の形態による処理例を示す説明図である。
図９（ａ）の例に示す不具合発見率グラフ９００Ａは、対象としているプロジェクト（Ａ）の時間経過と不具合発見率の関係を示したグラフである。
不具合発見率推移９１０Ａから、納期９３０Ａまでに不具合発見率が十分に低下しない可能性が高いので、現在９２０Ａの時点で、リスク有りと判定されたものである。
なお、リスク有りか否かは、予測目標達成日数に対し閾値を設定することで判定し、以下の算出式を用いる。
不具合発見率＝不具合数／テストケース数
不具合発見率の平均削減ポイント＝（現在の不具合発見率−目標とする不具合発見率）／経過日数
予測目標達成日数＝経過日数＋（現在の不具合発見率−目標とする不具合発見率）／不具合発見率の平均削減ポイント
そして、「予測目標達成日数が納期９３０Ａを超える」場合がリスク有りと判定する。
また、不具合発見率が安定するまでの期間は、リスクの顕在化の判定処理は行わないようにしてもよい。例えば、３か月かかるテストに対して初日の計測結果で提案するのではなく、２週間、１か月程度猶予期間を設けるようにすればよい。
【００５８】
図９（ｂ）の例に示す不具合発見率グラフ９００Ｂはプロジェクト（Ｂ）におけるものであり、図９（ｃ）の例に示す不具合発見率グラフ９００Ｃはプロジェクト（Ｃ）におけるものである。
プロジェクト（Ｃ）の方がプロジェクト（Ｂ）よりも提案スコアが高くなるようにする。つまり、顕在化したリスクに対し、適切に対応できたと推測でき、解決のためのノウハウ提供が期待できるからである。
提案スコアが閾値以上であるものを提案してもよい。さらに、提案スコアが最も高いプロジェクトを提案するようにしてもよい。
提案スコアは、リスクが顕在化から納期までの「不具合発見率の平均削減ポイント」を用いて求める。以下の算出式を用いる。
不具合発見率の平均削減ポイント＝（リスク顕在化時の不具合発見率−納期時の不具合発見率）／リスク顕在化から納期までの経過日数
ただし、以下の条件を満たすプロジェクトのみに限定する。
・納期に目標を達成できている。
・リスクの顕在化が発生している。
【００５９】
図８の例に示したフローチャートの処理を行うために、プロジェクト管理テーブル１０００を用いるようにしてもよい。
図１０は、プロジェクト管理テーブル１０００のデータ構造例を示す説明図である。プロジェクト管理テーブル１０００は、プロジェクトＩＤ欄１０１０、スケジュール欄１０２０、目標欄１０３０、目標達成フラグ１０４０、リスク種別欄１０５０、リスク発生日時欄１０６０、リスク要因項目欄１０７０を有しており、スケジュール欄１０２０は、開始日時欄１０２２、納期日時１０２４を有しており、リスク要因項目欄１０７０は、不具合発見率欄１０７２等を有している。プロジェクトＩＤ欄１０１０は、本実施の形態において、プロジェクトを一意に識別するための情報（プロジェクトＩＤ：ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）を記憶している。スケジュール欄１０２０は、そのプロジェクトのスケジュールを記憶している。開始日時欄１０２２は、そのプロジェクトの開始日時を記憶している。納期日時１０２４は、そのプロジェクトの納期日時を記憶している。なお、開始日時欄１０２２、納期日時１０２４は、活動フェーズ毎に用意されていてもよい。目標欄１０３０は、目標を記憶している。例えば、納期までに完了していること等がある。目標達成フラグ１０４０は、目標を達成したか否かを示す情報（フラグ）を記憶している。リスク種別欄１０５０は、そのプロジェクトで発生したリスク種別（そのリスクを判定したルールとしてもよい）を記憶している。リスク発生日時欄１０６０は、そのリスクの発生日時を記憶している。リスク要因項目欄１０７０は、そのリスク要因項目を記憶している。不具合発見率欄１０７２は、不具合発見率を記憶している。
【００６０】
図１１は、本実施の形態による処理例を示すフローチャートである。図３の例に示したフローチャートのステップＳ３１４の具体的処理例を示すものである。つまり、提案するプロジェクト内のメンバーの誰を紹介するかを決定するアルゴリズム例である。
ステップＳ１１０２では、対象プロジェクトのメンバーを抽出する。例えば、プロジェクト管理テーブル１２００から抽出する。図１２は、プロジェクト管理テーブル１２００のデータ構造例を示す説明図である。プロジェクト管理テーブル１２００は、ユーザーＩＤ欄１２１０、プロジェクト数欄１２２０、プロジェクトＩＤ欄１２３０、役職欄１２４０、担当フェーズ欄１２５０を有している。ユーザーＩＤ欄１２１０は、本実施の形態において、ユーザーを一意に識別するための情報（ユーザーＩＤ）を記憶している。プロジェクト数欄１２２０は、そのユーザーが参加しているプロジェクト数を記憶している。プロジェクト数欄１２２０内の数だけ、その後にプロジェクトＩＤ欄１２３０と役職欄１２４０の組み合わせが続く。プロジェクトＩＤ欄１２３０は、プロジェクトＩＤを記憶している。役職欄１２４０は、プロジェクトにおいて、そのユーザーが有しているリーダー、一般メンバー等のプロジェクト内の役割（役職）を記憶している。担当フェーズ欄１２５０は、そのユーザーが担当しているフェーズを記憶している。
【００６１】
ステップＳ１１０４では、提案するプロジェクトのメンバーを抽出する。同様に、プロジェクト管理テーブル１２００から抽出すればよい。
ステップＳ１１０６では、対象プロジェクトのメンバーと、提案するプロジェクトのメンバーとに、同じメンバーがいるか否かを判断し、いる場合はステップＳ１１０８へ進み、それ以外の場合はステップＳ１１１０へ進む。
ステップＳ１１０８では、対象プロジェクトのリスクに関わっているか否かを判断し、関わっている場合はステップＳ１１１０へ進み、それ以外の場合はステップＳ１１１２へ進む。具体的には、プロジェクト管理テーブル１２００の担当フェーズ欄１２５０を参照し、リスクが発生している（発生した）フェーズに該当するか否かで判断できる。
ステップＳ１１１０では、提案するプロジェクトのリーダーを紹介する。
ステップＳ１１１２では、そのメンバー（ステップＳ１１０６で同じメンバーと判断されたメンバー）を紹介する。
【００６２】
なお、プロジェクト双方向の提案スコアを合計して、合計値が高くなる他のプロジェクトを選択する場合の他のプロジェクトの提案スコアを算出するには、前述した提案スコアの算出におけるプロジェクトの関係を逆にすればよい。つまり、「対象とするプロジェクト」を「他のプロジェクト」として、「他のプロジェクト」を「対象とするプロジェクト」として提案スコアを算出すればよい。
【００６３】
なお、本実施の形態としてのプログラムが実行されるコンピュータのハードウェア構成は、図１３に例示するように、一般的なコンピュータであり、具体的にはパーソナルコンピュータ、サーバーとなり得るコンピュータ等である。つまり、具体例として、処理部（演算部）としてＣＰＵ１３０１を用い、記憶装置としてＲＡＭ１３０２、ＲＯＭ１３０３、ＨＤ１３０４を用いている。ＨＤ１３０４として、例えば、ハードディスク、フラッシュ・メモリであるＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等を用いてもよい。取得（Ａ）モジュール１０５、取得（Ｂ）モジュール１１０、リスク判定モジュール１１５、通知モジュール１２０、提案処理モジュール１２５等のプログラムを実行するＣＰＵ１３０１と、そのプログラムやデータを記憶するＲＡＭ１３０２と、本コンピュータを起動するためのプログラム等が格納されているＲＯＭ１３０３と、スキル情報テーブル５００、プロジェクト管理テーブル１０００、プロジェクト管理テーブル１２００等を記憶する補助記憶装置であるＨＤ１３０４と、キーボード、マウス、タッチスクリーン、マイク、カメラ（視線検知カメラ等を含む）等に対する利用者の操作（動作、音声、視線等を含む）に基づいてデータを受け付ける受付装置１３０６と、ＣＲＴ、液晶ディスプレイ、スピーカー等の出力装置１３０５と、ネットワークインタフェースカード等の通信ネットワークと接続するための通信回線インタフェース１３０７、そして、それらをつないでデータのやり取りをするためのバス１３０８により構成されている。これらのコンピュータが複数台互いにネットワークによって接続されていてもよい。
【００６４】
前述の実施の形態のうち、コンピュータ・プログラムによるものについては、本ハードウェア構成のシステムにソフトウェアであるコンピュータ・プログラムを読み込ませ、ソフトウェアとハードウェア資源とが協働して、前述の実施の形態が実現される。
なお、図１３に示すハードウェア構成は、１つの構成例を示すものであり、本実施の形態は、図１３に示す構成に限らず、本実施の形態において説明したモジュールを実行可能な構成であればよい。例えば、一部のモジュールを専用のハードウェア（例えば特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ：ＡＳＩＣ）等）で構成してもよく、一部のモジュールは外部のシステム内にあり通信回線で接続している形態でもよく、さらに図１３に示すシステムが複数互いに通信回線によって接続されていて互いに協調動作するようにしてもよい。また、特に、パーソナルコンピュータの他、携帯情報通信機器（携帯電話、スマートフォン、モバイル機器、ウェアラブルコンピュータ等を含む）、情報家電、ロボット、複写機、ファックス、スキャナ、プリンタ、複合機（スキャナ、プリンタ、複写機、ファックス等のいずれか２つ以上の機能を有している画像処理装置）などに組み込まれていてもよい。
【００６５】
なお、説明したプログラムについては、記録媒体に格納して提供してもよく、また、そのプログラムを通信手段によって提供してもよい。その場合、例えば、前記説明したプログラムについて、「プログラムを記録したコンピュータ読み取り可能な記録媒体」の発明として捉えてもよい。
「プログラムを記録したコンピュータ読み取り可能な記録媒体」とは、プログラムのインストール、実行、プログラムの流通等のために用いられる、プログラムが記録されたコンピュータで読み取り可能な記録媒体をいう。
なお、記録媒体としては、例えば、デジタル・バーサタイル・ディスク（ＤＶＤ）であって、ＤＶＤフォーラムで策定された規格である「ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ−ＲＡＭ等」、ＤＶＤ＋ＲＷで策定された規格である「ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等」、コンパクトディスク（ＣＤ）であって、読出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）等、ブルーレイ・ディスク（Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃ）、光磁気ディスク（ＭＯ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読出し専用メモリ（ＲＯＭ）、電気的消去及び書換可能な読出し専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ＳＤ（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ）メモリーカード等が含まれる。
そして、前記のプログラムの全体又はその一部は、前記記録媒体に記録して保存や流通等させてもよい。また、通信によって、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等に用いられる有線ネットワーク、又は無線通信ネットワーク、さらにこれらの組み合わせ等の伝送媒体を用いて伝送させてもよく、また、搬送波に乗せて搬送させてもよい。
さらに、前記のプログラムは、他のプログラムの一部分若しくは全部であってもよく、又は別個のプログラムと共に記録媒体に記録されていてもよい。また、複数の記録媒体に分割して記録されていてもよい。また、圧縮や暗号化等、復元可能であればどのような態様で記録されていてもよい。
【符号の説明】
【００６６】
１００…情報処理装置
１０５…取得（Ａ）モジュール
１１０…取得（Ｂ）モジュール
１１５…リスク判定モジュール
１２０…通知モジュール
１２５…提案処理モジュール
１５０…プロジェクト管理装置
１５５…プロジェクト活動情報記憶モジュール
１７０Ａ…プロジェクト（Ａ）担当ユーザー端末
２１０…プロジェクト
２５０…全プロジェクト管理装置
２５５…プロジェクトフェーズ情報記憶モジュール
２６０…リスク顕在化ルール記憶モジュール
２６５…顕在化リスク一覧記憶モジュール
２７０…ユーザー端末
２９０…通信回線
【図１】
2020034963.tif 000003
【図２】
2020034963.tif 000004
【図３】
2020034963.tif 000005
【図４】
2020034963.tif 000006
【図５】
2020034963.tif 000007
【図６】
2020034963.tif 000008
【図７】
2020034963.tif 000009
【図８】
2020034963.tif 000010
【図９】
2020034963.tif 000011
【図１０】
2020034963.tif 000012
【図１１】
2020034963.tif 000013
【図１２】
2020034963.tif 000014
【図１３】
2020034963.tif 000015