giftee engineer blog

Recurring ユニットの開発チーム紹介

2021-10-12

Recurring ユニットの開発チームがなにを作っていて、どんなチームか紹介します

giftee entrance

はじめまして。 PlusPass の 開発ディレクターをしている中井です。 今回は、PlusPassを開発しているRecurring ユニットの開発チームの紹介をしたいと思います。

何を作っていますか

サブスクリプションや回数券を販売するwebサービス開発しています。 昨年の12月にローンチしたサービスです。

具体的には、「PlusPass」という、 サブスクリプション・回数券の販売プラットフォームを作っています。 お客様によっては、プラットフォームではなく、自社サイトとして利用したい方もいらっしゃりOEM版の提供もおこなっています。

サービスの特徴としては、 取り扱っている商品のほとんどが来店型のサブスクリプション・回数券です。サブスクリプションをPlusPassで購入して、毎日お店で商品を受け取る、と言ったような使い方になります。 大好きな店舗・ブランドを頻繁に利用しやすくなるサービスと思ってもらえれば分かりやすいかなと思います。

どんな体制ですか

2021年6月現在、 正社員のエンジニア3名と、 業務委託や副業のメンバーが7名ほどいます。 当初、業務委託メンバーは約3名ほどしかおらず、約半年ほどでローンチまで漕ぎ着きました。 今年に入ってから、フロントエンドエンジニア、インフラエンジニア、サーバーサイドエンジニアと次々に参画いただき、やっと腰を据えて開発をできる下地が整っていたという状態だと思っています。 まだどのポジションも1人ずつしかいないので、いずれも募集中です!

具体的に、ポジションごとの構成としては以下のようになっています。

フロントエンド:2人 サーバーサイド:5人 インフラ:2人 QA:1人

※開発の他は、マネージャー/営業/CSで5人います

フロントエンドとサーバーサイドの垣根は低めで、1機能作るのに1人でフロントとサーバー両方書くメンバーがいたり、フロントのパフォーマンスを考えてサーバーサイドのコードを改善してくれるメンバーもいます。

また特色としては、初期から海外のエンジニアにも参画してもらっており、インド、ベトナム、日本とアジアを跨いだメンバーで開発を進めてきました。自分を含め、英語が得意というレベルではないですが、昨今の国内のエンジニア不足にくじけず、国際的な働き方を選んできました。 開発の日常としては、githubやSlackは英語が多めで、毎週のオンラインミーティングでは英語を話しています。

技術面

現在、PlusPassをはじめとするサービス提供はwebアプリケーションで提供しています。 主に、 フロントはReact、 サーバーはRuby on Rails で開発しています。

良くある構成なので、説明不要感はありますが、 Ruby on Rails のviewをそのまま使わず、Reactにした理由としては、 OEM対応のときに、フロントエンドのカスタマイズがしやすいようにしたいというもくろみがありました。

サービスの目指すところと設計

私たちは、PlusPassを「あなたの毎日をちょっとプラスにする 回数券・サブスクサービス」というテーマのもと、日々開発しています。

そんなちょっとプラス感をより多くの人に提供できるように、 サービス立ち上げ時、2点を特に意識していました。

  • データの分析/活用が可能な会員基盤
  • 柔軟にOEM対応可能なカスタマイズ機能 ※OEM(Original Equipment Manufacturing): 他社ブランドの製品としてのリリース

データ分析に関しては、 取り扱う商品がサブスクリプションや回数券と言う形式から、ユーザーが繰り返し使うため、ユーザーの継続や再購入といった行動ログが手軽かつ高頻度に集計・分析できる環境が非常に重要でした。 BIツールとしては、AWSのQuickSightを利用しています。 SQLを書かなくてもJoinや集計などが気軽にできることもあり、導入してからは、分析用のSQLを書いてもらうようなタスクがほぼ無くなりました。BIを活用して、bizメンバー(営業や施策検討・サービス設計などおこなうメンバー)が新商品の販売からすぐにデータを集めて改善提案・施策実行している場面もよく見かけます。

またOEMカスタマイズはかなり需要があります。OEMの導入に際して、既存機能の利用に加え、ほとんどの場合で1〜2個は新規機能のご要望をいただくことが多いですが、数ヶ月かからない程度でカスタマイズをご提供できる柔軟な設計になっています。

最近の開発の状況としては、デザインの大幅リニューアルや将来的な拡張のためにAPI連携機能を充実させていってます。

開発手法

メンバーも増えてきたこともあって、最近、スクラムを試し始めました。 それまでは、スクラムではないですが、週次でタスクの確認・整理はしつつ、営業の状況に応じて、必要な機能をリリースに間に合わせるために、やりくりするような状況でした。 引き続き導入いただけるお客様を増やすために、営業の状況に応じた柔軟な対応できる体制は残しつつも、メンバーが増えて余裕が出てきたので、リファクタリングや組織改善的なタスクも盛り込みつつ、プロダクト開発を進めています。

機能開発の作業分担としては、まずクライアントのご要望やお客様のお問い合わせ、プロダクトロードマップから、ざっくり機能要件があがってきます。 プランナーやディレクター的なポジションは一人しかいないので、全ての機能に詳細な仕様が作成できる状況ではないこともあり、クライアント要望はビジネスサイドのメンバーがワイヤーフレーム作成までやったりすることもあります。またフルタイムのデザイナーがいないこともあり、デザインもやっているエンジニアもいます。 もちろん、人が足りないから何でもやらされる、というよりは、興味や得意分野を伸ばすような気持ちで取り組んでくれているメンバーが多いです。

具体的にどんな機能を開発しているについてですが、 販促機能や利用促進機能が半分くらいで、 残りの半分は、ユーザーが繰り返し楽しめるコンテンツ機能やUI/UXを向上させる機能を開発しています。

チームの雰囲気

サービスもまだまだこれからというところもあり、 取れる仕事は取っていこうという焦ってはいないけど、ちょっと前のめりな雰囲気でやっています。 そんな感じなので、こういう機能が欲しい、こういうことできたら導入できそうなのですが可能ですか、みたいな話を日々、bizメンバーが持ってきてくれるので、頻繁にわいわい議論しています。仕様が細かく決まったものを黙々と作るわけでは無く、上流から携われるのは、大変でもありやりがいがあるところかなと思います。

まとめ

Recurring ユニットでは、回数券やサブスクリプションといった同じお店を継続的、かつ頻繁に利用してお客様とお店が繋がれるプラットフォームを目指しています。 できたてのチームかつ新規事業をやっているチームだからこそできるフットワークの軽さでこれからも挑戦を続けていきたいと思っています。