基本設計と詳細設計。
名前だけを見ると、
「基本設計は大まかに決めるもの」
「詳細設計は細かく決めるもの」
という違いに見えるかもしれません。
私もSEとして両方の設計を経験しましたが、実務で感じた違いは、単純な「大まか・細かい」だけではありませんでした。
私の場合、基本設計では顧客にも分かる言い回しを意識し、業務フローなどを使ってシステムの仕様を整理していました。
一方、詳細設計では、実際に実装できるように内部の情報や設定値まで具体化していきます。
そのため、私自身の感覚では、
難しさは基本設計。
作業量は詳細設計。
という違いがありました。
この記事では、基本設計と詳細設計の違いについて、元アプリSEとして実際に設計を行った経験から説明します。
なお、「基本設計」「詳細設計」という工程の分け方や、それぞれに何を書くかは、会社やプロジェクトによって異なります。
この記事で紹介する内容も、「すべての開発現場で必ずこうなる」という意味ではなく、私が経験した業務システム開発での考え方をベースにしています。
基本設計と詳細設計の違いを簡単に整理
私の実務経験をもとに整理すると、基本設計と詳細設計には次のような違いがありました。
| 基本設計 | 詳細設計 | |
|---|---|---|
| 主な役割 | システムの仕様を具体化する | 実装できるレベルまで内部仕様を具体化する |
| 私が意識したこと | 顧客にも分かる表現にする | 実装に必要な情報まで落とし込む |
| 記載した内容の例 | 業務フローなど | 内部情報や設定値など |
| 実務での印象 | 難しかった | 作業量が多かった |
この表だけを見ると、基本設計と詳細設計はきれいに分かれているように見えます。
ただ、実際の現場では必ずしもそうではありませんでした。
私が経験した案件でも、基本設計の中に詳細設計寄りの内容が入ることがありました。
IPAの「共通フレーム2013」でも、開発作業を工程へ当てはめた図について、工程と作業の対応は一例であり、その工程区分を推奨するものではないとされています。
そのため、「これは基本設計だから絶対にここまで」「ここから先は必ず詳細設計」と考えるより、プロジェクトごとの設計ルールを確認することが大切だと思います。
基本設計では「顧客にも分かること」を意識していた
私が基本設計を行うときに意識していたのが、顧客にも分かる言い回しにすることでした。
私が扱っていた基本設計書は、開発者だけでなく、顧客が確認することも意識して作成していました。
そのため、技術者にしか分からない表現だけで書くのではなく、「このシステムで何ができるのか」「業務がどのように流れるのか」が伝わるようにする必要があります。
私が作成していた基本設計では、業務フローも記載していました。
単にシステムの機能を並べるだけではなく、業務の中でそれぞれの処理がどうつながっているのかを整理して見せるためです。
ここが、後で説明する詳細設計との大きな違いだと感じていました。
詳細設計では「実装できるところまで」具体化していた
詳細設計では、基本設計で決めた内容を、実際に実装できるレベルまで具体化していきます。
IPAの「システムアーキテクト試験（レベル4）シラバス Ver.5.2」では、「ソフトウェア詳細設計」の項目で、ソフトウェアコンポーネントを、コーディング・コンパイル・テストができるソフトウェアユニットを含む下位レベルまで詳細化することが示されています。
私が詳細設計を行っていたときは、内部の情報や設定値なども設計書へ落とし込んでいました。
基本設計では顧客にも理解できる表現を意識していましたが、詳細設計になると、実際に作る側が必要とする情報が増えていきます。
そのため、私の感覚では、
「基本設計をさらに細かく書く」
というより、
「基本設計で決めた内容を、実装できる状態まで具体化する」
と考えた方が分かりやすいです。
もちろん、どこまで詳細設計書へ記載するかはプロジェクトによって異なります。
ただ、少なくとも私が経験した現場では、詳細設計は実装へつなげるための設計という位置付けでした。
実務では基本設計と詳細設計の境界がきれいに分かれないこともあった
基本設計と詳細設計について調べると、それぞれの役割がきれいに分かれて説明されていることがあります。
しかし、私が実際に仕事をしていたときは、そこまで単純ではありませんでした。
基本設計の中にも、詳細設計に近い内容が入ることがありました。
だからといって、それが間違いというわけでもありません。
会社やプロジェクトによって設計書の構成や粒度が違えば、「どの工程でどこまで決めるのか」も変わります。
そのため、新しいプロジェクトへ入ったときに「基本設計という名前だから、自分が以前作った基本設計と同じだろう」と決めつけるのは避けた方がよいと思います。
同じ「基本設計書」という名前でも、中に求められている情報まで同じとは限らないからです。
私は基本設計の方が難しいと感じていた
基本設計と詳細設計のどちらが難しいかは、担当するシステムや本人の経験によって変わると思います。
私の場合は、基本設計の方が難しいと感じていました。
基本設計では、システムとして必要な内容を整理するだけでなく、それを顧客にも伝わる形にする必要があったからです。
自分では分かっている内容でも、それをそのまま書けば相手にも伝わるとは限りません。
業務フローを含め、どのように整理して説明すれば理解してもらえるのかを考える必要があります。
詳細設計は内部の情報を細かく決めていく大変さがありますが、基本設計には「何を書くか」だけでなく「どう伝えるか」という難しさもありました。
これが、私が基本設計の方を難しいと感じていた大きな理由です。
一方で作業量は詳細設計の方が多かった
難しさでは基本設計の方が上だと感じていましたが、作業量については詳細設計の方が多い印象でした。
詳細設計では、実装できるレベルまで情報を具体化していきます。
内部の情報や設定値など、基本設計より細かな内容を決めて記載する必要があるため、設計書へ書き込む情報も増えていきました。
そのため、私の経験を一言で整理すると、
難しさは基本設計。
作業量は詳細設計。
という感覚になります。
もちろん、これはどの現場でも同じという意味ではありません。
あくまで、私自身が業務システム開発で基本設計と詳細設計を経験したときの印象です。
「基本＝大まか、詳細＝細かい」だけでは分かりにくい
基本設計と詳細設計という名前から、
基本設計＝大まかな設計
詳細設計＝細かな設計
と覚えることはできます。
ただ、これだけでは実務での違いを理解しにくいと思います。
私の経験から初心者向けに整理するなら、
基本設計は、要件定義で決めた内容を、システムの仕様として顧客にも伝わる形で具体化する。
詳細設計は、それを実際に実装できるところまで内部的に具体化する。
と考えると分かりやすいです。
そして、どこまでを基本設計と呼び、どこからを詳細設計と呼ぶかは、会社やプロジェクトによって違うことがあります。
用語の定義だけを覚えるより、「その設計書は誰が読み、次の工程で何に使うのか」を考えた方が、実際の役割を理解しやすいと思います。
まとめ：基本設計と詳細設計は「誰が読み、何に使うか」で考えると分かりやすい
基本設計と詳細設計は、単純に「大まかな設計」と「細かな設計」という違いだけではありません。
私が実務で基本設計を行うときは、顧客にも分かる表現を意識し、業務フローなどを使ってシステムの仕様を整理していました。
詳細設計では、実装するために必要な内部情報や設定値まで具体化していました。
私自身の経験では、難しかったのは基本設計で、作業量が多かったのは詳細設計です。
ただし、基本設計と詳細設計の境界は、すべての開発現場で同じではありません。
これから設計に関わるのであれば、「基本設計とはこういうもの」と名前だけで判断せず、そのプロジェクトで誰が設計書を読み、どこまでの情報が求められているのかを確認することが大切だと思います。
