システム開発の見積もりや提案書には、「要件定義」「基本設計」「UT」「IT」「ST」といった専門用語や略語が並びます。これらの意味が分からないままだと、何にいくらかかっているのか、どこまでやってくれるのかを判断できません。 用語が分からないことは、実は「見積もりの妥当性が判断できない」という発注リスクに直結します。逆に、工程の用語を発注者目線で理解しておけば、見積もりのどこを確認すべきか、どの工程が抜けていると危ないかが見えてきます。
本記事は、システム開発を発注する経営者・情シス・発注担当の方に向けて、開発工程の略語・用語を「発注者が知っておくべき意味と確認ポイント」に絞って解説する用語集です。専門家になる必要はありません。見積もり・提案を読み解き、ベンダーと対等に話せるだけの理解を目的とします。開発全体の流れはシステム開発の流れ完全ガイド、見積もりの読み方はシステム開発の費用・見積もりガイドもあわせてご覧ください。
目次
- 結論：用語がわかると「見積もりの抜け」が見える
- 開発工程の全体像とV字モデル
- 上流工程の用語（要件定義・設計）
- 開発・テスト工程の用語（実装・UT/IT/ST/UAT）
- 体制・役割の用語（SE・PG・PM・PL）
- 契約・見積もりで出る用語
- アジャイル開発でよく出る用語
- 環境・インフラ系の頻出用語
- 発注者が特に確認すべき工程
- よくある質問（FAQ）
- 見積もり・提案の読み解きで迷ったら
<a id="conclusion"></a>
結論：用語がわかると「見積もりの抜け」が見える
開発工程の用語を知る目的は、知識のためではありません。見積もりや提案に「何が含まれ、何が抜けているか」を見抜くためです。たとえば、見積もりに「要件定義」の工程が薄い、「テスト」の内訳が曖昧、「受け入れ（UAT）」の記載がない——こうした抜けは、用語の意味を知らないと気づけません。そして、こうした工程の抜けは、後から追加費用やトラブルの形で必ず返ってきます。
発注者にとって重要なのは、各工程を自分で実行できることではなく、「その工程が見積もりに入っているか」「誰が責任を持つか」を確認できることです。用語を知っていれば、打ち合わせで「この工程は含まれますか」「テストの内訳を教えてください」と具体的に確認でき、ベンダーとの認識のズレも早い段階で埋められます。以下の用語集は、その確認ができるようになることを目標に、発注者が出会いやすい順に整理しています。
<a id="vmodel"></a>
INSTANT ESTIMATE
計算式より、60秒で概算を出しませんか？
システム種別・規模・連携先を選ぶだけで、開発費用・期間・月額運用費の概算をその場で表示します。
開発工程の全体像とV字モデル
まず、開発工程の全体像を押さえます。システム開発は、おおまかに次の順で進みます。
要件定義 → 基本設計 → 詳細設計 → 実装（プログラミング）→ 単体テスト → 結合テスト → 総合テスト → 受け入れテスト → リリース → 運用・保守
この工程は、「V字モデル」という形で整理されることがよくあります。V字モデルは、左側の設計工程と右側のテスト工程が対応している、という考え方です。
横にスクロールして確認できます
| 設計（左側・下るほど詳細） | 対応するテスト（右側・上るほど広い） |
|---|---|
| 要件定義 | 受け入れテスト（UAT） |
| 基本設計 | 総合テスト（ST） |
| 詳細設計 | 結合テスト（IT） |
| 実装 | 単体テスト（UT） |
このモデルの意味は、**「上流で決めたことを、対応するテストで確かめる」**ということです。要件定義で決めたことは受け入れテストで確認し、基本設計は総合テストで確認する、という対応関係になっています。この対応を知っておくと、「要件定義が甘いと、受け入れテストで揉める」といった因果が見えてきます。
本記事は用語の意味と確認ポイントに絞った辞典です。各工程で発注者側が実際に何をすべきか、ベンダーから渡された工程表のどこを見るかは、ソフトウェア開発の流れと工程表の読み方で工程順に解説しています。用語で引くときは本記事、工程順に追うときはそちらを使い分けてください。
<a id="upstream"></a>
上流工程の用語（要件定義・設計）
開発の前半、いわゆる「上流工程」の用語です。ここは費用と成否を最も左右する部分です。
横にスクロールして確認できます
| 用語 | 読み・意味 | 発注者の確認ポイント |
|---|---|---|
| 要件定義 | 何を作るかを決める工程 | 業務要件が正しく反映されているか。ここが最重要 |
| 要件定義書 | 要件をまとめた文書 | 自社の業務課題が言語化されているか |
| 基本設計（外部設計） | 画面・機能・データの大枠を設計 | 使う側から見た仕様が固まっているか |
| 詳細設計（内部設計） | プログラムの内部構造を設計 | 主に開発側の作業。納品物に含むか確認 |
| RFP | 提案依頼書。発注側が要件を示す文書 | ベンダーに正しく要件を伝えられているか |
| 要件 / 非機能要件 | 機能の要件と、性能・セキュリティ等の要件 | 非機能要件（速度・可用性等）が漏れていないか |
上流工程で最も重要なのは要件定義です。ここが曖昧なまま先に進むと、後の工程すべてがずれ、手戻りと追加費用の原因になります。発注者として、要件定義に十分な工程と費用が割かれているかを必ず確認してください。
<a id="test"></a>
開発・テスト工程の用語（実装・UT/IT/ST/UAT）
開発の後半、実装とテストの用語です。テストの略語は特に混乱しやすいので、整理します。
横にスクロールして確認できます
| 略語 | 正式名称 | 意味 |
|---|---|---|
| 実装 / コーディング | プログラミング | 設計に基づいてプログラムを書く工程 |
| UT | 単体テスト（Unit Test） | 個々の部品（機能）が正しく動くか |
| IT | 結合テスト（Integration Test） | 部品同士をつないで正しく動くか |
| ST | 総合テスト（System Test） | システム全体が要件通り動くか |
| UAT | 受け入れテスト（User Acceptance Test） | 発注側が業務で使えるか確認する |
特に**UAT（受け入れテスト）**は、発注者が主役になる工程です。ベンダーのテスト（UT/IT/ST）は「作った通りに動くか」を確かめますが、UATは「業務で本当に使えるか」を発注側が確かめる場です。ここを軽視して「動いているからOK」で検収すると、業務に乗せてから問題が発覚します。見積もりにUATの工程・期間が確保されているかを確認してください。なお「IT」はこの文脈では結合テストの略で、情報技術（Information Technology）のITとは別物です。
<a id="role"></a>
体制・役割の用語（SE・PG・PM・PL）
開発体制に関わる役割の用語です。見積もりの人月単価は、これらの役割ごとに変わることがあります。
横にスクロールして確認できます
| 略語 | 役割 | 説明 |
|---|---|---|
| PM | プロジェクトマネージャー | 全体の進行・予算・品質に責任を持つ |
| PL | プロジェクトリーダー | チームをまとめ、現場の開発を主導する |
| SE | システムエンジニア | 設計や要件定義など上流を担うことが多い |
| PG | プログラマー | 実装（コーディング）を担う |
見積もりでは、これらの役割ごとに「人月単価」が設定されていることがあります。PMやSEなど上流を担う役割は単価が高く、実装中心のPGは相対的に低い、という構成が一般的です。**誰が何人、どの期間関わるか（体制）**が見積もりの根拠になるため、体制の内訳が示されているかを確認すると、金額の妥当性を判断しやすくなります。人月単価の考え方はシステム開発の費用・見積もりガイドも参考にしてください。
<a id="contract"></a>
契約・見積もりで出る用語
見積書や契約書で出会う用語です。
横にスクロールして確認できます
| 用語 | 意味 | 確認ポイント |
|---|---|---|
| 人月 / 人日 | 1人が1か月／1日働く工数の単位 | 何人月かで規模と費用が決まる |
| 請負契約 | 完成責任を負って納品する契約 | 総額が固まりやすい |
| 準委任契約 | 労働（作業）を提供する契約 | 完成責任は前提でない |
| 瑕疵 / 契約不適合責任 | 納品後の不具合に対する責任 | 対応期間・範囲を確認する |
| 検収 | 納品物を確認して受け入れること | 動作だけでなく資料・要件も確認 |
| 保守 / 運用 | リリース後の維持・改善 | 費用と範囲が別途か確認 |
これらの用語は、契約でトラブルになりやすい部分と直結しています。特に請負と準委任の違い、検収の基準、保守の範囲は、意味を理解したうえで契約に臨むことが重要です。
法律上の位置づけも押さえておくと、提案の言葉づかいに流されずに済みます。請負は「仕事を完成することを約し、その仕事の結果に対して報酬を支払う」契約と定められており（民法第632条）、完成義務が条文上の前提です。一方の準委任は「法律行為でない事務の委託」で（民法第656条）、委任の規定が準用されるため、完成そのものは約束の対象になりません。納品後の不具合についても期限があり、注文者が不適合を知った時から1年以内に請負人へ通知しないと、追完請求・報酬減額・損害賠償などを主張できなくなります（民法第637条第1項）。「検収して終わり」ではなく、この1年の通知期限が動き出す、という時間感覚を持って検収に臨んでください。
契約形態の使い分けは発注全体の設計に関わるため、初めてのシステム開発外注ガイド、請負・準委任の実務的な使い分けは受託開発とは何かもあわせて確認してください。
<a id="agile"></a>
アジャイル開発でよく出る用語
アジャイル（反復型）で進める場合、ウォーターフォールとは違う用語が出てきます。提案書でこれらが出てきたら、反復型で進める前提だと理解してください。
横にスクロールして確認できます
| 用語 | 意味 | 発注者の関わり |
|---|---|---|
| スプリント / イテレーション | 開発を区切る短い期間（例：1〜2週間） | 各区切りの成果を確認する |
| バックログ | やることの一覧（優先順位つき） | 優先順位づけに関与する |
| プロダクトオーナー | 何を優先して作るかを決める役割 | 発注側が担うことが多い |
| スクラム | アジャイルの代表的な進め方の枠組み | 定例で進捗を確認する |
| リリース / デプロイ | 作ったものを公開・反映すること | 反映のタイミングを把握する |
| MVP | 価値検証のための最小限の製品 | 検証範囲を一緒に決める |
アジャイルで注意したいのは、「プロダクトオーナー（何を優先するか決める人）」は発注側が担うことが多いという点です。つまりアジャイルは「任せれば進む」のではなく、発注側が優先順位づけとゴール管理に関与することが前提です。ここを理解せずにアジャイルを選ぶと、「柔軟なはずが、いつまでも終わらない」状態になりかねません。
<a id="infra"></a>
環境・インフラ系の頻出用語
システムを動かす「環境」に関する用語も、提案や運用の場面で頻出します。
横にスクロールして確認できます
| 用語 | 意味 | 補足 |
|---|---|---|
| 本番環境 | 実際に業務で使う環境 | ここで障害が起きると業務に影響 |
| ステージング環境 | 本番に近い確認用の環境 | リリース前の最終確認に使う |
| 開発環境 / テスト環境 | 開発・検証用の環境 | 本番と分けてリスクを避ける |
| サーバ / クラウド | システムを動かす基盤 | 自社保有かクラウド利用かで費用構造が変わる |
| API | システム同士をつなぐ仕組み | 外部サービス連携で登場する |
| DB（データベース） | データを保存・管理する仕組み | データ設計は移行や活用の要 |
これらの用語は、費用や運用の話に直結します。たとえば「本番・ステージング・開発の3環境を用意する」という提案は、品質を担保するために妥当な一方、環境の数だけコストがかかる要素でもあります。何のためにその環境が必要かを確認できると、運用費の妥当性を判断しやすくなります。クラウドかサーバ保有かは、初期費用と月額費用のバランスに影響します。
<a id="check"></a>
発注者が特に確認すべき工程
用語を押さえたうえで、発注者が見積もり・提案で特に注意して確認すべき工程は次の通りです。
- 要件定義：十分な工程と費用が割かれているか。ここが薄い見積もりは、後で手戻りが発生しやすい。
- テスト（UT/IT/ST）：テストの内訳が示されているか。「テスト一式」で曖昧にされていないか。
- 受け入れテスト（UAT）：発注側が業務で確認する期間が確保されているか。
- ドキュメント・納品物：設計書やマニュアルが納品物に含まれるか。
- 保守・運用：リリース後の費用と範囲が示されているか。
これらの工程が見積もりから抜けていたり、曖昧だったりする場合は、後から追加費用やトラブルになるサインです。用語を理解して「この工程は入っていますか」と確認できるようになることが、発注者にとっての最大の防御になります。とくに複数社の見積もりを比べるときは、各社が同じ工程を前提にしているかを揃えないと、安く見える見積もりが実は工程を省いているだけ、ということが起こります。工程が正しく見積もられているか不安なときは、第三者に見てもらうのも有効です。
<a id="faq"></a>
よくある質問（FAQ）
Q. UT・IT・STの違いが分かりません。 A. UT（単体テスト）は個々の部品が正しく動くか、IT（結合テスト）は部品同士をつないで動くか、ST（総合テスト）はシステム全体が要件通り動くかを確かめます。小さい単位から全体へと段階的にテストしていく、と理解してください。
Q. 「IT」は情報技術のITと同じですか？ A. 違います。テスト工程の文脈での「IT」は結合テスト（Integration Test）の略で、情報技術（Information Technology）のITとは別の意味です。見積もりの工程表に出てくる「IT」は、多くの場合、結合テストを指します。
Q. 要件定義はなぜそんなに重要なのですか？ A. 要件定義は「何を作るか」を決める工程で、ここが曖昧だと後の設計・開発・テストがすべてずれ、手戻りと追加費用の原因になります。V字モデルでは受け入れテストと対応しており、要件定義が甘いと検収で揉めます。上流ほど、後への影響が大きくなります。
Q. 見積もりに「テスト一式」とだけ書かれていますが問題ですか？ A. テストの内訳（UT/IT/ST/UAT）が示されていないと、どこまで検証されるかが不明で、品質の担保が曖昧になります。テストの範囲と、発注側が確認するUATの期間が含まれているかを確認しましょう。
Q. 用語が分からないままベンダーに任せてはいけませんか？ A. すべてを理解する必要はありませんが、工程が見積もりに含まれているかを確認できる程度の理解はあった方が安全です。用語が分からないと、抜けや曖昧さに気づけず、後で追加費用やトラブルになりやすくなります。
Q. 「人月」とは何ですか？見積もりの単位としてよく見ます。 A. 「人月（にんげつ）」は、1人が1か月働く工数を1とする単位です。「5人月」なら、1人で5か月、または5人で1か月に相当する作業量を意味します。見積もりは「何人月 × 人月単価」で金額が決まることが多いため、規模感と単価の両方を確認すると妥当性を判断しやすくなります。
Q. アジャイルとウォーターフォールは、用語からどう見分けますか？ A. 提案書に「スプリント」「バックログ」「イテレーション」といった言葉が出てくればアジャイル型、「要件定義→基本設計→…」と工程が一直線に並んでいればウォーターフォール型だと見分けられます。どちらで進めるかで発注側の関わり方も変わるため、提案がどちらの前提かを確認してください。
<a id="cta"></a>
見積もり・提案の読み解きで迷ったら
システム開発の工程用語を知る目的は、専門家になることではなく、見積もり・提案に「何が含まれ、何が抜けているか」を見抜けるようになることです。要件定義・テスト・受け入れ（UAT）・納品物・保守——これらの工程が正しく見積もられているかを確認できれば、後の追加費用やトラブルの多くは防げます。
GXOは、特定の開発を売り込む前に、受け取った見積もり・提案の工程に抜けがないかの第三者チェックと、発注前の要件整理からご一緒します。
- 受け取った見積もり・提案に工程の抜けがないか見てほしい → 見積もりセカンドオピニオン
- 開発の流れ全体を把握したい → システム開発の流れ完全ガイド
- 工程表のどこを確認すべきか知りたい → ソフトウェア開発の流れと工程表の読み方
- 開発の種類（受託・SES・SaaS・スクラッチ）から整理したい → システム開発の種類と選び方
- 費用・人月単価の妥当性を確認したい → システム開発の費用・見積もりガイド
- まず自社のIT・DXの現在地を診断したい → DX成熟度診断
用語がわかれば、見積もりの抜けが見える。そして抜けが見えれば、後の追加費用を防げます。その読み解きを、契約の前にご一緒します。
