クックパッドの新規アプリ開発を支える、ユーザー決済基盤

新規アプリ開発を支えるユーザー決済基盤

宇津宏一氏：よろしくお願いします。ユーザー決済基盤部の宇津が発表させていただきます。

みなさん、モバイルアプリ作ってますか？　新しくサービス開発をやっていくにあたって、共通して必要な機能はたくさんあります。

例えばユーザ管理とか認証機能は、だいたい必要ですよね。とくにモバイル時代のユーザー管理や認証に対する欲求というのは複雑になっていて、ユーザーはサービスのアカウントを、クックパッドで言えばクックパッドアカウントでサインインしなくても、利用できるようにする必要があったり。

もちろんデータも保存できるし、後からクックパッドアカウントに登録した場合や他のアカウントでログインした場合も、サインインせずに保存していたデータが良い感じに取り扱われる必要があります。時にはユーザーのアカウントを1つに統合することもあります。加えて1つのユーザーアカウントで複数の端末で利用できるようにするのは、もはや当たり前な時代になっています。

次に、ユーザー決済基盤の観点としては、アプリ内課金も非常に重要です。アプリ内課金は、iOSやAndroidのアプリプラットフォームから提供されている決済機能です。これを用いて、例えばクックパッドば、プレミアムサービスユーザーに登録できる・解約できる機能を実装されています。そうするということは、つまりユーザー管理にも影響があります。

他にも新規にアプリを作るにあたって必要な機能の例を挙げるとキリがないのですが、今回は省略します。

これから見せるのがクライアントサイドの認証フローのステート図です。

これは普通にAPIクライアントを実装するにあたって意識したくないですよね。もちろんクライアントサイドだけではなく、サーバーサイドも同様に複雑なロジックというのが組まれるわけです。

Cuisineとは何か？

ここから本題に入っていきます。では、新規アプリ開発のたびにこれらを毎回実装するのかという話です。

アプリ開発やサービス開始をやっていくにあたって、サービスの機能開発になるべく集中したいですよね。我々はクックパッドの長年の運用で培ったユーザ管理や決済にまつわるノウハウを持っています。なので、それを有効活用して新規アプリ開発を加速したわけです。

そこで、ユーザー決済基盤部として現在取り組んでいるのが、Cuisineというプロジェクトです。

Cuisineはクライアントサイド・サーバーサイドの両方の側面から、新規アプリ開発を加速する取り組みをやっていっています。先ほど4つのアプリを並べましたが、うち3つはCuisineのシステムを利用しています。

Cuisineのクライアントサイド

まずは、クライアントサイドから話していきます。アプリ開発者がサービス機能実装に集中するためにというところで、Cuisineでは主に3つの機能をサポートするクライアントライブラリを開発しました。順番に見ていきます。

まずAPI通信ですが、なるべく認証処理を意識させないかたちにしたいので、認証失敗時には自動で再認証処理をしつつ、API通信をリトライする機能を実装しました。

あとは、プラットフォームごとに使いやすいかたちで、iOSで言えば最近はAPIKitが有名で、これに近いかたちで使えるようにしました。AndroidにおいてはOkHttpで必要なコンポーネント、インターセプターだったりオーセンティケーターを提供するかたちで、クライアントライブラリを作っています。

認証フローとアプリ内課金

2つ目、認証フローについて。

冒頭でお見せしたステート図がうっすら、もしかたら見えてるかもしれません。クライアントライブラリの認証フローはStateMachineで実装しています。加えてライブラリ標準で2パターンの認証フローを提供しているので、大半のケースはカスタマイズが不要な状態になっています。

さらに、認証フローをカスタマイズしたい場合は、StateMachineなんでStateを定義して、Stateに対応したActionを実装して、標準フローを参考にStateMachineGraphを構築することでカスタマイズができます。

3つ目がアプリ内課金についてです。

アプリ内課金というのは、iOS・Androidで仕様も作法もぜんぜん異なります。サポート面も踏まえて「こうあるべき」と言えるような処理フローを実装するには、それなりにノウハウが必要です。

クックパッドでは一連のアプリ内課金にまつわる処理フローは標準化できる見込みがあったので、社内標準化しました。正常系のフローはもちろんのこと、発生しうる異常系とそれに対するユーザーへの見せ方が整備された状態になっています。

その上で、この標準フローに沿ったクライアントライブラリをCuisineのクライアントライブラリとして提供することで、標準の処理フローに基づいてアプリ内課金を実施できるようになっています。

というわけで、Cuisineではクライアントライブラリを提供して、クライアントサイドの複雑さを吸収して新規アプリ開発を加速していっています。

Cuisineのサーバーサイドについて

では次に、サーバーサイドの話です。クックパッドではここ数年、マイクロサービスをやっていっているって状況です。要するにクックパッド本体から、徐々にサーバーアプリケーションの分離が進んでいます。

これがクックパッドアプリにまつわるアプリケーション構成です。

アプリはリバースプロキシを経由して、クックパッドのAPIや、すでに分離されているマイクロサービスにアクセスします。その先には決済基盤やユーザー基盤があります。

あくまでもこれらは、クックパッドやクックパッドアカウントを利用しているアプリ・Webから利用される前提で構築されてきました。

ここに新規アプリが出てきます。

冒頭で述べていたような課題を解決するにあたってどうしたらいいか。まず、決済サービス、決済基盤やユーザー基盤には、クックパッド固有の機能……例えばクックパッドから送られてくるメールマガジンの受信設定が挙げられます。こういったものはユーザー基盤に乗せて個別にやっていきます。

そして、ユーザ管理・アプリ内課金の定期購読にまつわるビジネスロジックを持つ、cuisine-apiを新設しました。

事前にアプリケーションの登録、サーバーサイドの設定をしていただくとこのAPIを利用できます。かつ、先ほどお話したクライアントライブラリが、すでにこのcuisine-apiとのつなぎ込みをやってくれているので、以降はサーバーアプリケーションの開発に集中できる状況になっています。

「定期購読のAPI」とありますが、アプリ内課金には、定期購読の他にも都度課金の仕組みがあります。そちらについてはサービス固有の取り扱いになりやすい側面があって、標準化された決済フローも提供していますが、必要に応じてサービスごとに実装してもらっています。

補足になりますが、cuisine-apiを利用している新規サービスというのは、もちろんクックパッドの認証システムに乗っているので、レシピ情報といったクックパッドのリソースも参照することができます。

こういったかたちでCuisineプロジェクトのサーバーサイドは進行しています。

「Organized Around Business Capabilities」

こんな感じなんですが、あくまでもクックパッドの実践例というのは抑えておいてください。単純に「共通実装にしたんですね」という話では、僕はないと思っています。Cuisineプロジェクトとしてこれらのシステムやライブラリを構築するあたって大事にしていることがあって、それは「Organized Around Business Capabilities」という言葉です。

これは、マイクロサービス、ひいては進化的アーキテクチャの性質・特徴と言われているものです。現在クックパックの新規サービスは、クックパッドのリソースは参照しつつも、独立したビジネスをやっていています。

そうなった時にユーザー決済基盤としては、一番優先度を上げて取り組むべき業務というのは、これまで述べてきたとおりユーザー管理・決済機能をより速く導入できるようにする。そう考えた上で今のCuisineプロジェクトが進んでいます。

これが仮に、「プレミアムサービス登録ユーザー数を増やす」といった目的のための新規サービス展開であったらどうだったか。そうなった場合ビジネスの主体は、今までどおりクックパッドのアプリやWebの会員事業になりますよね。そして各新規アプリで定期購読を契約すると、クックパッドのプレミアムサービスも付いてくる、みたいなビジネスプランが考えられます。

そうなった時に、ユーザー決済基盤としては、クックパッドと新規サービス間のユーザー管理・決済状態を不整合なく同期できるアーキテクチャの構築が、一番重要な業務になるでしょう。もちろん速く導入できるようにすることも要件としてはありますが、そちらが優先されます。

つまり何が言いたいかというと、今cuisine-apiはこうなっているんですが、ビジネスの方向性によってはオーケストレーションAPIという位置にある必要はありません。

新規サービスのバックエンドにあってもいいと。加えて先ほど述べたようなプレミアムサービスのユーザー獲得を目的とするのであれば、そもそもAPIを新設する必要もないわけです。

ビジネスの方向性によってはこういう未来もあったでしょう。

クライアントライブラリのかたちも変わっていたと思います。ちょっと説明として不十分なところもありますが、つまりビジネスの方向性、ビジネスのオーナーシップをちゃんと念頭に置いた上で、より新規サービスのユーザー認証・決済機能の導入を加速していっているというのが、Cuisineプロジェクトになります。で、サーバーアプリケーションの構成もそれによって左右されます。

開発コストの削減のために共通のなにかを作っていくことはみなさんもあると思います。その時にビジネスの視点だったり、何に注力すべきか、何を共通化すべきかという視点ですね。ビジネスの方向性という視点があると、どこまでそこに乗せてこれは要らない、といった区別がつきます。ぜひ参考にしていただければなと思います。