0.はじめに
チームメンバーとの対話で、セキュリティ云々の前に、システム構築について知りたい、という意見がありました。
なるほど、そういうものかと思い、今回（引継ぎ/技術継承の意味も込めて）Qiitaの記事を書いてみることにしました。
システム構築で有名な手法の一つである「ウォーターフォールモデル」をベースに記事を書いていきます。
1. ウォーターフォールモデル
1-1. ウォーターフォールモデルとは
ウォーターフォールモデルとは、システム開発手法の一つで、ある工程を確定してから次の工程に進む方式です。
1970年にWinston W. Royceという方の論文「Managing the Development of Large Software Systems」が元になっているようです。
（面白いのは、彼は別にウォーターフォールモデルを推奨しているわけではないのですが、それはまたの機会に）
1-1-1. 長所
- 認識のずれを少なくできる
各工程ごとにドキュメントを作成し、合意した後に次の工程に進むため、お互いの合意内容にずれが少なくなります（少なくなる可能性が高まります）。
- （何かあった場合）説明しやすい
各工程ごとにドキュメントを作成し、合意した内容を承認するため、後でなぜこうなったかを説明しやすくなります。
- 工程毎に契約しやすい
各工程でドキュメントやアウトプットを作成して合意するため、工程単位で契約しやすくなります。
1-1-2. 短所
- 手戻りのコストが大きい
何らかの認識齟齬が発生して前工程まで戻る場合、何に影響があってどこまで戻るのか調査したり、再度同じような工程を実施する必要があるため、コストがかかります。
（その結果、仕様変更を管理したり、仕様変更かどうかの判定で揉めたりします）
- 実物のシステムをなかなか見れない
ウォーターフォールモデルで実際のシステムを開発・構築するのは後ろの工程のため、なかなか実物を見れません。
（その結果、イメージしていたものとは異なるものになる可能性はあります）
2. システム構築の各工程
ウォーターフォールモデルでシステム構築する場合、一般的に下記に示すような工程（フェーズ）があります。
（プロジェクトによっては名称が異なったり、工程が無かったり、逆に別の工程がある場合もあります）
- 要件定義
- 基本設計
- 詳細設計
- 構築
- 単体テスト
- 結合テスト
- システムテスト
- （移行）
2-1. 各工程の簡単な説明
2-1-1. 要件定義
作りたいシステムに対する要求（要件）を取りまとめる工程です。
夢と希望が膨らむ工程であり、とても楽しい工程である反面、ここで失敗すると後の工程でプロジェクトが炎上し、デスマーチイベントに突入します。
主に「機能要件」と「非機能要件」を取りまとめます。
2-1-2. 基本設計
要件定義に基づき、システム構築の基本的な設計を取りまとめる工程です。
何が基本で、何が詳細なのかは議論の余地がありますが（これは後述します）、基本的なことを取りまとめます。
前工程で定義した「要件」が、もれなく「設計」されていることを確認します。
なお、「外部設計」と呼ぶ場合もあります。
その場合は、（システム内部の処理ではなく）システム外部の処理（インターフェースやUIなど）を取りまとめる工程となります。
2-1-3. 詳細設計
基本設計で設計した内容を、より「詳細」に設計する工程です。
この工程を「パラメータ設計」という場合もありますし、「詳細設計」の後に「パラメータ設計」を実施する場合もあります。
私個人としては、詳細設計＝パラメータ設計、という考え方が好きです。
この場合、前工程で定義した「設計」が、もれなく「パラメータ」に落とし込まれていることを確認します。
さらに、後工程である「構築」で必要な情報が、もれなく「パラメータ」に落とし込まれていることも確認します。
なお、「内部設計」と呼ぶ場合もあります。
その場合は、システム内部の処理を取りまとめる工程となります。
（どこまでが「外部」で、どこからが「内部」かは、議論の余地があります）
2-1-4. 構築
システムを構築する工程です。
構築するシステムの設定値（パラメータ）は、前工程の詳細設計（パラメータ設計）で決まっているため、それに基づき構築していきます。
構築対象のものをすべて構築します。
※構築したものが「正しく」構築されているかどうかは、「テスト」工程で判断します。
2-1-5. 単体テスト
主に詳細設計の内容が構築したシステムに適切に反映されているかを確認する工程です。
詳細設計で定義した「パラメータ」と、実際に構築したシステムの「パラメータ」が一致していることを確認します。
2-1-6. 結合テスト
主に基本設計の内容が構築したシステムに適切に反映されているかを確認する工程です。
通常構築するシステムは、複数のサーバやコンポーネントで成り立っている場合が多く、それらがうまく連携できているかを確認します。
2-1-7. システムテスト
主に要件定義の内容が構築したシステムに適切に反映されているかを確認する工程です。
テスト内容は結合テストと似ていますが、主にお客様が業務として利用する上で問題ないかを確認します。
3. おわりに
今回はシステム構築全般の概要を説明しました。
本当は今回の記事に、各フェーズの詳細も記載しようかと思っていたのですが、要件定義編のボリュームが少し多かったので、分割で記事を書く方針に変更しました。
近々、要件定義編を公開しますので、こちらも併せて読んでみてください（どちらかというと、要件定義編が本命です）。
96.連載のリンク先
（今後、追記します）
97.参考文献
98.更新履歴
- 2026.07.01 初版