Tweet
Tweet

Slide 1

Slide 1 text

Takaya Akasaka

Slide 2

Slide 2 text

● IT戦略部システム開発グループ ● DeNA歴、8年 ● 前職ではERPコンサルタント ● 社内システム一筋、13年 ● 私生活では3人（男子）の子育てに奮闘中

Slide 3

Slide 3 text

社内システムのアカウント管理に対する考え方 ● 人と組織からアカウントマスタ情報をどのように 生成しているか ● アカウントマスタ情報をどのように、各社内シス テムに連携しているか

Slide 4

Slide 4 text

1. 体制とミッション 2. 社内システム導入の考え方 3. アカウントマスタ管理の考え方 4. アカウント連携の考え方 5. 事例：人事評価システムへの連携 6. 事例：Google Workspaceへの連携

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

システム本部IT統括部 ● IT基盤部 ● IT戦略部 ○ ユーザーサポートグループ ○ 技術推進グループ ○ 業務改革推進グループ ○ システム開発グループ 正社員：5名 派遣社員：2名

Slide 7

Slide 7 text

グループウェア シングルサインオン 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 基幹管理システム 開発管理

Slide 8

Slide 8 text

グループウェア シングルサインオン 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 基幹管理システム 開発管理 「人と組織の情報管理」（アカウント管理）は 上記全てに通ずるテーマ

Slide 9

Slide 9 text

● SaaS/パッケージでは実現できない機能の開発 ○ SaaS/パッケージ上でのアドオン開発 ○ Webアプリケーション開発 ● SaaS/パッケージ間を繋げる開発 社内システムの開発を外部委託せず、全て自部門において 実施しています。 今回はここ

Slide 10

Slide 10 text

言語/フレームワーク ● TypeScript / AngularJS, Express ● Ruby / Ruby on Rails 実行環境 ● Google App Engine（GCP） ● Amazon EC2（AWS） フロントエンド/バックエンド、同じ人が実施しています。

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

導入コストで考えるならとにかくSaaS ● システム導入/拡大時のリードタイム抑制 ● 従量課金という損しないモデル ● グループ会社を通じてガバナンスも効かせやすい 早く、安く価値をユーザーに届ける

Slide 13

Slide 13 text

システム連携を行うためのAPIを備えていること どんなシステムもひとりでは生きられない

Slide 14

Slide 14 text

機能はいいけど。。。 アカウント管理をどうする？ ● 入社/退職 ● 異動 ● 組織変更 イベントが発生するごとに管理が必要

Slide 15

Slide 15 text

有効/無効化だけではなく、部署/雇用形態によって システム権限を制限するケースが多い。 ⇒異動/組織変更のイベント対応が必須 例）会計システム 発注情報は発注を行う部門に所属する人のみが参照可能

Slide 16

Slide 16 text

4月1日の入社/異動/組織変更のために、3月31日の 深夜に全システムに対してアカウント入力を行う悪 夢のような深夜作業が発生　⇒　地獄の月末

Slide 17

Slide 17 text

● 入社後すぐに必要なメールが送れない ● 退職した人のアカウントが停止していない ● 異動したのに前の部署の情報が閲覧できる ● ワークフローの承認者が違う ごくごく基本なことだけにユーザーの信頼を失うこ とになる。

Slide 18

Slide 18 text

入社/異動/組織変更イベントを自動的に連携する。 各システムのアカウント管理は手動で行わない。 ワークフロー システム 入退社/異動 組織変更申請 会計 システム 研修 システム

Slide 19

Slide 19 text

入社/異動/組織変更イベントを自動的に連携する。 各システムのアカウント管理は手動で行わない。 ワークフロー システム アカウント 管理システム 会計 システム 研修 システム 入退社/異動 組織変更申請

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

● 人事発令（入退社/異動/組織変更申請）のデータを参照 ● 履歴の形でデータ構築

Slide 22

Slide 22 text

入退社/異動/組織変更申請からアカウントに必要な人と組 織の情報を抜き取って、DBに保持しておく。 入退社/異動 組織変更申請 アカウント 管理システム 人事システム 人事情報 連携システム アカウント マスタ 汎用ワークフロー Kintone 勤怠管理/給与計算 ePay

Slide 23

Slide 23 text

人事情報の中でアカウント情報とするもの ● 氏名　　　　赤坂宇哉 ● 所属部署　　IT戦略部 ● 雇用形態　　正社員 ● 役職　　　　部長 DeNAでは上記の4つをアカウント情報として管理している

Slide 24

Slide 24 text

氏名 所属部門 雇用形態 入社日 DeNA太郎 A部門 アルバイト 2020/01/01 氏名 所属部門 雇用形態 開始日 終了日 DeNA太郎 A部門 アルバイト 2020/01/01 2999/12/31 入社申請 アカウント マスタ

Slide 25

Slide 25 text

氏名 所属部門 異動日 DeNA太郎 B部門 2020/04/01 氏名 所属部門 雇用形態 開始日 終了日 DeNA太郎 A部門 アルバイト 2020/01/01 2020/03/31 DeNA太郎 B部門 アルバイト 2020/04/01 2999/12/31 異動申請 アカウント マスタ

Slide 26

Slide 26 text

氏名 雇用形態 雇用形態変更日 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 雇用形態 変更申請 アカウント マスタ

Slide 27

Slide 27 text

氏名 退職日 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 退職 申請 アカウント マスタ

Slide 28

Slide 28 text

雇用形態情報 所属部署情報

Slide 29

Slide 29 text

所属部署と雇用形態は日付によって変更が発生する。 履歴によって管理することによって、未来のデータを管 理/連携出来るようになる。 氏名 所属部門 雇用形態 開始日 終了日 DeNA太郎 A部門 アルバイト 2020/01/01 2020/03/31 DeNA太郎 B部門 正社員 2020/04/01 2999/12/31

Slide 30

Slide 30 text

氏名 所属部門 雇用形態 開始日 終了日 DeNA太郎 A部門 アルバイト 2020/01/01 2020/03/31 DeNA太郎 B部門 正社員 2020/04/01 2999/12/31 氏名 所属部門 雇用形態 DeNA太郎 A部門 アルバイト アカウント管理システム 連携対象システム 3月31日

Slide 31

Slide 31 text

氏名 所属部門 雇用形態 開始日 終了日 DeNA太郎 A部門 アルバイト 2020/01/01 2020/03/31 DeNA太郎 B部門 正社員 2020/04/01 2999/12/31 氏名 所属部門 雇用形態 DeNA太郎 B部門 正社員 アカウント管理システム 連携対象システム 4月1日

Slide 32

Slide 32 text

アカウント情報をAPIで提供している。 APIによって提供したアカウント情報により、社内システ ム部門が管理しているシステム以外のアカウント管理に利 用することが出来る。 アカウント 管理システム XXX システム 社内システム部門管理外 アカウント情報 取得API

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

● 組織/承認ルートを含む複雑な連携は、アカウント連携 基盤上において開発

Slide 36

Slide 36 text

Active Directory Okta アカウント 管理システム Google Workspace Slack Zoom 評価システム 会計システム 名刺管理 システム ・ ・ ・ ・ ・ ・ ・ ・ 複雑性高い （組織/承認ルート） 複雑性低い （有効/無効）

Slide 37

Slide 37 text

Active Directory Okta アカウント 管理システム Google Workspace Slack Zoom 評価システム 会計システム 名刺管理 システム ・ ・ ・ ・ ・ ・ ・ ・ 複雑性低い （有効/無効） パッケージ IDaaS活用

Slide 38

Slide 38 text

各システムと連携してアカウントプロビジョニング（アカ ウント作成）が出来る仕組み ● Active Directory ● Okta(IDaaS：Identity as a Service) アカウント管理システムから上記のシステムにアカウント 情報を連携した後に、各システムにプロビジョニング

Slide 39

Slide 39 text

ノーコードで連携できるのは嬉しい！

Slide 40

Slide 40 text

しかし 所属部署や承認ルートを含む複雑な連携は不可 ⇒　なければ作るしかない！

Slide 41

Slide 41 text

Active Directory Okta アカウント 管理システム Google Workspace Slack Zoom 評価システム 会計システム 名刺管理 システム ・ ・ ・ ・ ・ ・ ・ ・ 複雑性高い （組織/承認ルート） アカウント 連携基盤

Slide 42

Slide 42 text

連携基盤を構築し連携を増やす際には、各システムへの繋 の部分にフォーカス出来る状態にする。 メリット ● 構築工数の削減 ● 引継工数の削減 ● 共通化部品の品質向上 アカウント連携基盤 連携 Func 連携 Func 連携 Func 連携 Func 連携 Func Jenkins Node.js

Slide 43

Slide 43 text

連携結果はGUIで確認出来るようにする。 Jenkinsを可視化に利用している。 メリット エンジニア以外でも ● 結果確認可能 ● 再実行可能

Slide 44

Slide 44 text

アカウント連携基盤上で構築するとしても、各システムへ の連携を行う部分は個別に作成することになる。 本番一発でプログラム構築を行うのは怖い。。。 テスト環境を準備してくれる、SaaS/パッケージベンダー を選ぶことが重要となる。

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

評価システム上の承認ルートは多段の設定になっている。 異動/組織変更の際の承認ルート修正工数が大きく、一日 がかりでメンテナンスしている。 A部門 B部門 C部門 D部門 E部門 F部門 G部門 構築される承認ルート B部門上長 A部門上長 A部門上長 C部門上長 A部門上長 B部門上長 A部門上長 B部門上長 A部門上長 D部門上長 E部門上長 C部門上長 A部門上長 C部門上長 A部門上長 F部門上長 G部門上長 部門階層

Slide 47

Slide 47 text

A部門の上長が変わるとA部門を上位部門にもつ部門に所 属する従業員の承認ルートが全て変更になる。 B部門上長 A部門上長 A部門上長 C部門上長 A部門上長 B部門上長 A部門上長 B部門上長 A部門上長 D部門上長 E部門上長 C部門上長 A部門上長 C部門上長 A部門上長 F部門上長 G部門上長 変 変 変 変 変 変 変 構築される承認ルート

Slide 48

Slide 48 text

アカウント管理システム情報を利用して承認ルート連携 ● 承認ルートは組織マスタから ● 各従業員の所属情報はアカウントマスタから ● 連携はアカウント連携基盤を利用してAPI連携 アカウント マスタ 組織 マスタ アカウント 管理システム 承認 ルート 評価 システム API Call

Slide 49

Slide 49 text

評価システム上の承認ルートは多段の設定になっている。 異動/組織変更の際の承認ルート修正工数が大きく、一日 がかりでメンテナンスしている。 月次で発生していた一日作業がなくなった！ 設定漏れ等による承認ルートの間違えもない！

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

部門ごとのGoogleGroupがあると便利だな ● メールの送信 ● カレンダーの招待 ● ドキュメントの権限付与 各部門の担当者で実施するのは大変 ● 抜け漏れが発生 ● そもそもそんな工数ない

Slide 52

Slide 52 text

上位部門のグループにも所属するので、異動/組織変更の 際のメンテナンス対象のグループが膨大になる。 A部門 B部門 C部門 D部門 E部門 F部門 G部門 D部門所属のDeNA太郎の所属グループ D部門グループ B部門のグループ A部門のグループ

Slide 53

Slide 53 text

さらに 雇用形態別にも分けているためGoogleGroupを手動メンテ ナンスするのは現実的に不可能 例） 　A部門の全員グループ/A部門の正社員グループ　等々 所属部門　×　雇用形態

Slide 54

Slide 54 text

アカウント管理システム情報を利用してGoogleGroup連携 ● グループは組織マスタから ● グループの所属情報はアカウントマスタから ● 連携はアカウント連携基盤を利用してAPI連携 アカウント マスタ 組織 マスタ アカウント 管理システム Google Group Google Workspace API Call

Slide 55

Slide 55 text

部門ごとのGoogleGroupがあると便利 しかし各部門の担当者で実施するのは大変 ● 抜け漏れが発生 ● そもそもそんな工数ない 全部門のGoogleGroupが出来た！

Slide 56

Slide 56 text

アカウント管理 ● 人事発令（入退社/異動/組織変更申請）のデータを参照 ● 履歴の形でデータ構築 アカウント連携 ● 組織/承認ルートを含む複雑な連携は、アカウント連携基盤上 において開発

Slide 57

Slide 57 text

No content