メルカリのリーダビリティチームが取り組む、AI時代のスケーラブルな品質文化

Transcript

1. I. イントロダクション メルカリのリーダビリティチームが取り組む、AI時代 のスケーラブルな品質文化 モジュラモノリスの品質を支える戦略と実践 osari.k (Cross Border Engineering) 1 / 21
2. I. イントロダクション 自己紹介 osari.k 株式会社メルカリ Cross Border(XB) Engineering バックエンドエンジニア 2019年メルカリ入社 バックエンドエンジニアとして配送機能、マーケティング機能の開発に従事 現在はCross borderチームにてグローバルアプリのバックエンドシステム開発を担当 2 / 21
3. I. イントロダクション アジェンダ I. 背景と課題 チーム拡大時の課題とメルカリの挑戦 II. アーキテクチャと組織戦略 なぜModular Monolithを選んだのか Readability Teamによるスケーラブルなレビュー体制 技術事例：Feature Flag伝搬システムの設計 III. AI時代の品質管理 AI × ガイドライン基盤の相乗効果 私たちの反省点と学び 3 / 21
4. I. イントロダクション 開発チーム拡大時によくある課題 こんな課題を抱えていませんか? ☐ レビューが追いつかず、マージまで数日かかる ☐ コードの書き方がバラバラで、可読性が低い ☐ ベテランだけが知っている「暗黙のルール」が存在 ☐ 品質基準が属人化し、チームごとに異なる 4 / 21
5. I. イントロダクション 世界共通「メルカリ グローバルアプリ」の始動 One app for the whole world 2025年9月、台湾・香港より提供開始 世界共通のプラットフォームとして単一アプリを展開 AIリアルタイム翻訳を活用 圧倒的な展開スピードへの挑戦 目標: 3年以内に50以上の国や地域へ展開 エンジニアリングへの要求: 国が増えるたびにシステムを作り直す時間はない 「拡張性」と「初期開発速度」の極限の両立が必須 ビジネスインパクト 市場投入時間の短縮: 国ごとのシステム開発を不要に スケール効率: 一つのプラットフォームで全世界をカバー 5 / 21
6. II. アーキテクチャ選択 マイクロサービスで経験した課題 課題1: サービス数の爆発 チーム数を超えるマイクロサービスが存在 一つの機能実装に複数サービスへの変更が必要 課題2: 組織的オーバーヘッド オーナーチームとの調整コストが高い 非メンテナーのコントリビュートで品質の一貫性の担保が難しい。構成がサービスごとに違うのでコントリビューター用のドキュメントも 各自作成が必要 オーナー不明瞭なサービスの発生 課題3: 開発速度の低下 サービス立ち上げに時間がかかる 「サービスの細分化」が「組織のサイロ化」を生む 6 / 21
7. II. アーキテクチャ選択 モジュラモノリスというアプローチ 技術スタックと構成 言語: Go インフラ: Google Kubernetes Engine (GKE) 構成: 単一リポジトリ（Monorepo） 1つのバイナリ 目的 初期開発速度（Monolithの利点）と将来のスケーラビリティ（Moduleの独立性）の両立 メンバーの割り当ての流動性を高め、優先順位の高い機能をスムーズに開発 Microservicesのオーバーヘッドを排除 モノレポにすることで一貫性のあるコードベース 7 / 21
8. II. アーキテクチャ選択 単なるモノリスにしないための制約 Gateway(BFF), Tier 1-4の階層構造 上位から下位への一方通行 BFF → Tier 1 (Orchestration) → Tier 2 (Marketplace) → Tier 3 (Generic) → Tier 4 (Special) この制約により、Microservicesで起きた「依存関係のスパゲッティ 化」を構造的に防ぐ ↓ ↓ ↓ ↓ Gateway (BFF) Tier 1 Tier 2 Tier 3 Tier 4 8 / 21
9. III. 組織と技術の実装 品質を支えるリーダビリティチーム Readability Teamの構成 重要: 専属チームではない（Virtual Team） 構成：機能開発のエンジニア、SRE、アーキテクト（日本・イン ド混合） 通常業務を持ちながら、一定時間を品質活動に投資 開発初期から組成し、Microservicesで経験した実装の一貫性の維 持の難しさの経験を踏まえて活動 Readability Team 機能チームA 機能チームB SREチーム アーキテクト マネジメント層の理解 なぜこのチームが機能するのか？ マネジメント層の強いコミットメント 「品質維持への投資が、中長期的な開発速度低下を防ぐ」という 共通認識 これがなければ、機能開発の圧力に負けて形骸化してしまう 投資対効果 初期の品質投資により、後の開発速度低下を防ぎ、長期的な ROIを最大化 9 / 21
10. III. 組織と技術の実装 一貫性を保ちながら、全員がどのモジュールも開発で きる体制へ リーダビリティチームとは 目的: 可読性が高く、一貫性のあるコードの維持と開発スケールの支 援 役割: ガイドライン策定 コードレビュー 自動化ツール開発 効果: 新しいエンジニアの学習曲線を緩和し、オンボーディングを加速 組織内での担当変更やチーム間の貢献を円滑化 バグの検出や修正を容易にし、開発の品質とスピードを向上 システム開発の進化 初期 モジュールごとにメンバーをアサイン（Product、Order、Search等） モジュールごとに必要な実装を並行して行う モジュールに関するオーナーシップを持つ ▼ 現在 プロジェクトチーム体制へ移行 チームが必要な機能は、BFF〜Tier4までモジュール関係なく実装 メンバー全員がどのモジュールも開発できるようにする リーダビリティチームの役割: 一貫性のあるモジュールを維持する ことで、この方針を支える 10 / 21
11. III. 組織と技術の実装 多角的なアプローチで品質を支える 7つの活動 リーダビリティチームは以下の活動を通じて、コードの品質向上と開発スケールを支援しています: 1 ガイドラインの作成と維持 コードおよびPRガイドラインをGitHubリポジトリに集約 2 共通パッケージの作成 再利用可能なコンポーネントを提供 3 コードレビュー 複雑度の高いPRを中心にレビュー 4 自動化ツールの開発 CIによる自動チェックを実装 5 ワークショップの開催 ベストプラクティスの共有 6 隔週ミーティング ガイドライン、課題、改善点の議論 7 メトリクス駆動の改善 開発ボトルネックの特定と継続的な改善 11 / 21
12. III. 組織と技術の実装　―　①ガイドラインの作成と維持 ガイドラインの紹介 主要なガイドライン 【コーディング規約】 Go言語のコーディング規約 並行処理ガイドライン エラーコード処理 テストパターン 【インフラ・設計】 Protocol Buffersアノテーション DB設計ガイドライン セキュリティ設計原則 【プロセス・その他】 PRレビューの基準 その他多数... ガイドラインの特徴 公開されている情報を参考にしつつ策定 • Go公式ドキュメント • Protobuf公式ドキュメント • Tech各社が公開しているガイドライン • これらを参考にプロジェクトに合わせて策定 Good Code、Bad Codeの例を含む • 具体的なコード例で理解しやすく • なぜGoodなのか、なぜBadなのかを明記 12 / 21
13. III. 組織と技術の実装　―　①・②ガイドラインと共通パッケージ ガイドライン策定して終わりではなく、仕組みで解決 課題: エラー処理ガイドラインの例 ガイドライン Go言語ではエラーを2回以上処理しない エラーを呼び出し元に返すなら、ロギングしない ロギングするなら、エラーを返さない 理由: 似たようなエラーが複数箇所でロギングされると、ログ量が増 え、コスト増加とログ調査の困難化 現実とのギャップ 呼び出し元が知らない詳細な情報をログに付与したい場合 （例: どのIDでAPI呼び出しが失敗したか） IDをエラー文字列に含めると、Datadog上で検索しにくい "GetItem ID=123"と"GetItem ID=456"は同質のエラーだ が、まとめて検索/除外できない 解決策: 構造化エラーパッケージ 追加情報を持てるエラー構造を共通パッケージとして実装 追加情報は自動的にエラーログに出力されるようにミドルウェアも 実装 重要: ガイドラインを策定して終わりではなく、現実とのギャップを仕組 みとして解決 Before / After Error: GetItem failed Error: GetItem ID=123 failed Error: GetItem ID=456 failed Error: API call failed エラーログが散乱し、検索・集 計が困難 BEFORE Error: GetItem Fields: {itemID: "123"} Error: GetItem Fields: {itemID: "456"} 構造化され、検索・集計が 容易 AFTER 13 / 21
14. III. 組織と技術の実装　―　②共通パッケージの作成 Feature flagの透過的な伝搬 Feature Flagとは 機能のOn/OffをWeb UIから制御する仕組み Backendではリクエストごとにお客さまが違うため、都度APIで 問い合わせが必要 Modular Monolithにおける課題 1リクエストで、内部の複数モジュール（Tier 1〜4）が連携して動 く 課題: 各モジュールが個別にFeature Flag APIを叩くと、レイテン シが積み上がる 解決策：透過的な伝搬 Fetchは1回だけ（BFF層） モジュール間: gRPC Metadata（通信のヘッダー情報）で伝搬 モジュール内: context.Context に格納 結果: 各モジュールは通信を意識せず、Contextから値を取り出す だけ 効果: レイテンシ削減 + コードの可読性向上 Client BFF Order management Product Search Feature Flag API BEFORE: レイテンシ増大 Client BFF Feature Flag API 1回だけ Order management Product Search gRPC Metadata gRPC Metadata gRPC Metadata AFTER: レイテンシ最小化 14 / 21
15. III. 組織と技術の実装　―　②共通パッケージの作成 モノレポの相乗効果と一度の改善が全体に効く Protobuf + モノレポ 課題 Headerサイズ制限。JSONキー名（文字列）は重すぎる 解決策 Feature Flagの割当情報自体をProtocol Bufferで定義 効果 バイナリ化によるサイズ圧縮 optional型による型安全性 モノレポで定義を共有できるモジュラモノリスならではの強み JSON {"feature_a": true, "feature_b": false} Protobuf message Assignments { optional bool feature_a = 1; optional bool feature_b = 2; } Feature Flagから学ぶ教訓 1. レバレッジ効果 gRPC interceptorへの変更にすることで一度の改善（透過的伝搬）が 全モジュールに適用される 2. 開発者体験を最優先 通信を意識させない設計が、システム全体の効率性を高め、既存コー ドへの影響を最小化 15 / 21
16. III. 組織と技術の実装　―　③コードレビュー スケーラブルなレビュー体制 役割: 品質の「ガードレール」設置（ガイドライン、ツール） リーダビリティチームのレビューは必須ではない コードオーナーの承認があればマージ可能 リーダビリティチームがボトルネックにならないよう工夫 介入ポイント: 1. OpenなPR 複雑度が高いものを検知し、マージ前に助言（必須ではない） 2. マージ後のPR 定期的にチェックし、事後的に改善提案 16 / 21
17. IV. AI時代のスケールと持ち帰り 整った基盤とAI活用の必然性 基盤への投資 ガイドラインの作成と維持: 開発標準を文書化し継続的に整 備 Golangci-lintや独自のLinterを実装: 全モジュールが機械的に 同じルールに従うように ▼ メルカリのAI Native取り組み 全エンジニアがAIコーディングアシスタントを活用 Claude、GitHub Copilot等の積極的導入 結果として起きた変化 Pull Requestの数が増加 PRのボリューム（コード量）が増加 PRを作成するまでの時間が大幅に短縮 レビュー負荷が爆発的に増大 外的圧力とチャンス 人間だけでは品質維持が不可能に AIを活用しなければ処理できない状況 これはピンチであり、同時にチャンスでもある 整った基盤があったからこそ、この状況に対応できた 17 / 21
18. IV. AI時代のスケールと持ち帰り AI活用によるスケーラブルな品質管理 5つの具体的活用事例 1. PRの複雑度自動分類 Claudeが複雑度・サイズを自動分析しラベル付け。人間は「High Complexity」に集中 2. Linter代替のガイドライン参照 Linter作成が難しい/コストが見合わない場合の対応 具体例: 構造化エラーパッケージの遵守レビュー 古い実装パターンの検知 3. ローカル開発での自己修正ループ コード生成後、Makefileコマンド（lint, test, build等）を自動実行。AI が自らミスを発見し、修正を繰り返す 効果: 人間が介入する前に品質基準を満たしたコードが完成 4. ガイドライン作成にもAI活用 Slackでの議論をもとにAIがDraftを作成。人間は最終調整のみに集中 5. Unit Testの自動生成 Unit testガイドラインを細かくドキュメント化。AIがガイドラインに 従ってテストコードを生成 結果 新人がAIに書かせても、リーダビリティチーム準拠のコードが 出力 スケーラブルな品質管理に近づいてきていると感じています 18 / 21
19. IV. AI時代のスケールと持ち帰り AIがドキュメント品質を高め、ドキュメントがAIを高 める AIとドキュメントの好循環 1 AIがドキュメントを読む CLAUDE.md、README.md、ガイドラインを読み 込む。それに基づいてレビューやコード生成を行う 2 ドキュメントが古い時に気づきやすい AIが古いドキュメントに基づいて誤ったコードを生 成。レビュー時や開発時に「このガイドライン、も う古いのでは？」と気づける 3 ドキュメント更新もAIで効率化 直したいことをAIに伝えることで更新 重要: ツギハギの文章ではなく、全体として整合す るドキュメントが低コストで作れる 4 ドキュメントを最新に保つ AIによる効率的な更新により、ドキュメントのメン テナンスコストが下がる。結果として、ドキュメン トが常に最新の状態に保たれやすくなる AIが読む レビュー・生成 古い部分に気づく AIで更新 好循環 19 / 21
20. IV. AI時代のスケールと持ち帰り 早期に取り組むべきだった反省点 1. DBのガイドライン策定は最優先で APIはアトミックに変更できるが、 DBは一度デプロイするとマイグレー ションコストが高い ガイドライン策定前のDB設計は今 でも修正できていない 2. BFFのProtobufにおけるoptionalの 使い方を早期に決定 モバイルアプリは後方互換性が必須 で、BFFに破壊的変更ができない Go、iOS、Androidで影響が異な り、開発中盤で調整が困難に 3. モジュール内部設計のガイドライン も早期に ガイドラインがなく、一部モジュー ルが重厚なスタイルに AIの進化を待つ遅延戦略も選択肢。 戦略的に技術負債を管理 まだまだ課題は多いですが、失敗を共有することで少しずつ前に進めています 20 / 21
21. IV. AI時代のスケールと持ち帰り まとめ 品質とスピードは対立しない 1. アーキテクチャ Modular Monolithによる拡張性と開発 速度の両立 2. 組織 Readability Teamとマネジメントのコ ミットメント 3. ガイドライン/自動化/AI ガイドライン基盤 × 自動化 × AIによる スケーラブルな品質 メッセージ まだまだ改善の余地は多いですが、少しずつ形になってきました。 皆さんの状況とは異なる部分も多いと思いますが、 もし少しでも参考になれば幸いです。 ご清聴ありがとうございました 21 / 21