# Voicy+アプリ内課金リリース！プロジェクトの全体像とウェブ課金との違い まさと、ささんと、さみんと、いっくん ボイコード みんな慣れてない感じが Voicy Engineerの声とデータをチャンネル ボイコード、このチャンネルではVoicy Engineerの日々の活動をお話ししています。 はい、ということで 今日は週末版じゃないんですが 今日はですね、Voicyプラスのアプリ内課金3月の方ですねが終わりました。 無事に履修されましたので、その話をしていきたいと思います。 はい、お疲れ様でした。 じゃあ、改めて簡単に自己紹介 今更感、ボイコードだと今更感あるかもしれないんですけど 自己紹介をお願いします。まささんから。 皆様お馴染みかもしれないですが Voicyのバックエンドのエンジニア、プロダクトエンジニアのまさです。 iOSアプリ内課金のところとかでは 主にバックエンドのところを実装しておりました。 皆バックエンドか、今回は。 主にはチームとリードみたいな感じもさせてもらいつつ 何とかリリースまでこぎつけられたというような感じです。 よろしくお願いします。 じゃあ、さあさんお願いします。 はい、私Tシェル出てます。 iOSメインですけど、今回のVoicyプラスアプリ課金では バックエンドの開発が重かったので バックエンドの方に主に入ってやってました。 よろしくお願いします。 いっくんどうぞ。 いっくんです。 もともとはAndroid開発がメインでしたが 今回アプリ内課金では iOSとバックエンドの開発を行いました。 よろしくお願いします。 お願いします。 最後私ですね、さみぃです。 今回のアプリ内課金の中でいうと プロジェクトエンジニアとしての位置づけと あと、お手伝いというか プロジェクト管理のお手伝いというような形で入っていました。 よろしくお願いします。 お願いします。 じゃあ、急にアプリ内課金って何ぞやという感じだと思うんですよ。 ちょっとそこを説明ですかね。 まささんに聞いてみようかな。 今回のプロジェクトの全体像というか 何やったんでしたっけ? 今までVC++という機能は多分多くの方が 認知はしていただけているんじゃないかとは思ってはいるんですけれども 今はあれですね。 今のと放送の間に広告が出たりだったりとか あとはフォローグループという機能が 自分の好きなパーソナリティの方をグルーピングというかして 自分の特にお気に入りのパーソナリティの方が聞きやすくする機能だったりを VC++に加入すると聞けるようになるんですけれども もともとこれが加入のしづらさといいますか 多分今ウェブからクレジットカードを登録して課金をしないと 課金ができないというような形にはなっていて そういったところでアプリ内の課金のところの 動線のところがなくて 少しユーザーの方に 普通語じゃないな。 体験上少しちょっとウェブ上にまた遷移しないといけない 面倒くさかったりみたいなところがあったりしたので そこの変容を解消しようというようなところで iOSからではあるんですけれども iOSのところからまずアプリ内課金を投入して 皆さんがより楽に入れるようなところの体験を 作っていったというような形ですね ありがとうございます 今だと有料放送とかプレミアムリスナーは アプリ内課金ありますよね それと同じ感じで ウェブからだけじゃなくて モバイル上アプリ上でも 変えるようになったよというのが 今回のプロジェクトですかね モバイルアプリで完結できるようになった というようなところですね 今回ざっくり チーム構成は今なんとなくしゃべっちゃった チーム構成とかプロジェクトの ざっくりした期間とかってどのくらいですか そうですね メンバーはさっきの自己紹介してもらった 開発のエンジニアが3人と QAでサミさんが入ってくださって というようなところで進めていった 4人で進めつつ あとはポイントポイントというか 設計のところとかだったりで さっきも言ったんですけど バックエンドが結構重かったところであったので ボーイコード出演おなじみのせんちゃんとかに 設計の相談とかをさせてもらって 進めていったというような形になっていて 大体期間としては 3月くらいから始めて そうですね ちょうど3ヶ月くらい そうですね3ヶ月 3ヶ月ちょいぐらいか というくらいの期間で開発という感じですかね ありがとうございます じゃあ次さっさんに聞いてみようかなと思うんですけど ウェブ課金とアプリ課金って何が違うんですか ウェブ課金はウェブから アプリからというとしょうもないので ウェブはあれですね 加入するときに必ずクレジットカードを 登録する必要があって 結構それは手間っちゃ手間かなという感じがします アプリは多分多くの人はスマホに支払い方法とか 紐付けてあると思うので 購入ボタンを押したら パスワードとかあるいはフェースIDさえ通れば すぐ加入ができるよというところで アプリからウェブに支援をする必要もなくて 新しく決済情報を登録する必要もないというところで かなりアプリの方がスムーズに加入まで いけるというところが違いかなと思います ありがとうございます iPhoneだと電源ボタンダブルで よく皆さん使っているかなと思います じゃあ続いて深掘りしていきましょうか 今回難しかったところとかってどの辺でしたか 一君難しかったところ アプリからの通知を購入する際に また毎月更新する際に アプリからの通知が届いて それを処理する必要がありまして 実際サンドボックスで検証するとき 通知が届いていない場合がありますし こちらはおそらくサンドボックスの環境問題で 実際動作確認するときは難しいところもありました ありがとうございます 2つ話があったかなと思っていて 1個が今回設計というか 登場人物がこれまでのウェブでの支払い決済と ちょっと違って登場人物が多いよというところと あとサンドボックスというのがテスト環境ですかね アップルのテスト環境がある 決済のテストをできるように サンドボックスのものが用意されているんだけど そこがちょっとねっていう 若干不安定だったっていう マサさんに補足をしてもらおうかな 今回の設計というか 登場人物が多いみたいな この難しかったところ そうですね やっぱり一番難しいのは 全て思い知りの中で把握しきれないところ っていうような表現になってしまうんですけど 流れとしてはユーザーの方が 決済をしたタイミングで まず最初にアップルとユーザーの モバイル端末が通信をするみたいな形になっていて そこが成功した後に ボイシーとのエリトリをするみたいな形になるんですけど ボイシーとしては アップルの今の決済の状態を 100%どうなっているかすぐ知れない ところとかもあったりして 例えば 決済は成功したのに ボイシーサーバーに何か情報がうまく伝えられなくて 失敗しちゃったみたいなときとか そういうときとか なかなかボイシーサーバーとしては ボイシー側としては 今ユーザーさんがどういった状態なのか 課金の成立状態を知らないみたいな形になっているので そこの整合性を取るというか というところの難しさだったりとか あとは 例えば重複課金みたいなところとかが いろんなパターンで発生しちゃうので 何も考えずというか ただ流れを作るだけだと いろんなパターンで発生しちゃうので そこをどうやったら防ぐことができるのか みたいなところとかを考えていくのが すごく難しかったなという設計部分のところだったりとか あとは ドキュメントとかもちろん読んだりはしているんですけど 進める中で そんなこともできるのかみたいなことが出てきたりして そういったところとかも あとは すごくプログラム上 変更が効きやすい形には進められてはいたんですけど そこは出てきた時とかに 新しく出てきた時に これ大丈夫かなみたいなのが いくつか増えてきたりみたいなところが 結構大変だったポイントだったりするかなとは思っていますね ありがとうございます 次のチャプターに一回移動しますか そうです # 最難関はデータ整合性。専門外のバックエンドをチームでどう乗り越えたか 今の話を私なりに言い換えると、実装とか設計の難しいポイントがどうアプリ、モバイル、ユーザーのアプリとアップルの整合性とアップル社とボイシー社のデータの整合性をどう取るのか、同期をどうさせるのかというのがすごく難しいよね、ということかなと思っております。 そうですね。 ということかなと思うんですけど、じゃあ次佐さんに振るんですけど、それをどういうふうに乗り越えたのかというか、もともと佐さんはISエンジニアとしてのキャリアが長いという中で、結構今回のプロジェクトってバックエンドの実装だったりがすごい多いというか、ボリュームとしては多かったなと思うんですけど、どういうふうに佐さんは乗り越えていったんでしょうか。 もう始まってるかな。 あ、もう始まってるか。 はい。 そうですね。 マジでこれって流れ作るだけだったら簡単なんですよ、と。 多分自分だけでもできるんですよ、と。 やっぱりこの整合性でどこで失敗しているかとかも知りたくて、そういうことを知るには多分いろんな方法はあると思うんですけど、バックエンドが本職の人、お二人とも喋りながら。 最終的には起こった出来事をちゃんと完了したら記録していくみたいな方法で今回はやってるんですけど、そういうふうに何パターンかやり方はあるんですけど、その中でも自分で考えた後に本職のお二人に一回話、投げてみて相談したりがあったりとか。 今回やった実装方法とかは一般的な方法というか、あるにもあるというかだと思うんですけど、iOSの自分からしたらあんまり知らない状態ではあったので、その中でもお二人の解説付きとかで聞いているうちに最初は何を言っているんだろうなという人もありましたけど、最終的に実装終わったら確かになってなるくらい理解ができて。 コミュニケーションをとるのが大事かなって思いました。わからない面では本職の人と。そんな感じですかね。 はい、ありがとうございます。私から見てても最初設計をどうするんだっけというのはホワイトボードを出してみんなで喋りながらディスカッションしてたなと思いますし、その後もいざ小澤さんとか一君とかが実装するよってなった時、最初に自然言語で日本語で書いてましたよね。 こういう処理をする、こういう処理をするみたいなのを書いてその後にコードを書いてるように書いてましたよね。 そうですね。 そこがキャッチャップじゃないですけど、慣れてない中でどう進んでいくのかという時の一つ、今回やってみての学びというか、成果物だったのかなという感じもします。 やっぱり自分で突き進んじゃうとわからないところが多いところで、どんどんズレが大きくなっていってしまうので、認識ズレが起きないように日本語から始めたりとか、 せめて分かっている人とこれから分かりにいこうとしている人のズレが少ない状態でいかに進められるかというのは大事だなと思いました。 一君はどうでしたか?苦労とかこういう風に工夫したよということはありますか? そうですね。バックエンドの知識、最初入った時全然足りなくて、基礎の基礎もわからなくて、相談しながら進んでいるのもありますけど、 たくさんクラウドAIと相談して、たくさんトークンを食いましたという感じもあります。 やはり認識ズレが発生しないように、最初自然言語を考えて共通認識をとる必要が絶対必要ですので、 今後も認識合わせながら、正しいちゃんとみんな同じ方向性を持ってから進めた方がいい気がします。 ありがとうございます。あと何かあるかな。次のトピックにいこうかな。 チームの動き方とか今はだいぶ話してきたんですけど、 プロダクトエンジニアとして自分の一番の得意領域以外も含めて実装を進めていくみたいなところを、 今回すごく実践できた数ヶ月、3ヶ月半だったなという風に思っています。 チームの動き方とかでこれ良かったなっていうのがあるかなって考えてたんですけど、 1個どういう設計とか実装にしようかっていうのを4人でというか、 せんちゃんも入ったり入らなかったりで、一緒に話しながらというか、 チームエンジニアの目線でいうと、 Kも入った上でこういう風に作ったらいいんじゃないかっていう話ができたのがすごく良かったなと思っていて、 これまで割と実装の方針とかがある程度決まってから、 教諭をしてもらってとか説明をしてもらって、この辺どうなんですかっていう風に確認したりっていうやり取りが割と良かったんですけど、 本当にゼロからというか考えるところから今回入ってみて、 すごく理解、実装の内容とか方針の理解もすごく深まりましたし、 その場でこういう時ってどうなるんでしたっけみたいな疑問点を質問できたっていうのがすごく、 自分としてもやりやすかったし、チームとしても確かにその辺を考慮しないといけないんですねみたいな話につながったので、すごく良かったなって思いました。 最初の設計段階というか、まだ何もコード書いてない状態とかから、 サミさんとかも入ってくださり、この、さっき言ったデータ防ぐ方法をどう防ぐかとか、 どういう流れにしたら、できるだけ複雑ではなくかつデータも正しく持てるのかみたいな話を多分、 最初の方、すごい時間もかけて話してたので、確かにそういったところとかもしっかり入ってもらって、 最初から、たぶん我々実装の人からの、割と漏れてた観点とかからも、 サミさんが結構いろいろと、我々持ってなかった観点から突っ込んでくださったことで、 確かに、みたいな、さっきサミさんも言ってたと思うんですけど、 終わったのであれは確かにすごい良かったなとは思いますね。 あとは、どうですか話しちゃって。 自分的には、我々は結構アジャイルの開発のところで、 割とこのイテレーションのやることを、割ときっちり守りながらというか、 このイテレーションはこれをやろうみたいなのをしっかり決めながら、 チームでご意見とりながら、毎週プランニングとかもやりながら進めていると思うんですけど、 結構その後半の方とかは、このままだとちょっと間に合わないかもみたいな感じの、 ちょっと出てきてしまったところがあったので、 そういったときとかはイテレーションの中でやりきることに囚われずに、 先々に進められるんじゃないかみたいなところとかを、 例えばデビンにAIを使ってやってもらうとか、 そういったところとかもチームでもできたりしたりはしてたのかなと思って、 そういう進め方とかも、型に囚われすぎないみたいなところもすごく大事だなとか思いながら進めたりしてましたね。 何か他あります?チームの動き方とか、こういうの良かったなとか、逆に失敗したでも全然ご苦労まずいかなかったなとか。 失敗したのもあるな。 まささん何か言いそうですか? 僕は失敗したというか、もうちょっとうまくできたらよかったなと思ったところは、 それこそこれまでにも何回か話が出ているんですけど、 プロダクトエンジニアになるっていうところで、 初めてこのプロジェクトのところの頭だからそういう話になってきたみたいなところの中で、 ささんといっくんにどうやってバックエンドをキャッチアップしてもらおうかみたいなところで、 それで自然言語でやるみたいなところは良かった方の例になるんですけど、 逆にこの設計みたいな観点のところとしては、あんまりお二人に触れなかったというか、 いわゆるモデリングっていうところとかはあんまり触れなかったなと思っていて、 そのあたりをもう少し小さく切って、そこだけでもやってもらうとか、 そういうことをやってもらった方がより実装のイメージも二人もつきやすかったんじゃないかなとか、 よりバックエンドの力としても身につけられたりもしたのかなみたいなところとかは、 自分としてはもうちょっとうまくできたところがあるなっていう反省があったりしますね。 チーム力がそこを上がるっていうところにはなってくると思うので。 どうですか? 最初なんでね。 でもちょうどいい流度というか、ないので、 結構タスクとか分解しながらさせていただいたりとか、 自ら分解する場面とかもあったりして、 個人的にはそこまで後悔というか、もっとできたなという感じはないというか、 満足はしている感じですね。 確かに、プランニングの時にあえてというか、 佐藤さんとか一君がタスクストーリーの分解をするみたいな、 それをおしゃべってもらうことで、 どこまで理解しているかとか、 キャッチアップできているかとかは、 話すり合わせがしやすかったんじゃないかなという感じがします。 # AI活用で開発効率1.5〜5倍？テスト分析・設計・実装での使い方と今後の展望 続いてはですねAI活用についてももう少し話していきたいなと思うんですけど さっきMASAさんからもデビューに先回りして指示をして ライテレーション以降のやつも少し調査とか実装とか進めてもらったって話があったと思うんですけど SASAさんはどういうふうになんか今回活用しましたか? そうですねまずAIはすごいですね。すごくて本当に。 で一番自分が助かったなと思ってる部分は 何回も言ってるんですけどバックエンドを始めて入るという中で バックエンドのコードを一人だけで読んでいくのは結構難しい 最初にざっくりここのファイルではこういう流れでこういうことをしてるんだよっていう前提を AIに教えてもらえばそれを前提に読めるので入ってき方が全然違うなと思って 接近のところとかで喋りに行くとき、他のチームメンバーの方に行くときに AIとの相談なしでぶつけていくとやっぱり話がとっちらかっちゃうっていうか 自分の意見がまとまってないまま行くとやっぱりとっちらかっちゃう印象があって その前に一回手びんと割と時間かけてというか 株打ちしてちゃんと考えまとめて持っていくと その後との進み方のスムーズさも違うし 人と無駄にかける時間も減るなと思って そういう面でコーリングでももちろん活躍というか使いましたけど その設計、考えの手助けとしてAIはかなり今回は活躍してくれたなという印象ですね 確かに確かに 一君はどうですか?AI活用 はい、IOSの実装はDebianの方 IOSは実装はAndroidよりはレベルが低いけど 多少IOSの方がバックエンドより分かるので IOSの実装はDebianに投げて自分からレビューする形ですが バックエンドの実装は本当に最初だから分からないことがいっぱいあって 出てる分からない言葉を一つずつ細かく質問して 分かるまでずっとやりとりしている感じが多かったです 助かりました そういう細かいところはやはりリーダーの時間をとって聞く場ではないですので こういう細かい知識面の解説とかは さすがクロードにとうまく話して理解に進んでいるかなと思いました 分からない単語とかって一般的な知識と あとボイシードロインならではの分からないところがあると思うんですけど クロードに聞いたということは両方聞いてたんですか? 両方です とりあえず投げてその回答を見て さらに分からなければやりとりする 確かに 私も急エンジニア視点でというか 今回テスト分析のところをDebianとクロードにやらせたんですね 大体大きい案件だとテスト分析でしっかり画面一覧がある そこの画面一覧で今回の案件ではどこをテスト対象とすべきかっていうのを これまで全部手で丸をつけてたんですけど 今回のPRDの要件が固まっているものだったりとか それこそ設計のディスカッションして作ったメモというかテキストあるじゃないですか あれを読み込ませた上で今回どの辺テストしたらいいですかっていうのを リグレッションの観点既存の画面と今回の新規実装によって テストが必要なものっていうのを丸をつけてもらいました クロードとDebianと両方でやらせて 丸付いてる差分があるのでその差分も書いてもらって 最後に自分が上から全部確認して 確かにここ必要だよねとかここはテスト必要じゃないねみたいなのを 丸バツつけて最後にチェックしたっていう感じなので これまでの手で丸をポチポチやってたのを考えると相当楽になったなと コーディングも本当に自分ではほぼ書いてないので なかったらと思うと逆にドッとするというか どれくらいコースが膨れたんだろうとかは思いますね それこそ自分はこのタスク通りのものを進めながら裏でさっき言ったようにDebianに そっちはだいたいアウトプットのイメージが付いてるものを依頼したりしてたんですけど やるみたいな感じで2つ平行に進めるみたいなことが 平列に進めるみたいなのができてたんですけど それがもしAIがなかったら自分はこれをやって 頭の中にはあるけどそれはまだコードにできないみたいな この待ち時間みたいなのができちゃうと思うんですけど そういうのもAIでうまく使えればなくせるみたいなところは すごいデカいなとは思いますね なんか感覚で構わないんですけど 定量的にこのぐらい楽になったなみたいな 何時間ぐらい楽になったとか 感覚としては何日ぐらい 2枚まではいかないかもしれないですけど 1.5から8ぐらいなんじゃないかみたいな体感ですね コーディングを手で入力する必要がない 結構デカいのを出して あとはさっき言ったように平列で裏で書いてもらうこともできますし あとは設計とか注力すべきところに時間をしっかり避けられる ちょっと避けすぎたかなと思うんですけど 避けられたみたいなところもあったりはするので 自分の感覚はそれぐらいですね クエンド初めてのタミからずっと 全然4倍、5倍、6倍あるんですね 専門分野じゃないところだとより謙虚に 自分で一から書くのだと超時間かかると思うので 謙虚に感じられるなと思います 自分も同じくAIがなければ 勉強スピードがもしかして本から読む感じですね 勉強コストがだいぶかかります そういうコストも確かにあるんですよ 5倍残るんじゃないかもしれない さっきのテスト分析の例だと 丸ぽちぽちやるだけでも普通に1時間とか 本当に影響あるんだっけって考えながら丸付けるんで 1時間とか1時間半くらいかかってたのが 丸付けるのは待てばいいというか 5分、10分くらい待って 最後確認はどうせやるのでどっちにしろ すごい1時間半くらいのものが30分くらいで終わったみたいな そんな感覚です ありがとうございます じゃあ今後? 未来ってあるのかな 未来は今後どうしていくんだっけみたいなところ なんかあるのかな なんかありますか 今回はマブシプラスのアプリ内課金の話だったので なかなか難しいですね将来の話 でも入りやすくなるみたいなところは作れたかなとは思うので 機能の拡充みたいなところはやっぱりもっともっとしていきたいなとは思いますよね まだそこのプラスに入るだけの価値を どれくらい皆さん感じてくださっているのかみたいなところとかはあると思うので そこはもっともっと機能を早く それこそAI使って早く作って いろんな機能を皆さんに触っていただいて どんどんプラスに入ってよかったというようなものにしていきたいなというのは思います 確かに確かに なんかこのチームでも開発チームとしても数字をちゃんと見ていこうというのを 意識していきたいなと思っていて 加入者数だったり あとは会約者数だったりとか 見てましたもんね そういう事業目線で 今何が必要なんだっけとか 何したらいいんだっけっていうのを 考えながら報道できるようになっていきたいですよね そうですねチームとしてなんかもっと 自発的にというとあれですけど みんながチームで考えて それこそビデオと相談したりとかでやって もっと本当にVC++をどうやったらみんなに使ってもらえるんだ みたいなのをもっとチームでコミットしていく みたいなことはやっていけるといいなとは思いますね ささんといくま なんか私がバックエンドやってみて そうですね 他のチームでは一人一人プロジェクトとかやってますけど やっぱ一貫して 作れる能力とかがどんどんついていくのかなと思っていて バックエンドも今回触ったことによって そういうことでまた VC++の新機能とかでもいいですし その他でのVCにとってプラスになるような機能とかも 作れる速度が上がっていくのかなと思うので そういう面で語っていただけたらいいかなと思います はいありがとうございます これから今回アプリ内課金の学んだ知識を活用して 今後の一人のプロジェクトで ちゃんとしっかりためた知識を活用して進んでいきたいと思います はいありがとうございます ということで今回はVC++のアプリ課金についての話をしました このお話はですね デックブログでも文字としても公開する予定ですので ぜひお楽しみにしてください ありがとうございました