システム開発の用語集｜発注者が知っておくべき用語と確認ポイント

システム開発の打ち合わせで「ウォーターフォールにしますか、アジャイルにしますか」「要件定義後に基本設計へ移ります」と言われて、何となく頷いてしまった経験はないでしょうか。

非エンジニアとしてシステム開発プロジェクトの担当になると、エンジニアやベンダーとの打ち合わせで次々と専門用語が登場します。その場では「分かったふり」をしても、後から認識齟齬が発覚し、仕様変更や追加費用につながるケースは珍しくありません。

この状況で困るのは「用語の意味を知ること」だけではありません。「その用語が出たとき、発注者として何を確認・決定すればよいか」という実務的な判断軸が分からないことです。

本記事では、システム開発のプロジェクトで発注者側が直面する専門用語を厳選し、「用語の意味」と「発注者の確認ポイント」をセットで解説します。打ち合わせ前の予習や、会議中のリファレンスとしてご活用ください。

この記事の使い方（対象読者・活用シーン）

この記事で学べること

本記事では、各用語について以下の2つの情報を提供します。

• 用語の意味: 非エンジニアにも分かるように平易に解説
• 発注者の確認ポイント: その用語が出たとき、発注者として何を確認・合意しておくべきかの実務的アドバイス

「用語の意味だけ知りたい」場合は定義部分だけ読めばOKです。「打ち合わせで使いたい」場合は確認ポイントまで読むことで、次のアクションが明確になります。

こんな場面で役立ちます

打ち合わせ前: 「今日は要件定義について話す」と分かっている場合、該当セクションを事前に確認しておく

契約前: 「請負にするか準委任にするか」という話が出たとき、H2-3（契約・費用の用語）を確認しながら意思決定する

トラブル時: 「インシデントが発生した」「SLAを確認したい」という局面で、H2-5（品質・保守の用語）を参照する

また、本記事は各用語の詳細解説記事へのハブ記事です。「要件定義について詳しく知りたい」「請負と準委任を深掘りしたい」という場合は、各セクション内の関連記事リンクからご確認ください。

プロジェクト管理の用語（要件定義・設計・開発・テスト）

開発プロジェクトの初期段階から完了まで、工程順に並べた用語です。「今自分はどの工程にいるか」を意識しながら読むと、各用語の意味がより具体的に理解できます。

要件定義（Requirement Definition）

意味: システムに「何をさせるか」を文書化する工程です。「ユーザーがこのボタンを押したらどうなるか」「どんなデータを管理するか」など、システムの機能・仕様を開発会社と発注者が共同で確定させます。要件定義が曖昧だと、後工程での手戻りや追加費用につながる最大のリスク要因です。

詳しい進め方はシステム開発の要件定義を成功させる完全ガイドをご覧ください。

発注者の確認ポイント:

• 「要件定義書の最終承認者は誰か」を確認する（担当者が一人で承認するのか、役員承認が必要かで後の変更プロセスが変わる）
• 「要件変更の手続き（変更管理フロー）」を事前に合意しておく。変更が発生した場合のコスト・スケジュールへの影響確認フローを定める
• 要件定義書は「受取義務があるか」を契約前に確認する（納品物として明記されているか）

基本設計・詳細設計（Basic Design / Detailed Design）

意味: 要件定義で「何をするか」が決まった後、「どのように作るか」を設計する工程です。

• 基本設計（外部設計）: システムの画面構成・データの流れ・外部システムとの連携方法など、ユーザーから見えるシステムの姿を設計します
• 詳細設計（内部設計）: エンジニアが実際にコードを書くための設計。処理の詳細・データベース構造など、技術者向けの仕様書です

発注者が承認を求められるのは主に基本設計のフェーズです。

発注者の確認ポイント:

• 基本設計のレビュー頻度とタイミングを事前に確認する（「週次でレビューする」「節目で発注者確認が必要」など）
• 設計書のフォーマットと納品形式を確認しておく（プロジェクト終了後に自社で保管・引き継ぎが必要な場合、分かりやすい形式での納品が重要）
• 「設計フェーズ完了＝次フェーズ着手」という判断を誰がするか（承認プロセス）を合意する

ウォーターフォール・アジャイル・スプリント

意味（ウォーターフォール）: 要件定義→設計→開発→テスト→リリースという工程を順番に進める開発手法です。各工程が完了してから次の工程へ進むため、計画通りに進めやすく、スコープ・コストが見積もりやすい反面、途中での変更に弱い特性があります。

意味（アジャイル）: 機能を小さな単位（スプリント）に分割して、「設計→開発→テスト→フィードバック」のサイクルを短期間で繰り返す開発手法です。仕様変更に柔軟に対応できる反面、発注者も定期的にプロジェクトへ関与する必要があります。

詳しくはアジャイル開発とは？手法と導入のポイント、ウォーターフォール開発とアジャイル開発の違いを参照ください。

意味（スプリント）: アジャイル開発において、1〜4週間の短い開発サイクルのことです。1スプリントの終わりにデモ・フィードバックを行い、次のスプリントに反映します。

発注者の確認ポイント:

• どちらの手法を採用するかは「仕様変更の可能性」と「発注者の関与度」で選ぶ。仕様が固まっている場合はウォーターフォール、仕様が流動的な場合はアジャイルが向く
• アジャイルを選ぶ場合、発注者が「スプリントレビューへの参加」「優先順位の継続的な決定」に時間を割けるかを確認する
• ウォーターフォールを選ぶ場合でも「仕様変更の申請プロセス（変更管理）」を事前に合意しておく

テスト・デバッグ・QA（Quality Assurance）

意味: 開発したシステムに不具合がないかを確認する工程・活動です。

• テスト: 実際にシステムを動かして「意図通りに動くか」を確認する作業
• デバッグ: テストで見つかった不具合（バグ）の原因を特定・修正する作業
• QA（品質保証）: テストを含む、システムの品質を担保するための活動全般

システム開発では複数のテスト工程があります（単体テスト・結合テスト・受け入れテストについては「品質・保守の用語」セクションで解説します）。

発注者の確認ポイント:

• 「検収（受け入れ）基準」を事前に明文化する。「どういう状態になったら合格とするか」を曖昧にしたまま進むと、検収完了後にトラブルになりやすい
• 発注者がテストに参加するフェーズ（受け入れテスト・UAT）の日程を事前に確保しておく
• バグ修正の費用負担（開発会社負担か追加費用か）を契約で確認しておく

リリース・デプロイ・ロールアウト

意味: 開発・テストが完了したシステムを、実際のユーザーが使える状態にする作業です。

• リリース: システムを一般公開・運用開始すること
• デプロイ（Deploy）: 開発環境から本番環境へシステムを適用・展開する技術的作業
• ロールアウト（Roll-out）: 段階的にユーザーへ提供を広げること（「最初に一部ユーザーへリリースし、問題がなければ全員へ展開する」等）

発注者の確認ポイント:

• リリース日・リリース時間帯を業務に影響が少ない時間帯（深夜・週末等）にするか確認する
• リリース後の「切り戻し（ロールバック）」手順と判断基準を確認する（重大な問題が発生した場合、旧バージョンに戻せるか）
• リリース後の初期対応（障害発生時の連絡先・対応時間）を開発会社と合意する

契約・費用の用語（人月・工数・請負・準委任）

契約書や見積書に登場する用語です。「意味が分からないまま署名する」リスクを避けるために、特にしっかり確認しておくべき領域です。

人月・人日・工数（Man-Month / Man-Day / Effort）

意味: システム開発の作業量・規模を表す単位です。

• 人月（にんげつ）: 1人のエンジニアが1ヶ月フルタイムで働いた場合の作業量を「1人月」と表現します。「3人月の開発規模」=「1人が3ヶ月かかる作業量」または「3人が1ヶ月で完了できる作業量」を意味します
• 人日（にんにち）: 1人が1日で完了できる作業量の単位。より細かい作業の見積もりに使われます
• 工数（こうすう）: 作業完了に必要な人日・人月の総量。「この開発は工数10人月です」のように使います

発注者の確認ポイント:

• 見積もりに「工数が増えた場合の追加費用のルール」が記載されているか確認する（請負契約では通常固定費だが、準委任では工数変動が費用に直結する）
• 「1人月の単価」（エンジニアのスキルレベルによって大きく変わる）を確認し、見積もりの根拠を理解しておく
• 見積もりは「コンティンジェンシー（予備費）」が含まれているかを確認する

請負契約・準委任契約

意味: システム開発の発注に使われる2つの主要な契約形態です。どちらを選ぶかでリスク分担が大きく変わります。

• 請負契約: 「○○のシステムを完成させること」に対して報酬を支払う契約。完成物に対する責任（瑕疵担保責任）は開発会社が負います。仕様変更への対応は追加費用になることが多いです
• 準委任契約: 「○○の作業を遂行すること」に対して報酬を支払う契約。完成責任ではなく、作業プロセスへの責任を負います。工数に応じた費用が発生するため、仕様変更に柔軟に対応できる反面、費用が流動的になりやすいです

発注者の確認ポイント:

• 「システムが完成しなかった場合、誰がどのリスクを負うか」を理解した上で契約形態を選ぶ
• 請負契約の場合は「仕様変更の申請プロセス（CR：Change Request）」を事前に確認する
• 準委任契約の場合は「費用の上限（キャップ）」を設定できるか交渉する

追加見積もり・変更管理（Change Request）

意味: 開発途中に仕様変更や追加機能の要求が発生した場合の対応手続きです。

• 変更管理（CR: Change Request）: 当初合意した仕様から変更が生じた際に、変更内容・影響するスコープ・追加費用・スケジュール変更を確認・承認するプロセス
• 追加見積もり: 変更管理の一部として、追加作業の費用見積もりを提示してもらうこと

発注者の確認ポイント:

• 「どの規模の変更からCRが発生するか」の基準を事前に合意する（小さな修正も全てCR扱いになるのか、ある程度まとめて処理するのかを確認）
• CR申請から承認・着手までのリードタイム（時間）を確認しておく（緊急の変更が必要なケースへの対応方針）
• 「CRを却下した場合の取り扱い」（後の工程で再申請できるかなど）も確認する

SES・オフショア・RFP

意味: 「SES」「オフショア」は開発会社に依頼する際に出てくる調達方法の用語です。

• SES（システムエンジニアリングサービス）: エンジニアを特定の業務に従事させるサービス形態。発注側の会社でエンジニアが業務に参加しますが、指揮命令権は元の会社（SES会社）にあります
• オフショア開発（Offshore Development）: 海外の開発リソース（主にアジア各国）を活用した開発。コスト削減を目的とするが、コミュニケーションや品質管理のコストも発生します
• RFP（Request for Proposal: 提案依頼書）: 複数のベンダーから提案を受けるために発注者が作成する文書。要件・予算・評価基準をまとめたもの

発注者の確認ポイント:

• SESを活用する場合、「業務の指示（指揮命令）をどちらが行うか」を明確にする（SES契約では発注者側が直接指示することはできない）
• オフショアを含む場合、「日本語でのコミュニケーション体制（ブリッジSE）」を確認する
• RFPを作成する場合は、評価基準（技術力・価格・対応力等）を事前に社内で合意しておく

技術・インフラの用語（API・クラウド・フレームワーク等）

発注者が「なんとなく分かった」と思いやすい技術用語です。しかし実際には「費用負担」「依存リスク」「セキュリティ」など、発注者が意思決定すべき重要な論点を含んでいます。

API（Application Programming Interface）

意味: 異なるシステム・サービス間でデータや機能をやり取りするための「接続口（インターフェース）」です。例えば「GoogleマップのAPIを使う」とは、Google社が提供するAPIを通じて自社サービスにGoogleマップの機能を組み込むことを意味します。

「APIで連携します」という言葉が出た場合、自社システムが外部サービスに依存する部分が発生することを意味します。

発注者の確認ポイント:

• 「外部APIの利用料金（API使用料）は誰が負担するか」を確認する（月額・従量課金で費用が変動するケースがある）
• 「APIを提供している外部サービスが仕様変更・停止した場合、誰が対応するか」を契約で確認する
• 重要な機能をAPIに依存する場合、「APIが停止した場合の代替手段」があるかを確認する

クラウド・AWS・オンプレミス

意味: システムを動かすインフラ（基盤）の設置場所・形態です。

• クラウド（Cloud）: インターネット経由でサーバーやストレージをレンタルするインフラ形態。AWS（Amazon Web Services）、Google Cloud、Azureなどが主要サービスです。初期費用が低く、スケールしやすい反面、月額費用が発生します
• オンプレミス（On-Premise）: 自社でサーバーを購入・設置・管理する形態。イニシャルコストは高いが、月額費用が不要で、データを完全に自社管理できます

発注者の確認ポイント:

• 「月額クラウド費用の概算」と「費用の変動条件（アクセス数増加で費用が増えるか）」を事前に確認する
• クラウドを利用する場合、「アカウントの契約者は誰か」を確認する（開発会社名義の場合、将来的な移行リスクがある）
• 「データの保存場所（国内か海外か）」と「セキュリティ・コンプライアンス要件」を確認する

フレームワーク・ライブラリ

意味: システム開発を効率化するための「ひな型（テンプレート）」または「部品集」です。

• フレームワーク（Framework）: アプリケーションの骨格となるコードの枠組み。「Next.js」「Laravel」「Vue.js」など。特定のフレームワークで構築されたシステムは、そのフレームワークに精通したエンジニアが必要になります
• ライブラリ（Library）: 特定の機能を実現するための部品集。「グラフ表示ライブラリ」「PDF生成ライブラリ」など、必要な機能を部品として組み込みます

発注者の確認ポイント:

• 採用するフレームワークの「エンジニア人口（市場での採用技術者数）」を確認する。マイナーなフレームワークを採用すると、将来的なメンテナンス要員の確保が困難になるリスクがある
• 開発完了後に「別の会社にメンテナンスを依頼できるか」（技術移行性）を確認する
• 「オープンソースライブラリのライセンス条件」が商用利用に問題ないかを確認する

データベース（DB）

意味: システムが扱うデータを蓄積・管理する仕組みです。会員情報・注文履歴・在庫データなど、あらゆるデータはデータベースに保存されます。「PostgreSQL」「MySQL」「MongoDB」などの種類があります。

発注者の確認ポイント:

• 「データの所有権と移行権利」を契約で確認する（プロジェクト終了後にデータをエクスポートして持ち出せるか）
• データのバックアップ体制（頻度・保持期間・復元手順）を確認する
• 個人情報を扱う場合は、「データの暗号化・アクセス権限管理」の方針を確認する

品質・保守の用語（SLA・可用性・テスト種別）

リリース後・保守運用フェーズで出てくる用語です。契約前に合意しておくことで、運用中のトラブルや費用紛争を防げます。

SLA（Service Level Agreement）・可用性・稼働率

意味: システムの「品質保証レベル」を数値で定めた契約・指標です。

• SLA（サービスレベルアグリーメント）: 保守・運用サービスの品質水準（稼働率・障害対応時間等）を定めた合意書
• 可用性（Availability）: システムが正常に動作している割合。「99.9%の可用性」=「年間ダウンタイム8.7時間以内」を意味します
• 稼働率: 一定期間中にシステムが稼働していた割合。99.9%稼働でも、年間約8.7時間は停止可能な計算です

詳しくはシステム保守費用の妥当性を見極める完全ガイドをご参照ください。

発注者の確認ポイント:

• 「99.9%の可用性」が業務上許容できるかを確認する（EC系では深夜でも停止が許されないケースも）
• SLAに「ペナルティ条項（目標未達時のサービスクレジット等）」が含まれているかを確認する
• 障害発生時の「一次連絡先」「対応開始までの時間（RTO）」「復旧目標時間（RPO）」を合意する

単体テスト・結合テスト・受け入れテスト（UAT）

意味: テストには種類があり、工程ごとに確認の範囲が異なります。

• 単体テスト（Unit Test）: 個々の機能・モジュール単体が正しく動作するかを確認。開発会社が実施します
• 結合テスト（Integration Test）: 複数の機能・システムを組み合わせて、連携が正しく動作するかを確認。開発会社が実施します
• 受け入れテスト（UAT: User Acceptance Test）: 発注者・ユーザー目線で「業務要件を満たしているか」を確認するテスト。発注者が参加・主導する最重要フェーズです

発注者の確認ポイント:

• 受け入れテスト（UAT）のスケジュールを事前に確保する（開発完了後に「来週テストしてください」と言われても対応できないケースがある）
• 「受け入れ基準」を要件定義時に文書化しておく（「このユースケースが全て問題なく動作すること」等）
• 「受け入れテスト合格 = 納品完了」のタイミングを契約で確認する

インシデント・障害・バグの違い

意味: 運用中のトラブルを表す用語の違いを理解しておくと、発生時の対応がスムーズになります。

• バグ（Bug）: プログラムのコードに含まれる誤り（欠陥）。テストで発見・修正されることが理想だが、リリース後に発覚することもある
• 障害（Failure）: バグや外部要因（インフラ障害・ネットワーク断等）によってシステムが正常に動作しなくなった状態
• インシデント（Incident）: ユーザーへの影響が発生した障害・問題の総称。「インシデント対応」とは、発生した問題の緊急対処・影響範囲の特定・復旧を指します

発注者の確認ポイント:

• 「障害の重大度レベル（サービス全停止・一部機能不全・軽微な不具合）」に応じた連絡フローと対応優先順位を合意する
• 障害対応後の「原因分析レポート（ポストモーテム）」の提出義務があるか確認する
• 保守期間終了後にバグが発見された場合の対応（有償か無償か・対応範囲）を契約で確認する

保守・運用・サポートの違い

意味: リリース後に継続する活動で、混同しやすい3つの用語です。

• 保守（Maintenance）: システムに問題が発生した際の修正対応・機能改善・バージョンアップなど、システムを良い状態に保つ活動
• 運用（Operation）: システムの日常的な監視・データバックアップ・定期メンテナンスなど、システムを継続稼働させる活動
• サポート（Support）: ユーザーからの問い合わせ対応・操作説明・トラブルシューティングなど、利用者支援の活動

詳しくはシステムの保守と運用の違いとは？をご覧ください。

発注者の確認ポイント:

• 保守契約の「対応範囲の境界線」を確認する（「バグ修正」「機能追加」「OS・ミドルウェアのバージョンアップ対応」等が含まれるか）
• 「追加費用が発生する条件」（時間外対応・特定種別の障害等）を事前に確認する
• 保守担当者が変わった場合の「引き継ぎ資料の整備義務」を契約に含めておく

この記事で取り上げた用語の索引

本記事で解説した用語を50音順・アルファベット順で一覧化しました。打ち合わせ中に特定の用語が出た際は、この索引から該当セクションに直接ジャンプしてください。

あ行

• アジャイル → プロジェクト管理の用語
• インシデント → 品質・保守の用語
• インフラ → 技術・インフラの用語
• 運用 → 品質・保守の用語
• オフショア → 契約・費用の用語

か行

• 可用性 → 品質・保守の用語
• クラウド → 技術・インフラの用語
• 結合テスト → 品質・保守の用語
• 工数 → 契約・費用の用語

さ行

• 障害 → 品質・保守の用語
• スプリント → プロジェクト管理の用語
• SES → 契約・費用の用語
• SLA → 品質・保守の用語

た行

• 単体テスト → 品質・保守の用語
• データベース（DB） → 技術・インフラの用語
• デバッグ → プロジェクト管理の用語
• デプロイ → プロジェクト管理の用語

な行

• 人月・人日 → 契約・費用の用語

は行

• バグ → 品質・保守の用語
• 保守 → 品質・保守の用語
• 変更管理（CR） → 契約・費用の用語

ら行

• ライブラリ → 技術・インフラの用語
• リリース → プロジェクト管理の用語
• ロールアウト → プロジェクト管理の用語

わ行

• ウォーターフォール → プロジェクト管理の用語

A〜Z

• API → 技術・インフラの用語
• AWS → 技術・インフラの用語
• CR（Change Request） → 契約・費用の用語
• QA → プロジェクト管理の用語
• RFP → 契約・費用の用語
• SES → 契約・費用の用語
• SLA → 品質・保守の用語
• UAT → 品質・保守の用語

本記事では、システム開発に携わる非エンジニアの発注者が打ち合わせや契約で直面する主要な用語を解説しました。「用語の意味を知る」だけでなく「その用語が出たとき何を確認すべきか」まで理解しておくことで、開発会社との認識齟齬を大幅に減らすことができます。

各用語の詳細な解説は、本記事内の関連記事リンクからご確認ください。