こちらはAtlassian（Jira , Confuence, Trello, Bitbucket）のTips紹介 Advent Calendar 2018の22日目の記事です。

はじめに

JIRA/Confluenceを運用していてこんな状況に陥ったことはないでしょうか？

新しい人にAプロジェクトの閲覧権限を付けたいんだけど、どのグループに入れれば見れるようになるかわからない。

とか

JIRAが不安定になってると思って管理画面見たら見知らぬアドオンが！
誰かが勝手にインストールしたみたい。

とか。

これらは、JIRA/Confluenceの管理権限設計が適当な状態でアカウント運用をした結果、生じてしまいがちな事象です。

JIRA/Confluenceの管理画面はお世辞に言ってもどこをどうすればいいか、初見ではわからないと思います、メニューだらけで。
その結果、プロジェクトやアカウントの権限設定がいいかげんになってしまい、上記のような状況に陥るのだと思います。

私はJIRAやConfluenceを使い始めてもう5年以上経ちます。Admin業務をやるようになったのは今から3年くらい前ですが、まさかJIRAの管理画面がそんな状況になってるなんて知りませんでした。
これはちゃんと設計しないと大変なことになるな、とも思いました。

それから3年経ち、大分権限設計の方向性が定まってきました。
こちらの記事ではJIRA/Confluenceの管理権限の設計思想についてまとめたいと思います。

CPE観点での権限設計

CPEについてはこちらのマガジン「社内ITのデザイン帖」で以前投稿しました以下の記事を参考にしていただければと思います。

CPEの観点で社内ITツールの権限を設計する際に重要なことは、以下の2つだと思っています。

・メンバーが自主的にプロジェクト管理できるように、現場の管理者に強めの権限を付与すること

管理者が全部の管理権限を掌握する設計だと、現場のニーズを拾いきれず、便利な機能がすぐ使えない→いちいち管理者に確認を取らないといけない→時間の無駄。
その結果、生産性が下がるということにつながると考えます。

古い情シスの考え方だとこのような設計にしがちですが、CPEは生産性を上げるのがミッションなので、プロジェクトの管理権限を現場に移譲する形で「プロジェクト管理者」を設定するようにしています。
現場の判断で自律的にプロジェクト管理できるようにすることが、生産性向上につながると考えるからです。

もう一つは

・申請内容の作業を迅速に行えるように、命名規則や権限などルール化しておくこと

もうちょっと具体的に言いますと、グループ名を見ただけで、どこのプロジェクトに権限付与されるというのがわかるような状態にしておくべき、ということです。
そうすることで、新たに入社されたメンバーに対し、迅速に必要な権限を付与でき、アイドルする時間がないようにする「オンボーディングの改善」という狙いと、メンバーに対し適切な権限を付与することで、誤って強すぎる権限を付与し事故につながるようなことを防ぐ、という2つの狙いがあります。

この辺の考え方は情報デザインの考え方そのままです。社内ITにIAの知見が必要という一つの例だと思います。

JIRA/Confluecneのどこの設定を変えればいいの？

上記の考え方で権限設計する際に設定する場所ですが、画面が散らばっていて影響関係も非常にわかりにくいです。

まず、大前提として知っておかないといけないのが

Confluenceのアカウントやグループ設定は「JIRAを参照」している

ということです。ですので基本的にはJIRA側で作業します。
ただし、Confluenceのスペースの権限設定はConfluence側での設定になるので注意です…

以下が作業の大まかな流れになります。

１，JIRAでグループ設定をする

これがまず出発点になります。次に、

２,グローバルパーミッションを設定する

これは初回だけ設定すれば良いように設計します。
プロジェクト追加するたびに編集するような設定は絶対にやめましょう。運用が煩雑になってしまいます。

3,パーミッションスキームを設定する

こちらも1回だけ設定すればすむようにしておきます。
プロジェクトの運用方法によって、スキーム設定を追加しないといけないケースもあると思いますが…。

JIRAにはデフォルトでAdministrators、Developers、Usersという３つのロールが設定されていて、パーミッションスキームの画面でそれぞれのロールが扱える権限を設定する、という構成になっています。

ロールだけではなくグループやアカウントに対しても権限を設定できますが、運用がカオスになるので私は絶対にやりません。
どうカオスになるかといいますと…

・「パーミッションスキーム画面」と「ユーザーとロール画面」の2箇所でグループと権限を紐づけてしまうと、設定画面がバラけて管理が煩雑になる。

管理はシンプルにしたほうが良いです。
パーミッションスキームでグループを紐づけてしまうと、なんでこのグループは他のプロジェクト閲覧できるんだろう？と悩むことになります。

４，各JIRAプロジェクトのユーザーとロールを設定する

各プロジェクトに上記のパーミッションスキームをセットしたあと「ユーザーとロール」の画面でロールとグループ（ユーザー）の紐付をします。

Confluenceスペースも利用する場合は、コンフルの権限ページで

5,個々の（JIRAで設定した）グループごとに権限を設定する

だけでOKです。
Confluenceはグループに対して直接権限を設定できるので非常にシンプル。
グループ設計を間違わなければまず迷うことはないでしょう。

全体の流れを把握したところで、個々の設定について見ていきましょう。

STEP1:JIRAでグループ設定する

以下の3つのグループに大きく分けます。

・JIRA管理者グループ（デフォルトで存在してます）
・プロジェクト管理者グループ
・プロジェクト利用者グループ

JIRA管理者グループにはアカウント管理業務を行うメンバーや契約オーナーなどのアカウントが所属します。重要なのはここにプロジェクト管理者を含めない、ということです。

次に、プロジェクト管理者グループを作ります。個々のプロジェクトごとに管理者グループを作るほか、プロジェクト管理者オールのグループも作る必要があります。名前は以下のようにするとわかり良いと思います。

・project-adminグループ（プロジェクト管理者オール）
・***-adminグループ（個々のプロジェクト管理グループ）
　※***にプロジェクト名あるいは接頭辞が入るイメージ

何故projrct-adminグループが必要になってくるのかは、次のグローバルパーミッションが影響しています。

最後に利用者グループですが、これも利用者オールと個々のプロジェクト利用者のグループを作っておくと良いです。
利用者オールは、アカウント追加時にデフォルトで参加するグループとして「jira-users」がデフォルトで設定されているので特に何もしなくていいです。個々のプロジェクト利用者グループは以下のように設定するとわかり良いと思います。

・***-usersグループ（個々のプロジェクト利用者グループ）
　※***にプロジェクト名あるいは接頭辞が入るイメージ

図にまとめるとこんな感じになります。

STEP2:グローバルパーミッションを設定する

グローバルパーミッションの画面は、システム＞グローバルパーミッションでアクセスできます。ここで設定するのは以下の項目です。

・JIRAシステム管理者
・JIRA管理者
・ユーザーの参照
・共有オブジェクトの作成
・グループフィルターの配信登録管理
・一括変更

JIRAのアカウント管理に関わってくるのは

・JIRAシステム管理者
・JIRA管理者

プロジェクト管理に関わってくるのは

・共有オブジェクトの作成：フィルターの共有設定
・グループフィルターの配信登録管理：課題フィルターの配信範囲設定
・一括変更：複数課題の同時変更

利用者全員に付与すべきなのは

・ユーザーの参照：他のユーザーにメンション送ったりするのに使う権限

という感じで、グローバルパーミッションの権限を設定しています。
一部プロジェクト管理でくくった権限を利用者全員に開放してもいいと思いますが、このあたりは利用者ニーズ次第かなと思っています。

プロジェクトが追加されるたびに、グローバルパーミッションにプロジェクト管理グループを追加するのは作業が煩雑になってしまうので、プロジェクト管理者オールのグループproject-adminを作っておくと、運用が少し楽になります。

STEP3:パーミッションスキームを設定する

JIRAの権限設計の肝とも言える「パーミッションスキーム」。JIRAは初期設定の状態でDefault permission schemeがセットされています。これを改良する形で設定するのがいいと思います。

設定画面は、システム＞課題＞パーミッションスキームからDefault permission schemeを選択して下さい。システムページから直に行けないので迷いがちなので気をつけましょう。

パーミッションスキームをどのように設定するかですが、利用環境に左右されると思いますので、絶対これでやりましょうというものはないと思います。
大まかな方向性として

・Administratorsはプロジェクト管理者が使う機能
・Developersはプロジェクト利用者が使う機能
・Usersはjira-userに開放する機能

という観点で権限設計をしています。
例えば一番上にある「プロジェクトの管理」は拡張プロジェクト管理にチェックを入れてAdministratorsロールをセットします。ただDeveloperロールもセットするニーズはあると思いますので、利用者にヒアリングしてそのあたりは設定するのが良いと思います。

「プロジェクトの閲覧」はAdministratorsロールとDeveloperロールをセットします。プロジェクト参加者じゃないJIRAユーザーにも閲覧権限を付与したい場合はUsersロールもセットすればいいと思います。

STEP4:各プロジェクトのユーザーとロールを設定する

ここまで準備すれば、あとは簡単です。各プロジェクトのプロジェクト設定＞ユーザーとロールからAdministrators、Developers、Usersそれぞれのロールに、プロジェクトのグループを紐づけするだけです。

JIRAプロジェクトを追加する運用の際は、以下のことをする感じになります。

・プロジェクトのグループを作る、管理者と利用者。
・プロジェクト管理者をプロジェクト管理者グループに追加する。
・プロジェクトのユーザーとロールでロールにグループを紐づけする。

このように設計することで、運用の手間を減らしつつ、権限設計がカオスにならないように運用できるのだと思います。

STEP5:コンフルスペースの権限を設定する

ConfluenceはJIRAのグループとアカウントを参照しています。なので、STEP1で作ったグループをそのまま使います。
スペースツール＞権限のページにアクセスし、プロジェクトのグループを追加して、それぞれ利用可能にしたい権限をチェックして保存するだけです。

おわりに

IAの情報設計の設計思想において、利用者がアクセスしやすいラベリングやナビゲーションを設計するという「ユーザビリティ」や「ファインダビリティ」の観点があります。
また、設計したものが運用中に壊れないようにする「メンテナンシビリティ」という観点もあります。

今回ご紹介した考え方はメンテナンシビリティとファインダビリティを重視した権限設計の手法でした。
社内ITのデザインってなるほどこういうことなのね、と感じていただければ幸いですし、IAの方が興味を持って社内ITを改善していく流れが作れていくといいなと期待しています。

以上JIRA/Confluenceをベースに権限設計の方法論をまとめてきました。
こういった考え方は他のツールにおいても同様だと思っています。
ただ、ツール側の管理機能との兼ね合いでなかなか綺麗に設計できないことも多いです。

こういったことでお悩みの方いらっしゃいましたら、弊社の副業制度の範囲内でお手伝いさせていただければと思いますので、以下のメールまでご連絡下さい。

yoshioka.cpe@gmail.com