ID:83054さん

【役割・概要】 飲食情報サービス（toC Web/アプリ）において、施策の意図・ドメイン（検索/リストACP/広告枠/予約導線など）を理解したうえで、既存アーキテクチャ（モノリスPHP／Goマイクロサービス／BFF・GraphQL／Nuxt3 SSR／Fastly振り分け）に沿ってプロダクトとして一貫した形で実装するのが得意領域です。フロント／バックの役割分担に縛られず、境界を跨いで設計とコードを揃えます。 【設計・表現力】 複雑なドメインロジックは、構造（レイヤ責務・データの流れ）を先に決め、可能な限りリーダブルに分解して表現します。後から読む人が迷わないよう、重要な前提・不変条件・移行中の例外はコメントやPR説明、必要に応じてドキュメントに残すことを意識しています（「なぜそうしたか」まで含める）。 【パフォーマンス・改善】 EXPLAINや実測（DB/キャッシュ）に基づき、アプリケーション層でのクエリ・キャッシュ・呼び出し構造の改善を行います。施策の仕様やスコープが現実の負荷・運用と噛み合わない場合は、早期に論点を可視化し、PO/企画側とすり合わせながら「出す範囲」「段階投入」「計測の置き方」を調整して、成果と持続可能性のバランスを取った経験があります。 【主な成果の例】 ・人気店ページのリプレイス（PHP→Go）: 段階的ロールアウトと整合性担保を重視しつつ、性能・障害リスクを踏まえて展開判断。 ・大規模障害・OnCaller対応: 切り分けから再発防止（監視/手順/ポストモーテム）まで、運用に耐える形で仕上げる。 ・スクラム運営・リリースフロー整備: 認知負荷を下げるためのプロセス設計（イベント構造、合意形成、標準化）。 【次に活かしたいこと】 「正しく動く」だけでなく、ドメインとアーキテクチャに沿って読み手に優しく、かつ計測可能な形でプロダクトを表現する。ミスや過負荷で人が壊れない設計（仕組み・スコープ・観測）を、実装と運用の両面から支えたいです。 【自分について】 https://kodmm.github.io/

## プロジェクト概要国内大手のグルメ口コミサービスにおける、エリア・ジャンル・駅などの軸で店舗を絞り込み表示する **一覧ページ** を、長年運用されてきた PHP モノリスから、独立した Go 製マイクロサービスへ段階的に移行するプロジェクトです。このサービスは月間数千万 PV 規模の toC トラフィックを受ける主要な集客面であり、SEO・収益・ユーザー体験のいずれの観点でも「事業ど真ん中」の領域です。アーキテクチャ刷新の難しさは、止められないこと、影響範囲が広いこと、そしてドメインが10年以上の積み上げで複雑化していることでした。このプロジェクトに、私はバックエンドのコア実装者・段階移行設計者・他チーム連携窓口として、要件整理から設計、実装、ECS / IaC・CI/CD 整備、PHP 側のクリーンアップ、そして本番展開後の動作検証までを一気通貫で担当しました。実装は2024年10月〜現在まで継続しており、merged PR は Go 製マイクロサービスだけで **52件**、関連する店舗データ供給 Go マイクロサービス（87件）・PHP 製管理画面リポジトリ（109件）・フロントエンド（Nuxt 3）・GraphQL BFF・CDN / Terraform リポジトリを合わせると **300件超**に及びます。2026-04 以降は「Valkey 導入」「広告枠ロジックの完全 Go 化」「PHP API 経路の削除」など、**移行の最終フェーズ**を主担当として推進しています。 --- ## 役割・職責 | カテゴリ | 私の役割 | | -------- | ---------------- | | バックエンド設計・実装 | Go 製マイクロサービスの主要 rpc を新規実装・既存リファクタ。ユースケース層・リポジトリ層・インターフェースアダプタ層の境界を引き直し、保守性を担保 | | 段階移行設計 | PHP↔Go 同等性を担保する同等性検証ジョブを CI に組み込む。リクエスト割合制御による段階移行で本番割合を上げる仕組みを設計し、「いつでも巻き戻せる移行」を維持 | | 他リポジトリの連携実装 | 店舗データ供給 Go マイクロサービス・GraphQL BFF・旧 PHP モノリス APIを跨いで実装 | | インフラ / IaC | ECS タスク定義の環境変数追加、Secrets Manager 経由の Basic 認証導入、Valkey クラスタへの接続設定、CDN / Terraform リポジトリでのキャッシュ振り分け | | ドメイン整理・課題発掘 | 10年もののロジックを Slack / Confluence / コードを横断して読み解き、移行可否・優先度を判断。「軸（大ジャンル・小ジャンル・サブエリア・駅）」「内部リンク」「パンくず」「meta title」など各機能の責務を再定義 | | ステークホルダー連携 | 企画・PdM・SEO 担当・PO への翻訳。10年前の仕様を遡って意図を読み解き、現代化の提案を行いリリース判断につなげる | 「BE 担当」と一言で言える領域を超え、移行戦略・他チーム連携・インフラ・FE / CDN 整合性まで貫通して進めるのが、このプロジェクトでの私の動き方でした。 --- ## 課題と背景 ### 1. 10年もの PHP モノリスの限界旧来の一覧ページは PHP モノリスのうえに構築されていました。10年以上にわたり、複数の世代の機能（旧一覧ページ、軸別キュレーション一覧、テーマ別一覧、新一覧ページなど）が**同一コードベースに堆積**しており、以下の課題が顕在化していました。 - **可読性・保守性の劣化**: 同じユースケースに対して、世代ごとに書かれたロジックが並列で残っている。例えば「広告枠の店舗取得」だけでも PHP モノリス内の複数の広告枠取得関数と、新規 Go 実装の3経路が共存していた時期がありました。 - **依存の循環**: PHP モノリスが呼ぶサービス、サービスから呼び返す PHP のキャッシュロジック、それを参照する別のバッチ。何かを動かすと別の何かが連動して壊れる構造。 - **観測性の欠如**: PHP 側はログ・メトリクスの粒度が粗く、本番事象を再現するのに数時間〜半日かかる。 - **独立スケールの不能**: 一覧 toC の負荷スパイクが管理画面（一覧ページ）にも波及し、運用上の事故リスクとなっていた。 ### 2. ユーザー体験 / 事業面の課題一覧ページは SEO のメイン導線で、PV の大きな割合を占めます。にもかかわらず、 - ページレンダリング時間がユーザー体験を毀損するレベルの数値で滞留 - meta title / 内部リンク / パンくずの**生成ロジックが分散**しており、SEO 施策の打ちにくさが顕著 - 軸の組み合わせ（都道府県・エリア・サブエリア・大ジャンル・小ジャンル・駅）でロジックが複雑化し、新軸追加のリードタイムが長期化「変更したいが触れない」「触れるが事故が怖い」状態を、**アーキテクチャ側で解消する必要**がありました。 ### 3. 「移行を完遂しきる」ことの難しさリプレイスは過去にも何度か試みられ、しかし「半分まで進んで止まる」状態が続いていました。理由は明確で、**完遂のラスト1割（PHP 側のクリーンアップ・観測性・キャッシュ整備）が手付かず**になりやすかったからです。私が引き受けた局面では、「最後まで終わらせる」ことが事業価値であり、技術選定や設計よりも**ラストワンマイルの実装力**が問われていました。 --- ## 取った設計判断 ### A. リクエスト割合制御による段階移行と、同等性検証ジョブ「機能を切り替える」ではなく「**割合を上げる / 下げる**」設計にしました。具体的には、 - ある rpc に対して PHP 経路と Go 経路を両方用意し、リクエストごとに割合で振り分け - 同じリクエストに対する PHP / Go の出力を **同等性検証ジョブ** で比較し、不一致を CI で検知 - 出力の差異がある場合は仕様差なのか実装差なのかを切り分け、必ずチケット化（PR で issue 番号を残す）この設計により、「**いつでも 0% に戻せる安心感**」を担保しながら、本番で実トラフィックでの検証を進められる状態を維持しました。CI への組み込み（同等性検証ジョブ専用の CI ジョブ、カバレッジ・差分の PR コメント、hide属性競合の解消）まで含めて整備しています。 ### B. キャッシュ層の差し替え（Redis → Valkey、PHP → Go 直アクセス）旧構成は「Go サービスが PHP モノリス経由で Redis にアクセスする」という、ネットワーク上も論理上も**遠回りな依存**を持っていました。これを、 1. PHP の Redis アクセスロジックを Go に直訳しつつ、参照キーや TTL の同等性を担保 2. **Valkey クラスタ**（Valkey クラスタ）へ移行し、Go 直接アクセスへ切替 3. ECS タスクへキャッシュ接続用環境変数を注入し、Secrets Manager 経由で認証情報を整備 4. 開発者向けに、PHP 製管理画面リポジトリのローカル設定ファイルの記述例・SSH トンネル手順を Slack で共有し、ローカル開発でも詰まらないようサポートという形で、**「PHP に依存しない Go サービス」を完成**させました。最終的には PHP API 経路（広告枠取得用のPHPエンドポイント等）を削除し、Go 単独で広告枠店舗取得を行う構成に統一しています。 ### C. 「責務の境界」を引き直す旧コードベースでは、「店舗データ取得」「広告枠選定」「画像選定」「内部リンク生成」「meta title 生成」「パンくず構築」が、しばしば一つの巨大な関数に同居していました。Go 側のリファクタでは、 - ユースケース層には**ユースケース単位の振る舞い**だけを置く - リポジトリ層は **DB / 外部 API への純粋なアクセス**だけ - インターフェースアダプタ層で **rpc / バッチ / Web** の入出力を吸収という Clean Architecture の境界を貫徹し、**「同じデータを同じレイヤーから取りに行く」状態**を強制しました。この結果、後続の機能追加（4月以降の新軸対応や内部リンクの駅単軸対応）が、影響範囲を限定して入れられるようになっています。 ### D. 並列化・N+1 解消・nil 安全ホットパスの最適化として、 - 広告店舗コンテンツ取得 rpc と人気店舗取得 rpc を **goroutine + errgroup で並列化** - 画像取得を「軸ごとに有料・無料会員投稿画像・座席情報」を**1パスでまとめて取得**するよう設計し直し（旧実装は軸ごとに同じデータを再取得していた） - 重複排除の責務を usecase に集約し、軸間で同じ画像を返さない前提を保証 - nil 参照（サブエリアのランドマークタイトル等）で本番 panic を起こしうるパスを洗い出し、防御的プログラミングを適用「一見小さな最適化」を**正しいレイヤーで積み上げる**ことで、リプレイス後にむしろ性能が向上した状態を作りました。 --- ## 主な実装内容（PR 単位の代表事例）以下、Go 製マイクロサービスを中心に、関連リポジトリの代表 PR を抜粋します。すべて自分が author となっている merged PR です。 ### 1. サービスの土台整備（2024-10〜2024-11） - CI / CD パイプラインの整備と Docker での Go バージョン整合 - デフォルト一覧取得 rpc のモック実装と外枠定義（インターフェイスのレビューを先に進めるため） - 環境変数の参照パス修正、Datadog コンテナの secret 注入の切り出し - NotFound エラーをエラーとして計上しないハンドリング（メトリクスの正常化）「いきなり本実装」ではなく、**先に観測性と CI / CD の地盤を整えてから機能実装に入る**という順序で進めました。 ### 2. 新一覧ページ内部リンクの実装（2024-11〜2024-12） - 「エリアで探す」内部リンクセクションの新規実装 - 「他のエリアから探す」セクションで使用するリンク群とセクション名を返却 - エイリアス情報を考慮したエリア・サブエリア名の表示 - 誤ったリンクタイトル名の修正 - パンくずリストにおいて、軸パラメータの2軸目に小ジャンル軸が入った場合の title 名を変更ここで、「**内部リンクは SEO に直結するので壊しちゃいけない領域**」という認識のもと、PHP / Go 双方の出力を実 URL レベルで突き合わせる検証を CI に組み込みました。 ### 3. デフォルトタブ / meta title 生成（2025-04〜2025-06） - 「デフォルトタブ」 meta title 生成フローの大枠 - 不要関数のコメント整理 - meta title 生成関数のテストコード追加 - CI にカバレッジレポート用 CI ジョブ追加 - 同等性検証ジョブとカバレッジレポートの hide 競合をテンプレートキー分離で解消 - 新一覧ページの3軸内部リンクに index 判定を適用して出し分け同等性検証ジョブを運用する中で、CI 上のコメント表示が干渉する問題が発生したため、**自分でテンプレートキーの設計を切り出して恒久対応**まで完了させています。 ### 4. 段階移行のキー機能リプレイス（2025-09〜2025-10） - キーワード最適化によるリダイレクト処理を Go へ追加 - 広告店舗コンテンツ取得 rpc / 人気店舗取得 rpc の並列実行 - 一覧ページに表示するデータを新マイクロサービス基盤から取得するための下地の**テストコード対応** - 人気店枠で返す各店舗が「お店会員か否か」を識別 - 口コミ画像を1店舗最大3枚に制限 - 画像ファイルパスのサイズ指定（サイズ指定接尾辞）を除去するユーティリティと網羅テスト - 内部呼称をフロントエンド側の語彙にそろえてリファクタ - サブエリアのランドマークタイトルでの nil 参照を防御 - PHP モノリスからの脱却を試行する実験的 PR - マッチングレポート機能の不要コードを削除ここから「**PHP モノリスからの本格的脱却**」が始まりました。この実験的 PR で依存箇所を洗い出し、結果として後続の広告枠ロジックの Go リプレイスに直結しました。 ### 5. 注力領域 ── 完全 Go 化と Valkey 移行（2026-04〜現在） - 駅単軸の内部リンク取得時にサブエリアのランドマークタイトルで panic しないよう修正 - 「エリアから探す」のパンくずリストで駅単軸対応 - 1軸の meta title 生成ロジック実装 - 市町村一覧で表示するリンク取得ロジックの修正 - 末尾に「駅」をつけるかを考慮した駅名返却 - 新着レストラン情報（内部リンク）を返す rpc を新規実装 - 広告店舗ID取得 rpc のリファクタと**段階的移行の定義改変** - 広告枠の優先順位制御ロジックを **Go へ完全リプレイス** - ECS タスクへ PHP API のエンドポイント環境変数とキャッシュ接続用環境変数を注入 - PHP API への Basic 認証（Secrets Manager の URL から注入） - Valkey クラスタから一覧ページの事前計算キャッシュを取得 - 存在しないテーブルを参照していた箇所の修正 - 同等性検証ジョブで Valkey と PHP API を AFTER サーバーに渡す CI 改修 - 広告枠店舗取得の **PHP API 経路を完全削除**し、常に Go 実装を使用 - 移行検証ツールの削除とインフラ依存命名の整理（**移行完遂宣言**）このフェーズを「**注力領域**」と呼んでおり、**PHP モノリスからの完全脱却**を達成しています。「PHP API 経路削除」と「移行検証ツール撤去」するまでの一連の流れは、**始めて完遂された大型リプレイス**として社内でも文脈共有しました。 ### 6. 関連リポジトリでの実装 - **店舗データ供給 Go マイクロサービス（87件）** — 一覧ページが参照する「店舗データ供給」のレイヤー。軸別キュレーション一覧の各軸（みんなが予約しているお店軸、PayPay ポイントもらえる軸、個室軸、雰囲気軸、口コミが多い人気のお店軸など）の実装、一覧ページ用画像取得、有効ページ判定の SQL パフォーマンス改善、店舗情報一元管理バッチでの nil 安全対応、advanced-search-service との繋ぎ込み等を担当。 - **PHP 製管理画面リポジトリ（109件）** — 旧 PHP モノリスのうち、お店向け管理画面と toC 一覧の境界に位置する部分。Go 化後の API 接続クライアント整備、PHP 側の不要コード掃除、Vue 2 → Vue 3 への対応など。 - **GraphQL BFF** — GraphQL スキーマの整合性、BFF 層からの呼び出し変更。 - **CDN / Terraform リポジトリ** — エッジ層でのリクエスト振り分け、CDN キャッシュキーの再設計。これらを**横串で同時に動かす能力**が、このプロジェクトの肝でした。1リポジトリで完結する PR は少なく、ほぼ毎回「クロスリポジトリ」の整合性を担保する PR 設計になっています。 --- ## 出したバリュー ### 定量 | 指標 | 数値 | | ---- | ---- | | Go 製マイクロサービスでの merged PR | **52件**（2024-10〜2026-05） | | 店舗データ供給 Go マイクロサービスでの merged PR | **87件** | | 関連する PHP 製管理画面リポジトリの merged PR | **109件** | | 関連する toC 一覧で削除した PHP API 経路 | **1経路（広告枠の優先順位制御ロジック）を完全削除** | | PHP モノリスへの依存削減 | 主要 rpc については **依存ゼロ** | | 並列化による主要 rpc のレスポンス改善 | 主要 rpc で N+1 解消・並列化により**ホットパスの待ち時間が大幅に短縮** | | 広告枠ロジックの観測性 | Datadog 上の APM トレースを Go 側で取得可能に（旧 PHP は粒度不足） | ### 定性 - **「完遂された大型リプレイス」** という前例が社内に残ったことで、他サービスでも同様の段階移行手法が参照されるようになりました。 - **新機能追加のリードタイム短縮**: 新軸（駅単軸対応など）が、Go 側で1〜2 PR 単位で安全に追加できる状態に。 - **観測性の獲得**: Datadog APM を全 rpc に展開し、本番事象の調査が「数時間 → 数十分」レベルに短縮（OnCaller 経験から実体験的に確信できる範囲です）。 - **チームへのナレッジ移植**: 同等性検証ジョブの運用ノウハウ、ECS 環境変数の追加手順、Valkey の接続設定例などを Slack / Confluence で都度共有し、後続メンバーが**同じ落とし穴にハマらない**状態を作りました。 --- ## 苦労した点と乗り越え方 ### 1. 10年前の仕様の意図を読み解く最大の壁は「**10年前に意図的に作られた仕様**」との対峙でした。例えばパンくず・内部リンクの細部には、「当時の SEO 戦略のため意図的に入っている」ロジックが多数あります。これを単純に Go へ直訳すると、現代の SEO 戦略に合わない結果になることもありました。対応として、 - GitHub の古い PR / Issue を遡って意図を読む - Slack の過去ログを Slack 検索で検索して、当時の議論を再構築 - 必要であれば「10年前のこの仕様、今の前提では更新しても良さそうです」と PdM・SEO 担当に提案するを継続しました。「**その仕様、今の前提に合っていますか？**」と聞ける関係性をエンジニア側から作ることが、リプレイスの完遂には不可欠だと痛感しています。 ### 2. 段階移行中の事故防止リクエスト割合制御による段階移行では、「割合を上げた瞬間に本番で問題が出る」リスクが必ずあります。私が遭遇した例だと、 - のサブエリアのランドマークタイトルでの nil panic（特定の駅軸でのみ発生） - の市町村一覧リンク取得ロジックの不整合いずれも同等性検証ジョブで事前に差分は出ていましたが、「ノイズの中の本物の差分」を見抜くまでに時間を使いました。**「同等性検証ジョブの差分を必ず1件1件説明できる状態にする」というルール**を自分に課したことで、最終的にはこの種の事故がリリース後に再発しないラインに収まりました。 ### 3. インフラ・PHP・Go・FE を同時に動かす負荷完全 Go 化フェーズの一連の PR は、ECS タスク定義変更・Secrets Manager の値追加・PHP 側のコード削除・Go 実装本体・同等性検証ジョブの CI 改修・FE / BFF への影響確認を**ほぼ同時に進める**必要がありました。これは、 - 各 PR を「単独で revert 可能」な粒度に切る - 依存関係を Slack 上で明示し、レビュー順を提示する - インフラ反映と PHP 削除のタイミングをずらして「同時に倒す」を避ける - Slack 上で「**把握のほどよろしくお願いします**」と前広に共有して、関係者の認知不整合を防ぐという運用で乗り越えました。Slack のスレッドに**自分から前広に書きにいく**スタイルが、組織を横断する施策では極めて重要だと再確認しています。 ### 4. ステークホルダー間の合意形成「PHP 側で書き込んでいるじゃん？」（インフラ・PHP 担当）、「ここのキャッシュ仕様、当時の経緯は？」（CTO 室）、「この軸、今は廃止検討中なんだけど」（SEO 担当）、「FE 側はいつから新エンドポイント呼んでいい？」（FE）と、**多方向からの問い**が飛んでくる施策でした。それぞれに対して、 - 既存実装の URL（GitHub の行リンクまで）と挙動の差分を提示 - 「Go では◯◯までやります、◯◯は責務外として PHP に残します」と境界を明文化 - リリースタイミングを表で示して、**全員が同じスケジュール感**で動ける状態を維持する運用で合意に到達しました。**「翻訳とスケジュール明示」が、自分が一番貢献できた価値**だと感じています。 --- ## 学びと、次に活かしたいこと ### 学び - **段階移行は技術ではなく運用**。同等性検証ジョブの出力をどう解釈し、どう CI に統合し、どうレビュー手順に落とすかが本質。 - **完遂しきることが価値**。9割で止めると技術的負債が逆に増える。**残り1割の PHP 削除と検証ツール撤去まで含めて**、初めて事業価値になる。 - **責務の境界を引き直す機会としてのリプレイス**。新規実装と違い、リプレイスは「現実の制約」と向き合うので、設計力が試される。 - **クロスリポジトリの設計力**は、単一リポジトリでの開発経験では育たない。1施策が3〜5リポジトリにまたがる現場で何度も詰まりながら身につけた感覚です。 ### 次に活かしたいこと - 同様の段階移行をリードできる場が他社にもあれば、**設計から完遂までを最短で**進められる自信があります。 - リクエスト割合制御による段階移行・同等性検証ジョブ・キャッシュ層差し替え・PHP 経路削除という**型**を、別ドメイン（決済 / 検索 / コンテンツ配信など）に応用したい。 - 「**いつでも 0% に戻せる**」を前提とした移行設計と、「**最後まで完遂しきる**」をセットで進める文化を、次の組織でも持ち込みたいと考えています。 --- ## 補足: 使用技術 | カテゴリ | 技術 | | -------- | ---- | | 言語 | Go（バックエンド主言語）、PHP（旧モノリス側のクリーンアップ）、TypeScript（FE / BFF 連携） | | 通信 | gRPC（Proto 定義含む）、GraphQL（BFF 層） | | アーキテクチャ | Clean Architecture（usecase / repository / interfaceadapter） | | DB / キャッシュ | MySQL、Redis、**Valkey** | | インフラ | AWS ECS / ALB / Secrets Manager、Datadog（APM・Logs）、Fastly VCL、Terraform | | CI / CD | GitHub Actions、独自同等性検証ジョブ、coverage report、PR コメント自動投稿 | | 開発手法 | スクラム（スプリント計画・レビュー・レトロスペクティブ）、PR レビュー文化、Cursor / Devin を併用した AI ペアプロ |