◆ 基本設計書とは？まず最初に理解すべきポイント
システム開発では、いきなりプログラムを書き始めることはありません。
その前に、「どんなシステムを作るのか」 を関係者全員で共有するための文書が必要で、それが 基本設計書（基本設計） です。
● 基本設計書の役割
- お客様と開発側の認識を合わせる
- プログラマーが詳細設計・実装を進めるための土台
- テスト項目、運用設計のベースにもなる
つまり、
“このシステムはどう動くのか” を視覚的・論理的にまとめた設計書
と考えればOKです。
◆ 基本設計書に必ず入れるべき6つの項目
ここでは、「最低限これだけ入れればOK」という6つの構成を紹介します。
① システム概要（何を作るのか）
最初に書くべきは「システムの全体像」。
システムの目的／背景／利用者／期待される効果 を整理します。
例：
- 社員の残業申請を簡略化するためのシステム
- 管理者負担の削減と、申請ミスの防止が目的
ここは“システムの紹介ページ”のようにまとめると読みやすいです。
② 機能一覧（何ができるのか）
次に、システムが持つ機能を「大分類 → 小分類」で一覧にします。
| 大分類 | 小分類 | 内容 |
|---|---|---|
| ユーザー管理 | ユーザー登録 | 新規ユーザー登録 |
| ユーザー管理 | ログイン | 認証処理 |
| 商品管理 | 商品登録 | 商品情報の登録 |
開発漏れを防ぐための“目次”になる重要な部分です。
③ 業務フロー（どう使われるのか）
ユーザーや管理者がどう操作し、情報がどのように流れるかをフロー図で整理します。
例：
- ユーザーが商品を閲覧
- カートへ追加
- 注文処理
- 管理者が注文確認
図解にすると、エンジニア以外でも理解しやすくなります。
④ 画面設計（どんな画面になるのか）
基本設計書の中で最も重要です。
● 各画面の仕様を明確にする
- 画面レイアウト（ワイヤーフレーム）
- 入力項目
- ボタンとその動作
- エラーメッセージ
- 遷移先の画面
画面＝システムの顔
ここが曖昧だと、開発後のトラブルにつながります。
⑤ データ設計（どんな情報を扱うか）
どんなデータを扱うのかを整理します。
- データ項目一覧（ID、名前、メールなど）
- ER図（テーブルの関係図）
- 主キー・外部キー
データ設計が曖昧だと、実装後にほぼ必ず不具合が起きます。
⑥ インターフェース設計（外部連携）
外部システムとのつながりがある場合に必須。
例：
- API連携
- 入出力フォーマット
- エラー時の挙動
- リトライ・タイムアウト条件
特に企業システムでは“外部との接続仕様”が重要になります。
◆ 基本設計書を書くときの3つのコツ
✔ 1. 専門用語をできるだけ使わない
誰が読んでも同じ理解になることが一番大事。
✔ 2. 画面ベースで考えると抜け漏れが減る
画面 → 入力 → 処理 → 出力
という流れで設計すると体系化しやすいです。
✔ 3. 曖昧な表現を残さない
×「適当に並び替える」
○「ID昇順で並び替える（昇順／降順の切替あり）」
仕様の“解釈違い”は、後々のトラブルの原因になります。
◆ すぐ使える！基本設計書テンプレート
そのままコピー＆編集できます。
■ 1. システム概要
- システム名：
- 目的：
- 背景：
- 対象ユーザー：
- 効果：
■ 2. 機能一覧
(表の形で整理)
■ 3. 業務フロー
- 業務フロー図
- 利用シナリオ（ユースケース）
■ 4. 画面設計
- 画面一覧
- 画面ごとの詳細（項目・ボタン・遷移）
■ 5. データ設計
- データ項目一覧
- ER図
- マスターデータ一覧（任意）
■ 6. インターフェース設計
- API仕様
- 入出力定義
- エラー時の動作
◆ まとめ
基本設計書は、
「システムの骨格」をわかりやすく共有するための設計図です。
難しく考える必要はなく、
✔ 何を作るか
✔ どう動くか
✔ どんな画面か
✔ どんなデータか
を整理すれば作れます。
もし「これから自社システムを作る」「外部ベンダーへ依頼する」という場合は、
最初にこの基本設計をしっかり作るだけで、手戻りコストが大幅に下がります。
コメント