ソフトウェアを開発してると、「設計って何をやればいいの?」とか「どうやるべきなの?」という話が出てくると思う。 場合によっては「設計っていらなくね?」とかも。
自分もこれまでにいろいろ考えてきたので、設計や開発プロセスに関して「こうやるとよさそうだ」という現時点での考えを書いてみたい。
製造業へのたとえ
ソフトウェアの開発プロセスはよく製造業の開発プロセスにたとえられる。
すなわち、製造業だとまず企画を立てて、そのあと設計書を作り、それに基づいて実際の製品を製造するわけだけど、ソフト開発も同様に、まず要件定義をおこない、設計書を書いて、それに基づいてソースコードを書くと。
対応付けしてみると以下:
工程 | 製造業の成果物 | ソフト開発の成果物 |
---|---|---|
企画・要件定義 | 企画書 | 要件定義書 |
設計 | 設計書 | 設計書 |
製造 | 製品 | ソースコード |
これはそれっぽい説明で分かりやすいので、ソフト開発をしたことがない人には受け入れられやすい。 その結果として、製造=プログラムを書くのは設計書に基づいて手を動かすだけだから簡単だと勘違いされやすい。
でも実際にソフト開発をしたことがある人なら、プログラムを書くのがそんなに簡単でないことはすぐに分かる。 というか、プログラムを書くことこそが知的な生産活動の中心で、設計であるともいえる。
実際、ソースコードとは「ソフトウェアの設計書」なわけだし、ユーザに使ってもらうのもソースコードそのものではなくそれをビルドして作られるソフトウェアなわけだから、上記の対応はおかしい。
正しく対応づけるなら、以下のようになる:
工程 | 製造業の成果物 | ソフト開発の成果物 |
---|---|---|
企画・要件定義 | 企画書 | 要件定義書 |
??? | 設計書 | |
設計 | 設計書 | ソースコード |
製造 | 製品 | ソフトウェア |
ソフト開発における製造はもはや人間の仕事ではなくて、コンパイラなどコンピュータの仕事。 人が実際に手を動かさないといけない製造業と違い、機械が勝手に工程を実施してくれるので、工程として見えにくいんよね。
ただ、そうなると「じゃあソフト開発における『設計書』ってなんなんだ?」というのが問題になる。 ソースコードこそが設計書なのだとしたら、それとは別に作る「設計書」というのは一体何を設計してるというのか。 それこそ、ソースコードさえあれば設計書は不要なのでは?と考える人も出てきそう。
このあたりの混乱を解き明かしていきたい。
今日はここまで!