はじめに
みなさん設計してますよね？
渡された設計書の通りにプログラミングだけをしている場合は除いて、大抵の方は設計をしていると思う。しかし7年ちょっとの開発経験の中で、実際に設計ができている人と仕事をすることは 稀 であった。
設計ができていない人に共通するマズイ点は オブジェクト指向などのテクニックに走る傾向がある ように思う。実際に「C++で開発するんだからオブジェクト指向でやろう！」と話しているのを聞いたこともある。書店の設計コーナーにオブジェクト指向関連の書籍が並んでいるのを見て、「あー、こういった書籍で紹介されている技法を駆使してソフトウェアを作ることを設計というのね」と思ったのかもしれない。
変更に強いソフトを作るためにオブジェクト指向などのテクニックが役に立つ場面もあるが、それ以上に しっかりとした設計根拠を持つこと の方がはるかに重要である。
設計根拠とは
設計根拠とは ある設計案を採用する決め手 のこと。そして設計をする際はプロジェクトメンバに なぜそのような設計にするのかをきちんと説明できるよう にすればオッケーというのが最近の私の考え。
言葉で説明されただけではピンとこないかもしれないので、少し例を挙げてみる。
例題（１）
例として オブジェクト指向で作るFizzBuzz を見ると、簡単なFizzBuzz問題でも複数の設計があることがわかる。
リスト1はオーソドックスな設計だと思う。「3または5で割り切れる場合はFizzBuzz, 3で割り切れる場合はFizz, ...., を出力する」というFizzBuzz問題の説明文がそのままコードになっていて理解しやすい。
リスト2, 3はオブジェクト指向を使った設計になっている。FizzBuzz問題の説明文には出てこない、かつ、思いつかない戦略やファクトリという新たな概念が登場していて、リスト1と比べると理解し難い。
さて、どちらの案を採用したら良いのか？シンプルなリスト1か？オブジェクト指向を使っててカッコイイ感じになっているリスト2, 3か？
私ならリスト1の設計を採用する。というのもリスト1は FizzBuzz問題の メンタルモデル をそのまま表現していて理解しやすいから である。
もしリスト2, 3の設計案を採用する場合は プロジェクトメンバが納得できる、戦略やファクトリという新たな概念が必要な背景や理由 がなくてはならない。
例題（２）
Java向けHttpClientには様々なライブラリがある。Apache Commons HttpClientとかOkHttpとか。
どのライブラリを使うか決める際に ググって最初に出てきた○○が良さそうだから〇〇にする とか 以前参加していたプロジェクトで使用した経験がある（かつ、他のライブラリは使用経験がない）から〇〇にする とかやりがちだが、 JavaのHTTPクライアントはどれがいいのか？ で書かれているようなことを検討しなくてはいけない。
まとめ
仕様を満たすソフトウェアを作る方法はたくさんある。様々ある方法から プロジェクトメンバが納得できる根拠を持って一つの方法を決定すること が設計ですべきことである。つまりオブジェクト指向などの小難しいテクニックを知らなくても設計はできる。