プロビジョニング機能の内製化に関するAsIs調査とToBe策定

はじめに

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

前回の記事「プロビジョニング機能の内製化によるシステム運用の効率化事例」に続き、より具体的な内容について紹介いたします。

今回のブログでは、AsIs調査からToBe策定について記載しています。

プロビジョニング機能内製化の背景や流れについては前回の記事をご覧ください。

AsIs調査

前回のブログで、プロビジョニング機能の内製化によって大きな成果が得られたことをお伝えしました。しかし、この成功は、プロジェクトの最初のステップであるAsIs調査、つまり現状の徹底的な把握なくしては成し得ませんでした。

とくに、プロビジョニングの根幹をなすアカウント情報がどのように管理されているかを正確に把握することが、内製化のToBe像を描く上でもっとも重要でした。DeNAグループでは、Okta、Active Directory、社内人事システムのアカウントマスターが連携しており、それぞれのシステムで異なる形式や項目で情報が管理されていました。

1.アカウントマスターの仕様調査

現状の課題を明らかにし、内製化を進める上での土台を築くために不可欠なものでした。私たちは、以下の2つの観点から情報を整理しました。

(1)アカウントマスターごとの項目と要素の洗い出し

各システムがどのような情報を保持しているか、そしてそれぞれのデータ形式（文字列、数値など）や必須・任意といった要素を詳細に確認しました。たとえば、Oktaでは氏名や社員番号、メールアドレスが管理されている一方で、社内人事システムでは氏名とメールアドレスに加えて役職や権限レベルといった情報が管理されていました。

(2)アカウント情報の全体像の可視化

バラバラに管理されていた情報を1つにまとめることで、内製化を進める上で「どの情報がもっとも信頼できるか」や「どのような情報がどのシステムに連携されているか」などを一目で把握できるようになりました。

この調査はToBe策定を進めるための重要な土台となりました。次項では、この調査で明らかになった具体的な内容について、さらに深掘りしてご紹介します。

図1：アカウント情報の統合イメージ

図2：アカウントマスターの項目整理

2.Oktaプロビジョニング機能の実態調査

アカウントマスターの全体像を把握した上で次に着手したのは、「Oktaによるプロビジョニング機能が実際にどのように動作しているか」を詳細に調査することでした。Oktaは便利なサービスですが、長年の運用で、どの情報が・どこへ・いつ流れているのか、などの詳細なロジックが不透明になっていた部分があったため、一度正確に把握する必要がありました。

この調査の目的は、Oktaが現在どのようなシステム連携を担っているのかを正確に理解し、内製化の移行計画を立てるための基礎情報を得ることです。以下の3つの観点から、プロビジョニング対象システムごとに情報を整理しました。

(1)プロビジョニングの起点・終点と運用体制の明確化

まず、プロビジョニングの「起点」（Oktaに情報を送る元のシステム）と「終点」（Oktaによってアカウントが作成・連携される先のシステム）を明らかにしました。

さらに、終点側の各システムの運用体制についても調査しました。例えば、あるシステムは総務担当者が運用しており、Oktaから作成・連携されたアカウントに対して個別設定が行われていました。また、Okta以外からアカウントが作成される運用も存在し、手動での管理が運用負荷を上げていることが判明しました。

(2)アカウントのライフサイクルと連携情報の確認

次に、Oktaによるアカウント作成・削除プロセスと、連携される情報を確認しました。

アカウント作成は、特定の属性を持つユーザーが自動でアサインされる場合と、誰かが依頼を受けて手動で付与している場合がありました。また、アカウントの削除に関しては、プロビジョニング機能によって無効化されるだけで、アカウント自体は削除されないシステムがあることがわかりました。連携情報についても、システムごとに必要なフィールドが異なっていることを整理しました。

(3)グループ連携と開発環境の確認

最後に、グループ連携の有無や、内製化に向けた開発環境の状況を確認しました。

一部のシステムではGoogleグループとADグループの同期（グループPush）が行われていましたが、連携元のグループメンバーが削除されても、連携先のアカウントが無効になるだけで削除はされないといったシステムがあることも明らかになりました。また、本番と同仕様のAPIが叩ける開発環境がないシステムが複数あり、内製化のテスト環境構築に課題があることが判明しました。

この調査を通じて、私たちはOktaのプロビジョニングが持つ「便利さ」と長年の運用によって生まれた「プロビジョニング機能の全体像に対する不透明さ」の両面を再認識しました。とくに、システムごとに運用が異なっていることが、内製化の大きな課題として見えてきました。

ToBe策定

AsIs調査でOktaのプロビジョニング機能が利用されているシステムをすべて洗い出した後、私たちは内製化のスコープを明確にするため、以下の2つの観点からToBe像を策定しました。

プロビジョニングが不要なシステムの洗い出し
内製化対象システムの決定

安直に「既存システムをすべてスコープ対象とする」と判断せずに、開発や今後の運用リソースをどこに集中させるべきかをしっかりと再考した上でスコープを判断しました。この判断は、本プロジェクトの成功を左右する重要な意思決定であったと実感しています。

プロビジョニングが不要なシステムの洗い出し

調査の結果、Oktaのプロビジョニング機能が有効になっているものの、実際の運用を考えるとプロビジョニングを内製化する必要がないシステムがいくつかあることがわかりました。これらのシステムは、主にユーザー数が100人以下であるか、将来的な利用が限定的であるかを判断材料としました。

表：プロビジョニング機能_内製化移行判断基準表

具体的には、黄色でハイライトしたシステムをプロビジョニング対象から除外し、手動での運用や設定変更で対応することにしました。これにより、開発コストを抑えつつ、効率的な内製化を目指す方針を固めることができました。

内製化の対象システムの決定と移行の優先順位付け

次に、内製化の対象となるシステムを絞り込み、さらに移行の優先順位付けを行いました。私たちは単にユーザー数だけで判断するのではなく、「手動運用では非効率であり、内製化による自動化のメリットが最大限に得られるシステム」を多角的に評価しました。

この判断には、ユーザー数に加え、「業務への影響度」と「移行の難易度」という2つの軸を用いました。

ユーザー数： もっとも基本的な判断基準。ユーザー数が多いほど、内製化による自動化のメリットが大きくなります。
業務影響度： システムが業務に与える影響の大きさ。利用ユーザー数や、システムが停止した場合のリスクなどを考慮しました。
移行難易度： 移行に必要な技術的な労力。APIの仕様、既存システムの改修範囲、データの複雑性などを評価しました。

これらの観点に基づき、私たちは移行対象システムを分類し、ユーザー数が100人を超える主要な業務システムを優先的に内製化の対象としました。これにより、アカウント管理の運用負荷を大幅に削減し、本質的な業務に集中できる体制を構築します。

まとめ

本ブログでは、プロビジョニング機能の内製化という一大プロジェクトにおける、「AsIs調査」から「ToBe策定」までの詳細なプロセスをご紹介しました。

Oktaの便利な機能の裏側にあるアカウント情報の分散や運用の不透明性を徹底的に調査し、その客観的なデータに基づいて「プロビジョニングが不要なシステムの洗い出し」と「内製化の対象システムの決定」という重要な意思決定を行いました。

ToBe策定においては、ユーザー数という判断基準に加え、移行難易度と業務影響度という2つの軸を掛け合わせることで、投資対効果がもっとも高い部分にリソースを集中させる方針を固めました。

このプロセスを通じて、私たちは単なるツールの置き換えではなく、より効率的で柔軟なアカウント管理体制を構築するための基盤を築くことができました。

おわりに

今回の取り組みを通じて私たちが得たもっとも大きな教訓は、データに基づいた内製化こそが成功の鍵であるということです。

ベンダーサービスをそのまま置き換えるのではなく、まずは「何のために内製化するのか」という目的を明確にし、客観的なデータに基づいてスコープを絞り込むことが何よりも重要でした。

ユーザー数という明確な判断基準に加え、移行難易度と業務影響度という多角的な視点から、投資対効果がもっとも高い部分にリソースを集中させることができたのです。

この経験は、今後のDeNAグループのITシステム戦略においても、大きな指針となります。今後も、このようなデータに基づいた論理的な意思決定プロセスを大切にし、ITによる事業の成長に貢献します。