システム開発工程で使用する略称｜システム開発工程の種類も解説【2024年最新版】

システム開発では様々な専門用語があります。そのため、システム開発を依頼しようとしている担当者の中には以下のような悩みを抱えている人もいるのではないでしょうか。

• システム開発について、話している内容がわからない
• システム開発について話が十分に理解できないため、信頼して依頼していいか判断できない
• システム開発工程で使われる略語を理解できず、問題なく進行しているか判断できない

本記事では、システム開発工程で使用される略称やシステム開発工程の種類と特徴についても解説します。

この記事を読むことで、システム開発工程でよく使われる言葉の意味がわかるようになります。

システム開発について、どのような会社に相談すればいいか判断できない方はシステム幹事にご相談ください。信頼性が高い開発会社をご紹介いたします。

【無料】とりあえずシステム開発会社を紹介してもらう

システム開発の工程で使用される略称

システム開発では多くの専門用語が使われており、それぞれの意味がわかっていなければ、通常業務で支障をきたしてしまうことも多いでしょう。

業務をスムーズに処理していくためには、以下のような用語の理解が必要です。

• SP（システム企画）
• SA（要求分析）
• RD（要件定義）
• BD（基本設計）
• UI（UI基本設計）
• ED（外部設計）
• DD（詳細設計）
• ID（内部設計）
• SS（構造設計）
• FD（機能設計）
• PD/PS（プログラム設計）
• PG（プログラミング）
• CD（コーディング）
• UT（単体テスト）
• IT（結合テスト）
• PT（総合テスト）
• ST（システムテスト）
• OT（運用テスト）

それぞれの言葉の意味について、次で解説します。

SP（システム企画）

システム企画（SP：System Planning）とは、システムの計画から導入までを行う仕事のことです。事業やサービスをはじめる際に、必要となるシステムはなにか、システム開発の目的や概要を決定し、計画から導入までまとめていきます。

システム開発に関わるプロセスは、以下のような形で進行します。

システム企画はサービスの提供元であるベンダー側が行う場合もあれば、顧客側が行う場合もあります。

SA（要求分析）

要求分析（SA：System Architectural design）とは、顧客の要求は何か、何ができるようになりたいか、分析するプロセスのことです。ベンダー側が顧客に対して直接話を聞く形で要求分析は実施され、文書で残すことが一般的です。

要求分析では「経費の処理を書類で管理しているが、電子化させ、書類紛失のリスクを回避したい」のように定義します。

システムの専門用語は含まれず、経営者などシステムに関する専門知識がない人でも理解できる内容で構成されていることが重要です。

要求は様々なものがありますが、要求として記載されていないものはシステムにも反映されません。そのため、要求を漏れなく聞き取りできているかどうかがシステム開発の成否にも大きな影響を与えます。

RD（要件定義）

要件定義（RD：Requirement Definition）とは、要求定義で提示されたものを技術的にどのように解決するか定義するプロセスです。

要求定義と混同しがちですが、要求定義は顧客の要求そのものをまとめたもの、要件定義は要求を実現する手段をまとめたものと考えるとわかりやすいでしょう。

開発するシステムによって、記載するべき内容は若干変化しますが、

以下のような内容が含まれます。

• システム開発の概要
• システムの構成
• 顧客の現状のフロー
• システム開発後のフロー
• 利用者
• 利用対象者の人数
• 機能の要件

ここで決めた内容をベースにしてシステムの構築を進めるため、定義を可能な限り具体化できていることが、システム開発の成否を分ける重大な要素になります。

BD（基本設計）

基本設計（BD：Basic Design）とは、システム開発上、基本となる設計を決めていくプロセスです。システムの大枠で作成する機能に分類し、基盤となる仕様を決めていきます。

例えば以下のような設計が基本設計には含まれます。

• 使用する機器やソフトウェア
• 必要とされる機能
• 入力や出力に関する操作方法
• 操作画面（UI）
• 作成されるデータの概要

外部設計については、プログラミングの知識よりはユーザー目線が求められるプロセスです。
「どのようなデザインにすれば、ユーザーが使いやすいか」を考える必要があります。

UI（UI基本設計）

ユーザーインターフェース（UI：User Interface）とは、ユーザーとシステムの接点を意味し、具体的には操作方法や画面のレイアウトなどが含まれます。UI工程は基本設計に含まれる工程です。

※「UIの関連用語として「BD（基本設計）」へジャンプする」

ED（外部設計）

外部設計（ED：External Design）は、操作画面や操作方法のような、システムの見た目やユーザーが直接操作する部分に関わる設計のことです。基本設計とほぼ同義で使われることもあります。

※「外部設計の関連用語として「BD（基本設計）」へジャンプする」

DD（詳細設計）

詳細設計（DD：Detail Design）とは、基本設計を実現させていくよう、詳細なプログラムの設計を行うプロセスです。機能ごとに分類し、機能間でデータがどのように処理されるのか、インターフェースの動き方などの詳細についても設計していきます。

目に見える部分ではないため、正確に理解する必要はありませんが、データを処理する方法や呼び出し方法、取得方法、システムの呼び出しなどのシステムの目に見えない部分の動作を決めていくプロセスです。

ID（内部設計）

内部設計（ID：Internal Design）とは、外部設計で決めた仕様通りに動くよう、内部の機能やデータの詳細を決めていくプロセスです。詳細設計はシステムの目に見える部分ではなく、目に見えない部分を扱い、詳細設計と同義で使われることもあります。

※「内部設計の関連用語として「DD（詳細設計）」へジャンプする」

SS（構造設計）

構造設計（ SS：System Structure Design）とは、システムの構造をプログラミングできるよう分解し、具体的に設計できるように設計内容を決めていくプロセスです。

詳細設計や内部設計と似た言葉ですが、明確に区分されておらず、ほぼ同義で用いられることもあります。

※「構造設計の関連用語として「DD（詳細設計）」へジャンプする」

FD（機能設計）

機能設計（FD：Function Design）とは、システムの機能ごとに、具体的な仕様を決定するプロセスです。どの段階で具体的な仕様を決定するかはベンダーごとに違いがあるため、外部設計と内部設計のどちらに含まれるかは、ベンダーごとに異なります。

例えば、内部設計についてであれば、プログラムのレイアウトや操作方法などの内部設計に該当する画面設計が該当します。

外部設計に含まれる部分としてはデータやファイルの仕様、データベースの設計、データの取得元や受け渡し先の設定などが挙げられるでしょう。

PD/PS（プログラム設計）

プログラム設計（PD：Program Design/PS：Program Structure Design）はプログラムでどのような動作や処理をさせるのか、具体的に定義するプロセスです。システムの構造をプログラムごとに分類し、動作内容や処理の流れを決めていきます。

ベンダーによって詳細設計の後のプロセスに位置付けられることもあれば、詳細設計に含まれる場合もあります。そのため、詳細は開発会社に確認しましょう。

PG（プログラミング）

プログラミング（PG：Programing）プログラミングとは、プログラムを作成し、実際に実現したい機能の開発を進めていくプロセスのことです。

具体的には以下のようなプロセスが含まれます。

プログラム設計と、コーディングについては別の小見出しで紹介していますので割愛します。

テストでは、様々なテストが行われますが、動作時の不具合がないか、バグが完全になくなるまでテストと修正を繰り返す工程です。

最終的に顧客に対して、テストを実施後、システムが完成となり、実際の運用が始まります。

CD（コーディング）

コーディングとは、プログラム設計で決めた内容に基づいて、プログラミング言語を記述していくプロセスです。詳細設計を具体的に形にしていく作業が、コーディングだと考えるといいでしょう。

プログラミング言語を入力することで、ユーザーから見える画像や文字、実際の動作などが具体的な形になります。

プログラミング言語には、JavaやRubyなどいくつかの種類がありますが、言語によって得意とするシステムは様々です。そのため、どのような言語を使うのかは、システムに合わせて決められます。

UT（単体テスト）

単体テスト（UT：Unit Test）とは、システムを構成しているそれぞれの機能（モジュール）が、意図した通りに動いているか確認するテストです。

システム開発におけるもっとも早い段階で行われるテストで、分類されたシステムごとにテストするため、バグの原因特定を比較的簡単にできます。

単体テストでは、詳細設計で定義した内容について、設計した通りに動作するか確認します。
丁寧に単体テストを行うことで、その後のテストで大幅な修正を回避して進められるでしょう。

IT（結合テスト）

結合テスト（IT：Integration Test）とは、複数の機能を組み合わせた際に、問題なく動作するかを確認するテストです。組み合わせは2つの組み合わせから、大規模な組み合わせまで柔軟に組み合わせられます。

単体テストが終わった後で行われ、基本設計で決めた内容に対して、問題なく機能するかどうか確認することが主な目的です。この工程を丁寧に行うことで、後に行われる総合テストや運用テスト時のトラブルを防ぎ、テストがスムーズに進行しやすくなります。

PT（総合テスト）

総合テスト（PT：Product Test）とは、プログラム全体に対して行い、要件定義で定義した通りに動作するか確認するテストです。機能面に関する問題に加え、操作性やセキュリティに関してもテストが行われます。

プログラムが正常に動作するかに加え、処理速度に問題はないか、どのくらいのアクセス数まで対応できるかもテスト内容に含まれます。大部分の不具合を修正し、動作に関する問題はほぼ解消される状態を目指します。

ST（システムテスト）

システムテスト（ST：System Test）とは、開発したシステムが要件定義や仕様書の条件を満たして動作しているか確認するテストです。総合テストと同義でも使われます。

※「システムテストの関連用語として「PT（総合テスト）」へジャンプする」

OT（運用テスト）

運用テスト（OT：Operations Test）とは、受け入れテスト（UAT）ともよばれ、実際の運用環境と同様の環境で、問題なく動作するかどうかのテストです。運用テストでは、ベンダー側のシステムエンジニアではなく、顧客が実際に操作します。

機能上の問題だけではなく、ベンダー側が想定していない動作をされても問題はないか、予期していない使用方法で不具合が発生しないかなどを確認し、実際の使用に問題がないか確認することが主な目的です。

このテストが完了したら、実際にシステム運用が始まります。

V字モデル

システム開発でのV字モデルとは、開発工程とテストの工程を以下の画像のようにリンクさせたモデルです。各プロセスで決めた内容に合わせたテストが行われます。

V字モデルを採用することで、各工程で何をテストするべきかがわかりやすくなり、ゴールも明確になることがメリットです。その結果、開発工程で決めた内容を抜けや漏れなくチェックしやすくなります。

また、部分単位のテストから全体のテストに徐々に広がっていく形でテストが実施されるため、大幅な修正のリスクを抑えてテストをしやすい点も特徴です。

【無料】システム開発について相談する

システム開発の工程の種類とメリット・デメリット

システム開発の工程は様々なものがあり、種類ごとにメリットとデメリットがあります。それぞれについて理解を深めることで、自社のニーズに合わせたシステム開発が可能になり、システム開発が成功する可能性がグッと高まります。

ウォーターフォール型の場合

ウォーターフォール型とは、
システム開発の工程を最初に決めた計画通りに順番に進めていく手法です。

メリットとしては、スケジュールが立てやすいことが挙げられます。
なぜなら、工程ごとに仕様書やタスクの振り分けをスムーズにでき、ベンダー側の最良で無理のない工程が組みやすくなるからです。

一方デメリットとしては、仕様変更が起きると、当初の予定通りに完成しない可能性があることが挙げられます。なぜなら、ウォーターフォール型の開発は、一度工程を前に進めると後ろの工程に戻ることが難しくなるからです。

仕様変更があった場合には、スケジュール全体に影響が及び、全体の費用にも影響を及ぼします。
システム開発の初期からある開発手法で、プロジェクト全体のスケジュールが立てやすく、納期が決まって動かせないような場合や、大型のプログラムで仕様変更する可能性が少ないような場合に有効な手法です。

アジャイル型の場合

アジャイル型とは最初に厳密な仕様を決めず、要求分析の内容に応じて、大まかな仕様を決めていく手法です。仕様が細かく決まっていないため、仕様変更に対応しやすく、臨機応変にシステム開発を行えます。

1つのサイクル（イテレーション）を繰り返し、小規模のシステム開発を進めつつ、少しずつ機能を拡充させていきます。

小規模の開発になるため、不具合や仕様変更があった場合にスムーズに対応できる点がメリットです。1サイクルの規模が小さく、予定変更の影響を最小限に抑えられます。

厳密な仕様を決めずにシステム開発を始めるため、スケジュールをコントロールしにくい点がデメリットです。開発全体の目的を明確に設定できていない場合、開発の方向性がブレてしまうリスクもあります。

特にITなど変化が激しい業界で、仕様変更が起こりやすい場合に有効な開発手法です。

スパイラル型の場合

スパイラル型とは、システムを複数のサブシステムに分けて開発を進める手法です。サブシステムの開発が完了したら、サブシステムの内容を顧客が確認し、完了したら、次のサブシステムの開発に進みます。

システムをサブシステムに分けること以外は、ウォーターフォール型と開発プロセスは変わりません。サブシステムに分けることで、ウォーターフォール型よりも柔軟に仕様変更に対応できます。
不具合や問題点を発見し、軌道修正しやすい点もメリットの1つです。

しかし、サブシステムの軌道修正により、開発の全体像をベンダー側が把握しにくくなり、開発が長期化する可能性があることが、デメリットとして挙げられます。

プロトタイプ型の場合

プロトタイプ型とは、最初に試作品（プロトタイプ）を顧客に確認してもらって、フィードバックをもらってから、システム開発を進める手法です。

プロトタイプの段階では詳細な要件定義は行わず、顧客からのフィードバックを元に修正を重ねながら、開発を進めていきます。

プロトタイプ型のメリットは、試作品を実際に顧客に確認してもらい、意見をもらうため、大きな修正や仕様変更を避けつつ、開発が進められることです。フィードバックを元に、一定水準の質を確保しつつ、開発を進められます。

デメリットとしては、大規模開発には不向きな点です。なぜなら大規模開発の場合、プロトタイプの制作や修正にかかる負担が大きくなってしまうからです。

プロトタイプ制作の段階では詳細なイメージが固まっていないため、当初の想定よりも開発スケジュールが長引く可能性や、費用が高くなってしまう可能性もあるので注意が必要です。

【無料】システム開発について相談する

まとめ

本記事では、システム開発時によく使われる略語や用語を紹介しつつ、開発の種類、種類ごとのメリットとデメリットについて解説しました。

システム開発に関する略語や用語は数が多く、ここに紹介した以外の用語もあるため、そう簡単には覚えられません。

システム開発に関する知見がなく、専門用語がわからなくてお困りの方はシステム幹事にお任せください。システム開発について、丁寧に説明し、信頼できるシステム開発会社を紹介いたします。

コンサルタントのご紹介 岩田 専任のコンサルタントが、
お客様の予算と目的を丁寧にヒアリング。
最適な会社をピックアップ・ご紹介させていただきます！
初心者の方でも安心してご相談いただけます。

【【無料】システム開発の専門知識がなくても、安心して相談できるシステム開発会社を紹介してもらう】