ID/共通管理チームは「のびしろ」だらけ！これからやりたいことを一部紹介します！ #のびしろウィーク

こんにちは！ID/共通管理チームの id:convto です。ほんとは日曜日の担当だったんですが気づいたら火曜日になってました。不思議なことってあるんですね。今後は精神統一して乱れを正していきます。

あとぼくはとにかく猫が大好きなんですが、住んでる物件の都合で飼えない！とかなんだかんだ縁がなくてかれこれ3年くらい経ちます。運命を引き寄せるためにキャットタワーだけ先に買うか迷っているのでだれかアドバイスください。たぶん買ったほうがいいと思っている。

この記事は LayerXテックアドカレ2023 の33日目の記事です、前回は id:ar_tama さんが「成長サイクル」でVUCAの時代を乗りこなす、というタイトルで登壇しましたという登壇記事を書いてくれました。次回は id:yu-ya4 がML領域の課題を書いてくれるそうなので、楽しみにしていてください！

今回はのびしろウィークということで、所属しているID/共通管理チームの伸びしろをいろいろとお伝えできればと思います！

のびしろウィークとは

のびしろウィークとは、LayerXの各チームメンバーが自分たちのチームの伸びしろについて対外的に発信する期間です！過去の対外的な発信では社内でうまく行った事例などについては各種発信していましたが、どういう課題があってどういった方の協力を求めているかについての発信はあまり行なっていませんでした。

もちろん多くの企業と同じように不確実な市場で事業に向き合っているため、うまくいったこともあれば、これからもっと整備したい部分、いわば「のびしろ」もたくさんあります。今回はID/共通管理チームが抱えるのびしろについてご紹介させてもらえればと思います！

のびしろをざっと読んでみて、「その課題、一緒に取り組んでみたい！」とすこしでも思っていただけたら、ぜひ気軽にご連絡ください！

ID/共通管理チームとは

ID/共通管理チームは最近立ち上がったチームで、認証まわりや組織構造管理などを責務としています。 (今回はあまり触れませんが、ほかにもいくつかのマスタデータの管理や、監査関連の機能などプロダクトを横断するような機能群も提供しています。やることいっぱい！)

具体的には従業員などのユーザー情報の識別とアカウント管理をおこなうようなサービス群などの機能開発/メンテナンスを行なっています。

これらの機能はいままでは広く各プロダクトのメンバーで機能開発していましたが、プロダクトが増えて連携も複雑化していく中で、オーナーシップを持ったチームを立ち上げよりよい価値提供を目指すためにチームが立ち上がりました。

チームは小さくはじめており、現時点ではPM1名、EM1名、エンジニア1名の計3名のチームです。チームが立ち上がったことでオーナーシップが明確になり機能開発がスムーズになったり、関連機能にしっかりと定期的に手が入るようになったり、中長期的なあるべき整理の議論が始められたりと、早速良い影響をいくつも感じています！

ですが、そういったよい部分は今後別の機会でお話しするとして、今回はチームの伸びしろについての書ければと思います！

柔軟な認可制御

認可周りは複数プロダクトの展開にあたって少しずつ課題が出始めています。
現時点の仕組みとしては、roleベースで可能な操作とのマッピングが定義されていてRPC定義のタイミングで必要とするscopeを明示するような仕組みになっています。

この仕組みでも十分機能しますが、プロダクトを跨いだ複雑な機能などで課題が出てきています。
たとえば「あるプロダクトを利用できるroleが付与されていないが、ユースケースを考慮すると一部機能は利用したい」などのケースです。

付与されたroleでは別プロダクトのscopeがなく業務を遂行できない例を以下に示します。 (この例では「申請・経費精算」と「プロダクトB」は独立した個別のプロダクトとして捉えてください)

上記の例ではユーザーがプロダクトBの権限を持たないので一見期待する正しい挙動のように見えますが、申請承認者の場合は承認対象のデータを確認する必要があり、それが別プロダクトでかつ権限がなかったりすると元データが確認できず業務が遂行できなくなります。

では申請承認者role全体にプロダクトBをreadする権限をつけて良いかというと、そのプロダクトを契約しているかなど、いくつかの別の(場合によっては複数の)リソースの値によって権限の有無が規定されるようなユースケースがあります。

以下はrole + それ以外の複数要素によって規定される権限の簡易的な例です。(実際のプロダクトではより複雑な部分もあります)

このようなケースではroleベースの管理を超えてしまっているので、アプリケーション側でリソース取得、権限判定を行なっているようなケースが存在します。複雑なロジックなども存在し、認可に関する問題が構造上おきやすくなっています。

いくつかのアプローチを検討していますが、現時点ではまだ課題を認識して動き始めたばかりです。Zanzibarのようなグラフで関係性を持たせて網羅的な認可をするようなものも話題には上がっていますが、まだ検証などもできておらずどういった着地になるか現時点では不明です。

個別リソースの関係性によって権限が規定されるケースがある以上、一定のプロダクト固有の業務知識のようなものもあり、どのラインまで中央集権的に持つかも議論中です。

ユーザーの業務性質によるアカウント種別についての探索がまだできていない

ユーザーとその業務をみつめるうえで、典型的にはいくつかの性質を持ったユーザー種別がありそうなことを認識しています

企業の従業員。企業からアカウントを発行され利用する。基本的にはほとんどの割合がこのタイプ
税理士などの方で、外部のtenantに招待され業務のために利用する。そのtenantに従業員として所属しない場合がある
- 念の為補足すると、バクラクシリーズは各サービスで会計周りや監査に関する情報を管理する場合があり、税理士の方が利用することがあります
業務委託やアルバイトなど、契約関係はあるが従業員として所属しないケース。企業が発行するメールアドレスが割り当てられなかったり、それにともなってSSOなどが利用できないこともある

まだまだ業務への観察がすすんでいないですが、おそらくほかにも異なった利用傾向があるユーザーがいると思います。これらのユーザーはそれぞれアカウントの扱い方や、関連する業務のために必要とする機能などに違いがあります。

ここでは例として税理士の方の利用の仕方に着目してみます。多くの場合で企業から発行されたemailなどを利用していないでしょう。また、招待された各tenantにて業務を遂行するために都度参照権限の割り当てなどが発生するでしょう。ここには以下のような課題が存在しそうです。

企業が発行するアカウントを不所持な場合がありSSOが利用できない。tenantによってはセキュアな利用のためにSSOでしかsign inできない設定を有効にしているので、税理士の方がいると運用が特殊になる(専用のtmp accountを発行するなど)
- 税理士の方は直接所属しているわけではないので、SSOのみ設定でもemail/passにてsign in可能にする、もしくはその挙動をtenant側に選択可能にさせるなどの整理を検討できそう
税理士の方も現時点での扱いは一般ユーザーと同じなので、通常通りの権限の設定が必要
- もしかしたら「税理士ユーザーな時点で所属チームなどとは関係なく申請を閲覧可能にしてよい」などの整理によって業務を減らせるかも

ユーザー種別などの概念を導入することで個別具体的な要求に応え、より顧客の業務をバクラクにしていける伸びしろがありますが現状はまだできていません。

現時点ではそれぞれのユーザー種別を区別しておらず、利用傾向などから顧客の業務をみつめ情報を集めている段階です。

組織データの連携機能をより充実させたい

だいたい従業員と部門/チームを管理しているのは(しっかり管理できる情シスの方などが整備していればことさら)バクラク以外の別のソフトウェアだったりします。

Microsoft Entra ID(旧Azure AD)やGoogle Workspace、またはSmartHRなどの各種ツールによって管理していることが多いと思います。組織構造を社内ツールで管理する例などもあると思います。

バクラク共通管理はバクラクシリーズを使っていただく上での玄関になるようなサービスであり、ほかのプロダクトできめ細やかな可視性の制御を行うためにはこれらの組織構造にまつわる情報を登録する必要がありますが、現時点で対応しているのはCSVでの取り込み、およびUIを通しての編集/作成のみです。

より幅広いユースケースに対応するため

外部ソフトウェアとの連携
APIを通じての連携

などを検討し進めていきたいですが、いまはまだ機能が足りていないのが現状です。

また、バクラクが管理している組織構造は各種サービスでいくつかの権限の判定に利用されているケースがあります。「ある部署より上位のチームに所属していれば閲覧が可能」などはその典型ですね。つまり、構造と権限が密に繋がっており 実現したい可視性などの権限制御に合わせてチーム構造を変化させる 必要がある場合があります。

外部からの組織情報の取り込みを考えると、ユースケースによってはただ取り込むのみではダメで、付与したい権限などに合わせて適宜変換などが必要になる可能性があります。

いくつか複雑な要件があることが見込まれるので、顧客の業務に寄り添って、より業務を減らせる方向の仕様検討をしたいなと考えています。

あと単純にUIをポチポチしたりCSVに変換するスクリプトなり準備したりメンテするの面倒ですよね。いろいろ難しい話は抜きにしても、気がついたら組織情報が連携されて利用できる状況が整っていて、組織情報に変更があったら勝手に追従してくれる世界観のほうがより業務が減らせるので、もっとそういう方向に持っていきたいと思っています！

オブザーバビリティ

ID/共通管理チームがメンテしているシステムは認証処理などが絡むため、各プロダクトのなかでは相対的にシステムの可用性に対する要求が強いプロダクトです。そのため、異常の検知やシステム状態の観測ができる状態を(いまでもできている部分はありますが)より整えていきたいです。

異常の検知については、最近チーム内でSLOを作成すべくCritical User Journeyの整理を進めていたり、ただいま絶賛整理中の部分です。現時点でもいくつかのメトリクスに基づいたアラート設定などは行われており、実際に問題を検知できた実績もあります。
しかし、理想としては問題が起きていたらリリース後すぐ開発チームが異常を検知してアクションが取れたりすることを目指しているので、ここにはまだギャップがあります。

主要な観点の整理や閾値の調整、偽陽性の排除などを通してより確実に、より素早く異常をキャッチできる土台を整えていきたいと思っています。このあたりはシステムをより良くするための改善を行う改善デーなどを機会を通して少しずつですが改善を進められているので、手を止めずにより良い状態にしていきたいです。(余談ですが改善デーは多くのチームでうまくワークしてる仕組みなので、そのうち誰かが記事にしてくれると思います。ご期待ください！)

また、異常の検知だけでなく、システムの状態を観測できる状態もより整えたいと考えています。
例えばある処理が中断されたとき、どこまで処理が進んでいて、DBはどういう状態になっていて、それをうけて開発者はどのようなリカバリをすれば良いかが発生した事象に合わせてすぐわかるような状態を目指したいです。

ミッションクリティカルな機能などについては次のアクションやリカバリ手順、リカバリに必要なデータを明示したlogなどを出したりしていますが、こういった実装や整理をいまよりも広い範囲に適用させてよりメンテナンスしやすいアプリケーションにしていきたいです。

まとめ

ID/共通管理チームは最近立ち上がったチームですが、オーナーシップが明確になったことで機能開発がスムーズになったり、しっかりと定期的に手が入るようになったりと、早速良い影響を感じています。

しかし、今回紹介したようないくつかの伸びしろを抱えており、これからもっと頑張っていい価値を提供していくぞ！という状態です。

典型的には

より柔軟な認可の提供
組織データの連携機能の強化
ユーザーの業務性質によるアカウント種別の整理
オブザーバビリティ

などが大きいのびしろです。

逆にいうと、いままで専任チームがいなかったこともありこれらの部分についてはかなり素朴な実装となっている箇所もあり、「よりよい仕組みの導入」がとてもしやすい状態だと思っています。

現在のID/共通管理チームには事業の性質や顧客からの利用のされ方を見つめて、よりよい形でソフトウェアを設計して適用していく機会が多くあります。過去似たような問題領域に向き合った方が能力を発揮できる場もあるでしょうし、そうでなくとも事業やソフトウェアの性質に合わせて新しく検討する部分が盛りだくさんなので、まだ見ぬメンバーと一緒にもっと良くしていきたいです！

冒頭でも言及しましたが、「その課題、一緒に取り組んでみたい！」とすこしでも思っていただけたら、ぜひ気軽にご連絡ください〜！

これは僕個人の気持ちですが、やっぱり顧客にとって使いやすかったり価値を提供できたりするソフトウェアを作っていきたいので、いまよりどんどんよいものを作っていくサイクルをずっと回していきたいと思っています。やっていくぞ〜

今回はいくつかの課題を紹介しましたが、このような検討を進められていること自体がチームを立ち上げた大きいメリットの一つだと思っているので、しっかり価値提供まで繋げていきたいです。