基本設計書の読み方・確認ポイント｜発注者が承認前に必ずチェックすべき項目【2026年版】

基本設計書とは？なぜ発注者の確認が重要なのか

基本設計書とは、要件定義で決めた「何を作るか」を「どう作るか」に具体化した設計文書です。開発会社が実際の開発作業に入る前に発注者に提出し、承認を得る重要なドキュメントです。

システム開発の流れの中では、要件定義の次のフェーズにあたります。基本設計の段階で合意した内容が、その後の開発・テストの基準になるため、ここでの確認漏れが後工程のトラブルに直結します。

多くの発注者が「専門的すぎてよくわからない」「開発会社を信頼して任せた」とそのまま承認してしまいますが、これが大きな落とし穴です。基本設計の段階での変更コストは比較的低い一方、テスト・リリース後に設計の問題が判明した場合、変更コストは設計段階の数倍以上になることが一般的に知られています。

基本設計書の典型的な構成

基本設計書の構成は開発会社によって異なりますが、一般的に以下の内容が含まれます。

発注者が特に重視すべきは「高」に分類した3つ（システム概要・機能一覧・画面設計）です。これらは技術知識がなくても業務視点で確認できる内容です。

発注者が必ず確認すべき7つのポイント

ポイント1：機能一覧と要件定義書の突合

要件定義で決めたすべての機能が基本設計書に含まれているかを確認します。

確認の手順：

1. 要件定義書の機能リストと基本設計書の機能一覧を並べる
2. 要件定義にあって基本設計にない機能がないか照合する
3. 「後工程で追加」と記載された機能はスコープ外になっていないか確認する

よくある落とし穴：要件定義では「〇〇機能を追加する」と決めていたのに、基本設計書では「フェーズ2で対応」と書かれていて、初回リリースのスコープから外れているケース。

ポイント2：画面設計の業務フロー整合性

各画面のレイアウトと操作フローが、実際の業務の流れと一致しているか確認します。

確認すべき観点：

• 入力項目に不足がないか（現在紙の帳票で使っている項目はすべてあるか）
• 一画面に情報が詰め込まれすぎていないか
• よく使う操作が見つけやすい位置にあるか
• 現場スタッフが理解できるラベル名か（専門用語が使われていないか）

実際の画面設計確認には、現場で日常的にシステムを使うスタッフにも同席してもらうのが効果的です。管理職や経営者だけでは気づかない「現場の使いにくさ」が事前に発見できます。

ポイント3：画面遷移の業務シナリオとの一致

「受注を登録する → 在庫が更新される → 請求書を発行する」といった業務シナリオを実際に画面遷移図の上でたどってみます。

確認のコツ：

1. 業務で最も頻繁に行う操作フローを3〜5パターン選ぶ
2. そのフローを画面遷移図の上でなぞってみる
3. 「この操作の後にどの画面に行くか」が直感的にわかるか判断する

ポイント4：入力制御・バリデーション

各入力フォームに適切な入力チェック（バリデーション）が設定されているかを確認します。

バリデーションの不足は、後でデータの品質問題やシステムエラーの原因になります。「このフォームでおかしな値を入れたらどうなるか」を開発会社に確認しておきましょう。

ポイント5：権限設計（誰が何をできるか）

「誰が何の操作をできるか」という権限の設計が、業務上の必要性と一致しているかを確認します。

確認すべき観点：

• 管理者・一般ユーザー・閲覧専用など役割の分類が適切か
• 「削除」「承認」など重要な操作が特定の役割に限定されているか
• 部署間でデータを見せたくない場合、そのアクセス制限が設計に含まれているか
• 退職者のアカウントを無効化する仕組みがあるか

ポイント6：外部システム連携の範囲と方式

既存システム（会計ソフト・在庫管理など）との連携が正しく設計されているかを確認します。

API連携の方式や連携タイミング（リアルタイム・日次バッチなど）が業務要件と合っているかを特に注意して確認します。

確認の質問例：

• 「会計ソフトへのデータ連携はいつ行われますか？リアルタイムですか、それとも夜間バッチですか？」
• 「連携が失敗した場合、どのように検知・再処理しますか？」
• 「連携先システムが一時停止している間はどうなりますか？」

ポイント7：非機能要件（性能・セキュリティ）

「何人まで同時に使えるか」「パスワードは何文字以上か」といった非機能要件が自社の状況と合っているかを確認します。

確認でよく見つかるトラブルパターン

パターン1：スコープの縮小

要件定義では「月次レポートの自動生成機能」が含まれていたのに、基本設計書ではなくなっていた。開発会社に確認すると「工数が増えたため削除を提案したが、別途相談したい」と言われる。

対処法：要件定義書と基本設計書を機能レベルで突合し、要件定義にあって基本設計にない機能を必ずリストアップして質問する。

パターン2：画面イメージのズレ

ワイヤーフレームを見て承認したが、実際のデザインが出てきたときに「入力項目が多すぎて使いにくい」「ボタンの位置が直感的でない」と判明する。

対処法：基本設計のワイヤーフレーム確認時に、実際に現場でシステムを使うスタッフにも見てもらう。

パターン3：権限設計の過不足

「全ユーザーが全データを見られる」設計になっていて、競合する部署間でのデータ共有に問題が生じる。または逆に「権限が細かすぎて承認フローが回らない」事態に。

対処法：社内の組織図と役割をもとに、「誰が何を見て、何をできるべきか」を書き出してから権限設計を確認する。

基本設計書の承認前チェックリスト

以下の項目を承認前に確認してください。

機能・スコープ確認

• 要件定義書の全機能が基本設計書に含まれているか
• 「フェーズ2」「後日追加」として後回しにされた機能の扱いに合意しているか
• 追加費用が発生する可能性のある項目が明示されているか

画面・操作確認

• 主要な業務シナリオを画面遷移図でたどれるか
• 入力項目に過不足がないか（紙帳票と比較）
• 現場スタッフが理解できる画面かどうかを確認済みか

データ・連携確認

• 既存システムとの連携方式と連携タイミングが明記されているか
• 連携失敗時の対処方法が設計に含まれているか
• データの保存期間が業務上・法令上の要件を満たしているか

セキュリティ・権限確認

• 役割ごとのアクセス権限が業務実態に合っているか
• パスワードポリシーが適切か
• 個人情報の取り扱いが適切に設計されているか

非機能要件確認

• 想定する同時ユーザー数が記載されているか
• レスポンスタイムの目標値が記載されているか
• バックアップ・障害復旧の設計が含まれているか

開発会社への質問の仕方

基本設計書の確認で疑問が出たときの、開発会社への質問の仕方を紹介します。

避けるべき質問（曖昧すぎる）：

• 「この設計で本当に大丈夫ですか？」
• 「問題ないですか？」

効果的な質問（具体的）：

• 「要件定義書の〇ページにある『月次レポート自動生成』機能が基本設計書で見当たりません。これはどの画面で対応していますか？」
• 「受注登録後に在庫が更新されるタイミングはいつですか？リアルタイムですか、それとも夜間バッチですか？」
• 「A部署の担当者がB部署の受注データを閲覧できる設計になっていますが、これは意図通りですか？」

具体的な質問のほうが開発会社も答えやすく、認識のズレを素早く解消できます。開発会社とのコミュニケーション術も合わせてご参照ください。

まとめ

基本設計書の確認は、発注者が開発プロジェクトの方向性を決定づける重要な機会です。

• 技術的な詳細はわからなくてもよい。業務フロー・画面の使いやすさ・機能の過不足は発注者にしか判断できない
• 要件定義書との突合を必ず行い、スコープの縮小がないか確認する
• 現場スタッフを確認に巻き込むと、管理者が見落とす問題を発見できる
• 疑問点は遠慮せず具体的な質問として開発会社に伝える
• 基本設計段階での変更は、テスト後の変更より大幅にコストが低い

システム開発の各工程での発注者の関わり方はシステム開発の流れ完全ガイドで、要件定義の進め方は要件定義のやり方ガイドでそれぞれ解説しています。