「基本設計書を作っておいて」と言われて、まず手が止まる。何を、何冊、どの順で作ればいいのかが決まっていないからです。
しかも呼び方が現場ごとに違います。同じものを画面設計書と呼ぶ会社もあれば、画面定義書、画面仕様書と呼ぶ会社もある。前の現場の言葉が通じません。
この記事では、設計工程で作る成果物を種類別に並べ、それぞれのExcelテンプレートへの入口をまとめました。どれから手をつけるかの順序もあわせて示します。
設計工程の成果物は「一覧」と「設計書」の2階建てになっている
最初に、全体の構造を押さえておきます。設計工程の成果物は、ほぼ例外なく2階建てです。
| 対象 | 1階：一覧（数と粒度を決める） | 2階：設計書（中身を決める） |
|---|---|---|
| 画面 | 画面一覧 | 画面定義書 |
| 帳票 | 帳票一覧 | 帳票設計書 |
| バッチ処理 | バッチ処理一覧 | バッチ処理設計書 |
| 外部連携 | 外部インタフェース一覧 | 外部インタフェース設計書 |
| プログラム | プログラム一覧 | 各処理の設計書 |
一覧で「いくつあるか」を確定させ、設計書で「中身をどうするか」を決めます。
この順序を逆にすると破綻します。画面定義書を先に書き始めると、書いている途中で「この画面、隣のチームが作っている画面と同じでは」という話が出ます。画面IDが採番されていないので、どちらを残すかの判断もできません。手戻りは設計書1冊まるごとになります。
一覧が先である理由はもう1つあります。見積もりと進捗管理が一覧の行数を単位にしているからです。画面が38本あると分かって初めて、工数も進捗率も出せます。設計書から書き始めると、終わりが見えないまま進むことになります。
設計書・定義書・仕様書は、ほぼ同じものを指している
呼称の違いは、内容の違いではありません。会社と時代の違いです。
| 呼び方 | 使われ方 |
|---|---|
| 〜設計書 | 最も一般的。「どう作るか」を書いたもの |
| 〜定義書 | 項目や値の定義が中心のときに使われやすい |
| 〜仕様書 | 発注側・受入側の視点が入るときに使われやすい |
厳密に使い分けている現場もありますが、多くの現場では同じものを違う名前で呼んでいるだけです。テンプレートを探すときは、3つとも試してください。
工程の呼び方も同じです。
| 呼び方 | 同じ意味で使われる語 | 決めること |
|---|---|---|
| 基本設計 | 外部設計 | 利用者から見える部分。画面・帳票・連携の仕様 |
| 詳細設計 | 内部設計 | 中の作り。処理ロジック・データアクセス |
ただし実務では、1つのExcelブックの中に基本設計と詳細設計の両方が入っていることがよくあります。処理概要のシートは基本設計、入出力処理設計のシートは詳細設計、というように混在します。工程で分冊しようとすると、かえって管理が煩雑になります。
画面まわりの設計書
利用者が直接触る部分です。設計工程で最も分量が多くなります。
- 画面一覧 — 画面IDを採番し、画面の数を確定させます。すべての起点になります
- 画面定義書／画面設計書 — 1画面ずつ、レイアウト・画面項目定義・表示条件・入力チェック・入出力処理設計まで書きます
- 画面遷移図 — 画面同士のつながり。単体では正しく見えても、つないだ瞬間に破綻する経路が見つかります
- メッセージ設計書 — メッセージIDの設定ルールと文言。画面定義書の入力チェックと対になります
- 選択リスト定義書 — 選択肢の一覧と値。画面と帳票の両方から参照されます
メッセージ設計書は後回しにされがちですが、分散させると同じ意味の文言が画面ごとに違うという状態になります。1か所に集めておく価値があります。
帳票まわりの設計書
- 帳票一覧 — 帳票の数と出力方式を確定させます
- 帳票設計書／帳票定義書 — 出力項目・レイアウト・出力件数と性能まで
帳票で問題になるのは、たいてい件数です。レイアウトの議論は進むのに、月末に何万件出るのかが最後まで決まらない。性能問題は本番直前に出ます。一覧の段階で件数の欄を埋めておくと、後半が楽になります。
データモデルまわりの設計書
- データモデル・オブジェクト設計 — 概念データモデルから設計に落とす進め方。オブジェクト定義書のテンプレートもここから辿れます
- CRUD図／CRUDマトリクス表 — 機能とデータの関係。どの機能がどのデータを作り、更新し、消すか
- コード設計書／コード定義書 — コード体系と値の定義。区分値をどこで持つか
CRUD図は省略されることが多い成果物です。ただし**「このデータは誰が作るのか」が誰も答えられない**状態に気づけるのは、この表だけです。作るなら機能×オブジェクトのレベルまでで十分で、項目レベルまで作ると維持できなくなります。
処理・バッチまわりの設計書
- プログラム一覧 — 実装対象の数。機能種別ごとの難易度と規模を定義しておくと見積もりに使えます
- バッチ処理一覧 — バッチの数と処理方式
- バッチ処理設計書 — 処理概要・処理フロー図・入出力処理設計
- ジョブスケジュール — 起動サーバ・サイクル・時刻。バッチ同士の順序と依存
- トリガー処理設計書 ／ トリガー一覧 — データ更新をきっかけに動く処理
ジョブスケジュールは一覧の一種ですが、時間軸で見ないと衝突が見つかりません。処理単体では正しくても、同じ時刻に重い処理が3本走る設計になっていることがあります。
外部連携まわりの設計書
- 外部インタフェース一覧／連携全体図 — 連携の数と方向。全体図があると相手先との合意が早くなります
- 外部インタフェース設計書 — 処理概要・連携処理フロー・データ移送項目
外部連携は相手がいるため、自分たちだけでは決められません。設計工程の中で最初に着手すべき領域です。
どこから手をつけるか
順序をまとめると、こうなります。
- システム機能一覧 で、作るものの全体像を確定させる
- 各種の一覧（画面・帳票・バッチ・外部連携・プログラム）で、数と粒度を決める
- 外部連携の設計書から着手する（相手との調整に時間がかかるため）
- 画面・帳票の設計書を進める
- 処理・バッチの設計書とデータモデルを固める
一覧がすべて揃った時点で、設計工程の残作業が行数で見えるようになります。ここが引けているかどうかで、後半の進め方が変わります。
テンプレートを埋める作業をどう減らすか
テンプレートを配っても、埋める作業は残ります。設計工程で時間を食うのは様式を整えることではなく、項目を1つずつ書いていく作業です。
この部分は生成AIにかなりの割合を任せられます。ただし任せられる範囲と、任せてはいけない範囲が分かれます。具体的な手順は別の記事にまとめました。
まとめ
- 設計工程の成果物は**「一覧」と「設計書」の2階建て**。一覧で数と粒度を決め、設計書で中身を決める
- 順序を逆にすると手戻りが設計書1冊単位になる。見積もりと進捗も一覧の行数が単位
- 設計書・定義書・仕様書はほぼ同じもの。基本設計＝外部設計、詳細設計＝内部設計
- 1つのExcelブックに基本設計と詳細設計が混在するのは普通。工程で分冊しなくてよい
- 着手順は機能一覧 → 各一覧 → 外部連携 → 画面・帳票 → 処理・データモデル
テンプレートの埋め方や、プロジェクトに合わせた様式の調整を手を動かしながら身につけたい方は、AI開発トレーニングで個別にお伝えしています。
