LASSIC Media らしくメディア
システム開発の用語集｜発注担当者が工程ごとに押さえる32語
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- システム開発の用語は、企画・要件定義・設計・開発・テスト・移行・保守の工程ごとに引くと、見積書の内訳が読みやすくなります。
- 用語の意味は、IPAの共通フレームやデジタル庁のガイドラインなど公的な資料で確かめ、事業者と打ち合わせの最初にそろえます。
- 要件の承認、受入テスト、契約の形と引継ぎの中身は、事業者に頼んでも発注側が確かめる点として残ります。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
見積書に「外部設計」「総合テスト」と書かれているが、何をする工程なのか分からない。打ち合わせで「非機能要件」「移行判定」と言われても、何を聞き返せばよいか分からない——。システム開発を初めて発注する担当者には、こうした戸惑いがつきものです。システム開発の用語集は、企画から保守までの工程で使われる言葉を、意味とあわせて引けるようにまとめたものです。
用語は、どの工程の言葉かと発注側が何を確かめるかを知っておくと役に立ちます。ただし、用語の呼び方は資料や事業者によって違うことがあり、言葉だけでは中身が決まりません。本記事では、システム開発を発注する担当者に向けて、工程ごとの用語32語を表で示し、それぞれの意味と発注側が確かめること、そして外部に頼むときに確認しておきたい点を整理します。
システム開発の用語集とは
この用語集は、発注する側の担当者が打ち合わせや見積書で出会う言葉を、工程ごとに引けるようにしたものです。IPA（情報処理推進機構）の共通フレーム2013は、関係する人々が「同じ言葉を話す」ことができるよう作られた枠組みで、国際規格に合わせたJIS X 0160を土台にしています。*3 用語の意味は、この枠組みとデジタル庁のガイドライン、ITパスポート試験のシラバス、民法で確かめたものに限っています。
- 工程は、企画・要件定義・設計・開発・テスト・移行・保守の7つに分けています
- 用語は32語に絞り、どの語にも「発注側が確かめること」を付けています
- 表の右の列は、そのまま事業者との打ち合わせで聞く項目として使えます
同じ工程でも、資料によって呼び方が違うことがあります。たとえば国のガイドラインが「結合テスト」と書くテストを、ITパスポート試験のシラバスは「統合テスト」と呼びます。*4 打ち合わせの最初に、言葉の意味を事業者とそろえておくことが大切です。
企画と要件定義の用語
企画は、何のためにシステムを作るかを決め、事業者を選ぶまでの工程で、契約の形もここで決まります。国のガイドラインは、見積もりを取るときに業務・機能の内容、規模、サービスレベル、スケジュールなどの情報を事業者に渡し、数量・工数・作業者のレベル・単価などの内訳を明確にするよう求めています。*2
| 用語 | 意味 | 発注側が確かめること |
|---|---|---|
| システム化計画 | 対象業務を分析し、システム化構想と基本方針を立てて、開発の順序・概算コスト・効果などシステム化の全体像を明らかにすること | 概算コストと効果の見積もりを誰が出すか。自社で作るか、開発を外部に委託するかもこの段階で決める |
| RFP（提案依頼書） | 事業者に、導入するシステムの概要、提案を求める事項、調達の条件などを示し、提案書の提出を頼む文書 | 業務・機能の内容、規模、サービスレベル、スケジュールなど、見積もりに要る情報を載せたか |
| PoC（概念検証） | 新しい概念・サービス・ツールについて、実現できるか、効果があるかを検証すること | 何が確かめられたら本番の開発に進むか。検証を終える条件を先に決める |
| 見積書 | システムの開発・運用・保守などにかかる費用を示す文書 | 数量・工数・作業者のレベル・単価の内訳が分かるか。複数の事業者の見積もりを並べて比べる |
| 多段階の見積り | 工程の区切りごとに見積もり直す方式。モデル契約は、工程ごとに委託料を決める多段階契約と再見積りの形をとる | 要件定義が終わった時点で再見積りをする取り決めがあるか |
| 請負 | 当事者の一方が仕事を完成させることを約束し、相手方がその結果に報酬を支払う契約 | 完成させる仕事の範囲を、成果物の名前で契約に書いたか |
| 準委任 | 法律行為ではない事務を委託する契約。委任の規定が準用される | 企画や要件定義の支援を頼むときに、請負か準委任かを区別したか |
請負と準委任は、民法でそれぞれ定めがあります。*5 共通フレームは、企画や要件定義の作業の一部を事業者に頼むときも、最終的な責任の所在を明らかにするため、請負か準委任かを区別しておくよう勧めています。*3 契約の形の違いはシステム開発の準委任契約と請負契約の違いで、提案依頼書の作り方はRFP作成の支援で扱っています。
| 用語 | 意味 | 発注側が確かめること |
|---|---|---|
| 要件定義 | システムの調達にあたって、必要な要件を明確に定める行為、またはその定めた内容 | 要件を最終的に決めて承認する人が自社の誰か |
| 業務要件 | 業務を行う目的、達成したい目標、目標を達成するためのプロセスや流れなど | 利用者の数や、1日・1か月あたりの処理件数などの規模を数字で示せるか |
| 機能要件 | システムの要件のうち、機能に関する内容 | 画面の原案と画面の移り変わりを、実際に使う部門が確かめたか |
| 非機能要件 | 機能要件以外の要件。性能、信頼性、拡張性、運用性、セキュリティなど | 応答時間や障害からの回復時間など、運用で求める水準を書いたか |
要件定義の用語の意味は、デジタル庁の標準ガイドライン群用語集の定義に沿っています。*1 要件はあとから追加や変更が起こりやすく、そのたびに人・費用・期間に影響します。共通フレームは、予算を足す、機能を減らすといった対応をあらかじめルールにしておくよう求めています。*3 進め方は要件定義を外注する費用と進め方で詳しく紹介しています。
設計と開発の用語
設計は、要件定義で決めたことを、作れる形に落とし込む工程です。国のガイドラインは、機能の設計と非機能の設計を分け、どちらも要件定義との整合性を確かめるよう求めています。*2 発注側は、要件定義のどの項目に応えた設計なのかを報告の中で確かめられれば十分です。
| 用語 | 意味 | 発注側が確かめること |
|---|---|---|
| 外部設計 | 経済産業省のモデル契約が業務を分ける単位の一つ。要件定義の支援と、ソフトウェア開発の間に置かれる | この工程を請負と準委任のどちらで契約するか |
| 機能の設計 | 機能要件を具体化・詳細化し、画面・帳票・データ・外部とのつなぎ口・バッチなどを決める設計 | 要件定義と食い違いがないかを確かめた結果の報告を受ける |
| 非機能の設計 | 非機能要件を踏まえて、クラウドサービス・ハードウェア・ミドルウェア・ソフトウェアなどの構成や設定を決める設計 | 非機能要件のどの項目に、どの構成で応えるかを報告で確かめる |
| WBS（Work Breakdown Structure） | 成果物の単位で必要な作業を定め、作業に要る要員・工数・期間を書いた表 | レビューや受入テストなど、自社側の作業と担当者も載っているか |
| 用語 | 意味 | 発注側が確かめること |
|---|---|---|
| ウォータフォール型開発 | 工程を順に進め、原則として前の工程が終わってから次の工程を始める進め方。着手の時点で要件が固まっている場合に用いる | 工程の区切りごとの開始と完了の基準、承認する人 |
| アジャイル型開発 | 設計・開発をイテレーション（反復）と呼ぶ短い期間に分け、期間が終わるたびに機能の動きを確かめられる進め方。要件が固まっていない場合に用いる | 反復のたびに動きを確かめる自社の担当者と時間を確保できるか |
| プログラミング | 設計に従ってプログラムを作ること。共通フレームでは「ソフトウェア構築」と呼ぶ | 見積もりの範囲に、単体テストまでが含まれているか |
| 単体テスト | 作った一つひとつのプログラムに誤り（バグ）がないかを確かめるテスト | 実装と単体テストの実施状況の報告を、いつ受けるか |
開発の進め方は、ウォータフォール型かアジャイル型かで、発注側の関わり方が変わります。デジタル庁の用語集は、要件が固まっていればウォータフォール型、固まっていなければアジャイル型を用いるとしています。*1 アジャイル型は反復のたびに動きを確かめるため、発注側の時間が多く要ります。詳しくは基本設計・詳細設計の外注とアジャイル開発を外注する進め方で紹介しています。
テスト・移行・保守の用語
テストから先は、発注側が自ら手を動かす場面が増える工程です。国のガイドラインは、受入テストの計画書を発注側が作り、実際にシステムを使う部門が受入テストに参加するよう求めています。*2 何をもって合格とするかは、検収の前に決めておきます。
| 用語 | 意味 | 発注側が確かめること |
|---|---|---|
| 結合テスト | 単体テストが済んだプログラムを組み合わせ、要件どおりに動くかを確かめるテスト。ITパスポート試験のシラバスは「統合テスト」と呼ぶ | テスト計画書に、テスト方針・体制・環境・合否判定基準が書かれているか |
| 総合テスト | 結合テストとともに、受入テストの前に設計・開発事業者が行うテスト | 合否判定基準をすべて満たしたという報告を確かめてから、次の工程を認める |
| 受入テスト | 発注側が、システムが要件定義書に書いたことを実現しているかを、本番に近いテストデータで確かめるテスト | 実際に使う部門が参加するか。テスト計画書を発注側が作るか |
| 検収 | 納品物が、要件定義書などで求めた要件と品質を満たしているかを確かめること | 受入テストで合否判定基準を満たしたことを確かめてから検収する |
| 用語 | 意味 | 発注側が確かめること |
|---|---|---|
| 移行計画書 | 本番環境への業務移行・システム移行・データ移行の方法、環境、ツール、段取りなどを書いた計画書 | 一斉切替え・拠点別切替え・業務別切替え・並行運用のどれを選んだか、その理由 |
| データ移行 | 古いシステムのデータを新しいシステムへ移す作業。移すデータの取捨選択、崩れたデータの修復、文字コードの統一などを伴う | 古いデータの整備を、自社と事業者のどちらが担うか |
| リハーサル | 本番環境への移行手順を前もって試し、移行の筋書きとスケジュールが適切かを確かめること | 移行で障害が起きたとき、やり直すか、古い運用に戻すかの判断基準 |
| 移行判定 | 受入テストで品質基準を満たし、移行計画書とリハーサルの結果が適正と判断できたときに限って、本番移行を始める判断 | 判定の条件と、判定する人を前もって決めたか |
移行は、限られた時間で行う作業です。共通フレームは、移行で障害が起きたときに備え、やり直すか古い運用に戻すかを選ぶ判断基準を対応計画に入れておくよう勧めています。*3 受入テストはシステム開発の検収・受入テストの進め方、切り替えの計画はシステム移行のカットオーバー計画で扱っています。
| 用語 | 意味 | 発注側が確かめること |
|---|---|---|
| 運用 | システムの仕様と構成を原則として変えずに、稼働している状態を保つための行為 | 監視や問い合わせの対応など、どこまでを運用として頼むか |
| 保守 | 機能や品質を保ち、システムを設計どおりに動かすための行為。アプリケーション・ハードウェア・ソフトウェア製品・データの保守がある | 保守の対象ごとに作業の中身が違うため、対象を分けて契約に書いたか |
| SLA（サービスレベル契約） | 提供するサービスの水準について結ぶ取り決め。国のガイドラインは、運用・保守の事業者に毎月、サービスレベルの達成状況の報告を求めている | 目標に届かなかった指標について、分析と対策まで報告に含めるか |
| 契約不適合責任 | 引き渡されたものが、種類・品質・数量について契約の内容に合っていないときの責任。民法は修補などの追完を請求できると定めている | 責任の期間・内容・責任の境目を契約に書いたか。保守の作業との分担 |
| 引継ぎ | 設計・開発の事業者が、運用や保守の事業者に、設計書・作業の経緯・残っている課題などを渡すこと | 事業者を替えるときに受け取る設計書と、残っている課題の一覧 |
国のガイドラインは、保守の作業と、契約不適合責任の範囲で行う作業の分担を明確にするよう求めています。*2 不具合の直しがどちらの作業かで、費用の扱いが変わるためです。個別の契約の読み方は、専門家に確かめてください。SLAの決め方は保守契約のSLA設計で紹介しています。
外部に頼むときに確認しておきたい点
事業者に相談する前に、次の5点を社内で整理しておきます。どれも表の右の列と対応しており、整理した内容を渡せば提案や見積書を同じ条件で比べられます。
- 範囲：どの工程を頼み、どの工程を社内で担うか。要件の承認と受入テストは発注側に残る
- 契約の形：工程ごとに請負と準委任のどちらで契約するか
- 体制：レビューや受入テストに出る自社の担当者と、事業者の窓口
- 費用の決まり方：見積書の内訳と、要件定義の後に再見積りをするか
- 引継ぎ：設計書・作業の経緯・残っている課題を、いつ、どの形で受け取るか
見積書の用語のうち、意味が分からない工程名があれば、作業の中身と成果物を事業者に書面で聞いておきます。国のガイドラインの経費の区分も、設計・開発・テスト・移行などの単位に分かれています。*2
まとめ：用語で確かめておきたい3つの点
システム開発の用語について、確かめておきたい点は3つに整理できます。第一に、見積書や提案書の言葉がどの工程のものかを確かめること。第二に、言葉の意味を公的な資料で確かめ、事業者と打ち合わせの最初にそろえること。第三に、要件の承認、受入テスト、契約の形と引継ぎのように、事業者に頼んでも発注側が確かめる点を見落とさないことです。この3点を押さえておけば、「見積書の工程名が分からないまま契約してしまった」という事態を避けやすくなります。用語の整理や工程の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
事業者によって用語の意味が違うときはどうすればよいですか
打ち合わせの最初に、その言葉で何をするのかと、何が成果物になるのかを確かめます。合わせた意味は議事録や要件定義書に書き残しておきます。
用語集の用語はすべて覚えておく必要がありますか
すべてを覚える必要はありません。いま進んでいる工程の表だけを手元に置き、打ち合わせの前に右の列の確かめる点に目を通しておけば足ります。
アジャイル型開発でもこの用語集は使えますか
使えます。アジャイル型開発でも、要件、テスト、移行、保守の考え方はなくなりません。ただし工程を短い期間で繰り返すため、受入テストや検収をどの単位で行うかを、契約の前に事業者と決めておきます。
システム開発の発注準備のご相談
見積書や提案書の用語の確認から、要件定義・受入テスト・移行の進め方の整理まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：デジタル庁「DS-130 標準ガイドライン群用語集」（https://www.digital.go.jp/resources/standard_guidelines）。出典：デジタル社会推進標準ガイドライン DS-130（標準ガイドライン群用語集）。要件定義・業務要件・機能要件・非機能要件・概念検証・WBS・ウォータフォール型開発・アジャイル型開発・運用・保守の定義を参照（2026年10月確認）
- *2 参考：デジタル庁「DS-100 デジタル・ガバメント推進標準ガイドライン」（2026年6月12日）（https://www.digital.go.jp/resources/standard_guidelines）。出典：第3編第3章（経費の見積り）、第6章（調達仕様書の記載事項・検収）、第7章（設計・開発：機能の設計・非機能の設計・テストの計画・受入テスト・移行の実施・引継ぎ）、第9章（運用及び保守）、別紙2（情報システムの経費区分）を参照（2026年10月確認）
- *3 参考：独立行政法人情報処理推進機構（IPA）「SEC BOOKS：共通フレーム2013」第3部 共通フレームとガイダンス（https://www.ipa.go.jp/publish/secbooks20130304.html）。出典：書籍概要（ベースとなる国際規格をJIS X 0160:2012に変更）と、公開PDF「第3部_共通フレームとガイダンス」の1.1 取得プロセス、1.2 供給プロセス、2.2 要件定義プロセス、2.4.5 ソフトウェア構築、3.1.3 業務及びシステムの移行のガイダンスを参照（2026年10月確認）
- *4 参考：IPA「ITパスポート試験 シラバス」Ver.6.5（https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kn1-att/syllabus_ip_ver6_5.pdf）。出典：22．システム化計画、24．調達計画・実施、25．システム開発技術を参照（2026年10月確認）
- *5 参考：民法（明治二十九年法律第八十九号）（https://laws.e-gov.go.jp/law/129AC0000000089）。出典：e-Gov法令検索。第562条（買主の追完請求権）、第632条（請負）、第643条（委任）、第656条（準委任）を参照（2026年10月確認）
