基本設計における成果物一覧と書き方（基本設計書サンプルあり）

基本設計は、顧客の要件を実現するための機能を具体化する工程だ。

基本設計工程では、画面・帳票・テーブルなどの設計した後に「基本設計書」としてまとめるが、どのような資料を作るのか不安を感じるエンジニアも多いと思う。

そこで、今回は基本設計書の書き方を簡単に説明する。

※基本設計のことを外部設計と呼ぶ場合もあるが、当サイトでは基本設計に統一して記載している。

目次

• 基本設計の目的
• 基本設計書のサンプル
• 基本設計書の目次（成果物一覧）
• 1.業務要件に関わる成果物
• 2.機能設計に関わる成果物
  • 2-1.システム方式
  • 2-2.画面設計
  • 2-3.帳票設計
  • 2-4.バッチ設計
  • 2-5.テーブル・ファイル設計
  • 2-6.外部インターフェース設計
• 3.非機能要件に関わる成果物
• 資料作成に役立つアイコン提供サイト
• さいごに
• 参考文献

基本設計の目的

基本設計は要件定義の結果を受けてシステム機能を具体化する工程だ。

要件定義では業務要件・機能要件・非機能要件について整理したが、基本設計では「機能要件」を中心に具体化していく。（業務要件や非機能要件を修正加筆することもある）

プロジェクトによっては要件定義の成果物が不十分あるいはほとんど無い状態で基本設計工程に入ることもある。そういう場合はプロジェクト終盤で大きな手戻りにならないように、基本設計工程でも要件定義の内容（業務要件や非機能要件）を確認した方がいいだろう。

基本設計書のサンプル

それでは、基本設計工程の最終的なアウトプットである「基本設計書」のサンプルを紹介する。

農林水産省『システム構成図』

国立研究開発法人『見守り情報管理システム 基本設計書』

国立研究開発法人『eコミマップ 基本設計書』

特に、情報処理推進機構（以下、IPA）の下記資料は、具体的な書き方や検討のコツも紹介されているので参考になると思う。

IPA『機能要件の合意形成ガイド』

基本設計書の目次（成果物一覧）

ここからは基本設計書の書き方を解説していく。

ここで紹介するのは大規模システム開発もサポートできる手堅い資料であるため、人によっては資料の多さに驚くかもしれない。

システム開発の規模に比例して作成する資料は多くなるが、逆に規模が小さければ資料も少なくて良い。紹介する資料の中から必要なものを選んで作成すると良いだろう。

なお、ここで取り上げる資料はあくまでサンプルであるため、実際の業務ではあなたの部署の過去資料を参考にすることをお勧めする。

基本設計書としてまとめる資料は下記の通り。

1.業務要件（※1） 　1-1.システム化の目的・背景・狙い 　1-2.ビジネスプロセス関連図 　1-3.業務機能構成表 　1-4.ビジネスプロセスフロー 　1-5.システム化業務フロー 　1-6.業務処理定義書

2.機能設計 　2-1.システム方式 　　2-1-1.ハードウェア構成図 　　2-1-2.ソフトウェア構成図 　　2-1-3.ネットワーク構成図 　　2-1-4.アプリケーション機能構成図 　2-2.画面設計 　　2-2-1.画面一覧 　　2-2-2.画面遷移図 　　2-2-3.画面レイアウト 　　2-2-4.画面入出力項目一覧 　　2-2-5.画面アクション定義 　2-3.帳票設計 　　2-3-1.帳票一覧 　　2-3-2.帳票概要 　　2-3-3.帳票レイアウト 　　2-3-4.帳票出力項目一覧 　　2-3-5.帳票編集定義 　2-4.バッチ設計 　　2-4-1.バッチ処理一覧 　　2-4-2.バッチ処理フロー 　　2-4-3.バッチ処理定義 　2-5.テーブル・ファイル要件 　　2-5-1.テーブル関連図 　　2-5-2.テーブル・ファイル一覧 　　2-5-3.テーブル・ファイル定義 　　2-5-4.CRUD図 　2-6.外部インターフェース設計 　　2-6-1.外部システム関連図 　　2-6-2.外部インターフェース一覧 　　2-6-3.外部インターフェース定義書 　　2-6-4.外部インターフェース処理概要

3.非機能要件（※1） 　3-1.可用性 　3-2.性能・拡張性 　3-3.運用・保守性 　3-4.移行性 　3-5.セキュリティ 　3-6.システム環境・エコロジー

※1業務要件と非機能要件は、要件定義書が無い場合に基本設計工程にて整理する。要件定義書に書かれている場合は作成不要。

1.業務要件に関わる成果物

業務要件の認識に違いがあると、機能追加や修正の発生するリスクが高くなってしまうため、本来は要件定義工程で業務要件を整理することが望ましい。

設計を進めていく中で業務要件の修正加筆が発生することもあるが、そういう場合はユーザー企業とITベンダとの双方合意の元で、要件定義書を修正するのが正しい流れである。

一方で、業務要件が整理できていない場合は、基本設計工程で要件を確認しなければならないため見積りブレのリスクは高くなる。だが整理できていないものは仕方ないので基本設計工程からでも要件を整理したい。

業務要件は下記５つの資料でまとめられる。

これらの資料の書き方やサンプルについては、下記の要件定義の記事をご覧いただきたい。基本設計工程での説明は割愛させていただく。

>> 要件定義における成果物一覧と書き方　〜業務要件〜

2.機能設計に関わる成果物

基本設計の主な作業である機能設計。

要件定義書の機能要件を具体化していく作業のため、要件定義の機能要件と同じ資料が並ぶ。

システム方式設計はプラットフォーム設計とも呼ばれ、システムの稼働環境を中心に整理する。こちらの資料も見積りへの影響が大きいため、要件定義工程で整理すべき資料である。

もちろん要件定義工程で整理している場合は無駄に作成する必要は無いため作成は不要である。

システム方式の書き方やサンプルは要件定義の記事をご覧いただきたい。当記事では割愛させていただく。

>> 要件定義における成果物一覧と書き方〜システム方式〜

画面一覧や画面遷移については、要件定義工程で整理したものから修正されることはあまり無い。（一覧や画面遷移が修正されると見積りへの影響が大きい）

画面レイアウトはより具体化し、画面入力項目一覧、画面アクション定義といった資料を基本設計工程にて新たに整理する。

☆：基本設計工程で具体化する資料 ★：基本設計工程で新規作成する資料

出典：IPA『機能要件の合意形成ガイド～画面編～』,p.17

開発する画面の規模感が分かる資料。

基本設計工程で画面が追加や削減されることはあまり無いため、要件定義書の資料のままとなることが多い。

出典：経済産業省『LPガス保安技術者向けWebサイト 管理更新システム』,p.79

画面の流れが分かる資料。

要件定義では正常な画面遷移のみを記載するが、基本設計ではエラー時の遷移先などを細かく取り決めていくことになる。

出典：ThinkIT『令和時代の設計書の基本方針』

画面のイメージを共有するための資料。

要件定義ではざっくりとした画面イメージで良かったが、基本設計では曖昧な部分がないように確実に決めていく。

出典：IPA『機能要件の合意形成ガイド～画面編～』,p.30

画面の入出力を明確にする資料。

項目毎に下記のような内容を整理する。 画面入出力項目で整理する内容 　入力制御：入力無効（disabled）制御 　表示桁数：表示桁数 　入力桁数：入力可能な最大桁数 　データ型：データ型を記述（文字列や数値） 　文字種　：全角または半角 　入力制約：値範囲や入力文字制約等 　初期表示：初期表示有無、表示値 　出力仕様：計算式、色装飾等 　必須入力：必須かどうか

出典：IPA『機能要件の合意形成ガイド～画面編～』,p.33

画面操作におけるシステム動作を明確にする資料。

マウスイベントや入力チェック等の動作を決める。

帳票設計として整理する資料は下記の５つ。 帳票一覧や帳票概要は要件定義で整理したものから大きな変更は無い。（要件定義で整理していなければ基本設計で整理したい）

基本設計では「レイアウト決定」、「出力項目一覧の整理」、「編集定義の決定」の３つが主な作業となる。

☆：基本設計工程で具体化する資料 ★：基本設計工程で新規作成する資料