課金実装を1週間から半日に短縮。RevenueCatで実現したpiconの高速開発

株式会社piconは、ChatGPT API公開直後の開発競争において、わずか2〜3名という小規模チームで「AIチャットくん」をはじめとするヒットアプリを次々と生み出してきました。しかし当時、社内には課金基盤に関するノウハウがなく、フルスクラッチでの開発には最低でも1週間は必要になるという課題を抱えていました。

この状況を打開するため、同社が選択したのがアプリ内課金サブスク管理サービス「RevenueCat」です。導入によって開発期間は数日へと大幅に短縮され、リリースまでのスピードが飛躍的に向上しました。現在では実装工数は半日程度にまで圧縮され、デザイナー主導での施策改善も実現しています。開発負荷を気にすることなく、本質的な価値提供に注力できるようになった背景について、CTOの大村瞬也氏にお話を伺いました。

課題

──RevenueCat導入以前の開発体制や、当時の課金システムの状況について教えてください。

大村様：実働メンバーは私とCOOの渋谷に加え、業務委託の方がいれば最大2〜3名という体制だったため、開発リソースは限られていました。

また、それまで弊社がリリースしてきたアプリには課金機能自体がなく、サブスクリプション型のアプリ内課金を検討し始めたのは「AIチャットくん」やそのアプリ版の開発時期でした。課金基盤に関するナレッジも仕組みも存在しなかったため、完全にゼロからの構築が必要な状況でした。

──スピード感が最優先される中で、課金実装にはどのような懸念がありましたか？

大村様：2023年3月にChatGPT（gpt-3.5-turbo）のAPIが公開された直後で、「いかに早くサービス化できるか」が勝負の分かれ目でした。競争環境は非常に激しく、いち早くリリースして市場に出すことが絶対条件だったのです。

その状況下では、サービスの核となる体験づくりに集中しつつ、煩雑になりがちな課金まわりの実装をどう短縮するかが大きなポイントでした。もし自前で作り込むとなれば、熟練エンジニアであっても最低1週間は必要だったはずです。スピードが命の環境で課金開発に1週間を取られてしまうのは、私たちにとって避けたいリスクそのものでした。

導入背景

──課金実装の工数削減に向けて、どのようにしてRevenueCatにたどり着いたのでしょうか？

大村様：まず、煩雑なサブスクリプション管理を外部サービスに任せられないかと考え、技術記事を中心に情報収集を進めました。QiitaやZennを調べていく中で目に留まったのがRevenueCatです。

記事を読み込むと、これまで複雑だと思っていたレシート検証やプランの出し分けが、驚くほどシンプルに実装できることがわかりました。当時はサービスがどこまで成長するか見通しが立たない段階でしたが、利用料金もスタートアップにとって十分許容できる範囲で、導入ハードルが低かった点も大きな決め手になりました。

──実際の開発現場において、RevenueCatは当時のスピード感とどのようにマッチしていたのでしょうか？

大村様：ChatGPTが生成したコードをベースに、必要な部分だけ手直ししてサービスを作り上げる「Vibe Coding」での開発スタイルをとり、2日でリリースをしました。

RevenueCatは、その“爆速型”のフローと非常に相性が良かったと感じています。まずはLINE側の実装を最優先で進めつつ、並行して課金周りを組み込んでいきましたが、複雑なコードを書く必要がなく、設定ベースで構築できた点がスピード維持に大きく寄与しました。開発の流れを止めずに実装を進められたのは、当時の状況において非常に助かりました。

導入の決め手

──RevenueCat導入の決め手となったポイントはどこでしたか？

大村様：最も大きかったのは、情報の「シンプルさ」に尽きます。

スクラッチでの実装方法を調べると、QiitaやZennの記事が「設定編」「実装編」など複数回に分かれており、調査だけで相当な時間を要することが容易に想像できました。一方で、RevenueCatに関する記事は1本で完結しているものが多く、「この設定をすれば動く」といった形で非常に分かりやすかったのが印象的です。短時間で実装できるイメージが明確に持てたことが、導入を後押ししました。

──具体的にはどのようにRevenueCatの実装を進めたのでしょうか？

大村様：QiitaやZennの技術記事を参考にしながらハンズオン形式で組み込みを行いました。基本的にはその手順だけで問題なく進みますが、エラーが出た場合は公式ドキュメントを確認し、それでも解決できない特殊なケースはコミュニティのQ&Aを参照して対応しました。

最初からすべての仕様書を読み込むのではなく、実装しながら必要な情報を都度キャッチアップできたため、調査に時間を取られることなく最短距離で開発を進められました。この“段階的に必要な情報だけを取りにいく”というアプローチとの相性も非常に良かったと感じています。

導入結果

──最初の導入時、どのくらいの期間で実装を完了できたのでしょうか？

大村様：初回の実装は1日ほどで完了しました。集中的に作業した結果ではありますが、フルスクラッチで最低1週間はかかると想定していたことを踏まえると、数日でリリースレベルまで持っていけたのは非常に大きな成果でした。

現在ではさらに実装までの期間は短縮され、課金機能は半日ほどでリリースが完了する状況です。RevenueCat MCPの活用などもあり、他タスクと並行して作業するため実働時間はさらに短くなっています。新規アプリの開発時には「気付けばその日のうちに課金周りが終わっている」感覚に近く、かつて懸念事項だった課金実装がボトルネックになることはなくなりました。

──RevenueCatには豊富な機能がありますが、その中でも特にインパクトを与えているものは何でしょうか？

大村様：Paywall（課金誘導画面）のエディタ機能は非常に革新的だと感じています。アップデートにより、デザイナーが直感的に画面を作成・編集できるWYSIWYG形式となり、開発を介さずに実装できるようになりました。

以前であれば、デザインを変更するたびにエンジニアに依頼し、さらにAppleの審査を待つ必要がありました。しかし今では、デザイナーやPMだけでABテストの実施からデザイン変更まで完結します。エンジニアの工数を使わず、リードタイムゼロでPDCAを回せるようになったことで、各メンバーが本来注力すべき業務に集中できる環境が整いました。

──開発工数の削減は、経営判断や意思決定のスピードにどのような影響を与えていますか？

大村様：「エンジニアのリソースが空いていないから」という理由で課金施策を先送りにする必要がなくなりました。

通常、料金プランの変更や新機能の導入は工数が重く、経営側も判断をためらいがちです。しかしRevenueCatを使えば変更コストが極めて小さいため、「事業としてやるべきかどうか」だけに集中して意思決定できます。仮説検証のサイクルを止めず、仮に施策がうまくいかなくてもすぐ次の手を打てる柔軟さは、経営の観点でも大きなメリットだと感じています。

──運用・保守の面で、エンジニアが感じるメリットについて教えてください。

大村様：セキュリティとメンテナンスの両面で心理的な負担が大きく軽減されました。お金に関する機能はミスが許されませんが、RevenueCatのコンソールに沿って設定すれば、重大な事故を回避できるという安心感があります。

また、App Storeの仕様変更にもプラットフォーム側で対応してくれるため、こちらでコードを更新する必要はほとんどありません。売上推移などの分析ダッシュボードも標準で提供されているため、自作する必要がなく、運用コストを最小限に抑えられています。

RevenueCatについて

──どのような課題を持つ企業や開発者に、RevenueCatをおすすめしたいですか？

大村様：大きく2つのタイプの方々に特におすすめしたいと考えています。

1つ目は、課金施策を検討するたびに「まずエンジニアの工数状況を確認しなければ進められない」企業です。本来、料金プランの変更や新しい施策の判断はビジネスサイドで決めるべきものですが、技術的な制約によって滞ってしまうケースは少なくありません。RevenueCatを導入すれば、ビジネス側が主体となって施策を完結できるため、意思決定のスピードを大幅に高められます。

2つ目は、少人数でグローバルに挑戦しようとしているスタートアップや個人開発者です。近年は「Vibe Coding」の潮流もあり、少人数でも高品質なプロダクトを作れる時代になりました。だからこそ、複雑な課金実装に時間を割くより、プロダクトの本質的な価値やUXを磨くことに注力すべきだと思います。「課金機能は必要だが、実装に多くの時間を使いたくない」という方にとって、RevenueCatはとても相性の良い選択肢になります。

──最後にRevenueCatの導入を検討している方へメッセージをお願いします。

大村様：ユーザーとの距離が近く、「どんな体験を提供したいのか」を重視して開発している方ほど、RevenueCatの価値を実感できるはずです。届けたいユーザー体験に集中したいのであれば、課金まわりの複雑な処理はRevenueCatに任せてしまうのが得策です。プロダクトづくりのスピードとクオリティを両立させたい人にとって、心強いパートナーになってくれると思います。