Backlogの権限・ユーザー管理実務ガイド：管理者・プロジェクト管理者・一般ユーザー・ゲストで「誰が何に触れるか」を設計する

課題管理・ガントチャート・Webhook・APIの先に残る、権限という論点

「Backlogの課題管理実務ガイド」で課題・ドキュメント・ガントチャートの役割分担を、「Backlogの通知・Webhook・API実務ガイド」で外部ツールとの連携設計を扱った。この2本を運用に乗せたあとに残る論点が、誰が何を作成・編集・削除・追加できるかという権限の設計である。Backlog Developer APIの認証ドキュメントは、権限をAdministrator(管理者)・Project Administrator(プロジェクト管理者)・Member(一般ユーザー)・Guest(ゲスト)という4段階で定義しており、この4段階はAPI経由の操作だけでなく、Backlogの画面上の操作にもそのまま適用される。

「Jiraの権限・ロール管理実務ガイド」では、Jiraが権限スキーム・プロジェクトロール・課題セキュリティという3層構造を持つことを整理した。Backlogの権限設計はJiraとは発想が異なり、役割を細かく分けるのではなく「基本ロール×機能制限×追加権限」という3つの軸の組み合わせで、誰が何に触れるかを決める。この記事は、Backlog公式ヘルプセンターとBacklog Developer APIの一次情報にもとづき、この3軸の仕組みと、社外メンバーを迎える際の設計手順を整理する。

この記事の編集基準

本記事にアフィリエイトリンク・紹介料・掲載料は一切ない。仕様の記述は、Backlog公式ヘルプセンター(help-center.backlog.com)、Backlog Enterpriseユーザーガイド(backlog.com/ja/enterprise-help)、Backlog Developer API公式ドキュメント(developer.nulab.com/docs/backlog)で確認できた範囲に限定している。

Backlogの権限は「基本ロール」「機能制限」「追加権限」の3軸で決まる

Backlogのアクセス管理は、独立した3つの軸を組み合わせて設計する。1つ目は、誰がどのプロジェクトに参加し、どこまでの操作カテゴリーを持つかを決める基本ロール。2つ目は、一般ユーザーとゲストにだけ追加でかけられる、課題操作の上限を決める機能制限。3つ目は、管理者の全権をまとめて渡さずに特定の管理業務だけを個別に委任する追加権限である。この3つを別々に理解しないまま権限を割り当てると、「ゲストなのに他プロジェクトの情報まで見えてしまう」逆に「一般ユーザーなのに起票すらできない」といった食い違いの原因を追えなくなる。

基本ロールの4段階：それぞれ何ができるか

Backlog Developer APIの認証ドキュメントは、権限レベルをAdministrator・Project Administrator・Member・Guestの4段階と定義している。Backlogヘルプセンターの「ユーザーの権限」は、この4段階のうちMemberとGuestを画面上で「一般ユーザー」「ゲスト」と呼び、それぞれの範囲を次のように説明している。

機能制限：一般ユーザーとゲストに追加でかける上限

一般ユーザーとゲストには、管理者がユーザーの編集画面から、課題操作をさらに絞り込む機能制限を追加でかけられる。段階は制限なし・課題の追加のみ・課題の閲覧のみの3つで、Backlog Developer APIの表記ではNo restriction・Add issue only・View onlyにあたる。

プロジェクト管理者：一般ユーザーへの委任

「プロジェクト管理者の設定」ボタンは既定では管理者にのみ表示されるが、プロジェクトの基本設定を変更すれば、プロジェクト管理者自身にもこのボタンを表示できる。設定は「プロジェクト設定」の参加ユーザー画面から、プロジェクト単位で行う。

付与できる対象は「一般ユーザー(制限なし)」に限られる。機能制限がかかった一般ユーザーや、ゲストには、プロジェクト管理者権限を付与できない。管理者ではない担当者に特定プロジェクトの運用を任せたい場合、この条件を先に満たしているかを確認する必要がある。

追加権限：契約管理者・メンバー招待権限・チーム管理者という個別委任

管理者の全権をまとめて渡さずに、特定の管理業務だけを委任する追加権限が3つ用意されている。

誰がユーザー・チームをプロジェクトに追加・削除できるか

スペース外から新しいユーザーをプロジェクトへ招待できるのは、管理者、または「メンバー招待権限」と「プロジェクト管理者」の両方を持つ一般ユーザーに限られる。メンバー招待権限だけでは、スペース外のユーザーを新規招待する操作は完結しない。

すでにスペースに参加している既存のユーザー・チームを別のプロジェクトへ追加する操作、およびプロジェクトの参加ユーザーから削除する操作は、管理者またはプロジェクト管理者が行う。いずれも「プロジェクト設定」の参加ユーザー画面が操作の起点になる。

退職や契約終了でアクセスを完全に切りたい場合、プロジェクトからの削除だけでは足りない。プロジェクト単位の削除は、そのプロジェクトへの参加を外すだけで、組織内のユーザーとしての存在や他プロジェクトへの参加は残る。組織全体からアクセスを外すには、別の「組織から外す」操作が必要になる。

アクセスの単位はプロジェクト：個々の課題を絞り込む機能は無い

「Jiraの権限・ロール管理実務ガイド」で扱った課題セキュリティスキームは、スペースに入れる人の中でも、個々の作業項目単位で閲覧をさらに絞り込む仕組みだった。Backlog公式ヘルプで確認できる範囲では、アクセス制御の単位はプロジェクトであり、一般ユーザーは参加しているプロジェクトの課題しか操作・閲覧できず、管理者であっても参加していないプロジェクトの課題は閲覧できない。

つまりプロジェクトへの参加・非参加が、実質的な閲覧境界線になる。特定の課題だけを一部のメンバーから隠したいという要件が出た場合、Backlogでは課題単位の非公開設定ではなく、その課題を含む範囲をプロジェクトとして分ける対応になる。

社外メンバーを迎えるときの3つの設計

社外のメンバーをBacklogに迎える場面では、社内向けに共有したい情報と社外に共有してよい情報を区別して設計する必要がある。

少ない部品数で同じ問いに答える設計

プロジェクトの分離・チームの分離・自動追加設定の解除という3つを組み合わせれば、課題単位の個別設定を使わなくても、社外メンバーが見られる範囲と社内メンバーが見られる範囲を明確に線引きできる。基本ロール・機能制限・追加権限という3つの軸だけで、細かい役割を追加せずに同じ問いに答えられる設計になっている。プロジェクトの規模と社外メンバーの参加範囲が広がるほど、この3軸を先に固めておく価値は大きくなる。