プロビジョニング機能の内製化によるシステム運用の効率化事例

はじめに

こんにちは。IT本部IT戦略部テクニカルオペレーショングループの矢島です。
私はDeNAグループにおけるITシステム・ツールの導入企画から運用管理、運用改善などを担当しています。

今回のブログではDeNAで運用中のシステムに対するユーザー連携機能である「プロビジョニング機能」の内製化について紹介します。

この記事の流れ

プロビジョニング機能内製化の背景
内製化の流れ
内製化の効果
まとめ

プロビジョニング機能内製化の背景

DeNAで運用中のシステムへのプロビジョニング

DeNAでは約300を超えるシステムを運用しています。
クラウド環境・オンプレミス環境の混在のほか、SaaS・パッケージ製品・内製システムと多様なシステムを運用しています。
上記のうち、DeNAグループ全社での利用や複数部署で利用するシステムに「アカウントマスタ」からユーザー情報を「プロビジョニング機能」を用いて連携しています。

「プロビジョニング機能」とはシステムやサービスの利用開始に必要な設定や準備を行う機能です。
今回紹介する「ユーザー情報のプロビジョニング」は、システム利用ユーザーの作成・更新・削除のほか、権限設定などユーザーに関する設定の自動化を指します。

プロビジョニングを行う理由

ユーザー情報のプロビジョニングを行う理由は「ユーザー数が多く、連携操作が複雑なため手作業に多くの工数が必要なため」です。
連携作業における従来の課題は以下のとおりです。

システム利用ユーザー数が多い
- ユーザー数が多く、入退社や人事異動に伴うユーザーアカウント変更作業が大量に発生する。
アカウントマスタが複雑あり、ユーザーアカウント設定ルールが複雑
- ユーザー情報を管理する「アカウントマスタ」が複数あり、連携に複雑な操作が必要。

プロビジョニングの方法

従来のプロビジョニングは「Oktaのプロビジョニング機能」と「内製連携ツール」をシステムごとに使い分けていましたが、今回の取組で「内製連携ツールに一本化する」ことを決定しました。
決定の理由は2つあります。

1点目：SSO製品のポータビリティ向上
2点目：プロビジョニング機能の一本化

1点目は「SSO製品のポータビリティ向上」です。
SSO製品は市場に多数存在しています。また、SAML等の認証方式は標準化が進んでおり、ライブラリを組み合わせることで内製化も可能です。
しかし、プロビジョニング機能は認証機能とは異なり、標準化されていません。
そのため、特定製品に依存してしまう、いわゆる「ロックイン」のリスクがあります。
内製連携ツールへの一本化により、「SSO機能」と「プロビジョニング機能」を分離し、SSO製品のポータビリティ性を高めることを目指します。

2点目は「プロビジョニング機能の一本化」です。
従来は、下記のとおり複数のアカウントマスタが存在していました。
これらのマスタは、作成時期や管理目的が異なるため、構造や項目が統一されておらず、管理が煩雑でした。
また、プロビジョニングの方法も一本化されておらず、システムごとに分散管理されていました。

言うなれば「多（マスタ）対多（システム）」の関係です。
「Oktaのプロビジョニング機能」はGUIから設定が可能であり、比較的簡単に操作できます。そのため、構成が複雑でも運用担当者による対応ができていました。

ここで大きな転機となったのが「アカウントマスタシステムの新設」です。
IT戦略部では2023年から新たなアカウントマスタとなるシステムを新設し、これまでバラバラに管理されていたアカウントマスタを一元化するプロジェクトを進めています。
「プロビジョニング方法の見直し・効率化」も上記プロジェクト目的の1つです。
アカウントマスタを新システムに移行・一本化することで、以下のシンプルな構成を実現します。

従来の「多（マスタ）対多（システム）」から「1（マスタ）対多（システム）」となることで、プロビジョニング機能の一本化に向けた環境が整います。

内製化の流れ

ここからは実際に内製化に向けて実施した検討・対応事項を紹介します。

AsIs調査

構成変更の準備として以下の現状（AsIs）の調査を実施しました。
1.アカウントマスタの仕様調査
現在利用しているアカウントマスタの仕様を調査し、内容をまとめます。
マスタごとに記録されている項目や要素に違いがあるため、1つのシートで情報を網羅できるよう整理を実施しました。
2.Oktaプロビジョニング機能の実態調査
Oktaプロビジョニング機能の動作状況や設定項目を調査します。

プロビジョニング元のアカウントマスタは何か
プロビジョニング先のシステムにどのような情報を渡しているか
どれくらいの頻度で動作しているか

上記についてプロビジョニング対象システムごとに内容を整理しました。

ToBe策定

AsIs調査結果を基に「新機能の要件（ToBe）」を作成します。
内製化対象のシステム決定

プロビジョニングが不要なシステムの洗い出し
- AsIsで調査したシステムのうち、ユーザー数や連携実施内容から「手動対応で対応可能」なものを除外しました。
対象システムの決定
- 上記で除外されたシステムを除き、内製化対象を決定しました。

各システムのプロビジョニング動作決定

続いて、システムごとにユーザープロビジョニングの動作を決定します。
システムごとに連携値が異なるため、AsIsの調査内容をもとに検討を行いました。

ユーザーIDは何を使うか（メールアドレス/ADアカウント名など）
連携対象ユーザーはどのように特定するか（マスタ上のどのフラグを使うか？など）

上記について関係者で協議し、システムごとに動作を決定しました。

設計・実装・テスト実施

ここまでに決定した内容をもとに設計を実施し、機能を実装します。
実装後は下記の検証環境を用意し、テストを実施しました。

内製プロビジョニング機能の検証環境
プロビジョニング対象システムの検証環境

上記のうち、「プロビジョニング対象システムの検証環境」の用意に手間がかかりました。
内製システムやオンプレ環境上のシステムは検証環境や試験環境が存在するため、スムーズにテストを開始できます。
一方でSaaSの場合はサービス提供ベンダーに「検証環境の提供依頼」が必要なケースがあり、調整に時間を要しました。
長引いたケースでは依頼から提供までに数週間～1か月程度かかることもあり、テストスケジュールに影響が発生しました。

リハーサルの実施・本番作業準備

本番作業準備として検証環境でのリハーサルを実施します。
作業手順の作成では「システム利用ユーザーに影響を与えない」こと、「各システム管理者の対応工数を最小にする」ことを心がけました。
具体的には以下の順序で実施しました。

リハーサル手順作成・レビュー
リハーサル作業実施
リハーサル結果をもとにした本番手順作成
本番作業の日程調整
本番作業手順レビュー

本番作業の実施

準備が整ったら本番作業を実施し、プロビジョニング機能を切り替えます。
機能の切り替えは以下の流れで実施しました。

ドライラン結果の確認
- 本番環境に影響を与えないよう、「本番で動作させ、データは反映しない」ドライランを実施します。
- ドライラン結果を出力データ上で確認し、「切り替え前のユーザー情報と差分が出ない」ことを確認します。
切り替え開始連絡
Oktaプロビジョニング機能の停止
内製プロビジョニング機能の有効化
切り替え前後でのユーザー情報差分確認
- 切り替え前の状態と差分が無いか、ドライラン結果と本番に反映されたデータに差分が無いかを確認します。

上記の確認が完了し、本番作業を完了しました。

内製化の効果

2025年3月時点で計6システムのプロビジョニング内製化を完了しました。
入念な準備の結果、切り替えによる業務影響は一切ありませんでした。
また、当初目的の「SSOシステムのポータビリティ向上」と「プロビジョニング機能の一本化」のほか、以下の副次的な効果を発揮しています。
1.管理工数の低減

エラー発生時の調査工数・対応時間削減
- 「Oktaのプロビジョニング機能」のエラーについて製品サポートへ連携・相談が必要な場合、エラー解消までに原因切り分け等の調査工数と時間がかかることがありました。
- 内製化により対応を社内で完結できるようになり、工数・対応時間ともに低減することができました。
アカウントマスタ共通化による管理工数削減
- マスタの共通化により従来は「約1人月」かかっていたアカウントの棚卸工数を「90%削減」できる見込みです。
- 工数が減ることで棚卸の実施頻度を増やすことが可能になり、マスタの管理品質向上にも繋がります。

2.技術負債の解消

イレギュラーなアカウントの可視化と整理
- アカウントマスタ整理の過程で、マスタに登録されていない「イレギュラーなアカウント」を検知しました。
- イレギュラーとなった経緯を調査し、マスタ共通化時にあわせて通常の運用に是正しました。
- 結果として運用上の負債となる「イレギュラー要素」を解消することができました。
不要なアカウント停止によるコスト削減
- 整理の過程で見つかった不要アカウントを停止し、割り当てられていたライセンスを解除しました。
- 解除したライセンスを他のユーザーに割り当てることで追加のライセンス購入が抑制され、コスト削減に繋がりました。