設計書は何のために有るのか

2019年4月9日火曜日

システム開発 システム業界問題

t f B! P L

このブログは主に業務担当者などITシステム発注者の非情技(非ITエンジニア)向けに書いています。
しかし、この記事は非情技と情技師(ITエンジニア)の両方に跨がる話です。

境界を引くのが難しいのでこうなりました。
ご了承ください。

また、私は文章を読みやすくする為に文中では「です。ます。」などの敬語を使用しません。
威張っているわけでは無いのでこの点もご了承ください。

設計書の種類

このことは他の情技師の中でも時々言われることなので、似たようなことを言っている人は他にも居ると思う。
元々、私だけの意見ではないのでその点は了解して欲しい。

ウォーターフォール開発では設計書は前工程の「基本設計書」と、その次の後工程の「詳細設計書」というものがある。

また、システム発注元の顧客に説明する為の「外部設計書」と情技師が開発チームでシステム設計する為の「内部設計書」という物が有る。

SIer業界では「基本設計書」と「外部設計書」を同じ物と考え、「詳細設計書」と「内部設計書」を同じ物と考える事が多いが、厳密にはこの考え方は間違いで有る。

基本設計書と詳細設計書とは

基本設計書と詳細設計書は試行錯誤の道具であり考えた結果を記録するものである。
基本設計書は前工程であり、詳細設計書は後工程である。
基本設計書の作成で大枠の設計を行い、詳細設計書の作成で細かい部分の設計を行う。
更に細かい設計はコーディング(プログラミング)で行う。
システム開発は基本設計書・詳細設計書・プログラミングの三階層の設計によって行う。
プログラミングはよく「製造」と誤解されるが間違いだ。
プログラミングは設計であり、更にテストとデバック段階に入ると「開発」になる。
開発は製造業に例えると「試作品を作ってみて改良を繰り返す」工程と同じだ。
ソフトウェアに「製造」工程は無い。
それは現代では「ダウンロード」や「インストール」が製造に当てはまる。

人間はいきなり細かく複雑なことは考えられない為、最初は大枠から大雑把に考え、次に細かいところを考えて、複雑なソフトウェアを作っていく。

基本設計書が一番「大枠」で、詳細設計書が「中枠」、コーディング(プログラミング)が「小枠」の設計なのだ。

小規模なシステムやツールなら基本設計書から、いきなりコーディング(プログラミング)に進むことも珍しくない。
「現代では詳細設計書など必要無い」という意見もある。

基本設計書と詳細設計書とは試行錯誤の道具であり、その成果物である。
ソースコードもその範疇に含まれる。

外部設計書と内部設計書とは

外部設計書とは厳密に言えば「インターフェイスの設計書」である。
インターフェイスとはシステムが人間や他システムとの連携など「システムの外部」と接する「接触面」の仕様のことだ。
人間との接触面はシステムの画面と帳票になる。
他システムとの連携「接触面」はHULFTやSOAPやRESTなどで接続し、データはCSVやXMLやJSONで送受信する。
これらがインターフェイスとなる。
外部設計書とはこれらインターフェイスの設計を試行錯誤する道具であり、その成果物である。

内部設計書とは外部設計書の逆であり、外部から見えないシステムの内部を設計する設計書である。
外部設計書によって先にインターフェイスの仕様が定まった後で、機能をどのように実装するかを試行錯誤する道具であり、その成果物である。

先に外部設計書を作る必要があるので外部設計書が前工程になる。

この点が外部設計書と基本設計書を混同してしまう理由でもあると思う。

「基本設計書と詳細設計書」と「外部設計書と内部設計書」の違い

「基本設計書と詳細設計書」は「大雑把な枠組みの設計書」と「細かい枠組みの設計書」であり、
「外部設計書と内部設計書」は、「ユーザー(や他システム)から見える部分の設計書」と「見えない内部の設計書」という区別であり、区別の次元が違う。

だからもし全ての設計書を作れば、次のように4つの設計書を書かなければならない。
基本外部設計書、基本内部設計書
詳細外部設計書、詳細内部設計書

しかしこれを全部書くのはバカげている。
時間と労力とコストの無駄でしか無い。

だから多くのシステム開発の現場では「基本設計書と詳細設計書」を作成し、主に基本設計書でシステム発注元のユーザーと相談提案を行う。
それは外部設計書ではないので、ユーザーにとって必要の無い「内部」の設計も記載されている。
しかし、一々「外部設計書」を書くのはコストの無駄でしかないので多くのシステム屋は基本設計書をユーザーに見せる。
これは建設的コストダウンの為に行っていることは非情技(非ITエンジニア)は理解して欲しい。
基本設計書は試行錯誤の為に必要であり、外部設計書を書くのは時間とコストの無駄なのだ。
ユーザーに取って無駄な情報が記載されていることは許容して欲しい。

アホなSEには外部設計書だけ書いて基本設計書を書かない人もいる

こういうSEは十中八九炎上する原因になっているので、ユーザーもプログラマーも避けることをお勧めする。
基本設計書を書かないと言うことは内部の設計を行っていないということだ。
実装できるわけがない。

詳細設計書は必要なのか

システム開発の世界では昔から「詳細設計書は本当に必要なのか」ということが繰り返し議論されてきた。
コンピュータ言語が進歩して可読性(読みやすさとわかりやすさ)が向上し、「わざわざ詳細設計書など書かなくてもいきなりプログラミングしても良いのでは無いか?」という意見は15年ぐらい前からある。
私も「詳細設計書不要論」を支持する側の人間だ。
ただ状況によって詳細設計書は必要になる場合は現代でもある。

設計と開発を分業する場合

まず開発を担当する設計者とプログラマーが別の人間である場合は詳細設計書を書いた方が良い。
詳細設計書を書かずにプログラマーに開発を任せるケースも多いが、これが任せられるレベルのプログラマーならば、最初から基本設計のレベルから任せた方が早く効率が良い。
分業のやり方を間違っていると言わざる得ない。
任せられないレベルなら詳細設計書を書くしか無い。
そもそも開発を担当する設計者とプログラマーが別の人間であるのが、最初から間違った分業の仕方なのだ。
そういう意味では正しい分業すれば詳細設計書は要らないと言える。
どうしても分業が必要なら詳細設計書は必要だ。

大規模システムを開発する場合

大規模システムを開発する場合は全体の大雑把な枠組みが大きくなるので、基本設計・詳細設計といった設計の階層が多くなる。
要するに基本設計の上の階層が必要になる。
大規模システムの詳細設計書の粒度は小規模システムの基本設計書ぐらいの粒度になるのでは無いだろうか。
そういう意味では粒度の細かい詳細設計書はやはり必要無いとも考えられる。

設計書と仕様書は違う

設計書とは簡単に言えば「システムを作る前に作成する物」と言える。
仕様書は「システムを作った後に作成する物」と言える。

設計書は先に説明したように「試行錯誤の道具であり成果物」である。
この成果物を使用してプログラミングと開発を行う。

仕様書はシステムを作った後に、完成し既に定まったシステムの仕様を知らせる為に作成された資料だ。

そういう意味では通常は仕様書には外部仕様書しか存在しないとも言える。

設計書は開発と試行錯誤を進める内に内容が次々変わっていく。
しかし仕様書はある意味インターフェイスの型の保証でもあるのでバージョンアップしない限り変更しない。

システムを他の開発者に引き継ぐ為に内部仕様書が作られる場合もある。
これもシステム開発後に作成されるものである。





以上、設計書について一般に誤解されていることが多いことについて、解説しました。
間違った認識で仕事を進めても上手く行きません。
発注元を含めて。

外部設計書だけ書いて基本設計書を書かないアホなSEはいつまで経っても居なくならないです。
自分で開発(プログラミング)するならそれでいいが、大概は開発は人任せです。


誤解が解消されれば幸いです。

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ