基本設計とは？要件定義の次の工程｜成果物と発注者が確認すべきポイント
「要件定義が終わったら、次は何をするのか」「基本設計書のレビューを頼まれたが、どこを見ればよいのか分からない」。システム開発では、要件定義の次に基本設計という工程があり、発注者が仕様を確認できる最後の大きな機会になります。
この記事では、基本設計の意味と要件定義・詳細設計との違い、主な成果物、発注者がレビューで確認すべきポイントを解説します。
- 基本設計とは、要件定義で決めた内容を、画面・帳票・データ・連携の具体的な仕様に落とし込む工程
- 要件定義が「何を実現するか」、基本設計が「どう見えてどう動くか」、詳細設計が「内部でどう作るか」を決める
- 成果物は画面設計書、帳票設計書、機能一覧、データ設計、外部連携の仕様など
- 基本設計の承認後の変更は手戻りが大きいため、業務の流れに沿って画面と帳票を確認することが重要
目次
基本設計とは
基本設計とは、要件定義で合意した機能や条件をもとに、利用者や外部から見えるシステムの仕様を具体的に決める工程です。「外部設計」と呼ばれることもあります。画面にどの項目をどう並べるか、帳票をどの形式で出すか、どのようなデータを持つか、他のシステムとどうやり取りするかを決めます。
基本設計書は、開発会社が詳細設計・製造を進めるための土台であると同時に、発注者が「完成するシステムの姿」を確認するための資料でもあります。
関連記事システム開発の工程一覧｜要件定義の次の工程・略語（SDEM）・工程表の作り方
要件定義・基本設計・詳細設計の違い
上流工程の役割の違い
| 工程 | 決めること | 主な担当 | 発注者の関わり |
|---|---|---|---|
| 要件定義 | 何を実現するか（業務・機能・品質の要件） | 発注者と開発会社 | 主体的に参加し、内容を決める |
| 基本設計 | どう見えて、どう動くか（画面・帳票・データ・連携） | 開発会社（発注者が確認） | レビューと承認 |
| 詳細設計 | 内部でどう作るか（プログラムの構造・処理） | 開発会社 | 原則として関わらない |
基本設計の主な成果物
- 機能一覧：システムが持つ機能と、それぞれの概要
- 画面一覧・画面設計書：画面の種類、レイアウト、入力項目、ボタンの動き、画面の遷移
- 帳票設計書：請求書や集計表などの出力イメージ、項目、出力条件
- データ設計（ER図・テーブル定義の概要）：どのような情報をどの単位で持つか
- 外部連携の仕様：他システムとやり取りするデータの項目、形式、タイミング
- 非機能の設計：権限、性能、バックアップ、セキュリティの方針
すべてを文書で作るとは限らず、小規模な開発では画面の試作品（モックアップ）を見ながら確認する方法もあります。何を成果物とするかは、契約前に開発会社と合意しておきましょう。
基本設計の期間と工数の目安
基本設計は、開発全体の工数のうちおおむね1〜2割程度を占めることが多い工程です。全体で6か月程度の開発なら、1〜2か月程度が目安になります。発注者のレビューと修正の往復に時間がかかるため、社内の確認担当者と日程を先に押さえておくと遅れを防げます。
発注者がレビューで確認すべきポイント
- 業務の流れに沿って確認する受注から請求までなど、実際の1日の業務を画面と帳票でたどり、抜けている操作や項目がないかを見る
- 例外のケースを確認するキャンセル、返品、締め後の修正など、頻度は低いが必ず起きる業務が扱えるかを確かめる
- 帳票は実物と並べて確認する現在使っている帳票や取引先に出す書類と項目・並び順を照らし合わせる
- 権限と担当者を確認する誰がどの画面を使い、誰が承認するのかが社内のルールと合っているかを見る
- 分からない用語はその場で聞く設計書の専門用語は遠慮せず確認し、理解したうえで承認する
画面設計書に書かれる主な項目
基本設計書の中でも、発注者が最も時間をかけて確認するのが画面設計書です。一般的には次のような項目が記載されます。
画面設計書の記載項目の例
| 項目 | 内容 | 確認のポイント |
|---|---|---|
| 画面レイアウト | 項目やボタンの配置図 | よく使う項目が見やすい位置にあるか |
| 項目定義 | 項目名、入力形式、桁数、必須かどうか、初期値 | 現在の帳票や業務で使っている項目と一致しているか |
| 入力チェック | 入力できる値の範囲、エラー時のメッセージ | 現場で起きる入力ミスを防げるか |
| ボタン・操作 | 登録・検索・印刷などの動き | 業務の手順どおりに操作できるか |
| 画面遷移 | どの画面からどの画面へ移るか | 行ったり来たりが多すぎないか |
基本設計でよくある失敗と対策
- 現場の担当者がレビューに参加していない：管理職だけで承認し、稼働後に現場から使いにくいと言われる → 実際に使う担当者をレビューに入れる
- 例外の業務が漏れている：通常の流れだけを確認し、返品や訂正の処理がない → 年に数回しか起きない業務も一覧にして確認する
- 帳票の確認が後回しになる：画面だけ確認して帳票は「おまかせ」にし、取引先に出す書類の形式が合わない → 実物の帳票と並べて確認する
- レビューの期限が守れない：社内の確認が遅れ、開発全体の日程がずれる → レビュー担当と期限を工程表に入れておく
基本設計の前に発注者が準備しておくこと
基本設計をスムーズに進めるには、開発会社に任せきりにせず、発注者側でも材料をそろえておくことが大切です。準備ができているほど、レビューの往復が減り、期間と費用の超過を防げます。
今使っている伝票、Excelの様式、既存システムの画面のコピーを集めておく
返品、キャンセル、締め後の訂正など、通常と違う処理をまとめておく
誰がどの範囲を確認し、誰が最終的に承認するのかを社内で決めておく
あわせて、要件定義書の内容に変更や追加がないかも基本設計の開始前に確認しておきましょう。要件の変更を基本設計の途中で持ち込むと、要件定義からのやり直しになり、スケジュールに大きく影響します。
よくある質問
- 基本設計と外部設計は同じものですか？
- 多くの場合、同じ工程を指します。利用者や外部から見える部分を設計することから「外部設計」とも呼ばれます。会社によって範囲が少し異なるため、成果物の一覧で確認しましょう。
- 基本設計だけを別の会社に依頼できますか？
- 依頼すること自体は可能ですが、詳細設計・製造を担当する会社が設計の意図を理解できるよう、引き継ぎの方法と設計書の記載レベルを事前に決めておく必要があります。工程ごとに会社を分けると、責任の範囲もあいまいになりやすい点に注意しましょう。
- 基本設計書は納品してもらうべきですか？
- 将来の改修や保守、開発会社の変更に備えて、納品物に含めておくことをおすすめします。契約書の成果物の欄に記載されているかを確認しましょう。
- 外部設計と内部設計の違いは？
- 外部設計は利用者から見える部分（画面・帳票・操作の流れ・外部とのデータのやり取り）を決める設計で、基本設計とほぼ同じ意味で使われます。内部設計はプログラムの構造や処理の詳細など開発者向けの設計で、詳細設計とほぼ同じ意味です。発注者が主に確認するのは外部設計（基本設計）の成果物です。
まとめ
基本設計は、要件定義の次に行う工程で、画面・帳票・データ・連携など利用者から見える仕様を具体的に決めます。発注者が完成するシステムの姿を確認できる最後の大きな機会であり、承認後の変更は手戻りが大きくなります。業務の流れや例外のケースに沿って設計書を確認し、納得したうえで承認しましょう。
この記事に関連するサービス
受託システム開発
業務システム・Webシステム・基幹システムを、要件が固まる前のご相談から設計・開発・運用保守まで一貫して開発します。プロトタイプで早い段階から画面を確認でき、開発資産の活用で品質を… サービスの詳細を見る
