設計の引き出しは本でしか増えない

この記事は約 5 分で読めます。

経験 10 年でも設計パターンを 3 つしか知らない人がいる

経験年数が長いエンジニアが、必ずしも設計がうまいわけではありません。10 年間同じプロジェクトで同じアーキテクチャのコードを書き続けた人は、そのアーキテクチャには詳しくなりますが、他の選択肢を知りません。

設計の引き出しは、経験した設計パターンの数で決まります。しかし、1 人のエンジニアが実務で経験できる設計パターンの数には限りがあります。1 つのプロジェクトで採用される設計パターンはせいぜい数種類。転職を 3 回しても、経験できるパターンは 10〜15 種類程度です。

一方、設計の本を 1 冊読めば、20〜30 のパターンに触れられます。本は、実務では出会えない設計パターンを疑似体験させてくれる唯一の手段です。

実務で経験する設計は、所属する会社やプロジェクトの文化に強く影響されます。マイクロサービスの会社にいればマイクロサービスの設計ばかり経験し、モノリスの会社にいればモノリスの設計ばかり経験します。

この偏りは、設計判断の際に「自分が知っている方法」に引きずられる原因になります。本当はマイクロサービスが適切な場面でモノリスを選んでしまう、あるいはその逆。選択肢を知らなければ、最適な判断はできません。

設計の失敗は、数ヶ月から数年後に顕在化します。「この設計は変更に弱い」と気づくのは、実際に変更が必要になったときです。1 つの設計の失敗から学ぶのに 1〜2 年かかるとすると、10 の失敗パターンを学ぶのに 10〜20 年かかります。

本は、著者が数十年かけて蓄積した失敗パターンを数日で伝えてくれます。他人の失敗から学ぶことで、自分が同じ失敗をする時間を節約できます。

設計パターンに名前がついていることの最大の価値は、チームで議論できることです。「ここは Strategy パターンで実装しましょう」と言えれば、チーム全員が同じ設計を想像できます。

名前を知らなくても同じ設計はできますが、議論の効率が桁違いに落ちます。「条件によって処理を切り替えるんですけど、if 文じゃなくて、えーと、クラスを分けて...」と説明するのに 5 分かかることが、パターン名を知っていれば 5 秒で伝わります。

デザインパターン、リファクタリングパターン、アーキテクチャパターン。これらのカタログ本を 1 冊読むだけで、引き出しの数が一気に増えます。全パターンを暗記する必要はありません。「こういうパターンが存在する」と知っているだけで、設計判断の選択肢が広がります。

パターンの「What (何をするか)」を知った後、原則の「Why (なぜそうするか)」を学びます。デザインパターンの本でパターンを知り、設計原則の本で「なぜこのパターンが有効なのか」を理解する。この 2 段階で、引き出しの数と深さの両方が揃います。

本で学んだパターンを、次のプルリクエストで 1 つだけ試します。全部を一度に適用しようとすると、どのパターンが効果的だったのか判断できません。1 つずつ試して、効果を実感してから次のパターンに進みます。

設計の引き出しは、経験だけでは効率よく増えません。経験は偏り、失敗からの学びには時間がかかり、名前を知らないパターンは議論できない。本は、これらの限界を一気に突破する手段です。パターンカタログを 1 冊読むだけで、設計の選択肢が倍増します。