【今さら聞けない「設計」と「基本設計とは。」】目的や詳細設計との関係性を1から解説

システム開発や建築プロジェクトで頻繁に耳にする「基本設計」という言葉。その目的や、よく混同される「詳細設計」との違いを明確に説明できますか？本記事では、そもそも「設計」とは何かという基礎から、プロジェクトの成否を分ける「基本設計」の目的と重要性、そして要件定義や詳細設計との関係性までを、図や比較表を交えながら1から丁寧に解説します。結論として、基本設計とはユーザーの要望を形にするために「何を作るか」を定義する、いわばプロジェクトの骨格を決める最重要フェーズです。この工程の精度が、後の手戻りをなくし、プロジェクト全体の品質・コスト・納期を大きく左右します。新人エンジニアやプロジェクトマネージャーはもちろん、発注側の担当者の方も、この機会に設計プロセスの全体像を正しく理解しましょう。

そもそも設計とは何か

システム開発や建築、製品開発など、何か新しいものを創り出すプロジェクトにおいて、「設計」という言葉は必ず登場します。しかし、その意味を正確に説明できるでしょうか。この章では、後続の「基本設計」を理解するための土台として、「設計」という概念そのものについて、その定義や目的、重要性を掘り下げて解説します。

設計の定義：目的を達成するための計画

設計とは、一言でいえば「目的を達成するための具体的な計画を立て、それを図や文章などの形で可視化すること」です。家を建てる前に設計図を描くように、システムを開発する前にも、どのような機能を持たせ、どのような構造にするのかを詳細に計画する必要があります。この計画そのもの、あるいは計画を立てる行為全体が「設計」と呼ばれます。

設計は、単なるアイデアや構想を、実現可能な「仕様」へと落とし込むための重要なプロセスです。関係者全員が同じ完成イメージを共有し、効率的にプロジェクトを進めるための「共通言語」であり、「青写真」としての役割を担います。

設計の目的と重要性

なぜ、プロジェクトにおいて設計は不可欠なのでしょうか。その目的は多岐にわたりますが、主に以下の4つが挙げられます。

1. 関係者間の認識統一

プロジェクトには、顧客、開発者、デザイナー、管理者など、多くの人々が関わります。それぞれの立場によって、完成品に対するイメージや要求は異なる場合があります。設計書という客観的なドキュメントを作成することで、「何を作るのか」という共通認識を形成し、コミュニケーションの齟齬や誤解を防ぎます。

2. 品質・コスト・納期（QCD）の最適化

設計段階で課題やリスクを事前に洗い出すことで、開発途中の大規模な仕様変更や手戻りを最小限に抑えることができます。これは、プロジェクトの成功に不可欠な「品質（Quality）」「コスト（Cost）」「納期（Delivery）」、いわゆるQCDの最適化に直結します。しっかりとした設計は、無駄なコストや時間の浪費を防ぎ、最終的な成果物の品質を高めるための基盤となります。

3. 実現可能性の検証

頭の中にあるアイデアが、技術的・予算的に本当に実現可能かどうかを検証するのも設計の重要な目的です。要求された機能を実装するための技術的な課題はないか、予算内で収まるか、納期までに完成させられるかなどを、開発に着手する前に具体的に検討します。これにより、プロジェクトが途中で頓挫するリスクを低減できます。

4. 将来の拡張・保守性の確保

優れた設計は、完成した後のことまで見据えています。将来的な機能追加や仕様変更（拡張性）が容易にできるか、不具合が発生した際に原因究明や修正がしやすいか（保守性・メンテナンス性）を考慮して構造を計画します。目先の機能実現だけでなく、長期的な視点を持つことが、システムや製品の寿命を延ばす鍵となります。

様々な分野における「設計」の例

「設計」はIT分野の専門用語ではありません。私たちの身の回りにある多くのものが、それぞれの分野における設計プロセスを経て生み出されています。ここでは、代表的な分野における設計の例を比較してみましょう。

分野	設計対象	主な成果物	設計のゴール
IT（システム開発）	業務システム、Webアプリケーション、スマートフォンアプリなど	要件定義書、設計書（機能一覧、画面設計書、DB設計書など）	ユーザーの課題を解決し、要求された機能を安定して動作させること。
建築	住宅、ビル、橋、公共施設など	配置図、平面図、立面図、断面図、構造計算書など	安全性、快適性、デザイン性を満たし、法律や条例に準拠した建造物を建てること。
工業製品（自動車）	エンジン、ボディ、内装、電子制御システムなど	CAD図面、仕様書、部品表（BOM）、シミュレーションデータなど	性能、安全性、燃費、デザイン、生産コストなどの要件を高いレベルで両立させること。

このように、対象や成果物の形は違えど、「要求を整理し、具体的な形にするための計画を立てる」という設計の本質はどの分野でも共通しています。この普遍的な概念を理解することが、専門分野である「基本設計」を学ぶ上での第一歩となります。

基本設計とは 目的と重要性をわかりやすく解説

システム開発や建築など、何かをゼロから作り上げるプロジェクトにおいて、「基本設計」という言葉は頻繁に登場します。これは、プロジェクトの成功を左右する極めて重要な工程です。英語では「Basic Design（BD）」や「Architectural Design」などと表現され、プロジェクトの骨格を定める役割を担います。

では、具体的に基本設計とは何であり、どのような目的を持ち、なぜそれほどまでに重要視されるのでしょうか。この章では、基本設計の核心である「目的」と「重要性」について、初心者の方にも分かりやすく掘り下げて解説します。

基本設計の目的は「何を作るか」を決めること

基本設計の最大の目的は、「これから何を作るのか」というシステムの全体像を具体的に定義し、関係者全員で合意することです。前の工程である「要件定義」で集約されたクライアントやユーザーからの要望（「こんなことがしたい」「あんな機能が欲しい」）を、初めて具体的な「形」として目に見える仕様に落とし込む作業が基本設計です。

特に、ユーザーが直接触れる部分、いわゆる「外部設計」と呼ばれる領域を主に扱います。具体的には、以下のような項目を決定していきます。

• 機能要件の具体化: システムが持つべき機能（例：ユーザー登録機能、商品検索機能、決済機能など）を明確にします。
• 画面・UI（ユーザーインターフェース）の設計: ユーザーが操作する画面のレイアウト、ボタンの配置、表示項目などを決めます。いわば、システムの「見た目」と「操作感」の設計図です。
• 帳票の設計: システムが出力する請求書や報告書などの書類（帳票）のフォーマットを定義します。
• データフローの設計: ユーザーの操作によってデータがどのように流れ、処理されるかの大枠を定めます。
• 外部システムとの連携方式: 他のシステム（例：決済システム、物流システムなど）とどのようにデータをやり取りするかのルールを決めます。
• 非機能要件の定義: パフォーマンス（表示速度）、セキュリティ、可用性（システムが停止しないこと）など、機能面以外で満たすべき品質要件を定めます。

このように、基本設計は開発者やエンジニアのためだけのものではありません。むしろ、クライアントや発注者が「自分たちの要望が正しく形になっているか」を確認し、承認するための重要なコミュニケーションツールとしての役割を担っているのです。

なぜ基本設計が重要なのか

基本設計は、プロジェクト全体の土台となる工程です。この土台がしっかりしていなければ、その上にどれだけ精巧な建物を建てようとしても、いずれは傾き、崩れてしまいます。基本設計が重要である理由は、主に以下の4つに集約されます。

1. プロジェクトの手戻りを防ぎ、コストと時間を削減する

プロジェクトにおける最大の敵は「手戻り」です。もし基本設計が曖昧なまま後の工程（詳細設計やプログラミング）に進んでしまうと、「思っていた機能と違う」「この画面では業務が回らない」といった問題が後から発覚します。後の工程になればなるほど、修正にかかるコストと時間は雪だるま式に膨れ上がります。基本設計の段階で仕様を固めておくことは、プロジェクトを炎上させないための最も効果的なリスク管理なのです。

2. 関係者間の認識のズレをなくす

プロジェクトには、クライアント、プロジェクトマネージャー、デザイナー、エンジニアなど、様々な立場の関係者が関わります。それぞれの頭の中にある「完成イメージ」が異なっていては、プロジェクトは前に進みません。基本設計で作成される設計書は、全員が同じ完成イメージを共有するための「共通言語」であり、認識のズレをなくすための羅針盤となります。

3. 見積もりの精度を高める

「何を作るか」が具体的になることで、開発に必要な工数（時間）や人員、そしてコストをより正確に見積もることが可能になります。逆に、基本設計が不十分だと見積もりの根拠が曖昧になり、結果として予算超過や納期遅延を引き起こす原因となります。

4. プロダクトの品質を担保する

ユーザーにとってのシステムの品質は、使いやすさ（ユーザビリティ）や安定性によって大きく左右されます。基本設計の段階でユーザーの視点に立ったUI/UX設計を徹底し、セキュリティやパフォーマンスといった非機能要件をしっかり定義することが、最終的なプロダクトの品質を確保するための土台となります。

もし基本設計が不十分だった場合、プロジェクトは以下のような深刻なリスクに直面します。

リスクの種類	具体的な内容
手戻りの発生	後工程での大幅な仕様変更により、開発スケジュールが遅延し、追加コストが発生する。
認識の齟齬	完成したシステムがクライアントの要望と異なり、プロジェクトのやり直しや契約トラブルに発展する。
見積もりの失敗	予期せぬ追加作業が多発し、予算を大幅に超過する。最悪の場合、プロジェクトが頓挫する。
品質の低下	使いにくく、動作が不安定なシステムが完成し、ユーザーからのクレームや信頼の失墜につながる。

このように、基本設計は単なる設計工程の一つではなく、プロジェクトの成否そのものを決定づける生命線であると言えるでしょう。

開発プロセス全体における基本設計の位置づけ

システム開発やプロダクト開発において、基本設計は独立した工程ではありません。プロジェクト全体の流れ、すなわち開発プロセスの中で重要な役割を担っています。この章では、基本設計が開発プロセス全体の中でどのような位置づけにあり、前後の工程とどう連携するのかを具体的に解説します。

要件定義からリリースまでの流れ

システム開発のプロセスを理解するために、最も代表的な開発モデルである「ウォーターフォールモデル」を例に見ていきましょう。ウォーターフォールモデルは、水が上から下に流れるように、各工程を順番に進めていく手法です。基本設計がどの段階に位置するのかを把握することで、その役割がより明確になります。

工程	主な内容
企画	どのようなシステムを作るか、経営課題や事業戦略に基づいて大枠を構想します。
要件定義	顧客（発注者）の要望をヒアリングし、システムに実装すべき機能や性能などを明確に定義します。
基本設計（外部設計）	要件定義の内容をもとに、システムの基本的な仕様（画面、機能、操作方法など）をユーザー視点で設計します。
詳細設計（内部設計）	基本設計をもとに、プログラマーが実装できるように、システムの内部構造や処理ロジックなどを詳細に設計します。
実装（プログラミング）	詳細設計書に基づいて、プログラミング言語を用いて実際にシステムを構築していきます。
テスト	完成したシステムが設計通りに動作するか、不具合がないかなどを検証します。（単体テスト、結合テスト、システムテストなど）
リリース	テストをクリアしたシステムを本番環境に導入し、ユーザーが利用できる状態にします。
運用・保守	リリース後のシステムが安定稼働するように監視し、問題発生時の対応や機能改善などを行います。

このように、基本設計は「要件定義」と「詳細設計」の間に位置し、両者をつなぐ橋渡し役を担います。一般的に、要件定義から基本設計、詳細設計までを「上流工程」、実装からテストまでを「下流工程」と呼び、基本設計はプロジェクトの成功を左右する重要な上流工程の一つとされています。

基本設計と要件定義の関係

開発プロセスの中でも、特に「要件定義」と「基本設計」の関係性は密接であり、その違いを理解することが重要です。要件定義が「顧客の要望をまとめる」工程であるのに対し、基本設計は「その要望をシステムの仕様に落とし込む」最初の工程です。言い換えれば、要件定義書が基本設計のインプット（入力情報）となり、基本設計書が詳細設計へのアウトプット（出力情報）となります。

両者の違いをより明確にするために、以下の表で比較してみましょう。

比較項目	要件定義	基本設計
目的	顧客の要望や課題を整理し、システムで実現すべき「こと」（What）を定義する。	要件定義で決まった「こと」を、システムとして「どのように」（How）実現するかの概要を決定する。
主な視点	顧客・ユーザー視点、ビジネス視点	ユーザー視点と開発者視点の両方
担当者	プロジェクトマネージャー、ITコンサルタント、営業担当者など	システムエンジニア（SE）、プロジェクトリーダーなど
決定すること	・システムの目的とゴール ・必要な機能の一覧（機能要件） ・性能やセキュリティなどの要件（非機能要件）	・システムの全体構成 ・各機能の具体的な仕様 ・画面や帳票のレイアウト ・データベースの概要設計
主な成果物	要件定義書	基本設計書（機能一覧、画面設計書、DB設計書など）

要件定義が曖昧なまま基本設計に進むと、後工程で仕様の変更や手戻りが多発し、プロジェクトの遅延やコスト増大の原因となります。したがって、要件定義の内容を正確に理解し、それを過不足なくシステムの基本仕様として定義することが、基本設計の重要な責務と言えるでしょう。

基本設計と詳細設計の明確な違い

システム開発やソフトウェア開発のプロセスにおいて、「基本設計」と「詳細設計」は非常によく似た言葉ですが、その目的、対象者、そして作成するドキュメントの粒度は全く異なります。この違いを理解することは、プロジェクトを円滑に進める上で不可欠です。

一般的に、基本設計は「外部設計」、詳細設計は「内部設計」とも呼ばれます。この章では、「誰のために作るか」「何をどこまで決めるか」という2つの視点から、両者の違いを明確に解説していきます。

誰のために作るかという視点の違い

基本設計と詳細設計の最も大きな違いは、その設計書を「誰が読むのか」という対象者の違いにあります。成果物が誰に向けたものかによって、記述すべき内容や表現方法が大きく変わってきます。

基本設計（外部設計）は、主にクライアント（発注者）やプロジェクトマネージャー、そして実際にシステムを利用するユーザーのために作成されます。
そのため、ITやプログラミングの専門知識がない人でも、システム全体の仕様を理解できることが重要です。要件定義で決定した「何を実現したいか」という要望に対し、「どのような機能や画面で実現するのか」を具体的に示し、クライアントと開発者間の認識を合わせるためのコミュニケーションツールとしての役割を担います。ユーザーの目に触れる部分、いわゆるユーザーインターフェース（UI）や操作性（UX）に関する仕様が中心となります。

一方、詳細設計（内部設計）は、プログラマーや開発エンジニアのために作成されます。
こちらは、基本設計で定められた機能を実際にプログラミング（実装）するための、いわば「開発者向けの指示書」です。専門用語や技術的な記述が中心となり、どのようにコーディングすればよいかが具体的にわかるレベルまで、機能や処理を細かく分解して記述します。ユーザーの目には直接触れない、システムの内部構造に関する仕様が中心となります。

何をどこまで決めるかという粒度の違い

設計の対象者が異なるため、当然ながら設計で決める内容の細かさ（粒度）も大きく異なります。家づくりに例えるなら、基本設計が「間取りや外観、窓の大きさ」を決めるのに対し、詳細設計は「柱の材質や太さ、電気配線の引き方、コンセントの位置」などを決めるイメージです。

基本設計では、システムをユーザー視点で捉え、全体的な機能や画面構成などを決定します。
具体的には、以下のような項目を定義します。

• システムの全機能の一覧と概要
• 画面のデザイン、レイアウト、項目、画面間の遷移
• 帳票（印刷物）のレイアウトや出力項目
• システムが扱うデータの概要（論理データモデル）
• 使用するOS、ミドルウェア、ハードウェアなどの動作環境
• セキュリティや性能といった非機能要件の実現方針
• 外部システムとの連携方法

一方、詳細設計では、基本設計の内容を開発者視点で分解し、プログラミングが可能になるレベルまで具体化します。
基本設計で定義された一つひとつの機能に対して、以下のような内部仕様を詳細に決定していきます。

• 機能を構成するプログラム（モジュール）の構成と処理内容
• クラスやメソッド（関数）の仕様（引数、戻り値など）
• 具体的な処理フローやアルゴリズム
• データベースの物理設計（テーブル名、カラム名、データ型、インデックスなど）
• 詳細なエラーハンドリング（異常系処理）の方法

比較表で見る基本設計と詳細設計

これまでの内容をまとめると、基本設計と詳細設計の違いは以下の表のようになります。両者の役割と目的を正確に把握し、それぞれのフェーズで適切な成果物を作成することが、プロジェクト成功の鍵となります。

比較項目	基本設計（外部設計）	詳細設計（内部設計）
目的	要件定義の内容をシステムの機能・仕様に落とし込み、クライアントと合意形成する	基本設計で定義された機能を、プログラミング可能なレベルまで具体化する
主な対象者	クライアント、プロジェクトマネージャー、ユーザー	プログラマー、開発エンジニア
視点	ユーザー視点（システムがどう見えるか、どう使えるか）	開発者視点（システムをどう作るか、どう動かすか）
決定事項の粒度	粗い（システム全体の構成、画面や機能の概要）	細かい（個々のプログラムの処理、クラスや変数の定義）
主な成果物	機能一覧、画面設計書、帳票設計書、論理データベース設計書など	クラス図、シーケンス図、モジュール設計書、物理データベース設計書など

基本設計で作成する主な成果物

基本設計は、要件定義で決定した「何を作るべきか」という抽象的な要求を、具体的な形に落とし込む最初のステップです。このフェーズでは、クライアントと開発者の間で認識の齟齬が生まれないよう、システムの全体像や仕様を明確にするための様々なドキュメント（成果物）が作成されます。成果物の種類は、システム開発や建築といったプロジェクトの性質によって異なりますが、いずれも後続の詳細設計や開発・施工工程の基盤となる重要な役割を担います。

ここでは、代表的な分野として「システム開発」と「建築」における基本設計の主な成果物について、それぞれ具体的に解説します。

システム開発における成果物の例

システム開発における基本設計では、主にユーザーの目に触れる部分や、システムの外部から見た振る舞いを定義します。クライアントがシステムの完成イメージを具体的に掴めるように、専門用語を避けつつも、仕様を正確に伝えるためのドキュメントが中心となります。

機能一覧

機能一覧は、開発するシステムが持つべき機能をすべてリストアップし、その概要を整理したドキュメントです。要件定義で洗い出された要求を、実装すべき「機能」という単位に分解・整理し、プロジェクトの全体像と作業範囲（スコープ）を明確にします。この一覧をもとに、開発の優先順位付けや進捗管理が行われます。

項目名	説明
機能ID	各機能を一意に識別するための番号。
機能名	機能の内容が簡潔にわかる名前（例：ユーザー登録機能、商品検索機能）。
機能概要	その機能が「何をするためのものか」を具体的に説明した文章。
担当部署・担当者	その機能の仕様に責任を持つ部署や担当者。
優先度	開発の優先順位（高・中・低など）。
備考	関連する機能や特記事項などを記載。

画面設計書

画面設計書は、ユーザーが直接操作する画面のレイアウトやデザイン、動作を定義する重要な成果物です。UI（ユーザーインターフェース）設計の中核を担い、システムの使いやすさ（ユーザビリティ）を大きく左右します。ワイヤーフレームと呼ばれる骨組み図を用いて、どの画面にどのような情報（項目、ボタン、テキストなど）を配置し、ボタンをクリックしたらどの画面に移動するのか（画面遷移）といった、具体的なイメージを固めていきます。これにより、クライアントは早い段階で完成形を視覚的に確認でき、「思っていたものと違う」といった後工程での手戻りを防ぐことができます。

帳票設計書

帳票設計書は、システムから出力される請求書、納品書、領収書、各種レポートといった印刷物やPDFファイルのレイアウトを定義するドキュメントです。どのようなデータを、どのような形式・デザインで出力するのかを詳細に決定します。記載する項目、そのデータの取得元、計算式、ヘッダーやフッター、会社ロゴの配置などを定義します。特に、法律で書式が定められている公的な書類や、企業のブランドイメージに関わる書類を扱う場合に極めて重要となります。

データベース設計書

データベース設計書は、システムが扱う様々なデータ（顧客情報、商品情報、売上データなど）を、どのように整理して保存するかを定義するドキュメントです。システムの根幹を支える設計であり、システムのパフォーマンスや拡張性に直接的な影響を与えます。基本設計の段階では、主に「論理設計」と呼ばれる、システムの要件に基づいたデータの構造や関連性を定義します。代表的な成果物には、データのまとまり（エンティティ）とそれらの関連性を視覚的に表現した「ER図」や、各データ（テーブル）が持つ項目（カラム）の詳細を定義した「テーブル定義書」などがあります。

建築における成果物の例

建築分野における基本設計は、施主（クライアント）の要望やライフスタイル、予算といった条件を基に、建物の基本的な骨格やデザインを決定するプロセスです。建築基準法などの法的な規制を遵守しつつ、コンセプトを具体的な図面に落とし込んでいきます。この段階で作成される図面は「基本設計図書」と呼ばれ、施主との合意形成や、行政への建築確認申請の際に必要となります。

配置図・平面図

配置図と平面図は、建物の基本的な構成を理解するための最も重要な図面です。

• 配置図：敷地全体を真上から見て、その敷地に対して建物がどのように配置されるかを示した図です。道路との位置関係、方位、隣地境界線からの距離、門や塀、庭、駐車スペースの位置などが描かれ、周辺環境との調和や法規制（建ぺい率、容積率など）への適合を確認します。
• 平面図：一般的に「間取り図」として知られているもので、建物の各階を床から一定の高さで水平に切断し、真上から見た図です。部屋の配置や広さ、壁の位置、柱、ドアや窓の種類と開閉方向、キッチンや浴室などの設備、収納の位置などが詳細に描かれます。住む人の生活動線や快適性を決定づける、設計の核となる図面です。

立面図・断面図

立面図と断面図は、建物を立体的に理解するために不可欠な図面です。

• 立面図：建物を外側から、東西南北の各方向から見た「外観図」です。建物の全体の高さやプロポーション、屋根の形状や勾配、窓やバルコニーの配置、外壁の素材感など、建物のデザインが表現されます。街並みとの調和や外観の美しさを確認するために用いられます。
• 断面図：建物を指定した位置で垂直に切断し、その断面を横から見た図です。平面図だけではわからない各階の天井の高さ、床や壁の厚み、基礎の構造、階段の寸法、屋根裏の空間などを確認することができます。建物の内部構造や立体的な空間構成を把握し、構造上の安全性や断熱性などを検討するために重要な役割を果たします。

まとめ

本記事では、「設計」の基本的な考え方から、プロジェクトの成功を左右する「基本設計」について、その目的、重要性、そして詳細設計との関係性を解説しました。基本設計とは、要件定義で定められた要求を基に、「何を作るか」というシステムや建築物の全体像と外部仕様を決定する、プロジェクトの土台となる工程です。

基本設計が重要である結論は、この段階で発注者と開発者の間で「完成形」のイメージを完全に共有し、合意を形成する必要があるためです。ここでの認識のズレや仕様の曖昧さは、後の詳細設計や開発・構築の工程で大きな手戻りを生み、コストの増大や納期の遅延といったプロジェクト失敗の直接的な原因となります。

基本設計と詳細設計の明確な違いは、「誰のために（視点）」と「何をどこまで決めるか（粒度）」にあります。基本設計がユーザー（発注者）視点でシステムの振る舞いを決めるのに対し、詳細設計は開発者・制作者視点でその実現方法を具体的に記述します。この役割分担を理解することが、両工程をスムーズに進める鍵となります。

円滑なプロジェクト進行のためには、関係者全員が基本設計の目的と重要性を正しく理解し、綿密なコミュニケーションを通じて認識を合わせることが不可欠です。この記事が、あなたのプロジェクトにおける設計工程の理解を深める一助となれば幸いです。