シオンとグレッグの部活の話
どうも、シオンです。
どうも、グレッグです。
どうも、ジールです。
どうも、スティーブです。
TimeTree TechTalk、今回5回目ですかね、始まりました。
はい、始まりました。
お願いします。
お願いします。
今日は、4人いるんですけど、シオンが2回目の登場で、グレッグが初登場。
2人に来ていただいております。
まずは、ちょっと軽く自己紹介していただきましょう。
TimeTreeのiOSエンジニアをしています、シオンです。よろしくお願いします。
TimeTreeのバックエンドのチームで、APIとかの開発をしているグレッグです。よろしくお願いします。
2人をお呼びして、今日のテーマの前に、2人は実はですね、社内部活、社内部活TimeTreeいくつかあるんですけど、
どんな部活に属していて、ちょっとそれ気になったんです。
軽く聞きたかったんですけど。
僕が部長として活動しているマイクラ部というのがありまして、
結構昔からの記事とか出してるんですけど、マイクラ部の。
確かに確かに。
みんないつでも好きに入れるマイクラのサーバーがあって、
そこでみんな日々自分で遊びながら、たまに時間決めて集まって、みんなで一緒に遊ぶっていうことをやってて。
直近だとこの間、古代都市に探検に行くっていうのを。
めっちゃ楽しそうやん。探検って聞くだけでめっちゃ楽しそうですね。
最新版のマイクラの追加要素で、地下深くに古代の都市みたいのがあって、
そこに行くと音を出すと反応するセンサーみたいのがあって、
何回起動しちゃうとめちゃめちゃ強い敵が出てくるっていう。
そこでしか手に入らないアイテムとかあるんで、
みんなでそこに行って宝探しをしてきたっていう感じですね。
自分はボコボコにされてましたね。
グレッグはわりと新入部員があれなんですね、メンバーなんでね。
そうですね。マイクラフト始めたのも入るちょっと前とか。
でも今一番アクティブに活動してるのはグレッグです。
そうなんだ。逆にハマっちゃった。
部活の時間が結構遅めな印象があって、夜遅くに集まりますよね。
それはちょっと家庭の事情というか。
ですよね。
子供が寝てからやるっていう感じ。9時からとかになってますね。
僕マイクラブ、いつもオフィスで残業してる時に
トニーがオフィスでマイクラやってるんですよ、部活でね。
それで片耳でなんとなく聞こえてきて様子を知ってるぐらいの感じだったんだけど。
トニーいつも呼んでるんですけど大体来なくて。
前回も行くって言ってたのに結局オフィスでずっと飲んでて。
そんな今日はマイクラブからゲストをお二人にお呼びして。
今日のテーマなんですけど、今まであんまり触れることが実はなかった。
タイムツリープレミアムの開発
課金の開発ということで、
実はタイムツリーが今年の4月、2020年、22年の4月に
タイムツリープレミアムというですね、
有料の拡張機能みたいなものを開発して今提供しているんですけど、
サブスクリプションで毎月定期的に課金をしていただくと
使える機能が広がるみたいなものをやってるんですが、
その開発の話ですね、今日は。
SEONが来てくれているので、主にiOSの開発周りの話、
またiOSに関わるバックエンドの話ということで、
主に話を進めていただこうかなと思っております。
やっぱりラジオ慣れしているSEONが、
めちゃくちゃ今日缶ペンいっぱい書いてくれていて、
これに沿って言っていきたいと思います。
SEONのメモがあるんでね、
ほとんどそのまま振っていく感じになっちゃってますけど。
以前ね、iOSのチーム紹介の時にもSEONが
そういったところを担当されていましたってことで、
結構その新しく出たライブラリを使いましたよっていうことを
軽く言ってたんですよね。
それまた別途取りたいねという話をしてたんで、
その新しいライブラリみたいなところの話とかから
ちょっと始めていただければと思います。
プレミアムの最初のリリースが
今年の4月とかだったんですけど、
開発はその前から始めていて、
最初にまず課金機能を入れるっていう時に、
iOSだとストアキットっていうものを
使う必要があるんですけども、
それがですね、iOS15から
アプリ内課金のAPIが刷新されて、
ストアキット2という新しいものが使えるようになったんですね。
いろいろ改善されているという状況がありまして、
ただiOS14をサポートするためには
ストアキット2は使えないんですよ。
なんですけど、
ちょっとこれ、ストアキット2使うかどうかによって
かなりコースが変わってくるなと思いまして、
なんとかiOS15だけのサポートでいけないかという話を持ちかけて、
4月時点でiOS15リリースから7ヶ月後くらいになるんですけど、
その時点ではiOS14のシェアは
許容できるくらい下がるだろうというふうに見越して、
iOS14では購入はできないという仕様で決定しました。
これによってストアキット2っていうものの
いいところを享受できるようになったっていう。
これ結構悩ましい問題ですよね、OS対応。
そうですね。
どんな相談がそこでされたんですか。
開発者的にはいろいろコース削減とかにつながるので、
ぜひ取り入れたいという話と、
結構ストレス軽減にもかなり大きいところなので、
エンジニアっていうと。
なるほど。
そこをこれ使わないと
ちょっとコース増えちゃいますよっていう感じで
スカップライドにアプローチして、
経営陣にOKをもらってくるという。
これ結構チャーリーが数値をいつも見てくれる人なんですけど、
だいたいiOS14のシェアはこのくらいまで下がるから
大丈夫でしょうみたいなところを見てくれたり。
なるほど。
これ判断のタイミングはいつぐらいの判断になったんですか。
結構前の時点で判断したってことですか。
そうです。もう開発始める段階では判断しないといけないので、
かなり初期の段階で決めましたね。
なるほど。
結構ちゃんとそこは予測して、
どれぐらいまで落ちるかなっていうところを揃えた上で
判断してたってことなんですね。
StoreKit 2の新機能とメリット
このStoreKit 2、いろいろ良くなったみたいなところありますけど、
具体的には何だろう、どういうところが違ってきたみたいな話も
ちょっとじゃあしていきますかね。
まずはStoreKitに必要なレシート検証っていう作業があるんですけど、
これ従来のStoreKitだと、
クライアントがまずApp Storeに対して購入リクエストすると、
そのレシートっていうものがStoreから返ってくるんですね。
このレシートを今度はTime Treeのサーバーに送って、
サーバーがこのレシートをAppleの方に問い合わせて、
これが正しい購入ですよっていうのを確認するっていう検証のステップが必要になるんですね。
これがStoreKit 2だと、レシート自体がJWS、JSON Web Signatureっていう仕組みを使ってるんですけど、
これがクライアントからAppに問い合わせて、
その結果返ってきた時点でもう検証が済んでしまい、
クライアントだけで完結できちゃうので、かなりそこの設計がシンプルにできるっていう。
なるほど。
あります。
なるほどね。レシートってもう完全にお店でもらえるレシートみたいな意味ですよね。
そうですね。
普通のやつだとそのレシートを誰かがスーパーに、
これ本当に買ったやつですか?聞きに行かなきゃいけないみたいなやつがあったってことですよね。
そうです。
それがなくなったんだ。
偽造できちゃう。
なるほどね。
でもそれがちゃんとこのスーパーが発行したレシートですみたいなのががっちりわかるようになって、
いらなくなったみたいな。
そうです。そんな感じかなと。
今スラックを漁っていたらですね、
今年の1月ぐらいにもうすでにグレックがストアキット2使うならバックエンドへのレシート送信いらなそうみたいな、
いろいろリサーチしてこうやってるやりとりが見えますね。
そうですね。
なるほど。
ここはバックエンドとしてはそのフローがまるっとなくなるので、
実際コストがだいぶ下がって進めることができる状態でしたね。
確かにこれはすごい楽になってそうですね。
App Account Tokenっていう仕組みがあるんですけど、
これはクライアントがストアに購入リクエストするときに、
どのユーザーが買いましたっていうユーザーに対応するUUIDをつけることによって、
ストアが購入が成立したときに、
タイムツリーのバックエンド側に購入が発生しましたよっていう通知が飛ぶんですけど、
その通知にこのApp Account Tokenっていうのがついてくるんで、
どのユーザーが買ったっていうのがすぐに分かるようになる。
なるほど。
これはもともとなかったんですか?
もともとなかったもので、
古いAPIを使うと、
クライアントで買った購入のトランザクションIDみたいなのがあるんですけど、
それをこのトランザクションIDで買ったっていうのをクライアントからサーバーに送って、
さらにAppleからサーバーに行った通知とそのトランザクションを付き合わせて、
最終的にこの人が買ったよみたいなことをやらなきゃいけない。
そうかそうか。
サーバーに通知もくるけど、
それはユーザーIDみたいなやつじゃなくて、
注文IDみたいなやつで、
クライアントからもらうやつと合わせなきゃいけなかったんですね。
誰が買ったかっていう情報が、
Appleからもらった情報からだけだと分からないっていう状態だったわけですね。
なるほど。
それをこのUID1つでどっちも分かる状態にできたっていうことなのか。
すごい。めっちゃ便利。
あとはクライアントサイドでいろんなメリットもあって、
まずStarkit2はSwift Concurrencyっていう並行処理のための新しい仕組みにのっとっているので、
Async Awaitっていうコードも使って、
非同期処理が格段に書きやすくなっているっていうのがまずあります。
あとはStarkit Testっていうテスト用のフレームワークが用意されてるんですけど、
これで購入ロジックのユニットテストを書いたりっていうこともできたと。
クライアント側にもかなり大きなメリットがありましたね。
購入のテストとかすごい大変そうですもんね。普通にやろうと思ったら。
そうですね。結局テストはやらなきゃいけないんですけど、
ロジックの部分のテストがかなりやりやすいっていう感じでした。
このあたりが結構良くなった点っていうか、みたいなとこですかね。
グレッグのほうであります?
StoreKit 2の登場とV2通知のリリース
そうですね。たぶんちょうどStarkit 2が登場したのと同時期だと思うんですけど、
App Storeからサーバーに送られてくる通知のバージョンがV2っていうのがリリースされたんですね。
もともとはV1っていうのがあったんですけど、ちょうど同じくらいの時期にV2っていうのがリリースされて、
タイムツリーのプレミアムの開発ではV2っていうのを最初から利用することができたんですね。
そうですね。いろいろ違いはあるんですけど、
例えば通知の中にはNotification Typeっていう通知の種類みたいなのを判別するフィールドが存在しているんですけど、
そこにもう一つSubtypeっていうのが含まれて、より通知の状態っていうのがどういうものなのか、
より詳細な状態がわかるようになったりしていて、そういった嬉しさもあったっていうのは、
ちょうどこの開発の時期がたまたまこのタイミングだったから、最初からそっちを使うことができたっていうのがあったりするかもしれませんね。
なるほど。これはまたStarkit 2とは別であるんですね、サーバー側の。
そうですね。
テイロードのV2みたいなのがあるんですね、仕様が。
そうですそうですそうです。サーバーの通知、サーバーが受け取る通知のところですね。
なるほど。そこに情報が結構いろいろ乗るようになって、よりやりやすくなったと。
そうですね。あとサーバー側が叩くApp StoreのサーバーAPIっていうのもあるんですけど、
そっちもいろいろ叩く種類がちょうど切り替わりの時期だったみたいで、切り替わりなのかな?
そうですね。なのでその辺の情報を調べながら実装したりしてましたね。
とは言っても課金開発やっぱここ辛いよねみたいな話とかもきっとあると思うんですけど、
その辺の話を教えていただいていいでしょうか?
はい。いろいろ辛いことがありました。
辛そうですよね。どう考えても辛そうなんだけど。
まずはAppleが用意している課金周りのサンドボックス環境っていうのがあるんですけど、
そこで基本的な購入フローみたいなのがテストできるようになってるんですが、
サンドボックスでテストできないパターンがいくつかあって、
1個がAsk to Buyっていうものなんですけど、
これは使ったことない人にとっては全然馴染みがないと思うんですけど、
子供が使っている端末に制限をかけると、
何かアプリを買ったりとか課金しようとしたりする時に、
親に承認を求めるようなフローになっているんですよ。
子供がリクエストすると親に数字が一定で、親が許可した時に購入は成立するみたいな感じになって。
今初めて知ったこれ。あるんですね。
これはでも…
お父さんとかいないとわからない。
ですよね。
これ何が大変かっていうと、購入自体がアプリの外側で発生するんですよね。
なので普通と違うのと、
あとですね、さっき言ってたアップアカウントトークンっていうものが、
このフローの時にはついてこないっていうことがわかりまして、
要はサーバーがAppleから受け取った通知だけを見ると、
誰が買ったのかわからないっていう状態になるんですよね。
なので結局そうなった場合にも、
ちゃんと購入を付き合わせて誰が買ったかを特定できるようにするっていうところは、
結局作らなきゃいけなかった。
なるほど。
せっかくいけると思ったら、一部残ってたんですね。
そうですね。
結構これが試せる段階っていうのが、
通知種別と状態表示の改善
開発の後の方とかいろいろ結合してやり始めてようやく見えてきた課題で、
このアップアカウントトークンっていう情報がある前提で、
ユーザーとの紐付けをできるだろうというふうに見込んで開発していたんですけど、
そんなことはなかったということで、
誰かに仕方がないですね。
なんか哀愁漂ってますね。
やばいですね。
2人の顔がやばいですね。
完全これは落とし穴で、
本当に実装してみないとわからない仕様だったということですね。
そうですね。
そんなことあるんだ。
サンドボックス環境でテストできないってことだから、
要は本番みたいなところに一回上げて、
裏でテストするみたいなことをしているときにやっと気づいたってことですか。
やばそう。
これ自体ちょっとタイミング忘れちゃったんですけど、
アップアカウントトークンがつかないパターンっていうのがいくつかあって、
例えば一回購入した人が一回やめて、
もう一回購入するときにアプリの外の設定、
iOSの設定アプリの中から過去にサブスクライブしたものを見ることができて、
そこから再購入ができちゃうんですよね。
なるほどね。
この場合もアプリの外なんで、
アップアカウントトークンがつかないみたいなことが起こります。
なるほど。
いくつかあって、それがどっかで気づいて。
結局ドキュメントに全てが書いてないんですよね。
そうなんですよね。
ある程度こうなってるんだろうっていう感じで、
バックエンドとクライアント設計して作って、
繋いでみて、いざサンドボックスで購入テストをしたら、
いろんなことがボロボロ出てきたっていう。
なるほどね。
サンドボックスで気づける場合もあると。
だけど、このさっきのアスクという場合とかだと、
それすらもできない。
そうですね。
あと、返金ですね。
1回のユーザーが返金するっていう方もあって、
これもテストできなくて、
審査を通した後にリリースする前に、
プロモーションコードっていうものを使うと、
リリース前のアプリをインストールすることができるんですけど、
これを使って本番で実際に課金してみて、
テストするっていうのをやりました。
課金周りの辛い部分と復元機能の実装
やったわ。
これ、スティーブにもテストしたことがあります。
そこで初めて試せると。
そうですね。
実際にちゃんと動くかどうかっていうのを、
もう何回にならないと見れないっていう。
これつらいですね。
さっきのアスクという場合はまだわかるにしても、
返金とかって普通にあり得るじゃないですか、きっと。
それをその段階にならないと試せないのはつらいですね。
さっきのアスクという場合もそのタイミングでテストしたんですか?
そうですね。
僕が実際にプライベートで子供に端末を渡して使って、
なので実際に子供の端末で買ってみて、
っていうのをテストしました。
なるほどね。
パターン多そうだからね。
そうなんですよね。
いろんなパターンをあらかじめ想定して作ってるんですけど、
もうありすぎて、
いくら対応しても全然安心できなくて。
なんかでもすごい、
全パターンボーラーみたいなドキュメント書いたら
すげー嬉しい人いそう。
ちなみにインターネットの海、大海原には落ちてなかったんですね。
そうですね。
StoreKit2新しいんでまだあんまり見たことないですね。
そこが新しいところに手を出す時の辛みでもあるんですね。
検索すればいろんな辛みを書いてあるブログとかいろいろ出てくるんですけど、
だいたい古いAPIを使ったものだったりしますね。
これからStoreKit2の開発実績っていうか各社で増えそうですけど、
いろいろ出せるものありそうですね。
コードの開発とかだけじゃない部分でも何かありますか?
そうですね。
iOSではやっぱシンサっていうのがハーブルとしてあって、
1回リジェクトされてるんですけど、
そのリジェクトの理由が復元機能がないっていうものだったんですね。
復元?
はい。
iOSのアプリ内課金があるアプリってだいたい復元っていうフローが用意されてるんですけど、
要は課金したんだけどちゃんとその状態が反映されなくて、
課金状態になってないみたいなのを復元することによって、
もう一度ちゃんとストアから情報を取ってきて、
課金状態にするみたいなものですね。
で、これでもTimeTreeのプレミアム仕組みだと、
TimeTreeがサーバー側にこの人プレミアムですっていう情報を持ってるので、
ストア側に復元の問い合わせをしなくても大丈夫だろうと思っていたんですけど、
レビュアーからは復元がないですって言って、
リジェクトされてしまったと。
ちょっと説明をしたんですけど、
TimeTreeはサーバー側でちゃんと状態を持っているので、
いらないんじゃないですかって返したんですけど、
じゃあ復元ボタンがないので付けてくださいっていう。
とりあえずボタンを付けるという話で。
ちょっと具体的に何をすればいいのかわからなくて、
何もしないボタンを付ければいいのかみたいなことを。
何もしないボタン付ける、
そういう話題があったのを覚えてますね。
そうしろって話なのかみたいな。
いろいろ調査して最終的にどうしたかっていうと、
まず復元ボタンに役割が2つあって、
1個がクライアントがストアから受け取る状態でたまに不正語を起こしていて、
本当は課金してるのに課金してないことになってるみたいなことが起こるんですよね。
なのでこれを最初に更新するっていう、
リロードボタンみたいな意味合いが1つあります。
これは単にアプリとアップストア側の課金状態を見るものなんですけど、
それとは別に、さっき言ってたアップアカウントトークンがなくて、
サーバー側で購入のひも付けができないっていうケースがどうしても発生してしまうんですけど、
そうなっちゃった時にユーザー側から能動的にそれを解消しにいくっていう手段として、
この復元の操作をした時に、
クライアントからこのユーザーが買いましたよっていうのをサーバーに送ることで、
そこで購入品も付けるっていうことができるようになるっていう。
そういう2つの機能がこの復元機能につけられて、
それをつけてリリースしたっていう。
なるほど、なるほど。
だから押したらストアに今の課金状態をちゃんと聞きに行って、
それを持ってサーバーにこのユーザーがこの状態だよって言ったら、
その状態にちゃんとサーバー側でするっていうこの処理が必要だったんですね。
そうですね、今でも言いながら思い出したんですけど、
今言った2つの1つ目だけ対応して最初はリリースしたんですよね。
はいはい。
なんですけど、どうしてもひも付けができなくなっちゃうパターンがあるっていうのをリリース後に分かって、
2つ目の機能を後から入れたっていう経緯だったっていうのを今思い出しました。
なるほどね、なるほど。
サーバーに送らないで終わってたんですね、最初は。
そうですね、はい。
なるほど、なるほど。
プレミアムのリリース後の問題
でもその完全にうまくいかないケースみたいなのがやっぱあるねと分かってきたって感じなのか。
そうですね、その辺リリース後にグレッグとすごい相談しながら、胃が痛くなりながら2人で。
胃が痛いですね、なるほど。
ちなみにこういうなんて言うんでしょうね、ひも付けうまくできなかったよみたいなこととかっていうのは、
なんか気づけるようにしてたりとかしたんですか?
それが気づけるかというとデータで検知することはできるんですけど、ユーザーは気づけないんですよ。
ユーザーは、はいはい、確かに。
ユーザーは気づけない。
例えばアプリ外で高読したりして、その時にユーザーはアプリを起動するまではバックエンドにはどのユーザーとひも付いてるか分からないので、
ユーザーがアプリを起動しない限りは、その高読状態っていうのがどのユーザーか分からない、ずっと分からない状態で残り続けてしまうんです。
そういった状態があるっていうのは分かることは分かるんですけど、
でも誰に対してその情報を伝えればいいかっていうのは検討としては分からないんですよね。
ユーザーに伝える術がないっていう状態になっちゃうんですよね。
なるほど。
ユーザーさんとしては、アプリ開いた時に使えてれば一番良いけど、
不正語があると使えなくて、問い合わせるとかで直してもらうみたいになるのか、
自分で復元をするのかとか、そういう感じなのか。
あとは、例えばタイムツリーのユーザーは違うユーザーを使っているんだけれども、
アプリ外での利用状態とデータの扱い
Apple IDは誰かと同じものを使っているみたいなケースもデータとしてもあって。
嫌なやつですよね。Apple IDの共有、結構嫌なケースだと思うんですけど。
そうですね。ただ、それをどう扱うかっていうこともちゃんと定義して、
なるほど。
アレルギー状態を作るっていうのも難しかったり。
結構さっきのシオンのお話で言うと、
割とリリース後とかでも起動力を持って直せていってるような感じを受けたんで、
データの不正語みたいなのも結構チェックしてたかなと思って、
そういう気づくみたいなのは結構やってたのかなと思ったんですけど。
そうですね。アラートのチェックはずっとやってましたね。
アラートみたいなのが飛ぶんですね。
なるほど。このパターンおかしいなみたいな感じなんですね。
ただ、やっぱり全部を解消できるかっていうと、
そこはなかなかまだ解消できないケースもあったりして難しいところがありますね。
なるほど。そこはちょっとおかしかったら聞いてもらいつつっていうので、
改善できる部分があるのかな。
例えばプレミアムを使い始めたんだけど、
そのユーザーさんがログ上はタイムツリーを使わないまま解約してしまったみたいなケースがあったりするんですよね。
プレミアムの利用を止める。
多分アプリ外で、ストアの中でやってると思うんですけど、
そういう場合は結局ユーザーと紐づかない高毒情報が残り続けた状態になっちゃうっていうので、
扱いは結構難しいですね。
確かにそうですよね。最後の解約にアップアカウントトークンが載ってないってことですよね。
もう解約できません。サーバー側では。
なるほど。お金はストアの方で取ってるから、
金銭的に何か不都合があるわけじゃないけど、
データとして残っちゃうのがちょっとなみたいな、そういう話ですかね。
そうですね。そういうケースだと例えば利用中にApple IDを、
テストフライト版の対応
おそらくなんですけどApple IDを削除するみたいなことになると、
解約したっていう情報を送られてこないんですよね。
サーバー、バックエンドで受け取ることができないので、
通知が飛んでこないっていうのが正しいのかな。
結局その状態をどこかで無効にする仕組みもちゃんと入れとかないといけなかったりするので、
異常な状態っていうのはいろいろ入ってくるっていう感じですね。
さっきスヨンが言ってたんですけど、全部把握できないっていうところは。
テストフライト版のアプリの行動というのも、
ちゃんとバックエンドであるべき状態でハンドリングできない状態で、
テストフライトの現象とか発信入ってしまったみたいなのがあって、
その状態で直したというか対応できるようにしたみたいなのがあります。
そうですね。テストフライト版の場合は、ユーザーのデータはプロダクションのデータを使うんですけど、
アップストアの購入の状態はサンドボックスみたいな状態を使うんですね。
バックエンドとしては、アップストアのサンドボックス環境とタイムツリーのサンドボックス環境を一致させて、
プロダクション環境をそれぞれ一致させるみたいなことをしていたんですけど、
テストフライトの場合は、本番のタイムツリー上のデータなんだけど、
アップストアの購入情報はサンドボックスに使われるので、
通知を受け取ったとしても、そんなユーザーいないよっていうエラーになった。
そうですね。
これを何とかしなきゃいけないっていうのを連携した後に気づいて、
これ、Appleのレビューアーが実はサンドボックス環境でテストをしてくるんですよ。
なので、ちゃんとサンドボックス環境で変えるようになってないとレビューが通らないっていう事情もありました。
じゃあ絶対やらなきゃいけないんですね、そのテスト。
そうですね。
そのつなぎ込みはね。
そうです。
じゃあ絶対必須だ。
なるほど。
結構落とし穴ですね、でも。
そうですね。
じゃあ最後、iOSのバックエンドの対応PRを。
でもね、割と苦労話めっちゃしたから、めっちゃ大変なんじゃないかみたいな。
いやいやいや。
じゃあお願いします。
タイムツリーのiOSチームでは、ストアキット2に限らず、
SwiftUIとか、新しい技術を積極的に取り入れて、みんな楽しく開発しているので、興味のある方はぜひご検討ください。よろしくお願いします。
お願いします。ぜひとも。
そして、グレッグのチームはね、今もう絶賛あと100人くらい欲しい感じですからね。
そうですね。
そうですね。
タイムツリーのバックエンドチームはそうですね、プレミア、サブスクリプションか、みたいなこともやってるんですけど、やっぱりアプリケーションのAPIのところで、とてもデータ量が多くてですね、数十億レコードとかのデータ量と向き合えるようなサービスを提供していて、
しかも世界中にユーザーさんがいるっていう環境で、どんなアプリをよくしていける環境なので、
チャレンジしてみたいなって方がいたら、ぜひぜひまずお話でもしてみましょう。よろしくお願いします。
ありがとうございます。
でも業界的には何なのか分からないですけど、かなりいい学びを提供できるプロジェクトになったんじゃないですかね。
結局、これが正しいのか全然自信なくここまで来ていて。
同じことをやってた人たちとちゃんと話をしたいっていうのがありました。
それはすごいよくわかります。
サブスクリプションモデルを提供しているサービスの人たち、すごいなってやって改めて気づかされています。
はい、それでは今回はタイムツリープレミアム、今年4月にリリースしたタイムツリープレミアムについての開発、
主に課金回りのiOSとバックエンドの開発について、
シオン・ブレックお二人をお呼びしてお話いただきました。
ありがとうございます。
ありがとうございました。
