チーム管理対象サービス プロジェクトにある権限の概要

This page describes permissions for internal service project users. For information about customers, read about customer permissions

チーム管理対象サービス プロジェクトでは、次の 2 つの主な設定でユーザーの権限が決定されます。

1. サービス プロジェクトの内部アクセス レベル。

2. サービス プロジェクトにおけるロール。

Site admins control who's licensed to use the Atlassian products their organization is subscribed to. 

Read more about managing users and application access across your Atlassian site

内部アクセス レベル

サービス プロジェクトの内部アクセス レベルにより、ログインしている任意の Jira ユーザーに対し、サービス プロジェクトでの特定のロールを付与できます。

チーム管理対象サービス プロジェクトには、次の 2 つのシンプルな内部アクセス レベルが用意されています。

• Open. When a service project is open, anyone who logs into your Jira site (not the portal) can view and add internal notes to your project’s customer requests. With this access level, Jira Service Management gives anyone who logs into your Jira site the Agent role in your service project. Only people with the Agent role and product access to Jira Service Management can communicate with customers and resolve requests.

• Private. When a service project is private, only Jira admins and people added to the service project can see it or its requests in search results.

Jira 管理者 (Jira 管理グローバル権限を持つユーザー) は常に、サービス プロジェクトの設定へのアクセス権を持ちます。

Your service project's access level sets general permissions for people with internal access to you Jira site. You can give specific access or additional permissions to individual people by creating your own roles. Read more about roles

チーム管理対象サービス プロジェクト権限

チーム管理対象サービス プロジェクトでロールを定義するために付与できる権限の一覧は次のとおりです。 

添付ファイルの追加

この権限を使用すると、ユーザーがサービス プロジェクトのリクエストにファイルを添付できます。Jira 管理者は、添付できるファイルとファイルの大きさを制限できます。

Typically, any team member or collaborator needs this permission to help describe their work. 

More about attaching files and screenshots to work items

内部コメントを追加

この権限を持つユーザーは、プロジェクトのどのリクエストにもコメントできます。

通常、チーム メンバーまたはコラボレーターは顧客リクエストで内部でやり取りするためにこの権限が必要です。内部コメントは、サービス プロジェクト ポータルを使用する顧客には表示されません。

Add or remove work item watchers

This permission allows people to add or remove people from a work item's watch list.

サービス プロジェクトを管理する

この権限を持つユーザーはサービス プロジェクト設定にアクセスできます。このユーザーは以下が可能です。

• サービス プロジェクトへの他のユーザーの内部アクセス権を編集する

• リクエスト タイプ、フィールド、ワークフローを設定する

• ポータルを変更する

• カスタマー通知を管理する

• ナレッジ ベース設定の変更

• 自動化ルールをセットアップする

• サービス レベル アグリーメントを管理する

• 顧客度満足度のアンケートを有効化または無効化する

• サービス プロジェクトと顧客リクエストを完全に削除する

リクエストを割り当て

This permission allows people to change the value of the Assignee field on any of your service project's requests.

この権限を持つチーム メンバーは、作業のさまざまなステージでタスクを引き渡すことができます。

内部でリクエストを作成する

This permission allows people logged in to your Jira site internally to create requests in your service project. Usually, this happens via the + Create button in the navigation bar.

For some organizations, this creates a quick way for internal collaborators to raise requests in your service project anywhere from inside Jira. But, we don’t recommend this. Requests raised internally may cause unexpected behavior, including incorrect data entry for customer fields. We encourage internal service teams to promote their service project's portal even to internal customers. We also recommend service agents use the portal to raise a request on behalf of a customer, rather than Jira’s internal create button. This helps with proper tracking, sorting, and filtering for customer requests' Reporter field. 

More about how to raise requests

リクエストでのコラボレーション (一連の権限)

この一連の権限は、多くの場合でプロジェクトの中心的なロールを持たないチーム メンバーに付与されます。リクエストを解決するための質問への回答を得るために、チームがこうしたメンバーを関与させる場合があります。通常、これらはソフトウェア プロジェクトを使用する開発者またはビジネス プロジェクトを使用する管理者です。組織によっては、これらの権限を開発者、テクニカル ライター、コンサルタント、またはその他のサポート ロールに付与する場合があります。

この一連の権限を付与すると、次のバンドルされた権限が与えられます。

• 添付ファイルの追加

• コメントの追加

• 自分のコメントの編集

• 自身の添付ファイルを削除する

• 自分のコメントの削除

You may grant these permissions to anyone with log in access to your Jira site. For example, if you have multiple Jira products on the same cloud site, a Jira Service Management agent can be given this set of permissions and collaborate on work items in Jira.

任意の添付ファイルを削除する

この権限を持つユーザーは、サービス プロジェクトのリクエストで、任意のユーザーが追加した添付ファイルを削除できます。

一部のチームではこの権限を管理ロール用に予約している場合がありますが、オープンな組織では、この機能をすべてのチーム メンバーに付与することでメリットが得られます。たとえば、作業の進捗状況に応じて、技術的な図やその他の図が変更される可能性があります。チーム メンバーは元の添付ファイルの所有者ではなくても最新の状態に維持することができます。

内部コメントの削除

この権限を持つユーザーは、サービス プロジェクトのリクエストで、任意のユーザーが追加した内部コメントを削除できます。この権限は少しばかり強力です。

トレーサビリティと過去の調査のために、アトラシアンではすべての内部コメント、カスタマーへの返信、カスタマーのコメントを保存することを推奨しています。コメントは、リクエストの進行の追跡や今後のやり取りの改善点を検討するうえで参考になります。そのため、この権限はチーム リーダー、人事マネージャー、その他の管理ロールのみに付与することをおすすめします。

リクエストの削除

この権限を持つユーザーは、関連するフィールド データ、内部コメント、カスタマーの返信、作業ログを含む、プロジェクトの任意のリクエストを削除できます。

この権限は一般に、チーム リーダーまたはプロジェクトの管理ロールにのみ付与することが望まれます。一般に、リクエストを削除することは推奨されません。リクエストのステータスを完了カテゴリ ステータスに変更するほうが、不要なリクエストのクリーンアップよりも推奨されます。リクエストのステータスを変更すると、リクエストの報告者、担当者、およびウォッチャーに、チームがタスクで実行したアクションが通知されます。

作業ログ エントリを削除

この権限を持つユーザーは、サービス プロジェクトのリクエストで、任意のユーザーが追加した作業ログ エントリを削除できます。

通常、他のユーザーの作業ログ エントリの削除は、チーム リーダーまたはその他の管理ロール専用の権限です。

自身の添付ファイルを削除する

この権限を持つユーザーは、サービス プロジェクトのリクエストに自身が追加した任意のファイルや画像を削除できます。

Typically, anyone who can attach files to a request (by having the Add attachments permission) should be able to remove their own attachments. This practice can help clarify work where many versions of a file or image are uploaded throughout the course of resolving a request. Organizations with strict compliance or traceability requirements may consider restricting this permission to preserve an accurate historical record throughout a request’s lifecycle.

自分の内部コメントの削除

この権限を持つユーザーは、サービス プロジェクトのリクエストに自身が追加した任意の内部コメントを削除できます。

Typically, anyone who can leave internal notes on a request (by having the Add internal notes permission) should be able to remove their own internal notes. This practice can help clarify work if people leave erroneous or inaccurate notes. Organizations with strict compliance or traceability requirements may consider restricting this permission to preserve an accurate historical record throughout a request’s lifecycle.

自分の作業ログ エントリを削除

この権限を使用すると、自身が記録した時間、残余として見積もられた時間、サービス プロジェクトの任意のリクエストに追加した作業ログの説明を削除できます。

通常、サービス プロジェクトで作業して時間を記録しているユーザーは、データ入力時のエラーに備え、自分の作業ログを削除できる必要があります。

内部コメントを編集

この権限を使用すると、ユーザーは任意のサービス プロジェクト リクエストに追加された任意の内部コメントの内容を変更できます。

オープンな組織では、チームで互いの内部コメントを編集して、スペル ミスやリンク切れなどの軽微な問題を修正したり、コミュニケーションの流れを整理したりすることが推奨されます。厳格なコンプライアンスまたはトレーサビリティ要件を持つ組織は、この権限をチーム リーダーまたはプロジェクト マネージャー用に予約する場合があります。

期日を編集

This permission allows people to change the value of the default Due date field on any of your service project's requests.

厳格なコンプライアンスまたはトレーサビリティ要件を持つ組織は、この権限をチーム リーダーまたはプロジェクト マネージャー用に予約する場合があります。

リクエストの編集

This permission allows people to alter the summary and description, and change the value of fields that aren’t restricted by another permission (like the Assign requests or Edit reporters permissions).

オープンな組織ではチームに対し、作業でリクエストを表示する際にフィールドを調整することで互いの作業を最新の状態に維持するよう促します。説明を明確化し、フィールドを更新できるようにすることは、スタンドアップ ミーティング、計画ミーティング、またはキュー整理セッションなどの共通のミーティング時にリクエストのレビューを実施する可能性があるチーム メンバーには特に便利です。厳格なコンプライアンスまたはトレーサビリティ要件を持つ組織は、この権限をチーム リーダーまたはプロジェクト マネージャー用に予約する場合があります。

作業ログ エントリを編集

この権限を使用すると、サービス プロジェクトのいずれかのリクエストで任意のユーザーによって追加された記録時間、残り時間、および作業ログの説明を変更できます。

通常、他のユーザーの作業ログ エントリの調整は、チーム リーダーまたはその他の管理ロール用に予約されます。

報告者を変更

This permission allows people to change the value of the default Reporter field on any of your service project's requests. The Reporter field is automatically set to the request’s creator at the time the request is raised. Usually, this is the customer who submits a request through your portal. The Reporter field may be set manually when raising a request on behalf of a customer. 

How to raise requests on behalf of a customer

自分の内部コメントを編集

この権限を持つユーザーは、サービス プロジェクトのリクエストに自身が追加した任意の内部コメントの内容を変更できます。

Typically, anyone who can leave notes on a request (by having the Add internal notes permission) should be able to adjust their own notes and correct minor problems like spelling errors or broken links. Organizations with strict compliance or traceability requirements may consider restricting this permission to preserve an accurate historical record throughout a request’s lifecycle.

自分の作業ログ エントリを編集

この権限を使用すると、自身が記録した時間、残余として見積もられた時間、サービス プロジェクトの任意のリクエストに追加した作業ログの説明を変更できます。

通常、サービス プロジェクトで作業して時間を記録しているユーザーは、データ入力時のエラーや作業のスコープまたは要件の変更に備え、自分の作業ログを調整できる必要があります。

Link any work item

This permission allows people to link requests in your service project to one another, or to work items and requests in other projects on your site. To view the link properly, they need the same permission in the target project.

リクエストの作業を記録

この権限を持つユーザーは、サービス プロジェクトの任意のリクエストで時間管理フィールドを操作できます。

This permission allows people to create a work log entry, where they can indicate the time spent and time remaining to fulfil the request, including a brief description of the work they did along the way.

プロジェクトのリクエストを管理 (一覧の権限)

通常、この一連の権限は、チーム リーダーやマネージャーなどのサービス プロジェクト全体を監督するロールに付与されるのが一般的です。

この権限を付与すると、次のバンドルされた権限も与えられます。

• リクエスト ウォッチャーの追加または削除

• 任意の添付ファイルを削除する

• コメントを削除

• 期日を編集

• 内部コメントを編集

• 作業ログ エントリを編集

• 報告者を変更

• リクエストの削除

• 作業ログ エントリを削除

スプリントでリクエストを管理する

この権限を持つユーザーは、ソフトウェア プロジェクトでスプリントを作成、開始、および完了できます。これには、サービス プロジェクトからのリクエストが含まれます。この権限により、ソフトウェアを使用するチームに、サービス プロジェクト リクエストでトランジション、編集、および顧客とやり取りする権限が与えられることはありません。

Sprints are a concept from agile methodology, specifically a way of working called Scrum. Typically, sprints are managed by team leaders or designated Scrum masters. Some teams working in a scrum way include Jira Service Management customer requests on their sprint boards to track their progress in their own team’s workspace. For example, organizations that create software may have a Jira Service Management project that collects bug reports from customers. An internal development team using a software project may create a filter to include these bug reports in their scrum development boards, without having to recreate them as work items in their software project. These types of teams need permission to start and complete sprints that include your service project's requests.

リクエストをトランジション

This permission allows people to view any request’s underlying workflow and update the status of any of your service project's requests. They can move any work item through the workflow, triggering any workflow or automation rules that may be associated with the transition along the way. This permission may be overridden by the Restrict who can move a request workflow rule. Read about workflow rules

This permission is a combination of the Transition work items, Resolve work items, and Close work items permissions in company-managed projects.

ウォッチャーを表示

この権限を持つユーザーは、サービス プロジェクトの任意のリクエストをウォッチしているユーザーを表示することができます。

Jira サイトにログインするすべてのユーザーにこの権限を付与できます。

サービス プロジェクト リクエストでの作業 (一連の権限)

この一連の権限は、サービス エージェント、サービス チーム マネージャー、およびカスタマーのリクエストの解決に直接取り組む他のユーザーに付与されるのが一般的です。通常、中核チームのメンバーとみなされるユーザーに付与される権限です。

この権限を付与すると、次のバンドルされた権限も与えられます。

• リクエストを割り当て

• 自分の作業ログ エントリを削除

• リクエストの編集

• 自分の作業ログ エントリを編集

• リクエストのリンク

• リクエストの作業を記録

• リクエストをトランジション

これらの権限をロールに付与すると、そのロールを持つすべてのユーザーがサービス プロジェクト顧客とやり取りできます。