基本設計書は何を書くべきなのかまとめました。

基本設計とは

システムを作るために何を作るかを決める作業の内、要件定義と詳細設計の間にあたる行程。結合テストを対になる。

基本設計を作る上でのインプットは要件定義書であり、
アウトプットした基本設計書は詳細設計のインプットとなる。

行う作業

• 画面や帳票、バッチ処理など作るべき機能を洗い出す
• 作る機能がどんなものなのか明確にする
• 機能間の関係性や入出力するデータを明確にする
• データをどういう形式、項目として扱うか決める
• 既存システムとどんなデータのやり取りをするか決める
• どんなミドルウェアやハードウェアを組み合わせれば要件が実現できるか考える

外向けと内向けの区分

基本設計はお客様と意見をすり合わせる最後の機会でもあり、開発要員に設計を伝えるものでもある。
伝える相手と目的の違いで「外向け」と「内向け」に分けることができる。

外向けの設計

お客様がこうに使えるものだと認識するもの

• 画面遷移
• 出力される帳票のレイアウト
• 関連するシステムとのデータのやり取り
• システムを使った業務の流れ（使い方？）
  など

内向けの設計

システムの作られ方に関するもの

• 画面を表示するプログラム
• データベース
• アーキテクチャ
  など

基本設計で作るもの

用途	つくるもの
全体を把握する	機能一覧、業務フロー図、状態遷移図、データフロー図、入出力関連図
画面を決める	画面一覧表、画面遷移図、画面設計書（レイアウト）
帳票を決める	帳票一覧表、帳票設計書（レイアウト）
バッチ処理を決める	バッチ処理一覧表、バッチ処理フロー図、バッチ処理設計書
データベースを決める	テーブル一覧表、テーブル設計書、ER図、CRUD図
入出力を決める	ファイル一覧表、ファイルレイアウト、外部IF一覧表、外部IFレイアウト
その他決めること	項目定義書、コード定義書、メッセージ一覧表
物理構成や運用方法	システム構成図、運用設計書

全体を把握する

基本設計ではまず、要件定義から機能を分割・分類し、機能レベルで何を行うかを考える。
最初に作るものがいくつかるのか、数を把握する。
この時、機能の「単位」は様々であり、画面、帳票、バッチ処理、APIなど同じものの単位で一覧を作るのは普通である。また、もっと上の「業務」でグループ化し、その中にどんな画面、帳票、バッチ処理、APIがあるかでまとめることもよくある。

最初から全ての機能を一覧にすることはできない

要件定義書を見ながら検討や試行錯誤しながらだんだん育てていく。

画面設計

• どういう画面があるのか
• その画面は何ができるのか
• どういう項目があってどうに表示されるのか
• 画面間の繋がりはどうになっているのか

画面レイアウトやクリックアクション、画面遷移を明示する。
UIの専門家やUXの専門家も交えて議論を行う。

帳票設計

ここでいう帳票は、受注伝票や入金伝票などの業務上必要になるものやPDFなどで売上高の集計値が分かるもの。

• いつ
• 誰が
• どんな情報を
• どういう形式で
• どこから出力するか

帳票は画面で入力する検索条件やデータベース設計にも密着していて、関連する機能を一緒に考えながら徐々にブラッシュアップしていく。

バッチ処理設計

画面や帳票以外の処理、いわゆるバッチ処理がある。目には見えないところで行う処理。

• どういうバッチ処理があるか
• どういう情報を入力し、何を出力するか
• どういうタイミングで動くのか
• バッチ処理同士の前後関係
• バッチが途中で終了したらどうフォローするか

バッチ処理を考える上で大事なのは全体視点。一つ一つの処理は入出力や処理がわかりやすいように上手に分割して、それをうまく組み合わせて大きな一つの処理結果をどうやって作っていくかを考える。

データベース設計

システムで使うデータをどのように保存し、検索処理などによってどのように提供するかを考える。

• どのような種類のデータベースを使うか
• どのようにデータを管理するか
• どのような項目を持つか
• インデックスにはどのような項目を使うか
• テーブル間の関係

システム構成

システム構成は、アプリケーション側とサーバなどのインフラストラクチャ（インフラ）側の２つの領域から作られる。
アプリケーション側とインフラ側の担当者が、どのようなハードウェアやネットワークの構成にすれば、要件定義で決められた処理性能や可用性や運用性などのいろいろな要件・非機能要件を満たすことが出来るかを考える。また、それにかかるコストも検討する。

基本設計をする上で大事なこと

全体視点

使う側の視点、開発者としての視点、設計者としての視点、保守・運用する側の視点などさまざまな立場での視点のこと。
要件を形にするだけでは「使える」ものではない。

要件定義とずれないこと

基本設計は要件定義の「翻訳」をする。
基本設計で要件定義とずれてしまうと、成果物がずれてしまう。
システムで分からないことがあれは、基本設計に返る。運用する時も、障害が起きた時も、改修する時も、作業者が変わったときも常に基本設計があり続ける必要がある。

実際に作れるものであること

「こういうことができたらいいな」ではなく、「こうすればできる」「こうでなければならない」という明確な根拠ありきで進める。
その根拠は、設計の意図を他者に伝えることにもつながる。

設計の手戻りは必ずある

手戻りがあることを前提に取り得る選択肢や代替え案を考えておく。
設計上のリスクは設計の段階でお客様に合意をとっておくのも大事。

設計後に設計上の問題を見つけたとしても、絶対に基本設計を変えてはいけないわけではない。
設計は都度変わっていくものであり、準備はしておかねばならない。

参考