設計の引き出しは経験だけでは増えない

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

経験 10 年でも、設計の選択肢が 3 つしかないことがある

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

設計の引き出しは、知っている選択肢の数と、それぞれをどこで使い分けるかの判断で決まります。このうち数の方が、実務経験だけでは伸びにくいものです。1 つのプロジェクトで採用される設計は、そのプロジェクトが必要とした範囲に限られます。職場を変えても、増えるのはそこで採用されている設計の分だけで、増え方は経験した職場の数に比例する程度にとどまります。

一方、設計パターンのカタログ本は、著者が集めた選択肢を 1 冊に並べています。実務では 1 つずつしか出会えないものを、自分の職場が採用しなかった案まで含めて一度に見渡せます。他社の事例発表を聞く、他人のコードを読むといった道もありますが、体系立てて並んだ状態で、目の前の案件の都合と切り離して選択肢を眺められる媒体は、書籍がいちばん手に入れやすい形をしています。

経験だけでは不十分な 3 つの理由

1. 経験は偏る

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

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

2. 失敗から学ぶには時間がかかりすぎる

設計の失敗は、数ヶ月から数年後に顕在化します。「この設計は変更に弱い」と気づくのは、実際に変更が必要になったときです。1 つの設計の失敗が結果として見えるまでに 1〜2 年かかるとすると、失敗の型を 10 通り自分で踏むには、その繰り返しに何年もかけることになります。複数の失敗は並行して進むので単純な足し算にはなりませんが、それでも 1 人の在職年数で網羅できる量ではありません。

本は、著者が現場で踏んだ失敗と、その原因の見立てをまとめて渡してくれます。自分で踏む前に「この設計は何年後にどこが苦しくなるのか」を知れることが、経験では代えにくい部分です。

3. 名前を知らないパターンは議論できない

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

名前を知らなくても同じ設計はできますが、それをチームに伝える手間がまったく違います。「条件によって処理を切り替えるんですけど、if 文じゃなくて、えーと、クラスを分けて...」と身振りで説明するはめになる場面が、パターン名ひとつで済みます。名前がついていれば、後からコードを読む人も意図を辿れます。

設計の引き出しを増やす読書戦略

まずパターンカタログを 1 冊読む

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

次に設計原則の本を読む

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

実務で 1 つずつ試す

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

関連記事

• 設計・アーキテクチャ本ガイド - 設計力を上げる技術書の選び方
• 30 代エンジニアが読書で取り戻す「設計の言語化力」

まとめ

設計の引き出しは、経験だけでは効率よく増えません。経験は偏り、失敗からの学びには時間がかかり、名前を知らないパターンは議論できない。本は、このうち経験の偏りと時間の壁を最も安く埋められる手段です。パターンカタログを 1 冊読めば、次の設計判断のときに比較できる案が増えます。