1．設計書の作成

◆作業の概要、目的、タイミング

システムの流れ、画面・帳票、機能、データベースなどについて、詳細を定義したドキュメントを作る。
ユーザに対しては「何をするものか」「どうなるものか」が分かるように、  
開発チームに対しては「どう製造するか」が分かるようにする。

• プロジェクトにもよるが、顧客にドキュメントを納品することがある。
  その場合は、当然「納品物」として扱われる。
  内容的に（顧客が見て分かるように書かれている、など）適切であることはもちろん、納期までに体裁を整えて提出しないといけない。
• 製造にたずさわる技術者は、設計書（仕様書）を見てプログラムを作成する。
  設計者とプログラマが同じ場合もあるが、担当者が変わることも多い。記述漏れがあったり、間違いがあったりしても、
  プログラマはそれを信じて作ることになる（機能漏れや間違いがあるシステムができる）。

開発工程全体のうち設計工程は、設計書（または仕様書）を作ることが目的のフェーズ。
設計書（または仕様書）が、設計工程での成果物となる。

◆事前に必要なもの、情報

この作業の前段階として以下の作業を行い、また、作業に必要な情報として以下のものや情報等を用意しておく。

◆設計書として一般的な、定義項目

設計書としての主な項目を挙げるが、プロジェクトやシステムによっていろいろ違うこともある。
内容に応じて必要なものを選び、足りないものは追加する。

システム概要、目的、目標

• 何をするシステムか（対象業務は何か）、そのシステムによってどんなニーズを満たすことを目指しているか、などを説明する。

システム化範囲、主機能

• 対象業務や対象ユーザの中で、そのシステムを使って「誰が何をするか」を説明する。

開発技術

• どんな技術要素を使うか、を説明する。マシン、OS、DB、プログラム言語、など。

ネットワーク構成、ハードウェア構成

• どの場所にどんなマシン（OS、DB、アプリケーションの機能など）が置かれ、ネットワークでどうつながるかを説明する。

メニュー体系・画面構成

• システム全体での画面・帳票の流れを説明する。

画面設計・機能設計

• 各画面について、デザイン・レイアウト、配置されるデータ項目の詳細、（ボタンなど）その画面に関わる機能の詳細などを説明する。

帳票設計

• 各帳票について、デザイン・レイアウト、配置されるデータ項目の詳細などを説明する。

機能設計

• システムで実行される各機能の詳細を説明する。
  （システム形態や規模によっては、画面設計にすべて含めることも可能。）

データベース構成、テーブル定義

• システムで必要となるデータベースの数と種類、その中で必要となるテーブルの数と種類、テーブル相互の関係（リレーション）、各テーブルの詳細（フィールド詳細）を説明する。

コード体系

• システムで必要となる各種コードを洗い出し、それぞれの詳細を説明する。

◆具体的な作業項目、手順

文章よりも、図表が主体となる。  
だいたいプロジェクト内で決まったフォーマットを用意するものなので、その中を埋めていくイメージで作業を進める。

• フォーマットがない場合は、あらかじめ作っておく。または、類似プロジェクトで使っていたものをもらって、項目を調整する（システムが違えば、項目なども多少の違いがあるので）。
• まずフォーマットが先にあったほうがいい。
  とりあえずバラバラで作って後で合わせるのは、手間が大きい。

メニュー体系以降は、ほぼ画面・帳票単位、機能単位で設計書が作成されることになる。  
それまでに（メニュー体系の検討時に）、画面・帳票、機能などをきちんと分けておく。

• 「そのシステムがどんなものか」という説明は、全体 ⇒ 細部へという流れとなる。

画面や帳票など目に見えるものは、そのイメージをのせてしまったほうが早い。  
それを見れば分かるようなことは、あらためて（文として）書かなくてもいい。  
イメージに対して補足説明・詳細説明が必要な部分について、表などで説明をしていく。

• 形式や量も大事だが、「見て分かること」が大切。それを満たせるような書き方であればいい。

画面・帳票イメージは ワープロ的に描いてもいいし、プロトタイプ画面を作ってハードコピーをのせてもいい。  
決まりはないので、ドキュメントとして統一されていればいい。（プロジェクトによっては、指定されることもある。）  
早くからイメージをある程度決められる場合は、プロトタイプ画面のハードコピーを使うほうが、製造時にそのまま使えるので便利。

• ただし、まるごと使えると思わないほうがいい。ちゃんと本番向けの修正、名前付けなどをやり直す必要はある。あくまで「枠は使える」程度。
• ハードコピーの撮り方、ドキュメント上での扱い方を知っておく。

ドキュメント作成上の注意点

• ページ番号
  ファイルを分けたり、「ある部分はWord、ある部分はExcelで作る」ということもあるが、最終的にはちゃんと通しで振る。
• 項番、項目タイトル
  各項目には項番と項目タイトルを適切に振る。
  いきなり内容に入ると、ドキュメントを順番に見ていて、何のことだかよく分からない。
• 目次
  項番・項目タイトルとページ番号を、実際ときちんと一致させる。
  説明や質疑応答の際、「○ページの△△については～」と言いやすい。
  （これがなかったり、一致してなかったりすると、説明や質疑応答がほんとうにやりにくい。）
• フォント
  全体で統一する。「項目タイトルはゴシック体、詳細部分の文字は明朝体」などといった使い分けもできる。
• 「見て、分かりやすい」構成を意識する。
  • 文章をただひたすら並べるのではなく、図表や箇条書きを利用する。
  • 図示や色分けなどを工夫し、強調したいことを強調する。
  • Officeアプリケーションなどで、見栄えがいい機能や効率よくできるような機能を知り、使えるようにしておく。

◆成果物、最終イメージ、作業例

この作業で以下の成果物を出す。または完成イメージの状態にする。それをこの後の作業につなげる。

◆作業上のポイント、注意点

設計書は、顧客／ユーザも技術者も、どちらの立場も見るものとなる。

• 顧客／ユーザは、「自分たちのシステムの概要／詳細がどんなものか」「依頼したベンダーが、どんな仕事をするか」を確認するために見る。
• 技術者は、「システム企画を、どうやって（技術的に）実現するか」を知るために見る。

もし設計書がなかったら？（顧客に対して）

• こちらが「お客さまにこう言われたので、そのように作った」と思っていることでも、相手から「そうは頼んでいない、こうしてくれ」と後で言われることがある。
  もし設計書がなければ反論材料がないので、結局戻り作業を迫られることになる。
• そうならないよう、決まったことはきちんとドキュメント化し、それを相手にも見せて合意を取る。
  「○○書」というような明確な形にまではしなくても、テキストベースのメモを交換して保存したり、議事録に含めたり、やりとりしたメールを保存しておくなどする必要がある。

もし設計書がなかったら？（製造時）

• 設計者がそのまま製造に入れば（設計の経緯を知っているので）問題ないが、製造時に担当が変わることがある。
  その場合、設計の現場にいなかった人には、どこをどんな風に作ればいいのか分からない。
• そのため、製造時（プログラミング時）に指定が必要なことや言われないと分からないことはドキュメント化し、見れば分かるようにしておく。
  そうしないと、設計者の意図とできあがりが違ったり、ユーザのイメージと違ったりすることがある。

Copyright © Xincor miXell Co., Ltd. All rights reserved