10月の振り返り｜人事データベースからSCIMでサービスのグループまで連携する

10月の進捗

• 人事データベースからOkta、Oktaからサービスへのグループ連携を特定のサービスで開始
• Google WorkspaceのOAuthログに関するSIEMでの検知ルールを作成して運用

やったこと

9月は人事データベースの組織をOktaのグループとして自動連携できるようにしました。10月はその続きとして、Oktaに自動連携されたグループを、Oktaの先にあるサービス側のグループまでSCIM連携しました。

人事データベースからOktaへは組織情報や雇用形態をグループに反映しています。今回はOkta側で対象者をアサインするのサービス用のグループを2つ用意しました。1つは雇用形態が正社員のグループです。もう1つはバイネームで指定するグループです。どちらもサービスへPushされます。

サービス側には組織情報と雇用形態のグループをOktaからPushしており、人事データベースで所属情報が更新されるとOktaを経由してサービス側のグループも追従していきます。これにより、組織改編や人事発令の後にサービスごとに所属しているメンバーの情報を手動で更新する作業を減らすことが出来ました。

あえて手動を残したこと

先ほど、手動で更新する作業を減らすことができたとお伝えしました。今回SCIM連携を実装するにあたって、最も考えたことがどこまで自動化するかです。

対象のサービスは正社員であれば、入社時から全員が利用しています。一方で他の雇用形態では使う人と使わない人がいます。すべての雇用形態をそのまま自動Pushすると、使わない人にもアカウントと権限が割り当てられてしまいます。

そのため、正社員は無条件でPushし、それ以外の雇用形態はOkta側で手動でアサインしたときににサービス側へPushされる形にしました。これでライセンスのコスト最適化と権限も必要な人にだけ割り当てられる状態になります。

自動化を進める！といっている人間が、あえて手動を残すという逆の判断をしたことになります。ただ、そのサービスをどのように使うかは人事データベースの情報だけでは判断できません。機械的に（もしくは自動的に）進めようとするほど、実態と合わないことが増えてしまうのです。そこで最終的に自動で進められる範囲と手動で進めるべき範囲を分けることにしました。これは現時点での最善解だと考えています。もちろん今後サービスの使い方が変われば、連携方法も変わる可能性があります。

Google WorkspaceのOAuthログに関するSIEMでの検知ルールを作成

次はセキュリティ面での進捗です。9月はシャドーIT/AIの可視化サービスを検証しました。その時点ではサービスの導入は見送りました。ただ、その時に見たかった、誰がどんな情報をどこに連携しているのかについて、10月はGoogle WorkspaceのOAuthログをもとにSIEMでルールを作成して、新しくOAuthでサービス連携されたら検知できるようにしました。

OAuthの許可は、利用者からはボタン1つでできる便利な仕組みです。ただ、実際に渡しているのはメールやドライブの読み取りや書き込み権限だったりします。可視化サービスを導入しなくても、少なくとも業務アカウントから外部へ渡している権限については可視化できる状態になりました。

おわりに

最後に11月の目標です。11月もSCIM連携するサービスをさらに増やしていきます。サービスごとに仕様や社内での利用ケースが違うので、サービスごとに判断して最善解を求めていきたいと考えています。

連携がするサービスが増えるほど、人事発令のあとで手動で更新する作業が減っていくので、積み上げが効くのでコツコツ進めたいです。

---

人事データベースからOktaへのグループ連携や入社・退職の手続きの自動化については、それぞれ別の記事にしています。

• 9月の振り返り｜人事データベースからのOktaグループ連携
• 入退社の手続きを自動化してタスクの抜け漏れをなくす

同じような人事データの連携やアカウント管理の課題解決を、副業でお手伝いします！（週5〜8時間 / フルリモート）

情シスが1〜2名の会社での設計レビューや壁打ちも受け付けています。

ご連絡は Xからお願いします。

Corporate IT 9月の振り返り | 人事データベースからIDaaSグループ連携

9月の進捗

• 人事データベースの組織をIDaaSのグループとして自動連携
• シャドーIT/AIの可視化サービスの比較検討

やったこと

まず継続して取り組んでいる人事データベースですが、ついに組織情報をIDaaSへグループとして自動連携するようにしました。データベースでは人と組織の情報を管理しており、所属情報を動的に運用しています。

今回は組織情報をIDaaSへグループとして自動連携することで、データベース上で所属情報に更新があった場合、IDaaS側のグループにも同期して所属情報の更新ができるようになりました。

シャドーIT/AIの可視化サービスの比較検討に関して、そもそも可視化しておきたかったのは、誰がどんな情報をどこに連携しているのかということです。特にGoogle・Microsoft・GitHubなどの業務アカウントを使ってサードパーティのサービスにOAuthで登録してデータ連携をしていたりする場合、管理が難しくなります。

そこで、Nudge SecurityやChrome Enterpriseの新機能であるView Gen AI and SaaS app usage detailsを実際に検証しました。結論として現時点での導入は見送りましたが、シャドーIT/AIの可視化サービスも多く出てきている中で、改めてキャッチアップすることができたのでいい機会でした。

難しかったこと

難しかったのは、人事データベースの組織をIDaaSへグループとして自動連携することでした。少し細かい話になりますが、もともと人事データベースの組織には組織コードを持たせていて、コードは特定の組織とその階層を表現していました。

例えば、COO配下にある営業部の営業2チームであれば、COO-Sales-Sales2になります。COO配下からCRO配下に営業部がつくことになると、CRO-Sales-Sales2となる予定でした。

人事データベース上では組織コードの変更で問題ないのですが、人事データベースから連携する先で問題が発生します。IDaaSではCOO-Sales-Sales2とCRO-Sales-Sales2を別のグループとして認識するため、本来引き継いでほしい組織内の所属情報などを毎回作り直さなければいけません。

そこで組織の管理方法を変えました。組織コードではなく、組織IDを用いて常に一意に定められるようにしたのです。

これにより人事データベース上で組織の階層や名称が変わっても、毎回IDaaSのグループを作り直す必要がなくなりました。

10月の目標

人事データベースの組織をIDaaSへグループとして自動連携できるようになったので、10月はIDaaSに連携しているサービスのグループをIDaaSからSCIM連携していきたいと考えています。

これが実現できると、人事発令によって所属情報が更新されたときに、IDaaS→社内で利用していて、SCIM連携しているサービスのグループまで自動で連携できるので、サービスごとに所属している社員の情報を更新する必要がなくなります。

とはいっても、サービスごとに仕様が違うので、そこは1つずつ進める必要がありますが、いよいよ人事データベースを作成した効果を実感できるようになるので楽しみです。

---

同じような人事データの連携やアカウント管理の課題解決を、副業でお手伝いしています（週5〜8時間 / フルリモート）。

情シスが1〜2名の会社での設計レビューや壁打ちも受け付けています。

ご連絡は Xからお願いします。

入退社の手続きを自動化してタスクの抜け漏れをなくす

今回は社内の入社や退職に関わる業務の漏れをなくしリスクを低減するために実施した内容をまとめました。入社や退職に関わる業務は抜け漏れが発生した場合のリスクが高い一方で、一部のメンバーに業務が偏ることでの属人化や関係者が多いために連携ミスが発生しやすい業務でもあります。

仕組み化できれば、社内に横断的に貢献できる業務でもありますので、Corporate ITとしては取り組みたいところです。今回は実際に何を仕組み化した（一部は現在進行形で改善中）のかをまとめてみました。

やったこと

まずざっくりとしたまとめです。

入社や退職の社内申請を作成しました。社内申請の承認を起点として後続の業務が開始される仕組みです。具体的には、労務SaaSへの自動連携、社内の台帳への自動追記、関係者への連絡、退職の場合は退職者との手続きのチャンネルの自動作成と関係者の自動招待です。

またそれぞれのステップで、エラー通知も行うように設定しました。

	改善前	改善後
依頼の起点	Slackメッセージ	申請が承認された瞬間
労務SaaS登録	手入力	自動
社員台帳	別途手入力	自動
関係者への連絡	担当者が都度	4系統へ自動通知
漏れたとき	気づかない	通知が止まるので気づく

そもそもの課題

そもそもの課題としては大きく3点ありました。

最もクリティカルだった課題は業務のトリガーが決まっていないということです。採用担当からCorporate ITや労務へは、その都度Slackで伝える形で共有されていました。当然伝達が漏れれば後続の処理はそもそも始まりません。後続の処理を開始するための明確な起点がなかったのです。

2つ目の課題は、同じ情報を複数システムに手入力していたことです。採用担当、労務、総務、Corporate ITがそれぞれに入力しており、転記ミスがあっても検知しにくい状態でした。

3つ目の課題は担当者に依存していたことです。属人化していたため、誰が担当するかで手順が変わり、漏れても気づけない状態でした。

これらは特定の組織での課題ではありません。組織規模が小さく毎月数名の入社であれば、運用できてしまうため、多くの組織で潜在的な課題になっているはずで、これまで所属した組織でも同じ課題を抱えていました。

やらなかったこと

上記3点の課題の解決策として、既存システムやフローの大幅な変更は行いませんでした。

新規システムを導入することやフローの大幅な変更は、課題解決の方法としては簡単ではあるものの、社内の入社や退職に関わる業務の漏れをなくしリスクを低減するために新しいものを用意するのは過剰だと判断したためです。

すでにあるものを活用して抜け漏れを防ぐことに集中することで、対応するスコープを明確に決めました。

また、全自動化も目指しませんでした。取り扱う情報の性質を考慮し、判断が必要な項目は人に通知するようにしました。

権限と個人情報の扱い

やらなかったことに近いですが、権限や個人情報の取り扱いには注意が必要です。最小権限の原則に則り、関係者以外はアクセスできないことを担保しました。

さらにそれぞれの処理で「いつ・どの申請で・何が実行されたか」のログを取得することで、万が一問題が発生しても後から辿れる設計にしています。すぐには不要かもしれませんが、将来の監査対応も考慮してログの取得も実装しました。

全自動化を目指さないことで新たな発見もありました。これまで入退社の処理は、人事・労務・総務に分かれています。1人では完結しないタスクになっていました。これは意図した設計ではありませんでしたが、結果として統制が効く状態になっていました。

そのまま全てを自動化するとこれが1つに統合されます。社内の誰も持っていなかった強い権限を1つ作ることになるわけです。自動化は権限を1か所に集める行為なので、目的が「漏れをなくすこと＝統制を効かせること」なら、統制を弱める手段を選ぶべきではないと判断しました。

全体構成図の提示

これまで記載したことをまとめていくと、全体の構成の大枠は下記のようになりました。

申請の承認をトリガーとして、実行基盤が申請の詳細を取得し、取得したデータを労務SaaSや社内の台帳に記載して、記載が終わったら関係者にSlackで処理内容を通知します。 担当者視点では、Slackに申請の承認が通知された後、数分待てば労務SaaSや台帳への記載完了通知も届くようになっています。

詰まったこと・残っている課題

実装中にSlackの仕様にあわせる部分で少し詰まることがありました。Slackはアプリからの応答がないときに同じリクエストを最大3回まで再送します。Slack側としては処理が確実に行われるための仕組みになっているようです。

実際にテストケースとして試した先には、入社処理で同じ人が重複登録されていました。申請ごとに1つの鍵をとる仕組み（分散ロック）で対処し、2回目以降は何もしないようにしました。

より正確には、個人情報は処理に使うだけで、実行基盤には保存していません。二重実行を防ぐ鍵も申請URLのハッシュ値を使い、鍵から個人が復元できないようになっています。また鍵（ロック）は30分で自動解放されます。

残っている課題としては、申請の承認の受け取り方という問題があります。

申請が承認されたという通知文は承認サービスから定型文でSlackに通知されるため、入社・退職の申請ごとに分けることができません。そのため現状は、どちらの申請かは通知先のチャンネルを分けることで判断しています。通知先のチャンネルは申請側で設定しているため、申請側の設定変更によっては壊れる可能性があります。

また同姓同名や旧姓変更に弱いという課題もあります。本来は社員IDやメールアドレスなど一意な値を使って処理することが望ましいですが、現状はフルネームで突合している部分があります。

ただ、この部分は入社退職に関わるタスクの抜け漏れに関する対応というよりも人事マスタの整理として対応した方が適切なので、別のスコープとして切り出して対応することにしました。

他の組織でも実装するなら

今回対応してみて、他の組織でもできることは多いと感じました。

まず基本的なことですが、入社退職の申請フローをつくるということです。申請ツールでもチャットのワークフローでも問題ありませんが、明確な起点を用意することで、後続の処理ができるようになります。

次に承認されたら関係者に通知が飛ぶようにすることです。この仕組み自体はSlackのワークフローでもノーコードツールでも実装できるので、難易度は低いと思います。

最後に労務SaaSへの登録を自動化です。今回実装してみて、この部分は最後に回しても問題ないと思いました。その理由としては、申請フローとその結果を集計する台帳があれば、大半の抜け漏れは止められると感じているためです。手動での入力ミスは防止できませんが、入力ミスより抜け漏れの方が発生の可能性が高いです。

もちろん最初から自動化できればいいのですが、入社退職が月の合計で10件を超えてきたら検討でも問題ないというのが個人的な印象です。

まとめ

それでは今回のまとめです。

今回は入社退職に関わるタスクの抜け漏れをなくすための自動化をどのように実装したのかをまとめました。その結果として、ツール連携より大事なのは業務の起点を作ることとフロー整備だったことがわかりました。

そして漏れをなくすことは、業務効率化のためというより、監査指摘・アカウント残存・情報漏えいといったリスクを避けるために必要な取り組みだと確認できました。

また入社退職に関わるタスクの抜け漏れをなくすことは内部統制の観点で重要であり、自動化のために新しい権限を増やすことは統制の改善とは逆行することを学びました。

---

同じような入社退職やアカウント管理などの課題解決を副業でお手伝いします。

• 「入退社の依頼が属人化していて、抜けても気づけない」
• 「ツールは入れたが、運用が回っていない」

このような段階からのご相談や現状の整理でも対応します。 フルリモートで週5〜8時間を想定しています。

ご連絡は YOUTRUST / Xからお願いします。