設計書や進捗表を開いた瞬間、「RD、BD、DD、PG、UT、IT、ST……どの工程の話だっけ？」と止まったことはありませんか。
略称は短くて便利ですが、意味を曖昧なまま使うと、担当範囲やテスト対象の認識がずれます。まず押さえたいのは、略称そのものより「その工程で何を決め、何を確認するか」です。
開発工程の略称をまず一覧で確認する
ウォーターフォール型の開発でよく見かける略称を、上流からテストまで並べると次のようになります。
| 略称 | 英語 | 一般的な日本語 | 主な目的 |
|---|---|---|---|
| RD | Requirement Definition | 要件定義 | 何を実現するか決める |
| BD | Basic Design | 基本設計 | 外部から見える仕様を決める |
| DD | Detailed Design | 詳細設計 | 内部の実装方法を具体化する |
| PG / CD | Programming / Coding | 実装・製造 | 設計をコードにする |
| UT | Unit Test | 単体テスト | 部品単体を確認する |
| IT | Integration Test | 結合テスト | 部品同士の連携を確認する |
| ST | System Test | システムテスト | システム全体を確認する |
| UAT | User Acceptance Test | ユーザー受入テスト | 業務要求を満たすか確認する |
| OT | Operation Test | 運用テスト | 本番運用の手順や成立性を確認する |
ただし、この対応は絶対ではありません。会社によって基本設計をED、詳細設計をIDと呼ぶこともあり、受入テストをAT・UAT・OTなど別の略称で呼ぶケースもあります。
そのため、現場では「略称を暗記する」より、プロジェクトの工程定義書やテスト計画書で意味を確認する習慣が重要です。
UTはUnit Test｜部品単体の振る舞いを確認する
UTは一般にUnit Test、単体テストを指します。クラス、関数、モジュールなど、比較的小さな単位が期待どおり動くかを確認する工程です。
JSTQBのFoundation Levelシラバスでは、近い概念を「コンポーネントテスト（ユニットテストとも呼ばれる）」として整理し、コンポーネントを単独でテストすることに焦点を当てています。
Java / Spring Bootなら、サービスクラスの条件分岐、バリデーション、計算処理などをJUnitで確認する場面がイメージしやすいでしょう。
UT: OrderService.calculateTotal()
- 通常価格
- 割引あり
- 商品0件
- 不正な入力ポイントは「画面からDBまで全部通す」ことではなく、対象を絞って原因を特定しやすくすることです。
ITはIntegration Test｜つないだときの動きを見る
ITはIntegration Test、結合テストとして使われることが多い略称です。UTで確認した部品を組み合わせ、インターフェースやデータの受け渡しが成立するかを確認します。
たとえばController → Service → Repository、アプリ → DB、システム → 外部APIのように、境界をまたいだときに問題がないかを見ます。
- APIのリクエストがServiceへ正しく渡るか
- トランザクションが期待した範囲で動くか
- DBへ保存した値を正しく読み戻せるか
- 外部APIの応答をアプリ側で正しく扱えるか
なお、ITをITa / ITb、IT1 / IT2のように分ける現場もあります。その分け方に業界共通の一つの正解があるわけではないため、「何と何を結合するテストか」まで確認しましょう。
STはSystem Test｜システム全体で要件を確認する
STはSystem Test、システムテストを指すことが一般的です。個々の部品ではなく、統合されたシステム全体の振る舞いを確認します。
JSTQBでは、システムテストはシステムやプロダクト全体の振る舞いや能力に焦点を当てるテストレベルとして説明されています。
ここでは機能だけでなく、案件によって性能、セキュリティ、使用性などの非機能要件も確認対象になります。
たとえばECサイトなら、「商品を選ぶ → カートへ入れる → 決済する → 注文履歴へ反映される」という一連の業務フローを、システムとして成立するか確認するイメージです。
UATはUser Acceptance Test｜利用者目線で受け入れる
UATはUser Acceptance Test、ユーザー受入テストです。完成したシステムが利用者の業務要求を満たし、導入可能な状態かを確認します。
JSTQBでも受け入れテストは、システムがユーザーのビジネスニーズを満たしていることを確認し、想定ユーザーが実施することが理想とされています。
STで「仕様どおり動く」ことを確認できても、UATで「実際の業務では使いにくい」「承認フローが足りない」と判明することがあります。技術的な正しさと、業務上の受け入れ可否は別の観点です。
UT→IT→ST→UATは「範囲が広がる」と考える
4つの違いを覚えるときは、対象範囲が徐々に広がると考えると整理しやすくなります。
UT : 部品単体
↓
IT : 部品同士の連携
↓
ST : システム全体
↓
UAT : 利用者の業務として受け入れ可能かただし、これは工程を理解するための代表的な並びです。反復型・アジャイル開発では複数のテストレベルが時間的に重なることがあります。JSTQBも、テストレベルはSDLCモデルによって重複する場合があると説明しています。
「UTが完全に終わるまでITは絶対に始めない」と機械的に覚えるのではなく、プロジェクトの開発モデルと完了条件を確認するほうが実務的です。
設計工程のRD・BD・DDもセットで覚える
UTなどのテスト略称だけ覚えても、進捗表全体は読めません。前工程でよく出るRD・BD・DDもつなげておきましょう。
RD｜要件定義
何を作るのか、どんな業務要求・機能要件・非機能要件を満たすのかを整理する工程です。
BD｜基本設計
画面、API、帳票、外部インターフェースなど、利用者や外部システムから見える仕様を具体化します。
DD｜詳細設計
クラス構成、処理フロー、物理DB、例外処理など、実装者がコードへ落とせる粒度まで内部仕様を具体化します。
前の記事で扱った「基本設計と詳細設計の違い」と同じく、工程名や成果物の境界はプロジェクトごとに異なります。略称ではなく、成果物と責任範囲で判断しましょう。
PT・OT・ATは特に現場差が出やすい
略称で最も注意したいのが、複数の意味で使われる言葉です。
- PT：Program Test、Performance Test、Product Testなど、現場により意味が異なる
- OT：Operation Testとして運用テストを指すことが多いが、受入工程に近い意味で使う現場もある
- AT：Acceptance Testとして受入テストを指す場合がある
- IT：工程表ではIntegration Testでも、一般文脈ではInformation Technologyを意味する
略称だけを見て推測すると危険です。特に他社の案件へ参画した直後は、最初に用語集・WBS・テスト計画書を見て、そのプロジェクト固有の定義を確認してください。
3年目エンジニアは「工程名＋担当範囲」で説明する
職務経歴書や案件面談では、「UT経験あり」「ITまで担当」と略称だけを書くより、実際に何をしたかまで説明したほうが経験の深さが伝わります。
たとえば次の2つでは、同じ「IT経験」でも情報量が違います。
△ 「Java案件でITを担当しました」
○ 「Spring BootのAPI改修で、ControllerからDBまでの結合テストを担当し、正常系・入力エラー・トランザクションロールバックを確認しました」
略称はラベルです。評価されるのは、どの対象を、どの観点で、どこまで自分で確認したかです。
略称で迷ったときの確認手順
- WBSや工程表で前後の工程を見る
- テスト計画書で対象範囲と完了条件を確認する
- プロジェクト固有の用語集・標準を確認する
- PTやOTなど曖昧な略称は担当者へ正式名称を確認する
- 自分の成果物には可能なら日本語名も併記する
「UTだからこう」と決め打ちするより、対象・目的・完了条件の3点を確認すれば、初めての現場でも認識を合わせやすくなります。
略称は工程の地図として使う
UT・IT・ST・UATは、それぞれ単体、連携、システム全体、利用者の受け入れというように、確認範囲が広がっていくと理解すると整理しやすくなります。
一方で、RD・BD・DD・PT・OTなどを含め、略称の使い方は現場によって変わります。正式名称まで暗記することより、「今は何を決める工程か」「何をもって完了か」を確認できることのほうが重要です。
次にWBSを開いたら、略称の横へ「対象」「目的」「成果物」を1行ずつ書いてみてください。工程名がただの記号ではなく、仕事の流れとして読めるようになります。
