このページでは、内部サービス プロジェクト ユーザーの権限について説明します。顧客の情報については、顧客権限の詳細をお読みください。

Two main settings determine a person's permissions in your team-managed service project:

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

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

サイト管理者は組織がサブスクライブしているアトラシアン製品について、ライセンスを付与して使用を許可するユーザーを割り当てます。アトラシアン サイト全体でのユーザーとアプリケーションの管理についてお読みください。

内部アクセス レベル

サービス プロジェクトの内部アクセス レベルにより、ログインしている任意の 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.

• 非公開。サービス プロジェクトが非公開の場合、Jira 管理者とサービス デスクに追加されたユーザーのみが、サービス プロジェクトを表示したり、検索結果でそのリクエストを確認したりすることができます。

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

サービス プロジェクトのアクセス レベルは、Jira サイトへの内部アクセス権を持つユーザーに対して一般的な権限を設定します。独自のロールを作成して、各ユーザーに特定のアクセス権や追加の権限を付与できます。ロールの詳細をお読みください。

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

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

添付ファイルの追加

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

通常、チーム メンバーまたはコラボレーターは自分の作業を説明するためにこの権限が必要です。課題へのファイルやスクリーンショットの添付の詳細をご確認ください。

内部コメントを追加

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

Typically, any team member or collaborator needs this permission to communicate internally on customer requests. Internal notes do not display to customers using your service project's portal.

課題ウォッチャーの追加または削除

この権限を持つユーザーは、リクエストのウォッチ リストからユーザーを追加または削除できます。

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

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

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

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

• make changes to the portal

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

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

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

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

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

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

リクエストを割り当て

この権限を使用すると、ユーザーが任意のサービス プロジェクト リクエストの [担当者] フィールドの値を変更できます。

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

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

この権限を使用すると、内部的に Jira サイトにログインしているユーザーがサービス プロジェクトにリクエストを作成できます。通常、これはナビゲーション バーの [+ 作成] ボタンで実行されます。

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. Learn more about how to raise requests.

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

This set of permissions is typically granted to team members who don’t play a central role in your project. Your team may involve them in answering questions to help fulfill a request. Usually, these are developers using software projects or administrators using business projects. Depending on your organization, you might give these permissions to developers, technical writers, consultants, or other supporting roles.

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

• 添付ファイルの追加

• コメントの追加

• 自分のコメントの編集

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

• 自分のコメントの削除

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 issues in Jira.

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

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

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

内部コメントの削除

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

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

リクエストの削除

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

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

作業ログ エントリを削除

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

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

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

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

通常、(添付ファイルの追加権限を持つために) リクエストにファイルを添付できるユーザーは、自分の添付ファイルを削除できることが望ましいです。このプラクティスは、リクエストを解決する過程で多くのバージョンのファイルや画像をアップロードした作業を明確化するのに役立ちます。コンプライアンスまたはトレーサビリティについて厳格な要件が課される組織では、この権限を制限してリクエストのライフ サイクルを通じて正確な履歴レコードを保持することを検討することが望まれます。

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

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

通常、(内部コメントの追加権限を持つために) 課題に内部コメントを追加できるユーザーは、自分の内部コメントを削除できることが望ましいです。これは、ある人物が誤ったコメントや、不正確なコメントを追加した場合に、作業を明確化するのに役立ちます。コンプライアンスまたはトレーサビリティについて厳格な要件が課される組織では、この権限を制限してリクエストのライフ サイクルを通じて正確な履歴レコードを保持することを検討することが望まれます。

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

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

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

内部コメントを編集

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

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

期日を編集

この権限を使用すると、ユーザーが任意のサービス プロジェクト リクエストの既定の [期日] フィールドの値を変更できます。

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

リクエストの編集

この権限を持つユーザーは、要約や説明を変更したり、別の権限 (リクエストを割り当てや報告者を変更権限など) で制限されていないフィールドの値を変更したりできます。

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

作業ログ エントリを編集

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

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

報告者を変更

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. Learn more about how to raise requests on behalf of a customer.

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

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

通常、(内部コメントの追加権限を持つために) リクエストに内部コメントを追加できるユーザーは、自分のコメントを変更したり、スペルミスやリンク切れなどの軽微な問題を修正できることが望ましいです。コンプライアンスまたはトレーサビリティについて厳格な要件が課される組織では、この権限を制限してリクエストのライフ サイクルを通じて正確な履歴レコードを保持することを検討することが望まれます。

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

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

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

課題をリンク

この権限を持つユーザーは、サービス プロジェクト内のリクエストを別のリクエストや、サイト上の他のプロジェクトの課題およびリクエストにリンクすることができます。リンクを正常に表示するには、ターゲット プロジェクト内で同じ権限が必要です。

リクエストの作業を記録

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

この権限を持つユーザーは、リクエストに費やした時間と対応までの残りの時間を示す作業ログ エントリ (プロセス中に行った作業の簡単な説明を含む) を作成することができます。

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

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

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

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

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

• コメントの削除

• 期日を編集

• 内部コメントを編集

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

• 報告者を変更

• リクエストの削除

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

Manage requests in sprints

This permission allows people to create, start, and complete sprints in software projects that include requests from your service project. This permission does not give teams using software projects the ability to transition, edit, or communicate with customers on your service project requests.

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 issues in their software project. These types of teams need permission to start and complete sprints that include your service project's requests.

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

この権限を持つユーザーは、サービス プロジェクトの任意のリクエストで、リクエストのワークフローを表示し、ステータスを更新できます。ワークフローを通じて任意の課題を移動し、トランジションに関連付けられているワークフローまたは自動化ルールがあった場合はそれをトリガーします。この権限は、リクエストを移動できるユーザーを制限するワークフロー ルールによってオーバーライドされる場合があります。ワークフロー ルールの詳細をご確認ください。

この権限は、企業管理対象プロジェクトの課題のトランジション、課題の解決、課題のクローズの各権限を組み合わせたものです。

ウォッチャーを表示

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

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

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

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

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

• リクエストを割り当て

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

• リクエストの編集

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

• リクエストのリンク

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

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

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