エンジニア主体で行った人と組織の情報管理自動化【DeNA TechCon 2021】/techcon2021-5

昨今、業務を効率化する様々なSaaSが増えてきていますが、社内で利用するSaaSが増えるたびにそのアカウント情報の管理工数が増えるため、社員数が多くなると積極的なSaaSの導入は難しくなる、という課題があります。

一方で、社員数が数千名を超えるDeNAでは社内システムとして積極的なSaaSの導入をしています。そこで管理の鍵となるのが入退社／異動等の人事イベントにともなう各システム内でのアカウント情報の管理の自動化です。(アカウント作成／削除／権限変更等)

本セッションでは、エンジニアが主体となり、すべてのシステムで利用するであろう人と組織の情報を管理し利用するために、どのように自動化の仕組みを構築しているのかをお話しします。

Transcript

1. Takaya Akasaka
2. • IT戦略部システム開発グループ • DeNA歴、8年 • 前職ではERPコンサルタント • 社内システム一筋、13年 • 私生活では3人（男子）の子育てに奮闘中
3. 社内システムのアカウント管理に対する考え方 • 人と組織からアカウントマスタ情報をどのように 生成しているか • アカウントマスタ情報をどのように、各社内シス テムに連携しているか
4. 1. 体制とミッション 2. 社内システム導入の考え方 3. アカウントマスタ管理の考え方 4. アカウント連携の考え方 5. 事例：人事評価システムへの連携 6. 事例：Google Workspaceへの連携
6. システム本部IT統括部 • IT基盤部 • IT戦略部 ◦ ユーザーサポートグループ ◦ 技術推進グループ ◦ 業務改革推進グループ ◦ システム開発グループ 正社員：5名 派遣社員：2名
7. グループウェア シングルサインオン Okta 汎用ワークフロー Kintone Web Meeting Zoom メール/カレンダー等 Google Workspace ファイルストレージ box チャット Slack サポートデスク SeviceDesk Plus メール共有 Mailwise 無人受付 Smart at 名刺管理 sansan その他 財務会計/人事 Netsuite 管理会計BI Tableau 勤怠管理/給与計算 ePay 経費精算 Concur 連結会計 Diva 人事BI QlikView 目標管理 Cydas KPI管理BI Looker 端末管理 端末管理(Win) LanScope Cat 端末管理(Mac) Jamf 携帯端末管理 Google Workspace 開発ソース管理 Github 開発案件管理 Jira 描画作成 Cacoo 社内Wiki Confluence タスク管理 Trello 基幹管理システム 開発管理
8. グループウェア シングルサインオン Okta 汎用ワークフロー Kintone Web Meeting Zoom メール/カレンダー等 Google Workspace ファイルストレージ box チャット Slack サポートデスク SeviceDesk Plus メール共有 Mailwise 無人受付 Smart at 名刺管理 sansan その他 財務会計/人事 Netsuite 管理会計BI Tableau 勤怠管理/給与計算 ePay 経費精算 Concur 連結会計 Diva 人事BI QlikView 目標管理 Cydas KPI管理BI Looker 端末管理 端末管理(Win) LanScope Cat 端末管理(Mac) Jamf 携帯端末管理 Google Workspace 開発ソース管理 Github 開発案件管理 Jira 描画作成 Cacoo 社内Wiki Confluence タスク管理 Trello 基幹管理システム 開発管理 「人と組織の情報管理」（アカウント管理）は 上記全てに通ずるテーマ
9. • SaaS/パッケージでは実現できない機能の開発 ◦ SaaS/パッケージ上でのアドオン開発 ◦ Webアプリケーション開発 • SaaS/パッケージ間を繋げる開発 社内システムの開発を外部委託せず、全て自部門において 実施しています。 今回はここ
10. 言語/フレームワーク • TypeScript / AngularJS, Express • Ruby / Ruby on Rails 実行環境 • Google App Engine（GCP） • Amazon EC2（AWS） フロントエンド/バックエンド、同じ人が実施しています。
12. 導入コストで考えるならとにかくSaaS • システム導入/拡大時のリードタイム抑制 • 従量課金という損しないモデル • グループ会社を通じてガバナンスも効かせやすい 早く、安く価値をユーザーに届ける
13. システム連携を行うためのAPIを備えていること どんなシステムもひとりでは生きられない
14. 機能はいいけど。。。 アカウント管理をどうする？ • 入社/退職 • 異動 • 組織変更 イベントが発生するごとに管理が必要
15. 有効/無効化だけではなく、部署/雇用形態によって システム権限を制限するケースが多い。 ⇒異動/組織変更のイベント対応が必須 例）会計システム 発注情報は発注を行う部門に所属する人のみが参照可能
16. 4月1日の入社/異動/組織変更のために、3月31日の 深夜に全システムに対してアカウント入力を行う悪 夢のような深夜作業が発生　⇒　地獄の月末
17. • 入社後すぐに必要なメールが送れない • 退職した人のアカウントが停止していない • 異動したのに前の部署の情報が閲覧できる • ワークフローの承認者が違う ごくごく基本なことだけにユーザーの信頼を失うこ とになる。
18. 入社/異動/組織変更イベントを自動的に連携する。 各システムのアカウント管理は手動で行わない。 ワークフロー システム 入退社/異動 組織変更申請 会計 システム 研修 システム
19. 入社/異動/組織変更イベントを自動的に連携する。 各システムのアカウント管理は手動で行わない。 ワークフロー システム アカウント 管理システム 会計 システム 研修 システム 入退社/異動 組織変更申請
21. • 人事発令（入退社/異動/組織変更申請）のデータを参照 • 履歴の形でデータ構築
22. 入退社/異動/組織変更申請からアカウントに必要な人と組 織の情報を抜き取って、DBに保持しておく。 入退社/異動 組織変更申請 アカウント 管理システム 人事システム 人事情報 連携システム アカウント マスタ 汎用ワークフロー Kintone 勤怠管理/給与計算 ePay
23. 人事情報の中でアカウント情報とするもの • 氏名　　　　赤坂宇哉 • 所属部署　　IT戦略部 • 雇用形態　　正社員 • 役職　　　　部長 DeNAでは上記の4つをアカウント情報として管理している
24. 氏名 所属部門 雇用形態 入社日 DeNA太郎 A部門 アルバイト 2020/01/01 氏名 所属部門 雇用形態 開始日 終了日 DeNA太郎 A部門 アルバイト 2020/01/01 2999/12/31 入社申請 アカウント マスタ
25. 氏名 所属部門 異動日 DeNA太郎 B部門 2020/04/01 氏名 所属部門 雇用形態 開始日 終了日 DeNA太郎 A部門 アルバイト 2020/01/01 2020/03/31 DeNA太郎 B部門 アルバイト 2020/04/01 2999/12/31 異動申請 アカウント マスタ
26. 氏名 雇用形態 雇用形態変更日 DeNA太郎 正社員 2020/06/01 氏名 所属部門 雇用形態 開始日 終了日 DeNA太郎 A部門 アルバイト 2020/01/01 2020/03/31 DeNA太郎 B部門 アルバイト 2020/04/01 2020/05/31 DeNA太郎 B部門 正社員 2020/06/01 2999/12/31 雇用形態 変更申請 アカウント マスタ
27. 氏名 退職日 DeNA太郎 2020/12/31 氏名 所属部門 雇用形態 開始日 終了日 DeNA太郎 A部門 アルバイト 2020/01/01 2020/03/31 DeNA太郎 B部門 アルバイト 2020/04/01 2020/05/31 DeNA太郎 B部門 正社員 2020/06/01 2020/12/31 退職 申請 アカウント マスタ
28. 雇用形態情報 所属部署情報
29. 所属部署と雇用形態は日付によって変更が発生する。 履歴によって管理することによって、未来のデータを管 理/連携出来るようになる。 氏名 所属部門 雇用形態 開始日 終了日 DeNA太郎 A部門 アルバイト 2020/01/01 2020/03/31 DeNA太郎 B部門 正社員 2020/04/01 2999/12/31
30. 氏名 所属部門 雇用形態 開始日 終了日 DeNA太郎 A部門 アルバイト 2020/01/01 2020/03/31 DeNA太郎 B部門 正社員 2020/04/01 2999/12/31 氏名 所属部門 雇用形態 DeNA太郎 A部門 アルバイト アカウント管理システム 連携対象システム 3月31日
31. 氏名 所属部門 雇用形態 開始日 終了日 DeNA太郎 A部門 アルバイト 2020/01/01 2020/03/31 DeNA太郎 B部門 正社員 2020/04/01 2999/12/31 氏名 所属部門 雇用形態 DeNA太郎 B部門 正社員 アカウント管理システム 連携対象システム 4月1日
32. アカウント情報をAPIで提供している。 APIによって提供したアカウント情報により、社内システ ム部門が管理しているシステム以外のアカウント管理に利 用することが出来る。 アカウント 管理システム XXX システム 社内システム部門管理外 アカウント情報 取得API
35. • 組織/承認ルートを含む複雑な連携は、アカウント連携 基盤上において開発
36. Active Directory Okta アカウント 管理システム Google Workspace Slack Zoom 評価システム 会計システム 名刺管理 システム ・ ・ ・ ・ ・ ・ ・ ・ 複雑性高い （組織/承認ルート） 複雑性低い （有効/無効）
37. Active Directory Okta アカウント 管理システム Google Workspace Slack Zoom 評価システム 会計システム 名刺管理 システム ・ ・ ・ ・ ・ ・ ・ ・ 複雑性低い （有効/無効） パッケージ IDaaS活用
38. 各システムと連携してアカウントプロビジョニング（アカ ウント作成）が出来る仕組み • Active Directory • Okta(IDaaS：Identity as a Service) アカウント管理システムから上記のシステムにアカウント 情報を連携した後に、各システムにプロビジョニング
39. ノーコードで連携できるのは嬉しい！
40. しかし 所属部署や承認ルートを含む複雑な連携は不可 ⇒　なければ作るしかない！
41. Active Directory Okta アカウント 管理システム Google Workspace Slack Zoom 評価システム 会計システム 名刺管理 システム ・ ・ ・ ・ ・ ・ ・ ・ 複雑性高い （組織/承認ルート） アカウント 連携基盤
42. 連携基盤を構築し連携を増やす際には、各システムへの繋 の部分にフォーカス出来る状態にする。 メリット • 構築工数の削減 • 引継工数の削減 • 共通化部品の品質向上 アカウント連携基盤 連携 Func 連携 Func 連携 Func 連携 Func 連携 Func Jenkins Node.js
43. 連携結果はGUIで確認出来るようにする。 Jenkinsを可視化に利用している。 メリット エンジニア以外でも • 結果確認可能 • 再実行可能
44. アカウント連携基盤上で構築するとしても、各システムへ の連携を行う部分は個別に作成することになる。 本番一発でプログラム構築を行うのは怖い。。。 テスト環境を準備してくれる、SaaS/パッケージベンダー を選ぶことが重要となる。
46. 評価システム上の承認ルートは多段の設定になっている。 異動/組織変更の際の承認ルート修正工数が大きく、一日 がかりでメンテナンスしている。 A部門 B部門 C部門 D部門 E部門 F部門 G部門 構築される承認ルート B部門上長 A部門上長 A部門上長 C部門上長 A部門上長 B部門上長 A部門上長 B部門上長 A部門上長 D部門上長 E部門上長 C部門上長 A部門上長 C部門上長 A部門上長 F部門上長 G部門上長 部門階層
47. A部門の上長が変わるとA部門を上位部門にもつ部門に所 属する従業員の承認ルートが全て変更になる。 B部門上長 A部門上長 A部門上長 C部門上長 A部門上長 B部門上長 A部門上長 B部門上長 A部門上長 D部門上長 E部門上長 C部門上長 A部門上長 C部門上長 A部門上長 F部門上長 G部門上長 変 変 変 変 変 変 変 構築される承認ルート
48. アカウント管理システム情報を利用して承認ルート連携 • 承認ルートは組織マスタから • 各従業員の所属情報はアカウントマスタから • 連携はアカウント連携基盤を利用してAPI連携 アカウント マスタ 組織 マスタ アカウント 管理システム 承認 ルート 評価 システム API Call
49. 評価システム上の承認ルートは多段の設定になっている。 異動/組織変更の際の承認ルート修正工数が大きく、一日 がかりでメンテナンスしている。 月次で発生していた一日作業がなくなった！ 設定漏れ等による承認ルートの間違えもない！
51. 部門ごとのGoogleGroupがあると便利だな • メールの送信 • カレンダーの招待 • ドキュメントの権限付与 各部門の担当者で実施するのは大変 • 抜け漏れが発生 • そもそもそんな工数ない
52. 上位部門のグループにも所属するので、異動/組織変更の 際のメンテナンス対象のグループが膨大になる。 A部門 B部門 C部門 D部門 E部門 F部門 G部門 D部門所属のDeNA太郎の所属グループ D部門グループ B部門のグループ A部門のグループ
53. さらに 雇用形態別にも分けているためGoogleGroupを手動メンテ ナンスするのは現実的に不可能 例） 　A部門の全員グループ/A部門の正社員グループ　等々 所属部門　×　雇用形態
54. アカウント管理システム情報を利用してGoogleGroup連携 • グループは組織マスタから • グループの所属情報はアカウントマスタから • 連携はアカウント連携基盤を利用してAPI連携 アカウント マスタ 組織 マスタ アカウント 管理システム Google Group Google Workspace API Call
55. 部門ごとのGoogleGroupがあると便利 しかし各部門の担当者で実施するのは大変 • 抜け漏れが発生 • そもそもそんな工数ない 全部門のGoogleGroupが出来た！
56. アカウント管理 • 人事発令（入退社/異動/組織変更申請）のデータを参照 • 履歴の形でデータ構築 アカウント連携 • 組織/承認ルートを含む複雑な連携は、アカウント連携基盤上 において開発