はじめに
自社製品のプロジェクト管理で生産性を極限まで追求した結果、Jira と Confluence を活用したプロジェクト管理に落ち着いた。生産性抜群なチームがこれらのツールをどうやって使っているか簡単に紹介したい。
最初に名前あり
Jira と Confluence は各種権限やフィルター、ダッシュボードのようにテナント全体のグローバルな名前空間に展開されるリソースがまずあり、それらと個別のプロジェクト（Confluence であればスペース）のリソースが結びついて機能する。リソースは簡単に作れるため、すぐに乱立して管理不能なカオスな状態に陥る。例えば次のような感じだ。
プロジェクト一覧
- 製品A開発
- 製品A-T様向け拡張
- 製品A-D様向け拡張
- 製品A-T様向けサービスデスク
- 製品A-D様向けサービスデスク
- 製品A次世代版開発
- マーケティング
- リード管理
- 社内開発基盤管理
- チームX
- チームY
- チームZ
こうなると管理が大変だし、情報が散逸したり重複したり、とにかくプロジェクト管理に支障が出る。上記はプロジェクト名の例だが、Jira であればプロジェクト作成時にバックグラウンドで自動的に各種権限といったグローバルなリソースが大量に作成されてカオスになる。
リソースに一定の秩序を与えて、定期的な棚卸しやセキュリティチェックを容易にするためには、次のルールを適用する。
- プロジェクトは以下ののように「ドメインをひっくり返したもの / やること」のルールで名付ける
- com.example.www/development
- com.example.www/external-service-desk
- com.example.www/sales
- ドメインは自分たちが取得して利用できるものにする
- Jira のプロジェクトと、Confluence のスペースは必ず同じ名前のものをペアで作成する
- 各種権限やリソースは一部の例外を除き、個別のプロジェクトに紐づく形で作成し、プロジェクト間で共有しない
- com.example.www/development/filter.all
- com.example.www/development/filter.unresolved
- com.example.www/development/board.kanban
- com.example.www/development/board.scrum
- com.example.www/development/dashboard.project-health
- com.example.www/development/issue-type-scheme.default
- com.example.www/external-service-desk/filter.all
- com.example.www/external-service-desk/filter.unresolved
一部の例外としてグローバルに作成するリソースは次の通り。いずれもプロジェクトごとに個別に設定するより全体で共通化した方がよいもの。これらのリソースは一度追加すると変更や削除が難しいため、既存の体系を壊さないように注意深く拡張する。
* Issue type
* Sub-task
* Custom field
* Time tracking
* Issue linking
* Status
* Resolution
* Priority
プロジェクト名とスペース名のルールを統一するだけでも、ずいぶんわかりやすくなる。各種リソースを個別のプロジェクトに紐づくものと全体に適用する汎用的なものに分けて運用することで、プロジェクトごとに権限やフィルターをカスタマイズするときに影響範囲をそのプロジェクトにのみ限定できるので一般ユーザーが気軽に自分のプロジェクトに対して試行錯誤できるようになる。
# グループ名を活用したアクセス制御
Atlassian は単一アカウントで複数のリソースを利用できるが、各アカウントごとに個々のリソースへのアクセス権限を割り当てると管理が煩雑になる。そこでアカウントをグループにまとめ、グループごとに一括して設定する。イメージは Role-based access control (RBAC) と同じ。個々のアカウントは複数のグループに所属できる (N対N)。リソースはプロジェクトや権限 (Permission scheme) のことであり、Atlassian のグループはこれらのリソースにいい感じに割り当てることができる。グループと似たような機能にロールがあるが使いにくいので使っていない。
アカウント ⇔ グループ ⇒ リソース
※アカウントとリソースを直接紐づけず、必ずグループを介するのがポイント
当然、グループ名もテナント全体のグローバルな名前空間に展開されるリソースであるので、命名規則を導入する。グループはサブジェクトであり、オブジェクト（対象）であるリソースとはカテゴリが違うので、リソースとは異なる命名規則にしている。
- example:aa-administrator
- example:aa-developer
- example:aa-guest
- example:ab-administrator
- example:ab-designer
- example:ab-engineer
aa- と付いているのはグループ名の世代管理をするため。一度作成したリソースはポカミスなどを除けば変更したくない＝イミュータブルにしたいので、ab-、ac- のように名前にバージョンを付けて新規登録のみで運用している。イミュータブルにこだわらなければ aa- は名前から取り除いてもいい。
ちなみにサブジェクトはユーザー、グループなどのリソース、オブジェクトはプロジェクト、スペース、フィルターなどのリソース、アクションは作成、変更、削除などである。
上記のルールを適用することで、運用は大変だが影響範囲が常に狭くなるため、考えることが少なくなる。ひとつのテナントに協力会社を含む大量のアカウントを突っ込んでも、アクセスを許可したいリソースをピンポイントで指定して、それ以外は隠してアクセスできないようにする、といった運用が簡単に柔軟に実行できる。
あとは、グループ名ごとに Permission scheme や Space permissions を細かく設定し、人の入れ替わりがあればグループへ追加・削除すれば、自在なアクセス制御が可能だ。特にワークフローとカスタムフィールドの設定が熱い。
5年運用してみて
実は運用開始から一箇所だけ変更したルールがあった。グループ名の付け方だ。最初は iam:group/com.example/aa-guest のように URN 風の命名規則になっていた。これはもともと、アクセス権限の設定のときにグループやロールを名称で検索するので、それぞれで重複しないユニークな名称をつけようとして iam:group や iam:role といった接頭辞を付けたのだが、グループ名しか使わないから無駄だと気づいて example:aa-guest のような簡単な名前にした。それ以外は最初の運用開始時に設定したルールから変更せずに安定した運用ができている。いまでは Jira と Confluence なしで複数の大規模プロジェクトを管理することは考えられない。
あとがき
最初はもっと簡単なネタを書こうと思ってました。例えば Confluence は子ページを目次として表示する機能があるので、うまく構成するとマウスぐりぐりで自在にアウトラインを編集できるアウトラインエディタになる、アウトラインエディタは思索のための強力なツールだ、といった内容です。でも結局、Atlassian 製品を大規模環境で本格的に運用するためには、柔軟かつ強力なアクセス制御が必要で、それを実現するためには上記のノウハウが必須になるため、一番大事なところを書いてみました。
最後に上記のノウハウを適用するメリットをもう一つ挙げると、運用コストが安くなります。強力なアクセス制御ができる運用ルールを導入するおかげで、協力会社もお客様環境もすべてひとつのテナントに放り込むことができます。重複したライセンスがないので費用対効果を最大限にまで高められます。使えば使うほど安価に感じるツールです。