立ちはだかった3つの課題に向き合いながら、「理想のIDPのあり方」を軸に全社的に整合性が取れた解決方法をつくる

2021年10月から、サービス・機能開発の基盤を強化するRFSプロジェクトを始動したメルカリ。

RFSとは「Robust Foundation for Speed」の略で、メルカリグループ全体の非連続的な成長を支えるため、ビジネスの共通基盤に潜む複雑な技術的課題の解決と抜本的な強化を図るのが、RFSの目的だ。

プロジェクトスタートから1年以上が経ち、いまプロジェクトはどのように進捗しているか。RFSにおいて3つを注力する領域、「C2Cトランザクション」「IDプラットフォーム」「CSツール」をそれぞれ担当するチームのキーパーソンたちに、プロジェクトにおける課題とそれにどのように向き合ってきたのか、3回にわたってうかがっていきます。第3回は「IDプラットフォーム（以下、IDP）」の領域を担うIDP Teamの狩野達也（@kokukuma）と大井光太郎（@koi）に、メルコインのリリースをドライバーに進めてきたプロジェクトの現在地、そしてメルカリグループにおけるIDPの重要性について聞きました。

IDが絡む諸問題に対して、全社的に整合性が取れた解決方法をつくる

──まずは、IDP Teamのミッションと、おふたりのそれぞれの役割を教えていただければと思います。

@kokukuma：メルカリグループのサービスに対して適切な認証、アクセス制御、データプロテクションを標準的な形で導入することをミッションとしています。

自分の肩書きとしてはTech Leadになるのですが、いわゆる世間一般のTech Lead像みたいなところにはあまりマッチしていないと思います。おもな役割としては、メルカリグループにおいてIDが絡む諸問題に対して、全社的な整合性が取れた状態に持っていくことだと認識しています。一般的に解決方法が見えている部分はそれを適用するように促したり、まだ目処が立っていないような部分の解決方法を検討したりしています。

このような解決方法を検討するときには、チームとしての方向性の設計はもちろんですが、他のチームが取り組んでいること、これから進めようとしていることを把握して、IDP Teamとして持っている「理想のIDPのあり方」が、グループ全体の動きとマッチしてるかどうかを見極めて、もしそこにズレがあるなら自分たちの理想をアップデートなり、チューニングするということを行っています。

そして、こうした動きを、僕だけがやるのではなく、IDP Teamとしてこの動きをスケールして行えるようにすることも、自分の役割の一つだと思っています。

狩野達也（@kokukuma）

──では、koiさんの役割は？

@koi：自分の役割はPdMなのですが、kokukumaさんとある意味同じで、いわゆるPdM的な動きをしているかというと若干違くて（笑）。チーム外とのやり取りみたいなところは、既にkokukumaさんが第一線に立ってくれているので、何が必要な情報なのか一緒に動きながらキャッチアップしています。

それ以外だと、さまざまなプロジェクトのスケジュール調整だとか、チームとしてのロードマップ策定だとかを、いかにエンジニアの手を煩わせずに進めていけるかを考えています。だから、いま現在は「プロダクトマネジャー」というより「プロジェクトマネジャー」寄りの仕事なのかもしれません。特に直近で言うと、FIDO関係のプロジェクトに深く関わっています。

立ちはだかった、IDPの3つの課題

──IDPの領域における、RFSの課題について改めてうかがいたいと思います。

@kokukuma：前提として、IDP TeamではTransaction TeamやCS Tool Teamと異なり、「RFSのため”だけ”に使う時間」というのはあまりないんです。 他の重要度の高いプロジェクトとRFSを天秤にかけて優先度を決めるということはせず、「プロジェクトを短期的なドライバーとして、中長期的に実現したいこと漸近的に実現する」という形をとっています。その意味では、ある意味すべてのプロジェクトがRFSに繋がっているとも言えます。

IDP関連するところで、RFSの目的に合致してる部分の課題はおもに3つです。

・ 社内で利用可能な認証・認可に関連するアーキテクチャパターンが不明確
・ Access Tokenの権限を制限する機能の不十分
・ 開発者が自分でOAuth Clientの設定をすることができない

まず1つ目から説明していきます。「社内で利用可能な認証・認可に関連するアーキテクチャパターンが不明確」についてですが、社内において認証認可をどう使うべきかというアーキテクチャのパターンが明確ではない。それによって、他のチームがメルカリメルペイの機能を使った新しいサービスを作りたいとなった時に、どういうオプションがありどういう特性があるのかわからないまま判断しなければならないという状況です。この場合たいてい、自分が知己のある人・サービスの話を参考にして決めることになるので、その参考にしたサービスが持っている負債もそのまま引き継ぐという状態になっています。

2つ目は「Access Tokenの権限を制限する機能の不十分 」というところです。IDP Teamが外部用にアクセストークンを発行しているのですが、これまでは制限の仕組みがあまり十分ではなかった。「十分ではなかった」と表現すると適切ではないのですが、その時点のユースケースにおいては十分だったけど、それを拡張して他のところでも使っていくという面に関して言うと、十分ではなかったという状態がありました。それをそのままにしていると、新しいサービスでメルカリ・メルペイのIDPを使いたい時に、安全に実行することが難しい。それがRFSを推進していくにあたって、大きな問題になっていました。

3つ目は「開発者が自分でOAuth Clientの設定をすることができない」ところです。トークンを発行する前提として、このOAuthクライアントの設定をしなくてはいけないのですが、他のチームが新しいサービスでAPIを使いたい時に、IDPに対してリクエストを送られてくるのですが、その設定をIDP Teamが手動で行っていました。

その都度、「アーキテクチャをどうするか」とか「こういうケースだったらクライアントの発行が必要だ」など、チームで議論をしながら決めているのですが、リソースにも限界があり、リクエストを捌ききれない状態になっていました。しかし、リクエストする側からすると、そもそもコミュニケーションすること自体が面倒ですし、リクエストが実行されるのを待つ時間ももったいない。ここの設定をIDPのチームのメンバーが手動で行うこと自体が、RFSで問題視してるところと完全に合致しています。

──かなり複雑な課題が立ちはだかっていたわけですが、プロジェクトスタート時からどのように進捗していますか？

@kokukuma：現状、2つ目と3つ目の課題はだいぶ解消してきていますが、1つ目は少し根が深くなっています。先ほどもお話したように、基本的にIDP TeamはRFSのためだけに時間を使うということがなく、他のプロジェクトをドライバーにして何かしら設計をしていく、その設計をしていく上でRFSで推進すべきことを盛り込んでいます。

ここ1〜2年ぐらいドライバーにしてきたのはメルコインのリリースです。開発を進める中でいろんな機能がつくられてきたことによって、さきほどの2つ目と3つ目の問題は解消しつつあります。例えば、「メルペイ−メルコイン間の通信におけるアクセス制限の必要性」は、課題の2つ目のアクセストークンにおける権限制御の機能を作る強いドライバになりましたし、「メルコインにおいて複数の設定が複雑なOAuth Clientを作成する必要性」は、課題の3つ目のOAuth Clientを各チームで簡単に作成し、現状を簡単に知ることができるようにするための基礎になる部分を進めることができました。一方で、今までにはないビジネス上の要求を満たすために、これまでメルカリ内にはなかった概念が導入され、状況がより複雑になっているので、課題の1つ目の部分が解消していないという状態です。

──なるほど、一筋縄ではいかなさそうですね…。では、課題が解消されつつあるなかで新たに取り組んでいることはありますか？

@kokukuma：目下取り組んでいることは、FIDOとクライアントアプリケーションで使っているアクセストークンのマイグレーションですね。これはRFSの文脈でも意味のあることで、これから新しいサービスを作ろうと考えた時、基本的にはお客さまに新たなアプリを入れていただくとか、何かしらの別のサービスを使っていただくような形にせずに、メルカリアプリ内で既存の機能が同じように使える状況を実現していきたい。それは、メルコインだけに限らず、今後出てくる新しいサービスでも基本的に同じような要求を持っていると考えられます。

今回、メルコインにおいて、異なるセキュリティレベルのサービスであっても、そのサービスを使う前にFIDOで認証をして、新たに強い権限を持ったトークンを取って、メルコインに利用するというプロセスがひと通りできるようになったのは大きい。他のサービスにおいてもそういう流れはできるようにしていきたいです。

また、FIDOやアクセストークンのマイグレーション以外にも、他のカンパニーが計画しているプロジェクトがいくつもあるので、それらを安定してサポートしていけるようにしたいと思ってます。それ自体は、もちろん事業のためではあるんですけど、IDP Teamとしての「理想のIDPのあり方」というものに則してのことなんですね。自分たちの理想をアップデートするという意味でも、アーキテクチャが不明確な状態を解消する意味でも、IDP Teamとしての考え方は伝えつつ、一つひとつ丁寧にコミュニケーションしていき、プロジェクトにおける懸念を解消していくことが重要かなと思っています。

──IDP Teamが関わるプロジェクトは、時間軸が異なるものが混在しているような印象ですが、それらはどのように優先度を整理しているのでしょうか？各カンパニーのそれぞれの要望の熱量は高いと思いますが。

@kokukuma：そこは結構難しいところですね（笑）。今までは明確にメルコインがあったから、それを最優先にすることができましたが、メルコインほどの規模ではないけれど、各カンパニーにとって重要なプロジェクトはいくつも存在します。それらの優先順位をつけていくのは本当に難しいところです。

ひとつの解として、IDP TeamではQごとにロードマップを作るようになりました。最近スタートしたばかりなので、まだ完全にワークしてはいないのですが…。現状、IDP Teamが認識している各カンパニーのプロジェクトをQという短いスパンではなく、2〜3年ぐらいの中長期で整理したロードマップを策定してオープンにしています。それに対して、他のチームからの視点で「IDPの領域においてこれが抜けてるのではないか？」という意見をいったん受け入れて、それをアップデートしていく運用をしていこうと思ってます。

IDの技術者として、今このフェーズにメルカリで働くということ

──今後、IDP Teamとしてどんなことを目指していきたいと考えていますか？

@koi：グループ全体からIDP Teamのミッションや目指していることが理解され、オープンになっているから相談しやすくなるというのは、今後注力していきたいと思っていています。「こういう機能ができるようになります」みたいな話は、ロードマップでも情報はオープンにしているんですけど、やはり専門的な分野になればなるほど理解するのが難しいので、達成されることで何が嬉しいのかを理解してもらうための通訳が必要な部分ではあります。また、何か新しいビジネスの可能性を探っているメンバーにとって、情報が手が届きやすくすることは考えていきたいですね。

@kokukuma：それは確かにそうですね。RFSスタート時の懸念だった、アーキテクチャパターンが不明確というのは、結局ビジネスサイドだけでなく、エンジニアであってもIDPの機能がどういうもので、どういう制限があるかを理解しきれていない、あるいはこちらからも伝えきれてない状態でした。そこは解消していきたいと思っていますし、どういうユースケースにおいて使えば良いのかというのも合わせて伝えていく必要があります。既に仕組みや機能を理解している人間にとって、それがわからない人に対し上手く伝えるのはけっこう難しいところなので、その点についてはkoiさんのようなPdMが上手く伝えていってくれると期待しています（笑）。

@koi：そうですね（笑）。メルペイでいうと、PM Allhandsがあるので、そういう場でロードマップを参照しながら、IDP Teamとしてこういうことを考えていて、行く行くはこういう機能が使えるようになります、という説明はしていきたい。それはメルペイだけでなくて、マーケットプレイスはもちろんメルコインも含めて伝えていくべきですね。

また、誰でも参加可能なモーニングディスカッションを毎週開催しているのですが、そこを上手く活用する方法を考えたいですね。ちょっとした相談を持ち込みも歓迎なのですが、やはりエンジニアがいっぱいいるところにラフな相談を投げることに気が引ける部分はあると思いますし、それ以前にそもそも何をどう聞いたらいいかわからないという問題もあると思うので、そこのペインは自分たちPdMが上手く吸収していきたいですね。

大井光太郎（@koi）

@kokukuma：それに関連した話で言うと、ブログや勉強会でナレッジを共有するのも一つではあるんですけど、基本的には自分が興味ある時に調べるのが理解が進みやすいので、実際のプロジェクトでIDP Teamが絡むタイミングが知識を吸収しやすいと思います。その時にユースケースだったり、まとめた資料をすっと共有できる状態にしておきたいですね。

やっぱり、参照できるドキュメントや、プロジェクトのプライオリティが可視化されていないと、組織としても事業としてもスケールしないですよね。ロードマップやドキュメンテーションをきちんと更新して、チーム間のコミュニケーションを改善することがより求められていると感じます。

──最後に、チームとして目指す将来像と、いまIDP Teamで働く醍醐味を聞かせてください。

@kokukuma：理想像は冒頭で述べた、「メルカリグループのサービスに対して適切な認証、アクセス制御、データプロテクションを標準的な形で導入する」というミッションのとおりです。上手くコミュニケーションを改善していくことで、新しいサービスを作りたい時に、自然な形で負荷なく作っていけば、適切な認証をかけられて、かつアクセスコントロールもちゃんとできて、個人情報が意図せず漏ることもない…というのが理想状態です。

メルカリグループ全体においても、メルペイやメルコインのような認証とは切っても切れないような事業が成長しています。これから経営の意思決定においてもIDPの領域は重要視されていく状態です。サービスにおいてそこが重要じゃないと判断されたら、わざわざ汎用性まで考える必要はなく、ある意味ショートスパンのプロジェクト中心になっていくと思います。しかし、メルカリのサービスは決済や暗号資産に関わる分野なので、そこをしっかり構築しないのは会社にとってはリスクでしかなく、ビジネス継続できない状態になってしまいます。これからのメルカリの事業の進む先を考えると、技術者にとっては非常にやりがいがある状況です。

もう一つあるのは、最近はFIDOアライアンスに加盟したこともそうですが、外部のコンサルタントともコミュニケーションしているので、現状のメルカリのID関連の実装が、果たして本当に自分たちが理想としているものに近づいているのか、ある意味、第三者的に俯瞰しはじめている状態なので、目線が社内だけに閉じていない。いま、ここで働くことはIDの技術者として、将来的に確実に役に立つ、自分のキャリアを積める環境だと思います。

@koi：自分は前職ではIDのエンジニアとして働くなかで、さらにいろんな人とのコミュニケーションをとることに重きを置きたいと思っていました。そういう意味では、PdMという役割になって、いわゆる2線と呼ばれるメンバーやCSのメンバーなど、領域を横断したプロジェクトのステークホルダーとも相対して進めていくことのおもしろさを実感しています。広いコミュニケーションが求められるのは、基盤系の特徴でもあると思いますが、その中でもやっぱりID分野は人材がまだ少ないというのもあり、いずれ自分にとって必ずアドバンテージになると思います。

@kokukuma：あと、最後に強調したいのはID関連で色々議論したいけどできずにモヤモヤしてる人にとって、今のメルカリはすごくいい環境だと思います。この領域の仕事をしていると、「Refresh Token Rotationって絶対に全部のClientに適用しなきゃいけないんだろうか…」とか、「token exchangeの制限ってどこまでやれば適切なんだろう…」とか、明確な答えがあるわけじゃない疑問は色々でてきますが、そのあたりの話はそもそも話が通じる人が少なく、自分が何を問題だと考えているかをまずよく理解してもらえない…そして、よくわからない話はたいがい後回しにされていつまでも改善されない、という状況がけっこう起こりがちだと思います。

今のメルカリでは、IDに関する興味が強い人がだんだん増えてきたので、そんな悩みに対しては同じ知識レベルで議論できる可能性が高いです。かつ、経営からの期待も感じられるので、単純に技術者としてすごい楽しいんですよね（笑）。なので、そういう自分の悩みが理解してもらえず孤独を感じている人にとっては、今このフェーズにおいてメルカリで働くことはすごい面白いと思います。