ブログ記事
ソフトウェア設計の歩き方 — 地形と、遠回りせず判断力を身につける5冊
「設計の本、何から読めばいいですか？」——この問いに、地図で答えます。
AI がコードを書ける時代になりました。だからこそ効くのは、消えない「設計の基礎」です。 どのライブラリが流行るかは変わっても、読みやすさ・依存の向き・境界の引き方という土台は変わりません。 この記事は、ソフトウェア設計という分野の「地形」を俯瞰し、遠回りせず設計判断力を身につけられる**5冊の順路（最短ルート）**を、 なぜその順なのかという根拠付きで示します。
1. この分野の地形（どんな土地か）
ソフトウェア設計の地形は、海岸の低地から内陸の高山へと登っていく一つの大陸として描けます。
- 海岸の低地：コード品質。変数名・関数・責務といったミクロな単位を扱う、すべての登り道の出発点。
- 中腹の丘陵：テスト・リファクタリング。コードを壊さず育てるための習慣。
- 山脈：アーキテクチャとドメイン駆動設計。依存の向きと境界を設計する高地。
- 奥地の高原：分散・データ・運用。単一サーバーを越えた大規模・運用の世界。
ここで押さえたいのは、ミクロ（コード）からマクロ（組織・運用）まで、関心事のスケールが連続して繋がっていること。 いきなり山脈から登ろうとすると道に迷う。低地から順に標高を上げるのが近道です。
2. 遠回りせず設計判断力を身につける5冊（最短で土地勘をつかむ）
この大陸を一本道で貫く「幹」が次の5冊です。各ステップには「なぜ次にこれを読むのか」の理由があります。
flowchart LR
A["① リーダブルコード\n可読性の基礎\n（名前・関数・コメント）"] --> B["② Clean Code\n品質原則の体系化\n（関数・クラス単位）"]
B --> C["③ Clean Architecture\n依存の向き・境界設計\n（システム全体）"]
C --> D["④ ドメイン駆動設計をはじめよう\n境界の引き方の地図\n（戦略・戦術）"]
D --> E["⑤ エヴァンスDDD\n概念の原典・厳密な定義\n（応用の土台）"]
style A fill:#e8f4fd,stroke:#4a9eda
style B fill:#e8f8e8,stroke:#4caf50
style C fill:#e8f8e8,stroke:#4caf50
style D fill:#fff8e1,stroke:#f5a623
style E fill:#f3e5f5,stroke:#9c27b0
① リーダブルコード（可読性の基礎）
命名・関数分割・コメントといった、足元の可読性。すべての出発点。
なぜ次に Clean Code か：命名や関数分割といった可読性の基礎を押さえたら、それらを「なぜそうするのか」の原則へ束ねる段階に進みます。Clean Code は個別テクニックを職業倫理と設計原則の体系へと接続します。 根拠: TwoHardThings（命名の難しさ） - martinfowler.com
② Clean Code（コード品質の原則）
個別テクニックを「原則」として束ねる。関数・クラス単位の品質観を獲得する。
なぜ次に Clean Architecture か：関数やクラス単位の品質が身についたら、次はシステム全体の依存の向きと境界を設計する視点へ広げます。クリーンアーキテクチャは詳細を外側へ追いやり、ビジネスルールを中心に据える原則を与えます。 根拠: The Clean Architecture - Robert C. Martin
③ Clean Architecture（依存の向きと境界）
システム全体で「依存をどちらに向けるか」を設計する。ビジネスルールを中心に据える。
なぜ次に ドメイン駆動設計入門 か：依存の向きを制御できるようになると、次の関心は「境界をどこに引くか」へ移ります。ドメイン駆動設計はビジネスの言葉から境界づけられたコンテキストを導き、アーキテクチャの分割に意味を与えます。 根拠: BoundedContext - martinfowler.com
④ ドメイン駆動設計をはじめよう（境界の引き方の地図）
戦略・戦術の地図を入門書で獲得する。境界づけられたコンテキストという考え方を掴む。
なぜ次に エヴァンス DDD（原典）か：入門書で戦略・戦術の地図を得たら、概念の出どころと厳密な定義を原典で確かめます。エヴァンスの DDD はユビキタス言語やモデル駆動設計の根拠を与え、応用の判断を支える土台になります。 根拠: DomainDrivenDesign - martinfowler.com
⑤ エリック・エヴァンスのドメイン駆動設計（原典）
概念の出どころと厳密な定義。応用の判断を支える土台。ここが幹の頂上。
3. なぜ「順番」に意味があるのか
上のリンクは飾りではありません。各ステップの「なぜ次にこれか」は、 Martin Fowler や Robert C. Martin の一次情報に接地しています。 順序そのものに根拠があること——これが、断片的な「おすすめ本リスト」との決定的な違いです。
設計は「正解の暗記」ではなく「判断の土台づくり」です。 だからこそ、低地（可読性）→ 品質の原則 → 依存設計 → 境界設計、という標高順に登ることで、 上の階層の議論が「地に足のついた」ものになります。
4. 自分の現在地から登り口を選ぶ
幹は海岸の低地から始まりますが、全員が①から登る必要はありません。いま設計のどのスケールで詰まっているかで、入るべき登り口が変わります。
- コードレビューで可読性を指摘される段階なら、素直に①リーダブルコードから。足元を固めるほど上の階層が安定します。
- 関数・クラスの品質は書けるが、システム全体の構造で迷うなら、①②を飛ばして③クリーンアーキテクチャから入ってかまいません。
- 依存の向きは設計できるが、境界をどこで切るかが定まらないなら、④⑤のドメイン駆動設計が登り口です。
大事なのは、標高（スケール）が連続している以上、飛ばした低地はいつでも戻れるという点です。上で概念が抽象的に感じたら、一つ下の階層へ降りるのが最短の回復ルートになります。
5. よくある迷い方
この地形で道に迷うパターンは、だいたい三つに分かれます。
- いきなり山脈から登る：土台となる可読性やコード品質を飛ばしてアーキテクチャやDDDに挑むと、概念だけが宙に浮きます。抽象論が腹落ちしないときは、低地に土台が足りていないサインです。
- 順序なく本を積む：話題の設計書を手当たり次第に読んでも、判断はつながりません。この幹の価値は「なぜ次にこれか」という順序そのものに根拠があることにあります。
- 幹だけ登って枝道を無視する：テストとリファクタリングは幹の隣を並走する習慣です。幹を登りながら枝道を行き来しないと、学んだ設計を安全に実装へ移せません。
6. 地図で実際に辿る
この幹は一本道の一部にすぎません。リファクタリング・テスト・分散システムへの枝道、 各エッジの出典、難易度の色分けは、DevBookPath のソフトウェア設計マップで実際に辿れます。
「何を・なぜ・どの順で読むか」を、出典付きで確認できます。
筆者の体験から
テックリードとしてレビューする側に回って数年経った頃、若手に「設計の本は何から読めばいいですか」と聞かれるたびに、答えがその場の気分で変わっていることに気づきました。筆者自身、順序を考えずにいきなりドメイン駆動設計の原典へ挑み、途中で挫折した経験があります。当時は理解力の問題だと思い込んでいましたが、振り返れば順番を間違えていただけでした。
この順路で考えるようになってからは、本を渡す前に「いまどのスケールで詰まっているか」を先に聞き、まとめて渡すのをやめました。1冊読み終えて自分の言葉で話せるようになってから次を渡すようにすると、積読が明らかに減りました。「アーキテクチャレビューの指摘が増えた」と相談してきた若手に地形の比喩で聞いてみると、依存の向きは説明できても業務ロジックの境界で悩んでいると分かり、①②を飛ばして③④を渡したところ、1冊目を終えた頃には境界の切り方を自分の言葉にできていました。
とはいえ「抽象的に感じたら一段下に降りればいい」という考え方は、締切のある実務ではそう気楽に戻れないことも多く、理想論寄りだと感じる部分もあります。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有