権限空域ガバナンス:会社をチーム集合体として捉え、制限空域を与える
はじめに
国を会社とするなら、自治体はバックオフィスに最も近しい。両者に共通しているのはガバナンス機能であり、バックオフィス部門もガバナンスの向上が主要な目標と言える。
corp-IT領域についてはID棚卸が含まれるだろう。それぞれのメンバーが持っているアカウントが適切かどうかを判定して、不適切な場合には是正しなければならない。では適切かどうかはどう判定するべきか？
部署では表現できないケースがある。そこで部署と個人の間にチームという概念を導入して、チームと権限が完全一致するようにする。チームは部署の役割を保管するものであり、部署=チームであることが最も望ましい(とはいえそんな組織は見たことがないが...)。
チーム概要
| Q | 会社 | チーム | 個人 |
|---|---|---|---|
| 分割できるか？ | 不可 | 可能 | 不可 |
| メンバー数は？ | L | M | S(単一) |
| 柔軟性は？ | 低 | 高 | 高 |
チーム例
| 雇用区分 | 職種 | 部署 | 役職 | チーム名 |
|---|---|---|---|---|
| 正社員 | - | - | 代表取締役 | 社長 |
| 正社員 | - | - | 部長 | 部長 |
| 正社員 | - | 営業部 | 部長 | 営業部長 |
| 正社員 | - | 経理 | マネージャー | 経理マネージャー |
| 正社員 | - | 情報システム | - | 情シス |
| - | エンジニア職 | - | - | エンジニア |
| 正社員 | - | - | - | 社員 |
| アルバイト | - | - | - | アルバイト |
上の例のように、チームは以下要素によって主に決定する。
- 部署
- 役職(部長、マネージャーなど)
- 雇用区分(正社員、派遣社員、業務委託者など)
- 職種(ビジネス職、エンジニア職、デザイナーなど)
ただし、以下のような課題があるため「主に決定する」と前述した。
課題1 部署の中の細分化したチーム
権限は業務に紐づくべきだが、チームで業務が共通していない場合もある。勤怠システムの管理者は労務グループの中でも1名のみが持っている場合などがそれに当たる。そういった場合は個人名をチームに指定するしかない。
こういった個人指定の欠点は、異動があった場合に権限更新漏れが発生することだ。そのため非推奨だが、必要悪であるため禁止は技術的にできない。
課題2 各部に一人いる委員会
例えばコンプライアンス委員会のようなものがあるとして、それが各部から1名を選出する形とすると、そういったものは部門表で表現されない。
ただし、兼任という形をとり部門で表現されれば解決できる。可能であれば兼任案を取ることが望ましいが、人事システムの部門数は上限が決まっていることもある。
チームの権限
チームはそれぞれ権限上限(制限空域)を持つ
例
- [強制]経理チームは経費申請システムにて経理権限を持たなければならない
- [任意]社長チームはSlackでプライマリーオーナー以下を選択できる
- [任意]社員はSlackでメンバー以下を選択できる
- [禁止]営業チームはSalesforceの権限「一般_グループA」を付与してはならない(非推奨)
- 禁止は権限の更新に対応できない
チームに権限上限を設定する理由
- 個人に権限を渡すと、アカウントが消えてしまった場合に再設定が必要となる。
権限の制限空域
チームは各SaaSの制限空域を設定する。
例
| チーム | MF経費申請の権限上限 | GWSの権限上限 | kintoneの権限上限 |
|---|---|---|---|
| エンジニア | 任意_管理者 | なし | なし |
| 内部統制 | 任意_管理者 | 任意_管理者 | 任意_管理者 |
| 情シス | 強制_管理者 | 強制_管理者 | 強制_管理者 |
| 開発部 | - | - | 任意_管理者 |
| 経理 | 強制_経理 | - | 任意_管理者 |
| 社員 | - | 任意_一般 | 任意_一般 |
権限高度の例(Slack)
- プライマリーオーナー
- オーナー
- 管理者
- メンバー
- マルチチャンネルゲスト
- シングルチャンネルゲスト
権限高度の例(経費システム)
- オーナー
- 管理者
- 編集
- 閲覧
- 高度を持たない
- 経理権限
仕様
- 社員Aは社員チーム、開発部チームにいることがありうる。その場合kintoneの権限は「任意_一般」と「任意_管理者」を持つが、その際上位権限である「任意_管理者」が適用される。
- 各権限は高度を持つ。
- 一部チームに特化した権限(経費システムにおける経理権限など)は高度を持たせない。これは任意指定の場合にその権限が選択されることを防ぐため
申請例
| 申請名 | 内容 |
|---|---|
| チームへの追加申請 | 承認制。 |
| チームの権限変更申請 | 承認制。 |
| チーム作成申請 | 承認制。 |
| アカウント申請 | 承認なし。ただし制限空域外であれば承認を設定する。 |
効果
- 制限空域以下であれば社内申請にて上長承認をスキップする。またはcorpIT側から予め付与できる。
- 制限空域から外れた申請については上長承認が入る。また、そのような申請は特に精査され、空域設定の見直しも検討する。
課題
- 権限のメンテナンス
- その部署がもつ一時的な権限について、失われるタイミングを上長や担当者も判別できないケースがある
ゲームルール
権限空域ガバナンスの適用にはそれぞれのプレイヤーにルールが存在する。プレイヤーは
- corpIT
- メンバー
に分かれる。
corpITのルール
corpITは以下の責務を負う。
- チームメンバーが0人にならないこと。0人になればチームの廃止、チーム適用条件の変更を検討する。
- チーム内のメンバーが変わった際、制限空域に合わせて権限を変更または削除する。
シチュエーション
A:不完全な制限
権限が多岐にわたり、「営業部_マネージャー」「営業部_一般」のような権限指定されているケースでは全般的な高度指定ができず、また高度対象外にもできないかもしれない。
その場合は管理外にすることで解決するが、ガバナンスは低下する。
終わりに
オンボーディングとはよく言ったもので、onboardとは飛行機への搭乗を意味する。corpITにできることは権限を制約して、権限を付与することになる。空域を整えれば飛行機は新大陸へ羽ばたく。
Discussion