◆ 基本設計書とは？まず最初に理解すべきポイント
システム開発では、いきなりプログラムを書き始めることはありません。
その前に、「どんなシステムを作るのか」 を関係者全員で共有するための文書が必要で、それが 基本設計書（基本設計） です。
👉網羅的に設計書の在り方が理解できるおすすめの本
● 基本設計書の役割
- お客様と開発側の認識を合わせる
- プログラマーが詳細設計・実装を進めるための土台
- テスト項目、運用設計のベースにもなる
つまり、
“このシステムはどう動くのか” を視覚的・論理的にまとめた設計書
と考えればOKです。
◆ 基本設計書に必ず入れるべき6つの項目
ここでは、「最低限これだけ入れればOK」という6つの構成を紹介します。
① システム概要（何を作るのか）
最初に書くべきは「システムの全体像」。
システムの目的／背景／利用者／期待される効果 を整理します。
例：
- 社員の残業申請を簡略化するためのシステム
- 管理者負担の削減と、申請ミスの防止が目的
ここは“システムの紹介ページ”のようにまとめると読みやすいです。
② 機能一覧（何ができるのか）
次に、システムが持つ機能を「大分類 → 小分類」で一覧にします。
| 大分類 | 小分類 | 内容 |
|---|---|---|
| ユーザー管理 | ユーザー登録 | 新規ユーザー登録 |
| ユーザー管理 | ログイン | 認証処理 |
| 商品管理 | 商品登録 | 商品情報の登録 |
開発漏れを防ぐための“目次”になる重要な部分です。
③ 業務フロー（どう使われるのか）
ユーザーや管理者がどう操作し、情報がどのように流れるかをフロー図で整理します。
例：
- ユーザーが商品を閲覧
- カートへ追加
- 注文処理
- 管理者が注文確認
図解にすると、エンジニア以外でも理解しやすくなります。
④ 画面設計（どんな画面になるのか）
基本設計書の中で最も重要です。
● 各画面の仕様を明確にする
- 画面レイアウト（ワイヤーフレーム）
- 入力項目
- ボタンとその動作
- エラーメッセージ
- 遷移先の画面
画面＝システムの顔
ここが曖昧だと、開発後のトラブルにつながります。
⑤ データ設計（どんな情報を扱うか）
どんなデータを扱うのかを整理します。
- データ項目一覧（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 |
◆ まとめ
基本設計書は、
「システムの骨格」をわかりやすく共有するための設計図です。
難しく考える必要はなく、
✔ 何を作るか
✔ どう動くか
✔ どんな画面か
✔ どんなデータか
を整理すれば作れます。
もし「これから自社システムを作る」「外部ベンダーへ依頼する」という場合は、
最初にこの基本設計をしっかり作るだけで、手戻りコストが大幅に下がります。
コメント