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

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

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

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

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

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

要件定義から実装まで、何を考えて何を残すか

要件定義・基本設計では、目的や制約を確認し、実現する範囲を決める必要があります。

要件定義や基本設計の工程では、考える軸は Why と What です（代表のXの投稿より）

ここからは編集上の整理として、Whyを「なぜ必要か・どんな条件を守るか」、Whatを「何を実現するか」、Howを「どう実現するか」として、同じ経費申請機能に当てはめます。工程ごとに完全に分離する意味ではなく、詳細設計中も目的や制約との整合を確認します。

要件から設計、設計から実装へ引き継ぐ際は、前工程で決まっていないことも共有します。設計書の名前がそろっていても、業務上の未決事項が残ったままでは、実装担当者が推測で決めることになります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

設計書の作成・修正・レビュー・決定を分ける

同じ設計書に関わっても、指定された内容を記入したのか、案を検討したのか、承認したのかで担当責任は異なります。プロジェクトの体制に合わせて、誰が何を担当したかを確認します。

たとえば差し戻し後の再申請を認めるかは、業務のルールです。詳細設計中に不足が分かったら、基本設計の担当者・リーダーへ共有し、業務ルールを決める担当者に判断を依頼します。承認結果は要件、画面、内部処理の関連箇所へ反映します。設定値だけの変更か、業務や可用性の条件まで変わるかで、確認先も変わります。

インフラでも、通知先の登録修正と、夜間対応を不要にする運用変更では判断する範囲が異なります。後者なら、監視設定だけを変えず、業務・運用の責任者に対応方針を確認します。

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

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

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

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

入った後ちゃんと成果出す覚悟あんの？（代表のXの投稿より）

設計書を参照して設定した仕事は、その担当範囲を正確に記載してください。

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

書類全体への整理は職務経歴書の書き方、構成・設定の担当範囲はインフラの職務経歴書で確認できます。

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