美容医療サービスを通じて世の中を笑顔に

グループ会社全114社、2024年度の連結売上高2,774億円、従業員数7,565名という規模を誇るGMOインターネットグループ。
1991年に設立、2005年には東証一部上場も果たし、国内外でネットビジネス領域を牽引してきました。

そのメディア部門を牽引する、私たちGMOビューティーは2010年のサービス開始以来、
クーポンサイト『くまポンbyGMO』や美容医療のチケットサイト『キレイパスbyGMO』を通じて、お客様に新しい価値と喜びを提供してきました。

そして、美容医療業界のさらなる発展を目指し、
自由診療クリニック向けDXサービス『キレイパスコネクトbyGMO』や
オンライン診療サービス『キレイパスオンラインbyGMO』など、
革新的なサービスを展開しています。

これからも業界をリードするため、新たなサービスを次々と導入予定です。
私たちと共に未来を創る、熱い思いを持つ仲間を積極的に求めています。

仕事内容

「美容クリニックが患者と経営に集中できる環境を作る」というミッション実現するために、『キレイパスコネクトbyGMO』のプロダクト開発に携わっていただきます。

上記のミッションをサービスに関わる全チームで共有した上で、
開発チームは「Aという機能開発で潜在顧客の獲得を支援する」と「既存顧客の使いやすさ向上のためにBを作る」という風にミッション→それを実現するプロダクトに具体化して日々の業務に取り組んでいます。

開発の進め方

開発スタイルはカンバンを採用しています。
1つの機能開発に対して、通常1人のエンジニアが開発担当者として取り組みます。

ストリームアラインドな開発チームを構成することを意識しており、
インフラからバックエンド、フロントエンドまで一貫してチーム内のアプリケーション開発者が設計、開発、運用をしています。

タスクの種類ごとに、2つのモードを使い分けています。

• 新規開発モード
  • 潜在顧客を広げられる新機能開発は何か? 現状なくて、これから必要になる、今の使い勝手を大きく飛躍させる機能とは? をPMやデザイナーと一緒に考え実現していきます。
  • 例: 新規機能：デジタル診察券、決済端末との連携、経営分析機能 etc.
• CSE(カスタマーサクセスエンジニアリング) モード
  • コネクトの既存顧客から挙げられる具体的な要望・課題を元に、それを解決する方法を考えて実装します。

新規開発モードについては、1つの新規機能開発に対して一人のメインエンジニアが担当し、
1カ月～長くて3カ月程はその業務にフルで集中できる環境を作っています。
営業チームがヒアリングしてきた、クリニックの悩みや要望に対して、どうしたら解決できるかを模索し、仕様を考えるところからスタートになります。

メインの開発担当となるエンジニアは決めますが、一人でやり切らないといけないわけではなく、期限や開発規模によっては随時他のエンジニアと協働しながら作り上げることになります。

CSEモードについては、既存顧客からの要望・課題リストをベースに、顧客の声を聞いているCSチームの意見を聞きながら実装を進めます。

どちらのモードもPM、CS、デザイナーといった他職種のチームと協働して課題を解決していくという点では同じです。

キレイパスコネクトのチームについて

キレイパスコネクトの事業全体では、 新規営業、カスタマーサクセス、マーケティング、デザイン、エンジニアを含め20名ほど在籍しています。

その中で、キレイパスコネクトのエンジニアチームは4名です。

＜チームの雰囲気＞

• 知的好奇心が高めで、顧客課題を技術を使って解決することが好きなメンバーが多いです
  • 業界特化型のSaaSを作るために、なぜその機能が必要なのか業務フローから関心を持つ
  • 仕事で使っているライブラリでわからないところがあれば、そのままコードリーディング会を始める
  • 隣のグループ会社で起きたMySQLに起因する障害を首を突っ込んで解決する
• リモートで黙々、よりかはチームでワイワイ、仕事をしています
  • 基本は出社している人がほとんどなので、エラーが出たときなどは、皆でホワイトボードに仮説を書きながら解決していくなど、相談したいときにすぐできる環境です。

ポジションの魅力

• 機能開発に早期段階から携われる
  • キレイパスコネクトでは機能ごとに職種横断の事業組織を組成し、共に議論を重ねながら仕様などを決定します。早期段階から関われるため、背景や仕様への納得感を持って開発を行うことができます。
• 早くかつ簡単なCI/CD
  • masterにマージされたら自動デプロイされる環境があります。 CI/CDは早いが正義！という信念のもと、デプロイの時間が5~8分以内に収まるように心がけています。開発を続けていると様々な要因でデプロイ時間は伸びていくため、長くなって来た際はデプロイ時間を短縮しています。 また、PRを立てると、自動で検証環境が作られる仕組みを作っています。 バックエンドだと、Cloud RunのサービスをCIで作成してそこにデプロイしてPRの環境ができ、フロントエンドでは FIrebase Hostingの環境が作られるようになってます。 検証環境が空くのを待つ、デプロイ手順がわからない、という状態が発生しないようにしています。
• プラットフォーム課題
  • ユーザー（契約クライアント）が増えるに従い、増えていくデータ量に対して計算量を最適化する、 データ量が増えても問題が発生しないアーキテクチャに変えるというエンジニアリング的な面白さがあります。 データを取りこぼさない操作ログ収集のためのシステム、画像配信コストの最適化のような、ロジックや特定のサービスに依存しない横断的関心事を、プラットフォーム課題として管理しています。

技術スタック

GCPのマネージドサービスを積極的に採用しています

• バックエンド： Ruby (Ruby on Rails)
• フロントエンド： TypeScript (Angular)
• スキーマ定義： OpenAPI
• インフラ： Google Cloud (GCP)
• データベース： Cloud SQL (MySQL), Cloud Datastore (Firestore)
• モニタリング： NewRelic
• ダッシュボード： Metabase
• CI/CD： GitHub Actions
• その他： Notion, Slack, Figma, JetBrains Toolbox (RubyMine, WebStorm。希望者のみ。お好みのエディタをお選びいただけます)

必須要件

• バーティカルSaaSに興味をもって取り組める方
• ユーザーの声を聞いて開発したい方
• Ruby on RailsとTypeScriptでの開発に抵抗がない方

歓迎要件

• Ruby, TypeScript, Ruby on Rails, Angularなどによる開発経験
• Webアプリケーションフレームワークを用いた開発経験
• Google Cloudを用いたサービスの運用経験
• ISUCONの出場経験

求める人物像

• ユーザーの悩み・課題を解決することに注力できる方
• 同じチームのエンジニアはもちろん、デザイナー、PMなどの他チームとの協働作業ができる方
• 難しい技術課題が出てきた時にワクワクできる方
• 業務に関係のない会話を楽しめる方