基本設計書の書き方 構成要素8つと承認を得る記述のコツ、詳細設計との境界を解説

基本設計書をレビューに出したところ、発注者から「よく分からないので任せます」と言われて承認された。そして実装が終わった頃に「思っていたものと違う」と指摘が入る。設計工程で最も避けたい展開です。

原因は多くの場合、内容の不足ではなく書き方にあります。基本設計書の読み手は、システムの専門家ではありません。エンジニアには自然な表現が、発注者には判断材料になっていないのです。

基本設計書は、システムを外から見たときの動きを記述し、発注者の承認を得るための文書です。承認された時点で作るものが確定するため、この工程での確認漏れは後工程で高くつきます。

本記事では、基本設計書に書く8つの構成要素、承認を得るための記述の原則、詳細設計との境界の決め方、作成手順、そしてレビューを機能させる進め方までを順に解説します。

確認したいポイント	結論	詳細
基本設計書とは何を書く？	外から見たシステムの動きを記述する	画面、帳票、業務フロー、機能一覧が中心。発注者の承認を得るための文書。
誰に向けて書く？	発注者と利用部門。専門家ではない	専門用語をそのまま使うと、判断材料にならず形式的な承認になる。
どこまで書けばいい？	利用者から見える範囲まで	内部の処理方式やクラス構成は詳細設計。境界は事前に合意する。
承認が形骸化する原因は？	読み手が判断できる形になっていない	確認箇所を絞って提示し、立場ごとに観点を分けるとレビューが機能する。

この記事でわかること

• 基本設計書が果たす役割と、要件定義書・詳細設計書との関係
• 基本設計書に書く8つの構成要素と、それぞれの記載内容
• 発注者の承認を得るための記述の5原則（悪い例と良い例の対比つき）
• 詳細設計との境界の決め方と、曖昧になりやすい3つの領域
• 作成手順6ステップと、レビューを形骸化させない進め方

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

基本設計書は発注者の承認を得るための文書

書き方に入る前に、この文書が誰のために存在するのかを確認しておきます。ここを取り違えると、丁寧に書いても承認の役に立ちません。

ここでは読み手、工程上の位置づけ、そして承認が持つ意味を整理します。

読み手は非エンジニアである

基本設計書の主な読み手は、発注者と実際にシステムを使う利用部門です。詳細設計書の読み手が実装エンジニアであるのに対し、こちらは技術の専門家ではありません。

そのため、内部の処理方式やデータ構造を細かく書いても、読み手は判断できません。求められているのは「この画面でこの操作をすると、こうなる」という、業務の言葉での説明です。

エンジニアが自然だと感じる書き方と、発注者が判断できる書き方は違います。この差を埋めることが、基本設計書の書き方の中心的な課題になります。

要件定義書と詳細設計書の間に位置する

要件定義書は「何を実現するか」を決める文書です。基本設計書は、それを「どんな画面や帳票で実現するか」に具体化します。そして詳細設計書が「内部でどう作るか」を決めます。

基本設計書は、この2つをつなぐ位置にあります。上流の要件をすべて受けきり、下流の実装に引き渡せる形にする役割です。

要件定義書に書かれた要件のうち、基本設計書のどこで実現されるのかを追えるようにしてください。対応が取れていない要件は、実現手段が決まっていないということです。

承認された時点で作るものが確定する

基本設計書に対する承認は、単なる確認作業ではありません。承認をもって作る対象が確定し、以降の変更は原則として追加費用と日程の再調整が発生します。

実装が終わってから画面項目を1つ足すのと、基本設計の段階で足すのとでは、必要な工数が大きく異なります。

だからこそ、承認の前に読み手が本当に判断できたのかが重要になります。「分からないので任せます」という承認は、実質的に何も確認していないのと同じ結果になります。

基本設計書に書く8つの構成要素

ここからは具体的な中身に入ります。案件によって増減しますが、共通して必要になるのは次の8つです。

順に、何を書くのかと記載の観点を示します。

要素1｜システム化の方針と対象範囲

このシステムで何を実現するのか、どの業務・どの部署を対象とするのかを書きます。あわせて、今回は対象としないものも明記します。

対象外を書かないと、発注者は「当然含まれる」と考えます。「在庫管理のみを対象とし、会計連携は次期開発とする」の1行が、後の認識のずれを防ぎます。

要素2｜業務フロー

システム導入後に、業務がどう流れるのかを図で示します。誰が何をして、どこでシステムが介在するのかを表現します。

現行の業務フローと並べて示すと、何が変わるのかが伝わります。発注者が最も確実に判断できるのが、この業務フローです。画面より先に、ここを確認してもらってください。

例外的な運用も忘れずに描きます。「特定の取引先だけ別対応している」といった実態は、この段階で拾わないと後で仕様変更になります。

要素3｜機能一覧

システムが備える機能を、IDを振って一覧にします。機能名、概要、対応する業務要件、優先度を列にします。

要件定義書のIDと結びつけてください。この対応があると、要件が抜けていないかを機械的に確認できます。

要素4｜画面設計

画面一覧、画面遷移図、そして画面ごとのレイアウトと表示項目を記述します。入力できる項目、選択肢、ボタンを押したときの動きを示します。

画面遷移図は、上から下、左から右へ流れるように配置すると読みやすくなります。発注者が実際の操作を頭の中で追える配置になっているかを、描いた後に確認してください。

正常時の画面だけでなく、入力エラーが出たときの画面も示します。エラー時の挙動は、後で必ず質問が出る箇所です。

要素5｜帳票設計

出力する帳票の一覧と、それぞれの様式、出力条件、出力先を記述します。

帳票は社外に出るものが多く、体裁の要求が細かい領域です。現行で使っている実物を並べて確認してもらうと、指摘が早く出ます。

要素6｜データ設計（利用者から見える範囲）

扱うデータの種類、保存期間、件数の見込みを書きます。テーブルの詳細な定義は詳細設計に譲り、ここでは利用者が判断できる粒度にとどめます。

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

発注者に確認してもらうのは、データがいつ作られ、いつ更新され、いつ消えるのかという流れです。「退職した社員の情報はいつまで残るのか」といった問いに答えられる状態にします。

要素7｜外部システムとの連携

連携する相手のシステム、やり取りするデータの種類、連携の方式とタイミングを一覧にします。

外部連携は見積もり金額に大きく影響する項目です。後から追加されると設計のやり直しになるため、この段階で漏れなく洗い出します。

相手方のシステムを管理している部署や会社が別の場合は、この項目だけ先に合意を取っておくと日程が安定します。

要素8｜非機能要件

性能、可用性、セキュリティ、運用の条件を数値で示します。応答時間、同時利用者数、稼働時間、バックアップの頻度などが該当します。

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

「速い」「安定している」といった表現のまま承認されると、完成したかどうかを判定できません。数値に落とす作業は、必ずこの工程で行ってください。

8要素の一覧

整理すると次のようになります。発注者の確認が特に重要なものを分けて示します。

要素	記載する内容	発注者の確認
1. 方針と対象範囲	目的、対象業務・部署、対象外	必須
2. 業務フロー	導入後の業務の流れ、例外運用	必須
3. 機能一覧	機能ID、概要、対応要件、優先度	必須
4. 画面設計	画面一覧、遷移図、表示・入力項目	必須
5. 帳票設計	帳票一覧、様式、出力条件	必須
6. データ設計	データの種類、保存期間、件数見込み	保存期間を確認
7. 外部連携	連携先、データ、方式、タイミング	連携先と合意
8. 非機能要件	性能、可用性、セキュリティ、運用	数値の妥当性を確認

設計内容の確認や開発会社とのやり取りを、発注者側の立場で伴走支援しています。 ＞＞ 相談予約はこちら

承認を得るための記述の5原則

ここが本記事の中心です。同じ内容でも、書き方によって発注者が判断できるかどうかが変わります。

悪い例と良い例を並べながら、5つの原則を見ていきます。

原則1｜業務の言葉で書き、専門用語には注釈をつける

技術用語をそのまま使うと、読み手は意味を推測するか、確認を諦めます。

悪い例：受注データをバッチでインポートし、マスタとの整合性チェック後にコミットする。

この記述では、いつ処理されるのか、エラーがあったときにどうなるのかが読み取れません。

良い例：受注一覧のCSVファイルを取り込むと、毎日20時に自動で登録処理が動きます。取引先コードが登録されていない行があった場合、その行だけ取り込まず、翌朝に担当者へエラー一覧をメールで通知します。

専門用語を使う必要がある場合は、初出時に業務上の意味を添えてください。用語集を別に作るより、その場で説明したほうが読まれます。

原則2｜正常時だけでなく例外時も示す

正常な流れだけを描いた業務フローや画面設計は、実際の運用を想像させません。現場が知りたいのは、うまくいかなかったときにどうなるかです。

入力を間違えたとき、承認者が不在のとき、締め日をまたいだとき。こうした場面を1つずつ示すと、発注者から具体的な指摘が出てきます。

指摘が出るということは、読み手が内容を理解している証拠です。何も出ないレビューのほうが危険な状態です。

原則3｜判断が必要な箇所は選択肢を並べる

決まっていない事項を空欄にしておくと、そのまま見過ごされます。かといって「どうしますか」とだけ聞いても、発注者は判断材料を持っていません。

悪い例：承認者が不在の場合の扱いは要確認。

良い例：承認者が不在の場合、次の2案が考えられます。A案：代理承認者をあらかじめ登録し、3営業日を過ぎたら自動で代理承認者に回す（追加費用の目安：小）。B案：不在時は保留とし、担当者が個別に依頼する（追加費用なし）。どちらを採用するかご判断ください。

選択肢と、それぞれの影響を並べると、発注者はその場で決められます。判断が早く進み、未決事項が減ります。

原則4｜変えられる範囲と変えられない範囲を明示する

発注者は、どこまでが要望を出してよい範囲なのかが分かりません。すべて決定事項に見えると、遠慮して指摘を控えます。

画面の項目の並びは後からでも変えられる、データの持ち方は今決めないと後で変更できない、といった区別を示してください。

「この項目は基本設計の承認後は変更に追加費用が発生します」と書き添えるだけで、確認の密度が変わります。

原則5｜図と説明をセットにする

図は全体の流れを示すのに向いていますが、条件や例外を表すのは苦手です。業務フロー図の分岐に条件が書かれていないと、読み手は何を判定しているのか分かりません。

分岐の矢印には必ず条件を添え、図の下に補足を書いてください。「はい／いいえ」だけの分岐は、説明したことになりません。

画面設計も同様です。レイアウト図の横に、項目ごとの入力条件と桁数を表で並べると、確認しやすくなります。

詳細設計との境界をどこに引くか

基本設計の書き方でよく迷うのが、どこまで踏み込むかです。踏み込みすぎると発注者には読めなくなり、浅すぎると詳細設計に渡せません。

ここでは境界の考え方と、曖昧になりやすい領域を整理します。

境界は「利用者から見えるかどうか」

判断の軸は単純です。利用者の操作や業務の結果として現れることは基本設計、内部の実現方法は詳細設計に置きます。

画面に何が表示されるかは基本設計、その値をどのテーブルから取得するかは詳細設計。エラーメッセージの文言は基本設計、それを判定するロジックは詳細設計です。

迷ったら「発注者がこれを読んで判断できるか」を自問してください。判断できない内容は、基本設計書には不要です。

含める／含めないの整理

具体的に並べると次のようになります。

領域	基本設計に含める	詳細設計に譲る
画面	レイアウト、表示項目、入力条件、遷移	イベント処理、部品の実装方式
機能	機能一覧、処理の概要、実行タイミング	モジュール分割、クラス構成
データ	扱うデータの種類、保存期間、件数	テーブル定義、カラム型、インデックス
連携	連携先、データ項目、方式、頻度	通信の実装方式、リトライ処理
エラー	利用者への表示内容と対処方法	判定ロジック、ログ出力の内容

曖昧になりやすい3つの領域

境界が判断しにくいのは次の3つです。

1つ目は権限設計です。誰が何をできるかは業務の話なので基本設計、その判定をどこで行うかは詳細設計になります。

2つ目はバッチ処理です。いつ何のために動くかは基本設計、処理の順序や並列化は詳細設計です。

3つ目は性能要件です。応答時間の目標は基本設計で決めますが、それを実現する方式は詳細設計の判断になります。目標値だけを合意し、手段は開発側に委ねる形にします。

境界は着手前に合意しておく

会社やプロジェクトによって、境界の引き方は異なります。正解が1つあるわけではありません。

重要なのは、着手前に発注者と開発側で合意しておくことです。成果物の一覧と、それぞれに何を書くかを1枚にまとめて確認しておくと、検収時の議論を防げます。

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

基本設計書の作成手順6ステップ

構成要素がそろっても、書く順序を間違えると手戻りが発生します。画面から作り始めると、業務の流れが変わったときに全部描き直しになります。

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

ステップ1｜要件定義書を読み込んで不足を洗い出す

最初に要件定義書を読み、矛盾や曖昧な記述がないかを確認します。実現方法が複数考えられる要件は、この段階で選択肢を整理しておきます。

要件定義の成果物が不十分なまま基本設計に入る案件もあります。その場合は、業務要件と非機能要件を基本設計工程で改めて確認してください。終盤での大きな手戻りを防げます。

ステップ2｜業務フローを描く

導入後の業務の流れを先に固めます。誰が何をして、どこでシステムが関わるのかを図にします。

現場の担当者に見せて確認する往復を必ず入れてください。マニュアルどおりでない運用は、この確認でしか見つかりません。

ステップ3｜機能一覧に落とす

業務フローの中でシステムが担う部分を、機能として切り出します。IDを振り、対応する業務要件と結びつけます。

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

ステップ4｜画面と帳票を設計する

機能一覧をもとに、画面と帳票を設計します。画面一覧、遷移図、レイアウトの順に作ると整理しやすくなります。

エラー時の画面もこの段階で作ります。正常系だけを作って後回しにすると、実装時にまとめて質問が発生します。

ステップ5｜データと非機能要件を固める

扱うデータの種類、保存期間、件数の見込みを整理します。あわせて、性能や可用性の条件を数値で決めます。

数値の判断に迷う場合は、現行業務で許容されている水準を基準にします。いま検索に1分かかって業務が回っているなら、5秒以内は十分な目標です。

ステップ6｜レビューを受けて承認をもらう

まず開発チーム内でレビューし、その後に発注者と利用部門のレビューに進みます。指摘を反映してから承認を受けます。

承認時には、日付と版数を記録します。以降の変更は変更履歴として残し、どの時点の内容が生きているかを追える状態にしてください。

レビューを形骸化させない進め方

分厚い設計書を渡して「確認してください」と伝えるだけでは、レビューは機能しません。読み切れず、そのまま承認されます。

ここでは実際に指摘が出るようにするための4点を挙げます。

確認してほしい箇所を絞って提示する

全体を読んでもらうのではなく、判断が必要な箇所を先に伝えます。「今回は業務フローの承認ルートと、受注画面の入力項目を重点的に見てください」といった形です。

未決事項の一覧を1枚にまとめて添えると、確認の効率が上がります。選択肢と影響を並べておけば、その場で決まります。

立場ごとに見る観点を分ける

レビュー参加者が同じ目線で読むと、見つかる問題の種類が偏ります。役割ごとに観点を割り当てます。

利用者は「この業務が回るか」、運用担当は「障害時と締め処理をどうするか」、保守担当は「将来の変更に耐えるか」、テスト担当は「この記述で検証項目を作れるか」を見ます。

実際の利用方法を想定せずに設計を進めると、稼働後に使いにくいという評価になります。利用者の観点は、必ず現場の担当者に見てもらってください。

口頭で答えた内容を文書に反映する

レビュー中に質問が出て、その場で口頭で回答して終わりにするケースがあります。しかし口頭の回答は記録に残らず、後で誰も覚えていません。

質問が出た箇所は、記述が不足している証拠です。回答した内容をそのまま設計書に追記してください。同じ質問が二度出なくなります。

承認の記録を残す

誰がいつ、どの版を承認したのかを記録します。承認者の役職と氏名、日付、版数を残しておきます。

これは責任追及のためではなく、後から経緯を追うためです。「なぜこの仕様になったのか」を調べるとき、承認時の議事録とセットで参照されます。

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

つまずきやすい4つのパターン

基本設計書に関する問題には、繰り返し現れる型があります。どれも書き方の工夫で防げます。

ここでは4つ挙げます。

エンジニア目線で書いてしまう

最も多い問題です。書き手が普段使っている言葉で書くため、専門用語が並びます。書いた本人には自然でも、読み手は判断できません。

書き上げたら、システムに詳しくない人に1ページだけ読んでもらってください。詰まった箇所が、そのまま直すべき箇所です。

要件定義書と内容が乖離する

設計を進めるうちに、要件定義で決めた内容から外れていく状態です。実現しやすい形に寄せた結果、当初の目的を満たさなくなります。

要件のIDと機能のIDを対応表で管理してください。すべての要件が機能のどこかに現れているかを、定期的に確認します。

詳細設計に踏み込みすぎる

クラス構成やテーブル定義まで書き込んでしまい、発注者には読めない文書になるパターンです。分量も膨らみ、レビューの負担が増えます。

基本設計の段階で内部の作りを決めきると、実装時により良い方法が見つかっても変更しにくくなります。開発側の裁量を残す意味でも、境界は守ってください。

承認だけもらって中身が確認されていない

形式的に承認印は押されたが、実際には読まれていない状態です。実装後の指摘という形で、必ず表面化します。

レビューで質問も指摘もまったく出なかった場合は、内容が伝わっていないと考えてください。確認箇所を絞り直し、口頭で説明する場を設けたほうが結果的に早く進みます。

生成AIを使った基本設計書の作成

基本設計書の作成は、要件定義書の内容を具体化し、同じ形式の記述を機能の数だけ繰り返す作業です。生成AIとの相性がよく、下書きと点検で時間を削減できます。

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

要件定義書から機能一覧の草案を作る

要件定義書を渡し、機能ID、機能名、概要、対応要件の列に沿って草案を作らせます。工程をまたぐ転記と具体化の作業を任せられます。

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

専門用語を業務の言葉に言い換える

書き上げた設計書を渡し、「システムに詳しくない読み手が理解できない表現を挙げ、業務の言葉での言い換え案を出す」と依頼します。

書いた本人には専門用語が自然に見えるため、この点検は自力では難しい作業です。第三者の視点で機械的に洗い出すと、思わぬ箇所が見つかります。

例外パターンを洗い出す

業務フローや画面設計を渡し、「考慮されていない例外的な状況を挙げる」と依頼します。入力の誤り、担当者の不在、締め日の重なりといった観点が出てきます。

出てきた候補のうち、自社で実際に起こり得るものを選んで設計に反映します。すべてを採用する必要はありません。

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

業務として成立するかの判断は人が行います。現場の実態、例外的な運用、部門間の力関係を知っているのは、その組織の人だけです。

発注者との合意形成も同様です。基本設計書は文書を作ることが目的ではなく、関係者が同じ理解に立って承認するための手段です。

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

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

まとめ

基本設計書は、システムを外から見たときの動きを記述し、発注者の承認を得るための文書です。読み手は技術の専門家ではないという前提から、書き方が決まります。

構成要素は、方針と対象範囲、業務フロー、機能一覧、画面設計、帳票設計、データ設計、外部連携、非機能要件の8つです。このうち発注者が必ず確認すべきなのは、業務フローと画面・帳票です。

承認を得るための記述では、業務の言葉で書く、例外時も示す、判断が必要な箇所は選択肢を並べる、変えられる範囲を明示する、図と説明をセットにする、の5原則を押さえてください。

詳細設計との境界は「利用者から見えるかどうか」で判断します。踏み込みすぎると読めない文書になり、開発側の裁量も奪います。

そして、レビューで何も指摘が出なかったときこそ警戒してください。内容が伝わっていない可能性があります。確認箇所を絞り、立場ごとに観点を分けると、レビューは機能し始めます。

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