このページについて： 日越のオフショア開発およびAI開発でよく使われる用語を素早く参照できる実務用語集です。各用語について、デリバリーマネージャーの視点から2〜3文でその本質を簡潔に定義し、詳細を掘り下げたい方向けに関連記事のリンクを添えています。
TL;DR (Executive Summary)
- 課題： 「デリバリー」と「プロジェクト」、「AEO」と「SEO」、「BrSE」と「通訳」など、業界用語が曖昧に混同され、自社が本当に何を求めているかが分かりにくくなっている。
- 解決策： 教科書的な解説ではなく、現場での実務に基づいた極めて実践的な切り口で、各概念を短く定義する。
- 成果： 30秒で用語の本質と違いを理解でき、必要に応じて詳細な「深掘り記事」を参照できる。
デリバリー ＆ オフショア
デリバリーマネージャー（Delivery Manager） — ソフトウェアソリューションが約束通りに納品されることに対し、最終責任を負う役割。単に「コードが動く」だけでなく、ビジネスの課題を正しく解決し、本番環境で安定運用されることにコミットします。スケジュールやリソースの管理を中心とするプロジェクトマネージャー（PM）と異なり、最終的な成果物とその価値に対するAccountability（説明責任・結果責任）を持ちます。 → アウトソーシングとの違い
BrSE（Bridge Software Engineer / ブリッジシステムエンジニア） — 日本とベトナムの架け橋となるエンジニア。本質的な役割は単なる「言葉の翻訳」ではなく、2つの言語と技術文化の間で、要求仕様の「真意（コンテキスト）」を正しく翻訳・調整し、開発チームに正しく作らせることです。 → BrSEの4段階
日本品質（オフショアにおける定義） — 「単にバグがないコード」ではなく、例外的なエラー処理（Unhappy Path）の徹底、問題発生時のログ追跡可能性（Traceability）、そしてコードの保守性（Maintainability）が担保されている状態。初期コストは上がりますが、障害リスク時の損害が大きいシステムでは必須の投資です。 → ベトナムオフショアにおける日本品質の本質
オフショアベンダーの評価基準 — 見積金額だけで外注先を選ばないための評価軸。設計アーキテクチャの構築能力、リスクへの対応力、そして要件定義から運用までエンドツーエンドで責任を負える体制があるかを見極めます。 → オフショアベンダー選定フレームワーク
Webサイト ＆ AI検索
AEO（Answer Engine Optimization / 回答エンジン最適化） — ChatGPT、Google AI Overview、Perplexityなどの回答エンジンに、自社サイトのコンテンツを直接読み取らせ、引用元として回答に含めてもらうための最適化。リンク一覧の表示を目指すのではなく、「AIによる回答そのものになる」ことを目指します。 → AEOとGEOの概要 ・ AI対応度の無料診断
GEO（Generative Engine Optimization / 生成エンジン最適化） — AEOの類義語であり、生成AIモデルが回答を合成する際に、自社コンテンツを情報ソースとして採用させるための取り組み。直接的な回答記述、Schemaマークアップ、エンティティの明確化、そしてE-E-A-Tが重要になります。 → AEO & GEO：AIに引用されるための最適化
Technical Debt（技術的負債） — リリース速度を優先するために、一時的に「前借り」した設計やコードの妥協点。のちに保守コストという「利息」を伴って返済する必要があります。重要なのは負債をゼロにすることではなく、「いつリファクタリングし、いつ最適化にとどめるか」の境界線を見極めることです。
企業向けAI ＆ Claude
RAG（Retrieval-Augmented Generation / 検索拡張生成） — 生成AI（LLM）が回答する前に社内ドキュメントを「検索」し、その事実データに基づいて回答させる仕組み。社内向けAIアプリでハルシネーションのリスクを制御する重要な層です。 → ハルシネーションを制御する社内RAG
MCP（Model Context Protocol） — ClaudeなどのAIアシスタントが、外部のアプリやデータソースと共通のインターフェースで接続するためのオープン規格。「AIにとってのUSB-C規格」に例えられます。 → Claude 101 コース学習メモ
Claude / Anthropic 認定資格 — Anthropicが提供する資格には、Anthropic Academyで無料受講・取得できる「Course Certificate」と、公式の監視付き試験である「Claude Certified Architect (CCA)」の2種類があります。 → Claude認定資格の種類と学習ロードマップ
デリバリーマネージャーとは：アウトソーシングと「日本基準」の違い
アウトソーシングは仕様どおりのコードを納め、デリバリーマネージャーは運用できるソリューション全体に責任を持ちます。違いは「責任がどこで止まるか」であり、書いたコードの量ではありません。
一般的なアウトソーシングでは、クライアントが仕様書を渡し、開発チームはその通りにコードを書きます。早く、通常は安価です。しかし「クライアントが間違っていれば、製品も間違っている」——仕様にビジネスロジックの欠陥があれば、そのまま実装されます。これがITアウトソーシングのプロジェクトが失敗しやすい理由です。デリバリーマネージャーは仕様書に盲目的に従わず、問い返します。「この機能は現在の業務のどの問題を解決するのですか？ ユーザーがここで間違えたら、サポートに電話させないためにシステムはどうエラーを伝えるべきですか？」
日本市場は運用上のリスクを許容しません。小さなエラーでも、スタッフが顧客に謝罪する事態になり得ます。そのため、デリバリーにおける「日本基準」は次の3要素に集約されます。
- アンハッピーパス（Unhappy Path） — 一般的なチームは、すべてが順調な場合だけをコーディングします。日本基準のデリバリーマネージャーは、アーキテクチャ分析の約半分を「順調でない場合」に充てます。支払い中のネットワーク切断、外部APIのタイムアウト時のフォールバック。システムが理由を示さずに止まることは許されません。
- トレーサビリティ（Traceability） — すべての技術判断とデータフローに痕跡を残します。6ヶ月後に機能が止まっても、ログからすぐ根本原因にたどり着けるよう、ロギングとモニタリングは初日から用意します。
- 保守性（Maintainability） — 新しく参加したプログラマーがコードを読み、すぐにロジックを理解できること。データベース設計とコード構造を明確に保ち、アップデートのたびに作り直す事態を避けます。
すべてのプロジェクトに日本基準が必要なわけではありません。分析期間は長くなり、アーキテクチャのコストも上がります。2週間で役目を終えるキャンペーン用LPなら、最も安く速い方法で十分です。一方、基幹システム、数十人が使う社内業務基盤、主な収益源であるECサイトでは、継ぎはぎのアーキテクチャで妥協した代償を払い続けることになります。この基準が実際にどう機能したかは、日本向けB2B SaaSを4年間デリバリーしたケーススタディをご覧ください。
BrSEとは：通訳型からデリバリーオーナー型までの4段階
BrSEとは、「言った通り」ではなく「意図した通り」に物が作られることに責任を持つ役割です。責任の対象は「翻訳の正確さ」ではなく「成果物と意図の一致」です。発言を正確に訳しても、意図とズレた物が出来上がれば、BrSEの仕事は失敗です。日本語が話せるエンジニアなら誰でもBrSEになれるわけではなく、翻訳しかしないBrSEこそが日越プロジェクトの隠れたボトルネックになっています。
私は14年間、日越市場のBrSE兼デリバリーマネージャーとして働いてきました。そこから言えるのは、BrSEという肩書きの中にまったく別の4つの仕事が混在しているということです。
| 段階 | 呼び名 | 何を訳すか | 責任の範囲 |
|---|---|---|---|
| Level 1 | 通訳型 | 発言 | 訳の正確さ |
| Level 2 | 仕様翻訳型 | 仕様の行間・業務的意図 | 仕様理解の一致 |
| Level 3 | プロセス設計型 | 暗黙知→仕組み | 品質の再現性 |
| Level 4 | デリバリーオーナー型 | ビジネス課題→技術判断 | プロジェクトの結果 |
- Level 1：通訳型 — 会議の発言とチャットを訳す段階。語学力は高くても技術的判断はしないため、日本品質が暗黙知のまま消失する問題はそのまま起きます。伝言ゲームの精度が上がるだけで、伝言ゲーム自体は残ります。
- Level 2：仕様翻訳型 — 仕様の行間にある業務的意図を読み取り、「適切に処理する」と書かれていれば「適切とは具体的に何か」を確認しに行ける段階。多くの現場で「優秀なBrSE」と呼ばれますが、まだ問題が起きてから対応する受け身の役割です。
- Level 3：プロセス設計型 — 個別の誤解を潰すのではなく、誤解が起きないプロセスを設計する段階。Definition of Done、レビュー観点表、エスカレーションルールを整え、自分が訳さなくても品質が揃う状態を作ります。BrSE本人がボトルネックでなくなります。
- Level 4：デリバリーオーナー型 — ビジネス課題から逆算して技術判断を下し、必要なら代替案とともにNoと言う段階。自らSingle Point of Accountabilityとなり、アウトソーシング失敗の最大要因である「責任の断絶」を塞ぎます。肩書きはBrSEでも、実質はデリバリーマネージャー（上の節）です。
見積書に「BrSE 1名」と書かれていても、Level 1なのかLevel 4なのかは読み取れません。価格差は2〜3倍でも、プロジェクトへの影響は桁違いです。判断の目安は次の通りです。
- 保守・運用フェーズ、仕様が安定 → Level 1〜2で十分
- 新規開発、仕様が流動的 → Level 3が必須
- 基幹システム、失敗が許されない、複数ベンダー関与 → Level 4を置かないと構造的にリスクが残る
「BrSEはいるのに話が通じていない」と感じるなら、原因はBrSEの能力不足ではなく、必要な段階とのミスマッチかもしれません。フルタイムかパートタイムかの判断は6つの変数のマトリクス、AI時代の役割の変化はBrSEからAI Bridge SEへをご覧ください。
これらの概念が実際のプロジェクトでどのように機能しているかについては、開発事例（プロジェクトストーリー）をご覧いただくか、システムのご相談・お問い合わせよりお気軽にご連絡ください。
Nguyen Phuc Nguyen Chau（グエン・フック・グエン・チャウ）
デリバリーマネージャー / システムアーキテクト
日本・ベトナム市場向けのシステム設計および開発デリバリーにおいて14年の実務経験
よくある質問
デリバリーマネージャーとプロジェクトマネージャー（PM）の違いは何ですか？
PMは主にスケジュール、リソース、スコープの管理を担当します。一方、デリバリーマネージャーは、納品されるソフトウェアソリューションの「最終結果に対する責任（Accountability）」を負います。計画通りに動かすだけでなく、ビジネス上の課題を正しく解決し、安定して運用されることまでコミットします。
BrSE（ブリッジシステムエンジニア）とは何ですか？
日本のクライアントとベトナムの開発チームを繋ぐ架け橋となる役割です。単なる通訳・翻訳ではなく、業務フローと技術の両方を深く理解し、言語と言語、あるいは開発文化のギャップを超えて「要求仕様の真意」を正しく伝えるエンジニアです。
AEOやGEOは、従来のSEOと何が違うのですか？
SEOは検索結果ページでリンクの上位表示を目指すものです。それに対し、AEO（Answer Engine Optimization）とGEO（Generative Engine Optimization）は、ChatGPT、Google AI Overview、PerplexityなどのAIエンジンにコンテンツを正しく解析され、直接引用・回答ソースとして選ばれるように最適化することを目指します。
デリバリーマネジメントは通常の外注と何が違いますか？
外注は仕様どおりにコードを納品しますが、デリバリーマネジメントは運用解決策と最終品質に責任を持ちます。違いはコード量ではなく、エンドツーエンドの責任にあります。
どの企業にも「日本基準」が必要ですか？
いいえ。日本基準が活きるのは、障害リスクが高い、運用が複雑、品質要件が厳しい場合です。小規模で単純な案件では、見合う価値を生まずコストだけ上げることがあります。
ブリッジSEと通訳・コミュニケーターの違いは何ですか？
語学力は必要条件であって十分条件ではありません。N1でもLevel 1に留まる人もいれば、N2でも業務理解と技術判断でLevel 3として機能する人もいます。見るべきは語学証明書ではなく、「仕様の矛盾に気づいて押し返した経験」と「プロセスを設計した経験」です。
良いブリッジSEはどう見極めればいいですか？
面接で「最近、顧客の要求に対してNoと言った事例」を聞くのが有効です。翻訳型のBrSEはNoと言った経験がほとんどありません。要件の矛盾やリスクに気づき、代替案を添えて押し返した経験を具体的に語れる人材は、結果に責任を持つ段階に達しています。
