システム開発で必要な設計書。プログラムは設計書を元に書かれます。
チームで開発を行うため、設計を行う人と、プログラミングを行う人は
違うことが多いです。プログラマを作りやすい設計書と作りにくい設計書
があります。この違いは何でしょう？
もくじ
- 設計書は何故必要か？
- わかりやすい設計書とは？
1.設計書は何故必要か？
まず、設計書は何故必要でしょうか？設計書が必要な主な理由は以下です。
- お客さんとプログラマの橋渡し
- システム全体を俯瞰する
- 移植可能にする
「お客さんとプログラマの橋渡し」ですが、お客さんはプログラムはわかりません。
お客さんから業務仕様を聞いてシステムエンジニアがその業務仕様を
プログラミング可能なロジックを作っていきます。それが設計書です。
例えば、お客さんから要望で「休みの日は画面に花を表示して」というものがあったとします。
システムエンジニアは「休みの日」⇒「土日、祝日」という条件に変換して、
i)「土日、祝日」の場合
画面に花を表示する
ii)平日の場合
画面に花を表示しない
というロジックを作っていきます。
これをプログラマが見て
if(「土日、祝日」の場合) {
画面に花を表示する
} else {
画面に花を表示しない
}
というプログラムにしていきます。だれもがプログラムを知っているわけではないので
それを橋渡しをする設計書が必要となります。
逆に言うと、だれもがプログラムを理解できる環境では設計書を書かない場合があります。
設計書を書く分スピードを速くすることができるからです。
「システム全体を俯瞰する」とは、プログラムだけを見た場合、
いったい何の処理を行っているかがわかりません。
通常はコメントで何の処理を行っているかを書いています。しかし、
プログラムは俯瞰してみることはできません。設計書であると
日本語で書いているため、最初に目次をかいておけば俯瞰できます。
色々なプロジェクトをすると全てのプログラムを覚えているわけでは
ありません。また、メンバも入れ替わります。まずは設計書をみて
システムの全体構造をりかいするのです。優秀なプログラマであっても
大規模なプロジェクトの場合、プログラムを見てシステムの全体像を
理解することはなかなかできません。
「新しいシステムへ移行可能にする」とは、設計書は基本的にプログラム言語を
特定していません。何年も経ったシステムであればサーバを新しくすることや
データベース、Webサーバのミドルウェアを新しくします。
また、当時使用されていたプログラミング言語がもう使われていないもの
だった場合、別のプログラミング言語に変わったりします。
その一方で、会社の業務はあまり変わらないことが多いのです。
そのときに、設計書はあまり変えずに、設計書を元にプログラムを
書き換えることもあります。
ただ、当時の設計書があまり書かれていなかったりした場合、
プログラミングから設計書を作ることもあります。
2.わかりやすい設計書とは？
ではわかりやすい設計書とは何でしょうか？それはプログラミングしやすい設計書です。
プログラミング経験の無い人が書いた設計書はたいていわかりにくい設計書が多いです。
論理的ではないからです。わかりやすい設計書は以下の設計書です。
- インプットとアウトプットが明確になっている
- 全ての条件を網羅している
- この処理の後にどこに行くかが明確になっている
ロジックは表を書くように設計するのがわかりやすくなります。
わかりやすい設計書を書くことができればプログラムもわかりやすくなり
テストもし易くなります。つまり、プロジェクト全体の生産性が上がるのです。
いかがでしたか？「スキルアップの条件！わかりやすい設計書とは！？３つの基本」
毎回、ステップアップするヒントを書いていきたいと思います。
ちょっとずつステップアップしていきましょう。
