はじめに なぜ「外資系IT企業の用語集」が必要なのか
外資系IT企業で仕事を始めると、最初に戸惑うのは専門技術そのものではありません。
多くの場合、会議やメールで当たり前のように飛び交う略語や用語です。
とにかく、アルファベットの略語が飛び交います。
いちいち調べていたのでは、とても追いつきません。
略語には、業界全体で通用する共通用語と、社内固有の用語が混在しています。
社内用語はそれぞれの会社で確認していく必要がありますが、社外でも通用する業界の略語をあらかじめ知っておくことは、業務効率や会話の理解度を大きく高めます。
本記事では、一般的に外資系IT業界で多く使用される略語に焦点を当てて紹介していきます。
厳密には、用語の定義や運用は会社ごとに微妙に異なる場合があります。
概要を掴んだあとの深掘りは、都度必要です。
多くの会社では略語の意味が社内サイトにまとめられていますが、入社時に丁寧に教えてもらえることはほとんどありません。
（そもそも、そのサイトの存在を知らない人も多いのが実情です。欲しいものは自分で見つけるが鉄則です。）
そこで本記事は、そのサイトをあなたが見つけるまでの間を凌ぐための予備知識として活用してもらうことを目的としています。
PRD、DR、RMA、ECO、KPI──
一つひとつは調べれば意味は分かります。
しかし実務では、それらは単なる「単語」ではなく、
判断の前提や責任の所在を一瞬で共有するための共通言語として使われています。
特に派遣や出向といった立場で外資系IT企業に関わる場合、次のような状況に直面しがちです。
- 分からないまま話が進んでしまう
- 聞き返すタイミングを逃す
- 「理解している前提」で役割を期待される
本記事は、略語を暗記するための用語集ではありません。
- どのような文脈で使われるのか
- その言葉が出たとき、何が前提になっているのか
- どの領域（開発・品質・営業・組織）の話なのか
を把握するための、全体像をまとめています。
個々の用語の深い解説については、別記事で順に掘り下げていきます。まずはこの用語集を通じて、「全体構造」を掴んでください。
※主にIT系でもネットワーク系に片寄っているかも知れませんがご了承ください。
この用語集の使い方
すべてを覚える必要はありません
最初に強調しておきたいのは、
この用語集に載っている言葉をすべて覚える必要はないということです。
実務で本当に重要なのは、次のレベル感です。
- 聞いたことがある
- どの領域の話かが分かる
- 今は深掘りが必要な言葉かどうか判断できる
外資系IT企業では、「知らないこと」よりも、
前提を共有せずに話が進んでしまうことのほうがリスクになります。
用語は「役割」と「フェーズ」を示している
多くの略語は、単なる横文字ではありません。
それぞれが、
- 誰が主語になっているのか
- どのフェーズの話なのか
- 何が次の判断材料になるのか
を示すラベルの役割を持っています。
たとえば、
- RMA は不具合そのものではなく「回収・返品の手続き」
- DOA は手続きではなく「製品状態の区分」
- ECO は修正ではなく「変更を統制するための正式な判断」
といった具合に、意味のレイヤーが異なる言葉同士が、同時に使われるのが実務の特徴です。
本記事における用語の分類方針
本用語集では、外資系IT企業の実務構造に合わせて、用語を次の3つの文脈で整理します。
- 開発・品質プロセスに関わる用語
- 要求・設計
- 検証・量産・品質
- 変更管理・不具合対応
- 保守サービス・ライフサイクル
- 組織・役割を理解するための用語
- 営業・ビジネスで使われる用語
- 物流・出荷に関わる用語
この分類は、単なる整理のためではありません。
外資系IT企業がどのような構造で意思決定しているかを反映しています。
深掘りが必要な用語について
本記事に登場する用語の中には、
- RMA
- DOA
- RCA / RCCA
- ECO
- MTBF / MRR
のように、1つで30分以上説明が必要になる概念も含まれています。
これらについては、背景や判断のポイント、実務上の注意点を個別記事として詳しく解説していく予定です。本記事は、その入口として位置づけています。
開発・品質プロセスで頻出する用語
外資系IT企業の実務では、開発・品質に関わる略語が最も頻繁に登場します。
これらの用語は、技術用語というよりも「今どのフェーズの話をしているか」を示す合図として使われます。
この章では、
- 要求・設計フェーズ
- 検証・量産・品質フェーズ
- 変更管理・不具合対応フェーズ
の3つに分けて整理します。
要求・設計フェーズの用語
このフェーズの用語は、「何を作るのか」「どこまで決まっているのか」を示します。
会議でこれらの言葉が出たら、設計の成熟度を確認するサインです。
| 用語 | 正式名称 | 意味（概要） |
|---|---|---|
| PRD | Product Requirements Document | 製品として満たすべき要求事項をまとめた文書 |
| MRD | Market Requirements Document | 市場・顧客視点での要求を整理した文書 |
| SRD | System Requirements Document | システム全体としての要求仕様 |
| FRS | Functional Requirements Specification | 機能要件を具体化した仕様書 |
| HLD | High Level Design | 全体構成・アーキテクチャを示す設計 |
| LLD | Low Level Design | 実装レベルまで落とし込んだ詳細設計 |
| DR | Design Review | 設計内容をレビューする正式プロセス |
| DR0〜DR5 | ― | 設計進行度を段階的に確認するレビュー区分 |
補足
- DRは「設計を確認する場」であり、「問題を洗い出す場」ではありません
- DR番号が進むほど、後戻りコストは急激に高くなります
検証・量産・品質フェーズの用語
このフェーズでは、
「設計どおりに作れているか」「品質が安定しているか」が問われます。
| 用語 | 正式名称 | 意味（概要） |
|---|---|---|
| EVT | Engineering Validation Test | 技術的に成立するかを確認する試験 |
| DVT | Design Validation Test | 設計仕様どおりかを検証する試験 |
| PVT | Production Validation Test | 量産工程で品質が確保できるかの検証 |
| QA | Quality Assurance | 品質保証（プロセス重視） |
| QC | Quality Control | 品質管理（結果重視） |
| QMS | Quality Management System | 品質マネジメントの仕組み全体 |
| RA | Repair Analysis | 修理レポート ※どのパーツを交換修理したかのレポート |
| FMEA | Failure Mode and Effects Analysis | 故障モードと影響の分析手法 ※部品レベルまで実施することが多い |
| FMA | Failure Mode Analysis | 故障モードの解析 ※部品レベルまで実施することが多い |
| PFMEA | Process FMEA | 製造工程に特化したFMEA |
| CPK | Process Capability Index | 工程能力を示す指標 |
| GR&R | Gage Repeatability & Reproducibility | 測定システムの信頼性評価 |
| SPC | Statistical Process Control | 統計的工程管理 |
補足
- QAとQCは混同されやすいですが、役割が異なります
- このフェーズの議論は「感覚」ではなく「データ」が前提になります
変更管理・不具合対応フェーズの用語
ここは現場で最も摩擦が起きやすい領域です。不具合・変更・責任・コストが同時に絡みます。
| 用語 | 正式名称 | 意味（概要） |
|---|---|---|
| ECR | Engineering Change Request | 技術変更の検討依頼 |
| ECO | Engineering Change Order | 承認された設計・工程変更の指示 |
| ECN | Engineering Change Notice | 変更内容の通知 |
| PCN | Product Change Notice | 顧客向け変更通知 |
| RMA | Return Material Authorization | 製品回収・返品の正式手続き |
| DOA | Dead On Arrival | 到着時点で不具合がある状態の区分 |
| NCR | Non-Conformance Report | 不適合報告書 |
| RCA | Root Cause Analysis | 根本原因分析 |
| RCCA | Root Cause & Corrective Action | 原因＋是正措置の確定 |
| 8D | Eight Disciplines | 問題解決のフレームワーク |
重要な注意点
- DOAは「状態」、RMAは「手続き」です
- RMA＝不良確定ではありません
- RCAとRCCAはフェーズが異なります（分析と結論）
※これらの用語は一連の流れとして理解する必要があります。
詳細は個別記事で解説します。
保守サービスに関わる用語
外資系IT企業では、不具合や障害対応の内容は、技術的に直せるかどうかよりも、保守サービス契約の条件によって左右されることが少なくありません。
この節で扱う用語は、RMA や DOA が発生したあとに、
- どのような形でサポートが提供されるのか
- どのレベルまで対応されるのか
- 製品ライフサイクル上、どこまでサポート対象なのか
を理解するためのものです。
| 用語 | 正式名称 | 意味（概要） |
|---|---|---|
| RTS | Remote Technical Support | リモートで提供される技術サポート |
| OTS | Onsite Technical Support | エンジニアが現地に赴いて行う技術サポート |
| OPR | Onsite Parts Replacement | 現地で部品交換のみを行う保守対応 |
| NBD | Next Business Day | 翌営業日の対応を意味するサービスレベル 翌営業日に配達（荷物が到着）することを表すことが多い |
| SD | Same Day | 当日に配達（荷物が到着）することを表すことが多い |
| RTF | Return To Factory | 製品を工場に返送して修理や解析を行う対応 |
| EOL | End of Life | 製品ライフサイクルの終了段階 |
| EOS | End of Support / End of Sales | サポート終了、または販売終了 |
| EOE | End of Engineering | 設計・開発フェーズの終了 |
| EOSL | End of Service Life | サービス提供の完全終了 |
これらの用語は、どのように修理するかではなく、どこまで対応されるか、いつまで対応されるかを示します。
たとえば、
- OTS が含まれていない契約では、現地対応は提供されない
- OPR は部品交換までで、原因解析は含まれないことがある
- NBD 契約では即日対応は前提にならない
- EOSL を過ぎた製品は、RMA 自体が受け付けられない場合がある
といったように、技術的な可否よりも、契約条件とライフサイクルの状態が先に判断されます。
保守サービスに関わる用語は、営業、サポート、現場でそれぞれ異なる前提で使われやすい領域です。
※当日配送（荷物送る）か当日配達（荷物到着）、荷物はどこから配送されるか？海外の工場か？日本の倉庫か？など深堀りして確認する必要があります。それによって、処理のリードタイムが変わりますので、要求レベルとよく照らし合わせて確認する必要があります。詳しくは別の記事で解説できればと思います。
そのため、対応可否の議論に入る前に、どのサービスレベルとライフサイクル段階の話をしているのかを切り分けて理解することが重要になります。
これらの用語の理解が中途半端な状態で契約書を承認すると「こんなはずではなかった」という後々トラブルの元になります。
開発・品質プロセスで頻出する用語のまとめ
- 開発・品質系の略語は「専門用語」ではなくフェーズ管理の言葉
- どの言葉が出ているかで、今どこまで話が進んでいるかが分かります
- 特に不具合・変更系の用語は、混同すると判断ミスや摩擦の原因になります
組織・役割を理解するための用語
外資系IT企業では、役職名やロール名がそのまま「責任範囲」や「意思決定権限」を示します。
日本企業のように肩書が曖昧なまま運用されることは少なく、誰が決める立場なのかを明確にするための言葉として使われます。
この章では、次の3つに分けて整理します。
- 経営・マネジメント層の役割
- 開発・運用・品質系のロール
- プロダクト・プロジェクト関連のロール
経営・マネジメント層の役割
これらの役職は、現場から見ると一段上に見えますが、
実務では「どこまで決められる人なのか」を見極めるために重要です。
| 用語 | 正式名称 | 意味（概要） |
|---|---|---|
| CEO | Chief Executive Officer | 企業全体の最終意思決定責任者 |
| COO | Chief Operating Officer | 日々の事業運営の統括責任者 |
| CTO | Chief Technology Officer | 技術戦略・技術判断の最高責任者 |
| CIO | Chief Information Officer | 情報システム・IT戦略の責任者 |
| CISO | Chief Information Security Officer | 情報セキュリティ全体の責任者 |
| CDO | Chief Digital Officer | デジタル戦略・変革の推進責任者 |
| VP | Vice President | 特定領域を統括する上級管理職 |
| GM | General Manager | 事業・部門単位の運営責任者 |
これらの役職名は、単なる肩書ではなく「どのレイヤーで意思決定が完結するか」を示します。
会議で誰が参加しているかを見ることで、議題の重さを推測できます。
開発・運用・品質系のロール
このカテゴリのロールは、実際に手を動かす立場と、判断を下す立場が混在しています。
役割の違いを理解していないと、相談先や確認先を誤りがちです。
| 用語 | 正式名称 | 意味（概要） |
|---|---|---|
| Engineering Manager | ― | 開発チームのマネジメント責任者 |
| Tech Lead | ― | 技術面での意思決定を主導する役割 |
| Software Engineer | ― | ソフトウェア開発全般を担う |
| Backend Engineer | ― | サーバー側の実装を担当 |
| Frontend Engineer | ― | UIやクライアント側の実装を担当 |
| Full Stack Engineer | ― | フロントからバックエンドまで担当 |
| DevOps Engineer | ― | 開発と運用を横断し自動化を推進 |
| SRE | Site Reliability Engineer | サービス信頼性を担保する役割 |
| QA Engineer | ― | 品質保証・検証を専門とする |
| Security Engineer | ― | セキュリティ対策の実装・運用 |
| Sustaining Engineer | ― | 既存製品の保守・改善を担当 |
実務では、肩書よりも「この人は判断できるのか、実装担当なのか」を見極めることが重要です。
特にTech LeadとEngineering Managerは混同されやすい点に注意が必要です。
プロダクト・プロジェクト関連のロール
外資系IT企業では、プロダクト視点とプロジェクト視点が明確に分かれています。
日本企業で一人が兼務している役割が、分業されていることも珍しくありません。
| 用語 | 正式名称 | 意味（概要） |
|---|---|---|
| Product Manager | ― | 製品の価値・方向性に責任を持つ |
| Program Manager | ― | 複数プロジェクトを横断管理する |
| Project Manager | ― | 個別プロジェクトの進行管理を担う |
| Scrum Master | ― | スクラムプロセスの運営支援 |
| UX Designer | User Experience Designer | 体験設計を担当 |
| UI Designer | User Interface Designer | 画面や操作性の設計を担当 |
Product Managerは「何を作るか」、Project Managerは「どう進めるか」に責任を持ちます。
この違いを理解していないと、議論が噛み合わなくなります。
製品の仕様についての確認・開示の許可などは「Product Manager」の範疇になりますが、各社の都合でRoleが微妙にことなる場合があります。
組織・役割を理解するための用語のまとめ
組織・役割に関する用語は、誰が判断し、誰が実行し、誰が責任を持つのかを示すための言葉です。
役職名やロール名を正しく理解することで、
- 相談先を誤らない
- 判断を求める相手を間違えない
- 会議の目的を見誤らない
といった実務上のリスクを減らすことができます。
営業・ビジネスで使われる用語
外資系IT企業では、営業・ビジネス系の用語が開発や品質の議論と密接に結びついています。
これらの用語は単なる売上管理の言葉ではなく、
どの案件にどれだけの優先度が置かれているか、
どこまでコミットが求められているかを示す指標として使われます。
この章では、次の3つの観点で整理します。
- 目標・評価・数字に関わる用語
- 営業プロセスを示す用語
- 顧客・アカウント管理に関わる用語
目標・評価・数字に関わる用語
これらの用語は、営業だけでなく、開発・品質・サポート側の優先順位にも直接影響します。
| 用語 | 正式名称 | 意味（概要） |
|---|---|---|
| KPI | Key Performance Indicator | 業務や成果を評価するための主要指標 |
| Quota | ― | 営業個人やチームに割り当てられた売上目標 |
| Target | ― | 達成を目指す目標値 |
| Achievement Rate | ― | 目標に対する達成率 |
| Revenue | ― | 売上高 |
| Margin | ― | 利益率 |
| Gross Margin | ― | 売上総利益率 |
| Upside | ― | 追加で獲得できる可能性のある売上 |
| Run Rate | ― | 現在のペースで見積もった年間売上 |
これらの数字は、個人評価や部門評価に直結します。
そのため、会議でこれらの言葉が出る場合は、単なる参考値ではなく「判断材料」として扱われていると考える必要があります。
営業プロセスを示す用語
営業プロセス系の用語は、案件がどの段階にあり、どれだけ確度が高いかを示します。
| 用語 | 正式名称 | 意味（概要） |
|---|---|---|
| Lead | ― | 見込み顧客情報 |
| Inside Sales | ― | 非対面営業 |
| Sales Ops | Sales Operation | 営業活動を支援する機能や部門 |
| Opportunity | ― | 商談として成立した案件 |
| Pipeline | ― | 進行中案件の一覧・集合 |
| Sales Funnel | ― | 商談進捗を段階で示したモデル |
| Forecast | ― | 売上見込み予測 |
| Close /Closing | ― | 契約締結 |
| Close Rate | ― | 商談が成約に至る割合 |
| Conversion Rate | ― | 次フェーズへ進む割合 |
| Backlog | ― | 受注済みだが未消化の案件 |
開発や品質側に急な依頼が来る場合、これらの用語が背景にあることがほとんどです。
特にForecastやCloseという言葉が出ている場合は、スケジュールや品質に対する圧力が高まっている可能性があります。
顧客・アカウント管理に関わる用語
このカテゴリの用語は、顧客との関係性や長期的なビジネス視点を示します。
| 用語 | 正式名称 | 意味（概要） |
|---|---|---|
| Account | ― | 担当顧客または顧客企業 |
| Account Manager | ― | 特定顧客を担当する営業責任者 |
| Territory | ― | 担当する地域・市場区分 |
| Upsell | ― | 既存顧客への上位製品販売 |
| Cross-sell | ― | 関連製品の追加販売 |
| Churn Rate | ― | 顧客解約率 |
| Customer Retention | ― | 顧客維持率 |
| Renewal | ― | 契約更新 |
| SLA | Service Level Agreement | サービス品質に関する合意事項 |
ここで使われる用語は、不具合対応やRMA判断にも影響を与えることがあります。
特定アカウントの扱いが慎重になる理由は、これらの指標と結びついているケースが多いからです。
営業・ビジネスで使われる用語のまとめ
営業・ビジネス系の用語は、単なる売上管理の言葉ではなく、組織として何を優先するかを示すサインです。
これらの用語を理解しておくことで、
- なぜ急な対応が求められているのか
- なぜ特定の案件が優先されるのか
- なぜ品質やリスクの議論が後回しにされるのか
といった背景を読み取ることができます。
物流・出荷に関わる用語（インコタームズ）
外資系IT企業の実務では、製品は設計・製造されるだけでなく、国境を越えて移動する前提で扱われます。
その際に使われるのが、インコタームズ（Incoterms）を中心とした物流関連の用語です。
これらは単なる配送条件ではなく、
- どこまでが売り手の責任か
- どこからが買い手の責任か
- 輸送費・関税・リスクを誰が負担するのか
を明確にするための取り決めです。
不具合対応やDOA,RMAの議論においても、「どの条件で出荷されたか」は判断に大きく影響します。
インコタームズとは何か
インコタームズ（Incoterms）は、国際商取引における売主と買主の責任範囲を定義した国際ルールです。
外資系IT企業では、契約書、見積書、出荷指示、RMA条件などにこれらの略語が当然の前提として登場します。
よく使われるインコタームズ
以下は、外資系IT企業の実務で特によく登場する条件です。
| 用語 | 正式名称 | 意味（概要） |
|---|---|---|
| EXW | Ex Works | 売主は自社拠点で引き渡すまでが責任範囲 |
| FCA | Free Carrier | 指定場所で運送業者に引き渡すまでが売主責任 |
| FOB | Free On Board | 本船に積み込むまでが売主責任 |
| CIF | Cost, Insurance and Freight | 運賃・保険込みで港まで売主負担 |
| DAP | Delivered At Place | 指定場所まで売主が輸送を手配 |
| DDP | Delivered Duty Paid | 関税・輸送費すべて売主負担で納品 |
実務で重要になるポイント
インコタームズは、
「送料を誰が払うか」という話だけではありません。
実務上、特に重要になるのは次の点です。
- 輸送中の破損や紛失は誰の責任か
- 関税・通関トラブルが発生した場合の対応主体
- DOAが発生した際の返送コスト負担
たとえば、
- EXWでは、輸送中トラブルは原則として買い手責任
- DDPでは、到着まで売り手責任が続く
というように、不具合や返品対応の前提条件が大きく変わります。当然それは製品価格に関係してきます。安く製品を入手したい場合は、自社の物流網で対応すれば最小限のコストになります。しかしながら、着荷時の不具合、輸送中の不具合に関して責任範囲が広くなります。ここはリスク許容度、デリバリーリードタイム、コストを鑑みて適した選択をする必要があります。
なぜインコタームズを知っておく必要があるのか
物流条件を把握していないままRMAやDOAの議論に入ると、
- 「誰が返送料を負担するのか」
- 「どこまで無償対応なのか」
- 「契約上、対応可能なのか」
といった点で認識のズレが生じます。
営業・サポート・品質・物流が同じ言葉を使っていても、前提となるインコタームズを共有していないと、会話が噛み合わなくなる原因になります。
インコタームズのまとめ
物流に関する用語は、製品が「物として動く」段階での責任とリスクを定義する言葉です。
インコタームズを理解しておくことで、
- 不具合対応の前提条件を正しく把握できる
- RMAや返送条件の議論がスムーズになる
- 契約と実務のズレに気づける
といった効果があります。
この章では詳細な契約解釈までは踏み込みませんが、「どの条件で出荷されているのか」を意識するだけでも、実務上の判断ミスを大きく減らすことができます。
すべてを覚えなくてよい理由
ここまで、開発・品質、組織・役割、営業・ビジネス・物流という観点で、外資系IT企業で頻繁に使われる用語を整理してきました。
この章では、なぜそれらを「すべて覚える必要がないのか」、そして実務ではどのように使えばよいのかを整理します。
用語は知識ではなく状況判断の手がかり
外資系IT企業で使われる略語は、知識を誇示するためのものではありません。
多くの場合、それらは次のような情報を短時間で共有するための手段です。
- 今はどのフェーズの話をしているのか
- 誰の判断が前提になっているのか
- 次に何を決める必要があるのか
そのため、用語の正式な定義を暗記していなくても、「この言葉が出てきたということは、何を前提にしているのか」を察することができれば、実務上は十分です。
分からないことより危険なのは、分かったつもりになること
実務で問題になるのは、用語を知らないことそのものではありません。
- 分かったつもりで話を進めてしまう
- レイヤーの違う用語を同じ意味で扱ってしまう
- 判断フェーズを飛ばして結論に進んでしまう
こうした状態が続くと、後から手戻りや責任の押し付け合いが発生します。
たとえば、状態を示す言葉と手続きを示す言葉、分析フェーズと結論フェーズの言葉を混同すると、
議論の前提が崩れたまま進んでしまいます。
用語は立場によって見え方が変わる
同じ言葉でも、立場が違えば意味の重みが変わります。
- 営業にとっては、顧客対応や契約に直結する言葉
- 開発にとっては、設計や実装の制約を示す言葉
- 品質やPMにとっては、判断の根拠や責任範囲を示す言葉
この違いを理解せずに会話をすると、相手は同じ言葉を使っているのに、見ているポイントが噛み合わなくなります。
用語を知ることは、相手の立場や関心事を読み取る手がかりを持つことでもあります。
この用語集の正しい使い方
本記事は、
困ったときに最初に戻ってくるための場所として使うことを想定しています。
- 会議で聞き慣れない言葉が出てきたとき
- 話が急に具体化した、あるいは抽象化したと感じたとき
- 誰が決める話なのか分からなくなったとき
そうした場面で、「これはどのカテゴリの話か」「今どのフェーズか」を確認するために参照してください。そして、社内で一度各用語の意味を調べて、確認するようにしてください。
深い理解が必要になった用語については、個別の解説記事で補完していく想定です。
参考情報
関連書籍
※本記事にはPRが含まれます。
コメント