インフラと設計は別物ではない: どちらも「曖昧さを減らす技術」である

最初に立ち上がる違和感

「インフラは苦手だから、誰かに任せる」「設計は難しそうだから、まずは動くものを作る」。この2つは、現場ではとても自然な判断です。けれど、よく考えると不思議です。インフラを避けることと設計を後回しにすることは、別々の話に見えて、実は同じ問題に向き合っていません。

それは、ソフトウェアの中にある曖昧さをどう扱うかという問題です。環境が複雑で、仕様が揺れ、時間が足りず、責任範囲がぼやけるとき、人はつい「見えない部分」を切り離したくなります。インフラはインフラ担当へ、設計は後で考える。だがその瞬間、システム全体を支えるはずの境界が、逆にもっと曖昧になる。

ここに、実は大きな落とし穴があります。**インフラも設計も、どちらも本質的には“曖昧さを減らすための技術”**なのです。片方だけを理解しても、もう片方を軽視すると、システムは簡単に崩れます。

---

「動く」だけでは足りない理由

速く作ることは悪くありません。むしろ多くの現場では、スピードが正義です。小規模受託でも社内開発でも、最初はまずリリースしなければ始まらない。ところが、スピードが評価される環境ほど、コードはしばしば「その場の都合」を吸い込みます。後で直すつもりの仮置きが積み重なり、どこまでが正しい仕様で、どこからが暫定なのか分からなくなる。

ここで起きているのは、単なる技術負債ではありません。意味の負債です。何がどの責務を持ち、どの変更がどこに影響するのか、システムの意味論がだんだん薄れていく。コードは動くのに、読めば読むほど意図が見えない。これが設計不全の本質です。

一方で、インフラを避ける態度も同じ構造を持っています。環境構築や権限設定、デプロイの流れ、ネットワークの境界を理解しないまま開発を進めると、アプリケーションの責務と実行環境の責務が混ざります。すると、エラーが起きても原因がアプリなのか設定なのか分からない。どこで何が決まるのかを知らない状態は、設計がない状態と同じくらい危ういのです。

「動くものを作る」ことと、「理解できるものを作る」ことは、似ているようで違う。 前者だけを追うと、システムは動作するが、修正不能になる。

---

インフラとDDDをつなぐ共通の問い

インフラが苦手な人にとって、CDKやAmplifyのような仕組みは魅力的です。面倒な設定を抽象化し、少ないコードで環境を立ち上げられるからです。これは単なる便利機能ではなく、インフラを「手順」ではなく「構造」として扱う試みです。

同じことがドメイン駆動設計にも起きています。DDDは難解な理論体系に見えがちですが、実際には「現実の業務をどう切り分け、どう名付け、どう境界を引くか」を問う実践です。つまり、DDDもまた曖昧さを減らす技術です。何が売上で、何が請求で、何が注文で、何が配送なのか。それぞれの言葉を厳密にすることで、変更の影響範囲を局所化する。

ここで面白いのは、インフラと設計がまったく別の階層に見えながら、実際には同じ問いに答えていることです。

その問いとは何か。

「このシステムでは、何がどこまでの責任を持つのか」

インフラは、その責任を実行環境のレベルで問います。DDDは、責任をビジネス概念のレベルで問います。片方はAWSやVPCやデプロイの境界、もう片方は集約やエンティティやユビキタス言語の境界。表面は違っても、どちらも境界設計なのです。

---

境界設計というひとつのレンズ

ここで、両者をつなぐ有効な見方があります。それは、ソフトウェア開発を境界設計の連続体として捉えることです。

たとえば、最初にアプリを作るとき、開発者は「画面」「API」「DB」を分けて考えます。これは見た目には単純なレイヤー構成ですが、実は重要なのはレイヤーそのものではなく、どの情報がどの境界を越えていいかです。ユーザー入力はどこで検証されるのか。ビジネスルールはどこに置くのか。環境変数はどこで解釈されるのか。これらを曖昧にすると、コードはすぐに肥大化します。

例えば、ECサイトで「在庫がない商品は購入できない」というルールを考えます。これを画面側で止めるだけでは不十分です。API側でも確認し、最終的にはドメイン側でも保証しなければならない。なぜなら、画面は壊れるかもしれないし、別のクライアントがAPIを叩くかもしれないからです。ルールは境界を越えるたびに薄まるので、最も守りたい場所に近いところで再定義する必要があります。

インフラでも同じです。たとえば、ある機能をLambdaで動かすのか、コンテナで動かすのか、あるいは別のサービスに分けるのかは、単なる実装選択ではありません。そこには、実行時間、スケーリング、権限、障害の切り分けという境界が含まれている。インフラを理解しないまま選ぶと、見えない責務がアプリ側に流れ込みます。

つまり、設計とは境界を引くことではなく、境界を越える情報の質を制御することです。インフラもDDDも、その違う側面を見ているにすぎません。

---

便利な抽象化が、理解を奪うとき

現代の開発は、抽象化に満ちています。テンプレート、フレームワーク、マネージドサービス、生成AI。これらは確かに強力です。初心者がインフラの複雑さに圧倒されずに済むのは、抽象化があるからです。DDDにしても、用語とパターンがあるから、複雑な業務を整理しやすい。

しかし抽象化には副作用があります。便利さは、理解の必要性を減らすが、責任の必要性は減らさないのです。むしろ、抽象化が深いほど、どこで何が起きているのか分からないまま使ってしまう危険が増します。

たとえば、CDKやAmplifyを使えば、インフラの記述量は劇的に減ります。だが、「どのリソースが作られ、どの権限が必要で、失敗時にどこまで巻き戻るのか」を理解していないと、障害時に対応できません。便利な道具は、能力を拡張する一方で、理解しないまま使うとブラックボックスを増やします。

DDDも同じです。流行っているから導入する、という態度ではうまくいかない。用語を増やしても、現実の業務境界が整理されていなければ、単に難しい言葉が増えるだけです。ドメインモデルは飾りではなく、意思決定の地図です。地図を持たずに進むと、すぐに「とりあえず動くが、何が正しいか分からない」状態になります。

抽象化の価値は、難しさを消すことではない。 難しさの場所を見えるようにすることにある。

---

実務で本当に必要なのは「全部分かること」ではない

ここで誤解してはいけないのは、インフラもDDDも、すべてを完璧に理解しろという話ではないことです。現実には時間がありません。小さな会社ならなおさら、フルスタックに全領域を深く掘るのは難しい。

だが、必要なのは万能性ではありません。必要なのは、自分が今どの曖昧さを引き受けているかを言語化できることです。

たとえば、次のように考えると整理しやすいです。

1. 業務の曖昧さ: 仕様がまだ固まっていない。ここはDDD的な問いが必要。
2. 実行の曖昧さ: どこで動き、どう失敗し、どう復旧するかが見えていない。ここはインフラの問いが必要。
3. 責務の曖昧さ: どの層が何を決めるのか分からない。ここは両者をつなぐ設計の問いが必要。

この3つを分けて考えるだけで、問題の輪郭がかなりはっきりします。たとえば「画面からバリデーションしているのに不具合が出る」のは、業務の曖昧さではなく責務の曖昧さかもしれない。「デプロイは通るのに本番だけ壊れる」のは、実行の曖昧さかもしれない。問題の種類を取り違えると、対処もずれます。

つまり、成長とは「全部を知ること」ではなく、曖昧さの種類を見分ける解像度を上げることです。

---

Key Takeaways

• インフラと設計は別々の話ではない。どちらも、システムの曖昧さを減らし、責任の境界を明確にするための技術である。
• 動くことと理解できることは違う。短期的なスピードだけを追うと、後で修正不能な「意味の負債」が溜まる。
• 抽象化は理解の代用品ではない。便利なツールやフレームワークを使うほど、何が隠れているかを把握する必要がある。
• 設計の本質は境界設計。どの情報がどこを越えてよいかを決めることが、アプリでもインフラでも重要になる。
• まずは曖昧さの種類を分ける。業務、実行、責務の3つに分けて考えると、次に何を学ぶべきかが見えやすい。

---

では、何を学べばいいのか

ここまで読むと、「結局、インフラもDDDも両方やれということか」と感じるかもしれません。半分正しく、半分違います。正しいのは、両方を同じ視点で捉えるべきだという点です。違うのは、いきなり広く学ぶ必要はないことです。

おすすめは、ひとつの小さなシステムを題材にして、次の3点を書き出すことです。

• 何が業務ルールか
• 何が実行環境の都合か
• どこに責務の境界があるか

この作業は、コードを書く前でも、既存コードを読むときでも効きます。例えば「ログイン後にプロフィールを更新するだけ」の機能でも、認証、認可、入力検証、永続化、通知、デプロイ環境の権限が絡みます。表面的には小さな機能でも、曖昧さの層を剥がすと、設計の良し悪しが露わになる。

そして重要なのは、曖昧さをゼロにすることではない、という点です。現実には曖昧さは残ります。ただし、残してよい曖昧さと、絶対に固定すべき曖昧さがある。DDDは前者を整理し、インフラは後者を支える。そう考えると、両者は競合するのではなく、一つのシステムを異なる高さから支える補完関係だと分かります。

---

終わりに: ソフトウェアは機能の集合ではなく、責任の配置である

ソフトウェア開発で本当に難しいのは、コードを書くことではありません。何をどこまで引き受けるかを決めることです。インフラに弱い人がインフラを学ぶ理由も、設計に危機感を覚える人がDDDに触れる理由も、結局は同じ場所にあります。見えない責任を、見える責任に変えたいからです。

だから、インフラとDDDは別々に学ぶべき専門分野というより、同じ問いに対する異なる回答だと捉えたほうがいい。ひとつは「どこで動くか」を、もうひとつは「何が意味を持つか」を整理する。そしてその両方が揃って初めて、システムは単に動くだけではなく、変えられるものになります。

本当に強いエンジニアは、複雑さを恐れない人ではありません。複雑さをそのまま放置せず、どこに置くべきかを判断できる人です。インフラを学ぶことも、DDDを学ぶことも、その判断力を鍛えるための違う入口にすぎません。