システム構築のプロセスを徹底解説

ITの普及により、現代社会のニーズは日々めまぐるしく変化し、ビジネスの現場ではそれらの変化に迅速かつ柔軟に対応することが求められています。まさにITの力にその対応力が求められており、ITシステムは今や企業や組織の活動に欠かせない存在です。

ただ、いざシステム構築の計画を立てようとすると、どのような構築プロセスを踏むべきか、また各プロセスで何を気を付けるべきか、システム構築の経験や知識が豊富でない者には、計画を立てることすら非常に困難であると気付きます。

本記事では、システム構築に関する知識や経験が浅い情報システム担当者、あるいは技術者向けに、システム構築における各プロセスや構築手法について解説します。

本記事を参考にすることで、システム構築の各プロセスを一から理解し、是非期待に応えられるシステム構築をやり遂げられることを願います。

そもそもシステム構築とは何かといった基本的な内容についても別の記事で説明していますので、こちらの記事も是非参照してください。

システム構築のプロセスとは

はじめに、システム構築のプロセスについて説明します。

システム構築プロセスの概要

システム構築・構築は、次のプロセスで構成されています。

要件定義
基本設計（外部設計）
詳細設計（内部設計）
構築（開発）
テスト
移行
運用・保守

構築・開発の手法により、これらのプロセスを実施する順序や回数に違いがあります。

２章で各工程の詳細を説明し、３章で構築手法の紹介および構築手法の違いによってこれらの工程がどのように組み合わされるかを説明します。

各工程の説明

はじめに、システム構築の各工程について理解していきましょう。

要件定義

要件定義とは、構築するシステムの要件を決める工程です。

要件は「機能要件」と「非機能要件」に分けられますが、それぞれ次のような違いがあります。

機能要件　：システムが実行する必要がある機能に関する要件

非機能要件：機能要件を補足するための機能以外の部分や品質に関する要件

もっと分かり易いように言い換えると、機能要件は「そのシステムで何を達成するか」というシステムの目的に直接関わる要件を指し、非機能要件は可用性や保守性などシステムのサービスレベルや構造に関する要件を指します。

基本設計（外部設計）

基本設計とは、要件定義フェーズで定めた要件をどのように実現するか、システムの概要を設計する工程です。システムを構成するハードウェアやソフトウェアの数や種類、ネットワーク構成やこれらの設備をどのように配置するかなどシステムの大枠部分を定義します。

一方で、ソフトウェア開発では外部設計と称する場合があります。これは、ソフトウェアの画面など利用者が触れる部分を外部、利用者が直接目で触れることのないプログラムやデータベースなどを内部とし、前者について設計をする工程を指します。

詳細設計（内部設計）

基本設計がシステムの概要に関する設計であったのに対し、より詳細な部分を設計する工程を詳細設計と呼びます。具体的には、構成するハードウェアやソフトウェアの設定パラメータ、プログラムなどが対象となります。

前章で言及した通り、ソフトウェア開発では内部設計と称する場合があり、システムの内部で実行されるプログラムや連携するデータベースのプロパティ、テーブル構造やプロシージャに関する設計を行います。

構築（開発）

文字通り、設計したハードウェアやソフトウェアの設定を実際に行う工程です。

ソフトウェア開発の場合は開発と称し、プログラミングはこの工程で行います。

テスト

ここからは、構築したものをテストする工程です。

一般的にシステム開発とシステム構築の工程は、以下の流れで行われます。

単体テスト
結合テスト
総合テスト（システムテスト）

単体テスト

単体テストでは、主にハードウェアやソフトウェアの設定値が設計通りであるかを検証します。ハードウェアおよびソフトウェア単体で完結する簡単な動作試験であれば、この工程で実施することもあります。

また、プログラムの場合は、設計通りにプログラムを作成できているかを検証することになります。

単体テストによって設計通りでない箇所を検出した場合は、その原因を特定および分類し、どのように修正したかまできちんと記録します。

結合テスト

結合テストでは、システムを構成するハードウェアやソフトウェアが連動し、想定通りの動きをするかを機能単位で検証します。

単体テストで設定値が正しいことを確認しても、複数のハードウェア、ソフトウェアが組み合わさった場合、それぞれの仕様や制約などによって想定した動作をしない場合もあるのです。

結合テストの結果についても、単体テストと同様にテストの合否結果を記録し、想定通りでない箇所は原因から対応結果までを細かく管理することで、システムの品質を高めます。

総合テスト（システムテスト）

総合テストは、システムを構成するすべての構成要素が揃った状態で実施する動作確認テストです。結合テストでは機能単位での確認でしたが、総合テストは各機能を組み合わせた状態でシステム全体の動作を最終確認する違いがあります。

移行・導入

システム全体の動作確認を終えると、いよいよ構築したシステムを稼働させる準備を行います。

既存のシステムが存在する場合は、既存システムから新システムに切り替えることを移行と称します。一方、既存のシステムが存在しない場合、新システムを新規に稼働させることを導入と称します。

移行と導入のいずれにしても、前もって作業に掛かる時間や手順を念入りに検討し、うまくいかなかった場合には元の状態に戻すところまで計画します。

システムの規模によっては、移行のリハーサルを実施する場合や、何段階かに分けて部分的に順次移行することもあります。

運用・保守

新システムが導入された後は、日々の業務遂行やシステムを安定的に稼働させるために操作を行う運用フェーズとなります。

また、システムで障害が発生したり、バグや脆弱性が発覚した場合は、保守作業として然るべき対処を実施します。

システムで行う通常あるいは想定外の操作・作業を、まとめて運用・保守と称します。

構築手法により構築工程は異なる

続いて、システム構築の手法について説明します。

構築方法の種類

構築の手法はいくつかあるのですが、ここでは次の手法をピックアップして説明します。

ウォーターフォール・モデル
アジャイルソフトウェア開発
プロトタイプ・モデル
スパイラル・モデル

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

ウォーターフォール・モデルは、工程を上流から下流へ滝が流れるようにプロセスを組み、システム構築・開発を行う方法です。構築・開発プロセスが決められた順序に従って進むため、シンプルでわかりやすいことが特徴です。

日本国内では、システム構築・開発プロジェクトの実に97.4%がウォーターフォール・モデルで行われているとされています^※。

※IPA（独立行政法人情報処理推進機構）「ソフトウェア開発データ白書 2018-2019」

ウォーターフォール・モデルには、次のような特徴があります。

　・工程に則って確実に開発を進めていくため、進捗状況を把握し易い

　・計画的に構築・開発を進めやすい

　・高品質なシステムを作りやすい

　・予算や人材を確保しやすい

　・業務の引継ぎが行いやすい

要するに、定められた順序で上流プロセスから下流プロセスに進捗が進むため、スケジュールや投入リソースの計画を立てやすいということです。

ウォーターフォール・モデルでシステム構築を計画すると、例えば次のようなプロセスを組みます。

また、デメリットとしては、次のようなものが考えられます。

工程1つ1つを確実に完了させるため、システム完成させまでに時間が掛かる
前工程の取りこぼしや解決すべき課題は、後工程の投入リソースで回収を図るためある程度バッファが無いと現場負担が大きくなる
計画性の高さゆえ、急な仕様変更などには対応しにくい面がある

アジャイルソフトウェア開発

アジャイルソフトウェア開発は、システム構築・開発を小さな単位に分け、「計画」「実装、テスト」「機能のリリース」のプロセスを何度も繰り返すシステム開発方法です。

「開発」とあるように、システム基盤部分ではなくアプリケーション開発でよく用いられる手法となります。

アジャイルという言葉は日本語で「素早い」「俊敏」という意味を持ち、より良い開発方法を探し出すことを目的に、2001年にアメリカのユタ州に集まった技術者によって提唱された工程モデルです。

アジャイルソフトウェア開発には、次のような特徴があります。

スピーディーに開発を進められる
世の中の状況や技術の変化に柔軟に対応できる
新規事業や変化の多い事業との相性が良い

最近ではクラウドコンピューティングも普及していますが、ビジネスを取り巻く環境は急速に変化をするため、ITシステムにも迅速かつ柔軟な対応力が求められています。

前述のウォーターフォール・モデルは約50年の歴史を持つ構築・開発手法ですが、変化に対応しにくいウォーターフォール・モデルに対して、アジャイルソフトウェア開発は昨今の需要により適した手法であるといえるでしょう。

アジャイルソフトウェア開発でシステム構築を計画すると、例えば次のようなプロセスを組みます。

また、デメリットとしては、次のようなものが考えられます。

構築・開発するシステムの要件がある程度定まっていないと、工期や投入リソースが膨れ上がる可能性がある
計画的に構築・開発を進めにくい
構築・開発するシステムの要件や仕様がブレやすい

プロトタイプ・モデル

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

プロトタイプ・モデルには、次のような特徴があります。

ユーザーとITベンダの認識齟齬が生じにくい
終盤工程で手戻りが発生しにくい
小規模な構築・開発との相性が良い
画面操作を主体とするシステムとの相性が良い
ユーザーがシステムの具体的なイメージを持っていない場合にイメージを共有できる

プロトタイプ・モデルでシステム構築を計画すると、例えば次のようなプロセスを組みます。

また、デメリットとしては、次のようなものが考えられます。

大規模開発には向いていない
仕様の変更や追加を繰り返すと、工期や費用が膨らむリスクがある
プロトタイプを製作する手間が掛かる

スパイラル・モデル

スパイラル・モデルは、構築・開発対象のシステムを機能単位で分割して、重要度の高い機能から優先的に構築・開発を進める手法です。機能ごとに「要件定義→設計→開発→テスト」の工程を複数回繰り返し、改善しながら構築・開発していきます。

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

プロトタイプを製作する点でプロトタイプ・モデルと共通していますが、プロトタイプ・モデルとは違いがあります。

プロトタイプ・モデルでは開発当初から改善を前提とし、プロトタイプを製作しますが、スパイラルモデルでは段階ごとにプロトタイプを製作します。

スパイラル・モデルには、次のような特徴があります。

ステップごとにプロトタイプを作成し、得られたフィードバックを後工程に活かせる
改善を繰り返しながら構築・開発を進めるため、完成度の高いシステムが完成しやすい
仕様やスケジュールの変更に柔軟に対応できる
ユーザーとITベンダの認識齟齬が生じにくい

スパイラル・モデルでシステム構築を計画すると、例えば次のようなプロセスを組みます。

また、デメリットとしては、次のようなものが考えられます。

　・プロジェクトの全体像をつかみにくい

　・仕様の変更や追加を繰り返すと工期や費用が膨らむリスクがある

各構築手法のメリット・デメリット

ここまで紹介した構築手法について、改めてメリットおよびデメリットを整理しました。

開発手法	メリット	デメリット
ウォーターフォール・モデル	・進捗状況を把握し易い・計画的に構築を進め易い・高品質なシステムを作り易い・予算や人材を確保し易い・業務の引継ぎが行い易い	・完成までに時間が掛かる・バッファが無いと現場負担が　大きくなる・急な仕様変更に対応しにくい
アジャイルソフトウェア開発	・スピーディーに開発できる・世の中の状況や技術の変化に　柔軟に対応できる・新規事業や変化の多い事業と　相性が良い	・工期や投入リソースが膨らむ　可能性がある・計画的に開発を進めにくい・システム要件や仕様が　ブレやすい
プロトタイプ・モデル	・依頼先との認識がズレにくい・終盤工程で手戻りが生じにくい・小規模な構築との相性が良い・画面操作主体のシステムと　相性が良い・具体的なイメージが無くても　構築を始められる	・大規模開発には向いていない・工期や費用が膨らみ易い・プロトタイプを製作する　手間が掛かる
ストライプ・モデル	・構築しながらフィードバックを　得て後工程に活かせる・完成度の高いシステムを　作り易い・仕様やスケジュールの変更に　柔軟に対応できる・依頼先との認識がズレにくい	・プロジェクトの全体像を　つかみにくい・工期や費用が膨らみ易い