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

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

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

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

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

基本設計の目的

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

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

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

基本設計書のサンプル

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2-1.システム方式

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

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

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

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

2-2.画面設計

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

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

2-2-1.画面一覧

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

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

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

2-2-2.画面遷移図

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

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

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

2-2-3.画面レイアウト

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

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

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

2-2-4.画面入出力項目一覧

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

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

項目毎に下記のような内容を整理する。

2-2-5.画面アクション定義

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

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

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

2-3.帳票設計

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

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

2-3-1.帳票一覧

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.21

プロジェクトで開発する帳票を一覧にまとめた資料。

要件定義で一覧表を作っていれば基本設計では流用するだけだが、もし作っていなければこのタイミングでも一覧を整理しておきたい。

2-3-2.帳票概要

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.25

帳票の出力場所や業務上の用途が分かる資料。

こちらも要件定義工程で整理している資料だが、もし整理できていなければ基本設計工程で整理したい。

発行タイミングや発行量（ページ数）は、システム機能設計をするうえでも考慮すべきポイントになってくる。

2-3-3.帳票レイアウト

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.28

帳票の具体的なイメージを明確にする資料。

要件定義ではざっくりとしたイメージでも良かったが、基本設計では項目の位置を後述の「帳票出力項目一覧」と合うように決める必要がある。

2-3-4.帳票出力項目一覧

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.31

帳票に表示する項目の内容を具体的に述べた資料。

下記のような内容を項目毎に整理する。

出力ルールが複雑な項目は後述の「帳票編集定義」に記載する。

2-3-5.帳票編集定義

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.34

帳票の編集方法を述べた資料。

2-4.バッチ設計

バッチ設計として整理するのは下記３つ。
バッチ処理一覧は要件定義で整理すべき資料だが、整理できていない場合は基本設計で一覧表にまとめたい。基本設計では「バッチ処理フロー」「バッチ処理定義」が主な作業となる。

2-4-1.バッチ処理一覧

出典：IPA『機能要件の合意形成ガイド～バッチ編～』,p.19

プロジェクトで開発するバッチ機能を一覧にまとめた資料。

2-4-2.バッチ処理フロー

出典：IPA『機能要件の合意形成ガイド～バッチ編～』,p.23

バッチ処理の流れにおける入力・処理機能・出力を整理した資料。

処理をどう分けるかを検討することになるが、下記のようにデータ抽出・加工・更新といったように機能を分けておくと、テストをする際にデータベースを都度戻さなくてよいので効率が良くなる。

2-4-3.バッチ処理定義

出典：IPA『機能要件の合意形成ガイド～バッチ編～』,p.27

バッチ処理フローの１つ１つの処理について、入力・処理・出力を整理した資料。

基本設計ではなく、詳細設計で作成する場合もある。

2-5.テーブル・ファイル設計

基本設計のテーブル・ファイル関連で作成する資料は下記の通り。

要件定義で主要なテーブルを整理したER図や一覧資料については、設計を進めるにつれて処理に必要なテーブルを追記することもある。

基本設計工程ではテーブル定義やCRUD図の整理が主な作業となる。CRUD図は整理する組織と整理しない組織が大きく分かれる印象があるが、整理しておくと機能漏れやデッドロックの防止につながる。

2-5-1.テーブル関連図（ER図）

出典：IPA『機能要件の合意形成ガイド～データモデル編～』,p.16

システムで取り扱うテーブル関係が分かる資料。

要件定義では主要なテーブルのみを記載したが、基本設計では機能実現に必要なテーブルをきっちりと書き出していく。一方で、プログラミングをしていく中で必要となるテーブルも出てくるので、その場合は別途資料を修正することになる。

2-5-2.テーブル・ファイル一覧

出典：IPA『機能要件の合意形成ガイド～データモデル編～』,p.19

前述したテーブル関連図をもとに、主要なテーブルを一覧にまとめた資料。

下記のように作られ方からテーブルを分類しておくとCRUD図を整理する際に役立つ。種別の意味合いは下記の通り。

2-5-3.テーブル・ファイル定義

出典：IPA『機能要件の合意形成ガイド～データモデル編～』,p.22

前述したテーブル一覧を元にテーブル内の主要なデータ項目を一覧にまとめた資料。

要件定義では主要な項目のみで良かったが、設計工程では機能実現に必要な項目をきっちりと書き出していく。

もちろんプログラミングをするなかで必要となる内部処理用の項目が追加されることも多いので、その場合は別途資料を修正する。

2-5-4.CRUD図

出典：IPA『機能要件の合意形成ガイド～データモデル編～』,p.25

各テーブルの作成・参照・更新・削除を整理した資料で、機能漏れやデッドロックの防止が期待できる。

基本設計ではなく詳細設計で整理する場合もあるし、組織によってはソースコードを元に自動生成する場合もある。

2-6.外部インターフェース設計

システムを構築する上で必要な外部システムとの連携（インターフェース）について整理する。

見積りへのインパクトが大きくなりがちなので要件定義で関連図や一覧表については整理すべきだが、もし整理できていなければ基本設計工程にでも整理したい。

要件定義で作成した外部インターフェース定義書については、機能を実現するうえで必要な項目を追加していく。また処理概要の資料には送受信に関する双方の取り決めを整理する。

2-6-1.外部システム関連図

出典：IPA『機能要件の合意形成ガイド～外部インタフェース編～』,p.20

関連システムとのデータ連携を図解した資料。

2-6-2.外部インターフェース一覧

出典：IPA『機能要件の合意形成ガイド～外部インタフェース編～』,p.17

関連システムとのデータ連携を一覧にまとめた資料。
見積りに影響しやすいので5W2Hで整理しておきたい。

2-6-3.外部インターフェース定義書

出典：IPA『機能要件の合意形成ガイド～外部インタフェース編～』,p.23

関連システムとのデータのやりとりについて、主要なデータ項目を一覧にまとめた資料。

要件定義では主要な項目のみで良かったが、基本設計では送受信の識別やデータ破損識別（レコード長等）といったチェック用の項目も漏れなく書き出していく。

2-6-4.外部インターフェース処理概要

出典：IPA『機能要件の合意形成ガイド～外部インタフェース編～』,p.26

外部システムとのデータ連携について、手順やチェック方法等を取り決めた資料。

例えば下記のようなことを整理する。

3.非機能要件に関わる成果物

非機能要件は軽視されがちだが事業に大きな影響を与える可能性があるため、要件定義の重要な検討事項として位置付けられている。

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

非機能要件は下記６つの資料でまとめられる。（IPAによる非機能グレードを活用）

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

>> 要件定義における成果物一覧と書き方　〜非機能要件〜

資料作成に役立つアイコン提供サイト

基本設計で整理すべき資料（主に機能設計）について成果物の一例を紹介してきた。ここで資料作成に役立つサイトを紹介しておく。

下記は図解に役立つアイコンを無料で提供してくれているサイト。

icooon-mono
業務フロー作成のアイコンに便利

CISCO『Network Topology Icons』
ネットワーク構成図のアイコンに便利

さいごに

基本設計工程の成果物を紹介してきた。

要件定義工程の資料作成ができていないと基本設計工程で大きな苦労をすることになるため、できれば事前に資料は整理しておきたい。

また、冒頭に述べたようにどんな資料をつくるのかはプロジェクト特性や組織のルールによって異なるため、まずは部署の過去資料を確認してほしい。

以上、参考になれば幸いだ。

要件定義工程の関連記事はこちら。

要件定義工程の進め方

2021年2月7日

要件定義の目的は「プロジェクト5W2Hを明確にして失敗を減らすこと」

2021年2月6日

要件定義における成果物一覧と書き方（要件定義書サンプルあり）

2021年2月5日

機能要件・非機能要件の書き方【サンプル有り】

2018年8月17日

参考文献

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

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

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

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

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

IPA『機能要件の合意形成ガイド～画面編～』

IPA『機能要件の合意形成ガイド～帳票編～』

IPA『機能要件の合意形成ガイド～バッチ編～』

IPA『機能要件の合意形成ガイド～データモデル編～』

IPA『機能要件の合意形成ガイド～外部インタフェース編～』