LOG Sprout Jira権限設計ガイド プレゼンテーション

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

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

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

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

権限レイヤー結合図：操作型スキーマと現場ロールの分担 🏢 情シス（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

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

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

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

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

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

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

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