前回は、開発とはソースコードの差分を作ることであり、設計書とはその差分をどう作るか説明する文書であることを書いた。
そのうえで、設計書が本当に必要なのかどうかを考えていきたい。
設計書は必要か？
そもそも「設計書は必要なのか？」という疑問がなぜ生まれてくるのかというと、設計書がなくてもコードは書けるから。 開発で生み出すのが「ソースコードそのもの」であろうが「ソースコードの差分」であろうが、これは変わらない。
で、ぶっちゃけた話、個人開発の場合は設計書を書く必要性はあまりない。 そして、チームでの開発だとしても、実装前に方向性の確認がとれてそれを記録に残せているのであれば、設計書はなくてもいい。
これはなぜかというと、結局のところ文書というのはコミュニケーションの手段にすぎないから。 個人開発の場合はコミュニケーションをとる相手もいないので不要だし、チーム開発だとしても設計書で行うべきコミュニケーションが別の手段でできているのなら不要となる。 設計書という形式にこだわる必要はない。
ただ、その場合も「設計」自体は必要なことに気をつける必要がある。 そして、チームで開発する場合も「別の手段でできているなら」という条件がちゃんと満たされることは滅多にないので、基本的にはちゃんと設計書を書いた方がいい。 じゃないと、結局のところ「設計」がちゃんとされないままにコードが書かれて、コードレビューをしようとなった段階で「なんじゃこりゃ」みたいに発覚、その時点ではもうどうしょうもなくなってるということが起きがちなので。
そもそも「設計」とは何なのか？
ただ、上のように書くと、「そもそも『設計』って何なんだ？」ってなりそう。
- 「設計書」は不要な場合もあるけど、それでも「設計」自体は必要とは、どういうことなのか？
- ちゃんとした「設計」がされてないとは、どういうことなのか？
これを理解するには、「Why-What-How」の構造を意識する必要がある。
開発とはソースコードの差分を生み出すことだけど、それを実施するのは何かしらの理由があるからだ。 たとえば新機能がほしいだとか、バグを直す必要があるからだとか、将来の拡張のためにコードを整理する必要があるからだとか。 まぁいろんな理由があるにしろ、理由もないのにソースコードをいじることはありえない。
なので、開発のスタートにはまず「Why」つまり「要求」がある。
その要求を受けて、じゃあ実際に何をやっていくのか（あるいはやらないのか）を決める必要がある。 そうして決まるのが「What」であり、「開発で実現すること」すなわち「要件」となる。
要件が決まったら、今度はそれを実現するための方法を考える必要がある。 そうして得られるのが「How」で、「要件を満たすための方法」すなわち「設計」となる。
- Why：なぜ開発するのか（要求）
- What：何を開発するのか（要件）
- How：どう開発するのか（設計）
これをちゃんとWhy-What-Howの順にブレークダウンしていかないと、「何やってるの？」な開発になってしまう。 たとえば「東京から大阪に行きたいんだけど？」と言われてるのに「名古屋行きの切符を買うことにしましょう」と提案するのは変だし、ましてや「車を借りて横浜まで行きました」と報告されたらもう意味不明なわけだけど、実際の開発だとそういうことが起きがち。
そして重要なのが、1つのWhyを満たすようなWhatはたくさんあるし、1つのWhatを満たすようなHowもたくさんあるということ。 つまり、取捨選択の必要がある。 そして、たくさんあるWhatの中で実施するWhatを決める（と同時に実施しないWhatを決める）のが「要件定義」であり、たくさんあるHowの中で実行するHowを決める（と同時に実施しないHowを決める）のが「設計」となる。
そういった取捨選択をやらず、お客さんに言われたままのことをやったり、とりあえずでパッとコードを変更してしまうと、あとになって方針が全然間違ってることが分かって大きな手戻りが発生する可能性が出てくる。 というか、手戻りできるならまだよくて、大抵はスケジュールに追われて「現状が仕様」のゴリ押しになることが多い。 そうなると、あっという間にゴミだまりのソフトウェア、ソースコードの出来上がりとなる。。。
そういったことが起きないようにするためには、ちゃんと取捨選択ーーすなわち「要件定義」や「設計」ーーを行い、それが間違った方針になってないかをコミュニケーションしていく必要がある。 そのための文書が「要件定義書」や「設計書」となる。
今日はここまで！
