UX / UI のデザインに強いWebシステムの開発と、BtoB Webマーケを支援するWeb制作を提供するN’s Creates (エヌズクリエイツ) 株式会社の西山です。

「クリーンアーキテクチャ」という言葉を聞いたとき、多くの開発者は特定の技術やフレームワークを思い浮かべるかもしれません。しかし、名著として名高い『ちょうぜつソフトウェア設計入門』が示すように、その本質は技術の応用ではなく、ソフトウェア開発が抱える、より根本的な問題に光を当てる考え方そのものです。

この記事では、同書の第一章を基に、私たちがなぜ「綺麗な設計」を求めるのか、そしてその「綺麗」とは一体何を指すのかについて、その核心に迫ります。

アーキテクチャは誰のためにあるのか？

そもそも、優れたアーキテクチャはプログラムの動作に直接貢献するわけではありません。アーキテクチャを綺麗にしたからといって、アプリケーションの性能が向上したり、機能が増えたり、バグが消えたりすることは期待できません。

では、一体何の役に立つのでしょうか？答えはシンプルです。それは「ソフトウェア開発のパフォーマンスを向上させるため」です。つまり、アーキテクチャはユーザーのためではなく、未来の開発者（未来の自分自身を含む）のために存在するのです。後から機能を追加・修正する際に、既存のコードに悪影響を与えることなく、素早く、安全に変更を加えられること。これこそが優れたアーキテクチャがもたらす最大の価値です。

「汚い設計」が生産性を奪う本当の理由

「汚いコード」や「汚い設計」がなぜ問題なのでしょうか。それは、コードが複雑であること以上に、変更による影響範囲が不明瞭になるという問題を引き起こすからです。

汚い設計には、主に以下のような特徴があります。

• まとまりが悪い：一つの修正のために、あちこちのファイルに手を入れる必要がある。
• 意味が混ざっている：一つのモジュールに、関係のない複数の関心事が混在しており、少し触っただけで意図しない部分が壊れやすい。

コードに少しでも変更が加わると、その変更が他にどんな影響を及ぼすかを確認する必要が生まれます。この「影響があるかもしれない」という可能性が、開発者の思考負荷を爆発的に高めるのです。本来考えなくてもいいはずのことまで配慮が必要になり、結果として開発全体の生産性が著しく低下します。

クリーンな設計の鍵：「依存」をコントロールする

クリーンアーキテクチャが目指す「綺麗さ」とは、他の構造部分に予期せぬ影響が及ぶ可能性を最小化した設計です。そのために最も重要視するのが「依存」の考え方です。

凝集度と結合度

良い設計の基本は「高凝集・疎結合」です。

• 凝集度：関連性の高いコードが、一つのモジュールにまとまっている度合い。凝集度が高いと、変更箇所がそのモジュール内に限定されやすくなります。
• 結合度：モジュール同士の結びつきの強さ。結合が疎（そ）であるほど、一つのモジュールの変更が他のモジュールに影響しにくくなります。

最も重要な「依存の向き」と「安定度」

システムを構築する上で、モジュール間の依存関係をゼロにすることは不可能です。そこで重要になるのが、依存の「向き」です。

モジュールAがBを利用するとき、「AはBに依存している」と言えます。このとき、BはAが存在しなくても成立します。つまり、依存される側は、する側よりも変更の影響を受けにくい、安定した存在であるべきです。

ここから、クリーンアーキテクチャのシンプルな指針が生まれます。
「頻繁に変わるもの（不安定なもの）は、頻繁に変わらないもの（安定なもの）に依存すべきである」

では、何が「安定」しているのでしょうか。それは、アプリケーションが「そもそも何をするためのものか」という本質です。UIのデザインや使用するデータベースの種類は変わりやすいですが、アプリケーションの本質的な目的は簡単には変わりません。この「安定度」を見極め、依存の方向を制御することが、クリーンな設計の核心です。

クリーンアーキテクチャの4層構造

上記の原則を実践するための一つの具体的なパターンとして、クリーンアーキテクチャは4つの層を提案します。重要なのは、円の内側ほど安定しており、依存関係は常に外側から内側へ向かうというルールです。

第1層：ドメインモデル（The Essence）

アプリケーションの最も本質的な部分。ビジネスのルールやデータの構造など、ユーザーが何をしたいかに関わらず「事実」として存在するロジックです。この層は、プログラミング言語の標準ライブラリ以外、何にも依存しません。フレームワークやDBにも依存しない、最も安定した層です。

第2層：ユースケース（Use Cases）

ユーザーが「何をしたいか」を表現する、アプリケーション固有のロジックです。例えば「商品を注文する」「記事を投稿する」といった操作がこれにあたります。この層は、内側のドメインモデルにのみ依存します。

第3層：インターフェースアダプター（Interface Adapters）

ユースケース層のデータを、外部のツール（WebフレームワークやUIなど）が扱いやすい形式に変換する役割を担います。俗に言うコントローラーやプレゼンターがこの層に属し、コンピューターシステムとアプリケーションロジックの橋渡しをします。

第4層：インフラストラクチャ（Infrastructure）

UI、データベース、外部APIとの連携、Webサーバーなど、具体的な技術要素が集まる最も外側の層です。これらの要素は技術の流行り廃りや外部の都合で頻繁に変わるため、最も不安定な層と位置付けられます。

それは「パターン」であって「規約」ではない

重要なのは、この4層構造を厳格に守ること自体が目的ではない、ということです。クリーンアーキテクチャは、これまでに語られてきた数々の優れた設計パターンの共通項を抽出し、再編成した「メタな存在」です。

プロジェクトによっては3層かもしれませんし、5層かもしれません。大切なのは、「安定度」を見極め、「依存の向きを内側へ制御する」という原則を理解し、それを実現するためにオブジェクト指向などのテクニックを駆使することです。クリーンアーキテクチャは、そのための強力なガイドラインなのです。

まとめ

クリーンアーキテクチャを導入する本当の意味は、特定のフレームワークを使うことではなく、変更の辛さを最小化するための設計原則を身につけることにある。今回、本書の第一章の内容を整理してみて、私が最も感銘を受けたのは、その驚くほどのシンプルさと普遍性です。

この原則を理解すれば、有名な4層構造はあくまでその一例に過ぎないこともわかります。大切なのは円の数を覚えることではなく、自分たちのソフトウェアにとって何が「本質」で安定しているのかを見極め、そこに向かって依存の矢印を向ける意識を持つことです。

『ちょうぜつソフトウェア設計入門』が示すように、開発者が本当に身につけるべき力は、クリーンアーキテクチャというパターンをなぞる能力そのものではなく、その背景にあるオブジェクト指向設計の深い理解と実践スキルに他なりません。それは、未来の自分たちを助け、ソフトウェアの価値を長期にわたって守り続けるための、強力な武器となるでしょう。

UX / UI のデザインに強いWebシステムの開発と、BtoB Webマーケを支援するWeb制作を提供する
N's Creates 株式会社は、神戸三宮オフィスまで週１出社（それ以外はリモートワーク）できる「デザイナー」「エンジニア」を募集しています。

興味のある方は、カジュアル面談しますので気軽にお問い合わせください！