共有チームは、役割のセットで構成され、それらの役割にはメンバーが追加されます (コンテキストチームと同様です)。共有チームは、組織コンテキストで作成され、組織コンテキストから作成される複数のアプリケーションコンテキストのコンテキストチームとして使用できます。たとえば、Bike Company 組織に Product Demo Team という共有チームを作成したとします。この共有チームは、ユーザーが Bike Company 組織コンテキストで作業中に、製品やプロジェクトなどのアプリケーションコンテキストを作成する際に選択できます。アプリケーションコンテキストを作成しているユーザーが異なる組織コンテキストのメンバーである場合は、Product Demo Team は使用できません。詳細については、コンテキストについてを参照してください。

共有チームを作成する場合、その共有チームを使用するアプリケーションコンテキストの作成時に、共有チームをローカルで拡張可能にするかどうかを設定できます。その共有チームを選択するすべてのコンテキストチームに、共有チーム以外は使用しないよう制限する場合は、「関連するアプリケーションコンテキストにおいてローカルでのチームの拡張を許可します」オプションをオンにしないでください。

アプリケーションコンテキストの作成時に有効な共有チームがない場合は、アプリケーションコンテキストの作成者には共有チームフィールドは表示されず、作成されたチームはローカルチームになります。共有チームは、アプリケーションコンテキスト作成後には追加できません。

共有チームに加えた変更は、その共有チームを使用するすべてのコンテキストチームに反映されます。たとえば、共有チームに変更を加えた後で、その共有チームを使用しているコンテキストチームの「チーム」ページを再表示すると、共有チームに加えた変更が表示されます。

以下のセクションでは、共有チームの役割を紹介し、システムグループおよびドメインを使用して共有チームを管理する方法について説明します。

共有チームで確立される初期の役割は以下のとおりです。

共有チームへの役割とメンバーの追加または除去は、ローカルチームへの役割とメンバーの追加または除去と同じ方法で実行できます。詳細については、以下のトピックを参照してください。

コンテキストチームに共有チームとローカルチームの両方が含まれる場合、共有チームマネージャグループがコンテキストマネージャのシステムグループにメンバーとして追加されます。誰が共有チームマネージャグループのメンバーかがわかるようにするために、コンテキストチームをローカルに拡張しても、「メンバー」テーブルでは共有チームマネージャ役割とコンテキストマネージャ役割は別々のままになります。

たとえば、バイク設計プロジェクトに一般設計共有チームを含むコンテキストチームがあるものとします。一般設計共有チームマネージャ役割のメンバーはクリス・テイラーです。クリス・テイラーは、バイク設計プロジェクトの「メンバー」テーブルの共有チームマネージャ役割の下に表示されます。ただし、共有チームマネージャグループはメンバーとしてプロジェクトマネージャグループに追加されるので、クリス・テイラーは、ローカルチームのプロジェクトマネージャ役割のその他のメンバーとともに、バイク設計プロジェクトのプロジェクトマネージャの役割を担います。

共有チームのメンバー役割およびゲスト役割の参加者も、同様にローカルチームのメンバー役割およびゲスト役割のメンバーになります。共有チームのメンバーグループおよびゲストグループは、ローカルチームのメンバーグループおよびゲストグループとして追加されます。同様に、やはりローカルチームに含まれる共有チームにその他の役割を追加する場合、同じ名前を持つその役割の参加者は、同じ役割であると見なされます。ローカルチームの「メンバー」テーブルでは、共有チームおよびローカルチームのメンバーを持つ 1 つの役割のみが、「役割別メンバー」ビューのその役割の下に表示されます。

Windchill PDMLink では、ローカルチームのコンテキストマネージャ、組織管理者、サイト管理者、またはチーム構成を修正操作を実行できるユーザーである場合、ローカルチームと共有チームの両方の役割またはメンバーがビューに含まれているときに「メンバー」テーブルに表示される「所属」列に表示されている情報を調べることで、共有チームの一部となる役割やメンバーを決定することができます。たとえば、共有チームのデザイナー役割を 2 人の参加者に割り当て、ローカルチームのデザイナー役割を 1 人の参加者に割り当てている場合、3 人すべての参加者がコンテキストチームのデザイナーとなります。「役割別メンバー」ビューに切り替えると、「メンバー」テーブルのデザイナー役割に 3 人すべての参加者が表示されます。共有チームとローカルチームのどちらのメンバーなのかは、テーブル内の「所属」列によって識別します。

Pro/INTRALINK では、ローカルチームのコンテキストマネージャ、組織管理者、またはサイト管理者である場合、ローカルチームと共有チームの両方の役割またはメンバーがビューに含まれているときに「メンバー」テーブルに表示される「所属」列に表示されている情報を調べることで、共有チームの一部となる役割やメンバーを決定することができます。たとえば、共有チームのデザイナー役割を 2 人の参加者に割り当て、ローカルチームのデザイナー役割を 1 人の参加者に割り当てている場合、3 人すべての参加者がコンテキストチームのデザイナーとなります。「役割別メンバー」ビューに切り替えると、「メンバー」テーブルのデザイナー役割に 3 人すべての参加者が表示されます。共有チームとローカルチームのどちらのメンバーなのかは、テーブル内の「所属」列によって識別します。

共有チームのみがあり、ローカルチームがない場合は、「メンバー」テーブルには追加の役割は表示されません。また、コンテキストマネージャ役割はチーム内では作成されません。代わりに「共有チームマネージャ」役割が、コンテキストのコンテキストマネージャとして機能します。「共有チームマネージャ」役割に対して設定されたアクセス制御ポリシー規則は、役割内の参加者に、コンテキスト内のすべてのオブジェクトに対するフルコントロール (すべて) アクセス許可を付与します。

共有チームを作成すると、共有チームと同じ名前の管理ドメインが作成されます。この共有チームのドメインの親ドメインは、共有チームが作成された組織コンテキストにある Default ドメインです。たとえば、Bike Company 組織コンテキストに Product Demo Team という共有チームを作成したとします。「ポリシー管理」ユーティリティで以下のドメイン構造を使用できます。

共有チームを使用するアプリケーションコンテキストを作成した場合、そのアプリケーションコンテキストのデフォルトドメインは共有チームドメインに作成されます。詳細については、コンテキストとドメイン階層の概要を参照してください。

たとえば、Product Demo Team を使用する Super Bike 製品コンテキストを作成すると、「ポリシー管理」ユーティリティでは以下のドメイン構造が使用可能になります。

このドメイン構造では、共有チームドメインに一意な一連のポリシーアクセス制御規則を作成でき、それらは、その共有チームを使用するすべてのアプリケーションコンテキストで継承されます。