設計の妥当性を判断する力のゴールは、「正しい設計を予測して当てること」ではなく、「間違えても傷が浅い構造にしておくこと」です。この記事では、技術選定をいつ・どうやって決めるのか、情報がない最初の段階でどう折り合いをつけるのかを、エンジニアが毎日触っているGitに例えて解説します。「AI時代は設計力が大事と聞くけど、何を鍛えればいいのか分からない」という方向けです。
これは「AI時代のエンジニアに必要な基礎スキル」シリーズの2本目です。前回の「コードの目利き」に続いて、今回は「設計の妥当性を判断する力」を掘り下げていきます。
まず、コードの目利きと設計判断は別モノ
同じ「判断する力」でも、コードの目利きと設計の妥当性はゴールの性質が全然違うんですよね。ここを混ぜると話がこんがらがります。
- コードの目利き：対象がミクロで、あとから直せる。バグには「正解」があるので、危ないコードは直せば終わり。
- 設計の妥当性：対象がマクロで、あとから直しにくい。そして厄介なのが、設計には「正解」がないことです。
DB選定も、フレームワーク選定も、全部トレードオフでしかありません。「PostgreSQLが唯一の正解」なんてものは存在しなくて、「この条件下ではPostgreSQLが妥当」があるだけ。だから、設計判断のゴールは「正解を選ぶこと」にはならないんです。
じゃあゴールはどこかというと、「あとで詰む設計を、詰む前に避けられること」かなと思います。コードは1行ずつ直せるけど、設計を間違えると「3ヶ月後に全部作り直し」になる。その未来の後悔を、選ぶ時点で減らすのがこのスキルです。
技術選定は「いつ」決めるのか
僕が最初に誤解していたのが、「サービスが決まった時点で、言語もサーバーもDBも全部いま決めるものだ」という思い込みでした。でもこれ、幻想だったなと。
サービスを作り始める時点で持っている情報って、実はめちゃくちゃ少ないんですよね。ユーザーが何人来るか、どこがボトルネックになるか、どの機能が伸びるか、全部わからない。その状態で全部を賭けると、大体外れます。
（有名な話だと、Amazon Prime Videoがマイクロサービスからモノリスに戻して大幅にコスト削減した、という事例もあります。プロでも規模の見積もりは外すんですよ）
判断は「可逆性 × 依存度」でタイミングが分かれる
じゃあどこで決めるか。見極めの軸は2つで、「変えにくいか」×「依存が大きいか」で整理できます。
変えにくい 変えやすい
┌──────────────┬──────────────┐
依存が │ 最優先で慎重に │ 早めでいいけど │
大きい │ 決める │ 気楽に │
│ 例:データ構造 │ 例:言語 │
├──────────────┼──────────────┤
依存が │ 慎重に、でも │ 後回しでOK │
小さい │ 分離しておく │ 動かしてから │
│ 例:認証基盤 │ 例:キャッシュ │
└──────────────┴──────────────┘具体的に、よく迷うところで言うとこんな感じです。
- 言語：実は規模ではあまり決まりません。自分が書けるエコシステムで9割決まる。早めに決めるけど、気楽に決めていい枠。
- サーバー・インフラ：変えやすい枠。最初は一番安く簡単な構成でいい。スケールは「実際に遅くなってから」考えても間に合うことが多いです。
- DB・データ構造：一番慎重に決める枠。データが入った後にテーブル設計を変えるのは、本当に地獄なので。
「サービスが決まったから全部決める」んじゃなくて、変えにくいものだけ将来を見て慎重に、変えやすいものは今の規模でシンプルに選んで後で育てる。これが見極めの基本かなと思います。
「変えにくいもの」の正体は依存
「変えにくいものってDBだけ？」と最初は思ったんですが、そうじゃないです。ただ、リストを暗記するよりなぜ変えにくいのかの共通原理をつかむ方が大事で、これが分かると初見の技術でも自分で判断できるようになります。
その原理はこれです。
自分の「外側」にある何かが、それに依存し始めると変えにくくなる
技術そのものが変えにくいんじゃなくて、依存が積み重なると変えにくくなる。つまり時間とともに変えにくくなっていくんですよね。
- DB・データ構造：蓄積されたデータがスキーマに依存する
- データの持ち方：金額をint/float、時刻をUTCか等。溜まったデータに焼き付く
- 認証・認可の設計：全機能のコードが権限モデル前提で書かれる
- 公開API：外部のクライアントが契約に依存する
- URL構造：検索エンジンと外部リンクが依存する（SEO）
DBが代表例なだけで、共通しているのは全部「あとから他人（データ・コード・外部）が寄りかかってくる」ということ。
これ、実は自分でも体験していて。前回の記事のスラッグを、公開してすぐ短いものに変えたんですね。あれがまさにこの原理で、記事が検索エンジンにインデックスされて外部リンクが貼られた「後」にURLを変えると、リンク切れやSEO評価のリセットが起きる。まだ誰も依存していない早いうちに変えたのは、無意識に正しい判断だったなと。
だから設計で何か決めるときは、こう自問するといいです。「これ、あとから何が寄りかかってくる？」
情報がないのに決める、という矛盾との折り合い
ここが設計の一番おもしろくて難しいところです。変えにくいものほど早く決めなきゃいけないのに、早い時ほど情報がない。 この矛盾、シニアでも完全には解けないんですよね。
でも、できる人がやっている折り合いのつけ方には、はっきりした発想の転換があります。
予測を当てることを諦めて、「間違えても傷が浅い」ようにする
初心者は「将来を正しく予測して、正しい設計を選ぶ」を目指しがちです。でも情報がない以上それはムリ。だから、情報を増やせないなら間違いのコストの方を下げる。これが折り合いの本体だと思います。
これ、エンジニアはもうGitで毎日やってる
この「予測を当てるのを諦めて、間違いを安くする」って、実はGitで無意識にやっていることなんですよね。
- いきなりmainで作業しない → ブランチを切る（間違えても本線が死なない＝可逆にする）
- こまめにコミットする（戻れる点を作っておく）
- ヤバければ
revert／resetで戻す
これ全部、「一発で正解を書く」のを諦めて、「間違えても戻せる状態」を先に作っているわけです。設計は、この発想をシステム全体にスケールさせたもの。逆に「変えにくいもの」は、force pushで履歴を書き換えるみたいなやつ。戻せないから、そこだけは慎重になる。データ構造がまさにこれです。
「良いgit運用ができる人は、実は設計の素質がもうある」って、僕はけっこう本気で思っています。
具体的な4つの手
その「間違いを安くする」を、実際の技術選定に落とすと4つになります。
- 分離して局所化する：DBアクセスをビジネスロジックに直書きで散らさず、ORMやリポジトリの裏に隠す。最初SQLiteでも、後でPostgreSQLに移すときそこだけ直せば済む。ブランチを切っておくのと同じ発想です。
- 退屈な技術を選ぶ：出たばかりのイケてるものより、実績のある枯れた技術。詰みポイントが世界中で語り尽くされていて、未知の地雷が少ない。
- リスクの非対称で選ぶ：「どっちが正しいか」ではなく「どっちを間違えたら痛いか」で選ぶ。例えば主キーをserialにするかUUIDにするか迷ったら、外部公開やマルチテナントの芽が少しでもあるならUUID寄り。将来は読めなくても、間違えたときのコストの大小は今わかります。
- 決定を遅らせる：認証基盤・キャッシュ・キューなど、要るまで入れない（YAGNI）。今いらない依存を先に抱えないことです。
結局、お手本はない。でも型はある
ここまで読んで、「具体的なテンプレ（この通りやれば正解、みたいなお手本）は結局なかったな」と感じた方もいると思います。実はそれ、この記事の一番大事なポイントです。
お手本が「なかった」んじゃなくて、「存在しえない」です。
前回のコードの目利きは、チェックリストのような「答えのお手本」に近いものがありました。バグには正解があるから、正解表が作れる。でも設計には正解がない以上、答えのテンプレは原理的に作れません。
ただ、お手本（答え）はないけど、型（考え方のフレーム）はある。今日組み立てたのがこれです。
- 判断の軸：可逆性 × 依存度
- 問い：「これ、あとから何が寄りかかってくる？」
- 折り合い：予測を当てるのを諦めて、間違いを安くする
- 4つの手：分離・退屈・非対称・遅らせる
答えのテンプレじゃなくて、問いのテンプレなんですよね。「どう考えるか」は型化できるけど、「何が正解か」は型化できない。
そして、ここがAI時代の話につながります。お手本がある作業は、AIが一番得意なやつです。チェックリストならAIが完璧に回す。でも、文脈ごとに答えが変わる判断は、テンプレ化できないからこそ人間に残る。前回の「AIが書いたコードを人間が最終確認する」と同じ構造で、設計は「正解のない選択を、文脈を見て決める」という、人間に残る仕事なんです。
設計はテンプレで解けない。だからこそ、AI時代にも価値がある。 そう考えると、設計判断って予言じゃなくてリスク管理なんだな、と腑に落ちるかなと思います。
まとめ
- 設計には正解がなく、あるのはトレードオフだけ。ゴールは「あとで詰む設計を、詰む前に避けること」
- 技術選定は一括で決めるものではなく、「可逆性 × 依存度」でタイミングが分かれる
- 変えにくさの正体は依存。「これ、あとから何が寄りかかってくる？」と自問する
- 情報がない中では「予測を当てる」を諦めて「間違いを安くする」。分離・退屈・非対称・遅らせる、の4つの手
- お手本（答え）はないが、型（問い方）はある。テンプレで解けないからこそ人間に残る
だからこそ、地道にやっていかないといかけない部分かつAIには任せれない部分ではあるのかもしれません。
コメント