基本設計書のテンプレート 成果物別の様式と列構成、カスタマイズの手順を解説

基本設計書のテンプレートを探してダウンロードしたものの、思っていたものと違った。1つのファイルに全部入っていると思っていたのに、実際は複数の様式に分かれている。あるいは項目が多すぎて、どれを使えばいいのか分からない。

原因は、基本設計書が1種類の文書ではないことにあります。機能一覧、画面一覧、テーブル定義、帳票レイアウトなど、複数の成果物の集まりです。それぞれに適した様式があります。

そして、汎用のテンプレートをそのまま使うと、自社の案件に不要な項目まで抱え込むことになります。テンプレートは出発点であり、削ってから使うものです。

本記事では、基本設計書テンプレートの全体構成、成果物ごとの様式と列構成、自社に合わせたカスタマイズの手順、そして社内標準として運用する方法までを順に解説します。

確認したいポイント	結論	詳細
基本設計書のテンプレートとは？	成果物ごとの様式をまとめたもの	1ファイルではなく、機能一覧や画面一覧など複数の様式で構成される。
どの成果物が必要？	案件によって変わる。まず削る	画面がなければ画面設計は不要。使わない様式は先に削除する。
ExcelとWordの分担は？	一覧はExcel、方針の説明はWord	機能一覧や項目定義は表形式、目的や範囲の説明は文章が向く。
カスタマイズの基準は？	読み手が判断できるかで決める	項目を足すときは1つ削る前提にすると、様式が膨らまない。

この記事でわかること

• 基本設計書テンプレートの全体構成と、共通部・個別部の分け方
• 機能一覧や画面設計など、成果物ごとの様式と列構成
• 汎用テンプレートを自社の案件に合わせて削る・足す判断基準
• テンプレートを使った作成手順5ステップと整合性の確認方法
• テンプレートを社内標準として定着させる運用のつくり方

システム開発やAI導入の進め方を、支援内容とあわせて資料にまとめています。 ＞＞ 資料請求はこちら

基本設計書のテンプレートは1つではない

テンプレートを探す前に、基本設計書がどういう構造の文書なのかを押さえておきます。ここを誤解していると、探しても見つかりません。

ここでは文書の構造、テンプレートを使う利点、そしてファイル形式の分担を整理します。

基本設計書は複数の成果物の集まり

基本設計書は、システムを外から見たときの動きを記述した文書群です。実際には、業務フロー図、機能一覧、画面一覧、画面設計、帳票一覧、テーブル定義、外部インターフェース一覧といった成果物に分かれています。

それぞれ書く内容も適した形式も異なるため、共通の1様式では扱えません。「基本設計書のテンプレート」とは、これら複数の様式をひとまとめにしたものを指します。

配布されているテンプレートを開いて「シートが何枚もある」と感じたら、それが正しい構造です。

テンプレートを使うと判断の回数が減る

白紙から始めると、まず何を項目として立てるかを考えることになります。この作業自体に時間がかかり、担当者ごとに構成もばらつきます。

テンプレートがあれば、考えるのは中身だけです。項目が並んでいることで、埋められない箇所が空欄として可視化され、決まっていないことが分かります。

複数人で分担する場合はさらに効果があります。構成がそろっていれば、レビューする側も同じ順序で確認でき、見落としが減ります。

ExcelとWordの分担

一覧系の成果物はExcelが向いています。機能一覧、画面一覧、テーブル定義、帳票一覧は、IDを振って並べ替えや絞り込みができる形が便利です。

一方、システム化の方針、対象範囲、前提条件といった説明はWordのほうが伝わります。読み手が経緯から理解できるためです。

実務では、方針をWordで書き、一覧系をExcelで管理する2ファイル構成がよく使われます。業務フロー図や画面レイアウトは、作図しやすいツールで作り、別ファイルとして管理します。

基本設計書テンプレートの全体構成

テンプレートは、案件を問わず共通する部分と、成果物ごとの部分に分けて考えると整理しやすくなります。

ここでは全体の構成を示します。

共通部｜表紙・改訂履歴・用語定義

文書全体で1回だけ用意する部分です。文書名、対象システム、版数、作成者、承認者を表紙にまとめ、その下に改訂履歴の表を置きます。

改訂履歴には、日付、版数、変更内容、変更理由、変更者を並べます。変更理由の列を必ず設けてください。何を変えたかだけでは、後から見たときに戻してよい変更かを判断できません。

用語定義には、社内独自の呼び方や略語をまとめます。同じ対象を業務部門と開発部門が別の名前で呼んでいることは珍しくありません。

全体設計の成果物

システム全体にかかわる内容をまとめる部分です。システム化の方針と対象範囲、システム構成図、業務フロー図、非機能要件が含まれます。

この部分は、発注者が最初に読む箇所です。専門用語を避け、業務の言葉で書くことが求められます。

個別設計の成果物

機能、画面、帳票、データ、外部連携といった単位で作る部分です。一覧を作り、そこから個別の設計に展開する2段構えにします。

機能一覧から機能ごとの設計へ、画面一覧から画面ごとのレイアウトへ、という形です。一覧を先に作ることで、抜けや重複を早い段階で見つけられます。

成果物の一覧と必要性

整理すると次のようになります。すべてを用意する必要はありません。

区分	成果物	必要になる場面
共通	表紙・改訂履歴・用語定義	常に必要
全体	システム化方針・対象範囲	常に必要
全体	システム構成図	サーバーや端末の構成を示す場合
全体	業務フロー図	業務手順が変わる場合（ほぼ常に必要）
全体	非機能要件定義	常に必要
個別	機能一覧・機能設計	常に必要
個別	画面一覧・画面遷移図・画面設計	利用者が操作する画面がある場合
個別	帳票一覧・帳票レイアウト	帳票を出力する場合
個別	ER図・テーブル定義	データを保存する場合（ほぼ常に必要）
個別	外部インターフェース一覧	他システムと連携する場合
個別	バッチ処理一覧	定時実行する処理がある場合
個別	メッセージ一覧	エラーや確認の表示がある場合

自社の案件でどの成果物が必要か、現状を伺ったうえで整理をお手伝いします。 ＞＞ 相談予約はこちら

成果物ごとのテンプレート様式と列構成

ここからが本題です。主な成果物について、どの列を用意すればよいかを具体的に示します。

自社テンプレートを作る際の骨格として、そのまま使える構成にしています。

機能一覧の様式

基本設計書の中心になる一覧です。機能を1行ずつ登録し、要件定義書との対応を保ちます。

列	記載内容	記入の観点
機能ID	FN-001などの通し番号	削除しても番号は詰めない
機能名	受注登録、受注一覧表示など	業務の言葉で書く
機能区分	マスタ、トランザクション、集計など	分類は3〜5種類にとどめる
機能概要	この機能で何ができるかを1〜2文	専門用語を避ける
実行タイミング	利用者操作、日次バッチなど	自動か手動かを明示
優先度	MUST／WANT	2〜3段階にとどめる
対応要件ID	RQ-001など	要件定義書と結びつける

対応要件IDの列が空の行は、その機能が要件から導かれていないということです。なぜ必要なのかを確認してください。

画面一覧と画面遷移図の様式

画面一覧には、画面ID、画面名、概要、利用する権限、対応する機能IDを並べます。画面IDを振っておくと、遷移図や画面設計との対応が取れます。

画面遷移図は、上から下、左から右へ流れるように配置すると読みやすくなります。矢印には遷移する条件を書き添えてください。条件のない矢印は、何をすると移動するのかが伝わりません。

画面設計（項目定義）の様式

画面ごとに、レイアウト図と項目定義の表をセットにします。項目定義には次の列を用意します。

列	記載内容	記入の観点
項目No	画面内の通し番号	レイアウト図の番号と対応させる
項目名	取引先コード、数量など	画面上の表示名と一致させる
種別	入力、表示、選択、ボタン	操作できるかどうかを示す
必須	必須／任意	未入力時の扱いも記載
桁数・形式	半角6桁、日付など	全角と半角を区別する
入力チェック	数値のみ、当日以降など	エラー時のメッセージも記載
初期値	当日日付、空白など	画面を開いた時点の状態

レイアウト図に番号を振り、項目定義の表と対応させてください。図と表が独立していると、どの項目のことか分からなくなります。

帳票一覧と帳票レイアウトの様式

帳票一覧には、帳票ID、帳票名、用途、出力形式、出力タイミング、出力先を並べます。用紙の向きとサイズも記載しておくと、後の確認が減ります。

帳票レイアウトは、実際の出力イメージに近い形で作ります。現行で使っている実物を並べて確認してもらうと、体裁の指摘が早く出ます。社外に出る帳票ほど、要求は細かくなります。

ER図とテーブル定義の様式

ER図では、エンティティ間の関係と多重度を示します。「1件の注文に複数の明細がぶら下がる」といった構造を、この段階で固めます。

テーブル定義には、テーブル名、テーブルID、概要、保存期間、最大件数の見込みを並べた一覧を用意します。

カラムの型やインデックスの設計は詳細設計に譲ります。基本設計で確認してもらうのは、どんなデータをいつまで保持するのかという業務上の判断です。

外部インターフェース一覧の様式

連携先システム、連携するデータ、方式、タイミング、データ形式、責任分界点を列にします。

責任分界点の列を必ず設けてください。どこまでが自社の責任で、どこからが相手方の責任かが曖昧だと、障害時に対応が止まります。

相手方のシステムが別会社の管理下にある場合は、この一覧を先に合意してから他の設計を進めると日程が安定します。

非機能要件の様式

性能、可用性、セキュリティ、運用の条件を数値で記載します。ID、分類、要件、目標値、根拠の5列を用意します。

項目の抜けを防ぐには、IPAが公開している非機能要求グレードが使えます。非機能要求項目を6つの大項目ごとに階層的に整理し、要求レベルを段階的に決められる資料です。

根拠の列を設けると、過剰な要求を防げます。「なんとなく速いほうがいい」で厳しい目標値を書くと、その1項目のために費用が跳ね上がることがあります。

テンプレートを自社に合わせてカスタマイズする

配布されているテンプレートは、大規模案件にも対応できるよう項目が多めに用意されています。そのまま使うと、埋まらない欄が大量に残ります。

ここでは、自社の案件に合わせる手順を整理します。

まず不要な成果物と項目を削る

最初にやるべきは追加ではなく削除です。画面のないシステムに画面設計の様式は不要ですし、外部連携がなければインターフェース一覧も要りません。

空欄が並んでいると、決まっていないのか対象外なのかが判別できず、レビューのたびに確認が発生します。使わない様式は最初に削ってください。

IPAが外部設計工程を対象に公開している機能要件の合意形成に関する資料でも、業務の処理や流れ、データ、インターフェースといった設計要素が整理されています。自社の案件で該当する領域を確認する材料になります。

項目を足すときの基準

その案件で特に重要な観点があれば、列や項目を追加します。ただし、追加するときは既存の列を1つ削れないかを先に検討してください。

判断の基準は「その列がないと読み手が判断できないか」です。管理したいから足す、という理由で増やすと、様式が横に長くなり読みにくくなります。

列を追加した場合は、既存の行にも遡って埋める必要があります。途中から空欄の列が増えると、記入漏れなのか対象外なのか分からなくなります。

案件規模による調整

規模に比例して作成する成果物は増えます。小規模であれば、まとめたり省いたりして構いません。

規模	成果物の扱い	省略しやすいもの
小規模（機能20件未満）	一覧系を1ファイルに集約	システム構成図、バッチ一覧
中規模（機能20〜100件）	一覧と個別設計を分ける	メッセージ一覧（画面設計に含める）
大規模（機能100件超）	成果物ごとにファイルを分割	省略せず、責任者を分けて管理

規模が小さいほど、文書より対話で解決したほうが早い場面が増えます。ただし、決まったことを記録に残す手間は省かないでください。

削ってはいけない項目

どこまで絞る場合でも、次の項目は残してください。後から復元できない情報です。

• 対象範囲と、今回対象としないもの
• 要件定義書との対応関係（要件IDの列）
• 非機能要件の目標値と、その根拠
• データの保存期間
• 外部連携の責任分界点
• 改訂履歴と変更理由

とくに「対象としないもの」の記載は、削ってはいけません。書いていないものは対象外である、という了解は成立しないためです。

設計工程の進め方や成果物の範囲設定を、伴走して支援しています。 ＞＞ 相談予約はこちら

テンプレートを使った作成手順5ステップ

様式がそろっても、埋める順序を間違えると手戻りが発生します。個別の画面設計から始めると、業務フローが変わったときに全部やり直しになります。

ここでは無駄なく進める手順を5つに分けて説明します。

ステップ1｜案件に合わせて使う成果物を選ぶ

要件定義書を読み、必要な成果物を決めます。使わない様式は削除し、必要な列を確定させます。

この作業を最初にやっておくと、書きながら迷う時間がなくなります。関係者にも、どの成果物が納品対象かを共有しておきます。

ステップ2｜共通部と一覧系から埋める

表紙と用語定義を整えたら、業務フロー図と機能一覧に着手します。全体像を先に固めることで、個別設計の手戻りを減らせます。

機能一覧の段階で、要件定義書のすべての要件が現れているかを確認してください。現れていない要件は、実現手段が決まっていません。

ステップ3｜一覧から個別設計に展開する

機能一覧から機能設計へ、画面一覧から画面設計へと展開します。一覧のIDを引き継ぐことで、対応関係が保たれます。

難易度の高いものや、他への影響が大きいものから着手します。ここで見つかる問題は、他の成果物にも波及するためです。

ステップ4｜成果物どうしの整合を確認する

機能一覧に載っている機能が画面設計に現れているか、画面設計で使うデータがテーブル定義に存在するかを突き合わせます。

IDを振っておけば、この確認は表計算の関数で自動化できます。手作業で目視確認すると、規模が大きくなるほど見落とします。

ステップ5｜レビューを受けて版数を確定する

開発チーム内でレビューした後、発注者と利用部門のレビューに進みます。指摘を反映してから版数を確定し、改訂履歴に記録します。

未決の項目は空欄にせず、「未決」と理由を記入してください。空欄は見落とされますが、未決と書かれていれば追跡できます。

テンプレートを社内標準として定着させる

テンプレートの価値は、1つの案件で終わりません。社内で共通の様式を使い続けることで、組織に知見がたまります。

ここでは標準化を機能させるための4点を挙げます。

標準化で得られる効果

案件をまたいで様式がそろっていると、過去の設計書を参考にする際に必要な箇所をすぐ見つけられます。担当者が変わっても、読み解く時間が短くて済みます。

レビューする側も、毎回同じ順序で確認できるため負担が下がります。設計書の品質が担当者の経験に左右されにくくなる点が、最も大きな効果です。

置き場所と更新のルールを決める

テンプレートの原本を1か所に置き、そこからコピーして使うルールにします。個人のPCに置かれた版が広まると、どれが最新か分からなくなります。

原本を更新できる人を決めてください。誰でも変えられる状態にすると、いつのまにか別物になっていきます。

プロジェクト終了後に改善する

案件が終わったら、使いにくかった箇所を振り返ります。埋まらなかった列、追加した列、レビューで毎回指摘された箇所が改善の材料になります。

この振り返りを1回でも行うと、テンプレートは実務に合った形に近づきます。配布されたままの様式を使い続けるより、はるかに効率が上がります。

標準化が失敗する原因

最も多いのは、項目を増やしすぎて使われなくなるパターンです。「念のため」の列が積み重なると、埋める負担が大きくなり、現場が独自の様式を使い始めます。

標準化の目的は、統制ではなく効率です。現場が使わない標準は、存在していないのと同じ結果になります。定期的に削る作業を組み込んでください。

設計書の標準化や社内ドキュメント運用の見直しも支援しています。資料でご確認いただけます。 ＞＞ 資料請求はこちら

テンプレート活用でつまずきやすい4つのパターン

実際のファイルを見ていると、繰り返し現れる問題があります。どれも最初のルール決めで防げます。

ここでは4つ挙げます。

埋めること自体が目的になる

空欄をなくす作業に集中すると、何のために書いているのかが抜け落ちます。文章は整っているのに、読んでも判断できない文書ができあがります。

各項目を書いたら「この記述で発注者は承認できるか」と自問してください。判断できない項目は、文字数ではなく具体性が足りていません。

使わない項目を空欄で残す

不要な様式や列を削らずに残すと、決まっていないのか対象外なのかが判別できません。レビューのたびに同じ確認が発生します。

対象外であることが分かるよう、削除するか「対象外」と明記してください。空欄のまま残すのが最も避けたい状態です。

セル結合と独自の色分けで扱いにくくなる

見た目を整えるためにセルを結合すると、並べ替えもフィルタも使えなくなります。一覧管理という利点が失われます。

色に意味を持たせる場合は、必ず凡例を用意してください。そもそも色ではなく列で表現したほうが、絞り込みもできて確実です。社外に渡す場合、色の意味は伝わりません。

版が乱立して最新が分からなくなる

メールに添付して往復するうちに、複数の版が並行して編集される状態です。反映漏れが発生し、どれが正しいのか誰にも分からなくなります。

編集するファイルを1つに固定し、その場所を関係者全員に周知してください。添付での受け渡しをやめるだけで、この問題は大きく減ります。

生成AIでテンプレートの作成と点検を効率化する

基本設計書の作成は、様式に沿って同じ形式の行を埋める繰り返し作業です。生成AIとの相性がよく、下書きと点検で時間を削減できます。

ここでは3つの使い方と、任せてはいけない範囲を整理します。

要件定義書から一覧系の行を起こす

要件定義書と機能一覧の列構成を渡し、行の草案を作らせます。機能ID、機能名、概要、対応要件IDの形に整理する作業を任せられます。

指示文には、出力する列と「要件定義書に書かれていない機能を追加しない」という条件を必ず入れてください。この条件を省くと、確認していない機能がもっともらしく書かれます。

成果物どうしの整合性を点検する

機能一覧と画面一覧、画面設計とテーブル定義を渡し、「対応が取れていない項目を挙げる」「矛盾する記述を指摘する」といった点検を依頼します。

人が複数のシートを突き合わせる作業は見落としが出ますが、機械的な照合なら漏れが減ります。IDが振られていれば、対応関係の確認も自動化できます。

自社テンプレートの項目を見直す

使っている様式を渡し、「判断に必要な情報が欠けている列を挙げる」「重複している項目を指摘する」と依頼します。長年使っている様式ほど、見直しの効果が出ます。

過去の設計書を数本渡して、常に空欄になっている列を洗い出させる使い方も有効です。削る候補が具体的に見つかります。

生成AIに任せてはいけない範囲

設計方針の決定と優先度の判断は人が行います。何を必須とし何を見送るかは、事業の状況と予算を踏まえた判断です。

業務として成立するかの判断も同様です。現場の実態と例外的な運用を知っているのは、その組織の人だけです。

また、業務内容や顧客情報を外部サービスに入力してよいかは、事前に社内規程で確認してください。入力内容が学習に使われない契約かどうかもあわせて確認が必要です。

業務でのAI活用を広く整理した内容は、業務効率化アイデア55選｜部門別30＋AI15＋明日から3つで成果を出す方法でも紹介しています。基本設計書の書き方や要件定義の進め方は、ネクストスケールのブログ一覧に掲載している個別の記事もあわせてご覧ください。

まとめ

基本設計書のテンプレートは1つのファイルではなく、機能一覧、画面一覧、テーブル定義といった複数の様式をまとめたものです。案件によって必要な成果物は変わります。

構成は、表紙や用語定義などの共通部、方針や業務フローなどの全体設計、機能や画面などの個別設計の3層で考えると整理しやすくなります。一覧を先に作り、そこから個別設計に展開する順序が効率的です。

カスタマイズは、足すより先に削るところから始めてください。使わない様式や列を残すと、空欄が決まっていないのか対象外なのか判別できなくなります。

一方で、対象範囲と対象外、要件との対応関係、非機能要件の根拠、データの保存期間、外部連携の責任分界点だけは削らないでください。後から復元できない情報です。

そして、テンプレートは案件が終わるたびに見直してください。埋まらなかった列と追加した列が、次の案件で使いやすい様式を作る材料になります。

システム開発やAI導入を、どこから・どの順番で進めるべきか。現状を伺ったうえで、具体的な進め方をご提案します。 ＞＞ 相談予約はこちら