開発工程略語（IT/SA/FD/RD/PT/ST）とは？発注者向け早わかりガイド

進捗会議でベンダーから「今週でRDが完了し、来月からFDフェーズに入ります」という報告を受けたとき、「今どの段階にいるのだろう？」と感じたことはないでしょうか。

システム開発プロジェクトでは、IT・SA・FD・RD・PT・STといったアルファベット2〜3文字の略語が日常的に飛び交います。ベンダー側にとっては業界の共通言語ですが、発注者側の担当者にとっては、どの略語が何の工程を指すのかが分からず、進捗会議で質問するタイミングすら逃してしまうことがあります。

実は、これらの略語は一度体系的に覚えてしまえば決して難しいものではありません。そして、略語の意味を理解するだけでなく、「各工程で発注者が何を確認・判断すべきか」を知ることで、プロジェクトへの関与の質が大きく変わります。

本記事では、システム開発工程でよく使われる略語の意味を発注者向けにやさしく解説するとともに、各工程で発注者が確認すべきポイントをご紹介します。進捗会議で自信を持って参加するための実践ガイドとしてご活用ください。

執筆者

秋霜堂株式会社 代表 石川瑞起

中学生でプログラミングを独学で習得し、HP制作やアプリ開発の事業を開始。 大学入学後に事業を売却し、トヨクモ株式会社へ入社。 3年間にわたり1製品の開発責任者を務めたのち秋霜堂株式会社を設立し、多数の企業をサポートしている。

無料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード

開発工程略語とは？なぜ覚える必要があるのか

略語が飛び交う進捗会議あるある

システム開発の進捗会議では、こんな場面がよく起こります。

ベンダーの担当者が「現在RDが完了し、BDに移行したところです。来月中にFDを終えてPGに入る予定です」と資料を示しながら説明する。発注者側の担当者は「うんうん」とうなずきながら、内心では「RDって何だったっけ？BDとFDって順番はどちらが先？」と混乱している。

こうした状況は、発注者側の担当者が非エンジニアである場合に特によく起こります。略語が分からないまま進めてしまうと、現在の開発がどの段階にあるのか、次に何が起きるのか、自分が何を判断すべきなのかが見えなくなります。

略語を理解するメリット

略語を理解することで、以下のようなメリットが生まれます。

• 今どの段階か把握できる: 全体スケジュールの中での現在位置が分かり、進捗の良し悪しを判断できるようになります
• 適切なタイミングで確認・意思決定できる: 各工程には発注者が確認・承認すべきタイミングがあります。略語を理解することで、そのタイミングを逃さずに関与できます
• コミュニケーションの質が上がる: ベンダーと同じ言語で話せるようになり、疑問点や懸念をタイムリーに伝えられるようになります
• リスクへの早期対応が可能になる: 各工程の意味を知ることで、「この工程で何かあると後の工程に影響する」というリスクの所在を理解できます

システム開発工程の全体像と略語マップ

まずは、システム開発の全体像と主な略語の対応関係を把握しましょう。

工程の大分類

システム開発（特にウォーターフォール型）は、大きく以下の5つのフェーズに分けられます。

この大きな流れを頭に入れておくと、個々の略語がどの位置にあるかが分かりやすくなります。

略語早見表

以下が、システム開発でよく使われる主な略語の一覧です。

会社や業界によって略語の使い方が異なる場合もあります。ベンダーが使っている略語の定義は、プロジェクト開始時に確認しておくと安心です。

上流工程の略語（SA・RD）を理解する

上流工程は、「何を作るか」を決める最も重要なフェーズです。ここでの決定が、後工程の全てに影響します。

SA（要求分析）とは何か・発注者の確認ポイント

SA（System Analysis / Requirements Analysis：要求分析）は、発注者が「こんなシステムが欲しい」という要望を整理・分析するフェーズです。

ベンダーが発注者にヒアリングを行い、業務上の課題・解決したいこと・システムに期待することを洗い出します。この段階では、技術的な詳細よりも「ビジネス上の目的」に焦点が当たります。

発注者が確認すべきポイント:

• ヒアリング内容が現場の実態を正確に反映しているか
• 解決したい課題と優先順位が正しく整理されているか
• 現場の利用者（エンドユーザー）の声が反映されているか
• 見落としている要求や業務フローがないか

発注者にとっての役割: SAフェーズでは、発注者自身が積極的に情報を提供する必要があります。「システムに任せたい業務の詳細」「現在の業務フローの問題点」「利用者の人数や操作スキル」などを具体的に伝えることが、後工程のずれを防ぐ最大のポイントです。

RD（要件定義）とは何か・発注者の確認ポイント

RD（Requirement Definition：要件定義）は、SAで整理した要求を基に、「システムに実装すべき機能と非機能要件を具体的に定義する」フェーズです。要件定義書という形式の成果物が作成されます。

要件定義は発注者とベンダーが合意した「契約の土台」とも言えます。ここで曖昧な部分があると、後の工程で「言った・言わない」の問題が起きやすくなります。

発注者が確認すべきポイント:

• 要件定義書に記載された機能が、業務上必要なものを網羅しているか
• 「画面レイアウト」「処理の流れ」「データの入出力」が具体的に記述されているか
• 性能要件（処理速度・同時接続数）やセキュリティ要件が明記されているか
• 要件定義書を声に出して読み合わせし、発注者・ベンダー双方で内容を確認できているか
• 「要件定義書の内容でよいか」という正式な承認を行ったか

発注者にとっての役割: RDフェーズでの発注者の承認は、プロジェクト全体の方向性を確定させる重要な意思決定です。「なんとなく分かった」で承認するのではなく、疑問点は必ず解消してから承認しましょう。RD完了後に仕様を大幅に変更すると、コストと工期が大きく膨らむ可能性があります。

設計工程の略語（FD・BD・DD）を理解する

設計工程は、「どう作るか」を決めるフェーズです。要件定義で決まった「何を作るか」を、具体的な設計仕様に落とし込みます。

BD（基本設計）とは何か・発注者の確認ポイント

BD（Basic Design：基本設計）は、システムの全体像と主要な仕様を設計するフェーズです。画面のレイアウト、データベースの構造、外部システムとの連携方法などが決まります。

基本設計書は、発注者が確認できる最後の「見た目・使い心地」レベルの設計書です。この段階では、まだ技術的な詳細よりも「ユーザーが操作する画面」や「データの流れ」に焦点が当たるため、非エンジニアの発注者でも確認しやすい内容が含まれています。

発注者が確認すべきポイント:

• 画面イメージ（画面遷移図・ワイヤーフレーム）が要件定義の意図と合っているか
• ユーザーが使う主要な操作フローが自然に設計されているか
• 他のシステムや外部サービスとの連携に漏れがないか
• 要件定義書と齟齬がある点はないか

発注者にとっての役割: BDフェーズは、発注者が「イメージと違う」を指摘できる最良のタイミングです。この段階での修正はまだ比較的コストが低く抑えられます。実際に使う現場担当者にも確認してもらうと、後工程での手戻りリスクを大きく減らせます。

FD（機能設計）とは何か・発注者の確認ポイント

FD（Function Design：機能設計）は、システムの各機能について詳細な仕様を定義するフェーズです。「ボタンを押したらどんな処理が走るか」「どのデータをどう処理するか」といった機能レベルの設計です。

BDとFDは混同されることがありますが、BDが「全体構成」であるのに対し、FDは「各機能の詳細」と捉えると分かりやすいです。

発注者が確認すべきポイント:

• 各機能の仕様が業務フローと合致しているか
• 例外処理（エラー時の挙動・入力ミス時の動作）が適切に設計されているか
• 追加・変更があった要件が漏れなく反映されているか

発注者にとっての役割: FDフェーズは技術的な内容が増えてくるため、発注者が全てを詳細に確認することは難しい場合があります。重要な機能（業務の核となる処理・承認フロー・データ出力）に絞って確認する姿勢が現実的です。

DD（詳細設計）とは何か・発注者の確認ポイント

DD（Detail Design：詳細設計）は、エンジニアがプログラムを書くための最も細かい設計仕様を作るフェーズです。この段階の成果物は、主にエンジニア向けの技術文書となります。

発注者が詳細設計を直接レビューすることは少ないですが、DDフェーズに入ったことは「開発（プログラミング）まであと一歩」というサインです。

発注者が確認すべきポイント:

• BDやFDでの承認内容から大きな変更がないか
• スケジュール上、詳細設計が完了する見込みが立っているか
• 設計工程での疑問・変更要望がある場合、このフェーズが最後の調整機会であることを認識する

テスト工程の略語（IT・PT・ST・UAT）を理解する

テスト工程は、「正しく動くか確認する」フェーズです。実は、発注者が最も主体的に関与すべきテストがここに含まれています。

IT（結合テスト）とは何か・PT/STとの違い

IT（Integration Test：結合テスト）は、複数のプログラムやモジュールを組み合わせた状態で、正しく連携して動作するかを確認するテストです。個々のプログラムの動作を確認する「単体テスト（UT）」が完了した後に実施されます。

ITは主にベンダー側（開発チーム）が実施するテストです。発注者が直接参加することは少ないですが、ITが完了したという報告は「各部品の結合確認が終わった」というマイルストーンです。

発注者が確認すべきポイント:

• IT完了の報告を受けたら、テスト結果の概要（不具合件数・対応状況）を確認する
• 重大な不具合が発見されている場合、その対応状況と影響範囲を確認する
• 次のPT/STのスケジュールに変更がないか確認する

PT（総合テスト）・ST（システムテスト）とは何か

PT（Product Test：総合テスト）とST（System Test：システムテスト）は、システム全体が要件定義通りに動作するかを確認するテストです。会社や業界によってPTとSTを同義として使う場合と、別の工程として区別する場合があります。

このフェーズでは、個々の機能の正常動作だけでなく、負荷テスト（多数のユーザーが同時に使った場合の動作）やセキュリティテストも実施されることがあります。

発注者が確認すべきポイント:

• テスト計画書に「どんな条件でテストするか」が明記されているか確認する
• テスト範囲が要件定義で定めた全機能をカバーしているか確認する
• 発見された不具合の一覧と対応状況を定期的に共有してもらう
• PTまたはSTが完了した後に、自社でのUAT（受け入れテスト）に移行する

UAT（受け入れテスト）は発注者の仕事である

UAT（User Acceptance Test：受け入れテスト）は、他のテスト工程と根本的に異なります。UTからSTまでは主にベンダー側が実施しますが、UATは発注者側が主体となって実施するテストです。

UATの目的は、「開発されたシステムが、実際の業務で使えるか」を発注者の目線で確認することです。設計書通りに動くかどうか（これはSTで確認済み）ではなく、「業務要件を本当に満たしているか」「現場の担当者が問題なく操作できるか」を検証します。

発注者がUATで確認すべきポイント:

• 実際の業務シナリオを想定したテストケースを発注者側で準備する
• 現場の実際の利用者（エンドユーザー）に操作してもらい、使い勝手を確認する
• 業務上の例外パターン（特殊なケース・エラー時の対応）が正しく動くか確認する
• システムに移行するデータ（既存データ）の移行結果を確認する
• UATで発見した不具合や改善要望を記録し、ベンダーに報告する

よくある誤解: 「テストはベンダーがやること」と思っている発注者が多いですが、UATは発注者の義務と責任です。UATを省略・形骸化すると、本番稼働後に「使いにくい」「業務に合っていない」という問題が発覚し、修正対応に多大なコストがかかる可能性があります。

よくある混同パターンと対処法

STとUATの混同: STはベンダーが「設計書通りに動くか」を確認するテストで、UATは発注者が「業務要件を満たすか」を確認するテストです。STが完了してもUATが済んでいなければ、システムの納品は完了していません。

PTとSTの混同: 多くの企業でPTとSTは同義として使われますが、一部の企業ではPT（総合テスト）とST（システムテスト）を別フェーズとして扱うことがあります。ベンダーが使う場合はどちらの意味で使っているか、プロジェクト開始時に確認しておきましょう。

ITとUTの混同: UT（単体テスト）は個々のプログラム単体の動作確認、IT（結合テスト）は複数のプログラムを組み合わせた連携確認です。ITが完了してもそれはまだシステム全体のテスト（PT/ST）が残っています。

進捗会議ですぐ使える略語チェックシート

各工程の略語と、その工程で発注者が確認すべき質問例をまとめました。次回の進捗会議前にぜひご活用ください。

まとめ：略語を理解して発注者として能動的に関わろう

システム開発工程の主な略語をまとめると、以下のように整理できます。

• 上流工程: SA（要求分析）→ RD（要件定義）で「何を作るか」を決める
• 設計工程: BD（基本設計）→ FD（機能設計）→ DD（詳細設計）で「どう作るか」を決める
• 実装工程: PG/CD（プログラミング・コーディング）で「実際に作る」
• テスト工程: UT → IT → PT/ST → UAT の順で検証し、最後のUATは発注者が主体となって実施する

略語の意味を知ることは、単なる知識の習得ではありません。「今どの段階にいるか」を把握することで、発注者として適切なタイミングに確認・意思決定できるようになり、プロジェクトの品質・コスト・スケジュールを守ることにつながります。

特に重要なのは以下の3点です。

1. RD（要件定義）承認は最重要の意思決定: ここでの確認不足が後工程に連鎖的に影響します
2. BD（基本設計）レビューは発注者が参加できる最後の設計確認機会: 画面・操作フローを現場担当者と一緒に確認しましょう
3. UAT（受け入れテスト）は発注者の責務: ベンダー任せにせず、実際の業務シナリオでテストを実施してください

発注者として主体的にプロジェクトに関わることが、成功するシステム開発への近道です。

システム開発プロセスの全体的な流れについては、システム開発の流れとはも合わせてご参照ください。

無料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード