基本設計書とは？システム開発で役立つ設計書の作り方と実務ポイント

公開日：2026/01/19 更新日：2026/01/19

Web開発

基本設計書とは？システム開発で役立つ設計書の作り方と実務ポイント

公開日：2026/01/19 更新日：2026/01/19

Web開発

初めに

システム開発の成功には、要件定義だけでなく「基本設計書」の正しい作成が欠かせません。基本設計書は要件定義と詳細設計の橋渡しとして、仕様を開発チームに正確に伝える重要な文書です。しかし「書き方がわからない」「項目をどう整理すればよいかわからない」と悩む開発者は少なくありません。本記事では、基本設計書の目的、作成手順、具体的な項目例や実務での注意点まで、初めて作成する方でも理解できるように徹底解説します。

基本設計書とは

役割と目的

基本設計書は、システム開発プロジェクトにおいて要件をシステム仕様に落とし込み、後工程（詳細設計・実装・テスト）へ正しく引き渡すための設計文書です。要件定義書で整理されたユーザー要求や業務要件を、開発チームが具体的に実装可能な形に落とし込む役割を持っています。
主な目的は以下の通りです。

要件定義と詳細設計の橋渡し
要件定義書には抽象的な表現が多く、開発者がそのまま実装することは困難です。基本設計書では、画面構成、機能仕様、データ設計などを具体化し、詳細設計書にスムーズに引き渡せる形に整えます。
関係者間の認識統一
開発者だけでなく、プロジェクトマネージャー（PM）、テスト担当者、運用担当者など複数の関係者が関わる場合、仕様の齟齬は大きなリスクになります。基本設計書を用いることで、誰が見ても同じ理解になるよう情報を整理でき、レビューや承認プロセスも円滑に進められます。
開発効率と品質の向上
あらかじめ機能やデータの設計を整理することで、開発途中の仕様変更や手戻りを減らすことができます。結果として、開発効率を上げ、品質の高いシステムを納期内に提供できるようになります。
利害関係者別のメリット
開発者：実装の迷いを減らせる
PM：スケジュール管理が容易
QA：テスト設計がスムーズ
運用担当者：運用・保守時に参照可能

要件定義との違い

基本設計書は要件定義書と混同されやすいですが、両者には明確な違いがあります。

要件定義書
ユーザーやクライアントの要求や業務上の要望を整理した文書で、抽象的な表現が多いのが特徴です。何を実現するかの「WHAT」を中心に記載します。
基本設計書
要件定義をもとに、システムとしての仕様（画面・機能・データ・外部連携・非機能の方針など）を整理し、後工程に引き渡す文書です。現場によっては「WHAT＋HOWの概要」を扱い、詳細なHOW（実装レベル）は詳細設計で扱うこともあります。

この違いを理解せずに作業を進めると、開発途中での手戻りが発生しやすく、プロジェクト全体の効率が落ちてしまいます。

開発プロセスにおける位置付け

基本設計書は、システム開発プロセスの中で「要件定義の次、詳細設計の前」に作成されます。典型的な開発工程は以下のように整理できます。

要件定義フェーズ
ユーザー要求を整理し、システムで実現すべき内容を明確化。
基本設計フェーズ
要件定義を基に画面設計、機能設計、データベース設計などを行い、詳細設計書に引き渡せる形で文書化。
詳細設計フェーズ
プログラム単位での設計、API設計、UIの詳細仕様などを決定。

この位置付けを意識することで、基本設計書が単なる書類ではなく、開発全体の指針として機能することが理解できます。

基本設計書の必須項目

システム構成概要

システム全体の構成を示す概要図や説明は、基本設計書の冒頭に記載されます。主な内容は以下です。

システム全体のアーキテクチャ図
サーバ構成、ネットワーク構成
利用する主要ソフトウェアやフレームワーク
外部システムとの連携概要

これらを明確にしておくことで、開発者だけでなく運用やテスト担当者も全体像を把握しやすくなります。

機能一覧・画面設計

機能一覧では、システムが提供する機能を整理し、画面設計では各画面の構成や操作フローを具体化します。

機能一覧
各機能の名称、目的、関連画面、担当者や処理フローを一覧化。
画面設計
画面レイアウト、入力項目、ボタン配置、表示内容などを図解や表で整理。

この段階でユーザー操作とシステム動作の関係を明確にしておくことが、詳細設計や実装での手戻り防止につながります。

データベース設計

データベース設計は、システムの機能を支える重要な項目です。

テーブル定義：名称、カラム、型、制約条件
ER図：テーブル間の関係性を視覚化
初期データや制約条件：参照制約、ユニーク制約など

データ設計を基本設計書で整理しておくことで、後続の詳細設計やプログラム実装がスムーズになります。

作成手順とポイント

情報整理の流れ

基本設計書を作成する際は、情報を整理する順序を意識することが重要です。

要件定義書の内容確認
ユーザー要望、業務フロー、制約条件を再確認。
システム全体像の整理
構成図やアーキテクチャを作成し、担当者間で共有。
機能・画面・データの詳細化
機能ごとに画面やデータの設計を具体化。
レビューと修正
開発チームや関係者とレビューを行い、不明点や齟齬を修正。

この順序で整理することで、抜け漏れや認識違いを防ぎ、後工程の詳細設計・実装にスムーズに引き渡せます。

記入の注意点

基本設計書の作成では、以下のポイントに注意します。

抽象的な表現を避ける：誰が読んでも理解できるよう具体的に記載
関係者が参照しやすい形式：表や図を活用して視覚的に整理
変更履歴の管理：修正箇所を明確にしてトレーサビリティを確保
レビュー対応の明記：承認プロセスや責任者を明確化

これらの注意点を押さえることで、作成後の混乱や手戻りを最小限に抑えることができます。

レビュー・承認プロセス

基本設計書は、作成して終わりではなく、レビューと承認のプロセスを経ることで初めて実務で機能します。具体的な流れは以下の通りです。

内部レビュー
開発チーム内で設計内容の妥当性や抜け漏れを確認します。画面設計やデータベース設計に不整合がないか、開発者目線でチェックすることが重要です。
関係者レビュー
プロジェクトマネージャー、QA担当者、運用担当者など、関係者にレビューを依頼します。異なる視点からの指摘を受けることで、後工程でのトラブルを減らせます。
承認プロセス
レビューで指摘された修正を反映後、最終的にプロジェクト責任者やクライアントに承認してもらいます。承認された文書は公式な基準資料として扱われ、以降の詳細設計・開発の指針になります。

レビューと承認をしっかり行うことで、設計内容の信頼性を高め、開発途中の手戻りを最小化できます。