基本設計書のサンプル・記入例 記載項目と書き方、テンプレート活用のポイントを解説

「要件定義が終わり基本設計に進むが、基本設計書に何をどこまで書けばよいかわからない」「テンプレートは手に入れたが、各項目の具体的な記入例が見たい」という声は、初めて設計工程に携わる担当者や、開発会社から提出された基本設計書を確認する発注側の担当者からよく聞かれます。

この記事では、基本設計書の役割と記載項目を整理したうえで、架空のプロジェクトを題材にした記入例を項目ごとに掲載し、書き方のコツ、テンプレートのカスタマイズ方法、活用時の注意点までを解説します。まずは、この記事の要点を表で確認してください。

確認したいポイント	結論	詳細
基本設計書とは何を書く文書？	要件を画面・データ・構成に落とし込む文書	要件定義の「何を」を「どう実現するか」に変換し、発注者が承認できる粒度で記載。詳細設計書は実装者向け
記載項目は？	設計方針から非機能・テスト方針まで10項目	文書概要、システム構成、機能一覧、画面、帳票、データベース、外部連携、バッチ、非機能設計、テスト・移行方針
サンプルで何がわかる？	各項目の具体的な記入粒度と対応付けの方法	問い合わせ対応支援システムを題材に、画面項目・テーブル定義・外部連携・AI機能の設計例を掲載
活用時の注意点は？	要件との対応確認と読み手に合った粒度	要件IDと設計IDの対応表で抜け漏れを防ぎ、発注側は業務面を必ず確認。未確定事項は分けて書き、更新を続ける

この記事でわかること

• 基本設計書の役割と、要件定義書・詳細設計書との違い
• 基本設計書に含める10の記載項目と、それぞれに書く内容
• 架空の問い合わせ対応支援システムを題材にした、項目別の記入例
• 画面設計・データベース設計・非機能設計などを書くときのコツ
• テンプレートを自社のプロジェクトに合わせる方法と、活用時の注意点

基本設計書とは

基本設計書とは、要件定義で決めた「何を実現するか」をもとに、システムを「どのような構成と仕組みで実現するか」を定めた文書です。ここでは、基本設計書の役割、前後の工程の文書との違い、公的な枠組みでの位置づけ、作成者と読み手を整理します。

基本設計書の役割

基本設計書は、要件定義書に書かれた機能要件・非機能要件を、システムの構成・画面・データ・外部連携といった具体的な設計に落とし込んだ文書です。外部設計や概要設計と呼ばれることもあり、利用者から見えるシステムの姿を定めるため、発注者が内容を確認して承認する対象になります。

基本設計書が承認されると、その内容をもとに詳細設計・実装・テストが進みます。要件定義と実装をつなぐ橋渡しであり、発注者と開発者が「どのようなシステムになるか」を合意する最後の文書といえます。

要件定義書・詳細設計書との違い

• 要件定義書：システムが「何を実現するか」を定める。業務要件・機能要件・非機能要件を記載し、発注者が主体で作成する
• 基本設計書：要件を「どのような画面・データ・構成で実現するか」を定める。利用者や発注者から見える範囲を設計し、開発者が作成して発注者が承認する
• 詳細設計書：基本設計を「どのようにプログラムとして実装するか」を定める。モジュール構成や処理ロジックを記載し、開発者向けに作成する

読み手が異なる点が重要です。基本設計書は発注者や業務担当者が読んで理解・承認できる粒度で書き、詳細設計書は開発者が実装できる粒度で書くという違いを意識すると、何をどこまで書くかの判断がしやすくなります。

公的な開発プロセスの枠組みにおける位置づけ

独立行政法人情報処理推進機構（IPA）が公開している「共通フレーム2013」は、システムやソフトウェアの構想から開発・運用・保守に至るライフサイクルを通じて必要な作業項目や役割を包括的に規定した共通の枠組みです。このなかで基本設計に相当する工程は「システム方式設計プロセス」と「ソフトウェア方式設計プロセス」として定義されており、システム構成の決定、ソフトウェア構造の設計、外部インターフェースの設計、データベースの最上位レベルの設計などが含まれます。

（出典：独立行政法人情報処理推進機構（IPA）「共通フレーム2013」 https://www.ipa.go.jp/publish/secbooks20130304.html）

共通フレームは、発注者と開発者が「同じ言葉で話す」ための枠組みとして作られており、工程名や成果物の呼び方が会社ごとに異なる場合でも、どの作業に相当するかを確認する基準になります。自社と開発会社で「基本設計」の範囲の認識が合っているかを確認する際に活用できます。

誰が作成し、誰が読むのか

基本設計書は通常、開発会社（または社内の開発チーム）が作成します。ただし、画面の項目や業務の流れ、データの意味など、業務に関する判断は発注側でなければできません。開発会社が設計案を提示し、発注側の業務担当者が確認・修正を依頼するという協働で作られるのが一般的です。

読み手は、発注側の業務担当者・情報システム部門、開発側の設計者・実装者・テスト担当者と幅広くなります。発注側は「業務がこの設計で回るか」、開発側は「この設計で実装できるか」という観点で読むため、両方の読み手に伝わる書き方が求められます。

基本設計書の構成と記載項目

基本設計書の様式はプロジェクトや会社によって異なりますが、記載する項目はおおむね共通しています。ここでは、一般的な基本設計書に含める10の項目と、それぞれに書く内容を解説します。次章のサンプルも、この構成に沿って記載しています。

1. 文書概要と設計方針

文書の目的、対象読者、関連文書（要件定義書など）、改訂履歴を記載します。あわせて、設計全体で共通する方針（採用する技術、画面や処理の共通ルール、命名規則など）を冒頭で示しておくと、以降の設計の一貫性が保たれます。

2. システム構成（方式設計）

システム全体の構成を、構成図とともに記載します。サーバーやクラウドサービスの構成、ネットワーク、利用するミドルウェアやフレームワーク、開発言語、認証の方式などです。要件定義の技術要件や制約を、具体的な構成として確定させる項目です。

3. 機能一覧と業務フロー

要件定義の機能要件をもとに、システムが提供する機能を一覧にし、それぞれの機能がどの画面・バッチ・連携で実現されるかを対応付けます。また、システム導入後の業務フローを、システムの機能と担当者の操作が対応する形で記載します。

4. 画面設計

画面一覧、画面遷移図、各画面のレイアウト（画面イメージ）、画面項目の定義（項目名、入力形式、桁数、必須かどうか、入力チェック）、ボタンや操作ごとの動作を記載します。利用者が直接触れる部分であり、発注側の確認が最も重要になる項目です。

5. 帳票設計

システムが出力する帳票やレポートの一覧、各帳票のレイアウト、出力項目、出力条件、出力形式（PDF、Excel、CSVなど）を記載します。既存の帳票を置き換える場合は、現行帳票との対応も示します。

6. データベース設計

データの全体像（ER図など）、テーブル一覧、各テーブルの項目定義（項目名、型、桁数、主キー、必須、初期値、説明）、マスタデータの管理方法、データの保持期間を記載します。基本設計では、詳細な物理設計よりも、業務上必要なデータが漏れなく定義されていることを重視します。

7. 外部インターフェース設計

既存システムや外部サービスとの連携について、連携先、連携方式（API、ファイル連携など）、連携する項目、タイミング、エラー時の扱いを記載します。連携先の仕様に依存する部分は、確認状況や前提条件も明記します。

8. バッチ処理設計

定期的に自動実行する処理（データ取り込み、集計、通知など）の一覧、実行タイミング、処理内容、処理順序、異常終了時の対応を記載します。

9. 非機能設計

要件定義の非機能要件を、具体的な設計として記載します。性能を満たすための構成やキャッシュの方針、可用性を確保するための冗長化やバックアップ、セキュリティ対策（認証・権限・暗号化・ログ）、運用監視の仕組みなどです。

10. テスト方針と移行方針

基本設計をもとに実施するテスト（結合テスト、総合テスト、受入テスト）の範囲と方針、テスト環境、合格基準の考え方を記載します。あわせて、データ移行の方法や切り替え手順の方針も、この段階で設計しておきます。

すべての項目を同じ深さで書く必要はありません。プロジェクトの性質に応じて重点項目を決め、要件定義書の内容がすべて設計に反映されているかを確認することが基本です。

【無料資料のご案内】 要件定義から基本設計・開発・運用までを一貫して支援するサービスの内容や、設計工程の進め方をまとめた資料を無料でご用意しています。まずは概要を確認したい方は、以下から資料をご請求ください。 ▶ 資料請求はこちら（https://nextscale.co.jp/service-document/）

【サンプル】問い合わせ対応支援システムの基本設計書

ここからは、架空のプロジェクトを題材にした基本設計書の記入例を紹介します。題材は、中堅のBtoB企業が顧客からの問い合わせを一元管理し、過去の対応履歴やFAQをもとにAIが回答案を作成する「問い合わせ対応支援システム」です。実際の基本設計書はこれより詳細になりますが、各項目の書き方のイメージをつかんでください。

この題材は、要件定義書のサンプル・記入例の記事で紹介した要件定義書と同じプロジェクトです。要件がどのように設計へ落とし込まれるかを、あわせて確認できます。

1. 文書概要と設計方針（記入例）

• 文書の目的：本書は、問い合わせ対応支援システム（以下「本システム」）の要件定義書（第1.2版）に基づき、システムの構成・画面・データ・外部連携・非機能の設計を定めるものである
• 対象読者：営業部門責任者、営業事務担当者、情報システム部門、開発会社の設計・実装・テスト担当者
• 設計方針1：Webアプリケーションとして構築し、利用者はブラウザから操作する。画面は一覧・詳細・編集の共通レイアウトを採用する
• 設計方針2：顧客・製品・在庫・納期の情報は基幹システムを正とし、本システムは参照用に複製する。本システムから基幹システムのデータは更新しない
• 設計方針3：AI回答案生成は外部のAIサービスを利用し、本システムからAPIで呼び出す。回答案はそのまま送信されず、必ず担当者の確認を経る
• 命名規則：画面IDは「SCR-」、テーブルは「T_」、バッチは「BAT-」、外部連携は「IF-」を接頭辞とする

設計方針は、以降のすべての設計の前提になります。要件定義で決めた制約（データの正はどこか、AIの出力をどう扱うか）を設計方針として明文化することで、個々の設計判断がぶれなくなります。

2. システム構成（記入例）

• 構成方針：国内リージョンのクラウド上に、Webサーバー・アプリケーションサーバー・データベースサーバーを配置する。本番環境とテスト環境を分離する
• 利用者の接続：社内ネットワークからのみ接続を許可し、社外からの接続はVPN経由とする
• 認証：既存の社内認証基盤（シングルサインオン）と連携し、ログイン時に多要素認証を必須とする
• 外部接続：基幹システム（社内）、メールサーバー（社内）、AIサービス（外部）の3系統。AIサービスへの通信は暗号化し、送信するデータは問い合わせ本文と参照情報に限定する
• 開発言語・フレームワーク：開発会社の標準に従う（要件定義書の制約を満たすこと）。採用技術は別紙「技術選定書」に記載する

システム構成は、構成図とあわせて示すと理解しやすくなります。要件定義の技術要件や制約が、構成のどこで満たされているかを対応付けて書くことがポイントです。

3. 機能一覧と実現方法（記入例）

要件定義の機能要件（F-001〜F-009）を、画面・バッチ・外部連携のどれで実現するかを対応付けます。

• F-001 問い合わせ取り込み → BAT-001 メール取り込みバッチ（5分間隔）、SCR-010 Webフォーム受付画面
• F-002 担当者自動割り当て → BAT-001 内の割り当て処理、SCR-090 割り当てルール設定画面
• F-003 類似問い合わせ検索 → SCR-030 類似検索画面、SCR-020 案件詳細画面内の検索機能
• F-004 AI回答案生成 → IF-003 AIサービス連携、SCR-020 案件詳細画面内の回答案表示
• F-005 回答送信 → SCR-020 案件詳細画面の送信機能、IF-002 メール送信連携
• F-006 進捗管理ダッシュボード → SCR-040 ダッシュボード画面、BAT-002 期限超過通知バッチ
• F-007 FAQ管理 → SCR-050 FAQ一覧画面、SCR-051 FAQ編集画面
• F-008 対応レポート → SCR-060 レポート画面、BAT-003 月次集計バッチ
• F-009 顧客向けFAQサイト連携 → 本フェーズでは対象外（次フェーズで設計）

要件IDと設計上の実現手段を対応付けることで、要件の抜け漏れがないことを確認でき、後のテストでも「どの要件をどの画面で検証するか」が明確になります。

4. 画面設計（記入例）

画面一覧の例は次のとおりです。

• SCR-001 ログイン画面：認証基盤と連携してログインする
• SCR-010 案件一覧画面：案件を状態・担当者・期間で絞り込み、一覧表示する
• SCR-020 案件詳細・回答画面：問い合わせ内容、顧客情報、過去履歴、AI回答案を表示し、回答を編集・送信する
• SCR-030 類似検索画面：キーワードと類似度で過去の案件を検索する
• SCR-040 ダッシュボード画面：状態別の件数、担当者別の対応状況、期限超過案件を表示する
• SCR-050／051 FAQ一覧・編集画面：FAQの登録・更新・分類を行う
• SCR-060 レポート画面：月次集計を表示し、CSVで出力する
• SCR-090 設定画面：割り当てルール、ユーザー、権限を管理する

画面項目定義の例として、SCR-020 案件詳細・回答画面の主要項目を示します。

• 案件ID：表示のみ。自動採番（形式：年月日＋4桁連番）
• 受付日時：表示のみ。取り込み時の日時
• 顧客名・担当者名：表示のみ。基幹システムの顧客マスタから取得
• 分類：選択式（納期・在庫・見積・仕様・その他）。自動分類の結果を初期表示し、担当者が変更可能
• 問い合わせ本文：表示のみ。最大5,000文字
• AI回答案：表示のみ。参照した情報源と確信度（高・中・低）を併せて表示。「回答欄にコピー」ボタンで回答欄に転記する
• 回答本文：入力必須。最大5,000文字。テンプレートの挿入が可能
• 状態：選択式（未着手・対応中・回答済み・完了）。回答送信時に「回答済み」へ自動更新
• 送信ボタン：回答本文が未入力の場合はエラーを表示。送信前に確認ダイアログを表示する

画面設計は、レイアウトのイメージと項目定義をセットで示します。「AIの回答案はコピー操作を経なければ回答欄に入らない」といった業務上の制約を、画面の動作として設計に反映することが重要です。

5. データベース設計（記入例）

主要なテーブル一覧は次のとおりです。

• T_CASE（案件）：案件の基本情報と状態を管理する
• T_CASE_HISTORY（案件履歴）：案件に対するやり取りと状態変更の履歴を管理する
• T_CUSTOMER（顧客）：基幹システムから複製した顧客情報。参照のみ
• T_PRODUCT（製品）：基幹システムから複製した製品情報。参照のみ
• T_FAQ（FAQ）：よくある問い合わせと回答、分類、更新日を管理する
• T_ASSIGN_RULE（割り当てルール）：分類と担当者の対応を管理する
• T_USER（ユーザー）：利用者と権限を管理する

テーブル定義の例として、T_CASE の主要項目を示します。

• case_id：文字列12桁、主キー、案件ID
• received_at：日時、必須、受付日時
• channel：文字列1桁、必須、受付経路（1：メール、2：Webフォーム、3：電話）
• customer_id：文字列10桁、必須、顧客ID（T_CUSTOMERを参照）
• category：文字列1桁、必須、分類（1：納期、2：在庫、3：見積、4：仕様、9：その他）
• body：文字列5,000桁、必須、問い合わせ本文
• assignee_id：文字列8桁、任意、担当者ID（T_USERを参照）
• status：文字列1桁、必須、状態（1：未着手、2：対応中、3：回答済み、4：完了）
• ai_draft：文字列5,000桁、任意、AI回答案
• answered_at：日時、任意、回答日時
• updated_at：日時、必須、更新日時

保持期間として、案件データは完了から5年間保持し、年次バッチで削除する方針を記載します。業務上必要な項目が漏れなく定義され、参照関係が明確であることが基本設計でのデータベース設計の要点です。

6. 外部インターフェース設計（記入例）

• IF-001 基幹システム連携：顧客・製品・在庫・納期情報を1時間ごとにファイル連携で取得する。形式はCSV、文字コードはUTF-8。取得失敗時は前回データを保持し、管理者に通知する
• IF-002 メール連携：共有メールアドレスの受信メールをIMAPで取得し、本システムからの送信はSMTPで行う。添付ファイルは10MBまで保存する
• IF-003 AIサービス連携：問い合わせ本文と参照情報（類似案件の回答、FAQ、製品情報）をAPIで送信し、回答案と確信度を受け取る。応答は60秒以内、タイムアウト時は「回答案なし」として担当者に表示する。送信データに顧客の個人情報を含めない

外部連携は、相手先の仕様や制約に依存するため、確認済みの事項と未確認の前提を分けて記載することで、後の工程でのトラブルを防げます。

7. バッチ処理設計（記入例）

• BAT-001 メール取り込み・割り当て：5分間隔。受信メールを案件として登録し、分類と担当者を自動設定する。同一メールの重複登録を防ぐため、メールIDで判定する
• BAT-002 期限超過通知：1時間ごと。受付から4時間を超えて未回答の案件を抽出し、担当者と管理者に通知する
• BAT-003 月次集計：毎月1日の深夜に実行。前月の件数・分類別件数・平均回答時間を集計し、レポート用データを作成する
• BAT-004 データ保持期間管理：毎年4月1日に実行。完了から5年を経過した案件を削除する

8. AI回答案生成の設計（記入例）

AIを含む機能は、一般的なシステムとは異なる設計上の配慮が必要です。本サンプルでは次のように設計します。

• 参照情報の選定：問い合わせ本文と類似度の高い過去案件の回答を上位5件、分類が一致するFAQを上位5件、本文中の製品名に対応する製品情報を参照情報として抽出する
• 回答案の生成：参照情報とともに「回答案を作成し、根拠とした情報を示す」旨の指示をAIサービスに送信する。参照情報にない事項は「確認が必要」と明示するよう指示する
• 確信度の判定：類似案件の類似度とFAQの一致度から高・中・低を判定し、担当者に表示する
• 品質管理：担当者が回答案を「そのまま採用」「修正して採用」「不採用」のいずれかで評価し、T_CASE_HISTORYに記録する。月次で採用率を集計し、参照情報の見直しに活用する
• 安全対策：AIサービスへの送信前に、顧客名・メールアドレス・電話番号を除去する。回答案は担当者の操作なしには顧客に送信されない

AIの出力は常に正しいとは限らないため、「人が確認する前提の業務フロー」と「精度を継続的に改善する仕組み」を設計に組み込むことが、AI機能の基本設計の要点です。

9. 非機能設計（記入例）

• 性能：案件一覧の表示は初期表示100件に制限し、追加読み込み方式とする。類似検索は事前に計算した索引を利用し、3秒以内の応答を実現する
• 可用性：アプリケーションサーバーを2台構成とし、1台の障害時も稼働を継続する。データベースは日次のフルバックアップに加え、1時間ごとの差分バックアップを取得する
• セキュリティ：役割（担当者・管理者・閲覧者）ごとに画面と操作の権限を設定する。操作ログには操作者・日時・操作内容・対象案件を記録し、1年間保存する。通信はすべて暗号化する
• 運用監視：サーバーの稼働状況、バッチの実行結果、外部連携の成否を監視し、異常時は情報システム部門に通知する
• 拡張性：月間3,000件の問い合わせに対応できる容量を確保し、将来のチャット連携のために受付経路の追加が容易な構造とする

10. テスト方針と移行方針（記入例）

• 結合テスト：画面・バッチ・外部連携を結合し、要件IDごとに機能が実現されていることを確認する。開発会社が実施する
• 総合テスト：本番相当の環境で、業務フローに沿ったシナリオと非機能要件（性能・セキュリティ）を検証する。開発会社が実施し、発注側が立ち会う
• 受入テスト：営業事務担当者が実際の問い合わせを想定したシナリオで操作し、業務上の問題がないことを確認する。発注側が実施する
• データ移行：過去2年分の問い合わせメール（約36,000件）を、発注側が整形したCSVから移行バッチで取り込む。移行後に件数と内容を照合する
• 切り替え：運用開始後1か月は従来のメール運用と並行し、問題がなければ本システムに一本化する

テスト方針を基本設計で定めておくと、設計の内容がテストで検証可能かどうかを早い段階で確認できます。「この設計をどう検証するか」まで書くことで、設計の曖昧さも減らせます。

基本設計書を書くときのコツ

基本設計書は、要件定義書の内容を漏れなく設計に反映しつつ、発注者が理解・承認できる粒度にまとめる必要があります。ここでは、サンプルを自社のプロジェクトに置き換える際に押さえておきたい5つのコツを解説します。

要件定義書との対応を明示する

すべての要件が設計のどこで実現されているかを、要件IDと画面ID・バッチID・連携IDの対応表で示します。対応表があれば、要件の抜け漏れをすぐに確認でき、要件が変更されたときの影響範囲も特定できます。

「要件定義書に書いてあることが、すべて設計に反映されている」ことを検証可能にするのが、基本設計書の最も重要な役割です。

画面設計は業務の流れに沿って確認できるようにする

画面設計は、画面単体で見るよりも、業務の流れに沿って「この操作の次にこの画面に進む」という形で確認するほうが、業務担当者は問題に気づきやすくなります。画面遷移図と業務フローを対応付け、主要な業務シナリオごとに操作の流れを示しましょう。

また、可能であれば画面のモックアップ（見た目の試作）を作り、実際に操作しながら確認してもらうと、承認後の手戻りを大きく減らせます。「見て、触って、確認できる」設計書を目指すことがポイントです。

データベース設計は業務用語と項目を対応付ける

テーブルや項目の名前は英語や略語になりがちで、業務担当者には意味がわかりません。各項目に業務上の意味を日本語で添え、「この項目は画面のどこに表示されるか」「基幹システムのどの項目に対応するか」を示しましょう。

業務担当者がデータの定義を確認できる状態にしておくことで、「必要な項目がない」「意味が違う」といった問題を設計段階で発見できます。

非機能設計は要件の数値と設計を対応付ける

要件定義で定めた非機能要件の数値（応答時間3秒以内、稼働率99％以上など）が、設計のどの工夫によって達成されるのかを明示します。「要件は満たすつもり」ではなく、「この構成とこの処理方式で満たす」と根拠を示すことが必要です。

達成の根拠が示せない非機能要件は、実装後に満たせないリスクが高いため、この段階で開発会社と実現方法を確認しておきましょう。

未確定事項と前提条件を分けて書く

基本設計の時点では、外部連携先の仕様や、利用するサービスの制約など、確定できていない事項が残ることがあります。これらを確定したことのように書くと、後の工程で問題になります。

未確定事項は一覧にして、誰がいつまでに確認するかを明記します。「決まっていること」と「決まっていないこと」を明確に分けることが、設計書の信頼性を高めます。

【無料相談のご案内】 「開発会社から提出された基本設計書をどう確認すればよいか」「AIを含むシステムの設計をどう進めるべきか」といった具体的なご相談は、無料の相談予約からお気軽にお問い合わせください。 ▶ 相談予約はこちら（https://nextscale.co.jp/consultation/）

テンプレートの活用とカスタマイズの方法

基本設計書のテンプレートは、無料で公開されているものも多く、項目の抜け漏れを防ぐうえで役立ちます。ここでは、テンプレートの選び方と、プロジェクトの性質に合わせたカスタマイズの考え方を解説します。

ExcelとWordの使い分け

基本設計書は、画面項目定義やテーブル定義のように表形式の情報が多いため、Excelで作成されることが多い文書です。一方、設計方針やシステム構成の説明のように文章と図で示す部分は、Wordや文書管理ツールのほうが向いています。

実務では、全体の構成と方針をWordや文書ツールでまとめ、画面・帳票・テーブルの定義はExcelで管理し、IDで相互に参照する形が一般的です。表形式の情報と説明的な情報を、それぞれに適したツールで管理すると、更新もしやすくなります。

プロジェクトの種類に応じて重点を変える

• 業務システムの新規開発：画面設計・帳票設計・データベース設計を詳細に記載する。業務フローとの対応を重視する
• 既存システムの改修：変更する部分と変更しない部分を明確にし、既存機能への影響を記載する。差分がわかる形式にする
• Webサービス・アプリ：画面設計に加えて、利用者体験の設計（操作の流れ、エラー時の案内）を重視する。API設計を独立した項目として設ける
• AIを含むシステム：AI機能の入出力、参照データ、精度の評価方法、人による確認フロー、データの取り扱いを独立した項目として設計する

AIを含むシステムでは、従来の設計項目に加えて、AIの出力をどう扱うか、精度をどう維持するかを設計として明文化する必要があります。サンプルの「AI回答案生成の設計」を参考に、独立した項目として設けることをおすすめします。

AI開発における要件定義や設計の考え方、開発会社の選び方については、AI受託開発の費用相場と開発会社の選び方の記事でも解説しています。

アジャイル開発での基本設計書の扱い

反復的に開発を進めるアジャイル開発では、すべてを事前に設計書として固めるのではなく、システム構成・データの全体像・共通ルールといった「後から変えにくい部分」を基本設計として定め、画面や個別機能の詳細は反復のなかで決めていく進め方が取られます。

この場合でも、発注者と開発者の共通認識を作るための文書は必要です。「事前に決めるべきこと」と「進めながら決めること」を切り分け、前者を基本設計書に記載するという考え方で、テンプレートを簡略化して使うとよいでしょう。

サンプルやテンプレートを活用する際の注意点

サンプルやテンプレートは便利ですが、使い方を誤ると、体裁は整っていても設計として機能しない文書になります。ここでは、基本設計書の作成・確認でよくある4つの失敗と、その対策を解説します。

要件定義書との整合性を確認しない

テンプレートの項目を埋めることに集中すると、要件定義書に書かれた要件が設計に反映されているかの確認がおろそかになります。設計書としての体裁は整っていても、要件が抜けていれば、テストや検収の段階で問題が発覚します。

対策は、要件IDと設計IDの対応表を必ず作り、すべての要件に対応する設計があることを確認することです。基本設計書のレビューは、まず要件との対応表から始めることを習慣にしましょう。

発注側が内容を理解しないまま承認する

基本設計書は専門的な内容を含むため、発注側の担当者が「開発会社に任せておけば大丈夫」と内容を確認せずに承認してしまうことがあります。承認後の変更は費用と期間に影響するため、承認前の確認が重要です。

対策は、発注側が確認すべきポイント（画面の項目と動作、業務フローとの対応、データの定義、対象外の範囲）を絞り、その部分は業務担当者が必ず確認する体制をつくることです。技術的な部分は開発会社に、業務的な部分は発注側が責任を持つという分担を明確にしましょう。

詳細設計と同じ粒度で書こうとする

基本設計書に処理ロジックやプログラムの構造まで書き込むと、分量が膨らみ、発注側が読めない文書になります。逆に、発注側が判断すべき業務上の事項が技術的な記述に埋もれてしまうこともあります。

対策は、「発注者が承認できる粒度」を基準に、実装の詳細は詳細設計書に委ねることです。読み手が誰かを常に意識して、書く深さを決めることが、基本設計書の品質を保つ基本です。

設計書を更新せず、実装と乖離する

実装中に設計の変更が生じても基本設計書が更新されないと、運用開始後の保守や改修の際に、設計書が信頼できない資料になってしまいます。特にAIを含むシステムでは、参照データや判定条件の変更が頻繁に発生するため、設計書の更新が重要です。

対策は、変更管理の手順に設計書の更新を組み込み、改訂履歴を残すことです。基本設計書を「開発中の一時的な文書」ではなく「システムの資産」として管理することで、内製化や将来の改修にも役立ちます。

システム開発やAI活用の進め方については、NextScaleのコラム一覧でも関連記事を公開しています。

【無料相談のご案内】 基本設計書の作成や確認に不安がある方、AIを組み込んだシステムの設計・開発を検討している方は、以下から無料の相談予約をご利用ください。要件定義から設計・開発・運用までを一貫してご支援します。 ▶ 相談予約はこちら（https://nextscale.co.jp/consultation/）

まとめ

基本設計書は、要件定義で決めた「何を実現するか」を、システムの構成・画面・データ・外部連携・非機能といった「どう実現するか」に落とし込み、発注者と開発者が合意するための文書です。発注者が理解・承認できる粒度で書くことが、詳細設計書との違いであり、品質を保つ基本になります。

記載項目は、文書概要と設計方針、システム構成、機能一覧と業務フロー、画面設計、帳票設計、データベース設計、外部インターフェース設計、バッチ処理設計、非機能設計、テスト・移行方針の10項目が柱です。本記事では、問い合わせ対応支援システムを題材に、AI機能の設計を含む記入例を紹介しました。

サンプルやテンプレートを活用する際は、要件定義書との対応を明示する、業務の流れに沿って確認できるようにする、非機能要件の達成根拠を示す、未確定事項を分けて書くことを意識してください。そして、発注側は業務的な判断に責任を持ち、技術的な部分は開発会社の専門性を活用するという分担で、設計の品質を高めていきましょう。