Share via


Visual Studio Team Foundation Server と Microsoft Project Server との間で 1 つ以上のフィールドが期待どおりに同期されない場合は、このトピックの内容を確認してください。 影響を受けるフィールドのデータ型、OnConflict フィールドのマッピング属性、タスク階層は、同期エンジンによる特定フィールドの更新方法に影響します。 プロジェクト マネージャーが 1 つ以上の更新の送信を却下したか、プロジェクト計画が発行されなかった場合、タスクは正しく更新されません。 計画が発行されなかった場合、入れ子になった子作業項目は承認キューに配置されません。

このトピックの内容

  • フィールドの更新プロセスの概要

  • 却下された更新の送信

  • タイトルまたはタスク名に対する更新

  • 開始日と完了日に対する更新

  • 時間を格納するフィールドに対する更新

  • タスクの割り当てに対する更新

  • 複数回入れ子になった作業項目のサマリー タスク、タスク階層および送信

  • 選択リストまたはルックアップ テーブルに関連付けられたフィールドの更新

フィールドの更新プロセスの概要

次の図に示すように、データは Project Server から Team Foundation Server、PWA のインスタンス内のステータス キュー、エンタープライズ プロジェクト計画の順に移動し、最後は Project Server に戻されます。 次の表に、同期プロセスに関する追加説明と、プロセスの各ステップにおけるフィールドの更新方法を示します。

重要

作業項目またはタスクを同期に含めるようにスケジュールすると、プロジェクト計画からタスクを削除しない限りは同期から除外することはできません。タスクに割り当てられている [チーム プロジェクトに発行] の値、および Team Foundation の "Project Server に送信" フィールドを変更することはできません。また、Team Foundation Server に発行した後、またはこのソフトウェアから送信された後に、タスクを作業項目の別の種類に変更することはできません。

Updates to Mapped and Mirror Fields

手順

同期プロセス

フィールドの更新

Step 1

Team Foundation の同期: 同期エンジンにより、Project Server に発行された追加と変更が自動検出され、それらの更新が Team Foundation Server にプルされます。

このステップでは、Project Server から Team Foundation Server (targetToTfs マッピング) にマップされたフィールドのみが更新されます。 同期エンジンは常にミラー フィールドを更新しますが、参照フィールドは OnConflict 属性が PSWin に設定された場合にのみ更新します。 ただし、タスクが初めて Project Server に発行された場合は、参照フィールドとミラー フィールドの両方が、OnConflict 属性に割り当てられた値に関係なく設定されます。 ミラー フィールドは読み取り専用です。

既定では、OnConflict 属性は、"残存作業" フィールドおよび "実績作業" フィールドには指定されません。そのため、Team Foundation Server および Project Server 間でマップされたフィールドが異なる場合があります。 詳細については、このトピックで後述する「時間を格納するフィールドに対する更新」を参照してください。

Step 2

ステータス同期: チーム メンバーが、Project Server への送信を設定された作業項目を追加または変更すると、同期エンジンは更新をステータス キューに自動送信します。

ステータス キュー (tfsToTarget マッピング) への送信用にマップされたフィールドのみが送信されます。

開始日と完了日への変更は、作業項目が初めて送信される場合にのみ送信されます。 Team Foundation 内のフィールドは、プロジェクト内のリソース フィールドにマップするため、更新は、"リソースの残存作業時間" や "リソースの残存作業時間" などのリソース フィールドに対して行われます。

Step 3

承認同期: 更新が承認されると、エンタープライズ プロジェクト計画内に更新が表示されます。 承認または却下の通知は、Team Foundation の作業項目の履歴に書き込まれます。

Project Professional 用の Team Foundation アドインにより、pjTask* フィールドおよび pjResource* フィールドの値を正しく同期させることができます。 このため、チーム プロジェクトにマップされているエンタープライズ プロジェクト計画を編集するときは、Visual Studio 2013 またはチーム エクスプローラー 2013 がインストールされているクライアント コンピューターから Project Professional を使用する必要があります。

Step 4

発行同期: プロジェクト マネージャーがプロジェクト計画を発行すると、更新が Project Server に書き込まれます。

プロジェクト計画内のすべてのタスクへの変更が、Project Server で更新されます。

詳細については、次のトピックを参照してください。

却下された更新の送信

プロジェクト マネージャーが必要条件またはタスクへのステータスの更新を却下した場合、対応する作業項目は、却下が解除されるまで同期されなくなります。 却下の理由は "履歴" フィールドに表示され、[Project Server] タブの "最新の承認の状態" フィールドには "却下" と示されます。 作業項目の同期を再開するには、チーム メンバーが却下ステータスに対処する必要があります。

チーム クエリを作成して、更新ステータスが却下された作業項目を検索できます。 詳細については、「作業項目送信の監視および拒否状態の解消」を参照してください。

タイトルまたはタスク名に対する更新

Team Foundation Server の "タイトル" フィールドおよび Project Server のタスク名には、2 つの同期プロセスがあります。 つまり、一方のサーバーでの変更は、常に他方のサーバーで更新されます。 ただし、"タイトル" (System.Title) フィールドのマッピングを変更すると、この動作を変更することができます。

開始日と完了日に対する更新

フィールドをスケジュールすると、一方向の同期プロセスに含められます。 つまり、Team Foundation Server の開始日と完了日のフィールドには、常に Project Server に割り当てられた値が反映され、Team Foundation Server のこれらのフィールドに行った変更は、Project Server に送信されないということです。 この規則が適用されるのは、Project ではスケジュール エンジンを使用して、タスクの開始日と完了日を決定するためです。

既定では、開始日と完了日のフィールドは OnConflict="PSWin" でマップされるため、Team Foundation の日付フィールドは常に Project Server に割り当てられた値を反映します。 マッピング属性を変更して 2 つのブック セットを許可した場合でも、Team Foundation の日付フィールドへの変更は、Project Server に送信されません。ただし、作業項目が初めて送信される場合を除きます。 最初の同期イベントが実行されると、これらのフィールドにはプロジェクト計画に行った更新が反映されます。

時間を格納するフィールドに対する更新

既定では、2 つのブック セットを保持する実績作業時間数と残存時間数のフィールドが同期プロセスに含まれます。 時間の変更は、プロジェクト計画または Team Foundation で発生する可能性があります。 ただし、どちらの場所の情報も変更によって上書きされるとは限りません。 マッピング フィールドに OnConflict 属性が定義されていない場合、この機能が強制されます。

以下に示すシナリオのように、フィールドは、更新を担当するユーザーおよび更新がプロジェクト計画で承認されているかどうかに基づいて更新されます。

  • チーム メンバーが時間を更新し、プロジェクト マネージャーが送信を承認し計画を発行すると、参照フィールドとミラー フィールドの両方が Team Foundation Server の次の更新で反映されます。

  • チーム メンバーが時間を更新し、プロジェクト マネージャーが送信を却下すると、その更新をプロジェクト計画で受け付けることができません。 参照フィールドとミラー フィールドの値に差異が生じます。

  • プロジェクト マネージャーがプロジェクト計画の時間を変更すると、ミラー フィールドのみが、Team Foundation Server の次の同期で更新されます。

2 つのサーバー製品間でタスク時間が異なる場合は、チーム リーダーとプロジェクト マネージャーが差異を調整することになります。 このようにして、各ユーザーは自分の作業を個別に更新しながら、他のユーザーの変更にも目を配ることができます。 値がミラー フィールドに一致しないフィールドを検索する方法の詳細については、「Find Work Items Where the Work in Team Foundation Differs from that in Project Server」を参照してください。

プロジェクト マネージャーがベースラインを設定すると、Team Foundation の "最初の見積もり" フィールドの値が、次の図に示すように設定または更新されます。 既定では、このフィールドは OnConflict="PSWin" 属性にマップされます。

Work estimates

注意

Visual Studio のスクラム プロセス テンプレートは、"実績作業" フィールドおよび "最初の見積もり" フィールドを使用しないため、データ同期に含める作業項目の種類にこれらのフィールドを追加する必要があります。また、タスクの種類の定義を変更して、<EMPTY /> ワークフロー ステートメントを削除する必要もあります。詳細については、「スクラム プロセス テンプレートから作成されたチーム プロジェクトにマップするときに必要な変更」を参照してください。

割り当てまたはリソース名のフィールドに対する更新

Team Foundation の "担当者" フィールドは、Project Server の "リソース名" フィールドにマップします。 既定では、このフィールドは OnConflict="PSWin" 属性にマップされます。 リソースをエンタープライズ プロジェクト計画のタスクに割り当てるときは、次の規則について検討します。

  • 同期エンジンは、両方のサーバー製品間でリソース情報を同期しません。 既定では、Team Foundation Server は Active Directory からリソースを同期しますが、Project Server では同期を行いません。 リソースは Project Server に手動で追加できますが、最適な手段は Active Directory でリソースを同期することです。 リソースを Team Foundation Server との同期に含まれるエンタープライズ プロジェクト計画のタスクに関連付けるには、リソースを Project Server に追加する必要があります。 リソースを PWA のインスタント内のチーム メンバー グループに追加するか、Project の [プロジェクトを開く] と [プロジェクト サイトの表示] アクセス許可をリソースに付与します。 リソースをエンタープライズ プロジェクト計画のリソース リストに追加して、同期エンジンのプロジェクト計画を発行し、更新対象のリソース リストにアクセスできるようにする必要もあります。 詳細については、「TFS と Project Server を統合するためのアクセス許可の割り当て」を参照してください。

  • プロジェクトの詳細を管理している場合は、各タスクにリソースを 1 つだけ割り当てます。 タスクで複数のリソースを必要とする場合、タスクをサブタスクに分割し、各サブタスクに 1 つのリソースを割り当てます。

    トップダウン プランニングだけを使用してビジネス要件を管理している場合は、各ユーザー ストーリーまたは要件を開発のリーダーに割り当てます。

    プロジェクト計画を発行すると、Team Foundation のクライアント アドインによって、タスクごとに割り当てられているリソースが 1 つだけであることが検証されます。 タスクに複数のリソースが割り当てられていると、[検証の解決] ダイアログ ボックスが表示されます。このダイアログ ボックスで、アクティブな割り当てとしてリソースを 1 つだけ指定する必要があります。 詳細については、「妥当性確認エラーの解決」を参照してください。

  • タスクが作業項目にリンクまたはマップされた後は、ロールアップされていないタスクにのみ、リソースの割り当てまたは再割り当てを行うことができます。 ロールアップ タスクは、リンクされていない子作業項目を含む作業項目に関連付けられます。 通常、ロールアップ タスクには、"リソース名" フィールドの複数の名前が含まれています。 同期エンジンは、リソースのロールアップと各リソースでの作業時間数を送信します。 詳細については、「チーム プロジェクトにマップされているエンタープライズ プロジェクトにおけるリソース ロールアップの操作」を参照してください。

複数レベルで入れ子になった作業項目のサマリー タスク、タスク階層および送信

同期エンジンは、エンタープライズ プロジェクト計画内にサブタスクを持つリンク付きのタスクについて、プロジェクト フィールドを更新しないよう設計されています。 同期プロセスでは、プロジェクト計画でタスクの作業が計算されるため、これらのタスクの更新はスキップされます。 タイトルやその他の非作業フィールドの変更もこれらのタスクでは更新されません。 この動作は、2 サーバー製品の統合による既知の制限事項です。

プロジェクト マネージャーが必要条件を含むタスクの詳細セットとリンク付きのタスクを Team Foundation Server に発行すると、同期エンジンはタスク階層をロックします。 チーム メンバーは Team Foundation のタスク階層を変更することはできませんが、チーム プロジェクトのチーム メンバーにタスクを再割り当てすることはできます。 次の図に示すように、タスクは必要条件の下に一覧表示され、親タスクと子タスクの階層リンクはロックされています (Locked link icon)。 ロックされたリンクは、必要条件と子タスクが Project Server からチーム プロジェクトに追加されたことを示しています。 タスク階層を変更できるのは、プロジェクト計画のプロジェクト マネージャーのみです。

Work breakdown schedule in Team Explorer

チームが Team Foundation から Project Server に作業項目の複数のレベルを送信した場合、最初のレベルが承認されて Project Server に発行されるまで、次のレベルを送信することはできません。 たとえば、チームが 3 つのレベルの子項目を含む新しい作業項目のバッチを送信したと場合、すべての作業項目が Project Server と同期されるようにするには、プロジェクト マネージャーがプロジェクト計画を 4 回発行する必要があります。 プロジェクト マネージャーが作業項目の各レベルを承認し、それらを Project Server に発行していくにつれて、Team Foundation で階層リンク関係がロックされ、最終的にはリンク階層全体がロックされます。 このようにマップされた作業項目をチーム メンバーが変更することはできません。

選択リストまたはルックアップ テーブルに関連付けられたフィールドの更新

選択リストに関連付けられた Team Foundation Server フィールド、またはルックアップ テーブルに関連付けられた Project Server フィールドをマップする場合は、快適なユーザー エクスペリエンスにするために手順の追加を検討する必要があります。 同期エンジンは、対象に関連付けられたリストを自動的に作成したり、許容される値を他のサーバーに同期したりすることはありません。 推奨される手順は、Project Server にルックアップ テーブルを作成して、Team Foundation で定義された検索リストに一致させると共に、Team Foundation に選択リストを作成して、Project Server で定義されたルックアップ テーブルに一致させることです。 選択リストまたはルックアップ テーブルが変更された場合は、必ずもう一方のサーバー製品で対応するリストを手動で更新する必要があります。

参照

概念

データの同期をサポートするために TFS に追加された Project Server フィールド

その他の技術情報

TFS と Project Server の統合を使用したプロジェクトの管理

TFS と Project Server の間のフィールド マッピングのカスタマイズ