はじめに（この記事で解決できること）
システム開発では、要件定義、基本設計、詳細設計、実装、テストといった複数の工程が登場します。
それぞれの名前を知っていても、「なぜ工程を分けるのか」「前の工程で決めた内容が次の工程へどうつながるのか」が分からなければ、開発全体の流れは理解しにくいものです。
システム設計の工程は、単に作業を順番に並べたものではありません。曖昧な要求を段階的に具体化し、次の工程で判断や作業ができる状態へ変換していく流れです。
この記事では、要件定義から基本設計、詳細設計、実装、テストまでの関係を整理し、設計工程を分ける理由を解説します。
この記事で分かること
- システム設計の工程とは何か
- 要件定義・基本設計・詳細設計の関係
- 設計工程を複数に分ける理由
- 各工程で決めた内容が次の工程へどう渡されるか
- 設計書と設計レビューの位置付け
システム設計の工程とは
システム設計の工程とは、利用者や事業の要求を、実際に開発できるシステムの構造や仕様へ段階的に具体化していく流れです。
要件定義では「何を実現するか」や「どのような条件を満たすか」を整理します。しかし、要件だけでは、画面、データ、処理、プログラムの構造までは決まりません。
そこで基本設計と詳細設計を通じて、システム全体の振る舞いから内部の実装方法まで、判断の粒度を徐々に細かくしていきます。
設計工程の本質は、抽象的な要求を一度にプログラムへ変えるのではなく、複数の段階を通じて実装可能な状態へ変換することです。
設計工程の全体像
代表的なシステム開発の流れは、次のように整理できます。
| 工程 | 主に決めること | 次の工程へ渡す内容 |
|---|---|---|
| 要件定義 | 何を実現するか、対象範囲、制約、品質条件 | 設計の判断基準 |
| 基本設計 | システム全体の構成、外部から見た振る舞い | システムとしての仕様 |
| 詳細設計 | 機能内部の処理、部品構成、データの扱い | 実装可能な設計 |
| 実装 | 設計に基づくプログラムや設定 | 動作するシステム |
| テスト | 要件と設計どおりに動くか | 品質の確認結果 |
各工程は独立しているわけではありません。前の工程で決めた内容が、次の工程で判断するための前提になります。
設計工程を理解するときは、工程名を暗記するのではなく、何を入力として受け取り、何を判断し、何を次の工程へ渡すのかを確認することが重要です。
設計工程を分ける理由
判断の粒度が異なるため
要件定義では、利用者や事業が何を必要としているかを整理します。
基本設計では、その要件をシステム全体の構成や振る舞いへ変換します。詳細設計では、さらにプログラムとして実装できる粒度へ具体化します。
最初からクラス構成や処理方法まで決めようとすると、前提となる要件やシステム全体の方針が固まっていないため、後から大きな修正が必要になります。
大きな判断から小さな判断へ順番に具体化することで、手戻りを抑えられます。
判断する人と確認する人が異なるため
要件定義では、利用者、業務担当者、発注者などの視点が重要です。
基本設計では、システム全体を理解する設計者や運用担当者の視点が加わります。詳細設計では、実際にプログラムを作成する開発者が判断できる情報が必要です。
工程を分けることで、それぞれの段階に適した関係者が内容を確認できます。
問題を早い段階で発見するため
実装が終わってから要件の不足や設計の矛盾が見つかると、プログラムやテストを大きく修正しなければなりません。
要件定義、基本設計、詳細設計の各段階で内容を確認すれば、問題がまだ文章や図の状態であるうちに修正できます。
設計工程を分けることには、問題を早期に発見し、修正に必要なコストを小さくする役割があります。
各工程はどのようにつながるのか
要件定義から基本設計へ
要件定義では、実現する機能、対象範囲、性能、セキュリティ、予算、運用条件などを整理します。
これらは、基本設計でシステム全体の構成を決めるための判断基準になります。
要件が曖昧なままでは、設計者ごとに優先する内容が異なり、システム全体の方針も定まりません。
基本設計から詳細設計へ
基本設計では、画面、機能、データ、外部連携、権限など、システム全体の構成と外部から見た振る舞いを整理します。
詳細設計では、基本設計で決めた内容を、実際にプログラムとして作れる形へ具体化します。
処理の流れ、モジュール構成、クラスやメソッド、データ操作、エラー時の振る舞いなどが主な対象です。
詳細設計から実装・テストへ
実装では、詳細設計をもとにプログラムや設定を作成します。
テストでは、実装した内容が詳細設計に合っているかだけでなく、基本設計や要件定義で決めた内容を満たしているかを確認します。
そのため、テストは実装だけを確認する工程ではありません。要件から設計、実装までのつながりが正しいかを確認する工程でもあります。
基本設計と詳細設計の境界は組織によって異なる
基本設計と詳細設計の名称や境界は、組織や開発方法によって異なります。
基本設計を外部設計、詳細設計を内部設計と呼ぶ場合もあります。一つの設計工程としてまとめて実施する場合もあります。
重要なのは名称ではありません。
システム全体の構成や外部から見た振る舞いを決める段階と、実装に必要な内部構造や処理を決める段階があり、判断が段階的に具体化されることが重要です。
基本設計と詳細設計の具体的な違いは、別の記事で詳しく扱います。
設計書と設計レビューの位置付け
設計工程では、決めた内容を設計書や図として記録します。
設計書の目的は文書を作ることではありません。設計上の判断を関係者へ共有し、次の工程で同じ前提に基づいて作業できる状態を作ることです。
設計レビューでは、要件との不一致、設計の矛盾、考慮漏れなどを確認します。
設計書が判断を記録して伝える役割を持つのに対し、設計レビューは、その判断が妥当で次の工程へ進める状態かを確認する役割を持ちます。
設計書の種類や作成方法、設計レビューの具体的な観点は、それぞれ独立した記事で扱います。
設計工程は常に一方向ではない
設計工程は、要件定義から基本設計、詳細設計へ一度だけ進むとは限りません。
詳細設計を進める中で、基本設計の問題が見つかることがあります。実装やテストによって、要件や設計の不足が明らかになる場合もあります。
その場合は、必要な工程へ戻って内容を修正します。
重要なのは、工程を必ず一方向に進めることではありません。変更が発生したときに、どの判断へ戻り、どの設計書や実装へ影響するかを追跡できることです。
注文履歴機能を設計する例
「利用者が過去の注文履歴を確認できるようにしたい」という要求を例に考えます。
要件定義では、誰が何年分の履歴を確認できるのか、どの程度の応答速度が必要なのかなどを整理します。
基本設計では、注文履歴画面、検索条件、表示項目、権限、データの取得方法などを決めます。
詳細設計では、注文履歴を取得する処理、データベースへの問い合わせ、画面へ返すデータ形式、エラー時の処理などを具体化します。
実装では、その設計に基づいてプログラムを作成します。
テストでは、正しい利用者へ正しい注文履歴が表示されるか、件数が多い場合でも性能要件を満たせるかを確認します。
このように、一つの要求は複数の工程を通じて具体化され、動作するシステムへ変換されます。
まとめ
システム設計の工程とは、要件を段階的に具体化し、実装とテストが可能な状態へ変換していく流れです。
要件定義では設計の判断基準を決め、基本設計ではシステム全体の構成や振る舞いを整理します。詳細設計では、実装に必要な内部の構造や処理を決めます。
工程を分けることで、判断の粒度と確認する関係者を整理し、問題を実装前の段階で発見できます。
ただし、設計工程は必ずしも一方向ではありません。レビュー、実装、テストで問題が見つかった場合は、必要な工程へ戻りながら設計を改善することが重要です。
関連記事
コメント