はじめに
これは、私が 「設計」 という言葉にずっと惑わされてきたエンジニア人生に終止符を打つために書いた記事です。
基本的には自分のためにまとめたものですが、ついでに皆さんのお役にも立てたら嬉しいです
そもそもなんで急に設計を勉強しようと思ったのか。きっかけはAIです。
最近、AIがコードを書いてくれる量が尋常じゃないんですよね。ある日、AIが書いた 5000行くらいのバカでかいPR を前にして、私は固まりました。
全部読む？ 夜が明けるが？
かといって、人間が一行も確認せずにマージするのはさすがに怖い。
じゃあ、どこを読めばいいの？ AIに確認させるべきポイントってどこ？
（そもそもなんで1つのPRに5000行も書かせてるの？という声も聞こえてきそうですが、、笑）
ここで気づいたわけです。「コードを読む力」とは別に、「コードの良し悪しを判断する力」が要るぞ、と。そしてその判断力って、たぶん世間で言う「設計」ってやつなんじゃないか…？
というわけで、AI時代に人間が何を学べばいいのかを探る旅として、「設計」と向き合うことにしました。長くなりそうなので何記事かに分けます。この記事はその1本目、設計の全体像をつかむ「地図編」 です。
設計って？
まずは「設計」の意味を調べてみましょう。
「設計」とは、特定の目的を達成するためのシステムやモノ（建築物、工業製品、情報システムなど）について、機能や構造などを検討し、実現するための具体的な計画を立てて図面や仕様書などに落とし込む知的作業のことです。
うん、よくわからんすね
もう少し噛み砕きましょう。要するに、
特定の目的を達成するために、どんな機能や構造にするかを考えて、具体的な計画に落とす。
まだ漢字が多くて脳が拒否反応起こしちゃうな
もっとざっくり言うと、
目的を決めて、それを叶えるためにあれこれ考えて、計画にまとめる
ってことですかね。
なるほど、なんだ簡単じゃん。目的に向かって考えて計画立てればいいんでしょ？
…ん、あれ。でも私が「設計って難しい」って悩んでたの、これで説明つくか？ こんなシンプルな話なら、なんで私いつも「設計、設計」って唸ってるんだ？
ん、待てよ。さっきサラッと流した 「あれこれ考える」 のところ、これが一番難しいんじゃね？！
そう。設計っていうのは、目的があって、それを達成するためにあれこれ考えること。そして厄介なのは、その 「考える」の中身 なわけです。
なので、この記事ではまず「設計で何をどう考えるのか」、その地図を手に入れることをゴールにします。
設計をする意味とは？
その「"考える"の中身」の話に入る前に、そもそもなんで設計するの？って話を一瞬だけ。
こんな場面を想像してください。
あなたは料理人。注文された一皿を、10分以内に仕上げて出さなきゃいけません。
ここで何も準備せずに始めると、どうなるか。
- まず「どこで作ろう」と調理場所を探すところからスタート
- 次に、まな板と包丁がどこにあるか探し回り
- 必要な具材があちこちの冷蔵庫に散らばっているので、かき集め……
そうこうしているうちに、あっという間に10分は過ぎてしまいます。
逆に、作る前に「使う場所・道具・具材」を段取りしておけば、迷わず手を動かせて時間内に出せる。
これが設計です。設計とは、目的の達成確率を上げる行為。 だからやるんですね。
「いや、料理でそんな段取りミスしないでしょ。大袈裟すぎ」と思うかもしれません。料理なら、まあそうそう起きないでしょう。でも 開発だと、これが平気で起こる んですよ。調理場所を探すところから始めるみたいなこと、コードの世界では日常茶飯事です。
開発における設計とは？
じゃあ、開発で「段取り」するって具体的に何なのか。まずは 「開発する目的」 をハッキリさせることから始まります。で、これが地味に重要なんですが、開発の目的には階層があるんですよ。
たとえば「口コミアプリを作る」という開発、目的はどれでしょう？
- ユーザーが入力したらDBに値が保存されること？
- ユーザーが口コミを見ながら店を探せること？
- そのサービスで稼いでいい暮らしをすること？
全部目的です。ただし粒度が全然違う。そして、それぞれの粒度で必要な設計も変わります。
| 目的の粒度 | 考えること（設計の中身） |
|---|---|
| DBに値を保存する | 変な入力が来たらどうする？ 保存の流れは？ |
| 口コミを見て店を探せる | 口コミをどう集めてどう見せる？ 必要な表示速度は？ |
| サービスで稼ぐ | そもそも何に需要があって、どう価値を届ける？ |
…はい。
開発の設計って言っても、色々あんなー。
なんか、私がずっと「設計」って言葉でごちゃごちゃしてた原因、ここに大きくある気がする。「設計」の一言が、こんなに違うレイヤーの話を全部飲み込んでるんだから、そりゃ混乱するわ。
で、何？
頭を抱えてたら、隣の席の先輩が画面を覗き込んできました。
：先輩〜、設計って言葉、意味が広すぎて何から考えればいいかわからんのですよ。DB設計、インフラ設計、デザインパターン、情報設計、DDD、クリーンアーキテクチャ…どれも"設計"の話なんだけど、頭の中にバラバラ並んでるだけで、互いにどう関係してるのか全然わからん。もう全部ごちゃごちゃで
：あー、それな。お前が混乱してんの、頭が悪いからじゃないで。
なるほど。たしかに今まで本を読んでも、知識がバラバラに散らばるだけだった気がする…。
というわけで、先輩から地図を2枚もらいました。「縦の地図（対象のデカさ）」 と 「横の地図（用語の種類）」 です。
地図その1：縦の地図 ── どのデカさの話？
まず、設計は 「何の単位で考えるか」 によってレベルが分かれます。下にいくほど細かく、上にいくほどデカい話。
| レベル | 単位 | 主に考えること（代表例） |
|---|---|---|
| Lv1 | コード（関数・クラス） | 命名、責務分け、読みやすさ |
| Lv2 | コンポーネント（UI部品、サービスクラス） | 再利用性、テストのしやすさ |
| Lv3 | モジュール（機能のまとまり） | 凝集度、依存の向き、責務 |
| Lv4 | アプリ（1サービス全体） | ドメインモデル、フォルダ構成 |
| Lv5 | システム（複数サービスの連携） | API設計、データの流れ、結合度、非機能要件（拡張性・可用性など） |
「コード → コンポーネント → モジュール → システム」と、扱う範囲がだんだん大きくなっていく感じです。5段の区切り方はこの記事用のざっくりした整理なので、「だいたいこういうグラデーションがある」くらいで受け取ってください。
以降、上の表のとおり Lv1（コード）〜 Lv5（システム） と呼びます。
地図その2：横の地図 ── そもそも何の"種類"の話？
さて、本命です。DDD、クリーンアーキテクチャ、SOLID、デザインパターン…。この 「設計っぽい用語たち」 が一番の混乱の元じゃないですか？ 私はそうでした。
ここで、私が一番モヤモヤしてたやつを先輩にぶつけてみます。
なるほど。私はずっと、「中身をどう設計するか」と「全体の骨組みをどう組むか」という、踏み込む対象が違う2つを同じ土俵で比べようとして、勝手に混乱してたのか
つまりポイントは 「その用語は、何に踏み込んでる話なのか」。先輩いわく、設計用語はこの 「踏み込む対象」 で何種類かに分けられるそうです。
[ おおまかな方針・世界観の話 ]
(1) パラダイム … コードの根本的な世界観
(2) 方法論・思想 … どう作るかの哲学・進め方
(3) アーキテクチャパターン … コード全体の配置・骨組み
(4) 設計原則 … 守るべきルール
(5) デザインパターン … 目の前の実装テクニック
[ 目の前の具体的なコードの話 ]
上から下へ、"おおまかな方針"から"目の前のコード"へと、だんだん具体に降りていきます。でも大事なのは並び順そのものより、各層が"違う問い"に答えてること。「世界観の話」と「骨組みの話」と「実装テクの話」は、そもそも別の問いなんですね。
（この5分類もこの記事用のざっくりした整理。「こう眺めると見通しがいい」くらいで受け取ってください）
それぞれに、聞いたことある用語を当てはめるとこう。
| 層 | これは何の話か | 代表的な用語 |
|---|---|---|
| (1) パラダイム | コードの世界観 | オブジェクト指向、関数型、手続き型 |
| (2) 方法論・思想 | 作り方の哲学 | DDD、TDD など |
| (3) アーキテクチャパターン | コードの配置 | クリーンアーキテクチャ、ヘキサゴナル、MVC、マイクロサービス |
| (4) 設計原則 | 守るべきルール | SOLID、DRY、KISS、YAGNI、凝集度・結合度 |
| (5) デザインパターン | 実装の道具箱 | Singleton、Factory、Repository… |
DDD（2）とクリーンアーキテクチャ（3）、ほら、ちゃんと別の種類のところにいますね。道理で「どっち？」が成立しないわけだ。
用語同士の「関係」を見抜く
種類が分かると、今まで謎だったモヤモヤが次々に解けます。クイズ形式でいきましょう
Q1. クリーンアーキテクチャとヘキサゴナルアーキテクチャ、どっち使う？
→ これは正しい問い。同じ(3)の仲間の別の選択肢なので、"どっち"で合ってる。ご飯か麺か、みたいな話。
Q2. SOLIDってクリーンアーキテクチャの一部？
→ 惜しい。SOLID（4）はもっと汎用的な原則で、クリーンアーキテクチャ（3）がそれを土台として使ってる関係。家でいうと、SOLIDは"丈夫な構造の基本原則（荷重の支え方・力の逃がし方）"、クリーンアーキテクチャはその原則に沿って組んだ特定の骨組み、みたいな感じ。
Q3. DDDとクリーンアーキテクチャ、どっち？
→ ブブー
さっきの「間取りの考え方」と「骨組みの組み方」。踏み込む対象が違うので、並行して使える。
つまり、用語同士の関係はこの3種類。
- 上下：片方がもう片方の土台になってる（SOLID ← クリーン）
- 並列：同じ仲間で、入れ替えできる候補同士（クリーン vs ヘキサゴナル）
- 直交：扱う対象が別々で、干渉せず併用できる（DDD と クリーン）
新しい用語に出会ったとき、「これは(1)〜(5)のどの種類？（何に踏み込んでる話？）」「既知の用語とは "上下／並列／直交" のどれ？」を考える。これだけで、知識が地図の上に整理されていきます。
まとめ：地図を手に入れた
長くなったので一回まとめます。今回わかったこと。
- 設計＝目的の達成確率を上げるために「あれこれ考える」こと。難しいのは、その「考える中身」
- 「設計」という言葉は広すぎる。だから 2枚の地図 で整理する
- 縦の地図：設計には「コード〜システム」という**対象のデカさ（スコープ）**のレベルがある（この記事ではLv1〜Lv5と呼ぶ）
- 横の地図：設計用語は「何に踏み込んでる話か」で (1)パラダイム 〜 (5)デザインパターン に種類分けでき、用語同士は「上下／並列／直交」の関係を持つ
- DDDもクリーンアーキテクチャもSOLIDも、踏み込む対象（種類）が違うだけ。喧嘩してない
地図ができたので、ようやくスタート地点に立てた感じです。今まで読んだ本や記事の知識が、頭の中の地図に少しずつ置かれていく感覚、これがたぶん「解像度が上がる」ってことなんだと思います。
で、次回
地図を眺めてたら、また新しい不安が湧いてきました。
次回はその 「設計の大原則」 を掘っていきます。