ソフトウェア設計を学び始めた頃、多くの人は「設計パターン」や「ベストプラクティス」を覚えようとします。

しかし、経験を積むほど、あることに気付きます。

良い設計とは、ハウツーではないということです。

ハウツーは具体例に過ぎない

例えば、100個の設計事例を学んだとします。

それらを一つずつ覚えるのではなく、

  • なぜその設計が良かったのか
  • 何を守ろうとしていたのか
  • どのような考え方が共通しているのか

を考え続けると、100個の具体例は、やがて10個程度の共通した思想へと整理できます。

さらに、その10個を見比べると、もっと本質的な共通点が見えてきます。

最終的には、

「良い設計とは○○である」

という一言で表現できるようになります。

しかし、この一言だけを最初に聞いても、多くの人は何を意味しているのか理解できません。

それは、この一言が100個もの具体例を抽象化した結果だからです。

抽象的な概念はそのままでは実践できない

抽象化された概念は、本質を表しています。

一方で、そのままでは実践には使えません。

例えば、

「責務を適切に分離する」

という言葉だけを聞いても、

実際のプロジェクトで、

  • どこでクラスを分けるべきか
  • どこまで責務を持たせるべきか
  • 例外的なケースではどう判断するか

までは分かりません。

抽象的な概念は、「考えるための軸」を与えてくれるものであり、「答え」そのものではないのです。

設計はパターンではない

設計パターンは非常に役立ちます。

しかし、それだけでは十分ではありません。

なぜなら、ソフトウェア開発で解決したい課題は無限に存在するからです。

チームも違えば、

  • ビジネス
  • 技術的制約
  • 開発体制
  • メンバーの経験
  • 将来の変更

もすべて異なります。

つまり、たとえ100個のパターンを覚えたとしても、世の中のすべての問題を解決できません。

だからこそ重要なのは、

パターンを覚えることではなく、未知の問題に対して適切な判断ができる思考の型を持つことです。

思考の型は経験によって磨かれる

思考の型は非常に抽象的です。

そのため、実践経験が少ないうちは、

「なるほど」と思っても、実際の設計にはなかなか活かせません。

さまざまな失敗や成功を経験し、

「あの設計が良かった理由は、この考え方だったのか」

と何度も気付くことで、初めて抽象的な考え方が自分のものになります。

つまり、思考の型は知識ではなく、経験によって検証され、磨かれていくものです。

人間の脳も本質を抽象化している

実は、この考え方はソフトウェア設計に限った話ではありません。

人間の脳は、使わない知識を忘れていきます。

もし、あらゆるハウツーをそのまま覚え続けようとしたら、脳の負担は非常に大きくなります。

そこで脳は、多くの具体例を経験すると、

  • 共通点を見つけ
  • 抽象的な概念へ整理し
  • 必要な場面で、その概念から具体例を導き出す

という学習を自然に行います。

つまり、人間は無意識のうちに、

ハウツーを抽象化し、本質だけを残すように学習しているのです。

ソフトウェア設計についても、パターンとして覚えると、世の中の課題の数だけパターンを覚えることになってしまいます。

それは現実的に無理です。

だからこそ、現場でたくさんの事例を見て、そこから共通的な概念を抽出してこそ、初めて現場で使える抽象的な思考の型が身に付くと考えています。

まとめ

私は、設計とは「正しいパターンを知っていること」ではなく、

未知の問題に対して、適切な判断を行うための思考の型を持つことだと考えています。

設計書やデザインパターンは、その思考の型へたどり着くための教材です。

本当に身につけるべきなのは、個々のハウツーではありません。

数多くの具体例の中から本質を抽出し、どのような状況でも応用できる「判断の軸」を育てることこそが、設計を学ぶ本当の目的なのではないでしょうか。