JP2006099751A - プロジェクトを構成するタスクに人員を割当てるための方法、プログラムおよびコンピュータ - Google Patents

Abstract

【課題】プロジェクト管理の分野において、プロジェクトへ人員を割当てた後に、人員の状況が変動した場合であっても、人員データの変更に応じて動的な人員の割当てを可能にする。
【解決手段】人員割当てシステム１０は、プロジェクトを構成する複数のタスクに関するデータを管理するプロジェクト管理システム２０と、人員に関するデータを管理する人事管理システム３０に接続され、すでに人員を割当て済みのタスクに関する情報は、プロジェクト管理システム２０にタスクデータとして保持され、そのタスクデータには、割当てられた人員の少なくとも識別データが関連付けられ、この識別データは、人事管理システム３０に保持されている人員データにも含まれているので、レコード検索のキー情報として用いることができる。
【選択図】図１

Description

本発明は、研究、開発、製造等のプロジェクトに人員を割当てるためのシステムおよび方法に関し、特に、割当て後に人員データに変更があっても動的に人員の割当てを可能にするシステムおよび方法に関する。

プロジェクト管理の分野で、プロジェクトに最適な人員を割当てる方法としていくつかの技術が提案されている。特許文献１に記載の「人材供給最適化方法」や特許文献２に記載の「リソース管理サーバ、人材管理方法、及び人材管理システム」がその例である。

特許文献１は、必要なスキルをもった人員を、特定の事業部内からだけでなく会社組織全体から選択して、対象のプロジェクトに割当てることを可能にするシステムおよび方法を開示している。このシステムにおいては、プロジェクトに割当て可能な人員に関するデータ（人員データ）が、人事ファイル、スキルファイル、プロジェクト管理能力ファイルとしてあらかじめ登録される。第１の実施形態では、人員の検索要求に応答して必要な人員を検索して抽出する方法が開示されている。第２の実施形態では、登録されている人員のデータを検索要求の内容と照合することで、ある特定の人員に適合するプロジェクトの有無を検索する方法が開示されている。いずれの場合も、人員データはあらかじめ登録された固定のものであることを前提に、プロジェクトの要件が特定されたことに応答して、プロジェクトと人員のマッチング作業が実行される。

特許文献２は、人員に関連する情報（人事データベース）とスキルに関する情報（ナレッジ・データベース）をプロジェクト管理ツールとリンクさせることによって、個々の人員の能力を有効に活用できるリソース管理のためのシステムおよび方法を開示している。このシステムにおいても、プロジェクトに割当て可能な人員のデータ（人事情報とスキル情報を含む）があらかじめデータベースに格納されており、入力されたプロジェクトの要件が入力されると、適切な人員の検索が実行される。そして、検索を要求したユーザが検索結果にリストされた候補者をユーザが選択することによって、プロジェクトへの人員の割当が確定する。

特開２００３−４４６４２号公報 特開２００４−１１８６４８号公報

これら従来の人員割当てのシステムは、プロジェクトを管理する者（プロジェクト・マネージャ）によってプロジェクトの要件（例：必要なタスクの種類、各タスクに要求されるスキル、期間等）が入力されたことに応答して、あらかじめ登録された人員データを検索し、検索条件を満たすスキルをもった人員を自動的に割当てる。人員データは、人員割当てシステムによって、あらかじめローカルに保持されるか、他のシステムからレプリカとして定期的に複製される。しかしながら、かかるシステムにおいては、一旦プロジェクトに人員が割当てられた後に、その割当てを動的に見直す機構について十分な考慮がなされていない。例えば、実際にプロジェクトに割当てられた人員が急に休職した場合、従来の技術では、これに柔軟に対応することができない。

プロジェクトの要件そのものが変更された場合には、再度、割当て処理を実行することで、割当て人員の再構成は可能である。しかしながら、割当て処理の後に人員の状況に変更が生じた場合（例えば、割当てられた人員の退職、休職、スキルの変更等）、プロジェクト・マネージャは、通常、その事実を自動的には認識できない。また、仮にプロジェクト・マネージャが人員データの変更に気づいた場合であっても、その人員が割当てられたプロジェクト（または個別のタスク）を探し出し、変更が必要なプロジェクト（または個別のタスク）に関する人員の割当てを再度要求しなければならない。結果として、プロジェクト・マネージャの負担は大きくなり、プロジェクトの進行にも影響を及ぼしうる。

このような問題を避けるため、人員データを変更ができない静的なものとしてしまうことも可能であるが、人員データを管理する者（リソース・マネージャ）の立場からみて、そのようなシステムは柔軟性がなく、現実的ではない。また、プロジェクト・マネージャの立場からしても、最新の人員データにもとづくプロジェクト管理ができないため、きわめて不都合である。

したがって、人員データを管理する人事管理システムとプロジェクト管理データを管理するプロジェクト管理システムとは独立に稼動する一方で、これらのシステムの最新データを充分に利用して、プロジェクト管理の側からも、人事管理の側からも、柔軟かつ動的に対応できる人員割当ての仕組みをもつことが望ましい。

本発明の目的は、プロジェクトに対して人員を割当てた後に、かかる人員の状況に変動が生じた場合であっても、人員データの変更に応じて動的に再度人員を割当てることができる機構を提供することである。
本発明の他の目的は、そのような人員データの変更により必要とされるプロジェクト管理および人員管理の処理負担を軽減することにある。
さらに本発明の他の目的は、人員データの変更が生じた場合でも、迅速にこれをプロジェクト・マネージャまたはリソース・マネージャに認識させ、結果として、適時で効率的なプロジェクト管理を可能にすることである。
また本発明の他の目的は、プロジェクト管理システムと人事管理システムの双方と同期をとりつつ、柔軟にプロジェクトへの人員割当てを行えるシステムを提供することにある。

本発明の人員割当ての手法は、プロジェクトを構成する複数のタスクに関するデータ（タスクデータ）を管理する第１のシステム（プロジェクト管理システム）と、識別データを含む人員に関するデータ（人員データ）を管理する第２のシステム（人事管理システム）に接続されたコンピュータ（人員割当てシステム）において実装される。

すでに人員を割当て済みのタスクに関する情報は、第１のシステム（プロジェクト管理システム）にタスクデータとして保持され、そのタスクデータには、割当てられた人員の少なくとも識別データが関連付けられている。この識別データは、第２のシステム（人事管理システム）に保持されている人員データにも含まれているので、レコード検索のキー情報として用いることができる。

リソース・マネージャまたはその他の担当者（人事担当者、人員本人、そのレポート先の上司等）が、第２のシステム（人事管理システム）において特定の人員データを変更すると、人員割当てシステムがその変更入力を受付ける。人員割当てシステムは、この変更の受付に応答して、変更の対象となる人員に割当てられた関連タスクがあるかどうかを、識別データを検索キーにして第１のシステム（プロジェクト管理システム）のタスクデータを参照することによって判定する。少なくとも１の関連タスクがある場合には、人員割当てシステムが、その関連タスクのタスクデータを取得してイベント・データベース（人員イベント・データベース）に格納する。

イベント・データベースのデータ（イベント・データ）は、リソース・マネージャまたはプロジェクト・マネージャのディスプレイ装置に表示することができる。実施例では、リソース・マネージャによる割当て操作の後、プロジェクト・マネージャがその割当て内容を承認（または拒否）する構成となっている。したがって、まずリソース・マネージャのユーザ端末にのみイベント・データが提示されるが、かかる構成は任意であることに留意されたい。

人員割当てシステムは、表示した前記関連タスクへの代替人員の検索要求を受付けると、この関連タスクに割当て可能な代替候補者を探すため第２のシステム（人事管理システム）を検索し、代替候補者の人員データを取得する。この割当て可能な前記代替候補者のリストも、リソース・マネージャまたはプロジェクト・マネージャのディスプレイ装置に表示される。人員割当てシステムが、このリストからの代替人員の選択を受付けると、この選択された代替人員を上述の関連タスクに割当てて、その人員データを前記イベント・データベースに格納する。プロジェクト・マネージャがこの代替人員の割当てを承認すると、本発明の人員割当てシステムは、割当てられた代替人員の識別データを前記関連タスクのタスクデータと関連付けて第１のシステム（プロジェクト管理システム）に格納する。これによって、プロジェクト管理システムに自動的に再割当てのデータが反映される。

再割当て可能な代替候補者を特定する場合、その候補者にすでに割当てられたタスクが存在するかどうかを確認することは重要である。なぜなら、すでに割当て済みのタスクと実施期間が重複する新規のタスクに、そのような候補者を割当てることは、現実的ではないからである。本発明の人員割当てシステムは、そのような状況を回避するため、代替候補者を見つける際に、第２のシステム（人事管理システム）の人員データのみならず、第１のシステム（プロジェクト管理システム）のタスクデータも検索する。そして、代替候補者のリストには、新規タスクの期間データと前記割当て済みタスクの期間データが重複しない代替候補者のみが含まれることになる。

本発明は、上述のような人員割当てを実行するコンピュータとしても、そのような人員割当ての方法としても、またかかる方法をコンピュータに実行させるプログラムとしても把握することができる。

本発明により、プロジェクトに対して人員を割当てた後に、かかる人員の状況に変動が生じた場合であっても、人員データの変更に応じて動的に再度人員を割当てることができる機構が提供される。この機構により、そのような人員データの変更により必要とされるプロジェクト管理および人員管理の処理負担を軽減することができる。また、人員データの変更が生じた場合でも、プロジェクト・マネージャまたはリソース・マネージャはその事実を迅速に認識することができ、結果として、適時で効率的なプロジェクト管理が可能となる。

本発明は、既存のプロジェクト管理システムと人事管理システムと機能をそのまま維持しつつ、これらのシステムのとは切り分けられた独立のシステムとして構築されるので、各システムの最近のデータと適時に同期をとることで、柔軟かる動的な人員割当てを行うことができる。

以下、特定の実施形態および実施例を用いて本発明を説明するが、かかる実施形態および実施例はあくまで例として示されるものであり、特許請求の範囲にかかる発明を限定することを意図するものではない。

（１）統合システムの全体図
図１は、本発明の人員割当て方法を実施するための統合システム１の構成図である。図１に示されるように、統合システム１は、人員割当てシステム１０、プロジェクト管理システム（ＰＭシステム）２０および人事管理システム（ＲＭシステム）３０で構成される。これらのシステムは、一般的なサーバなどのコンピュータを用いて実装される。本明細書では、プロジェクト・マネージャ（ＰＭ）のユーザ端末４０とリソース・マネージャ（ＲＭ）のユーザ端末５０とが、ネットワーク６０を介して統合システム１に接続されている。しかしながら、物理的には、プロジェクト・マネージャがＰＭシステム２０を、リソース・マネージャがＲＭシステム３０を直接操作するように構成してもよい。

人員割当てシステム１０は、プロジェクトのタスクに人員を割当てる本発明の主要機能を実現するサーバなどのコンピュータであって、ネットワーク６０を介してＰＭシステム２０およびＲＭシステム３０に接続されている。この人員割当てシステム１０は、プロジェクト・マネージャ（ＰＭ）とリソース・マネージャ（ＲＭ）の双方からアクセス可能であるが、アクセスできるデータの範囲は制御されている。人員割当てシステム１０は、具体的には、タスクイベント・データベース（タスクイベントＤＢ）１２、割当て処理モジュール１４、人員イベント・データベース（人員イベントＤＢ）１６および候補者テーブル１８を具備している。これらのより詳細な構成および動作については後述する。

ＰＭシステム２０は、プロジェクトに関する情報を保持し管理するサーバなどのコンピュータであって、主にプロジェクト・マネージャによって使用される。ＰＭシステム２０は、市販されているプロジェクト管理ツールをコンピュータに導入することによって実装することができ、機能的には、プロジェクト管理データベース（ＰＭ−ＤＢ）２２、プロジェクト管理モジュール（ＰＭモジュール）２４およびイベントテーブル２６を含む。
プロジェクト・マネージャは、ユーザ端末４０を介してＰＭシステム２０にアクセスする。ＰＭモジュール２４は、人員の割当てが必要なプロジェクトの要件を入力するための画面を生成し、ユーザ端末４０に表示する。１つのプロジェクトは、通常、複数のタスクで構成されている。例えば、製品の開発プロジェクトの場合、設計、開発、テストなどがタスクの例である。プロジェクト・マネージャは、それぞれのタスクに関して、人数、必要なスキルやそのレベル、実施期間などのプロジェクト要件のデータを入力する。入力されたデータは、ＰＭモジュール２４によってプロジェクト管理データベース２２に格納される。プロジェクト・マネージャが、すべてのプロジェクト要件のデータを入力し、人員の割当てを要求すると、その要求がイベント・データとしてイベント・テーブル２６に書き込まれる。このようなプロジェクトを構成するタスクへの要件を入力して人員の割当てを要求するイベントを、この明細書では「タスク要件イベント」または「タスクイベント」として参照する。「タスク要件イベント」には、タスク内容（要求スキルや期間を含む）の決定および変更、タスクの追加および削除を含む。
本実施の形態では、人員割当てシステム１０は、定期的にこのイベント・テーブル２６をポーリングする。したがって、イベント・テーブル２６への書込みによって、タスク要件イベントが人員割当てシステム１０によって受付けられる。もちろん、タスク要件イベントが発生する度に、要求を人員割当てシステム１０に送信するように構成してもよい。

ＲＭシステム３０は、割当てられる人員に関する情報を保持し管理するサーバなどのコンピュータであって、主にリソース・マネージャによって使用される。ＲＭシステム３０は、市販されている人事管理ツールをコンピュータに導入することによって実装することができ、機能的には、人事管理データベース（ＲＭ−ＤＢ）３２、人事管理モジュール（ＲＭモジュール）３４およびイベントテーブル３６を含む。
リソース・マネージャは、ユーザ端末５０を介してＲＭシステム３０にアクセスする。ＲＭモジュール３４は、リソース・マネージャからの要求に応じて、人事管理データベース３２から必要な人員データを取り出し、画面を生成して、ユーザ端末５０に送信する。リソース・マネージャは、画面上で、人員データの作成、変更、削除などの編集操作を行うことができる。このような人員データの参照や編集は、リソース・マネージャ以外の他の担当者（例えば、人事部門の担当者、各人員本人、その人員がレポートする管理職など）も行うことができる。人員データの編集に応答して、リソース・マネージャが再度の人員の割当てを要求すると、その要求がイベント・データとしてイベント・テーブル３６に書き込まれる。このような人員データの変更に応じて人員の再度の割当てを要件するイベントを、この明細書では「人員要件イベント」または「人員イベント」として参照する。「人員要件イベント」には、人員の決定および変更、人員の削除および追加、人員のスキルおよびステータスの更新を含む。
本実施の形態では、人員割当てシステム１０は、定期的にこのイベント・テーブル３６をポーリングする。したがって、イベント・テーブル３６への書込みによって、人員要件イベントが人員割当てシステム１０によって受付けられる。もちろん、人員要件イベントが発生する度に、要求を人員割当てシステム１０に送信するように構成してもよい。

ユーザ端末４０および５０は、パーソナルコンピュータ、ＰＤＡ（携帯情報端末）、携帯電話などの一般的な情報機器でよい。ユーザ（プロジェクト・マネージャおよびリソース・マネージャを含む）は、ユーザ端末４０および５０から、一般的なウェブ・ブラウザを使用することによって、または専用のクライアント・プログラムを導入することによって、統合システム１にアクセスすることができる。また、ネットワーク６０は、社内ＬＡＮのようなクローズド・ネットワークでも、インターネットのようなオープン・ネットワークでもよい。ただし、セキュリティ上の問題から、認証されたユーザのみがシステムにアクセスできる機構を具備していることが望ましい。

（２）データ構造
統合システム１で使用される各種データの例を図２−５を用いて説明する。これらのデータ構造は、あくまで本実施形態に必要なデータ項目のみを例示するものであって、実際のシステムにはこれ以外のデータ項目も含まれうることにも留意されたい。

図２は、ＰＭシステム２０のプロジェクト管理データベース２２に記憶されるタスクデータの一例を示す図である。本明細書のプロジェクト管理データベース２２には、プロジェクト・レコード２２０、タスク・レコード２４０およびスキル・レコード２６０が格納されている。これらのタスクデータは、プロジェクト要件を指定するプロジェクト・マネージャによって主として入力される。

プロジェクト・レコード２２０は、各プロジェクトを特定するために必要な情報を含む。各プロジェクト・レコード２２０は、具体的には次のようなフィールドをもつ。「プロジェクトＩＤ」フィールドは、特定のプロジェクトを識別するための番号を含み、１つのプロジェクトに対して１つの番号が割当てられる。「プロジェクト名」フィールドは、そのプロジェクトの名称を含む。「プロジェクト・ステータス」フィールドは、各プロジェクトの現在の状況を示すデータを有し、例えば、「ＣＲＥＡＴＥ（プロジェクト・データの作成中）」、「ＡＳＳＩＧＮＥＤ（人員割当て済み）」、「ＡＣＴＩＶＥ（プロジェクトの開始および実行中）」、「ＲＥＶＩＥＷ（プロジェクト検証中）」、「ＣＯＭＰＬＥＴＥ（プロジェクト完了）」、「ＡＲＣＨＩＶＥ（データ保存）」などのデータを含む。「プロジェクト開始日」フィールドは、そのプロジェクトを開始した日付のデータである。「プロジェクト終了日」フィールドは、すべてのタスクが完了し、そのプロジェクトが終了した日付のデータである。

タスク・レコード２４０は、各タスクを特定するために必要な情報を含む。すでに説明したように、１つのプロジェクトは複数のタスクから構成されるので、プロジェクト・レコード２２０とタスク・レコード２４０は「１：Ｎ」の関係を有する。各タスク・レコード２４０は、具体的には次のようなデータ・フィールドをもつ。「タスクＩＤ」フィールドは、特定のタスクを識別するための番号を含み、１つのタスクに対して１つの番号が割当てられる。「タスク名」フィールドは、そのタスクの名称を含む。「タスク・ステータス」フィールドは、各タスクの現在の状況を示すデータを有し、例えば、「ＣＲＥＡＴＥ（タスク・データの作成中）」、「ＡＳＳＩＧＮＥＤ（人員割当て済み）」、「ＡＣＴＩＶＥ（タスクの開始および実行中）」、「ＲＥＶＩＥＷ（タスク検証中）」、「ＣＯＭＰＬＥＴＥ（タスク完了）」などのデータを含む。「担当」フィールドは、そのタスクに割当てられた人員を特定するためのデータを含む。「タスク開始日」フィールドは、そのタスクを開始した日付のデータである。「タスク終了日」フィールドは、そのタスクを終了した日付のデータである。「プロジェクトＩＤ」フィールドは、対応するプロジェクトの識別番号を有する。このデータが外部キーとなって、タスク・レコード２４０は、対応するプロジェクト・レコード２２０と関連付けられる。

スキル・レコード２６０は、タスクを実行するために要求されるスキルに関する情報を含む。１つのタスクを実行するためには複数のスキルが必要となる場合があるので、タスク・レコード２４０とスキル・レコード２６０は「１：Ｎ」の関係を有する。スキル・レコード２６０は、具体的には次のようなデータ・フィールドをもつ。「スキルＩＤ」フィールドは、特定のスキルを識別するための番号である。「スキル名」フィールドは、そのスキルの名称をあらわし、プロジェクト・マネージャ（役割）、デザイナ（役割）、テスタ（役割）、英語（言語）、ＪＡＶＡ（Ｒ）（プログラミング言語）などのデータを含む。「スキル・レベル」フィールドには、各スキルの相対的な評価が数値として示される。本発明の実施形態では、０から９の範囲で数値を入力することができる。「タスクＩＤ」フィールドは、対応するタスクの識別番号を有する。このデータが外部キーとなって、スキル・レコード２６０は、対応するタスク・レコード２４０と関連付けられる。

図３は、ＲＭシステム３０の人事管理データベース３２に記憶される人員データの一例を示す図である。本明細書の人事管理データベース３２には、人員レコード３２０と人員スキル・レコード３４０が格納されている。これらの人員データは、人員情報を扱うリソース・マネージャや人事担当者、その人員本人、その人員がレポートする上司などによって入力することが可能である。

人員レコード３２０は、ＲＭシステム３０が管理する人員を特定するために必要な情報を含む。「人員ＩＤ」フィールドは、個々の人員を識別するための番号である。「名前」フィールドは、その人員の氏名を含む。「人員ステータス」フィールドは、各人員の現在の状況を示すデータを有し、例えば、「ＡＶＡＩＬＡＢＬＥ（通常）」、「ＶＡＣＡＴＩＯＮ（休暇）」、「ＬＥＡＶＥ（休職）」などのデータを含む。本実施の形態において、ＲＭシステム３０は、人員割当てに特化したシステムではない。したがって、「ＡＳＩＧＮＥＤ（割当て済み）」のような特別のステータスは用意されていないが、そのような人員割当てに固有のステータス・データをもつようにしてもよい。「開始日」フィールドは、「人員ステータス」フィールドのデータの有効期間（継続期間）の開始日を、「終了日」フィールドは、「人員ステータス」フィールドのデータの有効期間（継続期間）の終了日をそれぞれあらわしている。

人員スキル・レコード３４０は、その人員がもつスキルの情報を含み、上述のスキル・レコード２６０に類似のデータ構造を有する。一人の人員が複数のスキルをもつ場合があるので、人員レコード３２０と人員スキル・レコード３４０は「１：Ｎ」の関係を有する。人員スキル・レコード３４０は、具体的には次のようなデータ・フィールドをもつ。「スキルＩＤ」フィールドは、特定のスキルを識別するための番号である。「スキル名」フィールドは、そのスキルの名称をあらわし、例えば、プロジェクト・マネージャ（役割）、デザイナ（役割）、テスタ（役割）、英語（言語）、ＪＡＶＡ（Ｒ）（プログラミング言語）などのデータを含む。「スキル・レベル」フィールドには、各スキルの相対的な評価が数値として示される。本発明の実施形態では、０から９の範囲で数値を入力することができる。「開始日」フィールドは、そのスキルがいつから有効になったかを示し、「終了日」フィールドは、そのスキルがいつまで有効かを示す。「人員ＩＤ」フィールドは、そのスキルをもつ人員の識別番号である。このデータが外部キーとなって、人員スキル・レコード３４０は、対応する人員レコード３２０と関連付けられる。

図４は、人員割当てシステム１０のタスクイベント・データベース１２に記憶されるイベントデータの一例を示す図である。

タスク要件イベントデータは、タスク要件レコード１２０の集合としてあわらすことができる。タスク要件レコード１２０は、人員割当てシステム１０がタスク要件イベントを受信したことに応答して各タスクごとに生成され、処理が完了すると、削除されるか、ログデータとして格納される（非アクティブ状態となる）。タスク要件レコード１２０は、どのタスクにどの人員がどのくらいの期間割当てられるかについての情報を保持し、具体的には次のようなデータ・フィールドをもつ。「イベントＩＤ」フィールドのデータは、そのタスク要件イベントを識別するための番号である。「プロジェクトＩＤ」フィールドおよび「タスクＩＤ」フィールドは、それぞれ関連するプロジェクトおよび関連するタスクを識別するための番号を含む。この「プロジェクトＩＤ」のデータは外部キーとなって、タスク要件レコード１２０をプロジェクト管理データベース２２のプロジェクト・レコード２２０と関連付ける。１つのプロジェクトに対して複数のタスクが存在するので、タスク要件レコード１２０とプロジェクト・レコード２２０は「Ｎ：１」の関係を有する。プロジェクト・レコード２２０についてはすでに説明したので、ここでは詳細に触れない。
「人員ＩＤ」フィールドは、そのタスクに割当てられた人員を識別するための番号を有する。「要件ステータス」フィールドは、各タスクの現在の状況を示すデータを有し、例えば、「ＲＥＱＵＥＳＴＥＤ（依頼受付済み）」、「ＡＳＳＩＧＮＥＤ（人員割当て済み）」、「ＮＯＴＡＳＳＩＧＮＥＤ（人員未確定）」、「ＮＯＴＡＶＡＩＬＡＢＬＥ（人員割当て不可）」、「ＡＰＰＲＯＶＥＤ（承認）」、「ＲＥＪＥＣＴＥＤ（再割当て請求）」などのデータを含む。「タスク開始日」フィールドは、そのタスクが開始される日付のデータを、「タスク終了日」フィールドは、そのタスクが終了する日付のデータを有する。「オーナー」フィールドは、タスク要件レコード１２０にアクセスできるユーザを示す。本実施の形態では、プロジェクト・マネージャまたはリソース・マネージャが主たるユーザであるので、その種別または人物の識別情報が書き込まれる（例えば、対応するデータ・ビットの０と１を切り替える）。すなわち、この「オーナー」フィールドを書き換えることで、ユーザのアクセスを制限することができる。

図５は、人員割当てシステム１０の人員イベント・データベース１６に記憶されるイベントデータの一例を示す図である。

人事要件イベントデータは、人員要件レコード１６０の集合としてあらわすことができる。それぞれの人員要件レコード１６０はイベントの発生時に生成され、処理が完了すると、削除されるか、ログデータとして格納される（非アクティブ状態となる）。人員要件レコード１６０は、すでにプロジェクト（具体的にはタスク）に割当てられている人員のデータに変更が生じたことに応答して、該当する人員が割当てられていた各タスク（該当する人員データの変更により影響が生じるタスク）ごとに生成される。ここで人員データの変更とは、人員の削除、ステータスの変更およびスキルの変更を含む。このような人員データの変更は、リソース・マネージャだけではなく、人事担当者、各人員本人、その人員がレポートする上司などが行うようにすることができる。人員要件レコード１６０は、該当するタスクの識別番号、ステータスや期間についての情報を保持し、具体的には、次のようなデータ・フィールドをもつ。「イベントＩＤ」フィールドのデータは、その人員要件イベントを識別するための番号である。「タスクＩＤ」フィールドは、その人員が割当てられていた関連するタスクを識別するための番号を含む。「人員ＩＤ」フィールドは、人員データが変更された人員を識別するための番号を含む。この「人員ＩＤ」のデータは、外部キーとなって、人員要件レコード１６０を人員管理データベース３２の人員レコード３２０と関連付ける。一人の人員に対して複数のタスクが割当てられている場合があるので、人員要件レコード１６０と人員レコード３２０は「Ｎ：１」の関係を有する。人員レコード３２０についてはすでに説明したので、ここでは詳細に触れない。

「要件ステータス」フィールドは、各人員の現在の状況を示すデータを有し、例えば、「ＲＥＱＵＥＳＴＥＤ（依頼受付済み）、「ＡＳＳＩＧＮＥＤ（人員割当て済み）」、「ＮＯＴＡＳＳＩＧＮＥＤ（人員未確定）」、「ＮＯＴＡＶＡＩＬＡＢＬＥ（人員割当て不可）」、「ＡＰＰＲＯＶＥＤ（承認）」、「ＲＥＪＥＣＴＥＤ（再割当て請求）」などのデータを含む。「開始日」および「終了日」フィールドのデータは、人員要件の有効期間の始点と終点の日付を特定する。「オーナー」フィールドは、人員要件レコード１６０にアクセスできるユーザを示す。本実施の形態では、プロジェクト・マネージャまたはリソース・マネージャが主たるユーザであるので、その種別または人物の識別情報が書き込まれる（例えば、対応するデータ・ビットの０と１を切り替える）。すなわち、この「オーナー」フィールドを書き換えることで、ユーザのアクセスを制限することができる。

（３）人員割当てシステム
図６は、人員割当てシステム１０の機能ブロック図である。以下では、本発明の中核をなす人員割当てシステム１０についてより詳細に説明する。人員割当てシステム１０は、入出力制御手段１１、タスクイベント・データベース（タスクイベントＤＢ）１２、通信制御手段１３、割当て処理モジュール１４、人事イベント・データベース（人事イベントＤＢ）１６および候補者テーブル１８から構成されている。タスクイベントＤＢ１２および人事イベントＤＢ１６については、すでに図５および図６を用いて説明したので、詳細な説明は省略する。

入出力制御手段１１は、キーボードやマウスなどの入力装置、ディスプレイやプリンタなどの出力装置、ＣＤ−ＲＯＭやハードディスク装置などの外部記憶装置その他の入出力装置と割当て処理モジュール１４とのインタフェースである。例えば、プロジェクト・マネージャまたはリソース・マネージャが直接人員割当てシステム１０を操作する場合には、入出力制御手段１１がその入出力を処理する。

通信制御手段１３は、外部ネットワークと割当て処理モジュール１４とのインタフェースである。本実施形態では、通信制御手段１３は、ネットワーク６０を介して、プロジェクト・マネージャのユーザ端末４０またはリソース・マネージャのユーザ端末５０とのデータのやり取りを制御する。

割当て処理モジュール１４は、タスク要件イベントおよび人員要件イベントが発生した場合に、適切な人員を割当てるための一連の処理を実行するプログラムである。物理的には、人員割当てシステム１０のハードディスク装置などの記憶装置に格納されたプログラムを主記憶装置に読込み、これをプロセッサ（ＣＰＵ）が実行することにより各種の機能が実現される。割当て処理モジュール１４は、具体的には、受付手段１１０、タスク判定手段１２０、通知手段１３０、検索手段１４０、表示制御手段１５０および割当て制御手段１６０を具備する。

受付手段１１０は、プロジェクト・マネージャまたはリソース・マネージャからの要求、選択その他の入力を受付ける。具体的には、受付手段１１０は、タスク要件の入力に応答した人員割当て要求（タスク要件イベント）、人員要件の入力に応答した人員データの変更（人員要件イベント）、人員の検索要求、表示されたレコードの編集、選択、確認または拒否、割当ての承認などを受付ける。

タスク判定手段１２０は、人員要件イベントの発生時に、データが変更された人員を特定し、その人員に割当てられたタスクが存在するかどうかを判定する。具体的には、タスク判定手段１２０は、人員ＩＤを検索キーにしてＰＭシステム２０に照会し、プロジェクト管理データベース２２が関連するタスクレコード２４０を有しているかどうかで判断する。

通知手段１３０は、プロジェクト・マネージャまたはリソース・マネージャに、アクションを必要とする何らかのイベントがあることを通知する。具体的には、通知手段１３０は、プロジェクト・マネージャまたはリソース・マネージャが人員割当てシステム１０にアクセスした際に、タスク要件レコード１２０および人員要件レコード１６０の「オーナー」フィールドのデータを参照し、アクセス可能となっているイベント・データがある場合には、そのデータをプロジェクト・マネージャまたはリソース・マネージャに提示する。

検索手段１４０は、検索要求に応答して、ＰＭシステム２０またはＲＭシステム３０にアクセスし、必要な人員またはタスクに関する情報を取得する。例えば、リソース・マネージャからの人員の検索要求に応答して、ＲＭシステム３０の人員管理データベース３２を検索し、タスク要件に合致する候補者の人員データを取り出す。また、検索手段１４０は、人員要件イベントの発生時には、代替候補者の検索要求に応答して、ＰＭシステム２０のプロジェクト管理データベース２２も検索し、必要なタスクデータを取得する。これは、代替候補者としてリストされた人員にすでに割当て済みのタスクがある場合、そのタスクの実施期間中は新たなタスクを割当てることができないため、そのような割当て済みのタスクの情報を取得する必要があるからである。具体的には、上述の検索手段１４０は、検索結果として取得した代替候補者の関連タスクデータに含まれる期間データを調べ、すでに割当てられているこの関連タスクの期間と再割当てされるタスクの期間とが重複しない場合に、その候補者を後述する候補者テーブル１８に維持する。このようにして、割当て可能な人員のみのリストが作成され、そのデータが表示制御手段１５０により表示される。

本実施態様では、ＰＭシステム２０とＲＭシステム３０が、それぞれ独立したシステムとして接続されており、人員割当ての場面では、これらを統合する形で人員割当てシステム１０が稼動する。したがって、ＰＭシステム２０とＲＭシステム３０は、人員割当てシステム１０を意識することなく、最新のデータを保持することができる。その一方で、人員割当てシステム１０は、必要な場合にのみ、必要なデータをＰＭシステム２０またはＲＭシステム３０から取得する。上述のように、リストされた候補者に割当て済みのタスクの期間データも、候補者の検索の終了後に必要に応じて、プロジェクト管理データベース２２から取得される。

候補者テーブル１８は、検索手段１４０による検索の結果取得された割当て可能な人員（候補者）のリストを格納する。このデータは、プロジェクト・マネージャまたはリソース・マネージャに提示され、候補者の選択、確認または拒否を通じて最終的にタスクへの人員の割当て（または再割当て）が承認されるまで保持される。

表示制御手段１５０は、プロジェクト・マネージャのユーザ端末４０またはリソース・マネージャのユーザ端末５０に、発生したイベントの内容、検索の結果（割当て可能な候補者のリスト）、割当て実行の結果などを表示する。この表示内容を作成するために、タスクイベント・データベース１２、人事イベント・データベース１６、候補者テーブル１８、ＰＭデータベース２２およびＲＭデータベース３２からのデータが、必要に応じて参照される。

割当て制御手段１６０は、タスク要件イベントまたは人員要件イベントの受付けに応答して、イベント・レコード（１２０、１６０）を作成し、イベント・データベース（１２、１６）に管理する。また、割当て制御手段１６０は、リソース・マネージャによる入力、選択、確認、プロジェクト・マネージャによる入力、選択、確認、承認などのユーザ操作に応答して、タスクに適切な人員の割当てを実行する。プロジェクト・マネージャにより承認された人員割当ての内容は、最終的には、割当て制御手段１６０により、ＰＭシステム２０のプロジェクト管理データベース２２に書き込まれる。

以下の実施例では、具体例を用いて、人員割当てシステム１０の処理フローが説明される。より詳細には、タスク要件イベントが発生した場合の処理フローを図７を用いて、人員要件イベントが発生した場合の処理フローを図８を用いて説明する。図８に示す処理は、図７に示されるような人員割当て処理が行われた後に実行される点に留意されたい。

（４）タスク要件イベント
図７は、タスク要件イベントが発生した場合の人員割当てシステム１０の処理フローを示す図である。図７とともに図９ないし１２を参照して、この処理フローを説明する。

人員割当てシステム１０においては、まず受付手段１１０が、ＰＭシステム２０からプロジェクトを構成する１または複数のタスクへの人員の割当て要求を受付ける（ステップ７１０）。この割当て要求は、プロジェクト・マネージャがＰＭシステム２０にアクセスし、タスク要件を入力することによって生成される。

図９は、このようなタスク要件を入力するためのＰＭシステム２０の画面イメージの一例を示す図である。ここでは製品ＡＡＡの開発プロジェクトに人員を割当てることが想定されている。このプロジェクトは、「Ｄｅｓｉｇｎ」、「Ｄｅｖｅｌｏｐ」、「Ｄｅｖｅｌｏｐ２」、「Ｔｅｓｔ」の４つのタスクで構成されており、それぞれに必要なスキルの内容とそのレベル、タスクの期間に関するデータを入力することが必要とされる。これらのデータを入力後、例えば「ＡＳＳＩＧＮ」ボタンをクリックすることで割当て要求が生成され、これがイベント・テーブル２６に書き込まれる。人員割当てシステム１０（受付手段１１０）は、このイベント・テーブル２６を定期的にポーリングしており、その結果、割当て要求が人員割当てシステム１０により受付けられる。割当て制御手段１６０は、割当て要求の受付に応答して、各タスクごとにタスク要件イベント・レコード１２０を作成する。必要なデータはプロジェクト管理データベース２２から取得する。このとき「オーナー」フィールドは、リソース・マネージャにアクセス許可するようにデータが書き込まれる。リソース・マネージャが人員割当てシステム１０にアクセスすると、このイベントの存在が通知手段１３０によって通知される（ステップ７１５）。

図１０は、リソース・マネージャが人員割当てシステム１０にアクセスしたときの画面イメージの一例を示す図である。この画面は、２つのタスク要件イベント（ＥＶＴ０００１とＥＶＴ０００２）があることを示している。リソース・マネージャが「ＥＶＴ０００１」の「選択」ボタンをクリックすることにより、対応するタスク要件の詳細に関するテーブルが表示される。ここでは４つのタスク要件が存在していることが示されている。リソース・マネージャが、特定のタスク（デベロッパーのスキル：７）の「検索」ボタンをクリックすると、受付手段１１０が、割当て可能な人員の検索要求を受付ける（ステップ７２０）。

検索手段１４０は、検索要求に応答して、ＲＭシステム３０を検索し、人員管理データベース３２から検索条件に適合する人員のデータを取得する（ステップ７２５）。具体的には、検索手段１４０は、検索条件に含まれるスキルの内容、スキルのレベルおよびタスクの期間に関するデータと、人員スキル・レコード３４０とを比較し、条件に適合する人員またはこれに近い人員を特定する。条件が完全一致しない場合にどこまでを「割当て可能」な人員として特定するかは任意である。さらに、人員レコード３２０の「ステータス」データも確認した後、割当て可能な人員のＩＤ、名前、スキルなどの人員データを取得する。割当て可能な人員が複数いる場合には、複数の人員データをリストとして取得する。

表示制御手段１５０は、取得した割当て可能な人員のデータをテーブルとして画面に表示する（ステップ７３０）。図１０を参照すると、検索結果の例が示されている。ここでは、３名の人員が候補者として示されている。リソース・マネージャは、「選択」欄にチェック・マークをいれることで、割当てたい人員をリストから選択することができる。この場合、複数の人員を割当て候補として選択することも可能である。ここでは、要求スキルのレベルが「７」であるので、それ以上のスキルを有する「加藤」を選択することがもっとも適切である。特定の人員（例えば「加藤」）を選択した後にリソース・マネージャが「確定」ボタンをクリックすることによって、人員割当てシステム１０の受付手段１１０は割当て候補者の選択を受付ける（ステップ７３５）。人員選択の確定に応答して、図１０のタスク要件の詳細テーブルにおける「Ｓｔａｔｕｓ」のデータが「ＮｏｔＡｓｓｉｇｎｅｄ」から「Ａｓｓｉｇｎｅｄ」に変更される。「山崎」が割当てられた「デザイナー」のタスク・レコードを参照されたい。

人員を割当てるべきタスクが他にも残っている場合（ステップ７４０のＮｏ）、割当て制御手段１６０は、リソース・マネージャからのさらなる検索要求を待つ（人員割当てシステム１０が待機する）。リソース・マネージャがすべてのタスクに人員を割当てて、画面下の「完了」ボタンをクリックした場合（ステップ７４０のＹｅｓ）、通知手段１１０が、プロジェクトまたはタスクへの人員の割当てが完了したことをプロジェクト・マネージャに通知する（ステップ７４５）。

図１１は、プロジェクト・マネージャが人員割当てシステム１０にアクセスしたときの画面イメージの一例を示す図である。図からも分かるように、画面の構成は図１０に近似している。例えば、特定のタスクを選択することによって、タスク要件の詳細テーブルが表示される点は同じである。大きく異なるのは、この画面ではすでに割当て候補者の検索（と暫定的な割当て）が完了している点である。そのためプロジェクト・マネージャは、検索要求を実行することを求められていない。例えば、詳細テーブルの１番左のコラムには、「検索」ではなく「確認」のボタンが用意されている。プロジェクト・マネージャがこの「確認」ボタンをクリックすると、対応するタスクに割当てられた人員のリストが表示される。複数のタスクがリストに存在する場合（ステップ７５０のＹｅｓ）、プロジェクト・マネージャは、すべてのタスクの人員割当てを確認し確定させる必要がある（ステップ７６０のＮｏ）。
割当て候補者が複数存在する場合、プロジェクト・マネージャは、割当て済みの人員の選択を変更したり、追加したりすることができる。そのためには、検索結果の「選択」欄のチェックマークを付加または削除したのち、「確定」ボタンをクリックする。候補者が一人だけの場合は、プロジェクト・マネージャは単に「確定」ボタンをクリックする。これにより、人員割当てシステム１０の受付手段１１０が人員の選択を受付ける（ステップ７５５）。人員選択の確定に応答して、図１１の詳細テーブルにおける「Ｓｔａｔｕｓ」のデータが「Ａｓｓｉｇｎｅｄ」から「Ａｐｐｒｏｖｅｄ」に変更される。これについても「山崎」が割当てられた「デザイナー」のタスク・レコードを参照されたい。
プロジェクト・マネージャが割当てられた人員を拒否する場合、検索結果のテーブルで「拒否」のボタンをクリックする。この場合、詳細テーブルの「Ｓｔａｔｕｓ」は変更されず、画面下の「承認」ボタンをクリックすることはできなくなる。

すべてのタスクに対する割当てが確定するか（ステップ７６０のＹｅｓ）、そもそもタスクが１つだけ存在する場合（ステップ７５０のＮｏ）、プロジェクト・マネージャは割当てられた人員を承認するか否かの判断を求められる（ステップ７６５）。承認する場合、プロジェクト・マネージャは図１１の画面下の「承認」ボタンをクリックする（ステップ７６５のＹｅｓ）。人員割当てシステム１０においては、割当て制御手段１６０が、その承認済みの人員のデータを、ＰＭシステム２０のプロジェクト管理データベース２２に自動的に反映し（ステップ７７０）、処理は終了する。承認しない場合、プロジェクト・マネージャは図１１の画面下の「再通知」ボタンをクリックする（ステップ７６５のＮｏ）。これにより、通知手段１１０は、再度リソース・マネージャにイベントを通知する。人員割当てシステム１０は、ステップ７１５から処理を再開する。上述のように、プロジェクト・マネージャが１つのタスクでも人員割当てを拒否した場合には、「承認」ボタンをクリックできないようになっている。そのため、この場合も「再通知」ボタンが押されて、同様の処理が実行される。

図１２は、人員割当て承認後のＰＭシステム２０の画面イメージの一例を示す図である。図９と比較すれば理解されるように、「Ｓｔａｔｕｓ」データが、「ＮｏｔＡｓｓｉｇｎｅｄ」から「Ａｓｓｉｇｎｅｄ」に更新され、「Ａｓｓｉｇｎ」欄に割当てられた人員の名前が表示されている。

（５）人事要件イベント
図８は、人事要件イベントが発生した場合の人員割当てシステム１０の処理フローを示す図である。図８とともに図１３ないし図１６を参照して、この処理フローを説明する。なお、図１３ないし図１６は、理解を容易にするため、図１２に示される人員割当ての承認後に遷移する画面の例として示される。

人員割当てシステム１０においては、まず受付手段１１０が、ＲＭシステム３０から人員データの変更要求を受付ける（ステップ８１０）。この変更要求は、典型的には、リソース・マネージャがＲＭシステム３０にアクセスし、人員要件の内容（更新内容）を入力することによって生成される。ここで人員データの変更とは、人員の追加および削除、スキルやステータスに関するデータの追加、変更および削除を含む。このような人員データの変更は、リソース・マネージャのみならず他の担当者（例えば、人事部門の担当者、各人員本人、およびその人員がレポートする管理職など）によっても行うことができる。

図１３は、このような人員要件を入力するためのＲＭシステム３０の画面イメージの一例を示す図である。この例では６名の人員のデータが示されている。本実施例では、図１３で強調表示されているように、（１）「山崎」のスキルとして「デベロッパー」（レベル４）を追加し、（２）「山田」のステータスを「通常」から長期間の「休職」に変更するシナリオを用いて本発明の処理フローを説明する。リソース・マネージャその他のデータ編集者は、画面の編集モードで（１）および（２）の人員要件を入力する。その後、画面下の「更新」ボタンをクリックすることによって、人員データの変更依頼がイベントデータとしてイベントテーブル３６に書き込まれる。人員割当てシステム１０（受付手段１１０）は、このイベント・テーブル３６を定期的にポーリングしており、その結果、変更要求が人員割当てシステム１０により受付けられる。

人員割当てシステム１０の処理フローに戻る。人員データの変更要求の受付に応答して、タスク判定手段１２０は、変更の対象になっている人員にすでに割当てられているタスクであって、そのデータの変更により影響が及ぶタスクが存在するかどうかを判定する（ステップ８１２）。タスク判定手段１２０は、人員ＩＤデータをキーにして、ＰＭシステム２０のプロジェクト管理データベース２２に関連するタスク・データが存在するかどうかを確認する。その結果、割当てられたタスクが存在しない場合および割当てられたタスクが存在するが人員データ変更の影響を受けないタスクのみが存在する場合、人員割当てシステム１０は処理を終了する（ステップ８１２のＮ０）。後者の変更を受けないタスクのみが存在する場合とは、スキルの追加や変更やスキル・レベルの変更があったが割当て済みのタスクの要件は満たしている場合（例えば、新規スキルが追加されただけで、割当て済みのタスクで必要なスキルは依然保持している場合）、ステータスの変更があったが割当て済みのタスクの実行期間と重複しない場合（例えば、２００４年８月１０日から１４日まで「休暇」のステータスに変更されたが、タスクの開始日が２００４年９月１日である場合）を含む。したがって、上記（１）の場合は、関連するタスクが存在しないこととなるが（ステップ８１２のＮｏ）、上記（２）の場合は、関連するタスクが存在することとなる（ステップ８１２のＹｅｓ）。

関連するタスクが存在する場合、割当て制御手段１６０が、各タスクごとに人員要件イベント・レコード１６０を作成する。必要なデータはプロジェクト管理データベース２２および人員管理データベース３２から取得する。このとき「オーナー」フィールドは、リソース・マネージャにアクセス許可するようにデータが書き込まれる。リソース・マネージャが人員割当てシステム１０にアクセスすると、このイベントの存在が通知手段１３０によって通知される（ステップ８１５）。表示制御手段１５０は、該当する人員に割当てられたタスクの情報を表示する。リソース・マネージャのユーザ端末５０に表示する。

図１４は、リソース・マネージャが人員割当てシステム１０にアクセスしたときの画面イメージの一例を示す図である。この画面は、１つのイベント（ＥＶＴ９００１）があることを示している。リソース・マネージャが「ＥＶＴ９００１」の「選択」ボタンをクリックすることにより、対応する人員要件の詳細に関するテーブルが表示される。ここでは１つの人員要件が存在していることが示されている。リソース・マネージャが、特定のタスク（デベロッパーのスキル：３）の「検索」ボタンをクリックすると、受付手段１１０が、割当て可能な代替人員の検索要求を受付ける（ステップ８２０）。

検索手段１４０は、検索要求に応答して、ＲＭシステム３０を検索し、人員管理データベース３２から検索条件に適合する代替人員（候補者）のデータを取得する（ステップ８２５）。具体的には、検索手段１４０は、検索条件に含まれるスキルの内容、スキルのレベルおよびタスクの期間に関するデータと、人員スキル・レコード３４０とを比較し、条件に適合する代替候補者またはこれに近い代替候補者を特定する。条件が完全一致しない場合にどこまでを「割当て可能」な代替候補者として特定するかは任意である。さらに、人員レコード３２０の「ステータス」データも確認した後、割当て可能な代替候補者のＩＤ、名前、スキルなどの人員データを取得する。割当て可能な代替候補者が複数いる場合には、複数の人員データをリストとして取得する。

検索手段１４０は、さらに代替候補者のＩＤをキーにしてＰＭシステム２０も検索し、その代替候補者に割当て済みのタスクに関するデータ（特に、期間データ）もプロジェクト管理データベース２２から取得する（ステップ８２８）。このようなデータが必要なのは、代替候補者にすでに割当てられているタスクの実施期間と新規に割当てたいタスクの実施期間が重なる場合、かかる代替候補者にタスクを割当てるのは現実的ではないからである。その判断のために、検索手段１４０は、ＲＭシステム３０のみならずＰＭシステム２０も検索する。

表示制御手段１５０は、割当て可能な代替候補者のデータをテーブルとして画面に表示する（ステップ８３０）。図１４を参照すると、検索結果の例が示されている。ここでは、２名の人員が候補者として示されている。このうち、「山崎」は、上記の（１）でスキルが追加された人員であり、すでにタスク要件イベントで「デザイナー」としてタスクに割当て済みであるが（例えば図１２参照）、期間が重複しないため割当て可能な候補者としてリストされている。リソース・マネージャは、「選択」欄にチェック・マークをいれることで、割当てたい人員をリストから選択することができる。この場合、複数の人員を割当て候補として選択することも可能である。ここでは、要求スキルのレベルが「３」であるので、それ以上のスキルを有する「山崎」を選択することがもっとも適切である。特定の人員（例えば「山崎」）を選択した後にリソース・マネージャが「確定」ボタンをクリックすることによって、人員割当てシステム１０の受付手段１１０は割当て候補者の選択を受付ける（ステップ８３５）。人員選択の確定に応答して、図１４の人員要件の詳細テーブルにおける「Ｓｔａｔｕｓ」のデータが「ＮｏｔＡｓｓｉｇｎｅｄ」から「Ａｓｓｉｇｎｅｄ」に変更される。

人員を割当てるべきタスクが他にも残っている場合（ステップ８４０のＮｏ）、割当て制御手段１６０は、リソース・マネージャからのさらなる検索要求を待つ（人員割当てシステム１０が待機する）。リソース・マネージャがすべてのタスクに人員を割当てて、画面下の「完了」ボタンをクリックした場合（ステップ８４０のＹｅｓ）、通知手段１１０が、プロジェクトまたはタスクへの人員の割当てが完了したことをプロジェクト・マネージャに通知する（ステップ８４５）。

図１５は、プロジェクト・マネージャが人員割当てシステム１０にアクセスしたときの画面イメージの一例を示す図である。図からも分かるように、画面の構成は図１４に近似している。例えば、特定の人事要件を選択することによって、詳細テーブルが表示される点は同じである。異なるのは、この画面ではすでに割当て候補者の検索（と暫定的な割当て）が完了している点である。そのためプロジェクト・マネージャは、検索要求を実行することを求められていない。例えば、詳細テーブルの１番左のコラムには、「検索」ではなく「確認」のボタンが用意されている。プロジェクト・マネージャがこの「確認」ボタンをクリックすると、対応する割当て候補者のリストが表示される。複数のタスク（人員要件）がリストに存在する場合（ステップ８５０のＹｅｓ）、プロジェクト・マネージャは、すべてのタスク（人員要件）の人員割当てを確認し確定させる必要がある（ステップ８６０のＮｏ）。
割当て候補者が複数存在する場合、プロジェクト・マネージャは、割当て済みの人員の選択を変更したり、追加したりすることができる。そのためには、検索結果の「選択」欄のチェックマークを付加または削除したのち、「確定」ボタンをクリックする。候補者が一人だけの場合は、プロジェクト・マネージャは単に「確定」ボタンをクリックする。これにより、人員割当てシステム１０の受付手段１１０が人員の選択を受付ける（ステップ８５５）。人員選択の確定に応答して、図１５の詳細テーブルにおける「Ｓｔａｔｕｓ」のデータが「Ａｓｓｉｇｎｅｄ」から「Ａｐｐｒｏｖｅｄ」に変更される。
プロジェクト・マネージャが割当てられた人員を拒否する場合、検索結果のテーブルで「拒否」のボタンをクリックする。この場合、画面下の「承認」ボタンをクリックすることはできなくなる。

すべてのタスク（人員要件）に対する割当てが確定するか（ステップ８６０のＹｅｓ）、そもそもタスク（人員要件）が１つだけ存在する場合（ステップ８５０のＮｏ）、プロジェクト・マネージャは割当てられた人員を承認するか否かの判断を求められる（ステップ８６５）。承認する場合、プロジェクト・マネージャは図１５の画面下の「承認」ボタンをクリックする（ステップ８６５のＹｅｓ）。人員割当てシステム１０においては、割当て制御手段１６０が、その承認済みの人員のデータを、ＰＭシステム２０のプロジェクト管理データベース２２に自動的に反映する（ステップ８７０）。承認しない場合、プロジェクト・マネージャは図１５の画面下の「再通知」ボタンをクリックする（ステップ８６５のＮｏ）。これにより、通知手段１１０は、再度リソース・マネージャにイベントを通知する。人員割当てシステム１０は、ステップ８１５から処理を再開する。上述のように、プロジェクト・マネージャが１つのタスク（人員要件）でも人員割当てを拒否した場合には、「承認」ボタンをクリックできないようになっている。そのため、この場合にも「再通知」ボタンが押されて、同様の処理が実行される。

図１６は、人員割当て承認後のＰＭシステム２０の画面イメージの一例を示す図である。強調表示されているように、図１２と比較すると、「Ｄｅｖｅｌｏｐ２」のタスクの担当者が「山田」から「山崎」に更新されて「Ａｓｓｉｇｎ」欄に表示されていることがわかる。

まとめると、本発明は、プロジェクトを構成する複数のタスクに関するデータ（タスクデータ）を管理するプロジェクト管理システムと、人員に関するデータ（人員データ）を管理する人事管理システムに接続される人員割当てシステムとして実装される。すでに人員を割当て済みのタスクに関する情報は、プロジェクト管理システムにタスクデータとして保持されており、そのタスクデータには、割当てられた人員の少なくとも識別データが関連付けられている。この識別データは、人事管理システムに保持されている人員データにも含まれているので、レコード検索のキー情報として用いることができる。したがって、本発明の人員割当てシステムは、人員データに変更が生じても、この識別データから関連する割当て済みタスクを自動的に抽出することができ、そこから再度自動的に代替人員の再割当て処理を行うことができる。

（６）その他の実施例
上記の実施例では、タスクに人員を割当てる場合、まずはリソース・マネージャによる予備的な人員の検索と選択（暫定的な割当て）を行い、その後にプロジェクト・マネージャがこの内容を承認することによって、はじめて割当て内容が確定する。しかしながら、人員の検索と選択を直接プロジェクト・マネージャに実行させるように構成してもよい。この場合、図７のステップ７１５および図８のステップ８１５では、イベントがプロジェクト・マネージャに通知され、以降の操作をプロジェクト・マネージャが実行することになる。そして、連結点Ａ（図７）およびＢ（図８）以降の処理フローは、それぞれ図７のブロック７６５および図８のブロック８６５につながることになる。

また、上記の実施例では、複数の割当て候補者が存在する場合には、プロジェクト・マネージャにもすべての候補者を提示して人員を変更することが可能である。しかしながら、リソース・マネージャによる選択を固定のものとして、プロジェクト・マネージャには他の候補者を選択させないように構成することも可能である。

また、実施例では、プロジェクト・マネージャのユーザ端末４０とリソース・マネージャのユーザ端末５０とがネットワーク６０を介して人員割当てシステム１０に接続される構成となっている。しかしながら、プロジェクト・マネージャまたはリソース・マネージャが直接人員割当てシステム１０を操作する構成としてもよい。

本発明の人員割当て方法に適合する統合システム１の構成図である。 プロジェクト管理データベース２２に記憶されるタスクデータの一例を示す図である。 人員管理データベース３２に記憶される人員データの一例を示す図である。 タスクイベント・データベース１２に記憶されるイベントデータの一例を示す図である。 人員イベント・データベース１６に記憶されるイベントデータの一例を示す図である。 人員割当てシステム１０の機能ブロック図である。 タスク要件イベントが発生した場合の人員割当てシステム１０の処理フローを示す図である。 人事要件イベントが発生した場合の人員割当てシステム１０の処理フローを示す図である。 タスク要件を入力するためのプロジェクト管理システム２０の画面イメージの例を示す図である。 リソース・マネージャが人員割当てシステム１０にアクセスしたときの画面イメージの例を示す図である。 プロジェクト・マネージャが人員割当てシステム１０にアクセスしたときの画面イメージの例を示す図である。 人員割当て承認後のプロジェクト管理システム２０の画面イメージの例を示す図である。 人員要件を入力するための人員管理システム３０の画面イメージの例を示す図である。 リソース・マネージャが人員割当てシステム１０にアクセスしたときの画面イメージの例を示す図である。 プロジェクト・マネージャが人員割当てシステム１０にアクセスしたときの画面イメージの例を示す図である。 人員割当て承認後のプロジェクト管理システム２０の画面イメージの例を示す図である。

符号の説明

１．．．統合システム、１０．．．人員割当てシステム、２０．．．プロジェクト管理システム、３０．．．人事管理システム、４０．．．ユーザ端末（プロジェクト・マネージャ）、５０．．．ユーザ端末（リソース・マネージャ）

Claims (20)

1. プロジェクトを構成する複数のタスクに関するデータ（タスクデータ）を管理するための第１のシステムと、識別データを含む人員に関するデータ（人員データ）を管理するための第２のシステムに接続されたコンピュータにおいて、当該タスクに人員を割当てる方法であって、
   前記コンピュータが、第１のシステムからの少なくとも１のタスクへの人員の割当て要求に応答して、第２のシステムを検索し、当該少なくとも１のタスクの要件を満たす少なくとも１の人員を第２のシステムを検索することによって割当て、割当てられた少なくとも１の人員の識別データを前記タスクデータと関連付けて前記第１のシステムに格納するステップと、
   前記コンピュータが、第２のシステムから特定の人員の人員データの変更を受付けるステップと、
   前記コンピュータが、前記変更の受付けに応答して、前記特定の人員に割当てられた少なくとも１の関連タスクがあるかどうかを、当該特定の人員の識別データをキーにして前記第１のシステムのタスクデータを参照することにより判定するステップと、
   前記少なくとも１の関連タスクがある場合には、前記コンピュータが、当該関連タスクのタスクデータを取得してイベント・データベースに格納し、ディスプレイ装置に表示するステップと、
   前記コンピュータが、前記関連タスクへの代替人員の検索要求を受付けるステップと、
   前記コンピュータが、前記代替人員の検索要求に応答して、前記関連タスクに割当て可能な代替候補者を探すため第２のシステムを検索し、当該代替候補者の人員データを取得するステップと、
   前記コンピュータが、割当て可能な前記代替候補者のリストを前記ディスプレイ装置に表示するステップと、
   前記コンピュータが、前記リストからの代替人員の選択を受付けるステップと、
   前記コンピュータが、前記代替人員の選択に応答して、選択された代替人員を前記関連タスクに割当て、当該代替人員の人員データを前記イベント・データベースに格納するステップと、
   を備える人員割当てのための方法。
2. 前記タスクデータがタスクの実施期間に関するデータ（期間データ）を含む、請求項１に記載の方法。
3. 前記コンピュータが、前記代替候補者の人員データを取得するステップの後、当該代替候補者に割当てられた少なくとも１の割当て済みタスクがあるかどうかを、当該代替候補者の識別データをキーにして前記第１のシステムのタスクデータを参照することにより判断し、当該割当て済みタスクがある場合には、その割当て済みタスクのタスクデータを取得するステップをさらに含み、
   前記割当て可能な代替候補者のリストには、前記関連タスクの期間データと前記割当て済みタスクの期間データが重複しない代替候補者のみが含まれる、
   請求項２に記載の方法。
4. 前記コンピュータが、プロジェクト・マネージャが前記代替人員の割当てを承認したことに応答して、当該代替人員の識別データを前記関連タスクのタスクデータと関連付けて前記第１のシステムに格納するステップをさらに含む、請求項１に記載の方法。
5. 前記ディスプレイ装置が、リソース・マネージャが使用する第１のユーザ端末のディスプレイである、請求項１に記載の方法。
6. 前記コンピュータが、前記関連タスクに前記代替人員が割当てられたことをプロジェクト・マネージャに通知し、当該プロジェクト・マネージャが使用する第２のユーザ端末に前記イベント・データベースに含まれるデータを表示するステップをさらに含む、請求項５に記載の方法。
7. 前記コンピュータが、前記代替人員の割当てを前記プロジェクト・マネージャが承認したことに応答して、当該代替人員の識別データを前記関連タスクのタスクデータと関連付けて前記第１のシステムに格納するステップをさらに含む、請求項６に記載の方法。
8. 前記ディスプレイ装置がプロジェクト・マネージャのユーザ端末のディスプレイである、請求項１に記載の方法。
9. プロジェクトを構成する複数のタスクに関するデータ（タスクデータ）を管理するための第１のシステムと、識別データを含む人員に関するデータ（人員データ）を管理するための第２のシステムに接続されたコンピュータに、当該タスクに人員を割当てるための手順を実行させるためのプログラムであって、当該手順が、
   第１のシステムからの少なくとも１のタスクへの人員の割当て要求に応答して、第２のシステムを検索し、当該少なくとも１のタスクの要件を満たす少なくとも１の人員を第２のシステムを検索することによって割当て、割当てられた少なくとも１の人員の識別データを前記タスクデータと関連付けて前記第１のシステムに格納するステップと、
   第２のシステムから特定の人員の人員データの変更を受付けるステップと、
   前記変更の受付けに応答して、前記特定の人員に割当てられた少なくとも１の関連タスクがあるかどうかを、当該特定の人員の識別データをキーにして前記第１のシステムのタスクデータを参照することにより判定するステップと、
   前記少なくとも１の関連タスクがある場合には、当該関連タスクのタスクデータを取得してイベント・データベースに格納し、ディスプレイ装置に表示するステップと、
   前記関連タスクへの代替人員の検索要求を受付けるステップと、
   前記代替人員の検索要求に応答して、前記関連タスクに割当て可能な代替候補者を探すため第２のシステムを検索し、当該代替候補者の人員データを取得するステップと、
   割当て可能な前記代替候補者のリストを前記ディスプレイ装置に表示するステップと、
   前記リストからの代替人員の選択を受付けるステップと、
   前記代替人員の選択に応答して、選択された代替人員を前記関連タスクに割当て、当該代替人員の人員データを前記イベント・データベースに格納するステップと、
   を含む、人員割当てのためのプログラム。
10. 前記タスクデータがタスクの実施期間に関するデータ（期間データ）を含む、請求項９に記載のプログラム。
11. 前記手順が、前記代替候補者の人員データを取得するステップの後、当該代替候補者に割当てられた少なくとも１の割当て済みタスクがあるかどうかを、当該代替候補者の識別データをキーにして前記第１のシステムのタスクデータを参照することにより判断し、当該割当て済みタスクがある場合には、その割当て済みタスクのタスクデータを取得するステップをさらに含み、
    前記割当て可能な代替候補者のリストには、前記関連タスクの期間データと前記割当て済みタスクの期間データが重複しない代替候補者のみが含まれる、
    請求項１０に記載のプログラム。
12. 前記手順が、プロジェクト・マネージャが前記代替人員の割当てを承認したことに応答して、当該代替人員の識別データを前記関連タスクのタスクデータと関連付けて前記第１のシステムに格納するステップをさらに含む、請求項９に記載のプログラム。
13. 前記ディスプレイ装置が、リソース・マネージャが使用する第１のユーザ端末のディスプレイである、請求項９に記載のプログラム。
14. 前記手順が、前記関連タスクに前記代替人員が割当てられたことをプロジェクト・マネージャに通知し、当該プロジェクト・マネージャが使用する第２のユーザ端末に前記イベント・データベースに含まれるデータを表示するステップをさらに含む、請求項１３に記載のプログラム。
15. 前記コンピュータが、前記代替人員の割当てを前記プロジェクト・マネージャが承認したことに応答して、当該代替人員の識別データを前記関連タスクのタスクデータと関連付けて前記第１のシステムに格納するステップをさらに含む、請求項１４に記載のプログラム。
16. 前記ディスプレイ装置がプロジェクト・マネージャのユーザ端末のディスプレイである、請求項９に記載のプログラム。
17. プロジェクトを構成する複数のタスクに関するデータ（タスクデータ）を管理するための第１のシステムと、識別データを含む人員に関するデータ（人員データ）を管理するための第２のシステムとにネットワークを介して接続され、前記タスクに人員を割当てるためのコンピュータであって、前記タスクデータは、すでに対応するタスクに人員割当て済みであればその人員の識別データを含んでおり、
    第１のシステム、第２のシステムまたはその他のユーザ端末からイベント、要求または入力を受付けるための受付手段と、
    前記受付手段が、第２のシステムから特定の人員の人員データを変更する入力を受付けたことに応答して、当該特定の人員に割当てられた少なくとも１の関連タスクがあるかどうかを、当該特定の人員の識別データをキーにして前記第１のシステムのタスクデータを参照することによって判定する判定手段と、
    前記少なくとも１の関連タスクがある場合には、当該関連タスクのタスクデータを取得してイベント・データベースに格納する割当て制御手段と、
    前記イベント・データベースに含まれるデータをディスプレイ装置に表示する表示制御手段と、
    前記受付手段が前記関連タスクへの代替人員の検索要求を受付けたことに応答して、前記関連タスクに割当て可能な代替候補者を探すため第２のシステムを検索し、当該代替候補者の人員データを取得する検索手段と、を具備し、
    前記表示制御手段が、前記ディスプレイ装置に前記代替候補者のリストを表示し、前記受付手段が当該リストからの代替人員の選択を受付けたことに応答して、前記割当て制御手段が、選択された当該代替人員を前記関連タスクに割当て、当該代替人員の人員データを前記イベント・データベースに格納する、
    を備える人員割当てのためのコンピュータ。
18. 前記タスクデータがタスクの実施期間に関するデータ（期間データ）を含み、
    前記検索手段が、前記代替候補者の人員データの取得後、さらに当該代替候補者に割当てられた少なくとも１の割当て済みタスクがあるかどうかを、当該代替候補者の識別データをキーにして前記第１のシステムのタスクデータを参照することにより判断し、当該割当て済みタスクがある場合には、その割当て済みタスクのタスクデータを取得し、
    前記割当て可能な代替候補者のリストは、前記関連タスクの期間データと前記割当て済みタスクの期間データが重複しない代替候補者のみを含む、
    請求項１７に記載のコンピュータ。
19. 前記割当て制御手段は、さらにプロジェクト・マネージャが前記代替人員の割当てを承認したことに応答して、当該代替人員の識別データを前記関連タスクのタスクデータと関連付けて前記第１のシステムに格納する、請求項１７に記載のコンピュータ。
20. 前記ディスプレイ装置が、リソース・マネージャが使用する第１のユーザ端末のディスプレイであって、
    前記表示制御手段は、前記プロジェクト・マネージャが使用する第２のユーザ端末に前記イベント・データベースに含まれるデータを表示する、
    請求項１７に記載のコンピュータ。

Images