目次

初めに
結論
システムアーキテクチャとは
システムデザインとは
なぜ、すべての「良いデザイン」を詰め込めないのか？
なぜ『なぜそうしたか』が重要なのか
日々の業務で意識すべきこと
まとめ：アーキ・デザインへの理解がミドルへの第一歩

初めに

AIが普及した今、単なる「作業員」であるジュニアの価値は著しく落ちており、早急に意思決定に責任を持つミドル・シニアクラスへ上がることが求められていると感じています。

それらを達成し、エンジニアが価値を生み出すためには、
自分なりの意見を持ち、意思決定に対して責任を持つことが重要だと考えています。

システムアーキテクチャ・システムデザインを理解することで、
何に対して意思決定をすればいいのかを明確にし、日々の業務で意識すべきことを具体化していきたいと思います。

少しでも今の業務に対する向き合い方に変化があったらうれしいです。

本記事をかくうえで、名著「ソフトウェアアーキテクチャの基礎」を参考にしています。

参考：ソフトウェアアーキテクチャの基礎

本書では 『ソフトウェアアーキテクチャ』 という言葉が使われていますが、
本記事ではインフラや全体構造を含めた広い意味を込めて、
普段使い慣れている 『システムアーキテクチャ』『アーキテクチャ』 という言葉で統一して解説します。

結論

システムアーキテクチャの本質は『何を』『どこに』置くのかを決めること
システムデザインの本質は『どのように』作るのかを決めること
アーキテクチャに最善はなく最悪があるだけなので、どちらにおいても『なぜそうしたか』が最重要となる
ジュニアの頃から目の前のシステムに対してアーキ・デザインのWhyを考え続けることがミドルへの第一歩になるのでは

システムアーキテクチャとシステムデザインの関係イメージ

システムアーキテクチャとは

システムアーキテクチャとは、一言でいえば システムの「骨組み」 です。
『何を』『どこに』置くのかを決定するもので、大きく下記4つの要素から構成されます。

$システムアーキテクチャ = 構造 + アーキテクチャ特性 + アーキテクチャ決定 + 設計原理$

構造: レイヤードやマイクロサービスといった、システムの見た目上の形。
アーキテクチャ特性: 可用性、スケーラビリティ、保守性など、システムが満たすべき「-ilities（〜性）」。
アーキテクチャ決定: 「この通信は非同期にする」といった、開発者が守るべき絶対的なルール。
設計原理: 「特定の技術に依存しない」といった、開発の指針・ガイドライン。

これらを考えながら、要件に合うアーキテクチャを設計していくのですが、0から考える必要はなく、将棋の定石のように、ある程度決まったパターンから選択していきます。
例えばレイヤードアーキテクチャを選択して、プレゼンテーション層、ビジネス層、永続化層、データベース層が分かれているものを作る、といったイメージです。

なぜアーキテクチャを選ぶのか

システムを構築する際に、「どんな要件を満たしたいか」というアーキテクチャ特性を定義する必要があります。

可用性・耐障害性: 止まらないこと
パフォーマンス: 速いこと
スケーラビリティ: 拡張できること
メンテナンス容易性: 修正しやすいこと

などなど、システムに求められる要件を整理します。

アーキテクチャごとに得意・不得意があるため、「すべての特性を満たす最強の構成」は存在しません。
例えばレイヤードアーキテクチャは、構造が単純で開発コストを抑えられるため、「メンテナンス容易性」や「開発スピード」 を重視するシステムにおいて非常に強力な選択肢となりますが、
モノリシックアーキテクチャであるため、「スケーラビリティの低下」や「耐障害性の低さ」 がデメリットとして挙げられます。

システムデザインとは

システムデザインとは、『どのように』システムを作るのかという「具体的な実装方法」 です。
アーキテクチャという骨組みの中で、定義された「特性」を実現するための手段（戦術）を選んでいきます。

可用性・耐障害性を上げるために、DB設計にシングルリーダーレプリケーションを実装する
スケーラビリティを上げるために、パーティショニングを実装する
パフォーマンスを上げるために、最もリージョンに接続するようにする

などなど、アーキテクチャ特性ごとに実装方法が複数あり、要件に合わせてシステムデザインを組み合わせていきます。

同じレイヤードアーキテクチャを選択したとしても、その中身をどう実装するかは目的や状況に応じていくつもの選択肢が存在します。

ビジネスロジックの書き方：
- 手続き型でシンプルに書くか（トランザクションスクリプト）
- 複雑なルールをオブジェクトに持たせるか（ドメインモデル）
データアクセスのやり方：
- DBのテーブルとコードを1対1で対応させるか（アクティブレコード）
- DBの存在を隠して、コレクションのように扱うか（リポジトリパターン）
UIへのデータ渡し：
- 生のデータをそのまま渡すか
- 表示専用の型に詰め替えるか（DTO：Data Transfer Object）

このように、同じ「レイヤード」という看板を掲げていても、その内部のデザインの組み合わせは無限にあります。

なぜ、すべての「良いデザイン」を詰め込めないのか？

「それなら、常に一番リッチで強力なデザインパターンを全部組み合わせれば、最強のシステムになるのでは？」と思うかもしれません。

しかし、現実はそう甘くありません。すべてを完璧に満たすデザインの組み合わせは存在しないのです。
アーキテクチャにおける最も重要なルールにこんなものがあります。

アーキテクチャの第一法則：
「ソフトウェアアーキテクチャのあらゆるものは、トレードオフである」

ドメインモデルを使えば保守性は上がりますが、コード量は増え、学習コストも跳ね上がります。

リポジトリパターンで抽象化すればDBの入れ替えは楽になりますが、単純な開発ではオーバーエンジニアリングになり、スピードを殺します。

何かを優先すれば、必ず別の何かが犠牲になります。
もし「この選択にデメリットはない」と感じたなら、それはまだトレードオフを見つけられていないだけなのです。

なぜ『なぜそうしたか』が重要なのか

正解がない中で、私たちは何を目指すべきなのでしょうか。著者はこう述べています。

「最高のアーキテクチャを目指すのではなく、その時々における『もっとも悪くない（least worst）』アーキテクチャを目指せ」

完璧な「最善」は存在しませんが、要件に対して致命的な欠陥を持つ「最悪」は存在します。その「最悪」を避け、現在の制約の中で最もマシな選択肢を選び取るのがアーキテクトの仕事です。

ここで、アーキテクチャの第二法則が登場します。

アーキテクチャの第二法則：
「『どうやって（How）』よりも『なぜ（Why）』の方が重要である」

「レプリケーションを使った（How）」という事実に価値があるのではなく、「コスト増のリスクを承知の上で、ビジネス上の継続性を守るために可用性を優先した（Why）」という意思決定の根拠にこそ価値があります。

なぜなら、数年後に前提条件が変わったとき、その「なぜ」が記録されていなければ、システムはただの「負債」になってしまうから、というのが書籍の解説です。

個人的にも、下記記事の感想で述べたように、AIによってコーディングの価値が失われていく今の環境において『自分なりの意見』を持つことが価値に繋がると考えているので、
アーキテクチャ選定などの意思決定は今後すべてのエンジニアに求められる能力だと考えています。

日々の業務で意識すべきこと

今までの話を受けて、
「意思決定は上流工程の仕事だから、ジュニアやSESの自分には関係ない」
「意思決定の経験を積みたくても今の業務では難しい」
と思ってしまうかもしれません。

しかし、アーキテクトとしての視点を養うチャンスは、日々のコーディングの中にこそ転がっていると考えています。

明日から意識すべきアクションは、「目の前のコード（How）から、裏側にある意図（Why）を逆算する」 ことです。

1. 既存のコードを「なぜ」で深掘りする

今触っているシステムのデザインや構造を観察し、その裏にある設計思想を想像してみてください。

「なぜ、このプロジェクトは単純なMVCではなく、わざわざ複雑なクリーンアーキテクチャにしているのか？」
「なぜ、この通信は同期処理ではなく非同期を選んでいるのか？」

ソフトウェアアーキテクチャの第二法則にある通り、「どうやって実装されているか（How）」を知るだけでは不十分です。
その裏にある 「なぜそうしたか（Why） を読み取ろうとすることで、過去のエンジニアが行った「意思決定の痕跡」が見えてきます。

2. トレードオフを見つける訓練をする

アーキテクチャの第一法則によれば、あらゆる選択にはトレードオフが存在します。
あなたが書いているそのコードが「便利」だとしたら、代わりに何を犠牲にしているかを考えてみてください。

メリット：抽象化して保守性が上がった
デメリット：記述量が増え、初見のメンバーには解読が難しくなった

このように、常に 「メリットの裏にある代償」 を探す癖をつけることが、アーキテクチャの基礎で言われる「最悪を避ける（もっとも悪くない選択をする）」ための判断力を養います。

3. 自分の意見を頭の中でシミュレーションする

新機能の設計やリファクタリングの際、「自分ならどうするか」という仮説を立ててみましょう。
「今の状況なら、スピードを優先してこのデザインを選ぶ。なぜなら……」と、根拠（Why）をセットにした自分なりの意見を積み重ねていくのです。

この「Why」のストックこそが、将来新しいシステムを作るときに「自分の意見」として昇華されます。

まとめ：アーキ・デザインへの理解がミドルへの第一歩

私は、意思決定の訓練を積むのに役職や立場は関係ないと考えています。

今触っているシステムの「Why」を理解し、その設計思想に触れようとすることが、
単なる「作業員」から脱却し、意思決定に責任を持つ「ミドル・シニアクラス」へと到達するための下地になると考えています。

AIにコードを書かせるのが当たり前になるこれからの時代、最後に残るのは
「なぜそれを作るのか」「なぜこの形であるべきなのか」という意思決定の価値です。

日々の業務を「ただのタスク」で終わらせず、アーキテクトの視点で向き合っていきましょう。