基本設計とは？基本設計の概要と、設計書作成の重要な観点や要素を紹介

基本設計とは、ソフトウェアの開発工程の一つで、要件定義と詳細設計の間に位置し、前工程の要件定義において抽出した要件を機能単位に分割し、それぞれの機能が「何を実現するのか」を決める工程です。基本設計の成果物には基本設計書というものがあります。

基本設計書には、「何を実現するのか」を書き出す場合もあれば、書き出さない場合もあります。また、基本設計書は、まったく作成しないことがあったり詳細設計で作成するドキュメントと分かれていないことがあったりとその形はさまざまです。プロジェクトによって基本設計書のつくり方は異なり、どれが正解だということはありません。

いずれにしても、基本設計書はあとにくる詳細設計の工程にとっては必要なものだということは変わりません。

基本設計についての理解を深めていく前に、その前の工程となる要件定義やあとの工程となる詳細設計も含め、それぞれが何をする工程なのかということをおさえておくために、具体例をあげて整理すると次の表のようになります。

前述したとおり、基本設計書はどのようなドキュメントに仕上げるのかということについて正解はありません。しかし、基本設計書を作成するうえで、プロジェクトに依存せず共通する重要な観点があります。

ここでは3つの重要な観点とあわせて、その観点に関係する人、重要である理由、観点をふまえないことでどのような問題が起きうるか、問題が起きないようにどうするべきかについてご紹介します。

関係者
発注者(システムの開発を依頼する人)
理由
要件定義書で網羅しきれていない要件があることや、要件定義で決まったことを基本設計工程で変更することがあるため
問題例
基本設計を進めていくうちに要件定義で決めきれていない箇所、実現が困難な箇所を基本設計者の判断で変更または決めてしまった
対応策
基本設計のずれが生じる場合は判明した時点で発注者と相談し、解消に努める

関係者
開発者(システムを開発する人)
理由
要件定義書に記載された内容では実現方法がいくつかあり、後続工程を意識して実現方法を選ぶ必要があるため
問題例
基本設計で実現方法を意識せずに設計書に記載した結果、後続工程においてセキュリティに問題があり手戻りが発生した
対応策
有識者のレビューにより基本設計の実現の適切さを判断する

関係者
利用者(システムの利用者で発注者と同じ場合あり)
理由
要件定義書には、利用者観点や使い方を考慮した機能の記載がないため
問題例
実際の利用方法を意識せずに基本設計を行った結果、リリース後に使いにくいシステムになってしまった
対応策
実際の利用方法を想定して基本設計を行う

これらの重要な観点に共通することは、基本設計においてはシステムに関係する人それぞれの立場で考える必要があるということです。

発注者の立場では要件定義で定めたことのとおり(イメージしたもののとおり)につくられていくのかを考え、開発者の立場では実現可能および適切な(手戻りが起きにくい)実現方法で設計されているのかを考え、利用者の立場ではできあがったシステムは使い勝手がよく、利用価値があるのかを考えるということです。

すなわち、基本設計はつくり上げられるシステムの全体がどう実現されるかが決まる工程であるため、システムに関係する人たちから合意を得るために、その人の立場で考えるということが重要だということです。

基本設計書は前述のとおりプロジェクトごとに作成するものが異なるほかにも、つくり上げるシステムの機能(画面を提供する、帳票を出力する機能を盛り込むなど)によって、必要になる設計書の一部が異なることや、システムの規模によっては一部を作成しないといったように、場合により完成形が異なることがあります。しかし、設計書そのものを構成する要素は大きく変わりはありません。

そこで、基本設計書はどういった要素によってつくられるのか、つくられる設計書はどういうものかに関して以下に紹介します。

作業ボリュームの把握や全体のイメージを関係者全員が共有するために、全体を可視化する、および流れをつかむための要素です。基本的に必要な要素ですが、開発規模によっては作成しないこともあります。

よくつくられるドキュメントは下記のとおりです。

機能一覧
開発対象のシステムを機能に分割し一覧にしたもの
業務フロー図
開発対象のシステムを使って業務がどういう流れで進んでいくのかを表現した図
状態遷移図
状態の移り変わりを表現した図(状態を管理する必要がある概念が存在する場合に必要)
データフロー図
データの流れを表現した図。すべてのデータに対してというよりも、システムを使うなかで増減するデータを主に対象にする
入出力関連図
画面や帳票などのアプリケーションが、どのテーブルを参照しているか、どのテーブルデータを更新しているかを図で表現したもの

開発対象のシステムにおいてどのような画面をつくるのか、画面で何ができるかをあらわす要素です。GUI(画面)を提供する場合に必要になり、そういった機能がある場合は開発規模にかかわらず作成することがほとんどです。

よくつくられるドキュメントは下記のとおりです。

画面一覧
開発対象のシステムにおいて構成される画面の一覧
画面遷移図
画面の構成をあらわす図で、画面がどのような順序で表示されるか、あるいは画面どうしがどのような関連性をもっているのかを示した図解のこと
画面設計書
画面に表示される項目やレイアウト、操作方法、遷移するページ、動きなどを表現したもの

開発対象のシステムで用いる帳票の種類や帳票を出力するタイミングをあらわす要素です。帳票を出力する機能がある場合に必要になり、そういった機能がある場合は開発規模にかかわらず作成することがほとんどです。

よくつくられるドキュメントは下記のとおりです。

帳票一覧
開発対象のシステムが出力する帳票の一覧
帳票設計書
帳票に表示されるレイアウトや項目、設定される項目の取得先などを表現したもの

開発対象のシステムにおいて一括処理やタイマー処理といった画面からの入力以外での処理を実現する場合に、どのような処理をバッチで実現するかをあらわす要素です。画面以外からの入力で処理を実現する場合に必要になり、そういった機能がある場合は開発規模にかかわらず作成することがほとんどです。

よくつくられるドキュメントは下記のとおりです。

バッチ処理一覧
開発対象のシステムにおいて構成されるバッチ処理の一覧
バッチ処理フロー図
どのバッチがどのタイミング、どういう順序で実行されるかを示した図解のこと
バッチ処理設計書
バッチ処理についての入出力や、実行される処理、参照及び編集するデータを表現したもの

システムを開発する際のデータの構造をどうするのか、どう管理していくのかをあらわす要素です。データを使わないシステムはほとんどないため必要になる可能性は非常に高いです。また、データベースの定義から設計書を自動生成するため、実際に作成してから設計書を起こすこともよく行われています。

よくつくられるドキュメントは下記のとおりです。

テーブル一覧
開発対象のシステムにおいて構成されるテーブルの一覧
テーブル定義書
どのテーブルにどんな種類のカラムを用意するか、どういう制約を設定するかを表現したもの
ER図
データ(Entity)間の関係性(Relationship)を図解にしたもの

開発対象のシステムが自身とは異なるシステムに連携する際に、どういう連携方法か、何を連携するのかをあらわす要素になります。他システムと連携する場合に必要になり、そういった機能がある場合は開発規模にかかわらず作成することがほとんどです。

よくつくられるドキュメントは下記のとおりです。

外部インターフェース一覧
開発対象のシステムと連携するシステムのインターフェースの一覧
外部インターフェース仕様書
ほかの何のシステムに連携するのか、どういう形式で連携するのか、何をどういう形式で連携するのかを表現したもの

開発対象のシステムを安定的に稼働させるためにアプリケーション以外に何を用意しないといけないのかをあらわす要素です。基本的に必要になりますが、開発規模によっては作成しないことがあります。

よくつくられるドキュメントは下記のとおりです。

システム構成図
サーバーやデータベース、ネットワークなどがどのように構成されているのかを図解したもの
運用設計書
システムを安定稼働させるためにシステムを運用する人の定期的な作業や障害発生時の対応方法などをまとめたもの

工程ごとに担当者が異なる場合には、詳細設計の担当者はシステムのユーザーが視覚的に確認できる画面や機能についての仕様まで決めることができないこともあるため、そのような仕様は基本設計の段階で決めておくことが望ましいでしょう。ほかにも詳細設計以降で準備すると、同じようなコードが複数できあがり冗長になることでメンテナンス性が低くなってしまう可能性があります。

よくつくられるドキュメントは下記のとおりです。

コード定義書
定義づけされたコードをデータとして格納するためにコードとその定義をまとめたもの
メッセージ一覧
画面やバッチの処理によって出力されるメッセージを一覧にまとめたもの

基本設計は、何を実現するのかを定めるにせよ定めないにせよ、このコラムで紹介した観点や要素をふまえながらいずれかの設計書を作成していき、後続の工程が円滑に進むことができるようにしていくことが重要です。

また、忘れてはならないのは、基本設計はシステム開発を依頼する側(システム利用者、発注者)と依頼される側(開発者)との間で開発をはじめる前に最後に取り決めをする工程だということです。基本設計の工程が終わったあとで不備が見つかった場合、依頼する側とされる側の双方で仕様の調整が必要になるだけではなく、スケジュールやコストの調整が必要になることも少なくはありません。そのため、基本設計の精度をいかに上げておくのかということは重要なポイントといえます。

もし、フォーマットどおりでは表現をしきれないという場合には、形には固執せず、必要になる要素を考えてその内容にそった資料(設計書)を作成することが基本設計にとってはむしろ大切なことだと思います。