Jiraの権限・ロール管理実務ガイド:権限スキームとプロジェクトロールで「誰が何に触れるか」を設計する

ワークフローと自動化ルールの先に残る、権限という論点

当サイトの「Jiraのワークフロー・課題タイプ設計」でステータスと遷移を固め、「Jiraの自動化ルール実務ガイド」で通知やアサインを自動化し、「Jiraのボード運用実務ガイド」でボードの運用に乗せたあとに残る論点が、誰が作業項目を作成・編集・削除・遷移できるかという権限の設計である。ワークフローは「どのステータスからどのステータスへ動けるか」を決める仕組みであり、権限は「誰がその操作を実行できるか」を決める別の仕組みである。この2つは独立して設定するため、ワークフローを精緻に作り込んでも権限の設計を後回しにすると、想定していない人が作業項目を削除したり、他人のコメントを書き換えたりできる状態のまま運用が始まってしまう。

この記事は、Atlassian公式ドキュメントの仕様から、Jiraの権限を構成する3つの層(グローバル権限・権限スキーム・課題セキュリティ)と、権限を人ではなく役割に紐づけるプロジェクトロール(スペースロール)の仕組みを整理し、会社管理スペースとチーム管理スペースで設計の入り口がどう違うかを手順としてまとめる。

この記事の編集基準

本記事にアフィリエイトリンク・紹介料・掲載料は一切ない。仕様の記述は、Atlassian公式サポートドキュメント(support.atlassian.com)で確認できた範囲に限定している。

権限は3つの層に分かれる

Jiraの権限は、適用される範囲が異なる3つの層で構成される。グローバル権限は、サイト全体に適用される権限である。権限スキームは、特定のスペースの中で「ユーザーが何をできるか」を定義する権限である。課題セキュリティスキーム(work item security scheme)は、その両方とは別に、アクセスできるスペースの中でも個々の作業項目の閲覧範囲をさらに絞り込む仕組みで、Atlassian公式ドキュメントは「an otherwise accessible spaceの中で、個々の作業項目の可視性を制限する」ものと説明している。3つの層は独立しており、権限スキームで「スペースに入れる」状態にした人でも、課題セキュリティで特定の作業項目からは締め出せる。

グローバル権限:サイト全体を制御する権限

グローバル権限は「Organization管理者またはサイト管理者」が設定でき、Organization管理者が作成したグループに対して付与する。

権限スキーム:スペースで「誰が何をできるか」を決める仕組み

Atlassian公式ドキュメントは権限スキームを「ユーザーがスペース内で何をできるかを定義できる」仕組みと説明している。1つの権限スキームは複数のスペースで共有でき、共有した状態で内容を変更すると、そのスキームを使っているすべてのスペースに変更が反映される。権限は、ユーザー・グループ・スペースロール(後述)のいずれに対しても割り当てられる。

権限スキームの新規作成には「Administer Jira」権限が必要で、手順は「設定」→作業項目のオプション画面→「Permission Schemes」(作業項目属性セクションの下部)→「Add Permission Scheme」から、名前と説明を入力して「Add」を選ぶ。作成しただけでは何も変わらず、続けてスキームへ権限を割り当て、対象のスペースへ関連付けて初めて有効になる。既存のスペースに別の権限スキームを割り当てる場合は、スペースの「More actions」(•••)から「Space settings」→「Permissions」→「Actions」→「Use a different scheme」で切り替え先のスキームを選び「Associate」を選ぶ。変更は即座に反映される。

権限スキーム・スペースロール・課題セキュリティスキームは、いずれもFreeプランでは利用できない。

作業項目に対する権限:作成・編集・削除・遷移を誰に許すか

Delete work itemsは、コメントや添付ファイルを個別に削除する権限とは別物である。作業項目そのものの削除と、その中の個々のコメント・添付ファイルの削除は、次の権限で別に制御する。

コメント・添付ファイル・投票者とウォッチャーの権限

時間追跡の権限

プロジェクトロール(スペースロール):権限を人ではなく役割に紐づける

権限スキームでユーザーやグループへ直接権限を割り当てると、担当者が入れ替わるたびにスキームを編集することになる。この手間を避ける仕組みがプロジェクトロール(スペースロール)である。Atlassian公式ドキュメントは、スペースロールを、権限スキームで使う「プレースホルダー」であり、Jira管理者がロールを定義し、実際の割り当てはスペース管理者がスペースごとに行う仕組みと説明している。

スペースロールの新規作成は、「設定」→「System」→「Security」セクションの「Space roles」→「Add Space roles」から、ロール名と説明を入力して保存する。この操作にはJira管理者権限が必要である。ロールを作っただけでは誰も所属しておらず、実際にどのユーザー・グループをそのロールに割り当てるかは、各スペースの管理者がスペースごとに設定する。同じロール名(例:レビュー担当)を複数のスペースの権限スキームで使い回しても、ロールに入る実際のメンバーはスペースごとに違ってよい。

会社管理スペースとチーム管理スペースで、設計の入り口が違う

Jiraのワークフロー・課題タイプ設計で扱ったとおり、Jiraのスペースには会社管理とチーム管理の2種類があり、権限の設計もこの区分で入り口が変わる。

会社管理スペースは、ここまで説明した権限スキーム・スペースロール・課題セキュリティスキームを使う。権限スキームの編集にはグローバル権限の「Administer Jira」が必要で、複数のスペースで同じスキームを共有できる。

チーム管理スペースは、権限スキームを使わない。かわりに、Administrator・Member・Viewerという3つの固定ロールで権限を管理する。

会社管理スペースとチーム管理スペースで、設計の入り口が違う（続き）

チーム管理スペースには、誰が既定でどのロールになるかを左右するアクセスレベルもある。

ロールの割り当てには「Space admin」ロールが必要である。会社管理スペースの15種類を超える作業項目権限と比べると、チーム管理スペースの権限は3ロールに集約されており、細かく分けたい権限(例:コメントの削除だけを一部の人に許す)がある場合は会社管理スペースを選ぶ判断材料になる。

設計の進め方

ここまでを、権限を新しく設計する際の順序として並べ直す。

STEP1：対象のスペースが会社管理かチーム管理かを確認する。チーム管理ならAdministrator・Member・Viewerの3ロールにメンバーを振り分ける設計で完結し、権限スキームは使わない。会社管理なら次のSTEPへ進む。

STEP2：作業項目に対する操作(作成・編集・削除・アーカイブ・遷移・移動・リンク・レポーター変更)を洗い出し、誰に許すかを役割ごとに決める。あわせてコメント・添付ファイル・時間追跡の権限も同じ単位で決める。

STEP3：役割の単位をスペースロールとして作る。「設定」→「System」→「Security」→「Space roles」で作成し、権限スキーム側でロールへ権限を割り当てる。

STEP4：権限スキームを対象のスペースへ関連付ける。既に他のスペースが使っているスキームを流用する場合は、変更がそのスキームを使う全スペースに及ぶことを踏まえ、専用のスキームを複製してから編集するか、影響範囲を確認してから変更する。

STEP5：特定のステータスでだけ編集を制限したい、特定の作業項目だけ閲覧者を絞りたいといった要件は、権限スキームではなくJiraのワークフロー・課題タイプ設計で扱ったワークフローの遷移条件や、課題セキュリティスキームで対応する。権限スキームは「スペースに入れるかどうか」の粗い制御で、ステータス単位・作業項目単位の細かい制御は別の仕組みが担う。

まとめ:権限設計はワークフローと自動化ルールの前提になる

Jiraの自動化ルール実務ガイドで扱った自動化ルールも、ルールを作成・管理できる人の範囲は権限で決まる。会社管理スペースでは「Administer spaces」と「Browse spaces」を持つ人が、チーム管理スペースでは「Administrator」アクセスを持つ人が、それぞれ自分のスペース内のルールを作成・管理できる。ワークフローと自動化ルールが「何がどう動くか」を決める仕組みだとすれば、権限とロールは「誰がその仕組みに触れられるか」を決める土台であり、運用を始める前に固めておくと、後から権限起因のトラブルを洗い出す手間が減る。