マーティン・ファウラーの見解：流行りのスタックを超えて長く使えるアーキテクチャ

なぜ流行りのテックスタックだけでは良いアーキテクチャを保証しないのか

新しいフレームワーク、目立つクラウドサービス、あるいはホットな企業の「標準スタック」は、品質への近道に見えることがあります。しかしスタック先行の思考はツールと構造を混同しがちです。最先端の技術で扱いにくいシステムを作ることもできれば、地味でよく知られた選択肢でクリーンで適応可能なシステムを作ることもできます。

「スタック先行」思考の問題点

スタックを先に決めると、スライド映えするものの実際の問いに答えない決定にチームが追いやられます：

• 境界はどこにあるのか？
• 何が頻繁に変わる必要があるのか？
• 何を安定させる必要があるのか？

技術選択が先に来ると、アーキテクチャは偶発的な副産物になり、タイトな結合、重複ロジック、単純な変更が高コストになる依存性が生まれます。

だから「マイクロサービスを使っている（あるいは今はサーバーレスだ）」というだけではアーキテクチャではありません。それはデプロイやツールの方向性です。アーキテクチャはシステムの部品がどう協調するか、決定が将来の仕事をどう制約するか、製品がどれだけ容易に進化できるかに関わるものです。

実務的な含意：ツールはデリバリを加速できますが、アーキテクチャ的思考に取って代わるものではありません。チャットで生成・反復するような現代の「vibe-coding」アプローチでも、同じ問いは残ります。Koder.ai のようなプラットフォームはウェブ、バックエンド、モバイルアプリの構築を劇的に速めるかもしれませんが、最良の成果を出すチームは境界、所有権、変更のしやすさを第一級の関心事として扱います（フレームワークが魔法的に解決するものではないと認識しています）。

ファウラーの影響：明快さ、実用主義、そして時間をかけた変化

マーティン・ファウラーの著作は常に本質への注意を引き戻します：流行のコンポーネントよりも明快な設計、イデオロギーよりも実践的トレードオフ、学びながらシステムを進化させる能力。彼の仕事はアーキテクチャを一度きりの“大きな設計”ではなく、継続的に改善するものとして扱います。

この記事で扱うこと

繰り返し現れるテーマは三つ：パターンはルールではなく道具として使うこと、リファクタリングを習慣にすること、そして進化するアーキテクチャ——確実性ではなく変更に備える設計です。

誰に向けた記事か

エンジニアリングリーダー、テックリード、または品質を維持しつつ高速に出荷しようとするプロダクトチーム向けです。目標は「完璧な」スタックを選ぶことではなく、ロードマップが必然的に変わったときにソフトウェアを容易に変更できるように決定を下すことです。

「ソフトウェアアーキテクチャ」が本当に意味すること（専門用語抜きで）

ソフトウェアアーキテクチャとは、後で変更するのが難しく（高コストで）なる決定の集合です。

この定義はわざと平易です。特別な図や「アーキテクト」という肩書きは不要です。ソフトウェアがどう成長するか、チームがどう働けるか、運用コストがどうなるかを決める選択についての話です。

アーキテクチャはテックスタックではない

フレームワーク、ツール、コーディングスタイルは重要ですが、それらの多くは真のアーキテクチャ的選択と比べれば取り替えやすいです。

• React と Vue の選択はしばしば元に戻せます。
• 「すべての書き込みは単一サービスを経由する」と決めるのはずっと戻しにくいです。

アーキテクチャは構造や境界に近い：部品がどう通信するか、データがどこにあるか、障害をどう扱うか、どの変更にチーム間の調整が必要か。

アーキテクチャは大半がトレードオフである

普遍的な“最良”のアーキテクチャはありません。各決定はある目標に最適化し、他を犠牲にします：

• パフォーマンス vs シンプルさ：キャッシュ層は高速化するが複雑さや厄介なエッジケースを生む。
• チームの速度 vs 信頼性：高速なリリースは学習を早めるが、強いテストやローアウト手順を必要とする。
• コスト vs レジリエンス：冗長化は稼働時間を改善するが、インフラと保守コストを増やす。

良いアーキテクチャはこれらのトレードオフを偶然に任せず明示化します。

例：アーキテクチャ的決定とライブラリ選択の違い

• アーキテクチャ的決定：「顧客の請求を独立したデプロイ可能なサービスとその専用データベースに分け、残りは非同期イベントで統合する。」

  これはデプロイ、データ所有、障害モード、監視、チーム調整に影響します。

• ライブラリ選択：「PDF 生成にライブラリ X を使う。」

  有用だが、通常は限定的な影響範囲で置き換え可能です。

もし元に戻すのに数週間の協調作業が必要なら、その決定はアーキテクチャです。

パターンを道具として使う：有益、任意、時に誤用される

デザインパターンは反復する問題に対する再利用解であり、戒律ではありません。ファウラーの基本姿勢は実用的で、パターンが設計を明確にする時に有用で、思考の代わりになると有害だというものです。

パターンが役立つ時

適切に使えば、パターンはチームの共通語彙を与えます。「ストラテジー」や「リポジトリ」と言えば長い説明を一語で圧縮でき、レビューが速くなり誤解が減ります。

また、パターンはシステムの振る舞いを予測可能にします。馴染みあるパターンはロジックの所在、オブジェクトの協調、どの変更が波及しやすいかについて期待を設定します。その予測可能性は本番での驚きを減らし、新メンバーの「これどう動いてるの？」を減らします。

パターンが害になる時

失敗モードはカーゴカルト化です：流行っているから、本に載っているから、あるいは「ここではこうする」という理由だけでパターンを適用すること。これにより過剰設計（余分なレイヤー、迂回、払戻しのない抽象化）が生まれます。

もう一つの罠は「すべてにパターンを当てはめる」こと。小さな問題ごとに名前付きの解決策があると、コードベースは保守の道具ではなく技巧の博物館になりがちです。

実用的な選び方

問題から始めて、パターンは後から選ぶ。

問うべきこと：

• どの変更を楽にしたいのか？
• どんなリスクを減らすか？
• どんな複雑さを導入するか？

それから、今日に合う最も単純なパターンを選び、選択肢を開いたままにします。より構造が必要になれば、実際の痛みをガイドに段階的に導入し、リファクタリングによって確認していくのが良いです。

リファクタリング：アーキテクチャを健康に保つ習慣

リファクタリングは内部設計を改善する実践であり、振る舞いを変えずに行います。ユーザーはリファクタ後に違いを感じるべきではありません——ただし未来の変更が容易で安全かつ迅速になるはずです。

ファウラーの主張は「コードをきれいに保て」という美的要求ではなく、アーキテクチャは最初に描く一回きりの図ではないという点です。アーキテクチャはシステムがどれだけ容易に変化できるかを決める一連の決定であり、リファクタリングはそれらの決定が硬化した制約にならないようにする手段です。

なぜリファクタリングはアーキテクチャ活動なのか

時間と共に、よく設計されたシステムでもドリフトします。新機能が短期的な圧力の下で追加され、クイックフィックスが永続化し、境界があいまいになります。リファクタリングは明確な分離を回復し、偶発的複雑さを減らすことでシステムの変更可能性を維持します。

健康なアーキテクチャは次を満たします：

• 重要なビジネスルールが UI 詳細と絡み合っていない
• モジュールに明確な責任がある
• 依存関係が合理的な方向を向いている

リファクタリングはこれらの特性を保つ日常作業です。

「今がその時」を示す一般的なトリガー

リファクタリングはカレンダーで予定するものではありません。コードが抵抗を示すときに行います：

• 重複：同じルールが三か所にあり、徐々に乖離している
• 境界不明瞭：「全部が全部に触れている」で変更が危険になる
• 遅いデリバリ：単純な要求が数日かかる、各変更で驚きが起きる

これらが現れたら、アーキテクチャはすでに影響を受けており、リファクタリングが修復になります。

安全にリファクタする方法（壊さないために）

安全なリファクタは以下の習慣に依存します：

• 主要なビジネスロジックを守るテスト
• 小さなステップ：多数の小さな可逆的変更
• コードレビュー：副作用やスコープの拡大を防ぐ

この方法で行えば、リファクタリングは定期的な保守になり、システムを次の変更に備えて脆弱にする代わりに準備します。

技術的負債：どのように蓄積し、どう返済するか

技術的負債は「今日の近道が生む将来のコスト」です。それは道徳的な失敗としての“悪いコード”ではなく、将来の変更コストを増やすトレードオフです。ファウラーの見方は有用で、負債は問題になるのは追跡をやめて見ないふりをした時だ、としています。

意図的な負債と偶発的な負債

意図的な負債は目を開けて負うものです：「まず簡単な版を出して、次スプリントで強化する」。これは返済計画があれば合理的です。

偶発的な負債はチームが借りていることに気付かないときに起きます：雑な依存性、あいまいなドメインモデル、クイックワークアラウンドがデフォルトになるなど。偶発的負債は所有者がいないことが多く、より高コストになります。

負債はどうやって静かに積もるか

通常のプレッシャーで負債は積み上がります：

• 急な締切で「とにかく動く」選択を強いられる
• 所有権不明瞭で誰もモジュールの健全性を感じない
• 足りない／脆いテストで変更が怖くなり近道を選ぶ

結果は予測可能です：機能の速度が落ち、バグが増え、リファクタリングがルーチンではなく危険に感じられるようになります。

軽量な負債管理と返済法

大規模なプログラムは必要ありません：

• 継続的に時間を確保する（例：各イテレーションの小さな割合）
• すべてではなくホットスポットを追う：よく触る、怖い箇所に集中
• 小さく返済する：機能作業と組み合わせてリファクタリングする

負債関連の決定を可視化すれば（例えば /blog/architecture-decision-records を参照）、隠れたコストが管理可能な作業になります。

進化するアーキテクチャ：確実性ではなく変化に備えて作る

ソフトウェアアーキテクチャは一度「正しく」なる青写真ではありません。ファウラーの視点はもっと実用的です：要件、トラフィック、チーム、制約は変わると仮定して、その変化に痛みなく対応できるよう設計することです。

「進化するアーキテクチャ」とは

進化するアーキテクチャは完璧さを目指すのではなく変化に備える設計です。「マイクロサービスにする」「100倍にスケールする」といった長期予測に賭ける代わりに、明確な境界、自動化テスト、頻繁に低リスクで調整できるデプロイの慣行を備えたシステムを作ります。

小さなリリースと実際のフィードバック

計画は推測です。本番が現実を教えてくれます。小さな増分リリースはユーザーが実際に何をするか、運用コストが実際にはどうか、パフォーマンスや信頼性がどこで重要になるかを学ばせてくれます。

小さなリリースは意思決定のスタイルも変えます：1つのモジュールを分割する、小さな API バージョンを導入するなど控えめな改善を試し、効果を測定できます——大規模な移行に賭ける代わりに。

ここで高速反復ツールは役立ちますが、建築のガードレールとセットで使うことが重要です。例えば Koder.ai のようなプラットフォームで素早く機能を生成・反復する場合でも、速度と並行してモジュール境界、良いテスト、頻繁なデプロイを維持すれば「高速に出荷して角に追い込まれる」ことを避けられます。

フィットネス関数（平易な言葉で）

進化の重要な考え方が「フィットネス関数」です：アーキテクチャ目標を守る測定可能なチェックポイント。ガードレールのようなものです。自動化され継続的に動くと、ドリフトしたときに警告してくれるので自信を持って変更できます。

フィットネス関数は複雑である必要はありません。あなたが気にする指標、テスト、閾値の形で良いのです。

実用的なフィットネスチェックの例

• ビルド時間： ビルド/テストが予算（例：10分）を超えたらパイプラインを失敗させる。遅いビルドはリファクタリングと安全な変更を妨げる。
• エラー率： 本番のエラー率が基準を超えたらアラート、あるいはローアウトをブロックする。
• セキュリティスキャン： 依存やコンテナを自動スキャンし、既知の重大脆弱性でビルドを失敗させる。
• API 互換性： コントラクトテストでリリースが既存クライアントを壊さないことを保証する。

全部を測る必要はありません。変更速度、信頼性、セキュリティ、相互運用性など自分たちのアーキテクチャの約束を反映するいくつかを選び、それらに基づいて日々の意思決定を行いましょう。

マイクロサービス vs モノリス：流行で選ばず制約で選ぶ

マイクロサービスはエンジニアリング成熟度のバッジではありません。ファウラーの要点は単純です：サービスに分割することは技術的な判断であると同時に組織的な動きでもあります。チームがサービスをエンドツーエンドで所有できないなら（構築、デプロイ、運用、進化）、複雑さだけ増えて利点は得られません。

三つの形、三つのトレードオフ

モノリスは一つのデプロイ可能ユニットです。利点は少ない可動部分、単純なデバッグ、一貫したデータ整合性。欠点はコードベースが絡み合うと小さな変更でも大きな調整が必要になる点です。

モジュラーモノリスは依然として一つのデプロイユニットですが、コードが意図的に明確なモジュールに分かれており境界が守られます。運用の単純さを保ちながら内部結合を減らせます。多くのチームにとってこれは最良のデフォルトです。

マイクロサービスは各サービスが個別のデプロイとライフサイクルを持ちます。独立したリリースと明確な所有権を実現できますが、組織がそれに備わっていないと「一つの困難」を「十の困難」にしてしまいがちです。

人々が忘れがちな隠れたコスト

マイクロサービスはアーキテクチャ図には見えないオーバーヘッドを伴います：

• デプロイ：パイプライン、バージョニング、ロールバック、調整が増える
• 可観測性：分散トレース、ログ相関、意味のあるメトリクスが必要
• オンコール負荷：失敗モードとアラートが増え、インシデント対応が重くなる
• データ整合性：トランザクションが難しくなり、最終的整合性やレポーティングが厄介になる

実用的なヒューリスティック

まずはモジュラーモノリスから始め、実際の圧力を測定してから分割する：リリースのボトルネック、モジュール周りのチーム間争い、スケーリングのホットスポット、信頼性分離の必要性など。これらの圧力が持続的かつ定量化されたときに、明確な境界と専任の所有者、運用計画を持ってサービスを切り出します——ただコードだけを分けるのではありません。

境界、結合、依存の実コスト

良いアーキテクチャはサービス数ではなく、一部を変えても他の三つが壊れないかにかかっています。ファウラーはこれを 結合（どれだけ絡み合っているか）と 凝集（一部がどれだけまとまっているか）で説明することが多いです。

結合と凝集を専門用語抜きで

レストランのキッチンを思い浮かべてください。凝集したステーション（例えば「サラダ」）は必要な材料、道具、責任が揃っています。タイトに結合したキッチンではサラダを作るのにグリル担当が止まり、パティシエがドレッシングを承認し、マネージャーが冷蔵庫の鍵を開ける必要があるような状態です。

ソフトウェアも同じです：凝集したモジュールは明確な仕事を持ち、疎結合のモジュールは単純で安定した合意を通してやり取りします。

不健全な結合を見つける方法

不健全な結合はコードの前にスケジュールに現れることが多いです。一般的な兆候：

• 調整されたリリース：「Team B が出すまで出せない」
• 頻繁なチーム間ブロッカー：作業が止まるのは他チームが変更しないといけないから
• 波及変更：小さな機能で多くのリポジトリやサービスを編集する必要がある

配達プロセスで定期的に群舞（グループ調整）が必要なら、依存のコストは既に支払われています——ただし会議と遅延の形でです。

結合を減らす設計上の手法

結合を減らすにはリライトは不要です。実用的な手段：

• 明確な API と契約：インターフェースを製品として扱い、安定かつ分かりやすい命名にする
• 境界づけられたコンテキスト：各領域が何を所有するか（ルールや用語も含む）を決める
• モジュール化：モノリスでも明示的な境界を持つモジュールは「ミニサービス」のように振る舞える

重要な決定は軽量なノート（例：/blog/architecture-decision-records）で残し、境界が意図的であり続けるようにしましょう。

データ：最も難しい境界

共有データベースは“秘密の結合”を作ります：どのチームもテーブルを変えられ、それが他を壊す可能性があります。共有 DB はサービスが独立して見えても実際には調整リリースを強いることが多いです。

より健全なアプローチはデータ所有権です：一つのシステムがデータセットを所有し、API やイベントで公開する。これにより依存が可視化され、管理可能になります。

アーキテクチャは社会的でもある：チームがシステムを形作る

ソフトウェアアーキテクチャはボックスと矢印だけではありません。仕事の分け方、意思決定の方法、現実が設計と矛盾したときの反応速度など、人の側面も重要です。これが社会技術的アーキテクチャの考え方で、システム構造はチーム構造を反映しがちです。

組織図が設計と戦うとき

紙の上に「きれいな」境界を設計しても、日々のワークフローがそれを横切っていれば失敗します。システムは技術的にはコンパイルしてデプロイできても、変更が高コストに感じられることがあります。

不一致の兆候：

• 頻繁なハンドオフ（"Team A が承認して、Team B がデプロイして、Team C が監視する"）
• 所有権の不明確（"このエンドポイントは誰の？" "うちじゃない"）
• インシデント対応が遅い（アラート、ログ、修正が複数チームにまたがる）
• 多数グループの同期リリースに依存するロードマップ

摩擦を減らす実用的な方法

所有権から始め、完璧ではなく現実的な境界を目指します。

• モジュール/サービスをチームに合わせる：1チームが他5つと調整せずに意味ある変更を行えること
• 責任を明確にする：各コンポーネントを誰が作り、運用し、改善するか（オンコールや運用予算も含む）を定義する
• ハンドオフを減らす：チームが独立して動けるよう安定した契約や共通基準を用意する

制約を現実的に受け入れる

チームを再編できない、レガシーモジュールを分割できない、採用で解決できないこともあります。その場合はアーキテクチャを交渉と捉え、最も高コストな調整を減らす境界を選び、自治を解放するようなリファクタに投資し、移行中の妥協は技術的・組織的負債を返済する計画とともに受け入れます。

決定を可視化する：簡潔な Architecture Decision Records

アーキテクチャは作るものだけでなく、途中で下した決定でもあります。Architecture Decision Records（ADRs）は、その決定を文脈が鮮明なうちに短く記録するメモです。

ADR とは何か（何でないか）

ADR は「何を決め、なぜか」を答える一ページメモです。長い設計書でも許可証でもありません。チームの耐久的な記憶として考えてください。

含めるべき内容

構造を一貫させてスキャンしやすくしましょう。軽量な ADR は通常：

• 決定：何を選んだか（例：「v1 はモジュラーモノリスを採用」）
• コンテキスト：解こうとしている問題と制約
• 検討した代替案：現実的な選択肢 2–3
• 結果：トレードオフ（何が楽になるか、何が難しくなるか）
• 日付とステータス：提案／採択／置換
• オーナー：決定を主導した人物（責める相手ではなく）

得られる効果

ADR は新入りのオンボーディングを早め、同じ議論を繰り返すことを防ぎます。現実が変わったときに計画を見直すための根拠も残ります。

軽量に保つ

簡単なテンプレートを使い、ADR をコードのそば（例：/docs/adr/）に置き、1 件書くのに 10–20 分を目安にしてください。

# ADR 012: API versioning strategy
Date: 2025-12-26
Status: Accepted
Owners: Platform team

Context:
We need to evolve public APIs without breaking partners.

Decision:
Adopt URL-based versioning (/v1/, /v2/).

Alternatives:
- Header-based versioning
- No versioning; rely on backward compatibility

Consequences:
+ Clear routing and documentation
- More endpoints to support over time

ADR が書類仕事に感じるなら短くしてください――習慣をやめないでください。

継続的デリバリとフィードバック：進化のエンジン

アーキテクチャは一度きれいに描いた図で保たれるわけではありません。システムは頻繁に小さな、安全なステップで変えられるときに良好さを保ちます。だから継続的デリバリ（CD）と高速フィードバックループが重要です：進化を危険なイベントではなく日常の習慣にします。

CI/CD はリファクタリングを実用的にする

リファクタリングは変更が小さく可逆的なときに最も容易です。健全な CI/CD パイプラインはすべての変更を自動でビルド、テスト、検証することでそれを可能にします。パイプラインが信頼できれば、チームは“大きな書き換え”を待つことなく設計を継続的に改善できます。

変化を可能にする品質ゲート（官僚主義ではなく）

品質ゲートは高速で一貫しており、あなたが気にするアウトカムに結びついているべきです。一般的なゲート：

• 自動テスト（ユニット＋統合）で内部を変えても振る舞いを保つ
• 静的解析で危険なパターンを早期検出（複雑さ、不安全な呼び出し、依存問題）
• セキュリティチェック（依存スキャン、基本的な SAST）でサプライズ脆弱性を防ぐ

目的は完全主義ではなく、壊すコストを上げつつ安全な改善のコストを下げることです。

可観測性はアーキテクチャへのフィードバック

良いアーキテクチャは本番で何が起きているかを知ることの一部です。フィードバックがなければ推測で最適化することになります。

• ログはインシデント時に何が起きたか（とその理由）を教える
• メトリクスは傾向を示す：エラー率、レイテンシ、キュー深度、飽和度
• トレースはサービス境界を越えてどこに時間が使われているかを示す

これらの信号があれば、アーキテクチャ決定を意見ではなく証拠で検証できます。

リリースの安全性：恐れずに出荷する

進化には頻繁なリリースが必要です。そのためには逃げ道が要ります。フィーチャーフラグはデプロイとリリースを切り離します。カナリアリリースは影響範囲を限定します。明確なロールバック戦略（データベース考慮を含む）は失敗を回復可能なイベントに変えます。

スナップショットとロールバックをサポートするアプリケーションプラットフォーム（例えば Koder.ai）を使うと、プロダクトデリバリ層でも同じ原則を強化できます：速く動きつつ、可逆性と運用の安全性をデフォルトにすること。

CI/CD とフィードバックを組み合わせることで、継続的に進化できるシステムが出来上がります——まさにトレンドを超えて残るアーキテクチャです。

今四半期にファウラーの考えを適用する実用チェックリスト

リライトは不要です。設計上の問題を可視化し、可逆にし、継続的に改善する反復可能な習慣が必要です。

すぐ使えるチェックリスト（計画時に使う）

• 明快さ： 新入りがシステムの主な責任を1ページで説明できるか？できないなら、主要領域ごとに短い README を追加してシステムの“形”を書き出す。
• 境界： モジュール／サービスに明確な所有と目的があるか？共有 DB やユーティリティバケット、神パッケージがないか？強化する境界を一つ選ぶ。
• テストを安全に： リファクタリングを恐れず行える高速なテストはあるか？最も変更されるコード周りの薄いが高価値なカバレッジを優先する。
• デプロイ： 小さな変更を頻繁にデプロイできるか？リリースがつらいなら、新たなアーキテクチャの複雑さを追加する前にデプロイを退屈にすることに注力する。
• 所有権： 何を誰が保守するか明確か？可能ならコードの境界をチームの境界と合わせ、そのマッピングを明示する。

30/60/90 日の改善プラン

次の30日： ホットスポット（高い変更頻度・頻繁な障害）を一つ選ぶ。特性テストスイートを追加し、ある依存連鎖を簡素化し、新しい変更のために軽量な決定ノートを書き始める。

60日までに： 問題のある継ぎ目をリファクタする：モジュールを抽出する、インターフェースを定義する、永続化やメッセージングなどのインフラ関心を境界の後ろに隠す。変更の“爆発範囲”を減らす。

90日までに： デリバリループを改善する。小さなプルリク、速いビルド、予測可能なリリースのリズムを目指す。マイクロサービスを検討する場合は、境界が既存コードベース内部で管理できないことを実証してから進めること。

（もし目的が単にハンドオフを減らしてより多くのプロダクトを出荷することなら、自動化が助ける箇所を検討してください。あるチームでは Koder.ai のようなチャット駆動のビルドワークフロー——プランニングモード、ソースエクスポート、デプロイ/ホスティング、カスタムドメイン、フリートゥエンタープライズの価格帯——が機械的なオーバーヘッドを減らし、境界、テスト、運用フィードバックに建築的注意を集中することを可能にします。）

努力ではなく成果を測る

毎月いくつかの信号を追う：

• コミットから本番までのリードタイム
• 変更失敗率（ロールバック、ホットフィックス）
• インシデント件数と再発原因

これらが改善していなければ計画を調整してください——アーキテクチャが“良くなった”のは変更が安全で安価になったときだけです。

スタックは変わり続けます。基本は変わらない：明確な境界、リファクタリングの規律、そして高速なフィードバックです。