意図が伝わる設計書を作るには，前提として「それぞれの設計書がどういう役割を担うか」「それぞれの設計書が相互にどういう関係にあるか」を正しく理解しておくことが重要である。豊富なサンプルとともに，設計書の役割と関係，さらには書き方のコツを解説する。
石川貞裕 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 担当本部長
向坂太郎 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部
「基本設計書」と聞いて，どんなものをイメージするだろうか。業務フロー図や画面レイアウト，E-R図など様々だろう。大規模，高品質のシステムを開発するなら，図1に示すような多くの設計書を作成することになる。
中心となる機能要件設計だけでも20種類。それぞれの役割や関係をきちんと理解し，過不足なく設計情報を盛り込むことが求められる。
難しいのは，設計書の読み手が開発者だけではないことだ。要件定義ではユーザーの視点で要件を集約した。基本設計では，これを開発者の視点で書き直す。開発者の視点に変えてなお開発者とユーザーの両者が読みやすい設計書にするのが，基本設計書を作成する上での課題となる。
基本設計のプロセスは大きく三つ
基本設計は大きく分けて「機能要件設計」「システム方式設計」「アプリケーション方式設計」という三つのプロセスを踏む。いずれの設計も入力情報となるのは要件定義で作成した成果物である。機能要件設計では，どのような機能をアプリケーションに求めるかを設計する。その際「画面」「業務プロセス」「データ」という三つの切り口に分ける。
システム方式設計では，性能や信頼性などの非機能要件を整理する。それを踏まえて，ハードウエアやソフトウエアなどの構造や実装方式を練る。アプリケーション方式設計では，非機能要件を考慮しつつ，機能要件設計で明確にした機能（画面，業務プロセス，データ）を適切なサイズのモジュールに割り当てる。
次回からは，この“巨大”かつ“複雑”な基本設計の全体像を解きほぐし，どういうふうに設計書を書けばよいのかを明らかにする。ユーザーとの間で特に誤解が生じやすい「機能要件設計書」を例に挙げて解説する。
