ID:84128さん

## 自社ライブ配信サービス「Pococha」のバックエンド開発（2024/04〜現在） ### プロジェクト概要 - 概要：MAU約30万のライブ配信サービス「Pococha」のバックエンド開発 - プロジェクト規模：チーム単位で5〜10名 - 役割：バックエンドエンジニア - 使用技術：Ruby / Ruby on Rails - 担当範囲：PdMとの仕様策定、API・DB設計、実装、テスト 初心者ユーザー向けの施策を中心に、新機能の仕様策定からバックエンドの設計・実装・リリースまで担当しています。 ### チュートリアル改善 **概要** 新規登録ユーザーが配信枠へ入室する前に、Pocochaの基本的な楽しみ方を理解できるようにするチュートリアル機能のバックエンド開発を担当しました。 公開情報：[【Welcome to Pococha第3弾】新機能「チュートリアル」「入室スタイル設定」がリリース！初心者リスナーさんに合わせた歓迎ができるようになります！](https://report.pococha.com/n/n90307fa0901f) **課題** 従来は会員登録後すぐにライブ配信を視聴する導線となっており、ライブ配信に馴染みのないユーザーが、サービスの楽しみ方を理解しないまま配信枠へ入室してしまう課題がありました。 バックエンドでは、単にチュートリアルの完了/未完了を保持するだけではなく、ユーザーが途中でアプリを離脱した場合や、後から再開した場合でも正しいステップから継続できるよう、進行状態を適切に管理する必要がありました。 **考えたこと・打ち手** クライアントとバックエンドの間で状態の解釈がずれると、不正な進行状態や再開時の不整合につながると考えました。 そのため、クライアントエンジニアと仕様をすり合わせながらチュートリアル全体の状態遷移を整理し、それをもとにデータモデルとAPIを設計しました。 特に、正常系だけでなく途中離脱・再開などのケースを含めて状態遷移を整理することで、クライアント側からも一貫した形で進行状態を扱えるようにしました。 **使用技術** - Ruby(Ruby on Rails)：チュートリアルの進行状態を管理するAPI・バックエンドロジックの設計、実装、テスト **成果** 新機能をリリースし、新規登録ユーザーの離脱率改善に貢献しました。 具体的なKPIは社外秘のため非公開です。 ### さがす機能の開発 **概要** リスナーが配信枠へ入室する前に、リアルタイムで配信枠の雰囲気を確認できる「さがす機能」のバックエンド開発を担当しました。 公開情報：[【新しい出会いの手段】「さがす機能」をリリースします！](https://report.pococha.com/n/nbe952ab18156) **課題** 従来はサムネイルを手がかりに配信枠を選ぶため、実際に入室するまで配信の雰囲気を把握できませんでした。 バックエンドでは、リスナーの利用条件、ライバー側の公開設定、ユーザー間のブロック関係など複数の条件を考慮し、閲覧可能な配信枠だけを返す必要がありました。 また、既存機能にも配信枠へのアクセス可否を判断するロジックが存在するため、新機能側に独立した判定を持つことで、将来的に仕様変更時の不整合が発生しないよう考慮する必要がありました。 **考えたこと・打ち手** まず、既存の配信枠へのアクセス可否に関するロジックを確認し、新機能固有の条件と既存機能でも共通して利用すべき条件を整理しました。 判定ロジックが複数箇所へ分散すると、仕様変更時に条件の適用漏れや挙動の差異が生じると考えたため、責務を整理したうえで既存ロジックとの整合性を保つAPI設計としました。 **使用技術** - Ruby on Rails：配信枠の取得API、閲覧条件の判定ロジックの設計・実装・テスト - 既存のRailsアプリケーション上で、既存機能への影響を考慮しながら新機能を追加 **成果** 機能をリリースし、ユーザーから肯定的なフィードバックを得ました。

## 社内業務効率化ツールの開発（2026/04〜2026/07） ### プロジェクト概要 - 概要：社内業務効率化のためのWebアプリケーション開発 - プロジェクト規模：5名 - 役割：PM兼テックリード - 使用技術：TypeScript / Next.js / Hono 想定利用者へのヒアリングから要件整理、タスク分解、スケジュール管理、設計、実装、コードレビューまで担当しました。 ### 要件整理・開発プロセスの設計 **課題** 少人数かつ限られた開発期間のプロジェクトだったため、利用者から挙がった要望をすべてそのまま実装すると、期間内に必要な価値をデリバリーできない可能性がありました。 また、要件が曖昧な状態で複数メンバーが並行して実装を開始すると、認識のずれによる手戻りが発生する懸念がありました。 **考えたこと・打ち手** まず想定利用者へのヒアリングを行い、「要望」と「解決したい課題」を分けて整理しました。 その上で、優先度の高いユースケースからユーザーストーリーと受け入れ条件へ落とし込み、各メンバーが完了条件を判断できる粒度までタスクを分解しました。 PM業務だけに専念すると開発リソースが不足するため、自身も実装とコードレビューを担当しました。 ### 開発におけるAI活用 **課題** 限られた人数と期間の中で開発速度を確保しつつ、設計や仕様判断など人間が行うべき作業へ時間を割く必要がありました。 **打ち手** Claude CodeやCodexなどのコーディングエージェントを、定型的な実装、テストコード作成、リファクタリングなどに活用しました。 一方で、設計や仕様の判断、生成されたコードの妥当性確認は人間が行うものとして切り分け、型チェック、自動テスト、コードレビューを通して品質を担保しました。 **成果** 要件整理から実装、プルリクエスト作成までのリードタイムを短縮し、限られた開発期間でのデリバリーにつなげました。

- 概要：生成AIアプリの開発 - プロジェクト規模：3名（役割：フロントエンドリード） - 技術：TypeScript / Next.js / NestJS - 業務内容：生成AIを組み込んだBtoB向けSaaSの開発に、フロントエンドエンジニアとして参画しました。フロントエンドの設計・実装・レビューをリードしながら、プロジェクトの状況に応じてバックエンド開発も担当しました。 - AI活用：生成AIコーディングエージェントに、コンポーネントやAPIクライアント、テストコードの初期実装を任せ、設計判断や機能間の結合に注力しました。 - 成果：担当領域をバックエンドまで広げながら、タイトなスケジュールの中で予定していた機能のリリースに貢献しました。

## プロダクトの0→1立ち上げ ### 課題 当時、ゲーマーが一緒にプレイする相手を探す際には、Twitter（現X）上で「一緒にゲームしませんか？ @1 #apex」のように募集し、それを見たユーザー同士が連絡を取り合って一緒にプレイする方法が一般的でした。 一方で、この方法では相手の性格やプレイスタイルが事前に分かりづらく、相性の良し悪しを判断しにくいという課題がありました。また、チートなどの不正行為を行うユーザーとマッチしてしまう可能性もあり、安心して一緒に遊べる相手を見つけるという点でも課題がありました。 ### 考えたこと・打ち手 そこで、単にプレイヤー同士をマッチングするだけではなく、ユーザーのプロフィールやプレイスタイルに関する情報をもとに、相性が良さそうなユーザー同士を繋ぐ仕組みを設計しました。 また、サービス上でユーザー情報を一定程度蓄積・管理することで、Twitter上の単発的な募集よりもユーザーの質を担保しやすい状態を作り、安心して一緒に遊べる体験を目指しました。 マッチング成立後は、ユーザー同士がすぐに一緒にプレイできるよう、Discord上にボイスチャンネルを自動生成する仕組みも実装しました。 一方で、マッチングサービスは一定数のユーザーが同じタイミングで利用しなければサービス本来の価値を提供しづらいという課題がありました。そのため、完成したサービスをそのまま一般公開するのではなく、利用者が同じ時間帯に集まるイベント形式で初回リリースを行いました。 イベントという明確な利用タイミングを設けることで、立ち上げ初期でもマッチングに必要な人数を確保し、実ユーザーにマッチングからDiscord上で一緒に遊び始めるまでの体験を提供できる状態を作りました。 ### 使用技術 * TypeScript / Next.js：プロフィール閲覧やマッチングを行うWebアプリケーションのフロントエンドを設計・実装 * Go：バックエンド機能を設計・実装 * Discord連携：マッチング成立後にボイスチャンネルを自動生成し、ユーザーがそのままコミュニケーションを開始できる仕組みを構築 ### 成果 イベント形式でサービスをリリースし、初回イベントには約100名のユーザーを集めました。 一定数のユーザーが同じ時間帯にサービスを利用する状態を作ることで、立ち上げ初期でも実際にマッチングが成立する環境を用意し、プロフィールをもとにしたマッチングからDiscord上で一緒にゲームを始めるまでの一連の体験をユーザーに提供しました。 また、イベントやユーザーインタビューを通じて得られたフィードバックを、その後の機能改善やプロダクトの方向性検討に活用しました。