設計ってナンダ？ - PART1

すごく苦労してない？

ちょっとした仕様変更はよくあることです。「ちょっとした」と言っても、それはお客さんにとっての話であって、それを実現する我々の苦労は全然ちょっとではないこともありますが、ともかく「仕様の」変更としてはちょっとぐらいのものはあって当然です。そんなとき、ちょっとの変更をどうやって実現するか話し合うために、チームのメンバーを全員集めて大会議を開催したりしていませんか？設計が正常に行われていれば、そんな気が滅入る会議を開催する必要はありません。ちょっとの仕様変更はちょっとの修正で実現できるような設計をしておけばいいのです。そう、たとえばシステムを正しくサブシステムに分割しておきさえすれば、変更を実現するための修正は、あるサブシステムの一部をちょっと手直しするというだけのものになるでしょう。正しい分割のもっとも重要な条件は、各サブシステムの機能を明確にするということだからです（機能が不明確だったり、同じような機能があちこちにあったりするのは正しくない分割です）。でも現実には、ちょっとの変更で大騒ぎすることの方が多いように思います。

仕様変更が起こったときに、「ああ、この変更はずいぶん前から要求されそうな気がしていたんだよなぁ・・・」と思うことはありませんか？やはりここでも設計の善し悪しがものをいいます。予測される変更を考慮して、それが実際に起こったときの手間を少なくするような設計をしておけば良いのです。でも現実には、将来への準備を怠っているケースが多いようです。

チームの中を見渡すと、みんながそれぞれ同じようでちょっとずつ違うプログラムを作っているということはありませんか？そういうときは、もっとうまい作業分担を考えればチーム全体としての作業の総量が減るはずです。作業の総量が減れば生産効率が良くなるし、バグも減ります。こういうことも設計の範疇です。

他人が作ったプログラムを修正するときも、設計の善し悪しが重大です。設計不在のプログラムを正しく修正するのは非常に骨が折れるか、または無理です（実際にそういう経験をしたことがある人も多いでしょう）。逆に、きちんと設計されたプログラムは読みやすいので直すべき場所を見つけるのが簡単だし、他人が作った良いコードを読むのは勉強にもなります。しかし、実際に良いコードに出会うことはほとんどないのではないでしょうか？

だからこそチャンスなんだ

どうやら、知恵を使いさえすればしなくても済むはずの苦労が、ソフトウェア開発業界には蔓延しているようです。これを逆に考えてみると、設計の技術を使いこなしてよけいな苦労を回避できるようになれば、人の何倍も仕事がこなせるようになるということです。