動画サービスの部署から課金システムに来て学んだこと

# 自己紹介と経歴

ドワンゴでプレミアム課金システムのエンジニア・マネージャーをしている坂本です。

2015年に新卒で入社し、そこから5年くらいはニコニコ動画のサーバーサイド開発として働いていました。
2019年頃からプレミアム課金システムを兼務。2020年にプレミアム課金の方に完全に異動して、マネージャーとして開発をしています。


# なぜプレミアム課金システムに異動したのか

僕が配属されたころのニコニコ動画は、複雑なシステムとレガシーなコードの塊でした。
少しずつ改善を進めたり、新しいAPIサーバーを立てたりして、動画システムはかなり改善されてきれいになりました。

https://www.utakata.work/entry/20181208/1544238000

動画システムはキレイになったのですが、周りを見渡してみると、プレミアム課金システムはあまり改善が進んでいないように思いました。
当時のプレミアム課金システムは、ニコニコ動画とインフラやコードベースを共有していたため、「動画インフラに詳しい自分がやるしかない」と思い、上司にお願いして、プレミアム課金の部署と兼務しました。

その時の改善の様子がこの記事です。

https://qiita.com/chiyoppy/items/2571e8e3ae675cc7a991

その後、2020年にはプレミアム課金システムのマネージャーとなり、プレミアム課金専属のエンジニアになりました。


# プレミアム課金システムに来て学んだこと

課金システムの開発は、今までの動画サービス開発とは全く異なるもので、多くの学びがありました。

ドワンゴの中でも、課金システムに関わっている開発者は非常に少ないと思います。せっかくなので、僕が感じたことをまとめようと思います。
この記事を読んで、「へぇ〜」と楽しんで貰えれると嬉しいです。

（最初はポケモンのこと書く予定だったんですが、あんまり広がりがなかったので、こっちにしました）


## 課金用語、ドメイン知識

まず驚いたのが、「オーソリ」や「売上処理」といった独特の要求です。
言葉くらいは聞いたことがある人もいるかもしれません。ミーティング等でこれらの用語が飛び交うので、まず言葉を知っておく必要があります。

**オーソリ**: クレジットカード支払いなどで、支払いが可能かどうかを確認し（利用限度額に達していないか等）、クレジットカードの利用枠を確保する処理のこと。利用枠の確保をするだけで、支払いが確定しているわけではない。「与信」とも言う。

**売上処理**: オーソリで確保した金額を、実際に決済して、ユーザーに請求を行う処理。ニコニコプレミアムのようなデジタルコンテンツの場合は、在庫の概念が無いので、オーソリを取ったらすぐに売上処理を行う。在庫の確保が必要な通販などでは、オーソリ後に在庫の確保を行い、在庫が確保できてから売上処理を行う。在庫が確保できなかった場合は、オーソリの開放を行えば、ユーザーに請求は行かない。

## クレジットカード課金と、iOSアプリ内課金は仕組みが全然違う

クレジットカードや、PayPal などは、「ニコニコのユーザー」「プレミアム課金のシステム」「決済サービス（クレカやPayPal等）」との3システムの間で決済を進めます。

正確なフローではありませんが、大まかにはこんな感じです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29024/53bf3065-7a8b-f882-211b-54f9a5448743.png)

プレミアム課金システムと、決済サービスが連動しているので、プレミアム課金システムがエラーを返した場合は、決済は失敗します。

一方で、iOSアプリ内課金では、決済にプレミアム課金システムは介入しません。決済の結果だけがプレミアム課金システムに送られてきます。

これも正確なフローとは違うところもあると思いますが、ざっくりこうです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29024/451e08d3-4384-61d0-ed29-03a02f762383.png)

課金のリクエストにプレミアム課金システムが介入しないので、プレミアム課金システムが落ちていても、決済は可能になります。

Apple → プレミアム課金システムに、課金開始・終了などの通知を送ってもらうことも可能です。

いずれにせよ、通常の課金とは若干フローが異なるので、この2つを上手く扱ってやる必要があります。


## 開発環境、ステージング環境の動作確認の難しさ

課金システムは、外部の決済システムとの連携することが多く、開発環境やステージング環境での動作確認が難しいです。

プレミアム課金システムの開発環境は、外部の決済システムの開発環境とつながっていますが、開発環境では実際にお金が動くことがなく、ダミーの決済で動作確認することになります。
すると、一部の処理は開発環境では動かないことがあります。具体的には、「売上金額が正しいかどうか」の処理だったり、「一度請求した決済の返金処理」などです。
このような処理は、本番一発になってしまうことがあります。

ステージング環境については、外部決済システムの本番環境と接続することになるのですが、外部のシステム → プレミアム課金への通知処理などは、ステージングではなく本番環境に届いてしまうため、ステージング環境での動作確認ができなかったりします。


## バックオフィスとのつながりが強い

課金はお金を扱う部署なので、経理や法務などの、バックオフィスとのやり取りが非常に多いです。

* 入金などの処理について経理や事業管理部とのやり取り
* 商品の販売について法務とのやり取り
* IRでプレミアム会員数を出すためのやりとり
* 返金などのトラブルに対応するためのカスタマーサポートとのやりとり

今までの動画サービス開発では関わったことが無い部署とも関わりました。

こういった部署とのコミュニケーションだったり、定常的な運用が非常に多い部署だと思います。


## トランザクションの重要性

当たり前といえば当たり前なのですが、トランザクションはめちゃくちゃ重要です。
トランザクションとは必ず「すべて成功」か「すべて失敗」になるべき一連の処理のことです。

* ユーザーがお金を払っているのにプレミアム会員になれていない
* お金を払っていないのにプレミアム会員になってしまった

といったことがないように、「決済」と「プレミアム会員化」は、必ずどちらも成功、あるいは、どちらも失敗させる必要があります。

動画サービスにいた頃は、正直、トランザクションを使うほどの処理はありませんでした。

しかし、課金システムでは、特に外部の決済サービスとのやりとりで様々なことが起こります。決済ができなかった、外部決済サービスからの通知が届かなかった、決済処理の途中でシステムがダウンしてしまった...

ユーザーのプレミアム会員状態と、課金状態が異なるような「不整合」が起こると、データベースの値を修正したり、ユーザーに返金をしたりなど、大変です。絶対に不整合がおこらないようにしなければなりません。


# さいごに

僕が課金システムに来た学びについて書きました。
「課金ってそんなことがあるんだ」と思って楽しんで読んでもらえると嬉しいです。

自分のここまでを振り返ると、入社して2〜3年は知識を吸収し、3〜5年目は、自分の知識を活用して、新システムの構築や、既存システムの改善を行ってきました。
そして、去年からはマネージャーとして、そして課金システムの開発者として、また新しい知識を身に着けていこうと思っています。