基本設計・詳細設計とは
システム開発にはさまざまな工程があります。
要件定義・基本設計・詳細設計などなどの工程が存在します。
設計書を作成するのは、開発工程の前段階である「設計」工程。設計工程はシステム開発の方向性を左右するため、特に重要とされています。
さらに設計工程は「基本設計」と「詳細設計」に分かれます。
設計業務に携わっていなくても、名前は聞いたことがあるという方は多いのではないでしょうか。
ただ、具体的にどのような違いがあるのか明確に理解できていない方もいるかもしれません。
1. システム設計とは
システム開発における「設計」とは、要件定義の工程で定めた要件を実現するためにシステムを設計する工程です。
要件定義ではクライアントの要求をもとにシステムに実装する機能や性能を決定しますが、設計は実際にシステムを動かす部分の仕様を決定します。
この設計段階で作成される設計書をもとに、次の工程である開発（プログラミング）が行われます。
開発が開始されてから修正が生じた場合は予定外の時間やコストが発生する可能性が高く、スケジュールの遅延や予算オーバーを招きかねません。
こうした問題を避けるために綿密な設計を行っておくことが重要であり、必要不可欠な工程といえます。
2. 基本設計・詳細設計の違い
システム設計は「基本設計」と「詳細設計」に分かれます。
名前だけを見ると「基本設計は大まかな概要の設計」、「詳細設計はより細かな設計」と解釈されがちですが、厳密にはそれぞれ明確な役割を担っています。
まず、基本設計とは要件定義のあとに行うもの。
要件定義での決定内容を実現させるためにシステムに実装する機能を明確化・具体化していく工程です。
クライアント向けに行われる設計で、ユーザーから見たときにどのような動作になるのかを決めるため「外部設計」とも呼ばれます。
一方、詳細設計は基本設計のあとに行うもの。基本設計書をもとに、プログラミングを行うエンジニアへ向けて「機能をどのように実装するのか」という設計を行う工程です。
詳細設計書を見ただけでエンジニアがプログラムを組めるよう、非常に細かい部分まで落とし込みます。
クライアントから見えない部分の設計を行うため「内部設計」とも呼ばれます。
3. 基本設計の進め方
3-1. 要件定義書の内容を確認する
基本設計は要件定義をもとに行うため、まずは要件定義書の内容を確認します。
複数名で基本設計を行う場合は、メンバー同士の認識をすり合わせる必要があります。
3-2. 設計を行う
確認した要件をもとにシステムの骨組みを決定する設計を行います。
具体的には以下のような作業が該当します。
・実装する機能の洗い出し
・必要なデータの明確化、整理
・画面レイアウトの決定
3-3. 基本設計書を作成する
基本設計書はクライアントに対して具体的なシステムの仕様を伝え、問題ないか確認してもらう役割もあります。
そのため開発者以外でも理解しやすいよう、専門用語などは使わず作成することが一般的です。
基本設計書に盛り込まれる項目は開発内容によって異なりますが、以下のようなドキュメントを作成することが多いです。
・機能一覧
システムに実装する機能を一覧にしたものです。
たとえば販売管理システムであれば見積入力、受注入力、受注チェックリストなど、必要な各機能をまとめます。
システムで作るべきものの全体像を把握できるように作成します。
・業務フロー図、システム構成図
システムを利用する際の処理がどのように行われるのかを明確にするための設計図です。
システムの構成要素を図形などを使って示し、それぞれの要素を線などでつないで処理の流れを表現します。
・画面設計図
システムにおいてどのような画面を表示するのか設計したものです。
要件定義である程度イメージされているものを、より明確に定義します。
画面一覧や画面遷移図、画面レイアウトを最終決定し、正常時のパターンだけでなくエラー時のパターンなども追加します。
・帳票設計図
販売管理システムなどのように、帳票が必要となるシステムを開発する際には帳票設計図を作成します。
要件定義で整理した帳票一覧や帳票レイアウトをより具体的にしたものです。
さらに帳票に表示する項目の内容を具体的に示した出力項目一覧や、帳票の編集方法を示した編集定義を作成して設計書としてまとめます。
・バッチ設計図
バッチとは、あらかじめ登録した一連の処理を自動的に実行する処理方式のことを指します。
バッチ設計図は要件定義で整理されたバッチ一覧をもとに、バッチ処理フローやバッチ処理定義を作成して設計書としてまとめたものです。
・データベース設計図
システムで使用するデータをどのように整理して保管するかを表したものです。
データベース内にデータがどのように保存されるかを可視化するテーブル関連図（ER図）、テーブルごとにどのような機能を持つかを表でまとめたCRUD図などを作成してまとめます。
・外部インターフェース設計図
要件定義で決定したシステムに連携する外部サービスについて連携方法や連携時に参照するデータなどを明確に定義したものです。
データ連携を一覧にまとめた外部インターフェース一覧、データのやりとりについて定義した外部インターフェース定義書、連携の手順やチェック方法等を取り決めた外部インターフェース処理概要などを作成します。
3-4. レビューを行う
基本設計書の完成後に、メンバー内とクライアント側それぞれの評価者からレビューを受けます。
設計内容を確認してもらうことで、設計者が気付かない欠陥や認識の相違を発見して修正することが目的です。
後続工程での混乱を防ぎ、品質を向上させます。
4. 基本設計の注意点
4-1. さまざまな視点から全体像を意識する
基本設計で意識すべきなのは、幅広い視点を持ちさまざまな角度から考えることです。
クライアント視点を持つことはもちろんですが、その後の詳細設計や開発以降の工程も考慮してバランスを取りながら要望をかなえるシステムを実現しなければなりません。
一つの視点ではなく、あらゆる角度から全体像を見られるように意識しましょう。
4-2. 要件定義との整合性
基本設計の内容は、その後の全工程に影響します。
基本設計と要件定義の整合性が取れていなければ、完成したシステムはクライアントのニーズとかけ離れてしまうでしょう。
あくまで要件定義書をもとに基本設計書としてアウトプットすることを意識し、次の工程に移る前に整合性を入念に確認しましょう。
4-3. 実現方法は適切か
要件定義書に記載された要件の多くは実現方法が複数ありますが、基本設計の段階で後続工程を意識しながら適切な実現方法を選択する必要があります。
インフラ構成からアプリケーションの機能、処理性能や運用面だけでなくそれらにかかるコストも検討項目です。
判断が難しい場合、特定の技術や業務に詳しい専門家からのレビューを受けることも非常に有効です。
5. 詳細設計の進め方
基本的な進め方は基本設計と同様ですが、詳細設計は実際にプログラミングを行うエンジニア向けに作成するものということを意識しましょう。
5-1. 基本設計書の内容を確認する
詳細設計では、基本設計で固めたシステムの全体像を具体化させていきます。
まずは基本設計書の内容を確認し、メンバー内で認識をすり合わせます。
5-2. 設計を行う
詳細設計書に記載された各機能をプログラムで実現できるよう設計を行います。
具体的には以下のような作業が該当します。
・機能やビジネスロジックの整理
・実装する機能の割り振り
・共通化できる部分の設計
・プラットホームに合わせた設計
5-3. 詳細設計書を作成する
設計がある程度固まったら、詳細設計書を作成します。
基本設計書はクライアント向けの読みやすい記述であるのに対し、詳細設計書は実際にプログラミングを行うエンジニア向けた指示書となるため、専門用語が並ぶことも特徴です。
基本設計書と同様、開発内容によって含まれる要素は異なりますが、主なドキュメントとしては以下のようなものがあげられます。
1.クラス図
システム同士の関係性や構造を表したものです。
プログラミングを行う際の見取り図としての役割があり、複数人で分業する際に役立ちます。
特に大規模な開発ではクラス図を作成しないと概要が分かりにくく、チームの連携が難しくなるため欠かせません。
またこのあと紹介するアクティビティ図やシーケンス図のもととなるため、重要な役割を持ちます。
2.アクティビティ図
ユーザー操作やシステム処理の流れを表したものです。
システムが稼働を始めてから終了するまでの動作を順番どおりに記載します。
基本的な書き方はフローチャートと同じで、ユーザー操作やシステム処理を矢印でつないで表します。
3.シーケンス図
アクティビティ図よりもシステム内部の処理をさらに細かく記載したもので、クラス・オブジェクト（データ構造）間のやりとりを時間軸に沿って表します。
アクティビティ図で大まかなユーザーと処理の流れを把握し、より詳細な処理を把握するためにシーケンス図を利用するといったイメージです。
4.モジュール構成図
各機能に必要な処理をモジュールごとに示し、またモジュール同士の関連性も表現したものです。
モジュールの構造を図形などを用いて表すことで、視覚的に理解しやすくなります。
モジュール化を活用した開発を行う場合、モジュールの組み合わせ方も重要になるため設計工程でモジュール構成図を作成することは必須です。
5-4. レビューを行う
詳細設計書の完成後に、メンバー内の評価者からのレビューを受けます。
仕様の問題や誤字のほかにも、渡される値の範囲や等号・不等号の明確さなど細かな箇所まで確認します。
詳細設計書上ではささいなミスでも、開発後のシステムでは不具合として表面化するため入念なレビューを行い手戻りを減らすことが重要です。
6. 詳細設計の注意点
1.曖昧な表現は避ける
エンジニアが詳細設計書を見ただけですぐにプログラミングに取り掛かれるようなアウトプットを目指しましょう。
「ここはどうプログラミングしたら良いの？」と疑問を持たれるようでは良い詳細設計書とは言えません。
曖昧な表現は避け、エンジニアなら誰もが理解できるようなドキュメントを心がけます。
2.説明文はシンプルに
説明文はなるべくシンプルであることが望ましいです。
長い文章だと読み手は理解するのに時間がかかるうえ、誤解して受け取る可能性も高くなります。
どうしても説明事項が多くなる場合は箇条書きにしたり、図や表を用いたりして表現方法を工夫するのがおすすめです。
7. 基本設計・詳細設計のまとめ
基本設計はユーザーから見たときの動作を設計するもの、詳細設計はエンジニアがプログラミングを行うために設計するものというように、それぞれに明確な役割があることがわかります。
要件定義と同じく、上流工程である基本設計・詳細設計には幅広い知識やスキルが必要です。
ハードルが高く感じるかもしれませんが、プロジェクトを成功に導くためには欠かせない重要な工程といえます。
考える力が試されますが、後続のコーディングがスムーズに出来るように、知識・スキルを高めていきましょう。