4-1 設計の基本概念
Fundamentals of System Design
1. 設計とは
1.1 設計の定義
設計（Design）とは、要件定義で明確化された「何を作るか」を、 「どのように作るか」に変換するプロセスである。 抽象的な要件を、開発者が実装可能な具体的な仕様に落とし込む。
| フェーズ | 問い | 成果物 |
|---|---|---|
| 要件定義 | 何を作るか（What） | 要件仕様書 |
| 設計 | どのように作るか（How） | 設計書 |
| 実装 | 実際に作る | ソースコード |
1.2 設計の目的
設計の目的は、要件を満たすシステムを効率的に構築するための 青写真を作成することである。
| 目的 | 説明 |
|---|---|
| 要件の実現 | 機能要件・非機能要件を満たす構造を定義 |
| 品質の確保 | 保守性、拡張性、性能などの品質特性を確保 |
| 開発の効率化 | 実装の指針を示し、開発者間の認識を統一 |
| リスクの低減 | 技術的な問題を早期に発見・解決 |
| コミュニケーション | ステークホルダー間の共通理解を促進 |
2. 設計のレベル
2.1 基本設計と詳細設計
設計は一般的に、基本設計（外部設計）と詳細設計（内部設計）の 2段階で行われる。
@startuml !theme plain skinparam backgroundColor #FEFEFE skinparam defaultFontName Noto Sans JP title 設計フェーズの流れ rectangle "要件定義" as Req #E0E7FF rectangle "基本設計" as Basic #DBEAFE rectangle "画面設計" as UI #DBEAFE rectangle "DB設計" as DB #DBEAFE rectangle "外部IF設計" as IF #DBEAFE rectangle "詳細設計" as Detail #D1FAE5 rectangle "クラス設計" as Class #D1FAE5 rectangle "モジュール設計" as Module #D1FAE5 rectangle "実装" as Impl #FEF3C7 Req --> Basic : How（どう作るか） Basic --> UI Basic --> DB Basic --> IF UI --> Detail DB --> Detail IF --> Detail Detail --> Class Detail --> Module Class --> Impl Module --> Impl note right of Req What（何を作るか） end note note right of Basic ユーザー視点 end note note right of Detail 開発者視点 end note @enduml
図1: 設計フェーズの流れ
| 観点 | 基本設計（外部設計） | 詳細設計（内部設計） |
|---|---|---|
| 視点 | ユーザー視点（外から見た振る舞い） | 開発者視点（内部構造） |
| 抽象度 | 高い | 低い（具体的） |
| 対象 | システム全体の構成 | 個々のモジュール・コンポーネント |
| 主な内容 | 画面、帳票、外部IF、データ構造 | クラス、メソッド、アルゴリズム |
| 参加者 | ユーザー、SE、アーキテクト | SE、プログラマー |
2.2 基本設計の成果物
基本設計では複数の成果物を作成する。
| 成果物 | 内容 |
|---|---|
| システム構成図 | ハードウェア、ネットワーク構成 |
| 機能一覧 | システムが提供する機能の一覧 |
| 画面設計書 | 画面レイアウト、項目定義、遷移図 |
| 帳票設計書 | 出力帳票のレイアウト、項目 |
| 外部インターフェース設計書 | 他システムとの連携仕様 |
| データベース設計書 | ER図、テーブル定義 |
| バッチ処理設計書 | バッチジョブの構成、スケジュール |
2.3 詳細設計の成果物
詳細設計では実装に必要な詳細を定義する。
| 成果物 | 内容 |
|---|---|
| クラス図 | クラスの構造と関係 |
| シーケンス図 | オブジェクト間のメッセージのやり取り |
| モジュール仕様書 | 各モジュールの入出力、処理ロジック |
| 物理データベース設計 | インデックス、パーティション |
| 単体テスト仕様書 | モジュールレベルのテスト設計 |
アジャイル開発では、事前に詳細な設計書を作成するのではなく、 イテレーションごとに必要な設計を行う。ただし、アーキテクチャなど 変更コストが高い決定は早期に行うことが重要である。
3. 設計の原則
3.1 基本的な設計原則
良い設計を行うための基本原則がある。
| 原則 | 説明 | 効果 |
|---|---|---|
| 関心の分離 | 異なる関心事を異なるモジュールに分離 | 変更の局所化、理解しやすさ |
| 高凝集 | 関連する機能を1つのモジュールにまとめる | モジュールの責務が明確 |
| 低結合 | モジュール間の依存を最小化 | 変更の影響範囲を限定 |
| 情報隠蔽 | 内部実装を外部から隠す | 実装変更の自由度確保 |
| 抽象化 | 詳細を隠し本質的な特徴を抽出 | 複雑性の管理 |
| モジュール化 | システムを独立した部品に分割 | 並行開発、再利用 |
3.2 SOLID原則
SOLID原則はオブジェクト指向設計の5つの基本原則である。
| 原則 | 名称 | 説明 |
|---|---|---|
| S | 単一責任の原則 | クラスは1つの責任のみを持つ |
| O | 開放閉鎖の原則 | 拡張に開き、修正に閉じる |
| L | リスコフの置換原則 | サブクラスは親クラスと置換可能 |
| I | インターフェース分離の原則 | クライアントに不要なメソッドへの依存を強制しない |
| D | 依存性逆転の原則 | 抽象に依存し、具象に依存しない |
設計原則は重要だが、過剰に適用すると複雑になりすぎることがある。 YAGNI（You Ain't Gonna Need It：今必要でないものは作らない）の 精神で、必要十分な設計を心がけるべきである。
4. 良い設計の特性
4.1 品質特性
良い設計は、以下の品質特性を備えている。
| 特性 | 説明 | 実現方法 |
|---|---|---|
| 正確性 | 要件を正しく満たす | 要件トレーサビリティ、レビュー |
| 保守性 | 変更・修正が容易 | モジュール化、文書化 |
| 拡張性 | 機能追加が容易 | 抽象化、プラグイン構造 |
| 再利用性 | 部品を他で再利用可能 | 汎用化、共通ライブラリ |
| テスト容易性 | テストしやすい構造 | 依存性注入、モック可能 |
| 理解容易性 | 設計意図が明確 | 命名規則、設計パターン |
4.2 設計のトレードオフ
設計では、相反する特性間のトレードオフを検討する必要がある。
| トレードオフ | 例 |
|---|---|
| 性能 vs 保守性 | 最適化されたコードは読みにくい |
| 柔軟性 vs 複雑性 | 拡張可能にすると構造が複雑化 |
| セキュリティ vs 利便性 | 認証を強化すると操作が煩雑 |
| 開発速度 vs 品質 | 急ぐと技術的負債が蓄積 |
設計判断の記録
重要な設計判断は「アーキテクチャ決定記録（ADR）」として 文書化することが推奨される。判断の背景、検討した選択肢、 選択理由、トレードオフを記録しておくことで、 後から設計意図を理解しやすくなる。
設計の基本概念を理解したら、次は「4-2 アーキテクチャ設計」で システム全体の構造設計について学習しよう。
[1] Martin, R. C. (2017). Clean Architecture.
[2] Bass, L. et al. (2012). Software Architecture in Practice.