基本設計と詳細設計の違いは？仕事内容と設計書を具体例で比較

基本設計では、要件を満たすシステムの機能や構成を決めます。詳細設計では、その機能や構成を実装・構築できる粒度まで具体化します。違いを理解するときは、設計書の名前とあわせて「何を決め、誰に引き継ぐ仕事か」を見ると分かりやすくなります。

この記事は、仕事内容を理解するための編集記事です。以下の申請機能とインフラの例は説明用の想定例で、TECH4Uや顧客の実案件ではありません。

基本設計と詳細設計で決めること

たとえば大阪市のシステム開発ガイドラインでも、基本設計で要求を満たす機能を設計し、詳細設計で内部の仕様を具体化する整理が示されています。ただし、これは同市の開発プロセスです。設計書の分け方や各工程の担当範囲は、プロジェクトごとに確認してください。

出典：大阪市「情報システム開発ガイドライン」標準成果物・詳細設計（確認日：2026年9月27日）。

同じ申請機能で比べる具体例

「社員が経費を申請し、上長が承認する機能」を想定します。要件定義で確認するのは、誰が申請・承認するか、どの費用を対象にするか、どんな承認ルールが必要か、といった業務上の条件です。

基本設計：利用者の操作と業務の状態を決める

基本設計では、申請画面に日付・金額・用途を入力する欄を置き、確認画面を経て送信する流れを決めます。承認者の画面には、確認に必要な申請内容と承認・差し戻しの操作を用意します。

ここで「差し戻された申請を、申請者が修正して再提出できるか」が不明なら、業務担当者と確認が必要です。承認済みの申請を変更できるか、誰がどの申請を閲覧できるかも、利用者の仕事を左右する判断です。

成果物には、画面の項目、画面遷移、申請の状態と遷移条件などを記載します。画面の見た目だけを作れば終わる工程ではありません。

詳細設計：処理・データ・例外時の動きを決める

詳細設計では、送信時の入力検証、保存するデータ、状態を更新する条件を具体化します。金額の型や桁数、エラー時に返す内容、複数の更新をどこまで一括で扱うかなどを定めます。

たとえば、承認操作の直前に別の担当者が同じ申請を処理した場合、古い状態のまま上書きしない仕組みが必要です。どの状態なら更新できるか、更新できなかった場合に何を表示するかまで決めると、実装とテストに引き継げます。

実装方法を検討して業務ルールの不足が分かったときは、基本設計側へ確認を戻します。詳細設計の担当者が、未決定の承認ルールを独断で補うことは避けます。

インフラでは構成方針と設定内容を対応させる

インフラでも、基本設計と詳細設計の関係は「方針を決め、構築できる内容へ具体化する」と捉えられます。

たとえば、業務を継続するためにサーバーを冗長化する方針を決めたら、詳細設計では構成や切り替えに必要な設定を詰めます。監視する対象を決めたら、何を異常と判断し、誰に通知するかを設定内容と運用手順へ落とし込みます。

値を埋める際には、構成方針や運用条件との対応も確認します。既存の設定をコピーしただけでは、新しい環境の条件を満たすか判断できません。

「設計経験あり」を担当した判断まで説明する

職務経歴書には、工程名に加えて、自分が作成・変更した対象と判断した範囲を書きます。同じ基本設計への参加でも、議事録の作成、画面仕様の修正、業務担当者との仕様調整では経験が異なります。

以下は記入方法を示す想定例です。実際に担当した内容に置き換えてください。

経費申請機能の画面仕様を担当。既存の承認ルールと画面遷移を照合し、差し戻し後の再申請条件が未定義である点を整理した。リーダーを通じて業務担当者に確認し、決定内容を画面仕様書に反映した。承認ルールの最終決定は業務担当者が行った。

この書き方なら、担当した成果物、発見した問題、確認の進め方、決定権の範囲が分かります。レビューを受けて修正した経験も、そのように記載すれば説明できます。

TECH4Uのエンジニア向け採用情報では、案件を検討する際に担当工程や役割も確認します。設計へ担当を広げたい場合の準備は上流工程へ進む方法、運用経験からの進み方は運用保守から設計・構築へ進む方法で扱っています。