権限空域ガバナンス:会社をチーム集合体として捉え、制限空域を与える

はじめに

国を会社とするなら、自治体はバックオフィスに最も近しい。両者に共通しているのはガバナンス機能であり、バックオフィス部門もガバナンスの向上が主要な目標と言える。

https://www.freee.co.jp/kb/kb-ipo/corporate_governance

corp-IT領域についてはID棚卸が含まれるだろう。それぞれのメンバーが持っているアカウントが適切かどうかを判定して、不適切な場合には是正しなければならない。では適切かどうかはどう判定するべきか？

https://otsukiblog.org/internal-control/itgc-introduction-id-inventory/#toc13

部署では表現できないケースがある。そこで部署と個人の間にチームという概念を導入して、チームと権限が完全一致するようにする。チームは部署の役割を保管するものであり、部署=チームであることが最も望ましい(とはいえそんな組織は見たことがないが...)。

チーム概要

Q	会社	チーム	個人
分割できるか？	不可	可能	不可
メンバー数は？	L	M	S(単一)
柔軟性は？	低	高	高

チーム例

雇用区分	職種	部署	役職	チーム名
正社員	-	-	代表取締役	社長
正社員	-	-	部長	部長
正社員	-	営業部	部長	営業部長
正社員	-	経理	マネージャー	経理マネージャー
正社員	-	情報システム	-	情シス
-	エンジニア職	-	-	エンジニア
正社員	-	-	-	社員
アルバイト	-	-	-	アルバイト

上の例のように、チームは以下要素によって主に決定する。

• 部署
• 役職(部長、マネージャーなど)
• 雇用区分(正社員、派遣社員、業務委託者など)
• 職種(ビジネス職、エンジニア職、デザイナーなど)

ただし、以下のような課題があるため「主に決定する」と前述した。

課題1 部署の中の細分化したチーム

権限は業務に紐づくべきだが、チームで業務が共通していない場合もある。勤怠システムの管理者は労務グループの中でも1名のみが持っている場合などがそれに当たる。そういった場合は個人名をチームに指定するしかない。

こういった個人指定の欠点は、異動があった場合に権限更新漏れが発生することだ。そのため非推奨だが、必要悪であるため禁止は技術的にできない。

課題2 各部に一人いる委員会

例えばコンプライアンス委員会のようなものがあるとして、それが各部から1名を選出する形とすると、そういったものは部門表で表現されない。

ただし、兼任という形をとり部門で表現されれば解決できる。可能であれば兼任案を取ることが望ましいが、人事システムの部門数は上限が決まっていることもある。

チームの権限

チームはそれぞれ権限上限(制限空域)を持つ

例

• [強制]経理チームは経費申請システムにて経理権限を持たなければならない
• [任意]社長チームはSlackでプライマリーオーナー以下を選択できる
• [任意]社員はSlackでメンバー以下を選択できる
• [禁止]営業チームはSalesforceの権限「一般_グループA」を付与してはならない(非推奨)
  • 禁止は権限の更新に対応できない

チームに権限上限を設定する理由

• 個人に権限を渡すと、アカウントが消えてしまった場合に再設定が必要となる。

権限の制限空域

チームは各SaaSの制限空域を設定する。

例

チーム	MF経費申請の権限上限	GWSの権限上限	kintoneの権限上限
エンジニア	任意_管理者	なし	なし
内部統制	任意_管理者	任意_管理者	任意_管理者
情シス	強制_管理者	強制_管理者	強制_管理者
開発部	-	-	任意_管理者
経理	強制_経理	-	任意_管理者
社員	-	任意_一般	任意_一般

権限高度の例(Slack)

1. プライマリーオーナー
2. オーナー
3. 管理者
4. メンバー
5. マルチチャンネルゲスト
6. シングルチャンネルゲスト

権限高度の例(経費システム)

1. オーナー
2. 管理者
3. 編集
4. 閲覧

• 高度を持たない
  • 経理権限

仕様

• 社員Aは社員チーム、開発部チームにいることがありうる。その場合kintoneの権限は「任意_一般」と「任意_管理者」を持つが、その際上位権限である「任意_管理者」が適用される。
• 各権限は高度を持つ。
  • 一部チームに特化した権限(経費システムにおける経理権限など)は高度を持たせない。これは任意指定の場合にその権限が選択されることを防ぐため

申請例

申請名	内容
チームへの追加申請	承認制。
チームの権限変更申請	承認制。
チーム作成申請	承認制。
アカウント申請	承認なし。ただし制限空域外であれば承認を設定する。

効果

• 制限空域以下であれば社内申請にて上長承認をスキップする。またはcorpIT側から予め付与できる。
• 制限空域から外れた申請については上長承認が入る。また、そのような申請は特に精査され、空域設定の見直しも検討する。

課題

• 権限のメンテナンス
  • その部署がもつ一時的な権限について、失われるタイミングを上長や担当者も判別できないケースがある

ゲームルール

権限空域ガバナンスの適用にはそれぞれのプレイヤーにルールが存在する。プレイヤーは

• corpIT
• メンバー

に分かれる。

corpITのルール

corpITは以下の責務を負う。

1. チームメンバーが0人にならないこと。0人になればチームの廃止、チーム適用条件の変更を検討する。
2. チーム内のメンバーが変わった際、制限空域に合わせて権限を変更または削除する。

シチュエーション

A:不完全な制限

権限が多岐にわたり、「営業部_マネージャー」「営業部_一般」のような権限指定されているケースでは全般的な高度指定ができず、また高度対象外にもできないかもしれない。
その場合は管理外にすることで解決するが、ガバナンスは低下する。

終わりに

オンボーディングとはよく言ったもので、onboardとは飛行機への搭乗を意味する。corpITにできることは権限を制約して、権限を付与することになる。空域を整えれば飛行機は新大陸へ羽ばたく。

https://www.youtube.com/watch?v=yvUTCz6eZ9Q