基本設計と詳細設計の違いは？システム開発の工程や設計書の書き方も含め解説

2024年6月17日

システム開発プロセスにおいて、基本設計と詳細設計の違いを正しく理解することは重要です。
多くの人が両者の違いを混同したり、単に設計の粒度の違いと誤解したりしがちです。
しかし、エンジニアとして開発に携わる者は、それぞれの目的と作成物の違いを把握しておく必要があります。

基本設計では、全体のシステム構成や機能要件を定義し、
詳細設計では、基本設計に基づいて具体的な設計を行います。

前者は大まかな枠組みを決め、後者はその実装方法を詳述するのが目的です。
本稿では、両者の違いを明確にし、適切な理解を促すことを目指しました。
システム開発に関わる方々は、この違いを十分に認識し、プロジェクトに活かしてください。

気になる内容をタップ

1 システム開発における工程とは？
- 1.1 システム開発の工程化
2 基本設計と詳細設計の違い
- 2.1 顧客向け基本設計の目的と内容
- 2.2 詳細設計の目的と内容
3 基本設計の作成項目
4 詳細設計の成果物例
5 まとめ

システム開発における工程とは？

ソフトウェア開発は、一般的に定められた一連のプロセスに従って実施されます。
通常、次のステップが含まれています。

要件収集
基本設計
詳細設計
コーディング
単体テスト
統合テスト
システムテスト
運用テスト
リリース
運用
メンテナンス

まず、顧客の要望を聞き取り、システムの概要を作成する要件収集が行われます。
次に、要件に基づいてシステムの設計書が作成されます。
その後、設計書に従ってコーディングが実施されます。
システムが適切に機能することを確認するためのテストが実施された後、リリースが行われます。
リリース後は、システムが適切に稼働するよう運用とメンテナンスが実施されます。
一般的に、要件収集から詳細設計までをシステムエンジニアが、コーディングからシステムテストまでをプログラマーが担当します。

システム開発の工程化

システム開発において、工程に従うことの最大の目的は、開発の手戻りを最小限に抑えることにあります。

要件定義や設計段階で綿密な検討を行い、顧客や上層部の承認を得てから次のステップに進むことで、開発フェーズでの仕様変更リクエストを防ぐ努力がなされています。
また、工程を順守することにより、開発上の課題を事前に発見しやすくなり、設計の大幅な見直しを回避できます。
さらに、各工程で必要となる人員や期間を事前に算出しやすくなるため、見積もりの精度が高まるというメリットもあります。

このように、システム開発では手順に沿った進行が重視されているのです。

基本設計と詳細設計の違い

システム開発における設計工程は、大まかな構造を決める基本設計と、細部にわたる詳細設計に区分されます。
両者の作業内容は異なりますが、その違いを正しく理解していない人が多数います。

基本設計でシステムの概要を定め、詳細設計でそれを掘り下げていくと考えている人もいますが、この認識は正確ではありません。

ここでは、基本設計と詳細設計の相違点について説明します。

それぞれの工程における作業内容
目標
具体的な行動内容

を解説していきます。

顧客向け基本設計の目的と内容

基本設計は、クライアントに向けて実施される設計プロセスであり、外部設計とも呼称されています。
この段階では、以下の2点が目的となります。

システムの仕様をクライアントに伝達し、提案された仕様で問題がないかを確認すること
システムの画面デザインや導入するサーバー・ネットワーク環境などの詳細を設計書にまとめること

クライアントはシステム開発に精通しているわけではないため、基本設計書は開発者以外の者でも理解できるように作成しなければなりません。
また、クライアントの理解を促進するため、設計書の様式がある程度標準化されていることが一般的です。

このように、基本設計の主な目的は、クライアントにシステムの概要を適切に伝達することにあります。

詳細設計の目的と内容

システムの内部構造や動作を明確化するために、開発者向けに行われる設計作業が詳細設計です。この設計書には、以下が記載されます。

各プログラムの処理の流れ
データの移動経路

詳細設計書は社内資料のため、企業ごとに書式や記載内容が異なることが多く、統一されたフォーマットはありません。
一方で、細かい処理の決定は開発者に一任する企業もあり、詳細設計を行わない場合もあります。
要するに、詳細設計の目的は、システムの内部動作を開発者に正確に伝えることにあります。

基本設計の作成項目

基本設計の構成要素を整理しました。
主要な項目として、

機能一覧
システム構築の概要図
画面レイアウト
帳票フォーマット
バッチ処理の設計図

があげられます。
ただし、開発プロジェクトの性質によって必要な資料は変わってくるため、注意が必要です。
それぞれの項目について詳しく説明していきましょう。

システム機能一覧表の作成プロセス

開発プロジェクトの初期段階では、要件定義書に基づいて必要な機能をリストアップします。
例えばECサイトの場合、

トップページ
ログイン機能
マイページ

などの機能を洗い出します。
このリストには、各機能の概要的な実装方法や優先度なども記載されます。
機能一覧が完成次第、顧客に提示し、要件を満たしているか、追加の要望がないかを確認します。
顧客からのフィードバックを反映させながら、機能一覧を改訂していきます。

システム構成図の作成ガイド

システム全体の構成を視覚的に表したものがシステム構成図です。この図には、サーバーやネットワークなどのインフラストラクチャの設計が含まれます。

具体的には、

利用するクラウドサービス
各サーバーの役割
サーバーに割り当てられるIPアドレス

などが記載されます。

システム構成図は顧客にも理解しやすいよう、専門用語の使用を最小限に抑える必要があります。

画面設計の重要性

ウェブアプリケーションや業務システムの画面構成を視覚的に表したものが画面設計図です。
各画面のレイアウト、ボタンの配置など、ユーザーインターフェースの詳細を決定します。
また、画面間の遷移経路を明確に示す必要があります。
ユーザーが直接操作するこの部分は、基本設計において極めて重要な役割を担っています。

帳票設計図の概要

帳票設計図は、システムから生成される書類の内容を示す資料です。業務アプリケーションでは、領収証や見積書など様々な文書を扱う場合があり、それらの構成要素を明確に定義する必要があります。具体的には、

書類に含まれる項目
レイアウト

などを記述します。ただし、出力する書類がない場合は、帳票設計図を作成する必要はありません。

バッチ設計の基本

定期的に実行されるプログラムを指します。例えば、ECサイトでは新商品の入荷通知メールを送信するためのプログラムがあります。
このようなプログラムの種類、目的、実行タイミングなどを記した設計書を作成します。
ただし、この設計書は顧客向けのものなので、プログラムの詳細な処理フローまでは記載されないことが一般的です。

詳細設計の成果物例

設計の詳細化においては、社内の開発者向けに設計書の作成が行われます。作成される資料は企業ごとに異なりますが、一般的には次の3種類が挙げられます。

クラス関係図
アクティビティ図
シーケンス図

こうした資料を用意することで、エンジニアが混乱することなく実装作業に取り掛かれるようになります。これが詳細設計の目的です。
それぞれの成果物について、より深く説明していきましょう。

クラス図の重要性

クラスの構造や相互関係を視覚化する図表がクラス図です。
オブジェクト指向プログラミングにおいて、各クラスの属性やメソッドを一覧化することで、クラスの役割や他のクラスとの関連性を把握しやすくなります。
大規模なシステム開発では、クラス図の作成が不可欠です。
そうしないと、

全体像の理解が困難になり
システムエンジニアとプログラマーの連携に支障をきたす恐れがあります

さらに、クラス図はシーケンス図やアクティビティ図の基礎となる重要な設計資料でもあります。

システムの流れを視覚化するアクティビティ図

システムの動作プロセスや条件分岐を視覚化したものがアクティビティ図です。
システムの起動から終了までの一連の処理を順序立てて表現します。
アクティビティ図を作成することで、以下の利点があります。

システムの処理フローが明確になる
無駄な手順がないかを確認できる

シーケンス図の概要と利点

シーケンス図は、クラスやオブジェクトの相互作用を時系列で示す設計手法であり、詳細設計の代表的な方式の一つです。
単なる仕様書よりも、ロジックの流れを把握しやすいというメリットがありますが、作成に多大な労力を要するというデメリットもあります。
この図は開発時のみならず、運用・保守段階においても有用です。
システムに不具合が発生した場合、シーケンス図を参照することで、修正が必要な箇所を迅速に特定できます。