プロジェクトにおける人材選定支援管理システムおよび人材選定支援管理方法、ならびにそのためのプログラム
【課題】プロジェクト経過中にチームの体制を随時見直して修正することが可能な、チーム内およびチーム間を意識した人間関係を考慮して安定した体制で運営可能な人材選定支援管理技術の提供。
【解決手段】プロジェクト人材選定支援管理システム（サーバ）１における処理部１Ａは、プロジェクト候補者検索処理手段１Ａ０１、プロジェクト候補者登録処理手段１Ａ０２、プロジェクトフォロー対象者検索処理手段１Ａ０３、プロジェクト退場者登録処理手段１Ａ０４、プロジェクトメンバ評価登録処理手段１Ａ０５および個人要望登録処理手段１Ａ０６からなる処理部１Ａとデータ部１Ｂを有し、プロジェクト進行中にメンバの勤務状況，進捗状況，第三者の評価情報，トメンバ個人の異動要望に関する情報を随時あるいは定期的に収集し、チーム維持の阻害要因を判定し該阻害要因となる情報を持つメンバ情報を退場候補者とし、該退場候補者から退場者を選択する。
【解決手段】プロジェクト人材選定支援管理システム（サーバ）１における処理部１Ａは、プロジェクト候補者検索処理手段１Ａ０１、プロジェクト候補者登録処理手段１Ａ０２、プロジェクトフォロー対象者検索処理手段１Ａ０３、プロジェクト退場者登録処理手段１Ａ０４、プロジェクトメンバ評価登録処理手段１Ａ０５および個人要望登録処理手段１Ａ０６からなる処理部１Ａとデータ部１Ｂを有し、プロジェクト進行中にメンバの勤務状況，進捗状況，第三者の評価情報，トメンバ個人の異動要望に関する情報を随時あるいは定期的に収集し、チーム維持の阻害要因を判定し該阻害要因となる情報を持つメンバ情報を退場候補者とし、該退場候補者から退場者を選択する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、作業プロジェクトチームを形成する際の人材選定支援技術に係り、特に、安定した作業プロジェクトチームを形成するために、プロジェクト進行中であっても、チーム内およびチーム間における人間関係も考慮し、最適な人材の選定を行うことが可能な人材選定支援管理システム、人材選定支援管理方法、およびそのためのプログラムに関する。
【背景技術】
【０００２】
近年、技術進歩が進みプロジェクトも大型化する傾向にあり、共通のプロジェクトを複数のメンバが協働して遂行することが多くなっている。職場で能力を発揮できるか否かは、職場の環境、雰囲気、人間関係またはモチベーションなど、精神面に依存するところが大きい。
【０００３】
例えば、プロジェクトチームのメンバ個人でみた場合、個人の技術、能力がいくら優れていても、周囲との人間関係が悪いと大きなストレスになり、仕事の能率も下がり、最悪な場合は精神的に病んで会社へ出社できなくなってしまうケースもある。
【０００４】
また、プロジェクトチーム全体でみた場合、人間関係が悪い者同士を同じチームメンバにしてしまうと、メンバ間のコミュニケーションが円滑に行われず、プロジェクト作業に支障が生じてチームとしてのパフォーマンスが十分発揮できないようになり、その結果、プロジェクト全体の進捗に大きく影響しかねない。
【０００５】
また、チーム内としては人間関係がいくら良好であっても、チーム相互間においてキーマン（例えば、プロジェクトマネージャーやプロジェクトリーダ）同士の人間関係が良好でない場合はプロジェクトとしての機能が低下してしまう。
【０００６】
このような背景の中、チーム形成時の条件として、個人のスキルや実績だけではなく、人間関係も考慮対象の要素に含めた技術開発が進められており、例えば、特開２００１−２８２９６５号公報（特許文献１）、特開２００７−２６４０４号公報（特許文献２）、特開２００７−１２２１４４号公報（特許文献３）などが先行技術文献としてあげられる。
【０００７】
特許文献１では、プロジェクトチームメンバ、チーム生成手法として、メンバのスキルと経験情報以外に人間関係に関する情報も考慮した手法を提供しており、特に、人間関係においてはプロジェクトメンバ間の評価に着目し、他のメンバに対する相互評価を取得して登録する手法とチーム生成時に前記登録された相互評価情報を提供する手法について開示されている。
【０００８】
特許文献２では、プロジェクトチームメンバ、チーム生成手法として、過去のプロジェクトデータからプロジェクトに適合したメンバを効率的に決定するための手法について開示されている。プロジェクトに適合する要件として、他のメンバから実績評価情報（アンケート形式で品質評価項目としてスキル、プロジェクトに対する経験、情報の共有度、品質の維持、運用／保守性などの観点に基づいた回答情報）や個人情報（過去の経験プロジェクト情報、コスト（給料）、資格や既知の性格分析など）から決定している。
【０００９】
特許文献３では、プロジェクトチームメンバ、チーム生成手法として、過去のプロジェクトに対する評価とそのプロジェクトを担当したプロジェクトチームのチークとしての能力（チームを構成するメンバの能力により算出）との相関を計算し、その相関に基づいてプロジェクトに対する評価を高めるようなチームとチームとしての能力特性値を実現するようにメンバの選定を行うようにしている。評価を高めるための要因として、過去のプロジェクト実績から担当するチームとしての能力やメンバ間の相性における成功要因情報を考慮している。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００１−２８２９６５号公報
【特許文献２】特開２００７−２６４０４号公報
【特許文献３】特開２００７−１２２１４４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
プロジェクト開始当初から選出されたメンバが、プロジェクトが完了するまでの間に何も問題なく最適な状態で各チームが維持できることは難しい。通常、プロジェクト進行中にメンバ自身、メンバ構成（プロジェクトチーム体制）に問題があれば、その都度、プロジェクトマネージャーやプロジェクトリーダにあたるメンバが該当者をフォローしたり、必要があれば体制を見直して補強したり再編成したり軌道修正しながらプロジェクトを進める必要があると考えられる。
【００１２】
しかしながら、上記背景技術に提示した特許文献に記載されたものは、最初のプロジェクトチーム形成時のメンバ選定に関するものであり、上記の如き観点から、メンバ自身、プロジェクトチーム（メンバ構成）選定後のプロジェクト経過中にプロジェクトチームの体制を随時見直して軌道修正することについては明記されていない。
【００１３】
また、プロジェクトチームとしてのパフォーマンスを高める手段として、チーム内における人間関係が考慮されているのは見受けられるが、チーム間を意識した人間関係についての考慮は全く見受けられない。
【００１４】
以上のことから明らかなように、従来、メンバ選定における要件として上記背景技術にあるようにメンバの実績、能力、第三者からの評価などから分析するケースがほとんどであり、プロジェクト経過中において、メンバの自分自身における要望および希望事項についてもプロジェクト退場となる大きな要因となれば、これらの要望や希望事項も人材選定条件のひとつとして考慮する必要があると考えられるが、プロジェクト経過中に、状況に応じたメンバ選定をはじめメンバ選定のきっかけとなる情報を検知することは行われていなかった。また、チーム間の関係を考慮した人材選定方法についても検討されていなかった。
【００１５】
そこで、本発明は、メンバ自身、プロジェクトチーム（メンバ構成）選定後のプロジェクト経過中におけるプロジェクトチームの体制を随時見直して軌道修正することが可能な、また、プロジェクトチームとしてのパフォーマンスを高める手段として、チーム内における人間関係に加えて、チーム間を意識した人間関係についても考慮することによって安定した体制で運営可能な人材選定支援管理システムおよび人材選定支援管理方法、ならびにそのためのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明は、上記目的を達成するための手段として、プロジェクト開始から終了まで安定したチームを維持するために、その阻害要因となる情報を随時あるいは定期的にバッチ処理で各プロジェクトメンバの勤務状況（欠勤、年休、超勤時間）、作業進捗状況（遅延日数）、他のメンバからの評価（例えば、５段階評価）情報およびプロジェクトメンバ自身の要望（異動希望、人間関係）から収集し、それらの情報から阻害要因となる基準を決め、基準から外れるプロジェクトメンバ情報を判定し抽出する。
【００１７】
抽出されたプロジェクトメンバ情報は、まず対象者の有無を知らせるメールを管理者（プロジェクトマネージャー等）たるメンバに配信することで日々状況を把握することができる。また、抽出されたメンバ一覧や詳細内容を参照できる画面を用意し、内容によってフォローし、さらに退場者とする場合の登録機能も提供する。
【００１８】
これにより、随時あるいは定期的にプロジェクトメンバの状況を把握することができるため、早期対策を打つことが可能になる。また、メンバの入れ替えについても、プロジェクト進行中であってもシステムにて支援する機能を備えているため、管理者側の負担軽減につながる。
【００１９】
また、本発明においては、安定したチームを維持するために、もうひとつのアプローチとしてチーム間においても人間関係に配慮したチーム生成機能を提供する。チーム間における人間関係の配慮方法として、互いのチームリーダにあたるメンバ同士が最適な関係になるように配慮する。
【００２０】
これにより、権限のあるチームリーダ同士のコミュニケーションが良好であれば、チーム間の連携も円滑化につながり、プロジェクトとしても安定した運用を築くことが可能になる。
【００２１】
さらに、本発明においては、上記機能に付け加え、プロジェクト進行期間中に以下の機能を実現できることも特徴としている。
（ａ）プロジェクトメンバ自身が仕事内容や人間関係について要望、希望事項があればいつでも登録することができる。
（ｂ）プロジェクトメンバの退場が必要になった場合、退場者の候補となったメンバについてワークフローの機能を使って適正な手順と判定を機械的に運用することができる。
（ｃ）プロジェクトメンバの増員が必要となった場合に既存のチームに新たなメンバを追加する機能やチーム単位で新しくメンバを追加する機能に、チームとメンバの人間関係に配慮した最適なメンバ候補を抽出することができ、退場者を決定する機能と同様にワークフローの機能も兼ね備え、適正な手順と判定を機械的に運用することができる。
【００２２】
より具体的には、
ａ）本発明に係るプロジェクト人材選定支援管理システムは、安定したプロジェクトチームを維持するためのプロジェクト人材選定支援管理システムであって、プロジェクト進行期間中に各プロジェクトメンバの勤務状況，作業進捗状況，第三者からの評価情報およびプロジェクトメンバ個人の異動要望に関する情報を随時あるいは定期的に収集する収集手段と、該収集手段により収集された情報に基づいて安定したプロジェクトチームの維持の阻害要因となる情報を判定し、該該阻害要因となる情報を持つメンバ情報を退場候補者として抽出し退場者を選定する権限を有する管理者に提供するメンバ情報提供手段と、該退場候補者に基づいて退場者を選択して登録する手段、を有することを特徴とする。
【００２３】
ｂ）また、上記ａ）において、プロジェクト進行期間中、随時あるいは定期的に、プロジェクトメンバ自身が仕事量，勤務時間，仕事内容，人間関係，あるいは異動希望に関する要望事項を登録する手段を有することを特徴とする。
【００２４】
ｃ）また、上記ａ）またはｂ）において、プロジェクト進行期間中にプロジェクトからプロジェクトメンバの退場が必要になった場合に前記退場候補者を退場者として登録する手段と、該退場者を他のプロジェクトメンバ候補対象者として登録する手段を有することを特徴とする。
【００２５】
ｄ）上記ａ）からｃ）いずれかにおいて、プロジェクト進行期間中にメンバの増員が必要となった場合に、既存のチームに新たなメンバを追加する手段とチーム単位で新しくメンバを追加する手段に加え、チームとメンバの人間関係について最適なメンバ候補を提供する手段を有することを特徴とする。
【００２６】
ｅ）上記ａ）からｄ）のいずれかにおいて、プロジェクトメンバを選定する場合、メンバの過去実績、スキル、およびコストを含むメンバ自身の能力に加え、チーム内におけるメンバ間の人間関係およびチーム間における人間関係を考慮して最適なメンバおよびチーム構成を選定する手段を有することを特徴とする。
【００２７】
ｆ）本発明に係るプログラムは、コンピュータを、上記ａ）からｅ）のいずれかに記載のプロジェクト人材選定支援管理システムにおける各手段として機能させることを特徴とするプログラムである。
【００２８】
ｇ）本発明に係るプロジェクト人材選定支援管理方法は、安定したプロジェクトチームを維持するためのコンピュータを用いたプロジェクト人材選定支援管理方法であって、プロジェクト進行期間中に各プロジェクトメンバの勤務状況，作業進捗状況，第三者からの評価情報およびプロジェクトメンバ個人の異動要望に関する情報を随時あるいは定期的に収集する収集ステップと、該収集ステップにより収集された情報に基づいて安定したプロジェクトチームの維持の阻害要因となる情報を判定し、該該阻害要因となる情報を持つメンバ情報を退場候補者として抽出し退場者を選定する権限を有する管理者に提供するメンバ情報提供ステップと、該退場候補者に基づいて退場者を選択して登録するステップと、を有することを特徴とする。
【００２９】
ｈ）上記ｇ）において、プロジェクト進行期間中、随時あるいは定期的に、プロジェクトメンバ自身が仕事量，勤務時間，仕事内容，人間関係，あるいは異動希望に関する要望事項を登録するステップを有することを特徴とする。
【００３０】
ｉ）上記ｇ）またはｈ）において、プロジェクト進行期間中にプロジェクトからプロジェクトメンバの退場が必要になった場合に前記退場候補者を退場者として登録するステップと、該退場者を他のプロジェクトメンバ候補対象者として登録するステップを有することを特徴とする。
【００３１】
ｊ）上記ｇ）からｉ）のいずれかにおいて、プロジェクト進行期間中にメンバの増員が必要となった場合に、既存のチームに新たなメンバを追加するステップとチーム単位で新しくメンバを追加するステップに加え、チームとメンバの人間関係について最適なメンバ候補を提供するステップを有することを特徴とする。
【００３２】
ｋ）上記ｇ）からｊ）のいずれかにおいて、プロジェクトメンバを選定する場合、メンバの過去実績、スキル、およびコストを含むメンバ自身の能力に加え、チーム内におけるメンバ間の人間関係およびチーム間における人間関係を考慮して最適なメンバおよびチーム構成を選定するステップを有することを特徴とする。
【発明の効果】
【００３３】
上記構成を採用することにより、プロジェクト開始から完了までのプロジェクト進行の全期間を通じて、メンバ自身、メンバ間に問題があれば、随時あるいは定期的に、例えば日々決まった時間に問題に関する情報を自動的に収集し、日々状況を確認することができる。
【００３４】
また、一個人の要望事項も日々収集が可能なので、問題があれば、早期対策を打つことができる。また、状況に応じて、随時、選定時点における最適なメンバ選定も可能になる。
【００３５】
このように、本発明は、上記構成を採用したことによって、プロジェクト経過中におけるプロジェクトチームの体制を随時見直して軌道修正することが可能な、また、チーム内における人間関係に加えて、チーム間を意識した人間関係についても考慮した、プロジェクトチームとしてのパフォーマンスの高い安定した体制で運営可能な人材選定支援管理システムおよび人材選定支援管理方法、ならびにそのためのプログラムを実現できる。
【図面の簡単な説明】
【００３６】
【図１】本発明に係るプロジェクト人材選定支援および人材管理システム（人材選定支援管理システム）の全体構成図である。
【図２．１】図１におけるプロジェクト候補者検索処理手段の処理動作例を示すフローチャートである。
【図２．２】図１におけるプロジェクト候補者登録処理手段の処理動作例を示すフローチャートである。
【図２．３】図１におけるプロジェクトフォロー対象者検索処理手段の処理動作例を示すフローチャートである。
【図２．４】図１におけるプロジェクト退場者登録処理手段の処理動作例を示すフローチャートである。
【図２．５】図１におけるプロジェクトメンバ評価登録処理手段の処理動作例を示すフローチャートである。
【図２．６】図１における個人要望事項登録処理手段の処理動作例を示すフローチャートである。
【図３】図１における画面遷移図である。
【図４．１】図１におけるプロジェクト候補者検索処理手段で用いられるプロジェクト候補者検索画面の画面レイアウトの一例を示す図である。
【図４．２】図１におけるプロジェクトフォロー対象者検索処理手段で用いられるプロジェクトフォロー対象者検索画面の画面レイアウトの一例を示す図である。
【図４．３】図１におけるプロジェクトメンバ評価登録処理手段で用いられるプロジェクトメンバ評価登録画面の画面レイアウトの一例を示す図である。
【図４．４】図１における個人要望登録処理手段で用いられる個人要望登録画面の画面レイアウトの一例を示す図である。
【図５．１】図１におけるコードマスタのＤＢ構成例である。
【図５．２】図１における認証テーブルのＤＢ構成例である。
【図５．３】図１における社員テーブルのＤＢ構成例である。
【図５．４】図１における組織マスタのＤＢ構成例である。
【図５．５】図１における勤務表テーブルのＤＢ構成例である。
【図５．６】図１における年休テーブルのＤＢ構成例である。
【図５．７】図１におけるスキルテーブルのＤＢ構成例である。
【図５．８】図１における実績テーブルのＤＢ構成例である。
【図５．９】図１におけるプロジェクトテーブルのＤＢ構成例である。
【図５．１０】図１におけるグループテーブルのＤＢ構成例である。
【図５．１１】図１におけるメンバテーブルのＤＢ構成例である。
【図５．１２】図１における進捗表テーブルのＤＢ構成例である。
【図５．１３】図１におけるフォローテーブルのＤＢ構成例である。
【図５．１４】図１における評価テーブルのＤＢ構成例である。
【図５．１５】図１における要望テーブルのＤＢ構成例である。
【図５．１６】図１における要望詳細テーブルのＤＢ構成例である。
【図５．１７】図１における申請テーブルのＤＢ構成例である。
【発明を実施するための形態】
【００３７】
（実施例）
以下、本発明の一実施例を、図面を用いて詳細を説明する。
図１は、本発明に係るプロジェクト人材選定支援および人材管理システム（本発明においては単に「プロジェクト人材選定支援管理システム」ともいう）となるサーバ１の全体構成図を示している。同図において、該サーバ１はネットワーク（インターネット）２を介して操作端末３と接続されており、相互に通信可能になっている。
【００３８】
同図に示すように、本発明に係るプロジェクト人材選定支援管理システム（サーバ）１は、大きく分けて、処理部１Ａと、該処理部１Ａで使用されるデータを保持するデータ部１Ｂと、から構成される。
【００３９】
処理部１Ａは、プロジェクト候補者検索処理手段１Ａ０１、プロジェクト候補者登録処理手段１Ａ０２、プロジェクトフォロー対象者検索処理手段１Ａ０３、プロジェクト退場者登録処理手段１Ａ０４、プロジェクトメンバ評価登録処理手段１Ａ０５および個人要望登録処理手段１Ａ０６の６つの処理手段を有している。
【００４０】
データ部１Ｂは、上記６つの処理手段によりアクセス可能なデータを保持するものであり、同図に示すように、コードマスタ１Ｂ０１、認証テーブル１Ｂ０２、社員テーブル１Ｂ０３、組織マスタ１Ｂ０４、勤務表テーブル１Ｂ０５、年休テーブル１Ｂ０６、スキルテーブル１Ｂ０７、実績テーブル１Ｂ０８、プロジェクトテーブル１Ｂ０９、グループテーブル１Ｂ１０、メンバテーブル１Ｂ１１、進捗表テーブル１Ｂ１２、フォローテーブル１Ｂ１３、評価テーブル１Ｂ１４、要望テーブル１Ｂ１５、要望詳細テーブル１Ｂ１６および申請テーブル１Ｂ１７を有している。
【００４１】
次に、コードマスタ１Ｂ０１、認証テーブル１Ｂ０２、社員テーブル１Ｂ０３、組織マスタ１Ｂ０４、勤務表テーブル１Ｂ０５、年休テーブル１Ｂ０６、スキルテーブル１Ｂ０７、実績テーブル１Ｂ０８、プロジェクトテーブル１Ｂ０９、グループテーブル１Ｂ１０、メンバテーブル１Ｂ１１、進捗表テーブル１Ｂ１２、フォローテーブル１Ｂ１３、評価テーブル１Ｂ１４、要望テーブル１Ｂ１５、要望詳細テーブル１Ｂ１６および申請テーブル１Ｂ１７の、それぞれの具体例を、図５．１〜図５．１７を用いて詳細に説明する。
【００４２】
図５．１は、コードマスタ１Ｂ０１の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００４３】
コードマスタ１Ｂ０１は、プロジェクト人材選定および人材管理システムで管理するコードをユニークに識別する為のＩＤを示す「コード」、コードの名称を示す「コード名」、当該コードＩＤに属するコード値１を示す「コード値１」、当該コードＩＤに属するコード値２を示す「コード値２」（必要に応じて使用）、画面に表示する順番を示す「順番」、コードＩＤとコード値１（コード値２）の組み合わせに対するコードの内容１を示す「内容１」、コードＩＤとコード値１（コード値２）の組み合わせに対するコードの内容２を示す「内容２」、コードＩＤとコード値１（コード値２）の組み合わせに対するコードの内容３を示す「内容３」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００４４】
図５．２は、認証テーブル１Ｂ０２の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００４５】
認証テーブル１Ｂ０２は、プロジェクト人材選定および人材管理システムにログインする際のユーザＩＤを示す「ユーザＩＤ」、プロジェクト人材選定および人材管理システムにログインする際のパスワードを示す「パスワード」、ユーザＩＤとパスワードの適用開始日を示す「適用開始日」、ユーザＩＤとパスワードの適用終了日を示す「適用終了日」、ユーザＩＤとパスワードに対応する社員番号を示す「社員番号」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００４６】
図５．３は、社員テーブル１Ｂ０３の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００４７】
社員テーブル１Ｂ０３は、社員をユニークに識別する為の番号である「社員番号」、社員の姓を示す「姓」、社員の名を示す「名」、社員の役職を識別する区分である「役職区分」（本例では、０：一般、１：係長級、２：課長級、３：部長級、４：重役級）、社員の属する組織を識別するコードである「組織コード」、社員のユーザＩＤを示す「ユーザＩＤ」、社員の入社した年を示す「入社年」、社員のメールアドレスを示す「メールアドレス」、社員の単価を示す「社員の単価」、プロジェクト人材選定支援および人材管理システムにおける社員の権限を識別する区分である「権限区分」（本例では、０：権限なし、１：申請権限、２：決済権限）を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００４８】
図５．４は、組織マスタ１Ｂ０４の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００４９】
組織マスタ１Ｂ０４は、組織を識別するコードを示す「組織コード」、会社の名称を示す「会社名」、事業所の名称を示す「事業所名」、部署の名称を示す「部署名」、課の名称を示す「課名」、組織の所在地を示す「所在地」、組織の外線電話番号を示す「外線電話」、組織の内線電話番号を示す「内線電話」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００５０】
図５．５は、勤務表テーブル１Ｂ０５の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００５１】
勤務表テーブル１Ｂ０５は、社員をユニークに識別する為の番号を示す「社員番号」、勤務表の対象年度を示す「対象年度」、指図分の実働時間を示す「実働（指図）」、指図以外の実働時間を示す「実働（指図なし）」、年休を使用した日数を示す「年休」、超勤の時間を示す「超勤」、休日出勤した日数を示す「超勤」、休日出勤した日数を示す「休出」、欠勤の日数を示す「欠勤」、代休の日数を示す「代休」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００５２】
図５．６は、年休テーブル１Ｂ０６の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００５３】
年休テーブル１Ｂ０６は、社員をユニークに識別する為の番号を示す「社員番号」、年休の対象年度を示す「対象年度」、対象年度内において年休を使用した日数を示す「年休総数」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００５４】
図５．７は、スキルテーブル１Ｂ０７の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００５５】
スキルテーブル１Ｂ０７は、社員をユニークに識別する為の番号を示す「社員番号」、スキルの区分を示す「スキル区分」（本例では、１：業種・業務分類、２：技術分類）、スキル区分に対応したスキルの詳細を識別する区分「スキル詳細区分」（本例では、スキルコード４桁であらわしている）、レベルの区分を示す「レベル区分」（本例では、１：高、２：中、３：低）、スキルについての詳細事項を示す「詳細事項」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００５６】
図５．８は、実績テーブル１Ｂ０８の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００５７】
実績テーブル１Ｂ０８は、社員をユニークに識別する為の番号を示す「社員番号」、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、作業の開始日を示す「作業開始日」、作業の終了日を示す「作業終了日」、作業の内容を示す「作業内容」、役割の区分を示す「役割区分」（本例では、０：作業員、１：ＴＬ（チームリーダ）、２：ＰＬ（プロジェクトリーダ）、３：ＰＭ（プロジェクト管理者）、４：その他）、業務の区分を示す「業務区分」（本例では、１：設計、２：製造、３：テスト、４：運用・保守、５：プロジェクト管理、６：ＱＡ、７：その他）、補足事項を示す「補足事項」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００５８】
図５．９は、プロジェクトテーブル１Ｂ０９の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００５９】
プロジェクトテーブル１Ｂ０９は、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、組織を識別するコードを示す「組織コード」、プロジェクトの開始日を示す「開始日」、プロジェクトの終了日を示す「終了日」、プロジェクトの名称を示す「プロジェクト名」、作業をユニークに識別する為の指図番号を示す「指図」、プロジェクトの予算額を示す「予算額」、プロジェクトの受注額を示す「受注額」、プロジェクトの実績額を示す「実績額」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００６０】
図５．１０は、グループテーブル１Ｂ１０の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００６１】
グループテーブル１Ｂ１０は、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、グループをユニークに識別する為のＩＤを示す「グループＩＤ」、グループの名称を示す「グループ名」、グループの終了日を示す「終了日」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００６２】
図５．１１は、メンバテーブル１Ｂ１１の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００６３】
メンバテーブル１Ｂ１１は、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、グループをユニークに識別する為のＩＤを示す「グループＩＤ」、社員をユニークに識別する為の番号を示す「社員番号」、グループのメンバの代表であることを示す「代表フラグ」、メンバがグループに属している状態の終了日を示す「終了日」、申請をユニークに識別する為のＩＤを示す「申請ＩＤ」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００６４】
図５．１２は、進捗表テーブル１Ｂ１２の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００６５】
進捗表テーブル１Ｂ１２は、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、工程の区分を示す「工程区分」（本例では、１：基本設計、２：詳細設計、３：製造、４：単体テスト、。５：結合テスト、６：総合テスト、７：受入テスト、８：本番対応、９：運用）、社員をユニークに識別する為の番号を示す「社員番号」、作業をユニークに識別する為のＩＤを示す「作業ＩＤ」、作業の開始予定日を示す「開始予定日」、作業の終了予定日を示す「終了予定日」、作業の開始日を示す「開始日」、作業の終了日を示す「終了日」、規模の単位を識別する為の区分を示す「規模単位区分」（本例では、１：ＫＳ（キロステップ）、２：人日、３：枚）、予定の規模を示す「予定規模」、実績の規模を示す「実績規模」、その他の項目を示す「その他」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００６６】
図５．１３は、フォローテーブル１Ｂ１３の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００６７】
フォローテーブル１Ｂ１３は、社員をユニークに識別する為の番号を示す「社員番号」、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、要注意の区分を示す「要注意区分」（本例では、１：欠勤、２：年休、３：進捗遅延、４：超勤、５：人間関係、６：異動希望）、要注意の区分が１，２，３の場合の日数を示す「日」、要注意の区分が４の場合の時間を示す「時間」、退場の区分を示す「退場区分」（本例では、０：未候補、１：退場候補、２：退場決定）、申請をユニークに識別する為のＩＤを示す「申請ＩＤ」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００６８】
図５．１４は、評価テーブル１Ｂ１４の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００６９】
評価テーブル１Ｂ１４は、社員をユニークに識別する為の番号を示す「社員番号」、評価される側の社員の社員番号を示す「評価社員番号」、評価の区分を示す「評価区分」（本例では、０：未登録、１：一緒に仕事したい、２：どちらでもない、３：一緒に仕事したくない、４：顔もみたくない）、社員のコメントを示す「コメント」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００７０】
図５．１５は、要望テーブル１Ｂ１５の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００７１】
要望テーブル１Ｂ１５は、社員をユニークに識別する為の番号を示す「社員番号」、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、異動希望があることを示す「フラグ」、異動希望がある場合に異動予定日を示す「異動予定日」、社員のコメントを示す「コメント」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００７２】
図５．１６は、要望詳細テーブル１Ｂ１６の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００７３】
要望詳細テーブル１Ｂ１６は、社員をユニークに識別する為の番号を示す「社員番号」、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、社員の要望を識別する為の区分を示す「要望区分」（本例では、１：仕事量、２：勤務時間、３：仕事内容、４：人間関係、５：異動希望）、社員の要望詳細を識別する為の区分を示す「要望詳細区分」（図中、＊１参照）、社員のコメントを示す「コメント」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００７４】
図５．１７は、申請テーブル１Ｂ１７の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００７５】
申請テーブル１Ｂ１７は、申請をユニークに識別する為のＩＤを示す「申請ＩＤ」、申請の区分を示す「申請区分」（本例では、１：候補者登録、２：退場者登録）、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、申請中であることを示す「申請中フラグ」、申請者の社員番号を示す「申請者番号」、差戻中であることを示す「差戻フラグ」、差戻の理由を示す「差戻理由」、差戻者の社員番号を示す「差戻者番号」、決済済みであることを示す「決裁フラグ」、決裁者の社員番号を示す「決裁者番号」、取消であることを示す「取消フラグ」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００７６】
次に、本発明に係るプロジェクト人材選定支援および人材管理システム（プロジェクト人材選定支援システム）としてのサーバの処理を、図面を用いて説明する。
【００７７】
図２．１、図２．２、図２．３、図２．４、図２．５、および図２．６は、それぞれ、図１におけるプロジェクト候補者検索処理手段１Ａ０１、プロジェクト候補者登録処理手段１Ａ０２、プロジェクトフォロー対象者検索処理手段１Ａ０３、プロジェクト退場者登録処理手段１Ａ０４、プロジェクトメンバ評価登録処理手段１Ａ０５および個人要望登録処理手段１Ａ０６により実行される処理動作のフローチャート図である。
【００７８】
以下、各処理手段により実行される処理を、フローチャート図を用いて詳細に説明する。なお、各処理手段の説明で使用するテーブルにおいて、同じテーブル名を用いている場合は参照符号が異なっていても同一のテーブル（図５．１〜図５．１７参照）を指すものとする。
【００７９】
図２．１は、図１におけるプロジェクト候補者検索処理手段１Ａ０１の処理動作例を示すフローチャート図である。
【００８０】
図１におけるプロジェクト候補者検索処理手段１Ａ０１の処理目的は、プロジェクト立ち上げ時によるメンバ候補者の選出またはプロジェクト進行中における増員、欠員に伴うメンバ選出を過去のプロジェクト経験、スキル、第三者からの評価情報を元に、人間関係も考慮した最適なメンバ候補を選出することである。
【００８１】
なお、プロジェクト候補者検索処理手段１Ａ０１は、プロジェクト候補メンバの仮登録権限を保有する社員のみが実行可能とする。その権限範囲は、社員テーブル２Ａ１１（図５．３参照）が保持する権限区分が１（申請権限）または２（決裁権限）の情報持つ社員のみとする。
【００８２】
図２．１に示すように、プロジェクト候補者検索処理手段１Ａ０１における処理は、［プロジェクト候補メンバの検索ステップＳ２Ａ０１］，［候補メンバの抽出（グループ）ステップＳ２Ａ０２］，［グループ化処理ステップＳ２Ａ０３］，［候補グループ・候補メンバの出力ステップＳ２Ａ０４］，［候補メンバの抽出ステップＳ２Ａ０５］，［候補メンバの出力ステップＳ２Ａ０６］，［プロジェクトメンバの選択ステップＳ２Ａ０７］，［プロジェクトメンバの仮登録ステップＳ２Ａ０８］からなる。以下、各処理ステップＳ２Ａ０１〜Ｓ２Ａ０８について説明する。
【００８３】
［プロジェクト候補メンバの検索ステップＳ２Ａ０１］
プロジェクト候補メンバの検索ステップＳ２Ａ０１では、新規プロジェクトの場合、プロジェクト候補メンバの条件設定を行う。ここでは、スキル、作業開始日、グループの人数、グループコストおよび組織を後述の候補メンバの抽出（グループ）ステップＳ２Ａ０２の抽出条件として設定する。既存プロジェクトの場合、新規または追加のプロジェクト候補メンバの条件設定を行う。
【００８４】
既存プロジェクトは、当該手段の機能を操作する社員が所属する組織が関わっているプロジェクトをプロジェクトテーブル２Ａ１２（図５．９参照）の中から選択する。その選択できるプロジェクトは操作している社員の役職によって適用範囲を制限するようにしている。それは、操作する社員が社員自身と関係のないプロジェクトに対してメンバを選択することは適切ではないためである。
【００８５】
その制限範囲は、社員テーブル２Ａ１１（図５．３参照）が保持する役職区分が1（係長級）の社員は社員自身が関わっているプロジェクトのみ選択が可能、2（課長級）の社員は社員が所属する組織の課内に関わっているプロジェクトのみ選択が可能、3（部長級）の社員は社員が所属する組織の部内に関わっているプロジェクトのみ選択が可能、4（重役級）の社員は全てのプロジェクト情報を取得し選択することができる。
【００８６】
次に、選択されたプロジェクトに対するプロジェクト候補メンバの選定方法について、プロジェクト候補メンバの選定条件設定を行う。
【００８７】
（イ）新たにグループを追加しそのグループに対するプロジェクト候補メンバを新規に選択するケースの場合は、新規プロジェクトと同様の抽出条件（スキル、作業開始日、グループの人数、グループコストおよび組織）を設定する。
【００８８】
（ロ）既に登録されているグループに対してプロジェクト候補メンバを追加するケースの場合は、新規プロジェクトと同様の抽出条件（スキル、作業開始日、グループの人数、グループコストおよび組織）に追加対象のグループ名も条件に加えた設定をする。
【００８９】
［候補メンバの抽出（グループ）ステップＳ２Ａ０２］
候補メンバの抽出（グループ）ステップＳ２Ａ０２では、プロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定された検索条件からプロジェクト候補メンバを抽出する。
【００９０】
また、新規プロジェクトや既存プロジェクトへの新規グループ追加の場合に適用する。プロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定された作業開始日と組織より、社員テーブル２Ａ１５（図５．３参照）から指定された組織に所属する社員情報を取得し、取得した社員情報の中から実績テーブル２Ａ１４（図５．８参照）より指定された作業開始日より前にプロジェクトが終了し、指定された作業開始日以降に参画しているプロジェクトがない社員を絞り込む。
【００９１】
そして、絞り込まれた社員の中から更にプロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定されたスキルによりスキルテーブル２Ａ１３（図５．７参照）から指定されたスキルを持つ社員を絞り込む処理を行う。
【００９２】
［グループ化処理ステップＳ２Ａ０３］
グループ化処理ステップＳ２Ａ０３は、候補メンバの抽出（グループ）ステップＳ２Ａ０２で取得した社員情報から、プロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定された条件、グループの人数、グループコストと評価テーブル２Ａ１６（図５．１４参照）に見合ったグループ化処理を行う。
【００９３】
グループ化処理を行う前提条件として、１グループに１人以上はリーダクラスに該当するメンバが含まれる構成となるようにする。リーダクラスは、社員テーブル２Ａ１７（図５．３参照）に持つ役職区分が1（係長級）以上の社員または社員が過去に経験したプロジェクト情報より実績テーブル２Ａ１８（図５．８参照）に持つ役割区分が１（ＴＬ：チームリーダ）以上の経験をしている社員とする。
【００９４】
まず、はじめにリーダクラスの社員の有無を判定する。もし１人もいない場合は（グループ化：ＮＧ）、プロジェクト候補メンバの検索ステップＳ２Ａ０１にて、検索条件の再設定を促し、当処理を終了させる。１人以上いた場合（グループ化：ＯＫ）、リーダ単位ごとにリーダに対して評価の悪くないメンバ（評価テーブル２Ａ１６（図５．１４参照）の評価区分が３（一緒に仕事をしたくない）、4（顔も見たくない）に該当しないもの）をグループ化する。
【００９５】
ここで、既存プロジェクトにおける新規グループ追加に伴うプロジェクト候補メンバであった場合は、既に登録されているグループのリーダクラスメンバと当処理で抽出したリーダクラスのメンバと互いの評価（評価テーブル２Ａ１６（図５．１４参照）の評価区分が３（一緒に仕事をしたくない）、4（顔も見たくない）に該当しないもの）を判定する。
【００９６】
１件も条件が満たされなければ、プロジェクト候補メンバの検索ステップＳ２Ａ０１にて、検索条件の再設定を促し、当処理を終了させる。
【００９７】
１件でも満たされれば、満たされたリーダクラスのメンバをもとにグループ化されたメンバのみメンバ間の評価を実施する。リーダ単位にグループ化されたメンバ同士について、互いの評価が悪くないメンバ（評価テーブル２Ａ１６（図５．１４参照）の評価区分が３（一緒に仕事をしたくない）、4（顔も見たくない）でないもの同士）でグループ化する。
【００９８】
以上の条件で１つまたは複数のパターンのグループが生成されるが、それぞれのグループについて、プロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定された条件、グループの人数、グループコストに見合う条件になっているかどうか判定をする。
【００９９】
グループコストにおける判定方法は、社員テーブル２Ａ１７（図５．３参照）に持つ単価を利用し、グループ単位で合計した結果と比較することで判定する。以上の条件全てを満たすグループが存在した場合に、候補グループ・候補メンバの出力ステップＳ２Ａ０４に進む。
【０１００】
［候補グループ・候補メンバの出力ステップＳ２Ａ０４］
候補グループ・候補メンバの出力ステップＳ２Ａ０４は、グループ化処理ステップＳ２Ａ０３にて絞り込まれた候補グループ・候補メンバ情報を画面に表示させるための編集処理を行う。最終的にプロジェクト候補メンバを手動で操作できる状態になる。
【０１０１】
［候補メンバの抽出（個人）ステップＳ２Ａ０５］
候補メンバの抽出（個人）ステップＳ２Ａ０５では、プロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定された検索条件からプロジェクト候補メンバを抽出する。
【０１０２】
また、新規プロジェクトや既存プロジェクトへの新規グループ追加の場合に適用される。プロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定された作業開始日と組織より、社員テーブル２Ａ１９（図５．３参照）から指定された組織に所属する社員情報を取得し、取得した社員情報の中から実績テーブル２Ａ２１（図５．８参照）より指定された作業開始日より前にプロジェクトが終了し、指定された作業開始日以降に参画しているプロジェクトがない社員を絞り込む。
【０１０３】
そして、絞り込まれた社員の中から更にプロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定されたスキル情報よりスキルテーブル２Ａ２３（図５．７参照）から指定されたスキルを持つ社員を絞り込む処理を行う。
【０１０４】
［候補メンバの出力ステップＳ２Ａ０６］
候補メンバの出力ステップＳ２Ａ０６は、候補グループ・候補メンバの出力ステップＳ２Ａ０４と同様にプロジェクト候補メンバの検索ステップＳ２Ａ０１および候補メンバの抽出（個人）ステップＳ２Ａ０５の順を追って候補メンバの抽出（個人）ステップＳ２Ａ０５にて得られた検索結果を画面に表示させるための編集処理を行う。最終的にメンバ候補を手動で操作できる状態になる。
【０１０５】
［プロジェクトメンバの選択ステップＳ２Ａ０７］
プロジェクトメンバの選択ステップＳ２Ａ０７は、候補グループ・候補メンバの出力ステップＳ２Ａ０４、または候補メンバの出力ステップＳ２Ａ０６で処理された結果を画面に表示し、検索結果によって得られたプロジェクト候補メンバ情報を元に手動で人為的にプロジェクト候補メンバを再選択できるようにする。また、グループ名が未設定である場合は最終的に選択したメンバに対してグループ名を入力することができる。
【０１０６】
［プロジェクトメンバの仮登録ステップＳ２Ａ０８］
プロジェクトメンバの仮登録ステップＳ２Ａ０８は、プロジェクトメンバの選択ステップＳ２Ａ０７にて再選択したプロジェクト候補メンバ情報を、グループテーブル２Ａ２４（図５．１０参照）、メンバテーブル２Ａ２５（図５．１１参照）および申請テーブル２Ａ２６（図５．１７参照）に登録する。
【０１０７】
図２．２は、図１におけるプロジェクト候補者登録処理手段１Ａ０２の処理動作例を示すフローチャートである。
【０１０８】
図１におけるプロジェクト候補者登録処理手段１Ａ０２の処理目的は、プロジェクト候補者検索処理手段１Ａ０１にて登録した情報を修正する機能と申請、差戻し、決裁といったワークフローの機能を持つ。
【０１０９】
図２．２に示すように、プロジェクト候補者登録処理手段１Ａ０２における処理は、［プロジェクトメンバ（仮登録）の抽出ステップＳ２Ｂ０１］，［プロジェクトメンバ（仮登録）一覧の出力ステップＳ２Ｂ０２］，［プロジェクトメンバの再仮登録ステップＳ２Ｂ０３］，［プロジェクトメンバ（仮登録）の本登録申請ステップＳ２Ｂ０４］，［プロジェクトメンバの本登録ステップＳ２Ｂ０５］，［プロジェクトメンバの仮登録（差戻し）ステップＳ２Ｂ０６］，［プロジェクトメンバの確定ステップＳ２Ｂ０７］からなる。以下、各処理ステップＳ２Ｂ０１〜Ｓ２Ｂ０７について説明する。
【０１１０】
［プロジェクトメンバ（仮登録）の抽出ステップＳ２Ｂ０１］
プロジェクトメンバ（仮登録）の抽出ステップＳ２Ｂ０１は、図２．１のプロジェクトメンバの仮登録ステップＳ２Ａ０８にて登録した情報を申請テーブル２Ｂ１１（図５．１７参照）、グループテーブル２Ｂ１３（図５．１０参照）、メンバテーブル２Ｂ１４（図５．１１参照）から抽出する。
【０１１１】
また、当処理は画面より抽出処理の操作を行うが、操作する人が、図２．１のプロジェクトメンバの仮登録ステップＳ２Ａ０８にて登録していれば、抽出することができる。抽出対象データがない場合は、当処理は終了する。
【０１１２】
［プロジェクトメンバ（仮登録）一覧の出力ステップＳ２Ｂ０２］
プロジェクトメンバ（仮登録）一覧の出力ステップＳ２Ｂ０２は、プロジェクトメンバ（仮登録）の抽出ステップＳ２Ｂ０１で抽出した件数が１件以上ある場合、抽出したメンバ情報を画面に表示させるための編集処理を行う。
【０１１３】
編集処理後、画面上で仮登録したプロジェクトメンバ候補者に対してグループの一覧から個々にプロジェクト候補メンバ候補を外したり、グループ単位で削除することができる。
【０１１４】
ただし、グループ単位で削除した場合もしくは全てのプロジェクト候補者を外した場合は、当処理は終了する。
【０１１５】
メンバ候補者を追加する場合は、プロジェクトメンバの再仮登録ステップＳ２Ｂ０３へ処理は推移し、仮登録する画面に遷移して追加処理を行うことができる。
【０１１６】
［プロジェクトメンバの再仮登録ステップＳ２Ｂ０３］
プロジェクトメンバの再仮登録ステップＳ２Ｂ０３では、プロジェクトメンバ（仮登録）一覧の出力ステップＳ２Ｂ０２にてメンバ候補者の追加が発生した場合に当処理にて追加したメンバ候補者の再仮登録をすることができる。
【０１１７】
当処理は、図２．１のプロジェクト候補メンバの検索ステップＳ２Ａ０１から候補メンバの抽出（個人）ステップＳ２Ａ０５、候補メンバの出力ステップＳ２Ａ０６、プロジェクトメンバの選択ステップＳ２Ａ０７、プロジェクトメンバの仮登録ステップＳ２Ａ０８までの処理と同等の処理となる。画面にてメンバ確定後、メンバテーブル２Ｂ１６（図５．１１参照）に追加メンバ情報を登録し、プロジェクトメンバ（仮登録）の抽出ステップＳ２Ｂ０１の抽出対象データとなる。
【０１１８】
［プロジェクトメンバ（仮登録）の本登録申請ステップＳ２Ｂ０４］
プロジェクトメンバ（仮登録）の本登録申請ステップＳ２Ｂ０４は、プロジェクトメンバ（仮登録）一覧の出力ステップＳ２Ｂ０２にてメンバ候補者の追加手続きがない場合、およびグループ単位の削除がない場合は、仮登録情報を決裁者へ申請し、決裁者が申請された情報を査収し本登録する流れとなる。
【０１１９】
最終決裁者へ通知する手段として、最終決裁者のメールアドレスを指定して本登録申請依頼情報（本登録処理用のＵＲＬ、申請ＩＤ）を添付して通知する。具体的な処理としては、申請の際は、メンバテーブル２Ｂ１８（図５．１１参照）の申請ＩＤに対して、申請テーブル２Ｂ１７（図５．１７参照）に仮登録時点にて採番した申請ＩＤを登録し、申請テーブル２Ｂ１７（図５．１７参照）には申請中フラグと決裁者番号を更新する。
【０１２０】
最終決裁者の決定方法は、基本は申請者が所属する直属の上司および役職が課長級以上の社員としている。ただし、申請者本人が、上司にあたる社員がいない場合、申請者本人ではなく、直属の部下にあたる役職の最高位の社員を選択できるように制御することで不正な登録ができないようにする。
【０１２１】
［プロジェクトメンバの本登録ステップＳ２Ｂ０５］
プロジェクトメンバの本登録ステップＳ２Ｂ０５は、プロジェクトメンバ（仮登録）の本登録申請ステップＳ２Ｂ０４にて申請時に通知されたメール本文に本登録用の画面に遷移するＵＲＬと申請ＩＤが記載されている。記載されているＵＲＬにアクセスすることで、本登録するための画面へ遷移し決裁処理を行う。申請されたメンバ候補者を正式なメンバとして確定する本登録処理と、プロジェクトメンバとして問題がある場合に申請者へ差し戻しを行う差戻し処理のいずれかを選択する。
【０１２２】
具体的な処理として、申請者より送信されたメール情報から申請ＩＤを取得し、取得した申請ＩＤから申請テーブル２Ｂ１９（図５．１７参照）からプロジェクトＩＤを、メンバテーブル２Ｂ２２（図５．１１参照）から社員番号とグループＩＤを取得し、社員番号から社員テーブル（図５．３参照）よりプロジェクト候補メンバの名前とプロジェクトＩＤとグループＩＤからグループ名を取得する。本登録を選択した場合、プロジェクトメンバの確定ステップＳ２Ｂ０７に推移する。差戻しを選択した場合、プロジェクトメンバの仮登録（差戻し）ステップＳ２Ｂ０６に推移する。
【０１２３】
［プロジェクトメンバの仮登録（差戻し）ステップＳ２Ｂ０６］
プロジェクトメンバの仮登録（差戻し）ステップＳ２Ｂ０６は、プロジェクトメンバの本登録ステップＳ２Ｂ０５にて差戻し処理が実行された場合、申請者へ差戻し情報を添付してメールにて通知され、プロジェクトメンバ（仮登録）の抽出ステップＳ２Ｂ０１の処理対象データとして処理する。
【０１２４】
具体的な処理として、申請テーブル２Ｂ２３（図５．１７参照）の差戻理由にプロジェクトメンバの本登録ステップＳ２Ｂ０５にて設定された差戻理由を設定、差戻者番号にプロジェクトメンバの本登録ステップＳ２Ｂ０５で操作した決裁者の社員番号を設定および差戻フラグを1に設定する。
【０１２５】
［プロジェクトメンバの確定ステップＳ２Ｂ０７］
プロジェクトメンバの確定ステップＳ２Ｂ０７は、プロジェクトメンバの本登録ステップＳ２Ｂ０５にて本登録処理が実行された場合、プロジェクト候補メンバからプロジェクト正式メンバへの確定処理を行う。具体的な処理として、申請テーブル２Ｂ２４（図５．１７参照）の決裁者番号に決裁者の社員番号を設定し、決裁フラグに1を設定する。
【０１２６】
また、実績テーブル２Ｂ２５（図５．８参照）にプロジェクトメンバの社員番号、プロジェクトＩＤと作業開始日にプロジェクトテーブル２Ｂ２６（図５．９参照）よりプロジェクトＩＤから作業開始日を取得し設定し、実績情報として登録する。
【０１２７】
図２．３は、図１におけるプロジェクトフォロー対象者検索処理手段１Ａ０３の処理動作例を示すフローチャートである。
【０１２８】
図１におけるプロジェクトフォロー対象者検索処理手段１Ａ０３の処理目的は、プロジェクトメンバの勤務状態や進捗状況よりプロジェクトの進行の妨げとなる要因、または一個人における精神面、健康面について問題がありそうなメンバ候補を抽出することができる。
【０１２９】
そして、対象となったメンバを日々画面で確認することが可能になるので迅速なフォローにつながり解決スピードの向上が計れる。また、フォローだけではなく、プロジェクトから退場候補者として選出し仮登録する機能も合わせ持つ。
【０１３０】
図２．３に示すように、プロジェクトフォロー対象者検索処理手段１Ａ０３における処理は、［勤務状況・進捗状況の編集ステップＳ２Ｃ０１］［フォロー対象者のフラグ設定ステップＳ２Ｃ０２］，［フォロー対象者の抽出ステップＳ２Ｃ０３］，［フォロー対象者一覧の出力ステップＳ２Ｃ０４］，［退場者の選択ステップＳ２Ｃ０５］，［退場者の仮登録ステップＳ２Ｃ０６］からなる。以下、各処理ステップＳ２Ｃ０１〜Ｓ２Ｃ０６について説明する。
【０１３１】
［勤務状況・進捗状況の編集ステップＳ２Ｃ０１］
勤務状況・進捗状況の編集ステップＳ２Ｃ０１では、各プロジェクトメンバの勤務状況（欠勤、年休、超勤時間）、作業進捗状況（遅延日数）、他のメンバからの評価（例えば、５段階評価）情報およびプロジェクトメンバ自身の要望（異動希望、人間関係）に関する情報を随時あるいは定期的に一括して収集する。
【０１３２】
具体的な処理として、進捗表テーブル２Ｃ１１（図５．１２参照）から終了予定日が処理日より過去日で、終了日に日付が設定されていないデータを進捗状況情報として取得する。勤務表テーブル２Ｃ１２（図５．５参照）からは処理日のその月を基準に当月における欠勤日数が１日以上、年休３日以上または、超勤時間数が３0以上のデータを勤務状況情報として取得する。
【０１３３】
評価テーブル２Ｃ１４（図５．１４参照）から評価区分が3（一緒に仕事したくない）、4（顔も見たくない）に該当するデータを評価状況情報として取得する。また、要望テーブル２Ｃ１５（図５．１５参照）から異動希望フラグが1に設定されているデータがあれば要望状況情報として取得する。
【０１３４】
［フォロー対象者のフラグ設定ステップＳ２Ｃ０２］
フォロー対象者のフラグ設定ステップＳ２Ｃ０２は、勤務状況・進捗状況の編集ステップＳ２Ｃ０１にて収集した情報がプロジェクトを円滑に遂行するための阻害要因となる要素を持つプロジェクトメンバとしてフォロー対象フラグを設定する処理を行う。
【０１３５】
また、フォロー対象となったプロジェクトメンバ情報は、管理者（プロジェクトマネージャー等）たるメンバへ対象者の有無を知らせるメールを配信する処理を行う。具体的な処理として、勤務状況・進捗状況の編集ステップＳ２Ｃ０１にて取得した情報をフォローテーブル２Ｃ１６（図５．１３参照）に登録する。
【０１３６】
勤務状況情報からは、該当プロジェクトメンバ毎に欠勤によるフォロー対象者であれば、フォローテーブル２Ｃ１６（図５．１３参照）の要注意区分に１（欠勤）と日に欠勤日数を設定し、年休によるフォロー対象者であれば、フォローテーブル２Ｃ１６（図５．１３参照）の要注意区分に２（年休）と日に年休日数を設定し、超勤時間によるフォロー対象者であれば、フォローテーブル２Ｃ１６（図５．１３参照）の要注意区分に４（超勤）と時間に超勤時間数を設定する。
【０１３７】
進捗状況情報からは、遅延が発生してプロジェクトメンバ毎にフォローテーブル２Ｃ１６の要注意区分に３（進捗遅延）と日に遅延日数を設定する。評価状況情報からは、該当プロジェクトメンバ毎にフォローテーブル２Ｃ１６（図５．１３参照）の要注意区分に５（人間関係）を設定する。要望状況情報からは、該当プロジェクトメンバ毎にフォローテーブル２Ｃ１６（図５．１３参照）の要注意区分に6（異動希望）を設定する。
【０１３８】
メールによる通知対象については、フォロー対象となったプロジェクトメンバがリーダクラスではない場合はそのグループリーダ、プロジェクトの管理者および直属の上司へ通知する。フォロー対象となったプロジェクトメンバがリーダクラスの場合プロジェクトの管理者および直属の上司へ通知する。
【０１３９】
［フォロー対象者の抽出ステップＳ２Ｃ０３］
フォロー対象者の抽出ステップＳ２Ｃ０３では、フォロー対象者のフラグ設定ステップＳ２Ｃ０２にてフォロー対象プロジェクトメンバ情報より、画面から検索条件（欠勤日数、年休日数、超勤時間、進捗遅延日数）を指定し、フォロー対象者を絞りこむ処理を行う。
【０１４０】
具体的な処理として、フォロー対象者のフラグ設定ステップＳ２Ｃ０２にて登録された情報をフォローテーブル２Ｃ１７（図５．１３参照）より申請ＩＤが未設定のものを取得する。その取得した情報から、画面にて設定された検索条件に該当する情報（欠勤日数以上、年休日数以上、超勤時間以上、進捗遅延日数以上）で絞りこむ。当処理を操作できる人は、フォローの通知を受けたメンバ（プロジェクトの管理者および直属の上司など）に限定する。
【０１４１】
［フォロー対象者一覧の出力ステップＳ２Ｃ０４］
フォロー対象者一覧の出力ステップＳ２Ｃ０４では、フォロー対象者の抽出ステップＳ２Ｃ０３にて絞り込まれた件数が１件以上ある場合、抽出したメンバ情報を画面に表示させるための編集処理を行う。また、検索結果で得られた情報を元に、退場候補を手動で選択できる状態になる。
【０１４２】
［退場者の選択ステップＳ２Ｃ０５］
退場者の選択ステップＳ２Ｃ０５では、フォロー対象者の中から退場候補者を選択する。操作手段として、フォロー対象者一覧の出力ステップＳ２Ｃ０４にて編集された情報から退場候補者を選択することができる。
【０１４３】
［退場者の仮登録ステップＳ２Ｃ０６］
退場者の仮登録ステップＳ２Ｃ０６では、退場者の選択ステップＳ２Ｃ０５にて選択された退場候補者情報を登録する。具体的な処理として、退場者の選択ステップＳ２Ｃ０５にて選択したメンバ情報についてフォローテーブル２Ｃ２０（図５．１３参照）の退場区分に1（退場候補）を設定する。
【０１４４】
図２．４は、図１におけるプロジェクト退場者登録処理手段１Ａ０４の処理動作例を示すフローチャートである。
【０１４５】
図１におけるプロジェクト退場者登録処理手段１Ａ０４の処理目的は、プロジェクトフォロー対象者検索処理手段１Ａ０３にて仮登録した情報を修正する機能と申請、差戻し、決裁といったワークフローの機能を持つ。
【０１４６】
仮登録した情報を修正する機能としては、メンバ候補者をグループ単位で削除することが可能である。また、仮登録情報を最終決裁者が決裁するため最終決済者のメールアドレスを指定し申請する機能を持つ。以下、図２．４を用いてさらに詳しく説明する。
【０１４７】
図２．４に示すように、プロジェクト退場者登録処理手段１Ａ０４における処理は、［退場者（仮登録）の抽出ステップＳ２Ｄ０１］，［退場者（仮登録）一覧の出力ステップＳ２Ｄ０２］，［退場者の再仮登録ステップＳ２Ｄ０３］，［退場者（仮登録）の本登録申請ステップＳ２Ｄ０４］，［退場者の本登録ステップＳ２Ｄ０５］，［退場者（仮登録）（差戻し）ステップＳ２Ｄ０６］，［プロジェクトメンバの編集ステップＳ２Ｄ０７］からなる。以下、各処理ステップＳ２Ｄ０１〜Ｓ２Ｄ０７について説明する。
【０１４８】
［退場者（仮登録）の抽出ステップＳ２Ｄ０１］
退場者（仮登録）の抽出ステップＳ２Ｄ０１では、プロジェクトフォロー対象者検索処理手段１Ａ０３にて仮登録した情報を申請テーブル２Ｄ１１（図５．１７参照）から抽出する。図２．３の退場者の仮登録ステップＳ２Ｃ０６にて登録した情報をフォローテーブル２Ｄ１３（図５．１３参照）より退場区分が1（退場候補）であるデータを取得する。
【０１４９】
また、当処理は画面より抽出処理の操作を行うが、操作する人が、図２．３の退場者の仮登録ステップＳ２Ｃ０６にて登録していれば、抽出することができる。抽出対象データがない場合は、当処理は終了する。
【０１５０】
［退場者（仮登録）一覧の出力ステップＳ２Ｄ０２］
退場者（仮登録）一覧の出力ステップＳ２Ｄ０２では、退場者（仮登録）の抽出ステップＳ２Ｄ０１で抽出した件数が１件以上ある場合、抽出したメンバ情報を画面に表示させるための編集処理を行う。
【０１５１】
編集処理後、画面上で仮登録した退場候補者に対して一覧から外すことができる。
【０１５２】
その際、外した退場候補者の社員番号からフォローテーブル２Ｄ１４（図５．１３参照）のその社員番号に対するデータの退場区分を0（未候補）に更新する。全ての退場候補者を外した場合は、当処理は終了する。退場候補者を追加する場合は、退場者の再仮登録ステップＳ２Ｄ０３へ処理は推移し、仮登録する画面に遷移して追加処理を行うことができる。
【０１５３】
［退場者の再仮登録ステップＳ２Ｄ０３］
退場者の再仮登録ステップＳ２Ｄ０３では、退場者（仮登録）一覧の出力ステップＳ２Ｄ０２にて退場候補者の追加が発生した場合に当処理にて追加したメンバ候補者の再仮登録をすることができる。
【０１５４】
当処理は、図２．３のフォロー対象者の抽出ステップＳ２Ｃ０３、フォロー対象者一覧の出力ステップＳ２Ｃ０４、退場者の選択ステップＳ２Ｃ０５、退場者の仮登録ステップＳ２Ｃ０６までの処理と同等の処理となる。画面にて退場候補者確定後、フォローテーブル２Ｄ１５（図５．１３参照）に退場候補者情報を登録し、退場者（仮登録）の抽出ステップＳ２Ｄ０１の抽出対象データとする。
【０１５５】
［退場者（仮登録）の本登録申請ステップＳ２Ｄ０４］
退場者（仮登録）の本登録申請ステップＳ２Ｄ０４は、退場者（仮登録）一覧の出力ステップＳ２Ｄ０２にて退場候補者の追加手続きがない場合、仮登録情報を決裁者へ申請し、決裁者が申請された情報を査収し本登録する流れとなる。
【０１５６】
最終決裁者へ通知する手段として、最終決裁者のメールアドレスを指定して本登録申請依頼情報（本登録処理用のＵＲＬ、申請ＩＤ）を添付して通知する。具体的な処理としては、申請の際は、退場候補者の社員番号に該当するデータに対してフォローテーブル２Ｄ１７（図５．１３参照）の申請ＩＤを設定する。
【０１５７】
その時に設定した申請ＩＤを申請テーブル２Ｄ１６（図５．１７参照）に登録し、申請区分に2（退場者登録）、申請中フラグと申請者番号を更新する。最終決裁者の決定方法は、基本は申請者が所属する直属の上司および役職が課長級以上の社員としている。ただし、申請者本人が、上司にあたる社員がいない場合、申請者本人ではなく、直属の部下にあたる役職の最高位の社員が選択できるように制御することで不正な登録ができないようにする。
【０１５８】
［退場者の本登録ステップＳ２Ｄ０５］
退場者の本登録ステップＳ２Ｄ０５は、退場者（仮登録）の本登録申請ステップＳ２Ｄ０４にて申請時に通知されたメール本文に本登録用の画面に遷移するＵＲＬと申請ＩＤが明記されている。
【０１５９】
その記載されているＵＲＬにアクセスすることで、本登録するための画面へ遷移し決裁処理を行う。申請された退場候補者を正式な退場者メンバとして確定する本登録処理と、退場者メンバとして問題がある場合に申請者へ差し戻しを行う差戻し処理のいずれかを選択する。
【０１６０】
具体的な処理として、申請者より送信されたメール情報から申請ＩＤを取得し、取得した申請ＩＤから申請テーブル２Ｄ１８（図５．１７参照）よりプロジェクトＩＤを取得する。
【０１６１】
また、取得した申請ＩＤからフォローテーブル２Ｄ２０（図５．１３参照）より社員番号とグループＩＤを取得し、社員番号から社員テーブル２Ｄ１９（図５．３参照）より退場者候補メンバの姓、名と、グループテーブル２Ｄ２５（図５．１０参照）よりプロジェクトＩＤとグループＩＤからグループ名を取得する。本登録を選択した場合、プロジェクトメンバの編集ステップＳ２Ｄ０７に推移する。差戻しを選択した場合、退場者（仮登録）（差戻し）ステップＳ２Ｄ０６に推移する。
【０１６２】
［退場者（仮登録）（差戻し）ステップＳ２Ｄ０６］
退場者（仮登録）（差戻し）ステップＳ２Ｄ０６は、退場者の本登録ステップＳ２Ｄ０５にて差戻し処理が実行された場合、申請者へ差戻し情報を添付してメールにて通知され、退場者（仮登録）の抽出ステップＳ２Ｄ０１の処理対象データとして処理する。
【０１６３】
具体的な処理として、申請テーブル２Ｄ２１（図５．１７参照）の差戻理由に退場者の本登録ステップＳ２Ｄ０５にて設定された差戻理由を設定、差戻者番号に退場者の本登録ステップＳ２Ｄ０５で操作した決裁者の社員番号および差戻フラグを1に設定する。
【０１６４】
［プロジェクトメンバの編集ステップＳ２Ｄ０７］
プロジェクトメンバの編集ステップＳ２Ｄ０７は、退場者の本登録ステップＳ２Ｄ０５にて本登録処理が実行された場合、既存プロジェクトのメンバが所属するグループから除外する処理を行う。
【０１６５】
具体的な処理として、申請テーブル２Ｄ２２（図５．１７参照）の決裁者番号に決裁者の社員番号を設定し、決裁フラグを設定する。また、退場メンバの社員番号に対するデータを実績テーブル２Ｄ２３（図５．８参照）とメンバテーブル２Ｄ２４（図５．１１参照）から取得し、実績テーブル２Ｄ２３（図５．８参照）の作業終了日と、メンバテーブル２Ｄ２４（図５．１１参照）の終了日を登録した日付で更新する。
【０１６６】
図２．５は、図１におけるプロジェクトメンバ評価登録処理手段１Ａ０５の処理動作例を示すフローチャートである。
【０１６７】
図１におけるプロジェクトメンバ評価登録処理手段１Ａ０５の処理目的は、プロジェクトメンバが他のメンバに対する評価を登録する機能を設けることで、現行のメンバ間の人間関係を管理者がシステムを通して確認できることでフォローするきっかけを得ることを可能にすること、また、新規プロジェクト立ち上げ時や、進行中のプロジェクトにおいて新たにメンバを選出または増員時の選出の際には、この評価情報を考慮した選出を実現することによってコミュニケーションの円滑化を意識したメンバ選出を可能にすることである。前提条件として、評価可能なメンバ対象者は同じプロジェクトに関わっているグループ内のメンバであること、リーダクラスはリーダ間も対象としている。
【０１６８】
評価対象メンバを特定している理由として、日頃、同じ環境で顔を見合わせているメンバを対象とすることで、評価の信憑性を高めるためである。ここでいうリーダクラスとは、社員テーブル１Ｂ０３（図５．３参照）に持つ役職区分が１（係長級）以上の社員または社員が過去に経験したプロジェクト情報より実績テーブル１Ｂ０８（図５．８参照）に持つ役割区分が１（ＴＬ：チームリーダ）以上の経験を保有している社員を指す。
【０１６９】
図２．５に示すように、プロジェクトメンバ評価登録処理手段１Ａ０５における処理は、［グループ選択ステップＳ２Ｅ０１］，［評価対象者の抽出ステップＳ２Ｅ０２］，［評価対象者一覧の出力ステップＳ２Ｅ０３］，［評価の登録ステップＳ２Ｅ０４］からなる。以下、各処理ステップＳ２Ｅ０１〜Ｓ２Ｅ０４について説明する。
【０１７０】
［グループ選択ステップＳ２Ｅ０１］
グループ選択ステップＳ２Ｅ０１では、評価者が評価可能なメンバを特定するための前処理としてグループで対象者を絞り込むために、グループを特定するための処理を行う。
【０１７１】
具体的な処理として、評価者が所属するプロジェクト情報について評価者の社員番号からメンバテーブル２Ｅ１１（図５．１１参照）よりプロジェクトＩＤを取得する。取得したプロジェクトＩＤからグループテーブル２Ｅ１２（図５．１０参照）よりグループＩＤを取得する。
【０１７２】
評価者がリーダクラスでない場合は、評価者が所属するグループＩＤを評価対象者の抽出ステップＳ２Ｅ０２の処理条件として設定する。評価者がリーダクラスである場合は、評価者が所属するプロジェクトに属するグループＩＤ全てを評価対象者の抽出ステップＳ２Ｅ０２の処理条件として設定する。
【０１７３】
［評価対象者の抽出ステップＳ２Ｅ０２］
評価対象者の抽出ステップＳ２Ｅ０２では、グループ選択ステップＳ２Ｅ０１にて設定されたグループＩＤからそのグループＩＤに属するメンバを評価対象者として抽出するための処理を行う。
【０１７４】
具体的な処理として、グループ選択ステップＳ２Ｅ０１にて設定されたグループＩＤよりメンバテーブル２Ｅ１３（図５．１１参照）から社員番号を取得し、取得した社員番号より社員テーブル２Ｅ１５（図５．３参照）から画面に表示するための名前（姓、名）を取得する。
【０１７５】
また、既に一度、評価を登録している対象者がいれば、取得した社員番号と評価者の社員番号より評価テーブル２Ｅ１６（図５．１４参照）から評価区分、コメントを抽出する。ただし、評価者がリーダクラスである場合、評価者が所属するグループ以外のグループに属するメンバに限って、評価者が所属するグループ以外のグループＩＤからメンバテーブル２Ｅ１３（図５．１１参照）より代表フラグが１となっている社員番号のみ取得対象となる。
【０１７６】
［評価対象者一覧の出力ステップＳ２Ｅ０３］
評価対象者一覧の出力ステップＳ２Ｅ０３では、評価対象者の抽出ステップＳ２Ｅ０２で抽出されたメンバ情報を画面に表示させるための編集処理を行う。画面上に表示する評価のリストはコードマスタ２Ｅ１７より取得する。
【０１７７】
［評価の登録ステップＳ２Ｅ０４］
評価の登録ステップＳ２Ｅ０４では、評価対象者一覧の出力ステップＳ２Ｅ０３で一覧表示されたメンバ情報から、評価したい対象者を選択し、自分にとって、評価対象者はどういう影響があるのかを視点にした質問形式と、質問に対する詳細な内容を登録する処理を行う。
【０１７８】
また、登録された情報について、一緒に仕事をしたくないという評価をしたメンバが１名以上いれば、プロジェクトフォロー対象者検索処理手段１Ａ０３の対象データとして、フォローテーブル２Ｅ１８（図５．１３参照）に登録され、メンバの上長にフォロー依頼のメールを通知する処理を行う。そうすることで、リアルタイムにメンバからのアラーム情報を機械的にチェックすることが可能になり、迅速な対応につなげられる。
【０１７９】
図２．６は、図１における個人要望登録処理手段１Ａ０６の処理動作例を示すフローチャートである。
【０１８０】
図１における個人要望登録処理手段１Ａ０６の処理の目的は、プロジェクトメンバ個人において抱えている問題、プロジェクトを遂行するにあたり困難が生じた場合に退場の要望事項を登録する画面を用意し、管理者にその要望事項が伝達できる仕掛けを用意することで、面と向かっては相談し難いことを当機能によって容易にすることでできる。よって、個人で抱える危険性を事前に防ぐ１つの手段となる。
【０１８１】
図２．６に示すように、個人要望登録処理手段１Ａ０６における処理は、［要望の入力ステップＳ２Ｆ０１］，［要望の登録ステップＳ２Ｆ０２］からなる。以下、各処理ステップＳ２Ｆ０１〜Ｓ２Ｆ０２について説明する。
【０１８２】
［要望の入力ステップＳ２Ｆ０１］
要望の入力ステップＳ２Ｆ０１では、現在従事している仕事や人間関係について要望事項を入力する。
【０１８３】
操作手段は、画面からの入力となる。入力内容は定型の質問事項（仕事量、勤務時間、仕事内容、人間関係）に対して、各々の事項に対する詳細がプルダウンにリストアップされ、その中から選択する形式をとる。
【０１８４】
定型の質問事項については、コードマスタ２Ｆ１３（図５．１参照）から取得する。異動希望の有無と異動希望日やその理由をフリーで入力する事ができる。入力画面には、要望テーブル２Ｆ１１（図５．１５参照）、要望詳細テーブル２Ｆ１２（図５．１６参照）に既に登録されていれば、その情報が画面に表示されるように情報を取得する。
【０１８５】
［要望の登録ステップＳ２Ｆ０２］
要望の登録ステップＳ２Ｆ０２では、要望の入力ステップＳ２Ｆ０１にて入力された情報を要望テーブル２Ｆ１４（図５．１５参照）、要望詳細テーブル２Ｆ１５（図５．１６参照）に格納する。登録の際、現在携わっているプロジェクトの情報も同時に登録される。
【０１８６】
図３は、図１における画面遷移図である。以下、図３に示す画面遷移図を説明する。
【０１８７】
［ログイン画面３Ａ０１］
ログイン画面３Ａ０１では、ユーザＩＤとパスワードを入力し、ＯＫボタンを押下する。入力されたユーザＩＤとパスワードが認証テーブル１Ｂ０２（図５．２参照）上に存在し、かつ利用可能期限内（適用開始日〜適用終了日）のユーザであれば、メニュー画面３Ａ０２に遷移する。該当データが存在しない、または利用可能期限外の場合は、当システム利用不可のため、エラーメッセージを表示する。
【０１８８】
［メニュー画面３Ａ０２］
メニュー画面３Ａ０２では、ログインしているユーザが使用できるメニューのみ表示する。
【０１８９】
メニューの使用可否は、社員テーブル１Ｂ０３（図５．３参照）の権限区分のデータを元に制御する。メニューの項目として、「プロジェクト候補者検索」、「プロジェクト候補者変更・申請」、「プロジェクトフォロー対象者検索」、「プロジェクト退場者変更・申請」、「プロジェクトメンバ評価」、「個人要望登録」および「申請状況照会」がある。
【０１９０】
「プロジェクト候補者検索」からは、プロジェクト候補者検索画面３Ａ０４へ遷移する。「プロジェクト候補者変更・申請」からは、プロジェクト候補者変更・申請画面３Ａ０７へ遷移する。「プロジェクトフォロー対象者検索」からは、プロジェクトフォロー対象者検索画面３Ａ１０に遷移する。
【０１９１】
「プロジェクト退場者変更・申請」からは、プロジェクト退場者変更・申請画面３Ａ１１に遷移する。「プロジェクトメンバ評価」は、プロジェクトメンバ評価登録画面３Ａ１４に遷移する。「個人要望登録」は、個人要望登録画面３Ａ１５に遷移する。「申請状況照会」は、申請状況照会画面３Ａ１６に遷移する。
【０１９２】
また、「選択」ボタンを押下した場合は、メニュー画面３Ａ０２の上に別画面としてプロジェクト選択サブ画面３Ａ０３を表示する。プロジェクト選択サブ画面３Ａ０３にてプロジェクトを選択し、呼び出し元であるメニュー画面３Ａ０２へ選択したプロジェクトのデータを渡した後にメニュー画面３Ａ０２においてメニューの項目を押下した場合は、選択したプロジェクトを入力条件として設定した状態で次画面へ遷移する（但し、選択したプロジェクトを入力条件として使用するのは、プロジェクト候補者検索画面３Ａ０４、プロジェクト候補者変更・申請画面３Ａ０７、プロジェクトフォロー対象者検索画面３Ａ１０、プロジェクト退場者変更・申請画面３Ａ１１、プロジェクトメンバ評価登録画面３Ａ１４および申請状況照会画面３Ａ１６の６画面）。
【０１９３】
［プロジェクト選択サブ画面３Ａ０３］
プロジェクト選択サブ画面３Ａ０３では、組織マスタ１Ｂ０４（図５．４参照）とプロジェクトテーブル１Ｂ０９（図５．９参照）から現在進行中のプロジェクトを取得し、プルダウンボックスにて選択可能とする。
【０１９４】
プロジェクトを選択した状態で「ＯＫ」ボタンを押下すると、呼び出し元であるメニュー画面３Ａ０２へ選択したプロジェクトのデータを渡して、プロジェクト選択サブ画面３Ａ０３を閉じる（メニュー画面３Ａ０２に選択したプロジェクトを表示する）。プロジェクトを選択せずに「ＯＫ」ボタンを押下した場合はエラーメッセージを表示する。
【０１９５】
［プロジェクト候補者検索画面３Ａ０４］（図４．１参照）
プロジェクト候補者検索画面３Ａ０４では、検索条件（スキル（図４．１の４Ａ０１）、作業開始日（同４Ａ０１）、グループ人数（同４Ａ０３）、グループコスト（同４Ａ０４）、組織（同４Ａ０５）、グループ名（同４Ａ０７））を入力する。
【０１９６】
検索条件のスキルの「選択」ボタン４Ａ０１を押下した場合、プロジェクト候補者検索画面３Ａ０４の上に別画面としてスキル選択サブ画面３Ａ０５を表示する。
【０１９７】
検索条件の組織の「選択」ボタン４Ａ０５を押下した場合、プロジェクト候補者検索画面３Ａ０４の上に別画面として組織選択サブ画面３Ａ０６を表示する。
【０１９８】
検索条件を入力後、「グループ検索」ボタン４Ａ０６または「個人検索」ボタン４Ａ０８を押下し、社員テーブル１Ｂ０３（図５．３参照）、スキルテーブル１Ｂ０７（図５．７参照）、実績テーブル１Ｂ０８（図５．８参照）、グループテーブル１Ｂ１０（図５．１０参照）、メンバテーブル１Ｂ１１（図５．１１参照）、評価テーブル１Ｂ１４（図５．１４参照）、要望テーブル１Ｂ１５（図５．１５参照）から候補グループ・候補メンバ（氏名、作業開始日、コスト、組織）、予定コストを取得、表示する（図４．１の４Ａ１０）。候補メンバは複数選択することができ、その選択したメンバ（同４Ａ１６）で構成されるグループに対し、グループ名を入力する（同４Ａ１７）。
【０１９９】
「登録」ボタン４Ａ１８を押下すると、プロジェクト候補者変更・申請画面３Ａ０７へ遷移する。候補メンバが選択されていない状態、選択した候補メンバ内にリーダクラスのメンバが１人もいない状態またはグループ名が入力されていない状態で「登録」ボタン４Ａ１８を押下した場合、エラーメッセージを表示する。
【０２００】
［スキル選択サブ画面３Ａ０５］
スキル選択サブ画面３Ａ０５では、コードマスタ１Ｂ０１（図５．１参照）からスキルの情報を取得、表示し、チェックボックスにチェックを付けることでスキルを選択する（複数選択可能）。
【０２０１】
スキルを選択した状態で「ＯＫ」ボタンを押下すると、呼び出し元であるプロジェクト候補者検索画面３Ａ０４へ選択したスキルのデータを渡して、スキル選択サブ画面３Ａ０５を閉じる（プロジェクト候補者検索画面３Ａ０４に選択したスキルを表示する）。スキルを選択せずに「ＯＫ」ボタンを押下した場合、エラーメッセージを表示する。
【０２０２】
［組織選択サブ画面３Ａ０６］
組織選択サブ画面３Ａ０６では、組織マスタ１Ｂ０４から現在進行中の組織を取得し、プルダウンボックスにて選択可能とする。
【０２０３】
組織を選択した状態で「ＯＫ」ボタンを押下すると、呼び出し元であるプロジェクト候補者検索画面３Ａ０４へ選択した組織のデータを渡して、組織選択サブ画面３Ａ０６を閉じる（プロジェクト候補者検索画面３Ａ０４に選択した組織を表示する）。組織を選択せずに「ＯＫ」ボタンを押下した場合はエラーメッセージを表示する。
【０２０４】
［プロジェクト候補者変更・申請画面３Ａ０７］
プロジェクト候補者変更・申請画面３Ａ０７では、プロジェクト候補者検索画面３Ａ０４で登録したグループ名、メンバ名を社員テーブル１Ｂ０３（図５．３参照）、グループテーブル１Ｂ１０（図５．１０参照）、メンバテーブル１Ｂ１１（図５．１１参照）、申請テーブル１Ｂ１７（図５．１７参照）から取得、表示する。
【０２０５】
メンバの変更をする場合は、削除するメンバを選択し（複数選択可）、「削除」ボタンを押下する。グループのメンバを上長へ申請（承認依頼）する場合は、申請先を選択の上、「申請」ボタンを押下する（申請先選択の「選択」ボタンを押下するとプロジェクト候補者変更・申請画面３Ａ０７の上に別画面として申請先選択サブ画面３Ａ０８を表示する）。
【０２０６】
「申請」ボタン押下後はメニュー画面３Ａ０２へ遷移する。「続けて登録」ボタンを押下した場合は、プロジェクト候補者検索画面３Ａ０４へ遷移する。なお、メンバを全員削除した場合や、メンバを削除後グループ内にリーダクラスのメンバが１人もいなくなってしまった場合は、「申請」ボタンを非活性にして申請できないようにする。
【０２０７】
［申請先選択サブ画面３Ａ０８］
申請先選択サブ画面３Ａ０８では、検索条件（社員番号、姓、名）を入力する。検索条件を入力後、「検索」ボタンを押下し、社員テーブル１Ｂ０３（図５．３参照）、組織マスタ１Ｂ０４から社員の情報を取得、表示し、選択可能とする。申請先を選択した状態で「ＯＫ」ボタンを押下すると、呼び出し元であるプロジェクト候補者変更・申請画面３Ａ０７へ選択した申請先のデータを渡して、申請先選択サブ画面３Ａ０８を閉じる（プロジェクト候補者変更・申請画面３Ａ０７に選択した申請先を表示する）。申請先を選択せずに「ＯＫ」ボタンを押下した場合、エラーメッセージを表示する。
【０２０８】
［プロジェクト候補者登録画面３Ａ０９］
プロジェクト候補者登録画面３Ａ０９は、メールに貼られたリンクからログイン画面３Ａ０１を経由して遷移する（メールはプロジェクト候補者変更・申請画面３Ａ０７で申請先として選択されていた上長宛てに届く）。
【０２０９】
プロジェクト候補者登録画面３Ａ０９では、プロジェクト候補者変更・申請画面３Ａ０７で申請されたグループ名、メンバ名をコードマスタ１Ｂ０１（図５．１参照）、プロジェクトテーブル１Ｂ０９（図５．９参照）、グループテーブル１Ｂ１０（図５．１０参照）、メンバテーブル１Ｂ１１（図５．１１参照）、申請テーブル１Ｂ１７（図５．１７参照）から取得、表示する。
【０２１０】
差戻しにする場合は差戻し理由を入力し、「差戻し」ボタンを押下する。プロジェクトメンバとして承認する場合は、「登録」ボタンを押下する。「差戻し」ボタンを押下した場合も、「登録」ボタンを押下した場合も、共にメニュー画面３Ａ０２へ遷移する。
【０２１１】
［プロジェクトフォロー対象者検索画面３Ａ１０］（図４．２参照）
プロジェクトフォロー対象者検索画面３Ａ１０では、検索条件（欠勤日数４Ｂ０１、年休日数４Ｂ０２、進捗（遅延）日数４Ｂ０３、超勤時間４Ｂ０４、グループ名４Ｂ０５）を入力する。
【０２１２】
検索条件を入力後、「検索」ボタン４Ｂ０６を押下し、社員テーブル１Ｂ０３（図５．３参照）、フォローテーブル１Ｂ１３（図５．１３参照；フォローテーブル１Ｂ１３はコードマスタ１Ｂ０１、勤務表テーブル１Ｂ０５、年休テーブル１Ｂ０６、進捗表テーブル１Ｂ１２を元に作成）からフォロー対象者（氏名、欠勤日数、年休日数、進捗日数、超勤時間、グループ名）を取得、表示する（図４．２の４Ｂ０７）。
【０２１３】
検索結果が０件の場合は、対象データなしのメッセージを表示する。必要に応じて退場者を選択する（複数選択可）。「登録」ボタン４Ｂ１３を押下すると、プロジェクト退場者変更・申請画面３Ａ１１へ遷移する。退場者が選択されていない状態で「登録」ボタン４Ｂ１３を押下した場合、エラーメッセージを表示する。
【０２１４】
［プロジェクト退場者変更・申請画面３Ａ１１］
プロジェクト退場者変更・申請画面３Ａ１１では、プロジェクトフォロー対象者検索画面３Ａ１０で登録した退場者（氏名、グループ名）を社員テーブル１Ｂ０３（図５．３参照）、フォローテーブル１Ｂ１３（図５．１３参照）、申請テーブル１Ｂ１７（図５．１７参照）から取得、表示する。
【０２１５】
メンバの変更をする場合は、削除するメンバを選択し（複数選択可）、「削除」ボタンを押下する。グループのメンバを上長へ申請（承認依頼）する場合は、申請先を選択の上、「申請」ボタンを押下する（申請先選択の「選択」ボタンを押下するとプロジェクト退場者変更・申請画面３Ａ１１の上に別画面として申請先選択サブ画面３Ａ１２を表示する）。
【０２１６】
「申請」ボタン押下後はメニュー画面３Ａ０２へ遷移する。「続けて登録」ボタンを押下した場合は、プロジェクトフォロー対象者検索画面３Ａ１０へ遷移する。なお、メンバを全員削除した場合は、「申請」ボタンを非活性にして申請できないようにする。
【０２１７】
［申請先選択サブ画面３Ａ１２］
申請先選択サブ画面３Ａ１２では、検索条件（社員番号、姓、名）を入力する。検索条件を入力後、「検索」ボタンを押下し、社員テーブル１Ｂ０３（図５．３参照）、組織マスタ１Ｂ０４（図５．４参照）から社員の情報を取得、表示し、選択可能とする。
【０２１８】
申請先を選択した状態で「ＯＫ」ボタンを押下すると、呼び出し元であるプロジェクト退場者変更・申請画面３Ａ１１へ選択した申請先のデータを渡して、申請先選択サブ画面３Ａ１２を閉じる（プロジェクト退場者変更・申請画面３Ａ１１に選択した申請先を表示する）。申請先を選択せずに「ＯＫ」ボタンを押下した場合、エラーメッセージを表示する。
【０２１９】
［プロジェクト退場者登録画面３Ａ１３］
プロジェクト退場者登録画面３Ａ１３は、メールに貼られたリンクからログイン画面３Ａ０１を経由して遷移する（メールはプロジェクト退場者変更・申請画面３Ａ１１で申請先として選択されていた上長宛てに届く）。
【０２２０】
プロジェクト退場者登録画面３Ａ１３では、プロジェクト退場者変更・申請画面３Ａ１１で申請された退場者（氏名、グループ名、退場理由）を社員テーブル１Ｂ０３（図５．３参照）、実績テーブル１Ｂ０８（図５．８参照）、グループテーブル１Ｂ１０（図５．１０参照）、メンバテーブル１Ｂ１１（図５．１１参照）、フォローテーブル１Ｂ１３（図５．１３参照）、申請テーブル１Ｂ１７（図５．１７参照）から取得、表示する。差戻しにする場合は差戻し理由を入力し、「差戻し」ボタンを押下する。
【０２２１】
退場者として承認する場合は、「登録」ボタンを押下する。「差戻し」ボタンを押下した場合も、「登録」ボタンを押下した場合も、共にメニュー画面３Ａ０２へ遷移する。
【０２２２】
［プロジェクトメンバ評価登録画面３Ａ１４］（図４．３参照）
プロジェクトメンバ評価登録画面３Ａ１４では、検索条件（グループ名）を選択する（図４．３の４Ｃ０１）。検索条件を選択後、コードマスタ１Ｂ０１（図５．１参照）、社員テーブル１Ｂ０３（図５．３参照）、グループテーブル１Ｂ１０（図５．１０参照）、メンバテーブル１Ｂ１１（図５．１１参照）、評価テーブル１Ｂ１４（図５．１４参照）から評価対象者（氏名、評価）を取得、表示する（図４．３の４Ｃ０２）。必要に応じて評価対象者を選択し、評価（図４．３の４Ｃ０３）、コメント（図４．３の４Ｃ０４）を入力する。「登録」ボタン（図４．３の４Ｃ０５）を押下後、登録完了のメッセージを表示する。
【０２２３】
［個人要望登録画面３Ａ１５］（図４．４参照）
個人要望登録画面３Ａ１５では、コードマスタ１Ｂ０１（図５．１参照）、社員テーブル１Ｂ０３（図５．３参照）、要望テーブル１Ｂ１５（図５．１５参照）から異動の要望の有無を、要望詳細テーブル１Ｂ１６（図５．１６参照）から、個人要望情報（仕事量（図４．４の４Ｄ０１）、勤務時間（同４Ｄ０２）、仕事内容（同４Ｄ０３）、人間関係（同４Ｄ０４）、異動希望（同４Ｄ０５）、異動希望日（同４Ｄ０６）、コメント（同４Ｄ０７））を取得、表示する。
【０２２４】
なお、ユーザが初めて本画面を表示した場合は全て空白を表示する。必要に応じて個人要望情報を入力（変更）する。「登録」ボタン（図４．４の４Ｄ０８）を押下後、登録完了のメッセージを表示する。
【０２２５】
［申請状況照会画面３Ａ１６］
申請状況照会画面３Ａ１６では、社員テーブル１Ｂ０３（図５．３参照）、プロジェクトテーブル１Ｂ０９（図５．９参照）、申請テーブル１Ｂ１７（図５．１７参照）から、ログインしているユーザに関連している各申請の情報（申請ＩＤ、申請内容、ステータス（申請中フラグ，差戻フラグ，決裁フラグ，取消フラグなど）、次処理者）を取得し、表示する。
【０２２６】
以下、本発明に係る操作端末３に表示される画面レイアウトについて説明する。
図４．１、図４．２、図４．３、図４．４は、本発明に係るプロジェクト人材選定支援管理システムにおける画面レイアウトの一例を示す図である。以下、図４．１、図４．２、図４．３、図４．４に示す各画面レイアウト図について詳細に説明する。
【０２２７】
図４．１は、プロジェクト候補者検索画面の画面レイアウトの一例を示す図である。
当画面では、新規立ち上げ時のプロジェクトにおけるメンバ候補検索はもちろんのこと、進行中の既存プロジェクトにおいてもチームの追加に伴うメンバ候補検索や既存チームに対するメンバ補充に伴うメンバ候補検索ができる。
【０２２８】
新規プロジェクトによるメンバ候補検索か、既存プロジェクトによるメンバ候補検索かは、メニュー画面３Ａ０２にてプロジェクトを選択したか否かにより判定する（プロジェクトを選択していない場合は新規、プロジェクトを選択した場合は既存）。
【０２２９】
メニュー画面３Ａ０２にてプロジェクトを未選択で遷移してきた場合は、ポップアップを表示し、プロジェクト名を入れた後、新規プロジェクトモードになり画面タイトル４Ａ１９にポップアップで入力したプロジェクト名が設定される。
【０２３０】
メニュー画面３Ａ０２にてプロジェクトを選択した状態で遷移してきた場合は、既存プロジェクトモードになり画面タイトル４Ａ１９にメニュー画面３Ａ０２で選択したプロジェクト名が設定される。
【０２３１】
画面から指定する検索条件として、スキル情報４Ａ０１、作業開始日４Ａ０２、グループ人数４Ａ０３、グループコスト４Ａ０４、組織情報４Ａ０５、グループ名４Ａ０７がある。
【０２３２】
スキル情報４Ａ０１としては技術（言語、資格、ソフト知識、ハード知識）に関すること、業務（金融、官公庁、流通、電力等）に関する情報を複数指定できる。作業開始日４Ａ０２はその指定した日から参画できるかどうかを条件として指定できる。
【０２３３】
グループ人数４Ａ０３やグループコスト４Ａ０４は、当画面では１チーム単位でメンバ候補を選択する機能になっているためグループとしての制約も条件として指定することが可能になっている。
【０２３４】
グループ名４Ａ０７については、既存のプロジェクトにおいて、あるグループにメンバを追加する場合にそのグループを指定できる条件になっている。
【０２３５】
更に、メンバ候補を検索するにあたり画面で指定する条件以外に常に最適なメンバ候補となるべく条件をあらかじめ設定している。その条件は、第三者における評価情報からグループ内におけるお互いの評価が良好であることと、グループの中にリーダクラスにあたるメンバが１名選択されていること、他にグループが形成されていた場合、各グループのリーダたるメンバ同士の評価が高いものも条件としている。
【０２３６】
以上の検索条件により、当画面のグループ検索ボタン４Ａ０６を押下すると、候補メンバ一覧４Ａ１０に検索条件に該当したメンバ候補者が一覧表示される。また、予定コスト４Ａ１１には、メンバ候補となったメンバの単価の合計値が設定される。
【０２３７】
候補グループプルダウン４Ａ０９は、新規時は初期値としてグループ１と表示される。検索条件にグループ名４Ａ０７に指定があり個人選択ボタン４Ａ０８を押下した場合は、指定されたグループ名が表示される。
【０２３８】
検索処理実行後の手順として、操作キーボタンを使用して、左記の候補メンバ一覧４Ａ１０から右記の候補メンバ一覧４Ａ１６へ最終メンバ候補者を移動させる操作を行う。
【０２３９】
操作キーボタン４Ａ１２は一覧上のリストを全て左から右へ移動させる。操作キーボタン４Ａ１３は一覧上の選択された行のみ左から右へ移動させる。操作キーボタン４Ａ１４は一覧上のリストを全て右から左へ移動させる。操作キーボタン４Ａ１５は一覧上の選択された行のみ右から左へ移動させる。
【０２４０】
移動させた後、グループ名入力欄４Ａ１７に任意のグループ名を入力し登録ボタン４Ａ１８を押下することで、当画面にて決定したメンバ候補者情報が仮登録される。
【０２４１】
図４．２は、プロジェクトフォロー対象者検索画面の画面レイアウトの一例を示す図である。
当画面では、勤務表や進捗表などから休む頻度の多いメンバ、進捗が遅れているメンバ、規定の残業時間を超えているメンバを検索できる。また、プロジェクトからの退場処理（仮登録）もできる。
【０２４２】
画面から指定する検索条件として、欠勤４Ｂ０１、年休４Ｂ０２、進捗（遅延）４Ｂ０３、超勤４Ｂ０４、グループ名４Ｂ０５がある。
【０２４３】
欠勤４Ｂ０１では欠勤日数を、年休４Ｂ０２では年休日数を、進捗（遅延）４Ｂ０３では遅延日数を、超勤４Ｂ０４では超勤時間を、グループ名４Ｂ０５には退場者がいるグループ名を指定し、検索条件とすることができる。
【０２４４】
検索条件を入力後、検索ボタン４Ｂ０６を押下することで、フォロー対象者一覧４Ｂ０７に該当者が出力される。検索処理実行後の手順として、操作キーボタンを使用して、フォロー対象者一覧４Ｂ０７から右記の退場者一覧４Ｂ１２へ最終退場者を移動させる操作を行う。
【０２４５】
操作キーボタン４Ｂ０８は一覧上のリストを全て左から右へ移動させる。操作キーボタン４Ｂ０９は一覧上の選択された行のみ左から右へ移動させる。操作キーボタン４Ｂ１０は一覧上のリストを全て右から左へ移動させる。操作キーボタン４Ｂ１１は一覧上の選択された行のみ右から左へ移動させる。
【０２４６】
移動させた後、登録ボタン４Ｂ１３を押下することで、当画面にて決定した退場者情報が仮登録される。
【０２４７】
図４．３は、プロジェクトメンバ評価登録画面の画面レイアウトの一例を示す図である。
当画面では、同グループのメンバに対する評価を入力することができる。グループ名４Ｃ０１を選択することによって、評価対象者一覧４Ｃ０２に選択したグループ名のメンバが表示される。
【０２４８】
評価対象者一覧４Ｃ０２で選択したメンバに対する評価を評価一覧４Ｃ０３から選択し、コメント４Ｃ０４には評価一覧で表現されてない、長所や短所を入力する。登録ボタン４Ｃ０５を押下することで、当画面にて入力した評価情報が登録される。
【０２４９】
図４．４は、個人要望登録画面の画面レイアウトの一例を示す図である。
当画面では、仕事量・勤務時間・仕事内容・人間関係・異動希望等の個人の要望を入力でき、この画面での異動希望をもとに新規プロジェクト立ち上げ時や途中のメンバ変更などを行う。
【０２５０】
仕事量４Ｄ０１には仕事量の『多い』，『普通』，『少ない』を、勤務時間４Ｄ０２には勤務時間の『多い』，『普通』，『少ない』を、仕事内容４Ｄ０３には仕事内容が『合っている』，『合っていない』を、人間関係４Ｄ０４には人間関係が『良い』，『悪い』を、異動希望４Ｄ０５には異動希望の『あり』，『なし』を、異動希望４Ｄ０５が『あり』の場合は異動希望日４Ｄ０６に日付の入力を、コメント４Ｄ０７には要望を記述し、最後に登録ボタン４Ｄ０８を押下することで、当画面にて入力した個人要望情報が登録される。
【０２５１】
なお、上記で説明した処理部１Ａにおける各手段（プロジェクト候補者検索処理手段１Ａ０１、プロジェクト候補者登録処理手段１Ａ０２、プロジェクトフォロー対象者検索処理手段１Ａ０３、プロジェクト退場者登録処理手段１Ａ０４、プロジェクトメンバ評価登録処理手段１Ａ０５および個人要望登録処理手段１Ａ０６）は、サーバ（プロジェクト人材選定支援管理システム）１を構成するコンピュータのＣＰＵやメモリなどのハードウェアにより各手段に対応するプログラムを実行（図２．１〜図２．６参照）することにより実現される。また、各手段に対応するプログラムはインターネットなどのネットワークなどのネットワークやＣＤ−ＲＯＭ、ＤＶＤ、ＦＤなどの記録媒体を介して市場に流通させることができる。
【符号の説明】
【０２５２】
１：サーバ（プロジェクト人材選定支援および人材管理システム（プロジェクト人材選定支援管理システム））
２：ネットワーク（インターネット）
３：操作端末
１Ａ：処理部
１Ｂ：データ部
１Ａ０１：プロジェクト候補者検索処理手段
１Ａ０２：プロジェクト候補者登録処理手段
１Ａ０３：プロジェクトフォロー対象者検索処理手段
１Ａ０４：プロジェクト退場者登録処理手段
１Ａ０５：プロジェクトメンバ評価登録処理手段
１Ａ０６：個人要望登録処理手段
１Ｂ０１，２Ｅ１７，２Ｆ１３：コードマスタ
１Ｂ０２：認証テーブル
１Ｂ０３，２Ａ１１，２Ａ１５，２Ａ１７，２Ａ１９，２Ｂ１２，２Ｂ２０，２Ｃ１８，２Ｄ１２，２Ｄ１９，２Ｅ１５：社員テーブル
１Ｂ０４：組織マスタ
１Ｂ０５，２Ｃ１２：勤務表テーブル
１Ｂ０６，２Ｃ１３：年休テーブル
１Ｂ０７：スキルテーブル
１Ｂ０８．２Ｄ２３：実績テーブル
１Ｂ０９，２Ｂ１５，２Ｂ２５，２Ｂ２６，２Ｃ１９，２Ｅ１４：プロジェクトテーブル
１Ｂ１０，２Ｂ１３，２Ｂ２１，２Ｄ２５，２Ｅ１２：グループテーブル
１Ｂ１１，２Ｂ１４，２Ｂ１６，２Ｂ１８，２Ｂ２２，２Ｄ２４，２Ｅ１１，２Ｅ１３：メンバテーブル
１Ｂ１２，２Ｃ１１：進捗表テーブル
１Ｂ１３，２Ｃ１６，２Ｃ１７，２Ｃ２０，２Ｄ１３，２Ｄ１４，２Ｄ１５，２Ｄ１７，２Ｄ２０，２Ｅ１８：フォローテーブル
１Ｂ１４，２Ｃ１４，２Ｅ１６：評価テーブル
１Ｂ１５，２Ｃ１５，２Ｆ１１，２Ｆ１４：要望テーブル
１Ｂ１６，２Ｆ１２，２Ｆ１５：要望詳細テーブル
１Ｂ１７，２Ｂ１１，２Ｂ１７，２Ｂ１９，２Ｂ２３，２Ｂ２４，２ｃ１１,２Ｄ１６，２Ｄ１８，２Ｄ２１，２Ｄ２２：申請テーブル
【技術分野】
【０００１】
本発明は、作業プロジェクトチームを形成する際の人材選定支援技術に係り、特に、安定した作業プロジェクトチームを形成するために、プロジェクト進行中であっても、チーム内およびチーム間における人間関係も考慮し、最適な人材の選定を行うことが可能な人材選定支援管理システム、人材選定支援管理方法、およびそのためのプログラムに関する。
【背景技術】
【０００２】
近年、技術進歩が進みプロジェクトも大型化する傾向にあり、共通のプロジェクトを複数のメンバが協働して遂行することが多くなっている。職場で能力を発揮できるか否かは、職場の環境、雰囲気、人間関係またはモチベーションなど、精神面に依存するところが大きい。
【０００３】
例えば、プロジェクトチームのメンバ個人でみた場合、個人の技術、能力がいくら優れていても、周囲との人間関係が悪いと大きなストレスになり、仕事の能率も下がり、最悪な場合は精神的に病んで会社へ出社できなくなってしまうケースもある。
【０００４】
また、プロジェクトチーム全体でみた場合、人間関係が悪い者同士を同じチームメンバにしてしまうと、メンバ間のコミュニケーションが円滑に行われず、プロジェクト作業に支障が生じてチームとしてのパフォーマンスが十分発揮できないようになり、その結果、プロジェクト全体の進捗に大きく影響しかねない。
【０００５】
また、チーム内としては人間関係がいくら良好であっても、チーム相互間においてキーマン（例えば、プロジェクトマネージャーやプロジェクトリーダ）同士の人間関係が良好でない場合はプロジェクトとしての機能が低下してしまう。
【０００６】
このような背景の中、チーム形成時の条件として、個人のスキルや実績だけではなく、人間関係も考慮対象の要素に含めた技術開発が進められており、例えば、特開２００１−２８２９６５号公報（特許文献１）、特開２００７−２６４０４号公報（特許文献２）、特開２００７−１２２１４４号公報（特許文献３）などが先行技術文献としてあげられる。
【０００７】
特許文献１では、プロジェクトチームメンバ、チーム生成手法として、メンバのスキルと経験情報以外に人間関係に関する情報も考慮した手法を提供しており、特に、人間関係においてはプロジェクトメンバ間の評価に着目し、他のメンバに対する相互評価を取得して登録する手法とチーム生成時に前記登録された相互評価情報を提供する手法について開示されている。
【０００８】
特許文献２では、プロジェクトチームメンバ、チーム生成手法として、過去のプロジェクトデータからプロジェクトに適合したメンバを効率的に決定するための手法について開示されている。プロジェクトに適合する要件として、他のメンバから実績評価情報（アンケート形式で品質評価項目としてスキル、プロジェクトに対する経験、情報の共有度、品質の維持、運用／保守性などの観点に基づいた回答情報）や個人情報（過去の経験プロジェクト情報、コスト（給料）、資格や既知の性格分析など）から決定している。
【０００９】
特許文献３では、プロジェクトチームメンバ、チーム生成手法として、過去のプロジェクトに対する評価とそのプロジェクトを担当したプロジェクトチームのチークとしての能力（チームを構成するメンバの能力により算出）との相関を計算し、その相関に基づいてプロジェクトに対する評価を高めるようなチームとチームとしての能力特性値を実現するようにメンバの選定を行うようにしている。評価を高めるための要因として、過去のプロジェクト実績から担当するチームとしての能力やメンバ間の相性における成功要因情報を考慮している。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００１−２８２９６５号公報
【特許文献２】特開２００７−２６４０４号公報
【特許文献３】特開２００７−１２２１４４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
プロジェクト開始当初から選出されたメンバが、プロジェクトが完了するまでの間に何も問題なく最適な状態で各チームが維持できることは難しい。通常、プロジェクト進行中にメンバ自身、メンバ構成（プロジェクトチーム体制）に問題があれば、その都度、プロジェクトマネージャーやプロジェクトリーダにあたるメンバが該当者をフォローしたり、必要があれば体制を見直して補強したり再編成したり軌道修正しながらプロジェクトを進める必要があると考えられる。
【００１２】
しかしながら、上記背景技術に提示した特許文献に記載されたものは、最初のプロジェクトチーム形成時のメンバ選定に関するものであり、上記の如き観点から、メンバ自身、プロジェクトチーム（メンバ構成）選定後のプロジェクト経過中にプロジェクトチームの体制を随時見直して軌道修正することについては明記されていない。
【００１３】
また、プロジェクトチームとしてのパフォーマンスを高める手段として、チーム内における人間関係が考慮されているのは見受けられるが、チーム間を意識した人間関係についての考慮は全く見受けられない。
【００１４】
以上のことから明らかなように、従来、メンバ選定における要件として上記背景技術にあるようにメンバの実績、能力、第三者からの評価などから分析するケースがほとんどであり、プロジェクト経過中において、メンバの自分自身における要望および希望事項についてもプロジェクト退場となる大きな要因となれば、これらの要望や希望事項も人材選定条件のひとつとして考慮する必要があると考えられるが、プロジェクト経過中に、状況に応じたメンバ選定をはじめメンバ選定のきっかけとなる情報を検知することは行われていなかった。また、チーム間の関係を考慮した人材選定方法についても検討されていなかった。
【００１５】
そこで、本発明は、メンバ自身、プロジェクトチーム（メンバ構成）選定後のプロジェクト経過中におけるプロジェクトチームの体制を随時見直して軌道修正することが可能な、また、プロジェクトチームとしてのパフォーマンスを高める手段として、チーム内における人間関係に加えて、チーム間を意識した人間関係についても考慮することによって安定した体制で運営可能な人材選定支援管理システムおよび人材選定支援管理方法、ならびにそのためのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明は、上記目的を達成するための手段として、プロジェクト開始から終了まで安定したチームを維持するために、その阻害要因となる情報を随時あるいは定期的にバッチ処理で各プロジェクトメンバの勤務状況（欠勤、年休、超勤時間）、作業進捗状況（遅延日数）、他のメンバからの評価（例えば、５段階評価）情報およびプロジェクトメンバ自身の要望（異動希望、人間関係）から収集し、それらの情報から阻害要因となる基準を決め、基準から外れるプロジェクトメンバ情報を判定し抽出する。
【００１７】
抽出されたプロジェクトメンバ情報は、まず対象者の有無を知らせるメールを管理者（プロジェクトマネージャー等）たるメンバに配信することで日々状況を把握することができる。また、抽出されたメンバ一覧や詳細内容を参照できる画面を用意し、内容によってフォローし、さらに退場者とする場合の登録機能も提供する。
【００１８】
これにより、随時あるいは定期的にプロジェクトメンバの状況を把握することができるため、早期対策を打つことが可能になる。また、メンバの入れ替えについても、プロジェクト進行中であってもシステムにて支援する機能を備えているため、管理者側の負担軽減につながる。
【００１９】
また、本発明においては、安定したチームを維持するために、もうひとつのアプローチとしてチーム間においても人間関係に配慮したチーム生成機能を提供する。チーム間における人間関係の配慮方法として、互いのチームリーダにあたるメンバ同士が最適な関係になるように配慮する。
【００２０】
これにより、権限のあるチームリーダ同士のコミュニケーションが良好であれば、チーム間の連携も円滑化につながり、プロジェクトとしても安定した運用を築くことが可能になる。
【００２１】
さらに、本発明においては、上記機能に付け加え、プロジェクト進行期間中に以下の機能を実現できることも特徴としている。
（ａ）プロジェクトメンバ自身が仕事内容や人間関係について要望、希望事項があればいつでも登録することができる。
（ｂ）プロジェクトメンバの退場が必要になった場合、退場者の候補となったメンバについてワークフローの機能を使って適正な手順と判定を機械的に運用することができる。
（ｃ）プロジェクトメンバの増員が必要となった場合に既存のチームに新たなメンバを追加する機能やチーム単位で新しくメンバを追加する機能に、チームとメンバの人間関係に配慮した最適なメンバ候補を抽出することができ、退場者を決定する機能と同様にワークフローの機能も兼ね備え、適正な手順と判定を機械的に運用することができる。
【００２２】
より具体的には、
ａ）本発明に係るプロジェクト人材選定支援管理システムは、安定したプロジェクトチームを維持するためのプロジェクト人材選定支援管理システムであって、プロジェクト進行期間中に各プロジェクトメンバの勤務状況，作業進捗状況，第三者からの評価情報およびプロジェクトメンバ個人の異動要望に関する情報を随時あるいは定期的に収集する収集手段と、該収集手段により収集された情報に基づいて安定したプロジェクトチームの維持の阻害要因となる情報を判定し、該該阻害要因となる情報を持つメンバ情報を退場候補者として抽出し退場者を選定する権限を有する管理者に提供するメンバ情報提供手段と、該退場候補者に基づいて退場者を選択して登録する手段、を有することを特徴とする。
【００２３】
ｂ）また、上記ａ）において、プロジェクト進行期間中、随時あるいは定期的に、プロジェクトメンバ自身が仕事量，勤務時間，仕事内容，人間関係，あるいは異動希望に関する要望事項を登録する手段を有することを特徴とする。
【００２４】
ｃ）また、上記ａ）またはｂ）において、プロジェクト進行期間中にプロジェクトからプロジェクトメンバの退場が必要になった場合に前記退場候補者を退場者として登録する手段と、該退場者を他のプロジェクトメンバ候補対象者として登録する手段を有することを特徴とする。
【００２５】
ｄ）上記ａ）からｃ）いずれかにおいて、プロジェクト進行期間中にメンバの増員が必要となった場合に、既存のチームに新たなメンバを追加する手段とチーム単位で新しくメンバを追加する手段に加え、チームとメンバの人間関係について最適なメンバ候補を提供する手段を有することを特徴とする。
【００２６】
ｅ）上記ａ）からｄ）のいずれかにおいて、プロジェクトメンバを選定する場合、メンバの過去実績、スキル、およびコストを含むメンバ自身の能力に加え、チーム内におけるメンバ間の人間関係およびチーム間における人間関係を考慮して最適なメンバおよびチーム構成を選定する手段を有することを特徴とする。
【００２７】
ｆ）本発明に係るプログラムは、コンピュータを、上記ａ）からｅ）のいずれかに記載のプロジェクト人材選定支援管理システムにおける各手段として機能させることを特徴とするプログラムである。
【００２８】
ｇ）本発明に係るプロジェクト人材選定支援管理方法は、安定したプロジェクトチームを維持するためのコンピュータを用いたプロジェクト人材選定支援管理方法であって、プロジェクト進行期間中に各プロジェクトメンバの勤務状況，作業進捗状況，第三者からの評価情報およびプロジェクトメンバ個人の異動要望に関する情報を随時あるいは定期的に収集する収集ステップと、該収集ステップにより収集された情報に基づいて安定したプロジェクトチームの維持の阻害要因となる情報を判定し、該該阻害要因となる情報を持つメンバ情報を退場候補者として抽出し退場者を選定する権限を有する管理者に提供するメンバ情報提供ステップと、該退場候補者に基づいて退場者を選択して登録するステップと、を有することを特徴とする。
【００２９】
ｈ）上記ｇ）において、プロジェクト進行期間中、随時あるいは定期的に、プロジェクトメンバ自身が仕事量，勤務時間，仕事内容，人間関係，あるいは異動希望に関する要望事項を登録するステップを有することを特徴とする。
【００３０】
ｉ）上記ｇ）またはｈ）において、プロジェクト進行期間中にプロジェクトからプロジェクトメンバの退場が必要になった場合に前記退場候補者を退場者として登録するステップと、該退場者を他のプロジェクトメンバ候補対象者として登録するステップを有することを特徴とする。
【００３１】
ｊ）上記ｇ）からｉ）のいずれかにおいて、プロジェクト進行期間中にメンバの増員が必要となった場合に、既存のチームに新たなメンバを追加するステップとチーム単位で新しくメンバを追加するステップに加え、チームとメンバの人間関係について最適なメンバ候補を提供するステップを有することを特徴とする。
【００３２】
ｋ）上記ｇ）からｊ）のいずれかにおいて、プロジェクトメンバを選定する場合、メンバの過去実績、スキル、およびコストを含むメンバ自身の能力に加え、チーム内におけるメンバ間の人間関係およびチーム間における人間関係を考慮して最適なメンバおよびチーム構成を選定するステップを有することを特徴とする。
【発明の効果】
【００３３】
上記構成を採用することにより、プロジェクト開始から完了までのプロジェクト進行の全期間を通じて、メンバ自身、メンバ間に問題があれば、随時あるいは定期的に、例えば日々決まった時間に問題に関する情報を自動的に収集し、日々状況を確認することができる。
【００３４】
また、一個人の要望事項も日々収集が可能なので、問題があれば、早期対策を打つことができる。また、状況に応じて、随時、選定時点における最適なメンバ選定も可能になる。
【００３５】
このように、本発明は、上記構成を採用したことによって、プロジェクト経過中におけるプロジェクトチームの体制を随時見直して軌道修正することが可能な、また、チーム内における人間関係に加えて、チーム間を意識した人間関係についても考慮した、プロジェクトチームとしてのパフォーマンスの高い安定した体制で運営可能な人材選定支援管理システムおよび人材選定支援管理方法、ならびにそのためのプログラムを実現できる。
【図面の簡単な説明】
【００３６】
【図１】本発明に係るプロジェクト人材選定支援および人材管理システム（人材選定支援管理システム）の全体構成図である。
【図２．１】図１におけるプロジェクト候補者検索処理手段の処理動作例を示すフローチャートである。
【図２．２】図１におけるプロジェクト候補者登録処理手段の処理動作例を示すフローチャートである。
【図２．３】図１におけるプロジェクトフォロー対象者検索処理手段の処理動作例を示すフローチャートである。
【図２．４】図１におけるプロジェクト退場者登録処理手段の処理動作例を示すフローチャートである。
【図２．５】図１におけるプロジェクトメンバ評価登録処理手段の処理動作例を示すフローチャートである。
【図２．６】図１における個人要望事項登録処理手段の処理動作例を示すフローチャートである。
【図３】図１における画面遷移図である。
【図４．１】図１におけるプロジェクト候補者検索処理手段で用いられるプロジェクト候補者検索画面の画面レイアウトの一例を示す図である。
【図４．２】図１におけるプロジェクトフォロー対象者検索処理手段で用いられるプロジェクトフォロー対象者検索画面の画面レイアウトの一例を示す図である。
【図４．３】図１におけるプロジェクトメンバ評価登録処理手段で用いられるプロジェクトメンバ評価登録画面の画面レイアウトの一例を示す図である。
【図４．４】図１における個人要望登録処理手段で用いられる個人要望登録画面の画面レイアウトの一例を示す図である。
【図５．１】図１におけるコードマスタのＤＢ構成例である。
【図５．２】図１における認証テーブルのＤＢ構成例である。
【図５．３】図１における社員テーブルのＤＢ構成例である。
【図５．４】図１における組織マスタのＤＢ構成例である。
【図５．５】図１における勤務表テーブルのＤＢ構成例である。
【図５．６】図１における年休テーブルのＤＢ構成例である。
【図５．７】図１におけるスキルテーブルのＤＢ構成例である。
【図５．８】図１における実績テーブルのＤＢ構成例である。
【図５．９】図１におけるプロジェクトテーブルのＤＢ構成例である。
【図５．１０】図１におけるグループテーブルのＤＢ構成例である。
【図５．１１】図１におけるメンバテーブルのＤＢ構成例である。
【図５．１２】図１における進捗表テーブルのＤＢ構成例である。
【図５．１３】図１におけるフォローテーブルのＤＢ構成例である。
【図５．１４】図１における評価テーブルのＤＢ構成例である。
【図５．１５】図１における要望テーブルのＤＢ構成例である。
【図５．１６】図１における要望詳細テーブルのＤＢ構成例である。
【図５．１７】図１における申請テーブルのＤＢ構成例である。
【発明を実施するための形態】
【００３７】
（実施例）
以下、本発明の一実施例を、図面を用いて詳細を説明する。
図１は、本発明に係るプロジェクト人材選定支援および人材管理システム（本発明においては単に「プロジェクト人材選定支援管理システム」ともいう）となるサーバ１の全体構成図を示している。同図において、該サーバ１はネットワーク（インターネット）２を介して操作端末３と接続されており、相互に通信可能になっている。
【００３８】
同図に示すように、本発明に係るプロジェクト人材選定支援管理システム（サーバ）１は、大きく分けて、処理部１Ａと、該処理部１Ａで使用されるデータを保持するデータ部１Ｂと、から構成される。
【００３９】
処理部１Ａは、プロジェクト候補者検索処理手段１Ａ０１、プロジェクト候補者登録処理手段１Ａ０２、プロジェクトフォロー対象者検索処理手段１Ａ０３、プロジェクト退場者登録処理手段１Ａ０４、プロジェクトメンバ評価登録処理手段１Ａ０５および個人要望登録処理手段１Ａ０６の６つの処理手段を有している。
【００４０】
データ部１Ｂは、上記６つの処理手段によりアクセス可能なデータを保持するものであり、同図に示すように、コードマスタ１Ｂ０１、認証テーブル１Ｂ０２、社員テーブル１Ｂ０３、組織マスタ１Ｂ０４、勤務表テーブル１Ｂ０５、年休テーブル１Ｂ０６、スキルテーブル１Ｂ０７、実績テーブル１Ｂ０８、プロジェクトテーブル１Ｂ０９、グループテーブル１Ｂ１０、メンバテーブル１Ｂ１１、進捗表テーブル１Ｂ１２、フォローテーブル１Ｂ１３、評価テーブル１Ｂ１４、要望テーブル１Ｂ１５、要望詳細テーブル１Ｂ１６および申請テーブル１Ｂ１７を有している。
【００４１】
次に、コードマスタ１Ｂ０１、認証テーブル１Ｂ０２、社員テーブル１Ｂ０３、組織マスタ１Ｂ０４、勤務表テーブル１Ｂ０５、年休テーブル１Ｂ０６、スキルテーブル１Ｂ０７、実績テーブル１Ｂ０８、プロジェクトテーブル１Ｂ０９、グループテーブル１Ｂ１０、メンバテーブル１Ｂ１１、進捗表テーブル１Ｂ１２、フォローテーブル１Ｂ１３、評価テーブル１Ｂ１４、要望テーブル１Ｂ１５、要望詳細テーブル１Ｂ１６および申請テーブル１Ｂ１７の、それぞれの具体例を、図５．１〜図５．１７を用いて詳細に説明する。
【００４２】
図５．１は、コードマスタ１Ｂ０１の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００４３】
コードマスタ１Ｂ０１は、プロジェクト人材選定および人材管理システムで管理するコードをユニークに識別する為のＩＤを示す「コード」、コードの名称を示す「コード名」、当該コードＩＤに属するコード値１を示す「コード値１」、当該コードＩＤに属するコード値２を示す「コード値２」（必要に応じて使用）、画面に表示する順番を示す「順番」、コードＩＤとコード値１（コード値２）の組み合わせに対するコードの内容１を示す「内容１」、コードＩＤとコード値１（コード値２）の組み合わせに対するコードの内容２を示す「内容２」、コードＩＤとコード値１（コード値２）の組み合わせに対するコードの内容３を示す「内容３」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００４４】
図５．２は、認証テーブル１Ｂ０２の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００４５】
認証テーブル１Ｂ０２は、プロジェクト人材選定および人材管理システムにログインする際のユーザＩＤを示す「ユーザＩＤ」、プロジェクト人材選定および人材管理システムにログインする際のパスワードを示す「パスワード」、ユーザＩＤとパスワードの適用開始日を示す「適用開始日」、ユーザＩＤとパスワードの適用終了日を示す「適用終了日」、ユーザＩＤとパスワードに対応する社員番号を示す「社員番号」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００４６】
図５．３は、社員テーブル１Ｂ０３の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００４７】
社員テーブル１Ｂ０３は、社員をユニークに識別する為の番号である「社員番号」、社員の姓を示す「姓」、社員の名を示す「名」、社員の役職を識別する区分である「役職区分」（本例では、０：一般、１：係長級、２：課長級、３：部長級、４：重役級）、社員の属する組織を識別するコードである「組織コード」、社員のユーザＩＤを示す「ユーザＩＤ」、社員の入社した年を示す「入社年」、社員のメールアドレスを示す「メールアドレス」、社員の単価を示す「社員の単価」、プロジェクト人材選定支援および人材管理システムにおける社員の権限を識別する区分である「権限区分」（本例では、０：権限なし、１：申請権限、２：決済権限）を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００４８】
図５．４は、組織マスタ１Ｂ０４の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００４９】
組織マスタ１Ｂ０４は、組織を識別するコードを示す「組織コード」、会社の名称を示す「会社名」、事業所の名称を示す「事業所名」、部署の名称を示す「部署名」、課の名称を示す「課名」、組織の所在地を示す「所在地」、組織の外線電話番号を示す「外線電話」、組織の内線電話番号を示す「内線電話」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００５０】
図５．５は、勤務表テーブル１Ｂ０５の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００５１】
勤務表テーブル１Ｂ０５は、社員をユニークに識別する為の番号を示す「社員番号」、勤務表の対象年度を示す「対象年度」、指図分の実働時間を示す「実働（指図）」、指図以外の実働時間を示す「実働（指図なし）」、年休を使用した日数を示す「年休」、超勤の時間を示す「超勤」、休日出勤した日数を示す「超勤」、休日出勤した日数を示す「休出」、欠勤の日数を示す「欠勤」、代休の日数を示す「代休」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００５２】
図５．６は、年休テーブル１Ｂ０６の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００５３】
年休テーブル１Ｂ０６は、社員をユニークに識別する為の番号を示す「社員番号」、年休の対象年度を示す「対象年度」、対象年度内において年休を使用した日数を示す「年休総数」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００５４】
図５．７は、スキルテーブル１Ｂ０７の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００５５】
スキルテーブル１Ｂ０７は、社員をユニークに識別する為の番号を示す「社員番号」、スキルの区分を示す「スキル区分」（本例では、１：業種・業務分類、２：技術分類）、スキル区分に対応したスキルの詳細を識別する区分「スキル詳細区分」（本例では、スキルコード４桁であらわしている）、レベルの区分を示す「レベル区分」（本例では、１：高、２：中、３：低）、スキルについての詳細事項を示す「詳細事項」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００５６】
図５．８は、実績テーブル１Ｂ０８の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００５７】
実績テーブル１Ｂ０８は、社員をユニークに識別する為の番号を示す「社員番号」、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、作業の開始日を示す「作業開始日」、作業の終了日を示す「作業終了日」、作業の内容を示す「作業内容」、役割の区分を示す「役割区分」（本例では、０：作業員、１：ＴＬ（チームリーダ）、２：ＰＬ（プロジェクトリーダ）、３：ＰＭ（プロジェクト管理者）、４：その他）、業務の区分を示す「業務区分」（本例では、１：設計、２：製造、３：テスト、４：運用・保守、５：プロジェクト管理、６：ＱＡ、７：その他）、補足事項を示す「補足事項」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００５８】
図５．９は、プロジェクトテーブル１Ｂ０９の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００５９】
プロジェクトテーブル１Ｂ０９は、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、組織を識別するコードを示す「組織コード」、プロジェクトの開始日を示す「開始日」、プロジェクトの終了日を示す「終了日」、プロジェクトの名称を示す「プロジェクト名」、作業をユニークに識別する為の指図番号を示す「指図」、プロジェクトの予算額を示す「予算額」、プロジェクトの受注額を示す「受注額」、プロジェクトの実績額を示す「実績額」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００６０】
図５．１０は、グループテーブル１Ｂ１０の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００６１】
グループテーブル１Ｂ１０は、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、グループをユニークに識別する為のＩＤを示す「グループＩＤ」、グループの名称を示す「グループ名」、グループの終了日を示す「終了日」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００６２】
図５．１１は、メンバテーブル１Ｂ１１の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００６３】
メンバテーブル１Ｂ１１は、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、グループをユニークに識別する為のＩＤを示す「グループＩＤ」、社員をユニークに識別する為の番号を示す「社員番号」、グループのメンバの代表であることを示す「代表フラグ」、メンバがグループに属している状態の終了日を示す「終了日」、申請をユニークに識別する為のＩＤを示す「申請ＩＤ」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００６４】
図５．１２は、進捗表テーブル１Ｂ１２の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００６５】
進捗表テーブル１Ｂ１２は、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、工程の区分を示す「工程区分」（本例では、１：基本設計、２：詳細設計、３：製造、４：単体テスト、。５：結合テスト、６：総合テスト、７：受入テスト、８：本番対応、９：運用）、社員をユニークに識別する為の番号を示す「社員番号」、作業をユニークに識別する為のＩＤを示す「作業ＩＤ」、作業の開始予定日を示す「開始予定日」、作業の終了予定日を示す「終了予定日」、作業の開始日を示す「開始日」、作業の終了日を示す「終了日」、規模の単位を識別する為の区分を示す「規模単位区分」（本例では、１：ＫＳ（キロステップ）、２：人日、３：枚）、予定の規模を示す「予定規模」、実績の規模を示す「実績規模」、その他の項目を示す「その他」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００６６】
図５．１３は、フォローテーブル１Ｂ１３の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００６７】
フォローテーブル１Ｂ１３は、社員をユニークに識別する為の番号を示す「社員番号」、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、要注意の区分を示す「要注意区分」（本例では、１：欠勤、２：年休、３：進捗遅延、４：超勤、５：人間関係、６：異動希望）、要注意の区分が１，２，３の場合の日数を示す「日」、要注意の区分が４の場合の時間を示す「時間」、退場の区分を示す「退場区分」（本例では、０：未候補、１：退場候補、２：退場決定）、申請をユニークに識別する為のＩＤを示す「申請ＩＤ」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００６８】
図５．１４は、評価テーブル１Ｂ１４の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００６９】
評価テーブル１Ｂ１４は、社員をユニークに識別する為の番号を示す「社員番号」、評価される側の社員の社員番号を示す「評価社員番号」、評価の区分を示す「評価区分」（本例では、０：未登録、１：一緒に仕事したい、２：どちらでもない、３：一緒に仕事したくない、４：顔もみたくない）、社員のコメントを示す「コメント」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００７０】
図５．１５は、要望テーブル１Ｂ１５の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００７１】
要望テーブル１Ｂ１５は、社員をユニークに識別する為の番号を示す「社員番号」、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、異動希望があることを示す「フラグ」、異動希望がある場合に異動予定日を示す「異動予定日」、社員のコメントを示す「コメント」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００７２】
図５．１６は、要望詳細テーブル１Ｂ１６の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００７３】
要望詳細テーブル１Ｂ１６は、社員をユニークに識別する為の番号を示す「社員番号」、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、社員の要望を識別する為の区分を示す「要望区分」（本例では、１：仕事量、２：勤務時間、３：仕事内容、４：人間関係、５：異動希望）、社員の要望詳細を識別する為の区分を示す「要望詳細区分」（図中、＊１参照）、社員のコメントを示す「コメント」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００７４】
図５．１７は、申請テーブル１Ｂ１７の一例を示す図であり、同図（ａ）は、項目の説明を、同図（ｂ）はデータ例を示している。
【００７５】
申請テーブル１Ｂ１７は、申請をユニークに識別する為のＩＤを示す「申請ＩＤ」、申請の区分を示す「申請区分」（本例では、１：候補者登録、２：退場者登録）、プロジェクトをユニークに識別する為のＩＤを示す「プロジェクトＩＤ」、申請中であることを示す「申請中フラグ」、申請者の社員番号を示す「申請者番号」、差戻中であることを示す「差戻フラグ」、差戻の理由を示す「差戻理由」、差戻者の社員番号を示す「差戻者番号」、決済済みであることを示す「決裁フラグ」、決裁者の社員番号を示す「決裁者番号」、取消であることを示す「取消フラグ」を保持するテーブルである。（ｂ）は具体的なデータ例である。
【００７６】
次に、本発明に係るプロジェクト人材選定支援および人材管理システム（プロジェクト人材選定支援システム）としてのサーバの処理を、図面を用いて説明する。
【００７７】
図２．１、図２．２、図２．３、図２．４、図２．５、および図２．６は、それぞれ、図１におけるプロジェクト候補者検索処理手段１Ａ０１、プロジェクト候補者登録処理手段１Ａ０２、プロジェクトフォロー対象者検索処理手段１Ａ０３、プロジェクト退場者登録処理手段１Ａ０４、プロジェクトメンバ評価登録処理手段１Ａ０５および個人要望登録処理手段１Ａ０６により実行される処理動作のフローチャート図である。
【００７８】
以下、各処理手段により実行される処理を、フローチャート図を用いて詳細に説明する。なお、各処理手段の説明で使用するテーブルにおいて、同じテーブル名を用いている場合は参照符号が異なっていても同一のテーブル（図５．１〜図５．１７参照）を指すものとする。
【００７９】
図２．１は、図１におけるプロジェクト候補者検索処理手段１Ａ０１の処理動作例を示すフローチャート図である。
【００８０】
図１におけるプロジェクト候補者検索処理手段１Ａ０１の処理目的は、プロジェクト立ち上げ時によるメンバ候補者の選出またはプロジェクト進行中における増員、欠員に伴うメンバ選出を過去のプロジェクト経験、スキル、第三者からの評価情報を元に、人間関係も考慮した最適なメンバ候補を選出することである。
【００８１】
なお、プロジェクト候補者検索処理手段１Ａ０１は、プロジェクト候補メンバの仮登録権限を保有する社員のみが実行可能とする。その権限範囲は、社員テーブル２Ａ１１（図５．３参照）が保持する権限区分が１（申請権限）または２（決裁権限）の情報持つ社員のみとする。
【００８２】
図２．１に示すように、プロジェクト候補者検索処理手段１Ａ０１における処理は、［プロジェクト候補メンバの検索ステップＳ２Ａ０１］，［候補メンバの抽出（グループ）ステップＳ２Ａ０２］，［グループ化処理ステップＳ２Ａ０３］，［候補グループ・候補メンバの出力ステップＳ２Ａ０４］，［候補メンバの抽出ステップＳ２Ａ０５］，［候補メンバの出力ステップＳ２Ａ０６］，［プロジェクトメンバの選択ステップＳ２Ａ０７］，［プロジェクトメンバの仮登録ステップＳ２Ａ０８］からなる。以下、各処理ステップＳ２Ａ０１〜Ｓ２Ａ０８について説明する。
【００８３】
［プロジェクト候補メンバの検索ステップＳ２Ａ０１］
プロジェクト候補メンバの検索ステップＳ２Ａ０１では、新規プロジェクトの場合、プロジェクト候補メンバの条件設定を行う。ここでは、スキル、作業開始日、グループの人数、グループコストおよび組織を後述の候補メンバの抽出（グループ）ステップＳ２Ａ０２の抽出条件として設定する。既存プロジェクトの場合、新規または追加のプロジェクト候補メンバの条件設定を行う。
【００８４】
既存プロジェクトは、当該手段の機能を操作する社員が所属する組織が関わっているプロジェクトをプロジェクトテーブル２Ａ１２（図５．９参照）の中から選択する。その選択できるプロジェクトは操作している社員の役職によって適用範囲を制限するようにしている。それは、操作する社員が社員自身と関係のないプロジェクトに対してメンバを選択することは適切ではないためである。
【００８５】
その制限範囲は、社員テーブル２Ａ１１（図５．３参照）が保持する役職区分が1（係長級）の社員は社員自身が関わっているプロジェクトのみ選択が可能、2（課長級）の社員は社員が所属する組織の課内に関わっているプロジェクトのみ選択が可能、3（部長級）の社員は社員が所属する組織の部内に関わっているプロジェクトのみ選択が可能、4（重役級）の社員は全てのプロジェクト情報を取得し選択することができる。
【００８６】
次に、選択されたプロジェクトに対するプロジェクト候補メンバの選定方法について、プロジェクト候補メンバの選定条件設定を行う。
【００８７】
（イ）新たにグループを追加しそのグループに対するプロジェクト候補メンバを新規に選択するケースの場合は、新規プロジェクトと同様の抽出条件（スキル、作業開始日、グループの人数、グループコストおよび組織）を設定する。
【００８８】
（ロ）既に登録されているグループに対してプロジェクト候補メンバを追加するケースの場合は、新規プロジェクトと同様の抽出条件（スキル、作業開始日、グループの人数、グループコストおよび組織）に追加対象のグループ名も条件に加えた設定をする。
【００８９】
［候補メンバの抽出（グループ）ステップＳ２Ａ０２］
候補メンバの抽出（グループ）ステップＳ２Ａ０２では、プロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定された検索条件からプロジェクト候補メンバを抽出する。
【００９０】
また、新規プロジェクトや既存プロジェクトへの新規グループ追加の場合に適用する。プロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定された作業開始日と組織より、社員テーブル２Ａ１５（図５．３参照）から指定された組織に所属する社員情報を取得し、取得した社員情報の中から実績テーブル２Ａ１４（図５．８参照）より指定された作業開始日より前にプロジェクトが終了し、指定された作業開始日以降に参画しているプロジェクトがない社員を絞り込む。
【００９１】
そして、絞り込まれた社員の中から更にプロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定されたスキルによりスキルテーブル２Ａ１３（図５．７参照）から指定されたスキルを持つ社員を絞り込む処理を行う。
【００９２】
［グループ化処理ステップＳ２Ａ０３］
グループ化処理ステップＳ２Ａ０３は、候補メンバの抽出（グループ）ステップＳ２Ａ０２で取得した社員情報から、プロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定された条件、グループの人数、グループコストと評価テーブル２Ａ１６（図５．１４参照）に見合ったグループ化処理を行う。
【００９３】
グループ化処理を行う前提条件として、１グループに１人以上はリーダクラスに該当するメンバが含まれる構成となるようにする。リーダクラスは、社員テーブル２Ａ１７（図５．３参照）に持つ役職区分が1（係長級）以上の社員または社員が過去に経験したプロジェクト情報より実績テーブル２Ａ１８（図５．８参照）に持つ役割区分が１（ＴＬ：チームリーダ）以上の経験をしている社員とする。
【００９４】
まず、はじめにリーダクラスの社員の有無を判定する。もし１人もいない場合は（グループ化：ＮＧ）、プロジェクト候補メンバの検索ステップＳ２Ａ０１にて、検索条件の再設定を促し、当処理を終了させる。１人以上いた場合（グループ化：ＯＫ）、リーダ単位ごとにリーダに対して評価の悪くないメンバ（評価テーブル２Ａ１６（図５．１４参照）の評価区分が３（一緒に仕事をしたくない）、4（顔も見たくない）に該当しないもの）をグループ化する。
【００９５】
ここで、既存プロジェクトにおける新規グループ追加に伴うプロジェクト候補メンバであった場合は、既に登録されているグループのリーダクラスメンバと当処理で抽出したリーダクラスのメンバと互いの評価（評価テーブル２Ａ１６（図５．１４参照）の評価区分が３（一緒に仕事をしたくない）、4（顔も見たくない）に該当しないもの）を判定する。
【００９６】
１件も条件が満たされなければ、プロジェクト候補メンバの検索ステップＳ２Ａ０１にて、検索条件の再設定を促し、当処理を終了させる。
【００９７】
１件でも満たされれば、満たされたリーダクラスのメンバをもとにグループ化されたメンバのみメンバ間の評価を実施する。リーダ単位にグループ化されたメンバ同士について、互いの評価が悪くないメンバ（評価テーブル２Ａ１６（図５．１４参照）の評価区分が３（一緒に仕事をしたくない）、4（顔も見たくない）でないもの同士）でグループ化する。
【００９８】
以上の条件で１つまたは複数のパターンのグループが生成されるが、それぞれのグループについて、プロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定された条件、グループの人数、グループコストに見合う条件になっているかどうか判定をする。
【００９９】
グループコストにおける判定方法は、社員テーブル２Ａ１７（図５．３参照）に持つ単価を利用し、グループ単位で合計した結果と比較することで判定する。以上の条件全てを満たすグループが存在した場合に、候補グループ・候補メンバの出力ステップＳ２Ａ０４に進む。
【０１００】
［候補グループ・候補メンバの出力ステップＳ２Ａ０４］
候補グループ・候補メンバの出力ステップＳ２Ａ０４は、グループ化処理ステップＳ２Ａ０３にて絞り込まれた候補グループ・候補メンバ情報を画面に表示させるための編集処理を行う。最終的にプロジェクト候補メンバを手動で操作できる状態になる。
【０１０１】
［候補メンバの抽出（個人）ステップＳ２Ａ０５］
候補メンバの抽出（個人）ステップＳ２Ａ０５では、プロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定された検索条件からプロジェクト候補メンバを抽出する。
【０１０２】
また、新規プロジェクトや既存プロジェクトへの新規グループ追加の場合に適用される。プロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定された作業開始日と組織より、社員テーブル２Ａ１９（図５．３参照）から指定された組織に所属する社員情報を取得し、取得した社員情報の中から実績テーブル２Ａ２１（図５．８参照）より指定された作業開始日より前にプロジェクトが終了し、指定された作業開始日以降に参画しているプロジェクトがない社員を絞り込む。
【０１０３】
そして、絞り込まれた社員の中から更にプロジェクト候補メンバの検索ステップＳ２Ａ０１にて設定されたスキル情報よりスキルテーブル２Ａ２３（図５．７参照）から指定されたスキルを持つ社員を絞り込む処理を行う。
【０１０４】
［候補メンバの出力ステップＳ２Ａ０６］
候補メンバの出力ステップＳ２Ａ０６は、候補グループ・候補メンバの出力ステップＳ２Ａ０４と同様にプロジェクト候補メンバの検索ステップＳ２Ａ０１および候補メンバの抽出（個人）ステップＳ２Ａ０５の順を追って候補メンバの抽出（個人）ステップＳ２Ａ０５にて得られた検索結果を画面に表示させるための編集処理を行う。最終的にメンバ候補を手動で操作できる状態になる。
【０１０５】
［プロジェクトメンバの選択ステップＳ２Ａ０７］
プロジェクトメンバの選択ステップＳ２Ａ０７は、候補グループ・候補メンバの出力ステップＳ２Ａ０４、または候補メンバの出力ステップＳ２Ａ０６で処理された結果を画面に表示し、検索結果によって得られたプロジェクト候補メンバ情報を元に手動で人為的にプロジェクト候補メンバを再選択できるようにする。また、グループ名が未設定である場合は最終的に選択したメンバに対してグループ名を入力することができる。
【０１０６】
［プロジェクトメンバの仮登録ステップＳ２Ａ０８］
プロジェクトメンバの仮登録ステップＳ２Ａ０８は、プロジェクトメンバの選択ステップＳ２Ａ０７にて再選択したプロジェクト候補メンバ情報を、グループテーブル２Ａ２４（図５．１０参照）、メンバテーブル２Ａ２５（図５．１１参照）および申請テーブル２Ａ２６（図５．１７参照）に登録する。
【０１０７】
図２．２は、図１におけるプロジェクト候補者登録処理手段１Ａ０２の処理動作例を示すフローチャートである。
【０１０８】
図１におけるプロジェクト候補者登録処理手段１Ａ０２の処理目的は、プロジェクト候補者検索処理手段１Ａ０１にて登録した情報を修正する機能と申請、差戻し、決裁といったワークフローの機能を持つ。
【０１０９】
図２．２に示すように、プロジェクト候補者登録処理手段１Ａ０２における処理は、［プロジェクトメンバ（仮登録）の抽出ステップＳ２Ｂ０１］，［プロジェクトメンバ（仮登録）一覧の出力ステップＳ２Ｂ０２］，［プロジェクトメンバの再仮登録ステップＳ２Ｂ０３］，［プロジェクトメンバ（仮登録）の本登録申請ステップＳ２Ｂ０４］，［プロジェクトメンバの本登録ステップＳ２Ｂ０５］，［プロジェクトメンバの仮登録（差戻し）ステップＳ２Ｂ０６］，［プロジェクトメンバの確定ステップＳ２Ｂ０７］からなる。以下、各処理ステップＳ２Ｂ０１〜Ｓ２Ｂ０７について説明する。
【０１１０】
［プロジェクトメンバ（仮登録）の抽出ステップＳ２Ｂ０１］
プロジェクトメンバ（仮登録）の抽出ステップＳ２Ｂ０１は、図２．１のプロジェクトメンバの仮登録ステップＳ２Ａ０８にて登録した情報を申請テーブル２Ｂ１１（図５．１７参照）、グループテーブル２Ｂ１３（図５．１０参照）、メンバテーブル２Ｂ１４（図５．１１参照）から抽出する。
【０１１１】
また、当処理は画面より抽出処理の操作を行うが、操作する人が、図２．１のプロジェクトメンバの仮登録ステップＳ２Ａ０８にて登録していれば、抽出することができる。抽出対象データがない場合は、当処理は終了する。
【０１１２】
［プロジェクトメンバ（仮登録）一覧の出力ステップＳ２Ｂ０２］
プロジェクトメンバ（仮登録）一覧の出力ステップＳ２Ｂ０２は、プロジェクトメンバ（仮登録）の抽出ステップＳ２Ｂ０１で抽出した件数が１件以上ある場合、抽出したメンバ情報を画面に表示させるための編集処理を行う。
【０１１３】
編集処理後、画面上で仮登録したプロジェクトメンバ候補者に対してグループの一覧から個々にプロジェクト候補メンバ候補を外したり、グループ単位で削除することができる。
【０１１４】
ただし、グループ単位で削除した場合もしくは全てのプロジェクト候補者を外した場合は、当処理は終了する。
【０１１５】
メンバ候補者を追加する場合は、プロジェクトメンバの再仮登録ステップＳ２Ｂ０３へ処理は推移し、仮登録する画面に遷移して追加処理を行うことができる。
【０１１６】
［プロジェクトメンバの再仮登録ステップＳ２Ｂ０３］
プロジェクトメンバの再仮登録ステップＳ２Ｂ０３では、プロジェクトメンバ（仮登録）一覧の出力ステップＳ２Ｂ０２にてメンバ候補者の追加が発生した場合に当処理にて追加したメンバ候補者の再仮登録をすることができる。
【０１１７】
当処理は、図２．１のプロジェクト候補メンバの検索ステップＳ２Ａ０１から候補メンバの抽出（個人）ステップＳ２Ａ０５、候補メンバの出力ステップＳ２Ａ０６、プロジェクトメンバの選択ステップＳ２Ａ０７、プロジェクトメンバの仮登録ステップＳ２Ａ０８までの処理と同等の処理となる。画面にてメンバ確定後、メンバテーブル２Ｂ１６（図５．１１参照）に追加メンバ情報を登録し、プロジェクトメンバ（仮登録）の抽出ステップＳ２Ｂ０１の抽出対象データとなる。
【０１１８】
［プロジェクトメンバ（仮登録）の本登録申請ステップＳ２Ｂ０４］
プロジェクトメンバ（仮登録）の本登録申請ステップＳ２Ｂ０４は、プロジェクトメンバ（仮登録）一覧の出力ステップＳ２Ｂ０２にてメンバ候補者の追加手続きがない場合、およびグループ単位の削除がない場合は、仮登録情報を決裁者へ申請し、決裁者が申請された情報を査収し本登録する流れとなる。
【０１１９】
最終決裁者へ通知する手段として、最終決裁者のメールアドレスを指定して本登録申請依頼情報（本登録処理用のＵＲＬ、申請ＩＤ）を添付して通知する。具体的な処理としては、申請の際は、メンバテーブル２Ｂ１８（図５．１１参照）の申請ＩＤに対して、申請テーブル２Ｂ１７（図５．１７参照）に仮登録時点にて採番した申請ＩＤを登録し、申請テーブル２Ｂ１７（図５．１７参照）には申請中フラグと決裁者番号を更新する。
【０１２０】
最終決裁者の決定方法は、基本は申請者が所属する直属の上司および役職が課長級以上の社員としている。ただし、申請者本人が、上司にあたる社員がいない場合、申請者本人ではなく、直属の部下にあたる役職の最高位の社員を選択できるように制御することで不正な登録ができないようにする。
【０１２１】
［プロジェクトメンバの本登録ステップＳ２Ｂ０５］
プロジェクトメンバの本登録ステップＳ２Ｂ０５は、プロジェクトメンバ（仮登録）の本登録申請ステップＳ２Ｂ０４にて申請時に通知されたメール本文に本登録用の画面に遷移するＵＲＬと申請ＩＤが記載されている。記載されているＵＲＬにアクセスすることで、本登録するための画面へ遷移し決裁処理を行う。申請されたメンバ候補者を正式なメンバとして確定する本登録処理と、プロジェクトメンバとして問題がある場合に申請者へ差し戻しを行う差戻し処理のいずれかを選択する。
【０１２２】
具体的な処理として、申請者より送信されたメール情報から申請ＩＤを取得し、取得した申請ＩＤから申請テーブル２Ｂ１９（図５．１７参照）からプロジェクトＩＤを、メンバテーブル２Ｂ２２（図５．１１参照）から社員番号とグループＩＤを取得し、社員番号から社員テーブル（図５．３参照）よりプロジェクト候補メンバの名前とプロジェクトＩＤとグループＩＤからグループ名を取得する。本登録を選択した場合、プロジェクトメンバの確定ステップＳ２Ｂ０７に推移する。差戻しを選択した場合、プロジェクトメンバの仮登録（差戻し）ステップＳ２Ｂ０６に推移する。
【０１２３】
［プロジェクトメンバの仮登録（差戻し）ステップＳ２Ｂ０６］
プロジェクトメンバの仮登録（差戻し）ステップＳ２Ｂ０６は、プロジェクトメンバの本登録ステップＳ２Ｂ０５にて差戻し処理が実行された場合、申請者へ差戻し情報を添付してメールにて通知され、プロジェクトメンバ（仮登録）の抽出ステップＳ２Ｂ０１の処理対象データとして処理する。
【０１２４】
具体的な処理として、申請テーブル２Ｂ２３（図５．１７参照）の差戻理由にプロジェクトメンバの本登録ステップＳ２Ｂ０５にて設定された差戻理由を設定、差戻者番号にプロジェクトメンバの本登録ステップＳ２Ｂ０５で操作した決裁者の社員番号を設定および差戻フラグを1に設定する。
【０１２５】
［プロジェクトメンバの確定ステップＳ２Ｂ０７］
プロジェクトメンバの確定ステップＳ２Ｂ０７は、プロジェクトメンバの本登録ステップＳ２Ｂ０５にて本登録処理が実行された場合、プロジェクト候補メンバからプロジェクト正式メンバへの確定処理を行う。具体的な処理として、申請テーブル２Ｂ２４（図５．１７参照）の決裁者番号に決裁者の社員番号を設定し、決裁フラグに1を設定する。
【０１２６】
また、実績テーブル２Ｂ２５（図５．８参照）にプロジェクトメンバの社員番号、プロジェクトＩＤと作業開始日にプロジェクトテーブル２Ｂ２６（図５．９参照）よりプロジェクトＩＤから作業開始日を取得し設定し、実績情報として登録する。
【０１２７】
図２．３は、図１におけるプロジェクトフォロー対象者検索処理手段１Ａ０３の処理動作例を示すフローチャートである。
【０１２８】
図１におけるプロジェクトフォロー対象者検索処理手段１Ａ０３の処理目的は、プロジェクトメンバの勤務状態や進捗状況よりプロジェクトの進行の妨げとなる要因、または一個人における精神面、健康面について問題がありそうなメンバ候補を抽出することができる。
【０１２９】
そして、対象となったメンバを日々画面で確認することが可能になるので迅速なフォローにつながり解決スピードの向上が計れる。また、フォローだけではなく、プロジェクトから退場候補者として選出し仮登録する機能も合わせ持つ。
【０１３０】
図２．３に示すように、プロジェクトフォロー対象者検索処理手段１Ａ０３における処理は、［勤務状況・進捗状況の編集ステップＳ２Ｃ０１］［フォロー対象者のフラグ設定ステップＳ２Ｃ０２］，［フォロー対象者の抽出ステップＳ２Ｃ０３］，［フォロー対象者一覧の出力ステップＳ２Ｃ０４］，［退場者の選択ステップＳ２Ｃ０５］，［退場者の仮登録ステップＳ２Ｃ０６］からなる。以下、各処理ステップＳ２Ｃ０１〜Ｓ２Ｃ０６について説明する。
【０１３１】
［勤務状況・進捗状況の編集ステップＳ２Ｃ０１］
勤務状況・進捗状況の編集ステップＳ２Ｃ０１では、各プロジェクトメンバの勤務状況（欠勤、年休、超勤時間）、作業進捗状況（遅延日数）、他のメンバからの評価（例えば、５段階評価）情報およびプロジェクトメンバ自身の要望（異動希望、人間関係）に関する情報を随時あるいは定期的に一括して収集する。
【０１３２】
具体的な処理として、進捗表テーブル２Ｃ１１（図５．１２参照）から終了予定日が処理日より過去日で、終了日に日付が設定されていないデータを進捗状況情報として取得する。勤務表テーブル２Ｃ１２（図５．５参照）からは処理日のその月を基準に当月における欠勤日数が１日以上、年休３日以上または、超勤時間数が３0以上のデータを勤務状況情報として取得する。
【０１３３】
評価テーブル２Ｃ１４（図５．１４参照）から評価区分が3（一緒に仕事したくない）、4（顔も見たくない）に該当するデータを評価状況情報として取得する。また、要望テーブル２Ｃ１５（図５．１５参照）から異動希望フラグが1に設定されているデータがあれば要望状況情報として取得する。
【０１３４】
［フォロー対象者のフラグ設定ステップＳ２Ｃ０２］
フォロー対象者のフラグ設定ステップＳ２Ｃ０２は、勤務状況・進捗状況の編集ステップＳ２Ｃ０１にて収集した情報がプロジェクトを円滑に遂行するための阻害要因となる要素を持つプロジェクトメンバとしてフォロー対象フラグを設定する処理を行う。
【０１３５】
また、フォロー対象となったプロジェクトメンバ情報は、管理者（プロジェクトマネージャー等）たるメンバへ対象者の有無を知らせるメールを配信する処理を行う。具体的な処理として、勤務状況・進捗状況の編集ステップＳ２Ｃ０１にて取得した情報をフォローテーブル２Ｃ１６（図５．１３参照）に登録する。
【０１３６】
勤務状況情報からは、該当プロジェクトメンバ毎に欠勤によるフォロー対象者であれば、フォローテーブル２Ｃ１６（図５．１３参照）の要注意区分に１（欠勤）と日に欠勤日数を設定し、年休によるフォロー対象者であれば、フォローテーブル２Ｃ１６（図５．１３参照）の要注意区分に２（年休）と日に年休日数を設定し、超勤時間によるフォロー対象者であれば、フォローテーブル２Ｃ１６（図５．１３参照）の要注意区分に４（超勤）と時間に超勤時間数を設定する。
【０１３７】
進捗状況情報からは、遅延が発生してプロジェクトメンバ毎にフォローテーブル２Ｃ１６の要注意区分に３（進捗遅延）と日に遅延日数を設定する。評価状況情報からは、該当プロジェクトメンバ毎にフォローテーブル２Ｃ１６（図５．１３参照）の要注意区分に５（人間関係）を設定する。要望状況情報からは、該当プロジェクトメンバ毎にフォローテーブル２Ｃ１６（図５．１３参照）の要注意区分に6（異動希望）を設定する。
【０１３８】
メールによる通知対象については、フォロー対象となったプロジェクトメンバがリーダクラスではない場合はそのグループリーダ、プロジェクトの管理者および直属の上司へ通知する。フォロー対象となったプロジェクトメンバがリーダクラスの場合プロジェクトの管理者および直属の上司へ通知する。
【０１３９】
［フォロー対象者の抽出ステップＳ２Ｃ０３］
フォロー対象者の抽出ステップＳ２Ｃ０３では、フォロー対象者のフラグ設定ステップＳ２Ｃ０２にてフォロー対象プロジェクトメンバ情報より、画面から検索条件（欠勤日数、年休日数、超勤時間、進捗遅延日数）を指定し、フォロー対象者を絞りこむ処理を行う。
【０１４０】
具体的な処理として、フォロー対象者のフラグ設定ステップＳ２Ｃ０２にて登録された情報をフォローテーブル２Ｃ１７（図５．１３参照）より申請ＩＤが未設定のものを取得する。その取得した情報から、画面にて設定された検索条件に該当する情報（欠勤日数以上、年休日数以上、超勤時間以上、進捗遅延日数以上）で絞りこむ。当処理を操作できる人は、フォローの通知を受けたメンバ（プロジェクトの管理者および直属の上司など）に限定する。
【０１４１】
［フォロー対象者一覧の出力ステップＳ２Ｃ０４］
フォロー対象者一覧の出力ステップＳ２Ｃ０４では、フォロー対象者の抽出ステップＳ２Ｃ０３にて絞り込まれた件数が１件以上ある場合、抽出したメンバ情報を画面に表示させるための編集処理を行う。また、検索結果で得られた情報を元に、退場候補を手動で選択できる状態になる。
【０１４２】
［退場者の選択ステップＳ２Ｃ０５］
退場者の選択ステップＳ２Ｃ０５では、フォロー対象者の中から退場候補者を選択する。操作手段として、フォロー対象者一覧の出力ステップＳ２Ｃ０４にて編集された情報から退場候補者を選択することができる。
【０１４３】
［退場者の仮登録ステップＳ２Ｃ０６］
退場者の仮登録ステップＳ２Ｃ０６では、退場者の選択ステップＳ２Ｃ０５にて選択された退場候補者情報を登録する。具体的な処理として、退場者の選択ステップＳ２Ｃ０５にて選択したメンバ情報についてフォローテーブル２Ｃ２０（図５．１３参照）の退場区分に1（退場候補）を設定する。
【０１４４】
図２．４は、図１におけるプロジェクト退場者登録処理手段１Ａ０４の処理動作例を示すフローチャートである。
【０１４５】
図１におけるプロジェクト退場者登録処理手段１Ａ０４の処理目的は、プロジェクトフォロー対象者検索処理手段１Ａ０３にて仮登録した情報を修正する機能と申請、差戻し、決裁といったワークフローの機能を持つ。
【０１４６】
仮登録した情報を修正する機能としては、メンバ候補者をグループ単位で削除することが可能である。また、仮登録情報を最終決裁者が決裁するため最終決済者のメールアドレスを指定し申請する機能を持つ。以下、図２．４を用いてさらに詳しく説明する。
【０１４７】
図２．４に示すように、プロジェクト退場者登録処理手段１Ａ０４における処理は、［退場者（仮登録）の抽出ステップＳ２Ｄ０１］，［退場者（仮登録）一覧の出力ステップＳ２Ｄ０２］，［退場者の再仮登録ステップＳ２Ｄ０３］，［退場者（仮登録）の本登録申請ステップＳ２Ｄ０４］，［退場者の本登録ステップＳ２Ｄ０５］，［退場者（仮登録）（差戻し）ステップＳ２Ｄ０６］，［プロジェクトメンバの編集ステップＳ２Ｄ０７］からなる。以下、各処理ステップＳ２Ｄ０１〜Ｓ２Ｄ０７について説明する。
【０１４８】
［退場者（仮登録）の抽出ステップＳ２Ｄ０１］
退場者（仮登録）の抽出ステップＳ２Ｄ０１では、プロジェクトフォロー対象者検索処理手段１Ａ０３にて仮登録した情報を申請テーブル２Ｄ１１（図５．１７参照）から抽出する。図２．３の退場者の仮登録ステップＳ２Ｃ０６にて登録した情報をフォローテーブル２Ｄ１３（図５．１３参照）より退場区分が1（退場候補）であるデータを取得する。
【０１４９】
また、当処理は画面より抽出処理の操作を行うが、操作する人が、図２．３の退場者の仮登録ステップＳ２Ｃ０６にて登録していれば、抽出することができる。抽出対象データがない場合は、当処理は終了する。
【０１５０】
［退場者（仮登録）一覧の出力ステップＳ２Ｄ０２］
退場者（仮登録）一覧の出力ステップＳ２Ｄ０２では、退場者（仮登録）の抽出ステップＳ２Ｄ０１で抽出した件数が１件以上ある場合、抽出したメンバ情報を画面に表示させるための編集処理を行う。
【０１５１】
編集処理後、画面上で仮登録した退場候補者に対して一覧から外すことができる。
【０１５２】
その際、外した退場候補者の社員番号からフォローテーブル２Ｄ１４（図５．１３参照）のその社員番号に対するデータの退場区分を0（未候補）に更新する。全ての退場候補者を外した場合は、当処理は終了する。退場候補者を追加する場合は、退場者の再仮登録ステップＳ２Ｄ０３へ処理は推移し、仮登録する画面に遷移して追加処理を行うことができる。
【０１５３】
［退場者の再仮登録ステップＳ２Ｄ０３］
退場者の再仮登録ステップＳ２Ｄ０３では、退場者（仮登録）一覧の出力ステップＳ２Ｄ０２にて退場候補者の追加が発生した場合に当処理にて追加したメンバ候補者の再仮登録をすることができる。
【０１５４】
当処理は、図２．３のフォロー対象者の抽出ステップＳ２Ｃ０３、フォロー対象者一覧の出力ステップＳ２Ｃ０４、退場者の選択ステップＳ２Ｃ０５、退場者の仮登録ステップＳ２Ｃ０６までの処理と同等の処理となる。画面にて退場候補者確定後、フォローテーブル２Ｄ１５（図５．１３参照）に退場候補者情報を登録し、退場者（仮登録）の抽出ステップＳ２Ｄ０１の抽出対象データとする。
【０１５５】
［退場者（仮登録）の本登録申請ステップＳ２Ｄ０４］
退場者（仮登録）の本登録申請ステップＳ２Ｄ０４は、退場者（仮登録）一覧の出力ステップＳ２Ｄ０２にて退場候補者の追加手続きがない場合、仮登録情報を決裁者へ申請し、決裁者が申請された情報を査収し本登録する流れとなる。
【０１５６】
最終決裁者へ通知する手段として、最終決裁者のメールアドレスを指定して本登録申請依頼情報（本登録処理用のＵＲＬ、申請ＩＤ）を添付して通知する。具体的な処理としては、申請の際は、退場候補者の社員番号に該当するデータに対してフォローテーブル２Ｄ１７（図５．１３参照）の申請ＩＤを設定する。
【０１５７】
その時に設定した申請ＩＤを申請テーブル２Ｄ１６（図５．１７参照）に登録し、申請区分に2（退場者登録）、申請中フラグと申請者番号を更新する。最終決裁者の決定方法は、基本は申請者が所属する直属の上司および役職が課長級以上の社員としている。ただし、申請者本人が、上司にあたる社員がいない場合、申請者本人ではなく、直属の部下にあたる役職の最高位の社員が選択できるように制御することで不正な登録ができないようにする。
【０１５８】
［退場者の本登録ステップＳ２Ｄ０５］
退場者の本登録ステップＳ２Ｄ０５は、退場者（仮登録）の本登録申請ステップＳ２Ｄ０４にて申請時に通知されたメール本文に本登録用の画面に遷移するＵＲＬと申請ＩＤが明記されている。
【０１５９】
その記載されているＵＲＬにアクセスすることで、本登録するための画面へ遷移し決裁処理を行う。申請された退場候補者を正式な退場者メンバとして確定する本登録処理と、退場者メンバとして問題がある場合に申請者へ差し戻しを行う差戻し処理のいずれかを選択する。
【０１６０】
具体的な処理として、申請者より送信されたメール情報から申請ＩＤを取得し、取得した申請ＩＤから申請テーブル２Ｄ１８（図５．１７参照）よりプロジェクトＩＤを取得する。
【０１６１】
また、取得した申請ＩＤからフォローテーブル２Ｄ２０（図５．１３参照）より社員番号とグループＩＤを取得し、社員番号から社員テーブル２Ｄ１９（図５．３参照）より退場者候補メンバの姓、名と、グループテーブル２Ｄ２５（図５．１０参照）よりプロジェクトＩＤとグループＩＤからグループ名を取得する。本登録を選択した場合、プロジェクトメンバの編集ステップＳ２Ｄ０７に推移する。差戻しを選択した場合、退場者（仮登録）（差戻し）ステップＳ２Ｄ０６に推移する。
【０１６２】
［退場者（仮登録）（差戻し）ステップＳ２Ｄ０６］
退場者（仮登録）（差戻し）ステップＳ２Ｄ０６は、退場者の本登録ステップＳ２Ｄ０５にて差戻し処理が実行された場合、申請者へ差戻し情報を添付してメールにて通知され、退場者（仮登録）の抽出ステップＳ２Ｄ０１の処理対象データとして処理する。
【０１６３】
具体的な処理として、申請テーブル２Ｄ２１（図５．１７参照）の差戻理由に退場者の本登録ステップＳ２Ｄ０５にて設定された差戻理由を設定、差戻者番号に退場者の本登録ステップＳ２Ｄ０５で操作した決裁者の社員番号および差戻フラグを1に設定する。
【０１６４】
［プロジェクトメンバの編集ステップＳ２Ｄ０７］
プロジェクトメンバの編集ステップＳ２Ｄ０７は、退場者の本登録ステップＳ２Ｄ０５にて本登録処理が実行された場合、既存プロジェクトのメンバが所属するグループから除外する処理を行う。
【０１６５】
具体的な処理として、申請テーブル２Ｄ２２（図５．１７参照）の決裁者番号に決裁者の社員番号を設定し、決裁フラグを設定する。また、退場メンバの社員番号に対するデータを実績テーブル２Ｄ２３（図５．８参照）とメンバテーブル２Ｄ２４（図５．１１参照）から取得し、実績テーブル２Ｄ２３（図５．８参照）の作業終了日と、メンバテーブル２Ｄ２４（図５．１１参照）の終了日を登録した日付で更新する。
【０１６６】
図２．５は、図１におけるプロジェクトメンバ評価登録処理手段１Ａ０５の処理動作例を示すフローチャートである。
【０１６７】
図１におけるプロジェクトメンバ評価登録処理手段１Ａ０５の処理目的は、プロジェクトメンバが他のメンバに対する評価を登録する機能を設けることで、現行のメンバ間の人間関係を管理者がシステムを通して確認できることでフォローするきっかけを得ることを可能にすること、また、新規プロジェクト立ち上げ時や、進行中のプロジェクトにおいて新たにメンバを選出または増員時の選出の際には、この評価情報を考慮した選出を実現することによってコミュニケーションの円滑化を意識したメンバ選出を可能にすることである。前提条件として、評価可能なメンバ対象者は同じプロジェクトに関わっているグループ内のメンバであること、リーダクラスはリーダ間も対象としている。
【０１６８】
評価対象メンバを特定している理由として、日頃、同じ環境で顔を見合わせているメンバを対象とすることで、評価の信憑性を高めるためである。ここでいうリーダクラスとは、社員テーブル１Ｂ０３（図５．３参照）に持つ役職区分が１（係長級）以上の社員または社員が過去に経験したプロジェクト情報より実績テーブル１Ｂ０８（図５．８参照）に持つ役割区分が１（ＴＬ：チームリーダ）以上の経験を保有している社員を指す。
【０１６９】
図２．５に示すように、プロジェクトメンバ評価登録処理手段１Ａ０５における処理は、［グループ選択ステップＳ２Ｅ０１］，［評価対象者の抽出ステップＳ２Ｅ０２］，［評価対象者一覧の出力ステップＳ２Ｅ０３］，［評価の登録ステップＳ２Ｅ０４］からなる。以下、各処理ステップＳ２Ｅ０１〜Ｓ２Ｅ０４について説明する。
【０１７０】
［グループ選択ステップＳ２Ｅ０１］
グループ選択ステップＳ２Ｅ０１では、評価者が評価可能なメンバを特定するための前処理としてグループで対象者を絞り込むために、グループを特定するための処理を行う。
【０１７１】
具体的な処理として、評価者が所属するプロジェクト情報について評価者の社員番号からメンバテーブル２Ｅ１１（図５．１１参照）よりプロジェクトＩＤを取得する。取得したプロジェクトＩＤからグループテーブル２Ｅ１２（図５．１０参照）よりグループＩＤを取得する。
【０１７２】
評価者がリーダクラスでない場合は、評価者が所属するグループＩＤを評価対象者の抽出ステップＳ２Ｅ０２の処理条件として設定する。評価者がリーダクラスである場合は、評価者が所属するプロジェクトに属するグループＩＤ全てを評価対象者の抽出ステップＳ２Ｅ０２の処理条件として設定する。
【０１７３】
［評価対象者の抽出ステップＳ２Ｅ０２］
評価対象者の抽出ステップＳ２Ｅ０２では、グループ選択ステップＳ２Ｅ０１にて設定されたグループＩＤからそのグループＩＤに属するメンバを評価対象者として抽出するための処理を行う。
【０１７４】
具体的な処理として、グループ選択ステップＳ２Ｅ０１にて設定されたグループＩＤよりメンバテーブル２Ｅ１３（図５．１１参照）から社員番号を取得し、取得した社員番号より社員テーブル２Ｅ１５（図５．３参照）から画面に表示するための名前（姓、名）を取得する。
【０１７５】
また、既に一度、評価を登録している対象者がいれば、取得した社員番号と評価者の社員番号より評価テーブル２Ｅ１６（図５．１４参照）から評価区分、コメントを抽出する。ただし、評価者がリーダクラスである場合、評価者が所属するグループ以外のグループに属するメンバに限って、評価者が所属するグループ以外のグループＩＤからメンバテーブル２Ｅ１３（図５．１１参照）より代表フラグが１となっている社員番号のみ取得対象となる。
【０１７６】
［評価対象者一覧の出力ステップＳ２Ｅ０３］
評価対象者一覧の出力ステップＳ２Ｅ０３では、評価対象者の抽出ステップＳ２Ｅ０２で抽出されたメンバ情報を画面に表示させるための編集処理を行う。画面上に表示する評価のリストはコードマスタ２Ｅ１７より取得する。
【０１７７】
［評価の登録ステップＳ２Ｅ０４］
評価の登録ステップＳ２Ｅ０４では、評価対象者一覧の出力ステップＳ２Ｅ０３で一覧表示されたメンバ情報から、評価したい対象者を選択し、自分にとって、評価対象者はどういう影響があるのかを視点にした質問形式と、質問に対する詳細な内容を登録する処理を行う。
【０１７８】
また、登録された情報について、一緒に仕事をしたくないという評価をしたメンバが１名以上いれば、プロジェクトフォロー対象者検索処理手段１Ａ０３の対象データとして、フォローテーブル２Ｅ１８（図５．１３参照）に登録され、メンバの上長にフォロー依頼のメールを通知する処理を行う。そうすることで、リアルタイムにメンバからのアラーム情報を機械的にチェックすることが可能になり、迅速な対応につなげられる。
【０１７９】
図２．６は、図１における個人要望登録処理手段１Ａ０６の処理動作例を示すフローチャートである。
【０１８０】
図１における個人要望登録処理手段１Ａ０６の処理の目的は、プロジェクトメンバ個人において抱えている問題、プロジェクトを遂行するにあたり困難が生じた場合に退場の要望事項を登録する画面を用意し、管理者にその要望事項が伝達できる仕掛けを用意することで、面と向かっては相談し難いことを当機能によって容易にすることでできる。よって、個人で抱える危険性を事前に防ぐ１つの手段となる。
【０１８１】
図２．６に示すように、個人要望登録処理手段１Ａ０６における処理は、［要望の入力ステップＳ２Ｆ０１］，［要望の登録ステップＳ２Ｆ０２］からなる。以下、各処理ステップＳ２Ｆ０１〜Ｓ２Ｆ０２について説明する。
【０１８２】
［要望の入力ステップＳ２Ｆ０１］
要望の入力ステップＳ２Ｆ０１では、現在従事している仕事や人間関係について要望事項を入力する。
【０１８３】
操作手段は、画面からの入力となる。入力内容は定型の質問事項（仕事量、勤務時間、仕事内容、人間関係）に対して、各々の事項に対する詳細がプルダウンにリストアップされ、その中から選択する形式をとる。
【０１８４】
定型の質問事項については、コードマスタ２Ｆ１３（図５．１参照）から取得する。異動希望の有無と異動希望日やその理由をフリーで入力する事ができる。入力画面には、要望テーブル２Ｆ１１（図５．１５参照）、要望詳細テーブル２Ｆ１２（図５．１６参照）に既に登録されていれば、その情報が画面に表示されるように情報を取得する。
【０１８５】
［要望の登録ステップＳ２Ｆ０２］
要望の登録ステップＳ２Ｆ０２では、要望の入力ステップＳ２Ｆ０１にて入力された情報を要望テーブル２Ｆ１４（図５．１５参照）、要望詳細テーブル２Ｆ１５（図５．１６参照）に格納する。登録の際、現在携わっているプロジェクトの情報も同時に登録される。
【０１８６】
図３は、図１における画面遷移図である。以下、図３に示す画面遷移図を説明する。
【０１８７】
［ログイン画面３Ａ０１］
ログイン画面３Ａ０１では、ユーザＩＤとパスワードを入力し、ＯＫボタンを押下する。入力されたユーザＩＤとパスワードが認証テーブル１Ｂ０２（図５．２参照）上に存在し、かつ利用可能期限内（適用開始日〜適用終了日）のユーザであれば、メニュー画面３Ａ０２に遷移する。該当データが存在しない、または利用可能期限外の場合は、当システム利用不可のため、エラーメッセージを表示する。
【０１８８】
［メニュー画面３Ａ０２］
メニュー画面３Ａ０２では、ログインしているユーザが使用できるメニューのみ表示する。
【０１８９】
メニューの使用可否は、社員テーブル１Ｂ０３（図５．３参照）の権限区分のデータを元に制御する。メニューの項目として、「プロジェクト候補者検索」、「プロジェクト候補者変更・申請」、「プロジェクトフォロー対象者検索」、「プロジェクト退場者変更・申請」、「プロジェクトメンバ評価」、「個人要望登録」および「申請状況照会」がある。
【０１９０】
「プロジェクト候補者検索」からは、プロジェクト候補者検索画面３Ａ０４へ遷移する。「プロジェクト候補者変更・申請」からは、プロジェクト候補者変更・申請画面３Ａ０７へ遷移する。「プロジェクトフォロー対象者検索」からは、プロジェクトフォロー対象者検索画面３Ａ１０に遷移する。
【０１９１】
「プロジェクト退場者変更・申請」からは、プロジェクト退場者変更・申請画面３Ａ１１に遷移する。「プロジェクトメンバ評価」は、プロジェクトメンバ評価登録画面３Ａ１４に遷移する。「個人要望登録」は、個人要望登録画面３Ａ１５に遷移する。「申請状況照会」は、申請状況照会画面３Ａ１６に遷移する。
【０１９２】
また、「選択」ボタンを押下した場合は、メニュー画面３Ａ０２の上に別画面としてプロジェクト選択サブ画面３Ａ０３を表示する。プロジェクト選択サブ画面３Ａ０３にてプロジェクトを選択し、呼び出し元であるメニュー画面３Ａ０２へ選択したプロジェクトのデータを渡した後にメニュー画面３Ａ０２においてメニューの項目を押下した場合は、選択したプロジェクトを入力条件として設定した状態で次画面へ遷移する（但し、選択したプロジェクトを入力条件として使用するのは、プロジェクト候補者検索画面３Ａ０４、プロジェクト候補者変更・申請画面３Ａ０７、プロジェクトフォロー対象者検索画面３Ａ１０、プロジェクト退場者変更・申請画面３Ａ１１、プロジェクトメンバ評価登録画面３Ａ１４および申請状況照会画面３Ａ１６の６画面）。
【０１９３】
［プロジェクト選択サブ画面３Ａ０３］
プロジェクト選択サブ画面３Ａ０３では、組織マスタ１Ｂ０４（図５．４参照）とプロジェクトテーブル１Ｂ０９（図５．９参照）から現在進行中のプロジェクトを取得し、プルダウンボックスにて選択可能とする。
【０１９４】
プロジェクトを選択した状態で「ＯＫ」ボタンを押下すると、呼び出し元であるメニュー画面３Ａ０２へ選択したプロジェクトのデータを渡して、プロジェクト選択サブ画面３Ａ０３を閉じる（メニュー画面３Ａ０２に選択したプロジェクトを表示する）。プロジェクトを選択せずに「ＯＫ」ボタンを押下した場合はエラーメッセージを表示する。
【０１９５】
［プロジェクト候補者検索画面３Ａ０４］（図４．１参照）
プロジェクト候補者検索画面３Ａ０４では、検索条件（スキル（図４．１の４Ａ０１）、作業開始日（同４Ａ０１）、グループ人数（同４Ａ０３）、グループコスト（同４Ａ０４）、組織（同４Ａ０５）、グループ名（同４Ａ０７））を入力する。
【０１９６】
検索条件のスキルの「選択」ボタン４Ａ０１を押下した場合、プロジェクト候補者検索画面３Ａ０４の上に別画面としてスキル選択サブ画面３Ａ０５を表示する。
【０１９７】
検索条件の組織の「選択」ボタン４Ａ０５を押下した場合、プロジェクト候補者検索画面３Ａ０４の上に別画面として組織選択サブ画面３Ａ０６を表示する。
【０１９８】
検索条件を入力後、「グループ検索」ボタン４Ａ０６または「個人検索」ボタン４Ａ０８を押下し、社員テーブル１Ｂ０３（図５．３参照）、スキルテーブル１Ｂ０７（図５．７参照）、実績テーブル１Ｂ０８（図５．８参照）、グループテーブル１Ｂ１０（図５．１０参照）、メンバテーブル１Ｂ１１（図５．１１参照）、評価テーブル１Ｂ１４（図５．１４参照）、要望テーブル１Ｂ１５（図５．１５参照）から候補グループ・候補メンバ（氏名、作業開始日、コスト、組織）、予定コストを取得、表示する（図４．１の４Ａ１０）。候補メンバは複数選択することができ、その選択したメンバ（同４Ａ１６）で構成されるグループに対し、グループ名を入力する（同４Ａ１７）。
【０１９９】
「登録」ボタン４Ａ１８を押下すると、プロジェクト候補者変更・申請画面３Ａ０７へ遷移する。候補メンバが選択されていない状態、選択した候補メンバ内にリーダクラスのメンバが１人もいない状態またはグループ名が入力されていない状態で「登録」ボタン４Ａ１８を押下した場合、エラーメッセージを表示する。
【０２００】
［スキル選択サブ画面３Ａ０５］
スキル選択サブ画面３Ａ０５では、コードマスタ１Ｂ０１（図５．１参照）からスキルの情報を取得、表示し、チェックボックスにチェックを付けることでスキルを選択する（複数選択可能）。
【０２０１】
スキルを選択した状態で「ＯＫ」ボタンを押下すると、呼び出し元であるプロジェクト候補者検索画面３Ａ０４へ選択したスキルのデータを渡して、スキル選択サブ画面３Ａ０５を閉じる（プロジェクト候補者検索画面３Ａ０４に選択したスキルを表示する）。スキルを選択せずに「ＯＫ」ボタンを押下した場合、エラーメッセージを表示する。
【０２０２】
［組織選択サブ画面３Ａ０６］
組織選択サブ画面３Ａ０６では、組織マスタ１Ｂ０４から現在進行中の組織を取得し、プルダウンボックスにて選択可能とする。
【０２０３】
組織を選択した状態で「ＯＫ」ボタンを押下すると、呼び出し元であるプロジェクト候補者検索画面３Ａ０４へ選択した組織のデータを渡して、組織選択サブ画面３Ａ０６を閉じる（プロジェクト候補者検索画面３Ａ０４に選択した組織を表示する）。組織を選択せずに「ＯＫ」ボタンを押下した場合はエラーメッセージを表示する。
【０２０４】
［プロジェクト候補者変更・申請画面３Ａ０７］
プロジェクト候補者変更・申請画面３Ａ０７では、プロジェクト候補者検索画面３Ａ０４で登録したグループ名、メンバ名を社員テーブル１Ｂ０３（図５．３参照）、グループテーブル１Ｂ１０（図５．１０参照）、メンバテーブル１Ｂ１１（図５．１１参照）、申請テーブル１Ｂ１７（図５．１７参照）から取得、表示する。
【０２０５】
メンバの変更をする場合は、削除するメンバを選択し（複数選択可）、「削除」ボタンを押下する。グループのメンバを上長へ申請（承認依頼）する場合は、申請先を選択の上、「申請」ボタンを押下する（申請先選択の「選択」ボタンを押下するとプロジェクト候補者変更・申請画面３Ａ０７の上に別画面として申請先選択サブ画面３Ａ０８を表示する）。
【０２０６】
「申請」ボタン押下後はメニュー画面３Ａ０２へ遷移する。「続けて登録」ボタンを押下した場合は、プロジェクト候補者検索画面３Ａ０４へ遷移する。なお、メンバを全員削除した場合や、メンバを削除後グループ内にリーダクラスのメンバが１人もいなくなってしまった場合は、「申請」ボタンを非活性にして申請できないようにする。
【０２０７】
［申請先選択サブ画面３Ａ０８］
申請先選択サブ画面３Ａ０８では、検索条件（社員番号、姓、名）を入力する。検索条件を入力後、「検索」ボタンを押下し、社員テーブル１Ｂ０３（図５．３参照）、組織マスタ１Ｂ０４から社員の情報を取得、表示し、選択可能とする。申請先を選択した状態で「ＯＫ」ボタンを押下すると、呼び出し元であるプロジェクト候補者変更・申請画面３Ａ０７へ選択した申請先のデータを渡して、申請先選択サブ画面３Ａ０８を閉じる（プロジェクト候補者変更・申請画面３Ａ０７に選択した申請先を表示する）。申請先を選択せずに「ＯＫ」ボタンを押下した場合、エラーメッセージを表示する。
【０２０８】
［プロジェクト候補者登録画面３Ａ０９］
プロジェクト候補者登録画面３Ａ０９は、メールに貼られたリンクからログイン画面３Ａ０１を経由して遷移する（メールはプロジェクト候補者変更・申請画面３Ａ０７で申請先として選択されていた上長宛てに届く）。
【０２０９】
プロジェクト候補者登録画面３Ａ０９では、プロジェクト候補者変更・申請画面３Ａ０７で申請されたグループ名、メンバ名をコードマスタ１Ｂ０１（図５．１参照）、プロジェクトテーブル１Ｂ０９（図５．９参照）、グループテーブル１Ｂ１０（図５．１０参照）、メンバテーブル１Ｂ１１（図５．１１参照）、申請テーブル１Ｂ１７（図５．１７参照）から取得、表示する。
【０２１０】
差戻しにする場合は差戻し理由を入力し、「差戻し」ボタンを押下する。プロジェクトメンバとして承認する場合は、「登録」ボタンを押下する。「差戻し」ボタンを押下した場合も、「登録」ボタンを押下した場合も、共にメニュー画面３Ａ０２へ遷移する。
【０２１１】
［プロジェクトフォロー対象者検索画面３Ａ１０］（図４．２参照）
プロジェクトフォロー対象者検索画面３Ａ１０では、検索条件（欠勤日数４Ｂ０１、年休日数４Ｂ０２、進捗（遅延）日数４Ｂ０３、超勤時間４Ｂ０４、グループ名４Ｂ０５）を入力する。
【０２１２】
検索条件を入力後、「検索」ボタン４Ｂ０６を押下し、社員テーブル１Ｂ０３（図５．３参照）、フォローテーブル１Ｂ１３（図５．１３参照；フォローテーブル１Ｂ１３はコードマスタ１Ｂ０１、勤務表テーブル１Ｂ０５、年休テーブル１Ｂ０６、進捗表テーブル１Ｂ１２を元に作成）からフォロー対象者（氏名、欠勤日数、年休日数、進捗日数、超勤時間、グループ名）を取得、表示する（図４．２の４Ｂ０７）。
【０２１３】
検索結果が０件の場合は、対象データなしのメッセージを表示する。必要に応じて退場者を選択する（複数選択可）。「登録」ボタン４Ｂ１３を押下すると、プロジェクト退場者変更・申請画面３Ａ１１へ遷移する。退場者が選択されていない状態で「登録」ボタン４Ｂ１３を押下した場合、エラーメッセージを表示する。
【０２１４】
［プロジェクト退場者変更・申請画面３Ａ１１］
プロジェクト退場者変更・申請画面３Ａ１１では、プロジェクトフォロー対象者検索画面３Ａ１０で登録した退場者（氏名、グループ名）を社員テーブル１Ｂ０３（図５．３参照）、フォローテーブル１Ｂ１３（図５．１３参照）、申請テーブル１Ｂ１７（図５．１７参照）から取得、表示する。
【０２１５】
メンバの変更をする場合は、削除するメンバを選択し（複数選択可）、「削除」ボタンを押下する。グループのメンバを上長へ申請（承認依頼）する場合は、申請先を選択の上、「申請」ボタンを押下する（申請先選択の「選択」ボタンを押下するとプロジェクト退場者変更・申請画面３Ａ１１の上に別画面として申請先選択サブ画面３Ａ１２を表示する）。
【０２１６】
「申請」ボタン押下後はメニュー画面３Ａ０２へ遷移する。「続けて登録」ボタンを押下した場合は、プロジェクトフォロー対象者検索画面３Ａ１０へ遷移する。なお、メンバを全員削除した場合は、「申請」ボタンを非活性にして申請できないようにする。
【０２１７】
［申請先選択サブ画面３Ａ１２］
申請先選択サブ画面３Ａ１２では、検索条件（社員番号、姓、名）を入力する。検索条件を入力後、「検索」ボタンを押下し、社員テーブル１Ｂ０３（図５．３参照）、組織マスタ１Ｂ０４（図５．４参照）から社員の情報を取得、表示し、選択可能とする。
【０２１８】
申請先を選択した状態で「ＯＫ」ボタンを押下すると、呼び出し元であるプロジェクト退場者変更・申請画面３Ａ１１へ選択した申請先のデータを渡して、申請先選択サブ画面３Ａ１２を閉じる（プロジェクト退場者変更・申請画面３Ａ１１に選択した申請先を表示する）。申請先を選択せずに「ＯＫ」ボタンを押下した場合、エラーメッセージを表示する。
【０２１９】
［プロジェクト退場者登録画面３Ａ１３］
プロジェクト退場者登録画面３Ａ１３は、メールに貼られたリンクからログイン画面３Ａ０１を経由して遷移する（メールはプロジェクト退場者変更・申請画面３Ａ１１で申請先として選択されていた上長宛てに届く）。
【０２２０】
プロジェクト退場者登録画面３Ａ１３では、プロジェクト退場者変更・申請画面３Ａ１１で申請された退場者（氏名、グループ名、退場理由）を社員テーブル１Ｂ０３（図５．３参照）、実績テーブル１Ｂ０８（図５．８参照）、グループテーブル１Ｂ１０（図５．１０参照）、メンバテーブル１Ｂ１１（図５．１１参照）、フォローテーブル１Ｂ１３（図５．１３参照）、申請テーブル１Ｂ１７（図５．１７参照）から取得、表示する。差戻しにする場合は差戻し理由を入力し、「差戻し」ボタンを押下する。
【０２２１】
退場者として承認する場合は、「登録」ボタンを押下する。「差戻し」ボタンを押下した場合も、「登録」ボタンを押下した場合も、共にメニュー画面３Ａ０２へ遷移する。
【０２２２】
［プロジェクトメンバ評価登録画面３Ａ１４］（図４．３参照）
プロジェクトメンバ評価登録画面３Ａ１４では、検索条件（グループ名）を選択する（図４．３の４Ｃ０１）。検索条件を選択後、コードマスタ１Ｂ０１（図５．１参照）、社員テーブル１Ｂ０３（図５．３参照）、グループテーブル１Ｂ１０（図５．１０参照）、メンバテーブル１Ｂ１１（図５．１１参照）、評価テーブル１Ｂ１４（図５．１４参照）から評価対象者（氏名、評価）を取得、表示する（図４．３の４Ｃ０２）。必要に応じて評価対象者を選択し、評価（図４．３の４Ｃ０３）、コメント（図４．３の４Ｃ０４）を入力する。「登録」ボタン（図４．３の４Ｃ０５）を押下後、登録完了のメッセージを表示する。
【０２２３】
［個人要望登録画面３Ａ１５］（図４．４参照）
個人要望登録画面３Ａ１５では、コードマスタ１Ｂ０１（図５．１参照）、社員テーブル１Ｂ０３（図５．３参照）、要望テーブル１Ｂ１５（図５．１５参照）から異動の要望の有無を、要望詳細テーブル１Ｂ１６（図５．１６参照）から、個人要望情報（仕事量（図４．４の４Ｄ０１）、勤務時間（同４Ｄ０２）、仕事内容（同４Ｄ０３）、人間関係（同４Ｄ０４）、異動希望（同４Ｄ０５）、異動希望日（同４Ｄ０６）、コメント（同４Ｄ０７））を取得、表示する。
【０２２４】
なお、ユーザが初めて本画面を表示した場合は全て空白を表示する。必要に応じて個人要望情報を入力（変更）する。「登録」ボタン（図４．４の４Ｄ０８）を押下後、登録完了のメッセージを表示する。
【０２２５】
［申請状況照会画面３Ａ１６］
申請状況照会画面３Ａ１６では、社員テーブル１Ｂ０３（図５．３参照）、プロジェクトテーブル１Ｂ０９（図５．９参照）、申請テーブル１Ｂ１７（図５．１７参照）から、ログインしているユーザに関連している各申請の情報（申請ＩＤ、申請内容、ステータス（申請中フラグ，差戻フラグ，決裁フラグ，取消フラグなど）、次処理者）を取得し、表示する。
【０２２６】
以下、本発明に係る操作端末３に表示される画面レイアウトについて説明する。
図４．１、図４．２、図４．３、図４．４は、本発明に係るプロジェクト人材選定支援管理システムにおける画面レイアウトの一例を示す図である。以下、図４．１、図４．２、図４．３、図４．４に示す各画面レイアウト図について詳細に説明する。
【０２２７】
図４．１は、プロジェクト候補者検索画面の画面レイアウトの一例を示す図である。
当画面では、新規立ち上げ時のプロジェクトにおけるメンバ候補検索はもちろんのこと、進行中の既存プロジェクトにおいてもチームの追加に伴うメンバ候補検索や既存チームに対するメンバ補充に伴うメンバ候補検索ができる。
【０２２８】
新規プロジェクトによるメンバ候補検索か、既存プロジェクトによるメンバ候補検索かは、メニュー画面３Ａ０２にてプロジェクトを選択したか否かにより判定する（プロジェクトを選択していない場合は新規、プロジェクトを選択した場合は既存）。
【０２２９】
メニュー画面３Ａ０２にてプロジェクトを未選択で遷移してきた場合は、ポップアップを表示し、プロジェクト名を入れた後、新規プロジェクトモードになり画面タイトル４Ａ１９にポップアップで入力したプロジェクト名が設定される。
【０２３０】
メニュー画面３Ａ０２にてプロジェクトを選択した状態で遷移してきた場合は、既存プロジェクトモードになり画面タイトル４Ａ１９にメニュー画面３Ａ０２で選択したプロジェクト名が設定される。
【０２３１】
画面から指定する検索条件として、スキル情報４Ａ０１、作業開始日４Ａ０２、グループ人数４Ａ０３、グループコスト４Ａ０４、組織情報４Ａ０５、グループ名４Ａ０７がある。
【０２３２】
スキル情報４Ａ０１としては技術（言語、資格、ソフト知識、ハード知識）に関すること、業務（金融、官公庁、流通、電力等）に関する情報を複数指定できる。作業開始日４Ａ０２はその指定した日から参画できるかどうかを条件として指定できる。
【０２３３】
グループ人数４Ａ０３やグループコスト４Ａ０４は、当画面では１チーム単位でメンバ候補を選択する機能になっているためグループとしての制約も条件として指定することが可能になっている。
【０２３４】
グループ名４Ａ０７については、既存のプロジェクトにおいて、あるグループにメンバを追加する場合にそのグループを指定できる条件になっている。
【０２３５】
更に、メンバ候補を検索するにあたり画面で指定する条件以外に常に最適なメンバ候補となるべく条件をあらかじめ設定している。その条件は、第三者における評価情報からグループ内におけるお互いの評価が良好であることと、グループの中にリーダクラスにあたるメンバが１名選択されていること、他にグループが形成されていた場合、各グループのリーダたるメンバ同士の評価が高いものも条件としている。
【０２３６】
以上の検索条件により、当画面のグループ検索ボタン４Ａ０６を押下すると、候補メンバ一覧４Ａ１０に検索条件に該当したメンバ候補者が一覧表示される。また、予定コスト４Ａ１１には、メンバ候補となったメンバの単価の合計値が設定される。
【０２３７】
候補グループプルダウン４Ａ０９は、新規時は初期値としてグループ１と表示される。検索条件にグループ名４Ａ０７に指定があり個人選択ボタン４Ａ０８を押下した場合は、指定されたグループ名が表示される。
【０２３８】
検索処理実行後の手順として、操作キーボタンを使用して、左記の候補メンバ一覧４Ａ１０から右記の候補メンバ一覧４Ａ１６へ最終メンバ候補者を移動させる操作を行う。
【０２３９】
操作キーボタン４Ａ１２は一覧上のリストを全て左から右へ移動させる。操作キーボタン４Ａ１３は一覧上の選択された行のみ左から右へ移動させる。操作キーボタン４Ａ１４は一覧上のリストを全て右から左へ移動させる。操作キーボタン４Ａ１５は一覧上の選択された行のみ右から左へ移動させる。
【０２４０】
移動させた後、グループ名入力欄４Ａ１７に任意のグループ名を入力し登録ボタン４Ａ１８を押下することで、当画面にて決定したメンバ候補者情報が仮登録される。
【０２４１】
図４．２は、プロジェクトフォロー対象者検索画面の画面レイアウトの一例を示す図である。
当画面では、勤務表や進捗表などから休む頻度の多いメンバ、進捗が遅れているメンバ、規定の残業時間を超えているメンバを検索できる。また、プロジェクトからの退場処理（仮登録）もできる。
【０２４２】
画面から指定する検索条件として、欠勤４Ｂ０１、年休４Ｂ０２、進捗（遅延）４Ｂ０３、超勤４Ｂ０４、グループ名４Ｂ０５がある。
【０２４３】
欠勤４Ｂ０１では欠勤日数を、年休４Ｂ０２では年休日数を、進捗（遅延）４Ｂ０３では遅延日数を、超勤４Ｂ０４では超勤時間を、グループ名４Ｂ０５には退場者がいるグループ名を指定し、検索条件とすることができる。
【０２４４】
検索条件を入力後、検索ボタン４Ｂ０６を押下することで、フォロー対象者一覧４Ｂ０７に該当者が出力される。検索処理実行後の手順として、操作キーボタンを使用して、フォロー対象者一覧４Ｂ０７から右記の退場者一覧４Ｂ１２へ最終退場者を移動させる操作を行う。
【０２４５】
操作キーボタン４Ｂ０８は一覧上のリストを全て左から右へ移動させる。操作キーボタン４Ｂ０９は一覧上の選択された行のみ左から右へ移動させる。操作キーボタン４Ｂ１０は一覧上のリストを全て右から左へ移動させる。操作キーボタン４Ｂ１１は一覧上の選択された行のみ右から左へ移動させる。
【０２４６】
移動させた後、登録ボタン４Ｂ１３を押下することで、当画面にて決定した退場者情報が仮登録される。
【０２４７】
図４．３は、プロジェクトメンバ評価登録画面の画面レイアウトの一例を示す図である。
当画面では、同グループのメンバに対する評価を入力することができる。グループ名４Ｃ０１を選択することによって、評価対象者一覧４Ｃ０２に選択したグループ名のメンバが表示される。
【０２４８】
評価対象者一覧４Ｃ０２で選択したメンバに対する評価を評価一覧４Ｃ０３から選択し、コメント４Ｃ０４には評価一覧で表現されてない、長所や短所を入力する。登録ボタン４Ｃ０５を押下することで、当画面にて入力した評価情報が登録される。
【０２４９】
図４．４は、個人要望登録画面の画面レイアウトの一例を示す図である。
当画面では、仕事量・勤務時間・仕事内容・人間関係・異動希望等の個人の要望を入力でき、この画面での異動希望をもとに新規プロジェクト立ち上げ時や途中のメンバ変更などを行う。
【０２５０】
仕事量４Ｄ０１には仕事量の『多い』，『普通』，『少ない』を、勤務時間４Ｄ０２には勤務時間の『多い』，『普通』，『少ない』を、仕事内容４Ｄ０３には仕事内容が『合っている』，『合っていない』を、人間関係４Ｄ０４には人間関係が『良い』，『悪い』を、異動希望４Ｄ０５には異動希望の『あり』，『なし』を、異動希望４Ｄ０５が『あり』の場合は異動希望日４Ｄ０６に日付の入力を、コメント４Ｄ０７には要望を記述し、最後に登録ボタン４Ｄ０８を押下することで、当画面にて入力した個人要望情報が登録される。
【０２５１】
なお、上記で説明した処理部１Ａにおける各手段（プロジェクト候補者検索処理手段１Ａ０１、プロジェクト候補者登録処理手段１Ａ０２、プロジェクトフォロー対象者検索処理手段１Ａ０３、プロジェクト退場者登録処理手段１Ａ０４、プロジェクトメンバ評価登録処理手段１Ａ０５および個人要望登録処理手段１Ａ０６）は、サーバ（プロジェクト人材選定支援管理システム）１を構成するコンピュータのＣＰＵやメモリなどのハードウェアにより各手段に対応するプログラムを実行（図２．１〜図２．６参照）することにより実現される。また、各手段に対応するプログラムはインターネットなどのネットワークなどのネットワークやＣＤ−ＲＯＭ、ＤＶＤ、ＦＤなどの記録媒体を介して市場に流通させることができる。
【符号の説明】
【０２５２】
１：サーバ（プロジェクト人材選定支援および人材管理システム（プロジェクト人材選定支援管理システム））
２：ネットワーク（インターネット）
３：操作端末
１Ａ：処理部
１Ｂ：データ部
１Ａ０１：プロジェクト候補者検索処理手段
１Ａ０２：プロジェクト候補者登録処理手段
１Ａ０３：プロジェクトフォロー対象者検索処理手段
１Ａ０４：プロジェクト退場者登録処理手段
１Ａ０５：プロジェクトメンバ評価登録処理手段
１Ａ０６：個人要望登録処理手段
１Ｂ０１，２Ｅ１７，２Ｆ１３：コードマスタ
１Ｂ０２：認証テーブル
１Ｂ０３，２Ａ１１，２Ａ１５，２Ａ１７，２Ａ１９，２Ｂ１２，２Ｂ２０，２Ｃ１８，２Ｄ１２，２Ｄ１９，２Ｅ１５：社員テーブル
１Ｂ０４：組織マスタ
１Ｂ０５，２Ｃ１２：勤務表テーブル
１Ｂ０６，２Ｃ１３：年休テーブル
１Ｂ０７：スキルテーブル
１Ｂ０８．２Ｄ２３：実績テーブル
１Ｂ０９，２Ｂ１５，２Ｂ２５，２Ｂ２６，２Ｃ１９，２Ｅ１４：プロジェクトテーブル
１Ｂ１０，２Ｂ１３，２Ｂ２１，２Ｄ２５，２Ｅ１２：グループテーブル
１Ｂ１１，２Ｂ１４，２Ｂ１６，２Ｂ１８，２Ｂ２２，２Ｄ２４，２Ｅ１１，２Ｅ１３：メンバテーブル
１Ｂ１２，２Ｃ１１：進捗表テーブル
１Ｂ１３，２Ｃ１６，２Ｃ１７，２Ｃ２０，２Ｄ１３，２Ｄ１４，２Ｄ１５，２Ｄ１７，２Ｄ２０，２Ｅ１８：フォローテーブル
１Ｂ１４，２Ｃ１４，２Ｅ１６：評価テーブル
１Ｂ１５，２Ｃ１５，２Ｆ１１，２Ｆ１４：要望テーブル
１Ｂ１６，２Ｆ１２，２Ｆ１５：要望詳細テーブル
１Ｂ１７，２Ｂ１１，２Ｂ１７，２Ｂ１９，２Ｂ２３，２Ｂ２４，２ｃ１１,２Ｄ１６，２Ｄ１８，２Ｄ２１，２Ｄ２２：申請テーブル
【特許請求の範囲】
【請求項１】
安定したプロジェクトチームを維持するためのプロジェクト人材選定支援管理システムであって、
プロジェクト進行期間中に各プロジェクトメンバの勤務状況，作業進捗状況，第三者からの評価情報およびプロジェクトメンバ個人の異動要望に関する情報を随時あるいは定期的に収集する収集手段と、該収集手段により収集された情報に基づいて安定したプロジェクトチームの維持の阻害要因となる情報を判定し、該該阻害要因となる情報を持つメンバ情報を退場候補者として抽出し退場者を選定する権限を有する管理者に提供するメンバ情報提供手段と、該退場候補者に基づいて退場者を選択して登録する手段、を有することを特徴とするプロジェクト人材選定支援管理システム。
【請求項２】
請求項１記載のプロジェクト人材選定支援管理システムにおいて、
プロジェクト進行期間中、随時あるいは定期的に、プロジェクトメンバ自身が仕事量，勤務時間，仕事内容，人間関係，あるいは異動希望に関する要望事項を登録する手段を有することを特徴とするプロジェクト人材選定支援管理システム。
【請求項３】
請求項１または２記載のプロジェクト人材選定支援管理システムにおいて、
プロジェクト進行期間中にプロジェクトからプロジェクトメンバの退場が必要になった場合に前記退場候補者を退場者として登録する手段と、該退場者を他のプロジェクトメンバ候補対象者として登録する手段を有することを特徴とするプロジェクト人材選定管理システム。
【請求項４】
請求項１から３のいずれかに記載のプロジェクト人材選定支援管理システムにおいて、
プロジェクト進行期間中にメンバの増員が必要となった場合に、既存のチームに新たなメンバを追加する手段とチーム単位で新しくメンバを追加する手段に加え、チームとメンバの人間関係について最適なメンバ候補を提供する手段を有することを特徴とするプロジェクト人材選定支援管理システム。
【請求項５】
請求項１から４のいずれかに記載のプロジェクト人材選定支援管理システムにおいて、
プロジェクトメンバを選定する場合、メンバの過去実績、スキル、およびコストを含むメンバ自身の能力に加え、チーム内におけるメンバ間の人間関係およびチーム間における人間関係を考慮して最適なメンバおよびチーム構成を選定する手段を有することを特徴とするプロジェクト人材選定支援管理システム。
【請求項６】
コンピュータを、請求項１から５のいずれかに記載のプロジェクト人材選定支援管理システムにおける各手段として機能させることを特徴とするプログラム。
【請求項７】
安定したプロジェクトチームを維持するためのコンピュータを用いたプロジェクト人材選定支援管理方法であって、
プロジェクト進行期間中に各プロジェクトメンバの勤務状況，作業進捗状況，第三者からの評価情報およびプロジェクトメンバ個人の異動要望に関する情報を随時あるいは定期的に収集する収集ステップと、該収集ステップにより収集された情報に基づいて安定したプロジェクトチームの維持の阻害要因となる情報を判定し、該該阻害要因となる情報を持つメンバ情報を退場候補者として抽出し退場者を選定する権限を有する管理者に提供するメンバ情報提供ステップと、該退場候補者に基づいて退場者を選択して登録するステップと、を有することを特徴とするプロジェクト人材選定支援管理方法。
【請求項８】
請求項７記載のプロジェクト人材選定支援管理方法において、
プロジェクト進行期間中、随時あるいは定期的に、プロジェクトメンバ自身が仕事量，勤務時間，仕事内容，人間関係，あるいは異動希望に関する要望事項を登録するステップを有することを特徴とするプロジェクト人材選定支援管理方法。
【請求項９】
請求項７または８記載のプロジェクト人材選定支援管理方法において、
プロジェクト進行期間中にプロジェクトからプロジェクトメンバの退場が必要になった場合に前記退場候補者を退場者として登録するステップと、該退場者を他のプロジェクトメンバ候補対象者として登録するステップを有することを特徴とするプロジェクト人材選定管理方法。
【請求項１０】
請求項７から９のいずれかに記載のプロジェクト人材選定支援管理方法において、
プロジェクト進行期間中にメンバの増員が必要となった場合に、既存のチームに新たなメンバを追加するステップとチーム単位で新しくメンバを追加するステップに加え、チームとメンバの人間関係について最適なメンバ候補を提供するステップを有することを特徴とするプロジェクト人材選定支援管理方法。
【請求項１１】
請求項７から１０のいずれかに記載のプロジェクト人材選定支援管理方法において、
プロジェクトメンバを選定する場合、メンバの過去実績、スキル、およびコストを含むメンバ自身の能力に加え、チーム内におけるメンバ間の人間関係およびチーム間における人間関係を考慮して最適なメンバおよびチーム構成を選定するステップを有することを特徴とするプロジェクト人材選定支援管理方法。
【請求項１】
安定したプロジェクトチームを維持するためのプロジェクト人材選定支援管理システムであって、
プロジェクト進行期間中に各プロジェクトメンバの勤務状況，作業進捗状況，第三者からの評価情報およびプロジェクトメンバ個人の異動要望に関する情報を随時あるいは定期的に収集する収集手段と、該収集手段により収集された情報に基づいて安定したプロジェクトチームの維持の阻害要因となる情報を判定し、該該阻害要因となる情報を持つメンバ情報を退場候補者として抽出し退場者を選定する権限を有する管理者に提供するメンバ情報提供手段と、該退場候補者に基づいて退場者を選択して登録する手段、を有することを特徴とするプロジェクト人材選定支援管理システム。
【請求項２】
請求項１記載のプロジェクト人材選定支援管理システムにおいて、
プロジェクト進行期間中、随時あるいは定期的に、プロジェクトメンバ自身が仕事量，勤務時間，仕事内容，人間関係，あるいは異動希望に関する要望事項を登録する手段を有することを特徴とするプロジェクト人材選定支援管理システム。
【請求項３】
請求項１または２記載のプロジェクト人材選定支援管理システムにおいて、
プロジェクト進行期間中にプロジェクトからプロジェクトメンバの退場が必要になった場合に前記退場候補者を退場者として登録する手段と、該退場者を他のプロジェクトメンバ候補対象者として登録する手段を有することを特徴とするプロジェクト人材選定管理システム。
【請求項４】
請求項１から３のいずれかに記載のプロジェクト人材選定支援管理システムにおいて、
プロジェクト進行期間中にメンバの増員が必要となった場合に、既存のチームに新たなメンバを追加する手段とチーム単位で新しくメンバを追加する手段に加え、チームとメンバの人間関係について最適なメンバ候補を提供する手段を有することを特徴とするプロジェクト人材選定支援管理システム。
【請求項５】
請求項１から４のいずれかに記載のプロジェクト人材選定支援管理システムにおいて、
プロジェクトメンバを選定する場合、メンバの過去実績、スキル、およびコストを含むメンバ自身の能力に加え、チーム内におけるメンバ間の人間関係およびチーム間における人間関係を考慮して最適なメンバおよびチーム構成を選定する手段を有することを特徴とするプロジェクト人材選定支援管理システム。
【請求項６】
コンピュータを、請求項１から５のいずれかに記載のプロジェクト人材選定支援管理システムにおける各手段として機能させることを特徴とするプログラム。
【請求項７】
安定したプロジェクトチームを維持するためのコンピュータを用いたプロジェクト人材選定支援管理方法であって、
プロジェクト進行期間中に各プロジェクトメンバの勤務状況，作業進捗状況，第三者からの評価情報およびプロジェクトメンバ個人の異動要望に関する情報を随時あるいは定期的に収集する収集ステップと、該収集ステップにより収集された情報に基づいて安定したプロジェクトチームの維持の阻害要因となる情報を判定し、該該阻害要因となる情報を持つメンバ情報を退場候補者として抽出し退場者を選定する権限を有する管理者に提供するメンバ情報提供ステップと、該退場候補者に基づいて退場者を選択して登録するステップと、を有することを特徴とするプロジェクト人材選定支援管理方法。
【請求項８】
請求項７記載のプロジェクト人材選定支援管理方法において、
プロジェクト進行期間中、随時あるいは定期的に、プロジェクトメンバ自身が仕事量，勤務時間，仕事内容，人間関係，あるいは異動希望に関する要望事項を登録するステップを有することを特徴とするプロジェクト人材選定支援管理方法。
【請求項９】
請求項７または８記載のプロジェクト人材選定支援管理方法において、
プロジェクト進行期間中にプロジェクトからプロジェクトメンバの退場が必要になった場合に前記退場候補者を退場者として登録するステップと、該退場者を他のプロジェクトメンバ候補対象者として登録するステップを有することを特徴とするプロジェクト人材選定管理方法。
【請求項１０】
請求項７から９のいずれかに記載のプロジェクト人材選定支援管理方法において、
プロジェクト進行期間中にメンバの増員が必要となった場合に、既存のチームに新たなメンバを追加するステップとチーム単位で新しくメンバを追加するステップに加え、チームとメンバの人間関係について最適なメンバ候補を提供するステップを有することを特徴とするプロジェクト人材選定支援管理方法。
【請求項１１】
請求項７から１０のいずれかに記載のプロジェクト人材選定支援管理方法において、
プロジェクトメンバを選定する場合、メンバの過去実績、スキル、およびコストを含むメンバ自身の能力に加え、チーム内におけるメンバ間の人間関係およびチーム間における人間関係を考慮して最適なメンバおよびチーム構成を選定するステップを有することを特徴とするプロジェクト人材選定支援管理方法。
【図１】
【図２．１】
【図２．２】
【図２．３】
【図２．４】
【図２．５】
【図２．６】
【図３】
【図４．１】
【図４．２】
【図４．３】
【図４．４】
【図５．１】
【図５．２】
【図５．３】
【図５．４】
【図５．５】
【図５．６】
【図５．７】
【図５．８】
【図５．９】
【図５．１０】
【図５．１１】
【図５．１２】
【図５．１３】
【図５．１４】
【図５．１５】
【図５．１６】
【図５．１７】
【図２．１】
【図２．２】
【図２．３】
【図２．４】
【図２．５】
【図２．６】
【図３】
【図４．１】
【図４．２】
【図４．３】
【図４．４】
【図５．１】
【図５．２】
【図５．３】
【図５．４】
【図５．５】
【図５．６】
【図５．７】
【図５．８】
【図５．９】
【図５．１０】
【図５．１１】
【図５．１２】
【図５．１３】
【図５．１４】
【図５．１５】
【図５．１６】
【図５．１７】
【公開番号】特開２０１１−８３８７（Ｐ２０１１−８３８７Ａ）
【公開日】平成２３年１月１３日（２０１１．１．１３）
【国際特許分類】
【出願番号】特願２００９−１４９６１５（Ｐ２００９−１４９６１５）
【出願日】平成２１年６月２４日（２００９．６．２４）
【出願人】（０００１５２９８５）株式会社日立情報システムズ (409)
【公開日】平成２３年１月１３日（２０１１．１．１３）
【国際特許分類】
【出願日】平成２１年６月２４日（２００９．６．２４）
【出願人】（０００１５２９８５）株式会社日立情報システムズ (409)
[ Back to top ]