基本設計書とは？書き方・記載項目・要件定義書や詳細設計書との違いを解説！

システム開発をしていると、「基本設計書を作成してください」と言われることがあります。

しかし、いざ基本設計書を書こうとすると、

• そもそも基本設計書って何？
• 要件定義書や機能仕様書・詳細設計書とは何が違うのか？
• 基本設計書には何を書けばいいの？
• 画面設計だけを書けばいいの？
• プログラムの内部処理まで書く必要があるの？

と疑問に思うこともあるでしょう。

この記事では、基本設計書とは何なのか、基本的な役割や主な記載項目、具体的な書き方についてわかりやすく解説します。

基本設計書とは？

基本設計書とは、簡単にいうと、要件定義で決めた内容を、画面・データ・外部インターフェース・システム構成など、システムとして実現できる形まで具体化し、その設計内容をまとめた資料です。

基本設計は「外部設計」と呼ばれることもあります。

例えば、Webサービスに「ユーザー登録機能」があるとします。

要件定義で、

ユーザーがWebサービスのアカウントを作成できること。

と決められていたとします。

これを基本設計では、

• ユーザー登録画面を用意する
• 氏名・メールアドレス・パスワードの入力欄を配置する
• 登録ボタンを配置する
• メールアドレスは必須入力とする
• 入力エラーがある場合は対象項目の近くにメッセージを表示する
• 登録に成功した場合は登録完了画面へ遷移する
• 登録後に確認メールを送信する

といった形まで具体化していきます。

一方、

• UserServiceクラスを作る
• register()メソッドを作る
• ControllerからServiceを呼び出す
• データベースへの登録・更新処理をどのように実装するか決める
• 例外をどのクラスで処理するか決める

といった、プログラム内部をどのように実装するかについては、一般的には詳細設計で扱います。

つまり、基本設計では「システムをどのような形にするか」、詳細設計では「その仕組みをプログラム内部でどのように実装するか」を考えると分かりやすいでしょう。

基本設計書は何のために作る？

基本設計書を作る大きな目的は、要件を実際に開発できるレベルまで具体化し、関係者の認識を合わせることです。

例えば、

ユーザーを登録できるようにする。

という要件だけでは、実装するための情報が不足しています。

実際に開発するには、

• どの画面から登録するのか
• 何を入力するのか
• どの項目が必須なのか
• 何文字まで入力できるのか
• 登録ボタンを押したあとどうなるのか
• エラーはどこに表示するのか
• 登録完了後はどこへ移動するのか

といった内容を決める必要があります。

基本設計書は、具体的には次のような目的で利用されます。

• 要件をシステムとして実現できる形まで具体化する
• 発注者や開発者など、関係者間の認識を合わせる
• 詳細設計や実装の基礎資料にする
• テストケースを作成するときの基準にする
• 仕様変更や機能追加の際の確認資料にする
• システム全体の構成を関係者で共有する

つまり、基本設計書は要件定義と詳細設計・実装をつなぐ設計資料と考えると分かりやすいでしょう。

要件定義書・機能仕様書・基本設計書・詳細設計書の違い

基本設計書について理解するときは、要件定義書・機能仕様書・詳細設計書との違いを知っておくと分かりやすくなります。

それぞれの役割を大まかに分けると、次のようになります。

要件定義書

要件定義書では、システムを作る目的や、システムで実現したいことを整理します。

例えば、会員制のWebサービスであれば、「ユーザーがWebサービスのアカウントを作成できること」といった内容です。

この段階では、「入力欄をどこに配置するか」「登録後にどの画面へ遷移するか」といった細かな設計までは決めない場合が一般的です。

機能仕様書

機能仕様書では、要件定義で決めた内容をもとに、システムが具体的に何をするのかを定義します。

例えば、ユーザー登録機能であれば、

• 氏名・メールアドレス・パスワードを入力できる
• メールアドレスは必須である
• 登録済みのメールアドレスでは登録できない
• 登録に成功すると完了画面を表示する

といった、システムの機能や振る舞いを定義します。

基本設計書

基本設計書では、要件や機能仕様を実現するために、システムをどのような形にするのかを設計します。

例えば、ユーザー登録機能であれば、

• ユーザー登録画面を作る
• 氏名・メールアドレス・パスワードの入力欄を配置する
• 登録ボタンを配置する
• エラーメッセージは入力欄の下に表示する
• 登録成功後は登録完了画面へ遷移する
• ユーザー情報としてどのようなデータを保持するかを定義する

といった内容です。

詳細設計書

詳細設計書では、基本設計をもとに、プログラム内部でどのように実装するのかを具体化します。

例えば、以下のような内容です。

• どのクラスを作成するか
• どのメソッドで処理するか
• 各処理をどのような順序で実行するか
• データをどのように読み書きするか
• SQLやデータアクセス処理をどのように実現するか
• API内部でどのような処理を行うか
• 例外をどのように処理するか

基本設計はいつ行う？

一般的なウォーターフォール型の開発では、基本設計は要件定義のあと、詳細設計の前に行います。

例えば、次のような流れです（一例です）。

企画
↓
要件定義
↓
基本設計
↓
詳細設計
↓
実装
↓
テスト
↓
リリース

機能仕様書を独立した成果物として作成するプロジェクトでは、次のように整理する場合もあります。なお、機能仕様という独立した工程を設けず、基本設計の中で機能仕様を整理するプロジェクトもあります。

企画
↓
要件定義
↓
機能仕様
↓
基本設計
↓
詳細設計
↓
実装
↓
テスト

ただし、実際の開発では、必ずしも一方向に進むわけではありません。

例えば、基本設計を進めている途中で、

ユーザー登録後にメールアドレスを確認する仕組みが必要ではないか？

といった新しい仕様が見つかることもあります。

その場合は、要件や機能仕様に戻って内容を確認・修正することもあります。

このように、要件定義・機能仕様・基本設計・詳細設計は、必要に応じて前の工程を見直しながら進めます。

基本設計書に書く主な項目

基本設計書には「必ずこの項目を書かなければならない」という決まりはありません。システムの種類やプロジェクトによって、必要な設計資料は異なります。

一般的なWebシステムであれば、例えば次のような項目があります。

1. 基本情報・改訂履歴

まず、設計書自体の情報を記載します。

• 文書名
• システム名
• バージョン
• 作成日
• 作成者
• 承認者
• 改訂履歴

例えば、改訂履歴は次のようにします。

設計書は開発中に何度も更新されます。改訂履歴を残しておくことで、どの仕様が最新なのか確認しやすくなります。

2. システム概要

システムが何をするものなのかを簡単に説明します。

本システムは、ユーザーがアカウントを作成し、ログインして各種サービスを利用できるWebシステムである。

要件定義書に詳しい説明がある場合は、基本設計書では概要だけを記載し、必要に応じて要件定義書を参照する方法でも構いません。

3. システム構成

システムを構成する主要な要素を整理します。

ユーザー
   ↓
Webブラウザ
   ↓
Webアプリケーション
   ↓
データベース

Webアプリケーション
   ↓
メール配信サービス

実際にはシステム構成図として、クライアント・Webサーバー・アプリケーション・データベース・外部サービスなどの関係を図で表すこともあります。

4. 機能一覧

システムにどのような機能があるのかを一覧にします。

機能IDを付けておくと、画面設計・API設計・テスト仕様書・要件定義書などとの対応関係を管理しやすくなります。

5. 画面一覧

Webシステムやアプリケーションでは、どのような画面が存在するのかを一覧にします。

6. 画面遷移図

画面同士がどのようにつながっているのかを整理します。

ログイン画面
   │
   ├── ログイン成功 → マイページ
   │
   └── 新規登録
          ↓
    ユーザー登録画面
          ↓
    登録完了画面
          ↓
    ログイン画面

画面遷移図があることで、どの画面からどこへ移動できるのかを把握しやすくなります。

7. 画面設計

各画面について、レイアウトや表示する項目を設計します。

--------------------------------

        ユーザー登録

氏名
[____________________]

メールアドレス
[____________________]

パスワード
[____________________]

       [ 登録する ]

--------------------------------

実際のプロジェクトでは、Excel・PowerPoint・Figmaなどを利用して画面イメージを作成することもあります。

ここでは見た目だけでなく、

• 入力項目
• 表示項目
• ボタン
• リンク
• メッセージ
• 活性・非活性条件

なども定義します。

8. 画面項目定義

画面に存在する各項目について詳しく定義します。

9. 画面イベント・処理

ボタンを押したときなど、ユーザー操作に対してどのような動作をするのかを定義します。

登録するボタン押下時：

1. 入力内容をチェックする
2. 入力内容に問題がある場合はエラーを表示する
3. 問題がなければユーザー登録処理を実行する
4. 登録に成功した場合は登録完了画面へ遷移する

ただし、

UserController.register()
↓
UserService.createUser()
↓
UserRepository.insert()

のような、プログラム内部のクラスやメソッド単位の処理まで書くと詳細設計に近くなります。

基本設計では、利用者や外部システムから見た動作に加えて、システム構成やデータ、外部インターフェースなど、システムを構成する主要な仕組みを中心に書くと整理しやすくなります。

10. 入力チェック

入力項目にどのようなチェックを行うのかを整理します。

必要に応じて、半角のみ・数字のみ・記号の利用可否・日付の範囲・重複チェックなどについても定義します。

11. メッセージ一覧

システムで表示するメッセージを一覧化する方法もあります。

メッセージを一元管理することで、画面ごとに異なる表現が使われてしまうのを防ぎやすくなります。

12. データ設計

システムでどのようなデータを管理するのかを設計します。

さらに、ER図を作成してデータ同士の関係を整理することもあります。

ユーザー
   │
   ├── 注文
   │      │
   │      └── 注文明細
   │
   └── 配送先

このように、基本設計では、システムでどのようなデータを管理し、それらのデータがどのような関係を持つのかを設計します。

ER図や論理データモデルを作成するほか、プロジェクトによってはテーブル名・カラム名・データ型・主キー・外部キーなどのテーブル定義まで基本設計で決めることもあります。一方、インデックスや物理的な格納方法など、データベース内部のより詳細な設計を詳細設計で決める場合もあります。

どこまでを基本設計で決めるかは、プロジェクトや組織によって異なります。

13. 外部インターフェース設計

外部システムや別サービスと連携する場合は、その接点を定義します。

• REST API
• ファイル連携
• メール送信
• メッセージキュー
• 他システムとのデータ連携

REST APIであれば、例えば次のようなエンドポイントを定義します。

POST /users

必要に応じて、HTTPメソッド・URL・リクエスト・レスポンス・ステータスコード・認証方式・エラー内容なども定義します。

14. 権限設計

利用者によって使用できる機能が異なる場合は、権限を整理します。

このような表を作成しておくことで、認可仕様を把握しやすくなります。

15. 非機能に関する設計

性能・セキュリティ・可用性などの非機能要件についても、基本設計で実現方法を検討します。

• 通信にはHTTPSを利用する
• 管理画面へのアクセスには認証機構を適用する
• 一定時間操作がなければセッションを終了する
• バックアップを毎日取得する
• 障害発生時にログを記録する
• 想定アクセス数を満たすサーバー・ネットワーク構成を設計する

規模の大きなシステムでは、セキュリティ設計書・運用設計書・性能設計書・インフラ設計書などを別資料として作成することもあります。

基本設計書の具体的な書き方

ここまで紹介した項目を、すべて1つの文書にまとめなければならないわけではありません。

実際のプロジェクトでは、例えば次のように資料を分けることがあります。

基本設計
│
├─ システム構成図
├─ 機能一覧
├─ 画面一覧
├─ 画面遷移図
├─ 画面設計書
├─ 帳票設計書
├─ メッセージ一覧
├─ データ設計書
├─ ER図
├─ API仕様書
├─ 権限設計書
└─ 外部インターフェース仕様書

つまり、「基本設計書」という1つの巨大な文書を書くというより、要件を実現するために必要な設計を行い、その結果を複数の設計資料として整理すると考える方が実務に近い場合もあります。

ユーザー登録機能を例に基本設計を書いてみる

ここでは、簡単なユーザー登録機能を例に基本設計を書いてみます。

機能概要

機能ID：
F-001

機能名：
ユーザー登録

概要：
未登録ユーザーが氏名・メールアドレス・パスワードを入力し、
Webサービスのアカウントを作成する。

使用する画面

SCR-002 ユーザー登録画面
SCR-003 登録完了画面

入力項目

基本フロー

1. ユーザーがユーザー登録画面を表示する
2. 氏名・メールアドレス・パスワードを入力する
3. 「登録する」ボタンを押す
4. システムが入力内容を確認する
5. 問題がなければユーザーを登録する
6. 登録完了画面を表示する

エラー時

・必須項目が入力されていない
  → 対象項目の下に「必須項目です」と表示する

・メールアドレスの形式が正しくない
→ メールアドレス入力欄の下にエラーを表示する

・メールアドレスが登録済み
→ ユーザー登録を行わず、登録済みであることを表示する

画面遷移

ユーザー登録画面
       │
       ├─ 登録成功
       │      ↓
       │  登録完了画面
       │
       └─ 入力エラー
              ↓
       ユーザー登録画面

このように、機能仕様だけでは決まっていなかった具体的な画面・項目・操作・遷移などを決めていくのが基本設計です。

基本設計書を書くときのポイント

要件との対応関係を分かるようにする

基本設計は要件を実現するための設計です。

そのため、例えば次のように関連付けられるようにしておくと便利です。

要件ID：REQ-001
↓
機能ID：F-001
↓
画面ID：SCR-002
↓
テストケース：TC-001

このように、要件と設計、テストなどの対応関係を追跡できるようにすることをトレーサビリティと呼びます。

正常系だけでなく異常系も考える

基本設計では、正常に動いた場合だけを書いて終わらないことが重要です。

• 必須項目が空の場合
• メールアドレスの形式が不正な場合
• 文字数を超えた場合
• 登録済みメールアドレスの場合
• 外部サービスとの通信に失敗した場合

なども考えておく必要があります。

曖昧な表現を避ける

例えば、

適切なエラーメッセージを表示する。

だけでは、実装者によって解釈が変わってしまいます。

できるだけ、

メールアドレスの形式が不正な場合、メールアドレス入力欄の下に「メールアドレスの形式が正しくありません」と表示する。

のように具体的にします。

また、「なるべく速く」「必要に応じて」「適切に」「基本的に」といった言葉を使う場合も、意味が曖昧になっていないか注意しましょう。

図や表を使う

基本設計では、文章だけでは分かりにくい内容が多くあります。

• システム構成 → システム構成図
• 画面の関係 → 画面遷移図
• データの関係 → ER図
• 項目仕様 → 表
• 権限 → 権限マトリクス

のように、図や表を使うと理解しやすくなります。

詳細設計を書きすぎない

基本設計を詳しく書こうとすると、プログラム内部の実装まで書きたくなることがあります。

UserController
    ↓
UserService
    ↓
UserRepository
    ↓
usersテーブル

このようなクラス構成やメソッド単位の処理は、詳細設計に近い内容です。

基本設計では、画面や外部インターフェースなど外部から見た仕様に加えて、データやシステム構成など、要件を実現するための主要な仕組みを中心に記載すると整理しやすくなります。

基本設計書と画面設計書は同じ？

基本設計書と画面設計書は同じものではありません。

画面設計書は、基本設計で作成する成果物の1つです。

基本設計
│
├─ 画面設計
├─ 帳票設計
├─ データ設計
├─ API設計
├─ 外部インターフェース設計
└─ 権限設計

そのため、「基本設計＝画面設計」ではありません。

特にWebシステムでは画面設計が目立つため混同されやすいですが、基本設計ではシステム全体について設計します。

基本設計書と機能仕様書は同じ？

機能仕様書と基本設計書は重なる部分が多いため、プロジェクトによって扱いが異なります。

考え方の1つとして、次のように分けると理解しやすくなります。

例えば、機能仕様では、

ユーザーはメールアドレスとパスワードを入力してアカウントを登録できる。

と定義します。

一方、基本設計では、

ユーザー登録画面に氏名・メールアドレス・パスワードの入力欄と「登録する」ボタンを配置する。登録成功後は登録完了画面へ遷移する。

といった形で、実現方法を具体化します。

ただし、「機能仕様書」という独立した文書を作らず、これらの内容を基本設計書に含めるプロジェクトもあります。

そのため、文書名だけで判断するのではなく、そのプロジェクトで何をどの資料に記載することになっているのかを確認することが重要です。

基本設計書は関係者が理解できるようにする

基本設計書は、実装担当者だけが読む資料ではありません。

• 顧客・発注者
• プロジェクトマネージャー
• 設計担当者
• 開発者
• テスト担当者
• 運用担当者

など、さまざまな人が利用する可能性があります。

そのため、実装担当者にしか分からないプログラム内部の説明ばかりにするのではなく、

• この画面で何ができるのか
• 操作するとシステムがどうなるのか
• システム同士がどのように連携するのか

が分かるように書くことが重要です。

本記事のまとめ

この記事では、基本設計書とは何なのか、要件定義書・機能仕様書・詳細設計書との違いや、主な記載項目、具体的な書き方について解説しました。

基本設計書を書くときは、以下の点を意識すると分かりやすくなります。

• 要件定義で決めた内容を、システムとして実現できる形まで具体化する
• 画面・画面遷移・入力項目・データ・外部インターフェースなどを整理する
• 正常時だけでなく、異常時や例外時の動作も考える
• 「適切に」「必要に応じて」などの曖昧な表現をできるだけ避ける
• 文章だけでなく、画面遷移図・ER図・表なども活用する
• クラスやメソッドなど、詳細設計レベルの実装内容を書きすぎない
• 基本設計と詳細設計の境界はプロジェクトによって異なるため、プロジェクトのルールに従う

基本設計書は、要件定義で決めた「実現したいこと」と、実際の実装をつなぐ重要な設計資料です。

「プログラム内部のクラスやメソッドをどのように実装するか」ではなく「要件をどのような画面・データ・外部インターフェース・システム構成などで実現するのか」を意識して書くと、分かりやすい基本設計書を作りやすくなります。

お読みいただきありがとうございました。