はじめに
こんにちは、サーバーサイドエンジニアの中川（@tkdev0728）です。 実は最近サーバーサイドの採用面接も担当しているのですが、面接の場で「実際どんな技術を使っているんですか？」「チームってどんな雰囲気ですか？」という質問をいただくことが多く、もっと事前に知れる情報を増やしたいと思いこの記事を書きました。
2026年6月現在の情報となりますが、こちらでヤプリのサーバーサイド組織に少しでも興味を持っていただけたら幸いです。
働き方とコミュニケーション
働き方
所定労働時間
- 10:00〜19:00
- フレックスタイム制度あり（コアタイム 10:00〜16:00）
ハイブリッド勤務
出社とリモートのハイブリッド勤務です。現在は週2日の出社が必要となっており、オフラインでの会話も大切にしています。
人数
サーバーサイドエンジニアは現在20名超。後述する4つの部署に分かれて開発を行っています。チームとしてはそれなりの規模感ですが、オンライン/オフライン関係なく全員がSlackや定例で気軽に話せる距離感です。
コミュニケーション
サーバーサイド全体として日次の定例は設けておらず、基本的には非同期コミュニケーションを中心に動いています。ただ、各部署やチームは必要に応じて定例を行なっているので、非同期・同期を使い分けているイメージです。個人的には集中しやすい環境だと感じています。その上で、サーバーサイドや開発全体として定期的に集まる場も大切にしています。
SV定例（週1回）
サーバーサイド全体の定例です。技術的な相談をカジュアルに行なったり、仕事に活かせそうな技術、仕事関係ないけど最近気になっている技術などをフラットに話せる場になっています。最近だとGo Conferenceに出すプロポーザルを考えるワークショップを全員で行なったりしました。
プラットフォーム技術共有会（月1回）
iOS・Android・フロントエンド・サーバーサイドなど、他部署のメンバーと一緒に技術的なテーマについてディスカッションする場です。インシデント共有として直近のインシデントからどんな学びを得たか共有したり、フリー共有という文字通り自由に技術的なテーマで話したりしています。最近だとiOSエンジニアによるWWDCの発表内容の共有があったり、サーバーサイドエンジニアによるCIのコスト削減を題材にしたAI時代の守備範囲の考え方の共有など考えさせられる共有があったりします。
YappdateWeek（Q1回）
毎Qに1度、プロジェクトタスク以外の開発に充てられる時間です。
実はもともとYappdateDayという月ごとに2日割り当てられた時間だったのですが、「システムが大きくなるにつれて1~2日で終わる課題が減って中規模課題が溜まってきた」という課題がありました。
そういった背景も踏まえて1日では対応しきれない中規模な開発にも期日を切ってコミットするためにWeekにアップデートされました。
前段のYappdateDayについてはこちらの記事もご覧ください。
Win Session（隔週）
こちらも他部署のメンバーと一緒に各チームごとに日々の成果（WIN）を共有します。例えば今こういう開発を進めていますといった共有だったり、このリリースの裏では実はこんな苦労があって... などなかなか表に出づらい裏側の本音だったり、クライアントが見るサポートページの改善だったりが話されます。発表者もエンジニアだけでなくデザイナーやサポートチーム、申請チームなど多種多様なメンバとなっており、ただ聞くだけでなくSlackで感想や感謝の言葉を言い合っています。個人的にここで得られる周りの反応はモチベーションにつながりますし、逆に他チームの工夫や苦労も知れるので気に入っています。
LT大会（Q1回）
業務終わりにお酒やピザを食べながらオフラインとオンラインのハイブリッドで開催されるイベントです。 発表時間は5分目安で発表される内容は直近入られた方の自己紹介であったり、趣味で触った技術の話だったり、完全プライベートの推し活の話だったり技術に限らずなんでもありとなっており、発表のハードルは意図的に低く設定されているので私もよく登壇しています。
社内開催で身内しかいないのでオフラインの登壇経験を積むにはもってこいだと思います。
技術スタック
プログラミング言語とフレームワーク
- 言語：Go、PHP
- フレームワーク：Laravel（PHP）
- アーキテクチャ：DDD（ドメイン駆動設計）
インフラ・ミドルウェア
- クラウド：AWS（ECS/Fargate、Aurora MySQL、EFS、S3）、Google Cloud
- 通信プロトコル：gRPC、REST
- その他：Redis
開発ツール・運用
- リポジトリ管理：GitHub
- CI/CD：CircleCI、GitHub Actions
- 監視・可観測性：New Relic
- IaC：Terraform
AIサービス・ツール *1
- Claude Code
- Codex
- Gemini
- Devin
- etc...
開発組織
ヤプリのサーバーサイドは、現在4つの部署に分かれて開発しています。技術スタックは共通する部分が多いですが、それぞれ担当するプロダクトや目指すものが異なります。
Yappli開発部
ヤプリの主力事業であるYappliプラットフォームの安定稼働と継続的な改善を担います。約1000のアプリ基盤のバックエンドを支えており、スケールと信頼性の両立が常に求められます。
CX開発部
顧客体験の向上を目的とした機能開発を担います。ビジネスサイドの要望をスピード感を持って実現しながら、技術的な観点から最適な設計を提案する役割です。「実装するだけでなく、事業の成功に主体的にコミットする」というスタンスが特徴で、開発とビジネスの両側と密接に連携します。
UNITE開発部
社内エンゲージメントアプリプラットフォーム「UNITE by Yappli」の開発を担当します。Yappliをベースに構築されたサービスで、エンゲージメント特化の機能を専任チームで開発しています。
マルチプロダクト開発部
Yappli・Yappli CRM・Yappli WebXなどヤプリが提供する複数サービスがシームレスにつながるAPI・連携基盤を開発します。単一プロダクトの枠を超えてシステム全体を横断した設計が求められるため、ヤプリの技術スタック全体を幅広く把握できるポジションです。
私たちが向き合う挑戦
約1000のアプリを支えるバックエンドのスケール
ヤプリのサーバーサイドは、約1000アプリを一つのプラットフォームで支えています。1つのAPIの変更が約1000アプリのエンドユーザーに影響するということは、変更の慎重さと、それを実現するための仕組みづくりの両方が求められます。大変な面もありますが、個人的にはこの規模感で仕事できることが大きなやりがいだと感じています。
カナリアリリースを用いた段階的なリリース、New Relicを使ったリアルタイムなログ・トレース監視など、大規模環境ならではの運用設計が求められます。また、インシデントが発生した際はチームで迅速に対応し、復旧後にポストモーテムを行って再発防止策まで考えるのが私たちの文化です。個人のミスを責めるのではなく、仕組みで解決するというマインドが根付いています。
PHP → Go + DDDへのアーキテクチャ進化
もともとAPIはPHPの独自フレームワークやLaravelで構築されていましたが、サービスの成長とともに複雑性が増していきました。現在は基本的に新規実装をGoとDDDで設計しており、CMSのバックエンドもGoで動いています。一部のAPIはPHPが残っていますが、現在は積極的な移行は行っておらずタイミングや開発内容に応じて必要あれば移行している状況です。
なぜGoとDDDを選んだのか。ヤプリのサーバーサイドが扱うドメインは、プッシュ通知・クーポン・会員管理・ポイントなど、複雑なビジネスロジックが絡み合っています。DDDのアプローチで設計を整理することで、変更に強い構造を実現しています。GoはgRPCとの相性も良く、サービス間の通信にも活用しています。
実際に10年以上稼働していたPHPの独自フレームワーク製APIをGoにリプレイスした事例も記事にしています。設計から実装・リリースまでの進め方が参考になれば幸いです。
PHPとGoが現在も共存しており、既存コードのリファクタリングや移行も続いています。レガシーと向き合いながらモダン化を進めていくのは大変な部分もありますが、実際の事業で起きるリアルな課題に取り組めるのは面白いと感じています。
大規模データのパフォーマンス改善
規模が大きいサービスだからこそ、パフォーマンス改善のインパクトも大きくなります。実際に私たちのチームが取り組んだ事例を2つ紹介します。
MySQLのパーティション剪定で16倍改善
Eloquentクエリに条件を1行追加するだけで、MySQLのパーティション剪定が正しく機能するようになり、クエリのパフォーマンスが16倍改善しました。問題の発見から原因特定、改善までのプロセスを丁寧にたどった事例です。
CSVユーザーインポートをCPUとI/Oの両面から爆速化
54億回の比較が発生していたCSVインポート処理と、Firebase API呼び出しのボトルネックに向き合い、CPU・I/Oの両面からアプローチして大幅に高速化しました。
オブザーバビリティの強化
New Relicを活用したログ収集・分析・アラートの仕組みを整えています。エラーが発生したときに「どのコンテナの・どのリクエストで・どのクエリが・何秒かかって失敗したか」をすぐに特定できる状態を維持することが、大規模サービスの信頼性を支えています。
アラートの精度向上（重複排除・ログレベルの適正化）なども継続的に取り組んでおり、「鳴りすぎるアラートで疲弊しない」環境づくりも大切にしています。
アラート対応の属人化解消にも取り組んできました。「気づいた人が見る」という性善説の運用から、当番制とマニュアル整備によってチーム全員が初動できる体制へと進化させた取り組みです。
AIを活用したエンジニアリングの加速
ヤプリのサーバーサイドではClaude Codeを積極的に開発に取り入れています。社内でのClaude Code活用については、Skills・Scheduleなどの仕組みを使って部署横断で共有する取り組みも進んでいます。
また、個人環境で育てたSkillを部署横断で共有できる社内マーケットプレイスの仕組みも整えており、AI活用の知見をチーム全体に広げていく取り組みを続けています。AIとどう付き合うかを技術的に真剣に考えているチームです。
入社後のスキルアップ環境
オンボーディング
入社後はYOP（Yappli Onboarding Program）と呼ばれる3ヶ月のオンボーディング期間があります。入社初日はウェルカムランチでチームメンバーと顔合わせするところからスタートです。
まずYappliのアプリを実際に使う研修からスタートします。自分たちが開発しているサービスをユーザー視点で触れることで、その後のキャッチアップがスムーズになります。
続いてメンターからシステム概要のレクチャーを受け、開発環境を構築して実務へ入っていきます。定期的にメンターと1on1があるので疑問をためることなく進められます。
最初はスコープが明確なタスクから始まり慣れてきたら課題解決のアプローチも自分で考える形になっていますが、もちろん経験やスキルによっては早い段階から難易度の高い実務にもアサインされることがあります。
技術的なキャッチアップと並行して、社内のつながり作りも自然と広がります。「バトンランチ」という文化があり、これから関わることの多い他部署の方とランチして、その人にまた別の社員を紹介してもらうといったリレー形式で、業務上の接点がなくとも自然に社内の知り合いが増えていきます。
私自身も中途入社でしたが、このYOP期間のおかげでサービスの全体像をスムーズにキャッチアップできましたし、チームや組織にうまく溶け込むことができました。
発信する文化
テックブログ執筆、プラットフォーム技術共有会やWin Sessionでの発表、LT大会など、社外・社内に向けて発信する機会が定期的にあります。「書いてみたいけど何から書けば」という状態でも、チームでテーマ出しや内容レビューをサポートする文化があります。SV定例の章でも触れましたが、直近ではGo Conferenceに出すプロポーザルを考えるワークショップを行い、8つものプロポーザルを提出することができました。この記事もそういう文化から生まれており、実はレビューを依頼したメンバー以外からも積極的なフィードバックをいただけたりしています。
最後に
ヤプリのサーバーサイドは、大規模なプラットフォームの信頼性を支えながら、モダン化・パフォーマンス改善・AI活用といった挑戦を同時進行で続けているチームです。「安定」と「進化」を両立させることの難しさと面白さに向き合える環境だと思っています。
記事に書いた以外にも色々とやっていたりするので、「もう少し具体的な話を聞いてみたい」「自分のスキルがどう活きるか聞きたい」という方は、ぜひカジュアル面談にお越しください。
*1:※これらのツールはセキュリティガイドラインに準拠し、ソースコードが外部に学習されない環境を担保して利用しています
