システム開発の設計書は、中身を書く前に、章立てや表の作り方で手が止まりがちです。特に月末のレビュー前や、取引先へ提出する直前だと、白紙のExcelから作るのは少ししんどいです。
このページでは、基本設計書・詳細設計書を中心に、要件定義書、テスト仕様書などのExcelテンプレートをまとめました。社内システムの小さな改修から、SI案件のたたき台、学習用のサンプルまで使いやすい構成です。
基本設計書・詳細設計書テンプレートの選び方
どれを使うか迷ったときは、まず「誰に見せる文書か」で分けると選びやすくなります。管理側や発注者に見せるなら基本設計書、開発担当者に渡すなら詳細設計書、という分け方です。
| 探しているもの | 使う場面 | 向いているテンプレート |
|---|---|---|
| 基本設計書 | システム全体の構成、機能、画面、帳票を整理したいとき | 基本設計書テンプレート、画面一覧、画面遷移図、機能一覧、帳票一覧 |
| 詳細設計書 | 処理内容、入出力、例外処理などを開発担当者向けにまとめたいとき | 詳細設計書テンプレート、モジュール設計、インターフェース定義 |
| システム設計書 | 基本設計書と詳細設計書を分けず、1つの文書でまとめたいとき | 基本設計書テンプレートをベースに、詳細項目を追加して調整 |
| 仕様書テンプレート | 機能、画面、データ、テスト項目などをExcelで整理したいとき | 要件定義書、基本設計書、詳細設計書、テスト仕様書 |
仕様書・設計書テンプレート（Excel）一覧｜サンプル画像付き
システム開発でよく使う文書のうち、要件定義書、基本設計書、詳細設計書、テスト仕様書・報告書のテンプレートをダウンロードできます。
要件定義書テンプレート（Excel）サンプル付き
表紙、更新履歴、目次、本文の4シート構成です。要件定義の段階では、業務フローや利用者、対象範囲を先にそろえておくと、後の基本設計で迷いにくくなります。
基本設計書テンプレート（Excel）｜画面一覧・機能一覧付き
基本設計書は、要件定義で決まった内容をもとに、システム全体の作りを整理する文書です。発注者、PM、社内の管理側が確認することも多いので、細かすぎる処理ロジックよりも、全体像が追える構成にしておくと使いやすくなります。
| 名称 | 説明 |
|---|---|
| システム構成図 | サーバー、ネットワーク、外部サービスなど、システム全体のつながりを整理する図です。 |
| 業務フロー図 | 業務の流れを順番に追えるようにまとめる図です。利用者の操作や担当部署の切り分けにも使えます。 |
| テーブル定義書 | DBテーブルの項目名、型、桁数、キー、NULL可否などを整理する表です。 |
| 機能一覧 | システムに含まれる機能を一覧で確認するための表です。見積り前の整理にも使いやすいです。 |
| 画面一覧 | システムで使う画面ID、画面名、利用者、関連機能などをまとめる一覧です。 |
| 画面遷移図 | ログイン後の移動、検索、登録、戻る、エラー時の流れなどを図で整理します。 |
| 帳票一覧 | 請求書、一覧表、CSV出力など、システムから出力する帳票を整理します。 |
| 帳票レイアウト（縦） | 縦形式の帳票レイアウトを整理するテンプレートです。 |
| 帳票レイアウト（横） | 横形式の帳票レイアウトを整理するテンプレートです。 |
詳細設計書テンプレート（Excel）サンプル一式
詳細設計書は、開発担当者が実装しやすいように、処理内容を具体化するための文書です。表紙、更新履歴、フレーム（章立て）を収録しているので、社内フォーマットがまだ固まっていない案件でも使い始めやすいです。
テスト仕様書テンプレート（単体・結合・総合テスト用Excel）
単体、結合、総合の3種類をまとめて収録しています。検証内容、実施日、結果、備考を書き残せるので、開発後半の確認作業を整理しやすくなります。
| 名称 | 説明 | |
|---|---|---|
 |
単体テスト | 関数、画面部品、モジュール単位で動作を確認するためのテンプレートです。 |
 |
結合テスト | 画面間、機能間、外部システム連携などの動きを確認するためのテンプレートです。 |
 |
総合テスト | 利用者の操作シナリオに沿って、システム全体の流れを確認するためのテンプレートです。 |
基本設計書と詳細設計書の違い
基本設計書は、システム全体をどう作るかを整理する文書です。画面、機能、データ、帳票、外部連携などを、利用者や管理側が確認できる粒度でまとめます。
詳細設計書は、その内容をもとに、開発担当者が実装できるところまで落とし込む文書です。処理内容、入出力、エラー処理、DB項目などを書いていきます。
現場では、基本設計で決めきれなかった細かい条件を、詳細設計の段階で詰めることもあります。完全に線を引くというより、「誰が読むか」「どこまで決めるか」で分けるイメージです。
| 種類 | 主に書く内容 | 使う場面 |
|---|---|---|
| 基本設計書 | 機能一覧、画面一覧、画面遷移図、帳票一覧、テーブル概要、非機能要件など | 発注者、管理側、PMがシステム全体の作りを確認するとき |
| 詳細設計書 | モジュール設計、処理ロジック、入出力、エラー処理、DB項目、インターフェース仕様など | 開発担当者が実装前に処理内容を具体化するとき |
基本設計書の項目例｜画面一覧・画面遷移図・機能一覧
基本設計書は、最初から全項目をきっちり埋めようとすると重くなります。小規模な社内ツールなら、画面、機能、データの3つを先に固めるだけでも進めやすくなります。
| 項目 | 書く内容 | 使う場面 |
|---|---|---|
| 表紙 | 案件名、文書名、作成日、版数、作成者、承認者など | 社内レビュー、取引先提出 |
| 更新履歴 | 変更日、変更内容、変更者、承認者など | レビュー後の修正管理 |
| 機能一覧 | 機能ID、機能名、概要、入力、出力、関連画面など | 開発範囲や見積り前の整理 |
| 画面一覧 | 画面ID、画面名、URL、利用者、関連機能、備考など | 画面数が多いWebシステム、業務アプリ開発 |
| 画面遷移図 | ログイン後の移動、検索、登録、戻る、エラー時の流れなど | 画面の抜け漏れをレビューしたいとき |
| テーブル定義書 | テーブル名、項目名、型、桁数、NULL可否、キー、備考など | DB設計、詳細設計に進む前の整理 |
| 帳票一覧 | 帳票名、出力条件、出力形式、出力項目、利用部署など | 請求書、一覧表、CSV出力がある案件 |
システム設計書テンプレートとして使う場合
社内では「基本設計書」ではなく「システム設計書」という名前で提出することもあります。中身は基本設計書に近く、システム構成、機能一覧、画面一覧、データ設計、帳票、運用まわりをまとめる形が多いです。
小さな改修案件では、基本設計書と詳細設計書を分けず、1つのシステム設計書にまとめた方が楽なこともあります。たとえば、既存の販売管理システムに検索条件を1つ追加するような案件なら、全体構成を厚く書くより、対象画面と処理内容を絞って書いた方が読みやすいです。
詳細設計書テンプレートに入れる項目例
詳細設計書は、開発者が「この内容なら実装できる」と判断できる粒度まで書く文書です。ただし、案件によってはすべての項目を使うわけではありません。既存システムの軽微な修正なら、変更対象の処理だけに絞ることもあります。
- モジュール設計（入出力、前提条件、処理内容、戻り値など）
- インターフェース定義（I/Oフォーマット、連携先、エラーコードなど）
- DBスキーマ詳細（項目、型、桁数、インデックス、制約など）
- 例外処理（リトライ、タイムアウト、エラー表示、ログ出力など）
- テスト観点（単体テスト、結合テストで確認する内容）
このページの仕様書テンプレートについて
ここで紹介している仕様書テンプレートは、製品仕様書や営業用の仕様書ではなく、システム開発で使う設計・テスト用のExcelテンプレートです。
機能、画面、データ、帳票、テスト項目などを整理する用途に向いています。製品の寸法やスペックをまとめる「製品仕様書」とは少し違うので、検索して来た方はここだけ先に見ておくと迷いにくいです。
テンプレートを使う前に決めておくこと
テンプレートがあると、章立てや表の形をゼロから作らずに済みます。ただ、使う前に案件の範囲だけは軽く決めておいた方がスムーズです。ここを決めずに書き始めると、あとで「この画面も対象でしたっけ？」となりやすいです。
| 使う前に決めること | 実務での考え方 |
|---|---|
| 対象範囲 | 新規開発なのか、既存システムの改修なのかを先に分けます。改修なら対象画面、対象機能を絞っておくと楽です。 |
| 読む人 | 管理側に見せる文書なら全体像を厚めに、開発者向けなら処理内容やDB項目を厚めにします。 |
| 省略する項目 | 小規模案件では、帳票や外部連携がないこともあります。使わない項目は無理に残さず、削った方が読みやすいです。 |
| 更新ルール | レビュー後に誰が修正し、誰が承認するのかを決めておくと、更新履歴があいまいになりにくいです。 |
システム開発の初期に役立つテンプレート
設計書だけでは、プロジェクト全体の進行は見えにくいです。体制図や議事録も一緒にそろえておくと、後から入ったメンバーにも状況を共有しやすくなります。
体制図テンプレート（プロジェクト組織の可視化）
プロジェクトを始める前に、誰がどの役割を担当するのかを図にしておくと、あとから参加した人にも状況を伝えやすくなります。担当の境目があいまいなまま進むと、地味に手戻りが増えます。最初に1枚作っておくと、朝の定例でも説明が早いです。
議事録テンプレート（会議記録用ひな形）
システム開発は、最初の要件定義やヒアリングだけで全部が決まることはほとんどありません。開発中も何度も打ち合わせが入るので、決定事項や宿題を残しておける議事録はかなり使います。あとで「言った・言わない」になりやすい場面ほど、効いてきます。
スケジュール管理・タスク管理テンプレート（Excel）
設計を始める前に、いつまでに何を終えるかをざっくり置いておくと、後半の詰まりを減らせます。最初の見積りは外れることもありますが、作業を分けておくだけでも調整しやすくなります。
WBSテンプレート（業務分解・工数見積）
WBSは、プロジェクトを始める前に全体像と工数感をつかむために使います。設計、開発、テスト、レビューを分けておくと、どこで遅れているのか見えやすいです。
ガントチャートテンプレート（進捗・納期管理）
ガントチャートは、プロジェクトのスケジュールや進捗を見渡すために使います。納期が詰まっている案件ほど、全体の流れが見えていないと後半で一気に苦しくなりがちです。早い段階で引いておくと、担当者同士の調整もしやすくなります。
コミュニケーション管理テンプレート（Excel）
システム開発では、質問、課題、確認待ちがメールやチャットに散らばりやすいです。小さな案件でも、一覧にしておくと後から探す手間がかなり減ります。
Q&Aシートテンプレート（質問と回答の管理）
質問と回答をまとめておけるシートがあると、同じ質問を何度も投げずに済みます。メンバー同士でも内容を共有しやすくなりますし、メールの中に埋もれて後から探せなくなる、あの感じも減らせます。
課題管理表テンプレート（問題・対応状況の記録）
Q&Aシートが顧客との確認や質問のやり取りを整理するものだとすると、課題管理表は、メンバー内で起きている問題や対応状況を追っていくための表です。リリース前の夕方になって未対応の課題が見つかるとかなり焦るので、早めに一覧化しておくと安心です。
よくある失敗と直し方（設計書作成編）
設計書は、作り始めると細かいところで詰まります。実際に多いのは、内容そのものよりも、用語や更新履歴、図表の参照がバラバラになるケースです。
- 章立てが案件ごとにばらつく → 章番号と見出しの付け方をそろえておくと、あとで差分を追いやすくなります。
- 用語が統一されず、認識がずれる → 冒頭に用語集を置いて、レビュー前に言葉をそろえておくと混乱が減ります。
- 図と表が本文から参照されていない → 図番や表番を付けて、本文側からたどれるようにしておくと読みやすいです。
- 更新履歴があいまいなまま残る → 変更理由、起票者、承認者まで書く形にしておくと、後から見返したときに助かります。
- 全部の項目を埋めようとして進まない → 小規模案件では、使わない章を消しても問題ありません。対象外の項目を残すと、読む側も迷います。
FAQ｜設計書テンプレートのよくある質問
まとめ｜基本設計書・詳細設計書テンプレートの使い方
今回は、システム開発で使う基本設計書、詳細設計書、要件定義書、テスト仕様書のExcelテンプレートを紹介しました。
基本設計書は、画面、機能、データ、帳票などを整理して、関係者が全体像を確認するために使います。詳細設計書は、そこから一歩進めて、開発担当者が実装しやすいように処理内容を具体化する文書です。
白紙から作ると、章立てや表の形だけで時間を使ってしまいます。テンプレートを使うと、最初の形が決まっているので、案件ごとの中身に集中しやすくなります。不要な項目は削り、足りない項目は追加しながら、自社の進め方に合わせて調整してみてください。
作成・監修体制
- 作成：業務文書・帳票設計の実務に関わってきた編集チーム
- レビュー：社内SEやPMの経験者が、構成や項目の細かさを確認
- 更新方針：主要な変更やガイドライン改定があった際に、内容を見直します
