事例：9万店舗のMEO SaaSで築いた「仕様が劣化しない」運用体制

#プロジェクトの背景：何が難しかったのか

このプロジェクトは、日本のMEO（マップエンジン最適化）プラットフォーム——Google Maps上の店舗掲載を分析・最適化する大規模SaaS——です。難しさは技術そのものより、仕様の性質にありました。

• 仕様書はSEO・Google Maps APIの日本語専門用語が密集（「順位計測」「インドアビュー」「サイテーション」など）
• データ規模が大きく、集計ロジックの誤解はリリース後にしか発覚しない
• スプリント単位の開発のため、1つの誤解がスプリント全体の遅延に直結する

つまり、「日本品質」が暗黙知のまま消失する問題が最も起きやすい条件が揃っていました。

#4層の運用体制 — 何をどう仕組み化したか

#第1層：日越共通の技術グロッサリー

最初に作ったのは、コードでもプロセスでもなく用語集です。日本語の専門用語1つずつに、技術的定義・ベトナム語訳・実際のデータ例を紐付け、日本側と開発チームが同じものを参照する。「順位」が検索順位なのか掲載順位なのか——この種の解釈ズレを、個人の語学力ではなく共有ドキュメントで排除しました。

#第2層：仕様の2段階チェック

仕様は2回チェックします。開発開始前——BrSEが技術的に検証し、曖昧な箇所・矛盾にフラグを立てて日本側へ確認。完成後——デモの前にもう一度仕様と突き合わせる。「作ってから誤解に気づく」コストは「作る前に質問する」コストの数十倍なので、質問を恥としない文化をルールで担保しました。

#第3層：全PRレビュー

すべてのプルリクエストをマージ前にレビューし、ロジックの誤りを早期に検出。レビューで繰り返し出る指摘は観点表に蓄積し、属人化したレビューから基準によるレビューへ移行していきました。

#第4層：24時間以内エスカレーション

問題・リスクは発見から24時間以内に必ず日本側へ共有するルールです。毎日のデイリーミーティングと日本語での日次報告がその受け皿になります。「解決してから報告する」というベトナム側の文化的デフォルトを、「早い報告を評価する」という明示ルールで上書きしました。

#結果 — 数字で見る4年間

注目してほしいのは、どの数字も「速く作った」ではなく**「誤解を構造的に排除した」**結果だという点です。オフショアの成否は開発速度ではなく、手戻りの少なさで決まります。

#この事例から再利用できる教訓

1. 語学力に投資する前に、用語集に投資する — 共有グロッサリーは最も安価で効果の高い誤解対策です。
2. チェックは「前」と「後」の2回 — 作る前の質問は安く、作った後の発見は高い。
3. エスカレーションは時間で区切る — 「重大なら報告」は機能しません。「24時間以内」のような機械的ルールだけが文化差を越えます。
4. 成果はredoの少なさで測る — ベロシティが高くても、作り直しが多ければデリバリーは失敗しています。

現在の日越プロジェクトで「手戻りが多い」「リリースが遅れ続ける」と感じている方は、体制のどの層が欠けているかを整理するだけでも改善の糸口が見えます。状況を共有したい方はこちらからどうぞ。専門領域と時間的余裕に合う案件であればご返信いたします。