皆さん、こんにちは。カミナシの認証認可ユニットでソフトウェアエンジニアをやっているトモ=ロウです。
この記事は、共通ID基盤の構築について解説した連載記事の後編です。まだ前編を読んでいない方は、ぜひそちらからご覧いただくことをお勧めします。
前編はこちら: スタートアップがゼロから作る共通ID基盤：立ち上げ〜ID統合まで道のり（前編）
後編では、真の共通ID基盤を完成させるための最後の関門である、「ログインフローの統一」と「ユーザー管理機能の統一」への道のりをご紹介します。
「ID統合」という言葉は厳密な定義がなく、一般的には
- 複数存在する「認証処理」や「ユーザー管理機能」を一つの基盤に統合すること
- 同一ユーザーが持つ複数のユーザーアカウントを一つのユーザーアカウントに統合すること
のどちらか、あるいはその両方を行うことを指すようです。本記事では前者の『複数存在する「認証処理」や「ユーザー管理機能」を一つの基盤に統合すること』を指す言葉として用いています。
後者の『同一ユーザーが持つ複数のユーザーアカウントを一つのユーザーアカウントに統合すること』に関する内容は取り扱っていないのでご注意ください。
前編の第3章の時点では、『カミナシ ID管理』はOIDCに準拠した最新の認証基盤として稼働を開始したものの、既存の主力プロダクトである『カミナシ レポート』では、独自の従来型ログインフローが利用されている状態でした。これを『カミナシ ID管理』のOIDCに準拠したログインフローに移行することを目標に掲げたプロジェクトが2024年4月にスタートしました。
移行の基本方針
まず、我々は移行に伴う技術的な複雑性を下げるために、既存のセッション（ログイン状態）の引き継ぎは行わないという意思決定を行いました。
認証処理に手を加える際のセッションを引き継ぐ・引き継がないの判断にはいくつかの材料があると思いますが、『カミナシ レポート』の場合はセッションの有効期限があり、多くのユーザーにおいて連休などのタイミングで定期的に再ログインが求められることが分かっていたため、ユーザーに再ログインを要求するハードルが比較的低かったと言えます。
逆にセッションの有効期限が長く、ユーザーが再ログインする機会がほとんどないようなサービスの場合、ある程度開発工数をかけてでも再ログインなしで移行できるような設計が必要になるかもしれません。
上記の意思決定を踏まえて、以下のステップを計画しました。
- 『カミナシ レポート』で『カミナシ ID管理』を利用した新認証機能をリリースする
- 『カミナシ レポート』の旧認証方式のエンドポイントを停止する
- 『カミナシ レポート』の旧認証方式で発行されたセッションを全て無効化する（古い方式で取得した有効なセッションをもつユーザーはこのタイミングで再ログインが求められる）
Webアプリの移行
『カミナシ レポート』には管理者がレポートの雛形（現場でレポートを記録する際のテンプレートのようなもの）を作成したりする際に使うWeb管理画面があります。このWeb管理画面移行は、この基本方針を素直に実施することで完了できました。新認証機能をリリース後、ユーザーが次にアクセスしたタイミングで新しいログイン画面が表示され、再ログインしてもらうことで大きな混乱なく新方式への切り替えが実現しました。
モバイルアプリの移行
『カミナシ レポート』には上述のWeb管理画面以外に、現場の記録業務に使うためのモバイルアプリも提供しています。
モバイルアプリはWebアプリとは異なり、ユーザーがアプリをアップデートするタイミングをこちらでコントロールできないため、旧方式のエンドポイントをすぐに停止できません。 古いバージョンのアプリは旧認証方式に依存しているため、もしエンドポイントを閉じてしまえば、アプリを更新していないユーザーは即座にサービスを利用できなくなってしまうためです。
この問題を解決するためには、技術的な対応だけでなく、お客様にアプリをアップデートしていただくためのコミュニケーションや、ユーザーがアプリをアップデートするための十分な猶予期間の設定が必要でした。具体的には、ユーザーへの告知を通じて計画的にアップデートを促し、事前に定めた期限をもって旧方式を停止する、という段階的な手順を踏むことで、この問題を乗り越えました。
最終的なモバイルアプリにおける移行ステップは以下のような形になりました。
- 『カミナシ ID管理』を利用した新認証機能をリリースする
- ユーザーにアプリのアップデートを促す告知を行う
- 一定の猶予期間が経過したのち、旧認証方式のエンドポイントを停止する
- 旧認証方式で発行されたセッションを全て無効化する
ログインフローの統一は完了しましたが、まだ大きな課題が残っていました。それがユーザー管理機能の統一です。ID統合プロジェクト最後の山であるユーザー管理機能の統一プロジェクトが2024年9月に発足しました。
なぜこのタイミングなのか
前編の1-2章ではユーザー情報の移行プロジェクトを紹介しました。なぜそのタイミングでユーザー管理機能も移さなかったの？と思われる方もいるかもしれません。データ移行のタイミングでユーザー管理機能を統一することは技術的にはもちろん可能ですし、むしろその方が前編で紹介した「ダブルライト」などの仕組みを一時的に構築する必要もなく、シンプルにプロジェクトを進めることが可能です。
結論から言うと、本プロジェクトがこのようなタイミングで発足した直接的な要因は、「その時点では『カミナシ ID管理』に十分なユーザー管理機能が存在しなかったこと」です。では、なぜ急いでユーザー管理機能を作らなかったのか、「ダブルライト」の設計や実装をしている時間があれば基本的なユーザー管理機能は作れたのではないか、という疑問が浮かぶかもしれません。
「ユーザー管理機能」はID管理システムのコアドメインです。「マルチプロダクトSaaSにおける理想のユーザー管理体験は、単一プロダクトにおけるそれとは異なるはず」というのが当時の我々の仮説でした。モノリシックなプロダクトが持つユーザー管理機能というのは、大抵はそのプロダクト特有の要件が暗黙のうちに組み込まれています。既存プロダクトの移行を見据えて急いでユーザー管理機能を設計することは、そういった仕様を無意識に共通基盤に持ち込むことに繋がるのではないかと考えたのです。
- 識別子の競合など、データ移行が遅れることによる懸念（詳しくは前編で！）
- フラットな視点でユーザー管理機能を設計したい気持ち
これらのバランスを取った結果、ユーザー移行とユーザー管理機能の移行を分けて行うプロセス設計になりました。
一方で、この選択によって引き起こされた問題もありました。
クロスセル問題
『カミナシ 従業員』をはじめとする新規プロダクトは始めから『カミナシ ID管理』を使ってユーザーを管理する想定で作られています。一方で『カミナシ レポート』は自身がユーザー管理機能を提供していました。
もし『カミナシ レポート』とその他の新規プロダクトを併用する場合、新規プロダクトを利用するユーザーは『カミナシ ID管理』で管理し、『カミナシ レポート』を利用するユーザーは『カミナシ レポート』のユーザー管理機能で管理する、といった一貫性のない体験をお客様に強いることになります。
また、上記の図からも分かる通り、『カミナシレポート』のデータベースの情報が更新されるのは『カミナシレポート』の管理画面を経由して操作した時のみです。もしお客様が間違えて、『カミナシ レポート』のユーザーを『カミナシ ID管理』上で操作してしまった場合、『カミナシ レポート』と『カミナシ ID管理』の間のユーザー情報の整合性が壊れてしまう問題もあります。
このような背景から、ID統合プロジェクトは、
『カミナシ レポート』のユーザー管理機能が『カミナシ ID管理』に移るまでは新規プロダクトと『カミナシ レポート』を同一のお客様に販売することはしない
という前提で進められていました。
ところが、カミナシの二つ目のプロダクトである『カミナシ 従業員』がリリースされて間もなく、『カミナシ レポート』と『カミナシ 従業員』の両方を契約するお客様が登場しました。これはエンジニア、PM、セールスなどの関係者の中でうまく情報共有ができていなかったことが原因で起きてしまった問題ですが、その原因を追求することよりもまずは上記の問題を起こさないためにはどうすれば良いかを考えなくてはいけませんでした。上記の問題をより簡潔に表現すると以下の三つになります。
- ユーザーは自テナントのユーザー管理のために二つの管理画面を使わなければならない
- ユーザーは『カミナシ レポート』と『カミナシ 従業員』で別のユーザーアカウントを使わなければならない
- 『カミナシ ID管理』上で『カミナシ レポート』のユーザーを操作してしまうとデータの不整合が発生してしまう
これらのうち1と2に関しては、もちろんお客様にご不便をおかけすることにはなりますが、その点さえ許容していただければ問題ないとも言えます。一方3に関しては深刻な問題です。一度不整合を起こしてしまうとそれを修正するのは非常に困難です。
この問題に対して我々は「『カミナシ レポート』のユーザーを『カミナシ ID管理』の管理画面上に表示させない」というアプローチを取りました。
「表示されないユーザーを操作することはできないため、データ不整合が起きない」
という極めて単純かつ強引なやり方ですが、こうすることでデータ不整合を引き起こすような致命的な問題は全て回避できることが分かりました。
このように、ユーザー管理機能の統一を後回しにしたことによって発生した問題は徐々に無視できないものになっていきます。幸いにもデータ移行から一年弱が経過し、『カミナシ ID管理』のユーザー管理機能は成熟していました。もうユーザー管理機能の統一を躊躇する理由はありませんでした。
非同期メッセージングによるプロビジョニング
目指したのは、「すべてのユーザー情報は『カミナシ ID管理』を正とし、『カミナシ レポート』はそれを参照 or 同期する」という世界です。 これを実現するために、我々は以下の二つの方法を考えました。
- 『カミナシ レポート』がユーザー情報が必要なタイミングで『カミナシ ID管理』のユーザー情報APIを呼び出す
- 『カミナシ ID管理』側でユーザーが追加・編集・削除されたタイミングでメッセージを発行し、非同期で『カミナシ レポート』が持つユーザーデータを更新する
まずはよりシンプルな 1. の方法を検討しましたが、『カミナシ レポート』はもともとユーザー情報を内包しているプロダクトだったため、あらゆるデータがユーザー識別子を外部キー制約として持っている状況でした。例えば、ある「記録」を行ったユーザーが誰であるか、その「記録」を「承認」したユーザーが誰であるか、などの関連が同一データベース上に存在する「ユーザー」テーブルとの外部キー制約によって表現されており、それらの関連付けは参照時のテーブル結合によって行われていたのです。そういった関連付けは、当時の調査によって50以上の処理で実施されていることが発覚しました。
それらをすべて剥がして『カミナシ ID管理』へのAPIコールに置き換えることは現実的に難しいという判断になり、本プロジェクトでは2.の非同期メッセージングを利用した方式を採用することとなりました。
技術の壁と、もう一つの見えざる課題
我々は当初、本プロジェクトを純粋な技術課題として捉え、上記の解決策の設計・実装を進めていました。設計・実装ともに計画通りに進行し、リリースが見えてきた段階でもう一つの見えない壁が立ちはだかりました。それは「お客様の管理体験が変わることに対するビジネス面の強い懸念」です。
「なぜこのタイミングなのか」でも言及したように、『カミナシ ID管理』はカミナシの全プロダクトのユーザーが利用することを想定して設計されています。つまり、ユーザー管理機能を『カミナシ ID管理』に移すということは、
- 『カミナシ レポート』に最適化された機能ではなくなる（今までワンクリックでできたことに、より複雑な操作が要求される など）
- 『カミナシ レポート』単体で利用するお客様には不要な機能が存在する
ということになります。
長年慣れ親しんだ管理画面の操作フローが変わることは、お客様にとって大きなストレスになり得ます。最悪の場合、そのストレスがサービスへの不満につながり、契約解除のリスクすら考えられました。この懸念は我々が技術者として想定していたよりも根深く、リリース計画は当初の想定よりも大幅に時間を要することになりました。
実を言うとこの問題への対処がこのプロジェクトの中で最も困難な課題でした。「とにかくこのプロジェクトを完遂させたいエンジニア」と、「顧客への影響を考えて待ったをかけるCustomer Succsessチーム」の対立構造になりそうな瞬間さえあったほどです。互いの主張を理解するために本プロジェクトに関する対話の機会を増やしました。我々開発チームはCSチームに対してこのプロジェクトの意義を説明し、CSチームは我々に対して少しでも既存顧客への影響が少なくなるよう建設的なフィードバックをくれました。リリース計画も見直して比較的影響度合いが少ないお客様から段階的にリリースすることを決定し、最後は無事にリリースを迎えることができました。
この一連の経験は、我々にとって大きな学びとなりました。段階的なリリースによって大きな混乱は避けられましたが、今振り返ると、「もっとスムーズな移行のために、技術者としてやれることがあったはずだ」という反省の念も残ります。 例えば、新旧両方のUIを一定期間併用できるような設計にするなど、お客様の負担を技術でさらに軽減する工夫ができたかもしれません。機能開発は、コードを書くだけでなく、それがお客様に届き、受け入れられるまでの全プロセスに責任を持つことなのだと、改めて痛感させられました。
本件に関して、我々開発チームが事前に十分な説明をせずに進めたにも関わらず最後まで付き合ってくれたCSチームには感謝しかありません。
約2年半にわたる開発の末、ゼロから始まったID統合プロジェクトは一旦の区切りを迎えました。初めはエンドポイントがたった二つのAPIサーバだった『カミナシ ID管理』は全自社プロダクトを支える認証基盤へと進化しました。
しかし、我々の挑戦はまだまだ続きます。プロジェクト完遂後も開発を続け、多要素認証（MFA）への対応や、ユーザーの所属情報（部署、役職など）の管理機能を拡充させてきました。今後もお客様によりセキュアで、より良い体験を提供できるID管理システムを目指し、さらなる改善施策を計画しています。
もし本記事で紹介した内容に少しでも興味を持たれた方がいれば、ぜひ一緒にチャレンジしてみませんか？カミナシの認証認可ユニットではソフトウェアエンジニアを募集しています。
本記事の内容が同じようにマルチプロダクトの壁に直面している開発者の皆さんの参考になれば幸いです。
最後までお読みいただき、ありがとうございました！
