システム開発・構築の違いとは？工程の流れや覚えておきたい略語などについても解説！

システム開発事業に参入したばかりの方やこれからシステム開発事業に参入しようと考えている方の中には、「システム開発」と「システム構築」の違いについて、理解が曖昧な方もいらっしゃるのではないでしょうか。システム開発とシステム構築は混同しやすいですが、対象とする範囲が異なるものです。これからシステム開発に携わるのであれば、それぞれの違いについて理解しておくことが大切です。

本記事では、システム開発とシステム構築の概要や違い、工程などについて詳しくご紹介します。

 

目次

 

 

システム開発・構築の工程って何？

システム開発の工程とは、システム開発においてあらかじめ決まった手順のことです。システムやWebアプリケーションを「最小限の時間とコスト、かつ高品質で開発するための枠組み」と考えるとわかりやすいですね。工程（枠組み）に沿ってシステム開発を進めていくことによって、品質の向上が期待できます。工程ごとに期限や品質の基準などを設け、それぞれの工程でしっかり管理することが、一定の品質を保ちつつ、期限までにシステムを開発して提供することにつながります。

システム構築でも同じことがいえ、決められた基準をもとに設計やプログラミング・テストをすることで、質の高いシステムの提供が可能です。

工程における期限はシステムの規模感によって異なり、小規模のシステムなら3ヶ月程度を期日とすることも珍しくありません。一方で大規模なシステムになれば、長期間1つの案件に着手することになるため、システムの規模に比例して各工程の期限を決めていくことが困難になります。

 

システム開発とシステム構築の違い

意味を混同しやすいシステム開発とシステム構築ですが、そもそも「開発」と「構築」では言葉の意味が異なります。開発とは、新しいものを作り実用化することを指します。構築とは、すでにあるモノ（材料や部品）を組み立て築き上げることを指します。開発が、新規性があるものに使われる一方で、構築は材料や部品、人材はすでに存在している前提で使用されることが多く、新規性に限定されません。

システム開発とは、プログラムの設計と実際のプログラミング、完成したシステムのテスト作業までの一連の作業のことを指し、システム構築はシステム開発の成果物を組み立て、実際に運用できるようにする「仕組み化」のプロセスを指します。

開発と構築の言葉の意味においては異なりますが、システム構築はシステム開発と同義語として語られることが多い傾向にあり、明確な違いはありません。言葉を使う方によって使い分けられている単語という認識も強い傾向にあります。

 

●「システム構築」は仕組み化までを範囲とすることも

先述のとおり、システム開発とシステム構築において明確な違いはないものの、対象とする範囲によって使い分ける場合があります。例えば、システム構築は「仕組み化までを範囲」と考えます。プログラミング、実装、テスト完了後に、それらの組み立てを行い実際に運用できるようにするところまでを指します。一方でシステム開発はプログラムの設計やプログラミング、テスト完了までの範囲を指し、システム構築の一部としてみなされます。システム構築はテストで完了ではなくその後に組み立てを行い実際に運用可能な状態にするまでだと考えるとわかりやすいです。対象とする範囲は違いますが、システム開発とシステム構築の工程において、大きな違いはありません。

 

システム開発とシステム構築の工程について

システム開発とシステム構築は、同義として使われていることもあれば、システム開発がシステム構築の一部とみなされることもあります。しかし、着手していく工程において大きな違いはありません。一般的にシステム開発とシステム構築の工程は、以下の流れで行われます。

 

• 要件定義（要求定義）

• 外部設計

• 内部設計

• プログラミング

• 単体テスト

• 結合テスト

• システムテスト

• 運用テスト

• システム移行

• 運用・保守

 

それぞれの工程について、詳しくみていきましょう。

 

●要件定義（要求定義）

要件定義とは、作り上げるシステムをどういった内容にしていくのかを決めていく工程のことを指します。決めた内容をもとに、予算や人員、期間なども設定します。要件定義に必要な事項は、以下のとおりです。

 

• システム開発や構築の実績

• システムを作り上げるためのプログラミングスキル

• 各工程の計画を立てていく能力

 

要件定義は、プログラミングスキルがあれば必ずしもできることではありません。上流工程であるため、定義するためにはシステム開発や構築における豊富な経験が求められます。

さらに各工程においてそれぞれ計画を立てる必要があるため、特定の工程について詳しいだけでは計画が立てられません。常に計画性を保ちながら、システムを作り上げていける環境の基盤を構築することが重要です。

そのため、要件定義は時間をかけて各工程の間で整合性が取れているかを確認しながら計画を立てていきます。また、要件定義で決めたことは各工程の責任者に伝えていきます。ここで誰か1人でも認識の違いがあると、完成するシステムに大きな影響を及ぼすため、しっかりと認識を合わせておきましょう。

 

●外部設計

外部設計とは、システムの画面の見た目を設計していくことを指します。要件定義で決めた内容に則って、ユーザーインターフェースを作り上げていきます。外部設計で不備があると、ユーザーが使いにくいシステムが完成することも起こり得ます。自社のシステムや依頼された企業に向けたシステムであれば業務効率の悪化を引き起こしてしまいますし、顧客に向けたシステムであれば満足度の低下につながるリスクとなるため、重要な工程です。外部設計をする際には、ユーザー側の視点に立つことが大切です。

 

●内部設計

内部設計とは、システムやソフトウェアの各種内部仕様を細かく定義する工程のことを指します。内部設計はプログラミングにかかわる工程です。外部設計が十分であっても、外部設計で設計した内容をシステム上に正しく反映させられないと意味をなしません。そのため、内部設計では開発者側の視点でプログラムの設計を進めていきます。内部設計に不備があった際には、システム内の必要な機能が使えないことも起こり得ます。内部設計が十分に行われていれば、安定して使えるシステムとなり、ユーザーから高い評価を得ることにつながります。

正しいコードによって設計できているかを確認するため、内部設計では1人だけでなく複数人でチェックすることがおすすめです。また、内部設計までが、システム開発やシステム設計の上流工程です。上流工程においては、あらゆる知識や経験が求められるため、経験豊富なエンジニアが担うケースが大半です。

 

●プログラミング

内部設計で大型プログラミングの型が完成したら、それに基づいてプログラミングの作成を行います。作成するシステムの種類によって必要なプログラミング言語が異なるため、システム会社によっては、様々な言語を使い分けてプログラミングを行います。世界中で高い人気を誇るJavaや、実行速度の速さに定評があるC言語など、言語ごとに特徴が異なります。

 

●単体テスト

プログラミングが完了したら、問題なく運用できるかテストします。テストには複数の種類があるため、システム全体をチェックするだけではありません。まずは、個々のプログラムが最初の要件定義で定めた内容を満たしているかテストしていきます。正常に反応しなかったプログラムが見つかれば、反応した内容を確認してどこに問題があったのかを明確にし、修正をします。

 

●結合テスト

単体テストのみが完了しても、システムが正常に反応するとは限りません。複数のプログラムが組み合わさることによって、それぞれが干渉し合い、正常に反応しないことも起こり得ます。そのため、複数のプログラムを組み合わせた結合テストを行います。具体的には、データの受け渡しなどの際にプログラム同士が正確に連携してくれるかなどをチェックするテストのことを指します。

 

●システムテスト

単体テストと結合テストが完了したら、すべてのプログラムを合わせて正常に反応するかを確認するため、システムテストをします。

単体テストや結合テストは、正常に反応してくれるか確認するテストである一方で、システムテストにおいてはシステム全体をテストする必要があります。そのため、アクセスへの耐久性や処理速度などを意識してテストを行います。要件定義のとおりに動作するかを確認することはもちろん、実際にユーザーが利用する際のことを考えてチェックすることが大切です。開発側の環境で問題なくシステムが運用できるか確認し、問題がなければ最後のテストへと移行します。

 

●運用テスト

システムテストが完了したら、実際にシステムを利用する環境下でも正常に反応するか、運用テストを行います。システム会社の環境で問題なく動いても、実際に使う現場の環境で正常に使うことができなければ意味をなしません。運用テスト以前のテストよりも、実用性を重視してチェックするテストだといえます。

 

●システム移行

すべてのテストが完了して、現場で問題なく運用する判断できたら、旧システムから新システムに移行させていきます。システムの移行には、大きく分けえると一気に切り替えていく一斉移行と徐々に切り替えていく順次移行の2つの方法があります。一斉移行は新システムへの移行を急速に行う場合に効果的な反面、現場で使う方がすぐに対応できず混乱を招くことも起こり得ます。急速に新システムへの移行が必要ない場合は、順次移行で段階的にシステムを切り替えていく方法がおすすめです。

 

●運用・保守

システムは完成して終わりではありません。システムの運用と保守を行い、システムを使い続けられるようにする必要があります。完成したシステムのことをもっとも理解しているのはシステム開発会社であるため、現場でシステムを持続的に活用し続けるための運用や保守を行えます。そのため、システム開発会社がシステムの運用や保守をするのが一般的です。例えば、メモリの利用状況を確認したり、システムのアップデートを行ったり、運用保守の業務内容は多岐に渡ります。

 

システム開発の工程モデル

システム開発の工程モデルには、複数の種類があります。システム開発の主な工程モデルとして、以下の6つが挙げられます。

 

• ウォーターフォールモデル

• アジャイルモデル

• DevOps（デブオプス）

• プロトタイプモデル

• スパイラルモデル

• V字モデル

 

それぞれの工程モデルについて、詳しくご紹介します。

 

●ウォーターフォールモデル

ウォーターフォールモデルとは、上流工程から下流工程に向けて流れるようにシステム開発を行う方法のことを指します。上から下へ流れる滝をイメージして生み出された開発方法で、開発手順がシンプルでわかりやすいことが特徴です。

要件定義から始まる工程に則って確実に開発を進めていくため、進捗状況が把握しやすく、計画的に開発を進めやすいというメリットがあります。計画的に開発ができることから、高品質なシステムを作りやすいほか、予算や人材を確保しやすい、業務の引継ぎが行いやすいというメリットもあります。

しかし工程1つ1つを確実に完了しないと次の行程に進めないため、システム完成させまでに時間がかかってしまうことがデメリットです。そのため、スピード感を持ってシステムを作りたい場合は不向きな方法だといえます。

 

●アジャイルモデル

アジャイルモデルとは、開発を小さな単位に分け、「計画する」「実装、テスト」「機能のリリース」という流れを何度も繰り返し行う開発方法のことです。

アジャイルという言葉を日本語に訳すと「素早い」「機敏」となり、スピーディーに開発を進められる点が特徴です。アジャイルモデルは、2001年により良い開発方法を探し出すことを目的に、アメリカのユタ州に集まったプログラマーと技術者によって提唱された工程モデルです。

アジャイルモデルにおいては、ウォーターフォールモデルのように計画に則って進めていくことよりも変化への柔軟な対応が重要視されています。2000年代に入ってからは、インターネットが急速に普及したことによって、世の中や企業を取り巻くビジネスモデルが急速に変化しました。世の中の変化の波に乗るためには、変化に柔軟に対応することが重要です。このような背景から、近年はアジャイルモデルへとシフトしている傾向にあります。

また、システムを早急に完成させたい場合に有効な方法で、アプリ開発のようにスピーディーな事業展開が求められる新規事業におすすめです。

 

●DevOps（デブオプス）

DevOps（デブオプス）とは、開発担当者と運用担当者が連携、協力して、柔軟かつスピーディーにシステム開発を行う手法のことを指します。

DevOpsは造語であり、「開発（Development）」と「運用（Operations）」を組み合わせた言葉です。DevOpsが生まれた背景には、開発担当者と運用担当者はそれぞれの立場の違いから、意見の対立が生じてしまう問題の解決のためにありました。

アジャイルモデルの項目でも触れたとおり、近年はより迅速な開発が求められおり、開発・運用チームの内部的な対立で疲弊してしまうことは避けることが大切です。そこで開発担当者と運用担当者が協力して円滑に開発を進めていくDevOpsにおける考え方が生まれ、注目されるようになりました。DevOpsは、開発工程の自動化を目指すことも特徴としてあります。すべての作業を迅速に、かつ品質を保証しながら行えるようになり、競争優位性を高めることにもつながります。

 

●プロトタイプモデル

プロトタイプモデルとは、本格的な開発に移る前にシステムのプロトタイプ（＝試作品）を作り、顧客のフィードバックを得ながら開発を進める方法のことを指します。認識の齟齬をなくし、スムーズに開発を進めることが目的です。

試作品を用いるため機能制限はあるものの、顧客が実際にシステムを操作し、リリース後の機能を試すことができます。

従来用いられていたウォーターフォールモデルは、仕様書やワイヤーフレームを使った確認のため、認識の齟齬が生じやすく、開発の終盤に手戻りが発生しやすいことが問題でした。このような問題を解決する目的で用いられるようになった方法が、プロトタイプモデルです。

近年のシステム開発においてはUIやUXが重要視されているため、プロトタイプモデルはこれからますます求められる開発モデルだといえます。

プロトタイプモデルは小規模な開発に適しており、以下の特徴を持つシステム開発においては特に役立ちます。

 

• 画面操作を主体とするシステム

• 顧客が具体的なイメージを持っていなかったり、仕様が固まっていなかったりするケース

• 技術的に可能か、事前のチェックが必要なケース

 

●スパイラルモデル

スパイラルモデルとは、対象のシステムを機能ごとに分割して、重要な機能から構築していく開発手法のことを指します。機能ごとに「要件定義→設計→開発→テスト→レビュー」の工程を複数回繰り返し、改善しながら完成を目指します。

ステップごとにプロトタイプを作成し、顧客のレビューにより得られたフィードバックをその後の工程に活かしていくことが特徴です。改善を繰り返して完成したシステムを本番環境へと移行し、運用・保守の段階へ至ります。

工程を繰り返す形が螺旋状に見えるということから、「スパイラル」という名称になりました。

スパイラルモデルは、最初にプロダクト全体の設計を行わず、機能ごとに開発計画を立てます。そのため、仕様やスケジュールの変更に柔軟に対応できるメリットがあります。開発の初期段階からプロトタイプを使って動作させることによって評価やレビューを得られるため、イメージの共有がしやすくなり、システムのクオリティを保ちやすい点もメリットとして挙げられます。

前項のプロトタイプモデルとは、プロトタイプを製作するという共通点がありますが、プロトタイプを作るフェーズや段階に違いがあります。プロトタイプモデルでは開発当初から改善を前提とし、プロトタイプを製作しますがスパイラルモデルでは、段階ごとにプロトタイプを製作します。

 

●V字モデル

V字モデルとは、システム開発の開始から終了までの流れをV字のような進め方をするモデルです。ウォーターフォールモデルは、要件定義からシステムテストの工程において上流から下流に流れる滝のようなイメージの方法ですが、V字モデルは開発から後の作業を折り返したV字型になる方法です。

開発工程とテスト工程において各作業をリンクさせ、検証作業を効率良く実施することが特徴です。それぞれのリンクは、以下のとおりです。

• 要件定義の内容をシステムテストで確認

• 基本設計の内容を結合テストで確認

• 詳細設計の内容を単体テストで確認

V字モデルは、ウォーターフォールモデルが進化した開発モデルだといえます。

 

システム開発の種類

システム開発には工程のモデルだけでなく、開発の種類も複数あります。システム開発の主な種類として、以下の3つが挙げられます。

• オープン系システム

• 汎用系システム

• Web系システム

ここでは、それぞれの種類について詳しくみていきましょう。

 

●オープン系システム

オープン系システムとは、すでに仕様が公開されているソフトウェアやハードウェアを利用して開発したシステムのことを指します。特定条件に依存することなく様々な条件下にも対応できることから、開放を表すオープンという言葉が使われています。

オープン系システムはPCで動かすことを前提とした業務アプリケーションが多いため、ユーザーのニーズをしっかり考慮し、OSやルーターなどの環境面も踏まえたうえで開発します。企業ごとに必要となるシステムは異なるため、より高い専門性が実現できるオーダーメイドのシステム開発だといえます。オープン系システムの具体的な開発事例として、受発注管理システムや在庫管理システム、販売管理システムなどが挙げられます。

開発に使用する主な言語は、JavaやC++などが挙げられますが、近年ではRubyやPythonが用いられることもあります。

 

●汎用系システム

汎用系システムとは、専用の汎用機といわれる大型のコンピュータに組み込み利用するシステムや、汎用機で開発するシステムのことを指します。PCやスマートフォンが普及する以前に業務用の大型コンピュータとして使用されていたものを汎用機といいます。1964年にSystem/360という汎用コンピュータが開発される以前は、コンピュータは用途によって使い分けられていました。それらを1台で完結できるようにした高性能なコンピュータが汎用機です。

汎用機はメインフレームと呼ばれることも多く、PCやスマートフォンが普及した現代においても企業や公的機関において用いられています。

一般的に、金融や物流などの分野で基幹システムとしてデータ処理の中枢的な役割を果たし、その重要性からホストコンピュータ同義に扱われることもあります。具体的な開発事例としては、高いセキュリティと耐久性が必要とされる金融系や流通系、メーカー系などの基幹システムが該当します。

開発に使用する主な言語は、COBOLなどが挙げられます。

 

●Web系システム

Web系システムとは、Webアプリケーションを開発するシステム開発のことを指します。インターネットの発展が盛んになり、オープン系システムから派生したものがWeb系システムです。

インターネットを介してブラウザ上で利用できるシステムのため、PCやモバイルデバイスなどWebブラウザが搭載されている機器で利用します。インターネットを介することが特徴の1つですが、社内のイントラネットにだけ接続するシステムはWeb系システムではなく、基本的に不特定多数のユーザーに使われるものを指します。

具体的な開発事例としては、ECサイトやSNSなどが挙げられます。

不特定多数のユーザーがアクセスできるため、BtoCのシステムに適しています。また、データベースサーバを活用することで大量のデータを保持できるため、業務システムなどの複雑なデータ管理が可能な点も特徴です。

高速処理が可能な言語を使用する必要があり、開発に使用する言語としてはPHPやJavaなどが挙げられます。

 

覚えておきたい略語について

要件定義を行う中では、クライアントと意見をすり合わせる必要があります。その際には、専門用語の内容をしっかり伝えることが求められるため、以下の略語の内容についてはしっかり覚えておきましょう。

 

• SP：企画

• SA：要求分析/システム方式設計要求分析

• RD-UI：要件定義

• UI：基本設計

• BD：基本設計

• SS：構造設計

• FD：機能設計

• DD：詳細設計

• PD：詳細設計/プログラム設計

• PS：詳細設計

• CD：コーディング

• PG：プログラミング

• PT：総合テスト

• OTO：運用テスト

 

システム開発を依頼する前の準備

システム開発を依頼する際には、事前準備も重要な要素の1つです。システム開発を依頼する前には、以下のことについて準備しておきましょう。

 

• システム開発の契約形態について知っておく

• 提案依頼書を用意する

• 見積もりは複数の企業からとっておく

 

ここでは、それぞれのポイントについて詳しく解説します。

 

●システム開発の契約形態について知っておく

システム開発の契約形態においては、請負契約と準委任契約などがあります。請負契約と準委任契約では、報酬の対象と開発者の義務において大きな違いがあります。

請負契約とは、業務の完了を約束し、成果物に対して報酬が発生する契約のことを指します。そのため、開発者にはシステムを開発して、成果物を納品する義務があります。

準委任契約とは、システム開発に費やした労働力に対して報酬が発生する契約のことを指します。そのため、開発者の義務は、求められる業務に対して適切に稼働することとなります。

契約形態は、システム開発の工程モデルによっても異なります。例えば、ウォーターフォールモデルでは、プロジェクトの初期段階で要件や仕様を決定するため、成果物が明確な詳細設計やプログラミングなどを請負契約として締結することが多いです。その一方で、アジャイルモデルでは開発途中で仕様変更を重ねながら進めるため、準委任契約を締結することが多いです。

自社が依頼するシステム開発には、どちらの契約形態が適しているか把握するために、それぞれの契約形態について知っておきましょう。

 

●提案依頼書を用意する

提案依頼書を用意することも重要なポイントです。提案依頼書とは、システム開発の発注先を選定する際に、システムの依頼背景や目的、概要など、発注準備で用意する内容を記載したもののことを指します。提案依頼書は、英訳すると「Request for Proposal」となるため、その略称であるRFPとも呼ばれています。

外注先は、提案依頼書をもとにシステム開発の提案をするため、非常に重要な書類です。提案依頼書を用意するメリットとして、以下の4つが挙げられます。

 

• 自社が求めるシステム要件を外注先に正しく伝えることができる

• 外注先を選定する際に、比較すべき項目が明確になる

• 自社システムの現状を見直し、解決すべき課題が確認できる

• 自社システムが目指す形を明確化し、社内および外注先と共有できる

 

提案依頼書が用意できなかったり、内容が不十分であったりすると、自社と外注先の間で認識の齟齬が生じ、工期や金額が見積もりと大きくずれてしまうことが起こり得るため、注意しましょう。

 

●見積もりは複数の企業からとっておく

見積もりを評価しやすくするために、複数の企業から見積もりをとりましょう。見積もり依頼をする際に、前項の提案依頼書が必要になります。

複数社から見積もりがきたら、見積もり内容を評価します。評価する際には、以下の4つのポイントに注意します。

 

• 着手から納品までの期間が明確か

• 金額や工数の数字が妥当であるか

• 提案力があるか

• 責任の範囲が明確か

• トラブルに対する対応が含まれているか

 

上記のポイントを抑えながら、複数社の見積もりを確認しもっとも自社に適している外注先を選ぶことが重要です。見積もりの内容について曖昧なまま発注し開発を進めてしまうと、見積もり内容と依頼内容に大きな齟齬が生じたり、そもそもの前提条件の認識がずれたりと、やり直しになることも起こり得ます。見積もりで不明瞭な箇所があった場合は、必ず質問して不明点を解消しておきましょう。

 

開発・構築の違いを理解してシステム開発依頼を容易に

システム開発とシステム構築は類似している言葉ではありますが、開発と構築の言葉が表す意味を考えると異なることがわかりますよね。行う作業の範囲によって変化するため、システム開発とシステム構築の違いについてしっかり理解することが大切です。

システムを作り上げる際には要件定義や設計、プログラミング、テストを経て実際に現場で運用していきます。システムを完成し、運用するまでの過程においてのシステム開発とシステム構築の範囲についても理解しておきましょう。

また、システムの開発や構築を依頼する際には、依頼内容に適したシステム会社に依頼することが大切です。システム開発とシステム構築の外注先をお探しであれば、発注ナビにお任せください。発注ナビであれば、全国5000社以上の開発会社の中から、ご要望や案件内容に合ったテスト会社や第三者検証会社を厳選してご紹介可能です。「自社に合った開発会社がわからない」「選定にできるだけ時間をかけずにスムーズに導入したい」とお考えのご担当者様はぜひ一度ご検討してみてはいかがでしょうか。

 

 

 

■システム開発に関連した記事