この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2015 の投稿記事です。

こんにちは、syamataです。

リクルートマーケティングパートナーズ（以下RMP）はワークスタイル変革のために、リモートワークなどのダイバーシティを推進する〈ワークスタイル変革プロジェクト〉という全社横断のチームをつくり、動いています。そこで私はプロジェクトをシステム面でサポートするIT担当として、Google Appsなどの情報インフラを担当しています。

ワークスタイル変革の推進

リクルートマーケティングパートナーズでは、ひとりひとりの多様な人生に合わせた働きかたができる会社を目指し、ワークスタイルの変革に取り組むことを決めました。その第一歩として、先期はリモートワーク（在宅勤務）のフィジビリティスタディに着手しました。今期も引き続き、従業員全員が自律的に最適な働きかたを選択できる環境を整備することで、個々人の成長を応援していきます。

なぜやるのか

リモートワークを実現させるためには、それに適したツールや情報インフラを用意することがとても大切です。一部を除き、会社に出勤しての業務を想定して情報インフラが設計されています。それらを社外利用できるようアジャストすることも必要ですが、思い切って新しい業務システムを導入しリプレイスすることにも挑戦しなければいけません。基本的には情報インフラや業務システムはリクルートグループ全社で標準化されていますが、分社化¹⁾グループガバナンス体制変更についてのお知らせ以降、各社の多様な事業ドメインや業務スタイルに応じて、各社で判断して整備することも選択肢として設けられてきました。

〈コミュニケーション〉と〈ドキュメント管理〉

ITチームには社内・社外を分け隔てない〈コミュニケーション〉と〈ドキュメント共有〉についての課題解決が依頼されました。

我々はそれぞれ別のソリューションを導入するのではなく、Google Apps²⁾Google Apps for Workをグループウェアとして導入することに決めました。Google Hangtoutsをコミュニケーションに、Google Driveをドキュメント共有に使います。これらのサービスを提供することは要件の課題解決はもちろん、Gmailやカレンダーなどの今後の機能拡張性を考えると適していると判断しました。他サービスとの比較の観点は本稿では触れませんが、何より管理者の我々が日頃使い慣れているツールであることが大きかったです。

Active Directoryを使うまでの経緯

単純にGoogle Appsを導入することはそれほど難しくありません。

今回の要件の実現は大切ですが、中長期的観点では、より汎用的なシステムであるべきであると考えました。
システム導入以前にITチームは、RMP全社を見渡して、ユーザーID管理システムを独自に持つ業務システムが多いことに課題感を抱いていました。それぞれ独自に持つということは、追加・削除・編集・棚卸しなどをシステムがあるだけ実施する必要があるということです。特に定期的な棚卸しが煩雑だという意見が組織長の方々から多く出ていました。³⁾より多くの部下を持つ上位職の方ほど多いようです

そこでディレクトリ・サービスを別途用意することにしました。将来的に複数システムのユーザーID管理を一元的に管理するためです。先立ってGADSを使った制御を考えていたため、LDAPにすることは決めていました。コスト面を考えてOpenLDAPのようなオープンソースソフトウェアでの実装を検討しましたが、AWSのWindows ServerはSPLA（Service Provider License Agreement）のライセンス⁴⁾Microsoft とアマゾン ウェブ サービスはどのような関係ですか?（AWS）により、CAL（Client Access License）を適用せずにActive Directoryを使えるということでしたので、コスト以外にLDAPの実装にこだわりはなかったためActive Directoryを選択しました。

GADSの使い方

Google Appsとの連携はGADS（Google Apps Directory Sync）を使います。Syncという名称から、同期が必須だと思われがちですが、今のところActive DirectoryからGoogle Appsへは一方通行でユーザーの追加・変更・削除（サスペンド）を実行するバッチ処理として利用しています。また、他システムとのパスワード連携をせずGoogle Apps側にパスワード管理を委譲することで、意図的に可用性を下げています。

AWS構成

GADSはWindows、Active DirectoryはWindows Serverで動かしています。メールはAmazon SESでユーザーに送信。

ユーザー追加の流れ

以下の流れでユーザーを追加しています。

1. リクルート全社のディレクトリ・サービスなど⁵⁾など、というのがポイントです。単純ではありませんからデータを取得
2. データを加工し、Active Directoryにインポート
3. ユーザー追加バッチ実行
   • GADSでGoogle Appsにユーザー追加
   • ユーザーにActivationメール送信
4. ユーザーは初期パスワードをGoogle Apps側で変更

ユーザー削除・棚卸しの流れ

以下の流れでユーザーの削除・棚卸しをしています。

1. 削除・棚卸し対象者のデータを作成し、Active Directoryにインポート
2. ユーザー削除バッチ実行
   • GADSでGoogle Appsにユーザー削除
3. （いきなり削除はされません）サスペンド状態になったユーザーの目視確認
   • ヒューマンエラーによる誤削除ではないかの台帳突き合わせ
   • Google Driveでオーナーになっているファイルの権限移譲処理
4. Google Apps側でのユーザー削除対応

サスペンド状態になるとユーザーはログインできなくなりますが、ライセンス費用は発生し続けます。ユーザーの随時削除と、当社基準の頻度での棚卸しを定期的に行うことで健全なセキュリティを保ち、コスト管理を実現します。

今回やらなかったこと

今回はスピーディに実装する必要があったため、以下の点をやらない判断をしました。

• パスワード同期
• マルチマスタ構成

上述の通りパスワード管理はGoogle Appsに委譲し、認証情報をリアルタイムに同期する必要をなくしました。パスワード同期（正確にはActive Directoryからのみのパスワード変更処理）を実現するにはGAPS（Google Apps Password Sync）が必要で、更にActive Directoryでパスワード管理することでセキュリティ要件が高まり、且つパスワード変更I/Fの構築が必要になる……などの追加要件があるため今回は見送りました。いずれSSO（Single Sign-On）などの利便性向上の施策と合わせて実施するのが良いかなと、個人的には考えています。

マルチマスタ構成は、パスワード管理やSSOなどのリアルタイム処理を不要としたことで、ミッションクリティカルではないと判断して導入を見送りました。同時にいずれ上の要件を実現する際は必要になりますが、それはその時ということで。

まとめ

今回はActiveDirectoryとGADSを使ったGoogle Apps運用について書きました。

まだまだ十分ではありませんが、今後のためにディレクトリ・サービスを分割した拡張性と、ユーザーが不便を感じない程度のサービスレベルにできたことで、初期要件は問題なく満たせたかと思います。一方で、サービス運用のルール策定やEUS（End User Support）は、企業のカルチャーや多数のユーザーニーズにフィットさせるために多くの時間が必要で、ユーザー装着への取り組みに終わりはない、という印象です。

今後は、Google Appsの利用促進（実はこれが一番大切なことだったりします）、Active Directoryの活用によるユーザーID管理の進化などに取り組んでいきたいと思います。