プロローグ — アーキテクチャを選ぶということ
月曜の朝、カオリは会議室で固まっていた
画面には真っ白なドキュメント。タイトルには「新規ECプラットフォーム アーキテクチャ設計書（案）」と書いてある。カーソルが点滅している。
田中カオリ、35歳。SIer出身で独立系スタートアップに転職して3年目のシニアエンジニアだ。Rails歴8年、AWSの設計経験もある。それなりの自信はあった。しかし今日は違う。
「カオリさん、来週の月曜日までに初稿お願いします」
CTO の声が脳内でリプレイされる。新しいECプラットフォームは、3ヶ月後にβリリース、1年後に本番ローンチ予定。想定ユーザー数は初年度10万人、3年後には100万人。チームは自分を含めて6人。
何から始めればいい？
クリーンアーキテクチャ？ マイクロサービス？ それとも素直なモノリス？ 先週読んだブログではサーバーレスが最高と書いてあった。でも、どれが「正解」なのだろう。
INFO
この本は、カオリとともに主要なソフトウェアアーキテクチャを探求する旅です。各章でカオリが直面する課題を通じて、アーキテクチャの選択とトレードオフを学んでいきます。
アーキテクチャとは何か
ソフトウェアアーキテクチャという言葉は、人によって指す範囲が違う。コードの構造、システムの配置、チームの分割方法、全部含まれることもある。
本書では、次のように定義する。
ソフトウェアアーキテクチャとは、システムの重要な設計上の決定の集合であり、変更が困難であるもの
ここでの「変更が困難」というのがポイントだ。後から簡単に変えられる決定はアーキテクチャの問題ではない。しかし、一度決めると変更コストが非常に高い決定—例えばデータベースの分割戦略、サービス間通信の方式、コードの責務の境界—これらがアーキテクチャを構成する。
カオリはノートにこう書き留めた。「アーキテクチャを決めることは、将来の選択肢を制約すること。だから慎重に、でも必ず決めなければならない」
なぜアーキテクチャが重要なのか
「そんな高尚な話より、まずコード書けばいいじゃないか」という声も聞こえてくる。実際、カオリも前職では設計ドキュメントなど書かずに突っ走って成功した経験がある。
しかし、規模が大きくなるにつれて、アーキテクチャの不在は致命的なコストを生む。
技術的負債の雪だるま
設計なしに書かれたコードは、最初は速い。しかし機能が増えるにつれ、密結合になった部分が足を引っ張り始める。バグを直すと別の場所が壊れる。新機能を追加するには既存コードを全部理解しないといけない。
カオリの前職でも、2年後には「全部作り直し」という判断を迫られた。その書き直しに1年かかった。
チームの認知負荷
コードベースが大きくなると、一人の頭では全体を把握できなくなる。アーキテクチャは「誰が何を担当するか」の地図になる。地図がなければ、6人のチームは6方向にバラバラに動く。
変化への対応力
ビジネス要件は必ず変わる。「3ヶ月後に決済プロバイダーを変更したい」「来年には海外展開する」。アーキテクチャが良ければ、こうした変化を局所的な修正で吸収できる。悪ければ、連鎖的な修正が全システムに及ぶ。
アーキテクチャに「正解」はない
カオリが最初に気づくべきことがある。それは、アーキテクチャに唯一の正解は存在しないということだ。
Googleはモノリスから始まった。Netflixはマイクロサービスへ移行した。Shopifyは今もモノリスで動いている。Amazonはサービス分割で有名だが、最近一部をモノリスに戻した事例もある。
重要なのは、それぞれの文脈だ。
- チームの規模と習熟度: 6人チームと600人チームでは最適なアーキテクチャが違う
- ビジネスの成熟度: 探索フェーズとスケールフェーズでは要求が全く異なる
- ドメインの複雑さ: ECサイトとリアルタイム取引システムでは自然な構造が違う
- 運用の能力: 複雑なインフラを運用できるチームかどうか
WARNING
「○○アーキテクチャが最高」という情報には注意が必要です。発信者の文脈（チーム規模・ドメイン・フェーズ）をセットで読まないと、間違った学習をしてしまいます。
トレードオフを理解する
良いアーキテクトは「これが最高」とは言わない。「この選択には、このメリットとこのデメリットがある。今の文脈ではこちらが適切だ」と言う。
カオリは、指導役の先輩エンジニア・ケンジの言葉を思い出した。
「設計判断はトレードオフの選択だ。完璧な設計はない。あるのは『今の文脈で最も少ない問題を持つ設計』だけだ」
その観点で、主要なアーキテクチャの特性を整理するとこうなる。
| アーキテクチャ | 開発速度 | スケール | 保守性 | 複雑さ |
|---|---|---|---|---|
| モノリス | 高 | 中 | 中 | 低 |
| レイヤード | 中 | 中 | 高 | 中 |
| クリーン | 低（初期） | 中 | 高 | 中 |
| マイクロサービス | 低（初期） | 高 | 中 | 高 |
| サーバーレス | 中 | 高 | 低 | 高 |
「これを見ると、マイクロサービスが一番スケールするけど、複雑さも高い。うちの6人チームには荷が重いかも」
カオリは初めて、霧が晴れるような感覚を得た。
本書の旅路
この本では、カオリとともに13のアーキテクチャを旅する。
- モノリシックアーキテクチャ: シンプルの強さ
- レイヤードアーキテクチャ: 責務の分離
- クリーンアーキテクチャ: 依存関係の制御
- ヘキサゴナルアーキテクチャ: 外部依存の隔離
- オニオンアーキテクチャ: ドメイン中心の設計
- CQRS: 読み書きの分離
- イベントソーシング: 事実の記録
- SOA: サービス指向の教訓
- サーバーレス: 関数で考える
- イベント駆動: リアクティブなシステム
- 比較と選定: トレードオフの実践
- エピローグ: 進化するアーキテクチャ
各章でカオリは、そのアーキテクチャをRailsで実装し、AWSで展開し、チームに説明しながら理解を深めていく。
カオリは白紙のドキュメントに最初の一文を書いた。
「アーキテクチャは、チームとシステムの未来への投資である」
さて、最初はどこから学ぼうか。まずは最もシンプルなところから始めよう。
次章では、「モノリシックアーキテクチャ」—一枚岩の力と限界—を見ていく。