はじめに
ソフトウェア開発では「設計」と「アーキテクチャ」という言葉をよく耳にします。
しかし「設計＝クラス図を書くこと？」「アーキテクチャ＝フレームワークの選定？」と混乱しがちです。
Robert C. Martin（Uncle Bob）の名著『Clean Architecture』は、冒頭で次のように問いかけます。
「設計とアーキテクチャの違いは何か？」
本記事ではその整理を行い、さらに実務での意味合いを考えてみます。
ソフトウェアの二つの価値
ソフトウェアには2つの価値があります。
-
振る舞い（Behavior）
- ユーザーやビジネスに直接役立つ機能
- 「動くこと」そのものの価値
-
構造（Structure）
- 将来的な変更を容易にする設計のしやすさ
- 「変更しやすいこと」こそが長期的な価値
目先の「動くコード」だけを優先すると、構造が壊れ、将来の変更コストが爆発します。
設計の目的とは？
- 設計の本質は ソフトウェアを変更しやすくすること。
- 「動くコードを書く」ことは最低条件に過ぎません。
- 優れた設計やアーキテクチャは、新しい機能を短期間で安全に追加できる力を与えます。
Uncle Bob は言います。
「アーキテクチャの良し悪しは、どれだけ簡単に変更を加えられるかで測られる」。
設計とアーキテクチャの関係
- 設計（Design）
→ クラス、関数、モジュールなど比較的小さな粒度の決定。 - アーキテクチャ（Architecture）
→ システム全体の構造や依存関係の決定。
両者は明確に線引きできるものではなく、**「同じ目的を持つスケールの異なる活動」**と捉える方が自然です。
よくある誤解
- 「設計は時間がかかるから、とりあえず後回し」
- 「アーキテクチャはフレームワークを決めればOK」
こうした誤解は 技術的負債（Technical Debt） を積み上げます。
短期的には速く見えても、数ヶ月後には開発速度が急降下してしまうのです。
実例で考える（Flutter/Android）
悪い例：UIが直接HTTPを叩く
// Flutterの例
final response = await http.get(Uri.parse("https://api/users/42"));
final user = jsonDecode(response.body);
Text("Hello, ${user['name']}");
- UIがAPI仕様に直結 → API変更＝画面全修正
- テスト困難
良い例：UseCase / Repositoryを分離
// UseCase: ユーザー取得の振る舞いを表現
class GetUserUseCase {
final UserRepository repo;
GetUserUseCase(this.repo);
Future<User> call(int id) => repo.getUser(id);
}
- UIは抽象（UseCase）に依存 → APIやDB変更に強い
- テスト容易
設計とアーキテクチャは「変更しやすさ」を守る盾になることがわかります。
まとめ
- 設計とアーキテクチャの本質は同じ：変更容易性を高めること
- ソフトウェアには「振る舞い」と「構造」の二つの価値がある
- 短期の速さを優先して設計を犠牲にすると、長期的なコストが膨大になる
- 良いアーキテクチャは「新しい機能を素早く、安全に追加できる」形をしている