RevenueCatのミッションは、開発者がより多くの収益を得られるように支援することです。CEOのJacobは、隔週で行われる全社会議で毎回、「勝てるチームをつくること」と「開発者がより多くの収益を得られるようなものを開発し、届け、販売すること」によってそれを実現していると語っています。後者、つまりプロダクトを出荷することは、Engineering・Product・Design（EPD）の責任範囲であり、勝てるチームを支える3つの柱の1つが、私たちのプロダクトエンジニアチームです。
現在、このプロダクトチームは5名のプロダクトエンジニアで構成されており、複数のポジションを募集中で、2026年に向けてさらに採用を進めていく予定です。そこで本記事では、RevenueCatにおけるプロダクトエンジニア（PE）の実際の働き方、ここで成功するために必要なこと、そして私たちが直面している課題について紹介していきます。
RevenueCatのプロダクトが特別である理由
プロダクトに関わる立場として取り組める製品には、誰もが知っている（あなたの両親ですら知っているような）コンシューマー向けプロダクトから、特定の業界にいないと理解が難しいニッチなプロダクトまで、さまざまなものがあります。RevenueCatは明らかに後者に分類されますが、それでも非常に特別なプロダクトです。
難解な問題と意味のあるインパクト
RevenueCatを特徴づける要素のひとつは、非常に複雑で、やや専門的で分かりにくい問題を解決している点です。アプリ内課金のペイロードに含まれる各フィールドが何を意味するのか、Apple・Google・Stripeそれぞれでどのようなエッジケースが存在するのか、そしてそれらをどう扱うのが最適かを理解することは、複雑で決して華やかなものではありません。
私たちはよく「痛みを食べて生きている」と言います。つまり、開発者が向き合わずに済むように、つらいインフラの問題を引き受けているという意味です。それだけでもRevenueCatは扱うのが難しいプロダクトですが、それ以上に意味があるのは、その取り組みの背景にある理由です。私たちはアプリ開発者がアプリで収益を得られるよう支援しています。なぜなら…
- 私たちは、ソフトウェアは（全体として見れば）世界にとってプラスの存在であると信じています。
- 人々がソフトウェアを作り、それで生計を立てられるようにすることが、人類がより多くのソフトウェアを生み出す最良の方法だと考えています。
これらの考えに共感できるのであれば、RevenueCatは非常に魅力的なプロダクトです。私たちが解決している問題は、何万もの開発者がアプリで収益化することを支えているからです。
また、RevenueCatの多くのメンバーはアプリ開発のバックグラウンドを持っており、今でも個人アプリをストアで公開している人もいます。そのため、私たちは顧客と同じ立場を経験してきており、自分たちが解決している問題や提供している価値を実感として理解しています。これが私たちのユニークな点です。
顧客に愛されるプロダクト
RevenueCatは多くのファンを持つプロダクトです。もちろん、すべての顧客がファンというわけではありません。正当な不満を持つ人もいれば、単に日々の業務で使うツールのひとつとして捉えている人もいます。それでも、私たちのプロダクトを本当に気に入ってくれている顧客は数多く存在します。なぜなら、RevenueCatによって「好きなこと（アプリ開発）で収益を得ること」が可能になっていると実感しているからです。
カンファレンスで自ら私たちのブースを訪れてアプリの話をしてくれる顧客や、App Growth Annualに参加してくれる人たちと直接会うと、自分たちが関わっているプロダクトが愛されていることを実感できます。また、顧客が初めてのRevenueCatの請求書について誇らしげにSNSに投稿しているのもよく目にします。これは無料プランの上限を超え、アプリで実際に収益を得られるようになったことを意味します。これほど「お金を払うこと自体を喜ばれる」プロダクトは多くありません。
こうしたフィード バックは、RevenueCatで働くことの大きなやりがいにつながるだけでなく、問題に直面している顧客を支援したいというモチベーションにもなります。
顧客と一致したビジネスインセンティブ
最初の請求書の話に関連して言うと、RevenueCatとそのビジネスモデルの大きな特徴のひとつは、私たちのインセンティブが顧客のインセンティブと一致している点です。私たちは顧客の収益の一定割合を課金します。つまり、顧客が成長すれば私たちも成長し、顧客が収益を上げれば私たちも収益を得るという構造です。
これ以上に純粋なビジネスモデルはほとんどありません。私たちは顧客の成功を望んでいます。なぜなら、それがそのまま私たちの成功にもつながるからです。両者のインセンティブは完全に一致しており、その結果、プロダクトの意思決定においてビジネス的な妥当性を判断することが非常にシンプルになります。
数年前、私たちは価格体系をシンプルにし、無料プランであってもエンタープライズプランであっても、すべての顧客がすべての機能を利用できるようにしました。これは、私たちの収益が顧客の収益に比例して増えるため、顧客が大きくなれば自然とより多くの料金を支払う構造になっているからです。また、私たちはすべての開発者が成長ツールの恩恵を受けるべきだと考えています。もし低価格プランの開発者に対してそれらのツールへのアクセスを制限してしまえば、自分たちの成長機会をも制限することになってしまいます。
異なるプロダクト領域とそれぞれの課題
最後に強調したいプロダクトの特徴 は、複数の異なる領域（サーフェス）を持っている点であり、それぞれに固有の（技術的な）課題が存在することです。
- バックエンド：私たちのバックエンドは顧客にとっての重要なインフラです。顧客の収益に影響を与えないよう、信頼性を最優先にする必要があり、同時に非常に高いスケーラビリティも求められます。バックエンドは毎日数十億件のAPIリクエストを処理しており、最も利用されるAPIエンドポイントは完全にキャッシュされていなければ、データベースは瞬時に崩壊してしまいます。
- SDKおよびAPI：これらは、開発者がアプリやバックエンドを構築する基盤となるため、長期間にわたって安定して動作するように設計する必要があります。特にSDKは品質基準が非常に高く、バグのあるSDKが一度アプリに組み込まれてしまうと、ユーザーがアプリを更新しない限り、その問題が長期間にわたって残り続ける可能性があります。
- Webダッシュボード：この領域では、より自由度高くイノベーションや改善を行うことができるため、非常に高速に変更をデプロイできます。
- コンシューマー向けUI：最近では、より多くのコンシューマー向けUIを提供しています。ペイウォール、カスタマーセンター、Webチェックアウト、Webカスタマーポータルなどは、顧客のさらにその先のユーザーが利用するため、信頼感を与える高い完成度が求められます。
プロダクト開発へのアプローチ
私たちのプロダクト開発へのアプローチは、会社のバリューとタレントビジョンの両方によって形作られています。
プロダクトマネジメントではなく、プロダクトエンジニアリング
私たちは最近、プロダクトマネージャーという役割をプロダクトエンジニアへと変更し、プロダクトエンジニアをエンジニアリング組織に統合するという意思決定を行いました。AIによる開発支援によってコードを書くことがボトルネックではなくなりつつある現在、プロダクトとエンジニアリングはこれまで以上に密接に連携する必要があります。プロダクト担当者はソフトウェアエンジニアを介さずにプロダクトの変更をリリースできるようになり、一方でエンジニアは単にコードを書くのではなく、より高いプロダクト視点や判断力が求められるようになります。つまり、プロダクトとエンジニアの連携と一体化がこれまで以上に重要になっており、この役割変更はその整合性を強化するものです。
何を作るかを決める
私たちは毎年、プロダクト戦略を策定します。この戦略が、その年に注力すべき領域を決定します。一般的に、毎年の戦略は過去の戦略の延長線上にある進化であり、大きな転換や急激な方向転換ではありません。戦略は経営陣によって決定されますが、その形成過程にはプロダクトエンジニア（PE）が重要なインプットを提供します。
この戦略に基づき、チーム構成も見直されます。私たちは比較的安定したクロスファンクショナルチームを持ち、PEはエンジニアチーム、エンジニアリングマネージャー（EM）、そしてデザイナーと協力して業務を進めます。
ロードマップは主に四半期ごとのプランニングプロセスで決定されます。このプロセスはこれまで何度も改善されてきましたが、現在は次のような流れになっています。
各チーム（PE、EM、デザイナーで構成）が優先事項のセットを提案し、それを経営陣（CEO、CTO、Head of Product）がレビューおよび議論します。これらの議論の中で一部調整が行われることもありますが、基本的には各チームがロードマップと優先順位の決定を担います。プロダクトエンジニアはこのプロセスにおいて重要な役割を果たしており、自身の担当領域を最も包括的に理解し、顧客にどのような価値を提供できるかを最もよく把握している存在であることが多いです。
日々および週単位の業務では、プロダクトエンジニアはEMやデザイナーと密接に連携し、少なくとも週1回のミーティングと、より頻繁な非同期コミュニケーションを通じて協働します。チームにおける機能の発見（ディスカバリー）と実装（デリバリー）はチーム全体で担われ、緊密なコラボレーションによって実現されています。
プロダクトチームにおけるバリューの実践
前述の通り、私たちのプロダクト開発の進め方を形作っているもう一つの要素は、会社のバリューです。これらはNotionに書かれて忘れられているような単なるリストではなく、私たちが日々意識し、実践し、自分たちを評価するための指針となるものです。
顧客への徹底したフォーカス（Customer obsession）
RevenueCatでは、何よりもまず顧客に価値を提供することを重視しています。これはいくつかの具体的な行動につながります。
- PEは頻繁に顧客と会話し、関わることが求められる：これには1対1のミーティングやリサーチコールだけでなく、サポートチケット、SNSの投稿、営業との会話、顧客との共有Slackチャンネル、カンファレンスでの会話なども含まれます。
- PEと顧客の間に障壁はありません。より良いプロダクト判断につながるのであれば、すぐに会話を設定すべきです。
- 顧客の具体的なエピソードは、プロダクトの意思決定を議論する際に非常に説得力のある材料になります。もちろん、顧客の要望をそのまま全て実装するわけではありませんが、その背後にある本質的なニーズや課題を理解しようとします。一般的に、顧客が自分の問題や未解決の課題を伝えてくれるほどプロダクトに関心を持っているのであれば、その声には耳を傾けるべきだと考えています。
- チームは、問題の規模に関係なく顧客のニーズに向き合います。たとえ小さな不満であっても軽視しません。戦略やロードマップは重要ですが、バグを素早く修正したり、ユーザーが直面している制約を取り除いたりすることで「自分たちは大切にされている」と感じてもらえれば、それだけで顧客の印象は大きく変わり、懐疑的だったユーザーがファンになったり、ファンがさらに強い支持者へと変 わることもあります。
常にリリースし続ける（Always be shipping）
「常にリリースし続ける」という価値観は、私たちのプロダクト開発の進め方に大きく影響しています。具体的には、計画している機能のスコープをMVP（最小実用製品）まで削減することを促します。その理由はいくつかあります。
- 顧客に価値をより早く届けることができるため
- できるだけ早い段階で顧客からフィードバックや検証結果を得ることができるため
リリース目標
この「常にリリースする」状態を実現し、スコープを最小化するための方法のひとつが、社内の締め切りを設定することです。
こうしたリリース目標を設定した場合、私たちはその期限までに必ずリリースできるよう、チームのスピードを上げるためにリソースを追加するなど、あらゆる手段を講じます。また同時に、「必須」だった要素を「あると良い」へと下げるといった、痛みを伴うスコープ削減を迫られることもあります（ソフトウェア開発を知っている人であれば分かる通り、多くの場合「あると良い」は実際には実装されません）。
興味深いのは、機能をリリースして顧客に使ってもらった後に寄せられる最初の要望が、後回しにした機能ではなく、まったく別のものになることが多い点です。これは、迅速にリリースすることの価値を示しています。私たち自身も顧客も、機能が実際にプロダクト内で使われたときにどう振る舞うかを正確に予測することはできません。それを知る唯一の確実な方法は、素早くリリースし、その後に改善を重ねることです。
行動バイアス（Bias for action）
「常にリリースし続ける」もう一つの側面は、行動バイアスです。私たちは常に不完全な情報のもとで意思決定を行っています。もし完全な情報を待っていたら、決断は永遠にできません。そのため、プロダクトエンジニアには、不確実性の中でも意思決定を前に進める責任があります。多くの決定は後から修正可能であるため、延々と議論し続けるよりも前進することの方が重要です。行動せよ、議論だけで終わるな。
オーナーシップを持つ（Own it）
RevenueCatではオーナーシップが非常に重要です。プロダクトエンジニアにとって、それは「どんな問題も他人事ではない」という意味です。私たちは共に勝ち、共に負けます。問題に気づいたら、それが自分の担当領域でなくても行動するべきです。
もちろん、PEがすべての問題を自分で解決する必要があるわけではありません。しかし、顧客の課題から解決策の設計、技術的な実装に至るまで、最も広くエンドツーエンドで理解していることが多いため、問題に気づく立場にあり、実際にそれが期待されています。
RevenueCatのプロダクトエンジニアは高い主体性を持っており、困難な状況でも変化を起こせると信じられています。彼らは目の前の問 題を解決するためにできる限りのことを行い、ときにはそれ以上のこともします（例えば、より良く問題を解決するために新しいことを学ぶなど）。コードベースを掘り下げてバグの原因を特定したり、データウェアハウスをクエリしてデータを理解したり、顧客の問題をデバッグするために急遽ミーティングに参加したりします。
また、AI支援による開発の進化により、プロダクト担当者がコードベースに直接貢献することも珍しくなくなっています。変更が比較的シンプルな場合、チケットを書いてエンジニアに依頼するよりも、PE自身がCursorやClaude Codeを使って直接修正を行い、レビューを経てリリースする方がはるかに速いこともあります。
要するに、やるべきことは多く、全員が総力戦で取り組んでいるということです。
バランス（Balance）
「バランス」というバリューは、おそらく最も誤解されやすいものです。これは手を抜くという意味ではありません（むしろ、RevenueCatはスタートアップであり、仕事は意図的にハードです）。私たちはスピードを維持し続けてこそ成功できます。
しかし同時に、このバリューは「速く動くこと」と「燃え尽きること」の間にある微妙なバランスを意識させてくれます。興味深い課題に取り組み、モチベーションの高いチームと働くことは、大きなやりがいにつながります。PEはチームのモチベーションや関心を維持する上で重要な役割を担っており、自分たちが解決している問題と顧客へのインパクトを結びつけること、例えば顧客からのポジティブなフィ ードバックを共有したり、熱量のある雰囲気を生み出したりすることが求められます。
また、「バランス」は他者に対する思いやりや優しさ、そして信頼と相互理解に基づいたチーム環境を築くことも含んでいます。プロダクトエンジニアは自然とリーダー的な役割を担うことが多く、こうした行動を体現し、チームに広げていく上で重要な存在です。
RevenueCatのタレントビジョン
RevenueCatのタレントビジョンは、高い能力を持つメンバーで構成された「勝てるチーム」を築くことです。そのため、すべてのメンバーに対して高い基準を設けており、それを採用やパフォーマンス管理のプロセスを通じて維持しています。
この考え方は、プロダクト開発の進め方にもいくつか の影響を与えています。まず、私たちのチームは比較的シニアでプロダクト志向のエンジニアやエンジニアリングマネージャーで構成されています。そのため、RevenueCatのPEは、細かいプロジェクト管理や詳細なチケット作成に深く入り込む必要はあまりありません。むしろ、必要なコンテキストや問題領域の理解を的確に伝える能力が重要であり、それによってエンジニアがPEの意思決定によってボトルネックになることを防ぎます。
また、このビジョンはチームが比較的リーンであることも意味しています。私たちは、優秀な人材で構成された小さなチームの方が、基準の低い大規模なチームよりもはるかに速く動けると考えています。
プロダクトチームが直面している主な課題
ここでは、RevenueCatのプロダクトエンジニ アとして直面している主な課題を紹介します。
やるべきことが多すぎて時間が足りない
これは典型的なスタートアップの課題かもしれませんが、RevenueCatでもまさに同じ状況です。私たちには常に、取り組むべきアイデアや解決すべき顧客の課題が、実際に対応できるキャパシティを上回っています。そのため、会社全体としても、各チームとしても、そしてPE個人としても、適切に優先順位を付け、それを市場や顧客、社内の関係者にしっかりと伝える必要があります。これに対しては、戦略とプランニングプロセスを通じて、常に最もインパクトの大きい機会に集中するようにしています。
顧客志向と戦略的優先順位のバランス
上記の優先順位付けの必要性に関連して、私たちはしばしば「顧客への徹底したフォーカス」と「戦略的優先順位」の間で引き裂かれる状況に直面します。戦略的なプロジェクトは成果が出るまでに時間がかかる一方で、顧客志向の価値観は小さなリクエストにも迅速に対応することを求めます。どちらかに偏りすぎるのは望ましくありません。顧客の声を無視して長期戦略だけに集中すれば、反応が遅いと見なされ、これまで築いてきた顧客からの信頼を失うリスクがあります。一方で、顧客の要望ばかりに対応していると、大きな成長機会を逃したり、市場の変化に乗り遅れたり、プロダクトや会社にとって次の大きなチャンスを掴めなくなります。
成長に伴う調整コストの増加
RevenueCatはここ数年で大きく成長してきました。タレントビジョンに基づき、収益ほど急速にチームを拡大してはいませんが、それでも組織は拡大しており、今後も成長を続けていく予定です。EPDチームが大きくなることでプロダクト改善のためのリソースは増えますが、その分、調整に必要なコストも増加します。エンジニアリングチームの人数が倍になったとしても、リリースできる変更が単純に倍になるわけではありません。一部のリソースは調整や連携に割かれる必要があるからです。また、チームが増えることで、プロダクトの各領域で一貫性のない体験が生まれるリスクも高まり、それを防ぐためにもさらなる調整が必要になります。
マルチプロダクト企業への転換
現在直面している最大の戦略的課題は、単一プロダクト企業からマルチプロダクト企業へと移行することです。RevenueCatは長年、アプリにアプリ内課金を導入するための最良の手段として位置づけられてきました。その結果、多くのサブスクリプションアプリが最初からRevenueCatを採用しています。しかし、新規のサブスクリプションアプリの市場には限界があります。
成長を続けるためには、既存のターゲット市場に対してより多くの価値を提供すると同時に、現在のRevenueCatプロダクトが適していない新しい顧客層にもアプローチする必要があります。そのためには、完全に新しいプロダクトを追加するか、既存のプロダクトを分解して個別に提供できるようにするなど、マルチプロダクト戦略が不可欠です。
私たちはその両方に取り組む計画であり、それに伴ってプロダクト意思決定のプロセスも大きく変わることになります。プラットフォームの一部だけを利用するユーザーにも適した体験を設計し、価格や課金モデルを構築し、適切なプロダクトを見つけて設定できるオンボーディングフローを設計する必要があります。
この取り組みはまだ始まったばかりであり、今後しばらくは私たちにとって大きなテーマであり続けるでしょう。
RevenueCatにおける優れたとはプロダクトエンジニアとは
ここまで読んでいただけましたか？それでは、RevenueCatにおけるプロダクトエンジニアに適した人物像について見ていきましょう。もしかすると、あなた自身がその人物かもしれませんし、思い当たる誰かがいるかもしれません。
- ビルダーであり、マネージャーではない：RevenueCatのPEは自分たちを「プロダクトを作る人」と捉えています。バックログを管理したりステークホルダーを調整したりするのではなく、協働し、最適な解決策を提案し、チームがより速く前進できる よう支援します。
- ミッショナリー：私たちのミッションは開発者がより多くの収益を得られるようにすることであり、PEはそれを強く信じています。ソフトウェアが世界にとって良いものであり、開発者が成功することでより多くのソフトウェアが生まれると考えているからこそ、顧客に強くフォーカスします。
- 徹底したオーナーシップ：RevenueCatのPEは、顧客の課題を解決しプロダクトを成功させるために必要なことはすべてやります。他人を責めたり失敗を受け入れたりするのではなく、チームの一員として責任を分かち合いながら前に進む方法を見つけます。孤立した個人ではなく、チームの一員として行動します。
- 不完全な情報でも決断できる力：スピードの速いスタートアップ環境では、PEは必要十分な情報を集めて素早く意思決定を行います。現在のデータに基づいて行動し、方針を定めてチームを導きつつ、新しい情報が得られた場合には柔軟に方向転換できる姿勢を持っています。
- 深い技術理解：RevenueCatは複数のユーザー層に対応していますが、本質的には開発者向けツールです。そのためPEには、API、分散システム、SDKの制約、データモデルといった領域について深い技術的理解が求められ、それらに関する意思決定を説明し評価できる必要があります。
- 非同期コミュニケーション力：グローバルなリモートチームであるRevenueCatでは、PEはドキュメント、Loom、FigJamなどを用いた明確な非同期コミュニケーションに優れており、必要に応じてリアルタイムの会話に切り替えてチームの認識を揃える判断力も持っています。
採用中です！
RevenueCatではプロダクトエンジニアチームを継続的に拡大しています。難しくも意味のある問題に取り組み、何万もの開発者が好きなことを仕事にできるよう支援したいと考えるビルダーであれば、ぜひお話ししましょう。詳しくはキャリアページの募集をご覧ください！