【初心者向け】基本設計書の書き方を超わかりやすく解説｜まず覚えるべき6つの構成とは？

◆ 基本設計書とは？まず最初に理解すべきポイント

システム開発では、いきなりプログラムを書き始めることはありません。
その前に、「どんなシステムを作るのか」 を関係者全員で共有するための文書が必要で、それが 基本設計書（基本設計） です。

👉網羅的に設計書の在り方が理解できるおすすめの本

---

● 基本設計書の役割

• お客様と開発側の認識を合わせる
• プログラマーが詳細設計・実装を進めるための土台
• テスト項目、運用設計のベースにもなる

つまり、
“このシステムはどう動くのか” を視覚的・論理的にまとめた設計書
と考えればOKです。

---

◆ 基本設計書に必ず入れるべき6つの項目

ここでは、「最低限これだけ入れればOK」という6つの構成を紹介します。

---

① システム概要（何を作るのか）

最初に書くべきは「システムの全体像」。

システムの目的／背景／利用者／期待される効果 を整理します。

例：

• 社員の残業申請を簡略化するためのシステム
• 管理者負担の削減と、申請ミスの防止が目的

ここは“システムの紹介ページ”のようにまとめると読みやすいです。

---

② 機能一覧（何ができるのか）

次に、システムが持つ機能を「大分類 → 小分類」で一覧にします。

大分類	小分類	内容
ユーザー管理	ユーザー登録	新規ユーザー登録
ユーザー管理	ログイン	認証処理
商品管理	商品登録	商品情報の登録

開発漏れを防ぐための“目次”になる重要な部分です。

---

③ 業務フロー（どう使われるのか）

ユーザーや管理者がどう操作し、情報がどのように流れるかをフロー図で整理します。

例：

1. ユーザーが商品を閲覧
2. カートへ追加
3. 注文処理
4. 管理者が注文確認

図解にすると、エンジニア以外でも理解しやすくなります。

---

④ 画面設計（どんな画面になるのか）

基本設計書の中で最も重要です。

● 各画面の仕様を明確にする

• 画面レイアウト（ワイヤーフレーム）
• 入力項目
• ボタンとその動作
• エラーメッセージ
• 遷移先の画面

画面＝システムの顔
ここが曖昧だと、開発後のトラブルにつながります。

---

⑤ データ設計（どんな情報を扱うか）

どんなデータを扱うのかを整理します。

• データ項目一覧（ID、名前、メールなど）
• ER図（テーブルの関係図）
• 主キー・外部キー

データ設計が曖昧だと、実装後にほぼ必ず不具合が起きます。

---

⑥ インターフェース設計（外部連携）

外部システムとのつながりがある場合に必須。

例：

• API連携
• 入出力フォーマット
• エラー時の挙動
• リトライ・タイムアウト条件

特に企業システムでは“外部との接続仕様”が重要になります。

---

◆ 基本設計書を書くときの3つのコツ

✔ 1. 専門用語をできるだけ使わない

誰が読んでも同じ理解になることが一番大事。

---

✔ 2. 画面ベースで考えると抜け漏れが減る

画面 → 入力 → 処理 → 出力
という流れで設計すると体系化しやすいです。

---

✔ 3. 曖昧な表現を残さない

×「適当に並び替える」
○「ID昇順で並び替える（昇順／降順の切替あり）」

仕様の“解釈違い”は、後々のトラブルの原因になります。

---

◆ すぐ使える！基本設計書テンプレート

そのままコピー＆編集できます。

✅ 基本設計書テンプレ（Cocoon向け・すっきり版）

0. 改訂履歴（最初に置くと運用がラク）

版	日付	作成/更新者	変更概要
0.1	YYYY/MM/DD		初版

---

1. システム概要

システム名
（例：〇〇管理システム）

目的
（何を解決する／何を実現する）

背景
（現状課題・経緯・なぜ今必要か）

対象ユーザー
（部署/役割/利用頻度/利用端末）

期待効果
・工数削減：
・ミス削減：
・可視化：

---

2. 機能一覧（ここは表で固定）

No	機能名	概要	優先度	備考
1			高/中/低
2			高/中/低

コツ：この表だけで「何ができるシステムか」が伝わるように、概要は1行で。

---

3. 業務フロー・ユースケース

3.1 業務フロー

業務フロー図
（画像貼り付け／URL／図の作成場所）

3.2 利用シナリオ（ユースケース）

No	ユースケース名	アクター	トリガー	結果
UC-01

ユースケース詳細
前提条件：
基本フロー：
1.
2.
3.

代替フロー：

• A-1：
• A-2：

例外（エラー）：

E-1：

---

4. 画面設計

4.1 画面一覧

画面ID	画面名	用途	主な遷移元	主な遷移先
SC-01

4.2 画面詳細（1画面＝1ブロックで見やすく）

画面ID：SC-01　画面名：
目的：
表示項目：
・
入力項目：
・
ボタン：
・（押下時の処理）
バリデーション：
・必須／桁数／形式
遷移：
・成功時 →
・失敗時 →

---

5. データ設計

5.1 データ項目一覧

項目名	物理名	型	桁	必須	初期値	備考
				Y/N

5.2 ER図

ER図
（画像貼り付け／作成ツール／格納先）

マスターデータ一覧（任意）

マスタ名	主キー	用途	更新方法

---

6. インターフェース設計

6.1 IF一覧

IF-ID	種別	名称	方向	方式	認証	備考
IF-01	API/Batch/File		IN/OUT	REST/SOAP/SFTP

---

6.2 IF詳細（1IF＝折りたたみで運用向き）

IF-01：（API名 / 連携名）

■ 概要

• 目的：
• 接続先：
• 方式：REST / SOAP / File / Batch
• タイムアウト：秒
• リトライ：回（間隔：秒）

■ API仕様（例：REST）

項目	内容
Method	GET / POST
Endpoint
Header
Content-Type	application/json

■ 入力（Request）

項目	型	必須	説明
		Y/N

■ 出力（Response）

項目	型	説明

■ エラー時の動作（これを表にすると強い）

ケース	例	システム動作	利用者への表示	ログ	リトライ
通信失敗	Timeout				する/しない
認証失敗	401/403
入力不正	400
想定外	500

---

◆ まとめ

基本設計書は、
「システムの骨格」をわかりやすく共有するための設計図です。

難しく考える必要はなく、
✔ 何を作るか
✔ どう動くか
✔ どんな画面か
✔ どんなデータか
を整理すれば作れます。

もし「これから自社システムを作る」「外部ベンダーへ依頼する」という場合は、
最初にこの基本設計をしっかり作るだけで、手戻りコストが大幅に下がります。