基本設計（外部設計）とは？意味・決める内容と進め方

基本設計（外部設計）とは

基本設計とは、要件定義で合意した「何を実現するか」を、システムの外側から見える形に落とし込む設計工程です。外部設計とも呼ばれます。

平易に言えば、「どんな画面があり、どんな項目を入力し、どんな帳票やデータが出てきて、他のどのシステムとつながるのか」を決める作業です。システムの中身がどう動くかよりも、使う人や連携先から見たときの姿を決めるのが特徴です。

「外部」とは利用者や外部システムとの接点を指します。これに対して、プログラム内部の構造を決める工程を詳細設計（内部設計）と呼び、両者を合わせて設計工程と呼ぶのが一般的です。英語ではBasic Design（BD）と略されることもあります。

基本設計の成果物は「基本設計書」と呼ばれ、複数の資料の集合として作られます。プロジェクトの規模によって粒度は変わりますが、おおむね次の項目を扱います。

この段階で重要なのは、発注側が「見て判断できる」状態まで具体化することです。要件定義書では「顧客情報を管理できる」としか書かれていなかった内容が、基本設計では「顧客一覧画面で会社名・担当者・最終接触日を表示し、絞り込みは担当者と地域で行う」という粒度になります。

たとえば、ある小売企業が店舗ごとの在庫を本部で一元管理するシステムを外注する場面を考えます。要件定義で「各店舗の在庫を本部でリアルタイムに把握する」と合意したとします。基本設計では、次のような点を一つずつ決めていきます。

この過程で「理由区分は現場でどこまで細かく選べるか」「本部は全店舗を一度に見たいのか、エリア別に見たいのか」といった、要件定義では見えていなかった論点が必ず出てきます。基本設計のレビュー会で現場担当者に画面イメージを見てもらうと、この種の食い違いを開発前に発見できます。

発注側にとって基本設計は、「作られるものを確認できる最後の大きな機会」です。ここで合意した内容が開発の前提になり、以降の変更は追加費用や納期の延長につながりやすくなります。

「基本設計は開発会社の仕事なので任せればよい」という誤解。 作成するのは開発会社でも、内容を判断できるのは業務を知る発注側だけです。レビューの時間を確保せず承認すると、リリース直前に「使えない」と分かる事態になりがちです。

画面の見た目だけを確認してしまう。 レイアウトに目が行きがちですが、本当に確認すべきは入力項目の過不足、エラー時の挙動、権限による表示の違いです。正常な操作だけでなく「間違えたらどうなるか」を質問すると、設計の甘さが見つかります。

要件定義と基本設計の境界があいまいになる。 基本設計の途中で新しい機能を追加し始めると、見積もりの前提が崩れます。新しい要望は一覧に記録し、今回の範囲に入れるかどうかを別途判断する運用にしておくと安全です。

アジャイル開発では不要という誤解。 アジャイル開発でも、画面や連携の仕様を決める作業はなくなりません。分厚い設計書を最初に作り込まない代わりに、機能単位で短く設計して確認するやり方に変わるだけです。

Otsumuは、要件定義から基本設計・開発・運用まで一気通貫で支援しています。目的から逆算して必要な画面と機能に絞り込み、発注側が判断しやすい粒度で設計内容を示すことを重視しています。「設計書を受け取ったが妥当か判断できない」「設計段階で手戻りが続いている」といった状況にも対応できます。

開発の全体像はシステム開発のページで紹介しています。進め方に迷ったら30分の無料相談でお気軽にご相談ください。

執筆：Otsumu株式会社／編集日 2026.10.01