設計書が必要か?

システム開発の中で、設計書の必要性が問われやすいのはソフトウェア開発だと思う。ソフトウェア開発の方法は、構造化やデータ指向、オブジェクト指向といった設計自体の技術論と、その設計をどう進めるかといった開発プロセスがセットで語られる。どの組み合わせでも設計書の立場が明確になることはほとんどない。そこで、設計書がソフトウェアを構成する成果物として必要かどうか現場レベルのローテクで考えてみる。
量産品や建築、機械といった物作りを例に見ると設計書が必ず存在し、設計書にしたがって製造される。設計を任されたほとんどの SE やプログラマは気がついたと思うが、先にあげた例の場合、設計者と製造者が分業されている。(※)これは分業することによって設計者は要求実現の方法に集中でき、製造者はいかに効率をあげるかということに熱をいれることができるからだと思う。(※2)つまり、それぞれの作業目的が異なるのである。こうなるとどうしても両者の間で物作りのための情報伝達手段が必要となる。そこに設計書の存在価値がある。
ソフトウェア開発ではどうか?設計書は必要だろうか?
YES の場合はどういう時か?よく、開発規模が大きい場合設計書が必要といわれる。これは明らかにリソース面から分業が必要になるだろうということだと推測できる。
別のケースでは他業種の例のように設計担当をおく場合があるかもしれない。これは設計者と製造者のリソースを開発案件に縛られないするためだと考えられる。多少オーバヘッドがあると思うが開発案件を多数こなさなければならない状況では意味があると思う。
また、ソフトウェアの構成によっては設計書が必要な場合がある。フレームワークやライブラリといったシステム共通のコンポーネントを製作する場合や、プロセス間通信などを行う場合などシステム内に明確に境界線を引くことができ分業可能な場合である。
では、NOの場合はどうか。
ソフトウェア開発の最初から最後まで一人でこなすことが可能な場合であると思う。ソフトウェアはソース・コードを記述することで製作されるが、このソース・コードというのは見方を変えると設計書なのである。つまり、要求の実現方法を直接書いていることになる。そうなるとソース・コードを書く前に実現方法が記された設計書を書くことは重複作業となる。一人で作業する場合、明らかにソース・コードを書く前のいわゆる設計書というものは不要となる。(※3)

(※)一通りは自分で作業する大工のオヤジでも設計と製造は明確に作業が分かれているはずである。また、途中で設計変更する場合もあるかもしれないが、親方の設計変更の目的は製造できないことで行き詰まったわけではないと信じている。(^^;
(※2)実際の量産工場では歩留まりやコスト低減のために設計変更を行う担当がいるかもしれない。この場合でも設計者は効率を実現するための方法を探すことになる。
(※3)設計しないということではない。ソース・コードを書くために自分の頭の整理する目的で設計書を書く場合、それは私的なもので、成果物ではないということ。(なので、メモ書き程度でもぜんぜん問題ない)

2件のコメント

  1. 確かにコードを読んでいて意図がわからない場合は困ります。楽できる場合は、近くにコード書いた人が居るか、テストケースがきちんと記述されているか、あるいは、ちゃんとコード読み方手引があるか、、はたまた書き手と読み手の思考回路が一致(DNAレベル?)しているか。。。ふぅ。でもやっぱり、読み手が苦労するしか現実ないんだよなぁ。

  2. 私は設計書とは「実現方法」ではなく、なぜそのように実現するように至ったかという「意図」を書くものであるという意味において必要だと思っています。コードは結果であり結果からもともとの目的を類推することが困難な場合は特にそうです。例えば某オペレーティングシステムのVM部分とかね(苦笑

コメントを残す