---
title: LOG Sprout Jira権限設計ガイド プレゼンテーション
tags: 
author: [Fumiya Okazaki](https://image.docswell.com/user/FumiyaOkazaki)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/G75MX83874.jpg?width=480
description: Jiraの運用整備、クラウド移行
published: September 06, 26
canonical: https://image.docswell.com/s/FumiyaOkazaki/5VJ2DV-2026-09-06-142709
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/G75MX83874.jpg)

情シス向け Jira運用ナレッジ
Jira 権限設計ガイド
設定の乱立・煩雑化を防ぎ、直感的な運用とガバナンスを両立する設計手法
岡崎 文哉
LOG Sprout合同会社


# Page. 2

![Page Image](https://bcdn.docswell.com/page/9J29XKZVER.jpg)

LOG Sprout合同会社のご紹介
Mission
「想いを形に、未来を紡ぐ。」
人の多様な経験からなる小さな気づきを記録（LOG）し、積み
上げ、芽開く（Sprout）。
単なるツール導入で終わらせず、現場の限界を超える「質の高
い伴走」で組織の成長を牽引します。
© LOG Sprout G.K. All rights reserved.
会社概要
商号: LOG Sprout合同会社
ミッション: チーム伴走型ITイノベーションの推進
事業内容:
アジャイル開発・Jira活用定着コンサルティング
ITインフラ・ツール運用の伴走型業務改善支援、その他
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/DEY48NRQJM.jpg)

Server/DC移行時に陥る「権限の乱立・煩雑化」
移行時にしっかり権限設計を行わないと、設定の「乱立・煩雑化」を引き起こします。
旧環境の設定を
無計画に一括移行
➔
権限・設定が
無秩序に乱立・煩雑化
➔
直感的なタスク管理の阻害
情シスへ問い合わせ集中
「謎のステータスや入力項目がある」「意図した操作ができない」等
不満・問い合わせが情シスに集中！
© LOG Sprout G.K. All rights reserved.
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/VJNYQXD278.jpg)

Jiraにおける権限設計 4つのレイヤー構造
1. アプリケーションアクセス
2. グローバル権限
3. 権限スキーマ
4. プロジェクト(スペース)ロール
Jiraへのログイン可否およびライセンス消費をグループ単位で
制御する最上位階層。
企業管理対象PJにおいて、閲覧・起票・編集等の操作条件を
共通定義する型。
© LOG Sprout G.K. All rights reserved.
サイト管理や、Cloud固有機能である「チーム管理対象PJ作
成」等の全体権限。
プロジェクトごとにユーザーやグループを「管理者・メンバ
ー」等に割り当てる枠組み。
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/YE9PD8GDJ3.jpg)

権限レイヤー結合図：操作型スキーマと現場ロールの分担
🏢 情シス（Jira管理者）の管轄
📁 プロジェクト（スペース）：現場の作業空間
全社共通ルール
1. アプリケーションアクセス
IdP連携 ➔ ログイン・ライセンス付与
2. グローバル権限
サイト全体管理 ＆ PJ作成権限制御
3. 権限スキーマ（既定ロールへの操作定義） 最小限に集約
ライフサイクルに応じてスキーマを切り替え
PJ-1（プロダクト開発）
PJ-2（人事・労務機密）
PJ-3（移行完了システム）
全社オープン（Usersに全正社員）
機密（ロール割当者のみ閉鎖）
凍結（改ざん防止・閲覧専用）
適用: 標準スキーマ
適用: 標準スキーマ再利用
適用: アーカイブスキーマ
➔
適
用
・
切
替
👤 4. 現場リード（Administrators）によるロール割り当て
公開範囲の制御はここで完結
オープン化（Usersに全正社員グループを指定）も機密化（ロールを特定数名に絞る）も同一の標準スキーマのまま現
場のロール設定だけで吸収可能！
標準運用スキーマ（通常稼働PJ）
• Administrators: PJ設定・ロール割当・全操作
• Developers: 課題起票・編集・担当・ステータス進行
• Users: 課題閲覧・起票・コメント追加（現場の基本操作）
アーカイブ用スキーマ（終了PJ用）
• 全ロール（Admin / Dev / User）: 起票・編集・削除権限を一律
剥奪し、「閲覧権限（Browse Projects）」のみ付与
© LOG Sprout G.K. All rights reserved.
👥 エンドユーザーの操作確定ロジック
自動判定
ユーザーが来訪すると、「適用スキーマの権限定義」✕「現場での割り当てロール」が照合されます。アーカイ
ブスキーマが適用されたPJでは、現場ロールが「Developers」であっても一律で閲覧のみに制限され、安全に過
去資産として保護されます。
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GE8D38V5ED.jpg)

Server/DCとCloudの違い：チーム管理対象プロジェクト
メリットと管理面のデメリット（横ぐし統制の喪失）
メリット（現場の自走性）:
旧Server/DC版にはなかった機能。情シスを介さず現場管理者が直感的に
フィールドやワークフローを追加・変更可能。
⚠️ 具体的な弊害例：ステータス差異による集計漏れ
企業管理対象PJと異なり共通スキーマによる横ぐし統制が効きません。
例えば「A-PJはオープン/進行中/完了の3ステータス」だが、「B-PJは完了後再開
した課題を【再オープン】という独自ステータスで管理」していた場合、全社横
断で分析するフィルターやダッシュボードを作成しても、【再オープン】が除外
され意図したチケット数の取得漏れが発生します。
© LOG Sprout G.K. All rights reserved.
グローバル権限での作成制御設計
※以下はグループ設計の一例です。
正社員・役職者グループ等に限定して付与:
横ぐし分析が崩壊するリスクを防ぐため、作成者を責任ある層に絞り込
み、現場の自走と全社分析のバランスを担保
グループ設計の重要ポイント:
Jira上に「明示的な拒否（ブロックリスト）」機能はありません。
そのため、アルバイト・外部委託等のIDが含まれないIdPグループを正確
に定義し、「そのグループのみに作成権限を付与する」設計を徹底しま
す。
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/LELMVR537R.jpg)

1. アプリケーションアクセス ＆ 2. グローバル権限
アプリケーションアクセス（IdP連携）
IdP（Okta / Entra ID等）と連動したグループ管理を徹底。
`jira-software-users` などの明確分離
ライセンス消費対象グループを厳格に自動管理
自動SSOプロビジョニング
退職時・異動時のライセンスの浮きや無駄コストを遮断
© LOG Sprout G.K. All rights reserved.
グローバル権限の設計原則
サイト全体の安全性とガバナンスを確保。
「Jira管理者」権限の最小化
情シスの特定のシステム管理者のみに限定
企業管理対象PJ作成権限の制限
高度なワークフロー作成は情シス管理グループへ集約
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4JMYGR3MJW.jpg)

3. 権限スキーマ：ロールとの役割倒錯を防ぐ集約設計
⚠️「公開範囲」でスキーマを分けない
「社内オープン用」「機密PJ用」など公開範囲ごとにスキーマを分け
ると、現場の「プロジェクトロール（配役）」と役割が倒錯し、1PJ1
スキーマ乱立の元凶になります。
あるべき設計: オープンか機密かの差分は、現場リードがロール
（Users等）に「全正社員グループ」を入れるか否かで吸収させ、
スキーマは共通化します。
© LOG Sprout G.K. All rights reserved.
既定ロールに対する「操作型」スキーマの設
計例
全社標準権限スキーマ（稼働中PJのほぼ全て）:
• Administrators: プロジェクト管理、バージョン・ロール設定
• Developers: 課題起票、編集、担当、ステータス進行、作業記録
• Users: 課題の閲覧、起票、コメント追加（日常のタスク参加）
アーカイブ用（読み取り専用）スキーマ:
利用終了したPJ用。現場のロール割り当て（Admin/Dev/User）は一
切変えず、スキーマ側で起票・編集・削除を剥奪し、全ロールに
「Browse Projects（閲覧権限）のみ」を付与して安全に凍結保存。
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/PJR9ZRQL79.jpg)

4. プロジェクトロール活用による情シスの問い合わせ削減
権限スキーマ内の操作権限は、個別のユーザー名ではなくすべて「プロジェクトロール」に対して付与します。
これにより、情シスへ「メンバー追加依頼」をする必要がなくなり、現場側で自走して運用を完結できます。
情シスの保守コスト削減 ✕ 現場の即応性を高める既定ロールの役割
管理者（Administrators）: 現場リード。自チームメンバーのロール割り当て権限を保有
開発・主担当（Developers）: 課題の起票・編集・ステータス更新・担当など主業務を遂行
一般利用者・閲覧者（Users / Viewers）: 課題の起票・進捗確認・コメント（誤操作や意図しない変更を防止）
© LOG Sprout G.K. All rights reserved.
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/PEXQ9RR6JX.jpg)

権限崩壊が招く最悪のシナリオ：シャドーIT化とナレッジ分断
誰がどこまで見えているか制御不能な状態へ
安易なオープン権限設定や移行時の乱立放置によりアクセス制御
が安全・安心に行えなくなると、社外秘・関係者外秘などの機微
情報を安心して扱えないプラットフォームへと一気に低下しま
す。
© LOG Sprout G.K. All rights reserved.
使い物にならないプラットフォーム化のリスク
アクセス権限が信用できない結果、現場各部門では
「個別に別ツール（スプレッドシート等）で管理したほうが
安全！」
という判断が下され、シャドーIT化が進み全社のナレッジが
分断・失われる原因になります。
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/3EK9PRRGED.jpg)

まとめ：健全な全社ナレッジ基盤を実現する権限設計
権限設計を整えてこそ、Jiraは全社の「強固な情報基盤」となる
1. スキーマとロールの役割を厳格に切り分け、スキーマの無秩序な量産を防ぐ
（公開範囲の差分は現場のロールで吸収し、スキーマは標準型やアーカイブ用など操作ルールの差分のみに集約）
2. 「IdP連携の全正社員グループ」と作成権限制御でガバナンスを効かせる
（横ぐし統制が効かないチーム管理対象PJの無秩序な増殖や、外部パートナー混入によるサイト切り直しの歪みを防止）
3. 企業規模に応じた設計で、社内ナレッジを広く扱えるIT基盤へ整備する
（終了PJのアーカイブ凍結運用など、情報が散逸せず自然と全社に蓄積・検索・共有される環境を実現）
© LOG Sprout G.K. All rights reserved.
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/L73WX88575.jpg)

ご清聴ありがとうございました。
© LOG Sprout G.K. All rights reserved.
12