【読書感想】『ソフトウェアアーキテクチャの基礎』を読み始めた話 Part1：エンジニアからアーキテクトへの思考の転換
はじめに
こんにちは。現在、26 卒として IT 企業（テクノロジーアーキテクト職）への入社を控えている学生です。
入社までの期間、技術力を高めるために Python や Java、AWS、Docker/Kubernetes など、フロントエンドからインフラまで幅広く学習を進めています。
学習を進める中で、「コードを書く」だけでなく、「どうシステム全体を設計するか」という視点の重要性を痛感し、オライリーの『ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ』を読み始めました。
・ ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ
今回は、この本の冒頭部分（第 1 部）を読んで得られた「アーキテクトとしての心構え」や、これまでのプログラミング学習との視点の違いについて、備忘録を兼ねてまとめます。
なぜこの本を手に取ったのか
アーキテクト職として配属が決まったものの、「そもそもアーキテクチャとは何か？」「シニアエンジニアとアーキテクトは何が違うのか？」という部分が自分の中で曖昧でした。
普段の個人開発では、
- 「とりあえず動くものを作る」
- 「新しい技術を使ってみたい」
というモチベーションで技術選定をしがちです。しかし、プロのアーキテクトとして仕事をする上では、より論理的な判断基準が必要だと感じ、体系的に学べる本書を手に取りました。
学び ①：アーキテクチャには「正解」がない
本書の冒頭で最も印象に残ったのが、以下の「ソフトウェアアーキテクチャの第一法則」です。
ソフトウェアアーキテクチャの第一法則
"ソフトウェアアーキテクチャはトレードオフがすべてだ"
これまでは「最高のアーキテクチャ」「最強の技術スタック」が存在すると思っていました。しかし、著者は「あるのはトレードオフだけであり、何を選ぶかよりも、何を選ばないか（何を犠牲にするか）が重要だ」と説いています。
さらにきれいなスペクトルは存在しないことを体現する言葉として
必然的帰結その一
"アーキテクトが、トレードオフではない何かを見出したと考えているなら、まだトレードオフを特定していないだけの可能性が高い"
と説いています。
具体例：モノリス vs マイクロサービスにおける「犠牲」
アーキテクチャ選定において、現在主流の「マイクロサービス」と、伝統的な「モノリス」を比較すると、第一法則の残酷なまでの正しさがわかります。
もし私たちが、拡張性（Scalability）や開発のアジリティ（Agility）を求めてマイクロサービスを選択したとします。その瞬間、私たちは対価として以下の「安寧」を即座に失うことになります。
-
「単純さ」を犠牲にする（複雑性の移動） モノリスでは関数呼び出し一つで済んでいた処理が、マイクロサービスではネットワーク越しの通信になります。アプリケーション内部のロジックの複雑さは減るかもしれませんが、代わりに「システム全体の連携」というインフラ・運用レベルの複雑さが爆発的に増大します。
-
「ACID 特性（厳密なデータ整合性）」を犠牲にする モノリスならデータベースのトランザクション機能（コミット/ロールバック）で守られていたデータの整合性が、サービス分割によって保証されなくなります。マイクロサービスを選ぶなら、結果整合性（Eventual Consistency）を受け入れ、分散トランザクションという極めて難易度の高い実装コストを支払う覚悟が必要です。
-
「パフォーマンス（レイテンシ）」を犠牲にする 本来、メモリ上の関数呼び出しで完結していた処理が、ネットワーク通信に置き換わるため、どうしてもオーバーヘッド（遅延）が発生します。「速さ」を定義する際、スループット（処理量）は向上しても、個々のリクエストに対するレイテンシ（応答速度）は悪化するというトレードオフが発生しがちです。
逆に言えば、「モノリスを選ぶ」ということは、拡張性の限界というリスクを背負う代わりに、「データの堅牢性と開発の単純さ」という強力な武器を手に入れるという意思決定でもあるのです。
学び ②：アーキテクチャを構成する 4 つの次元
本書では、アーキテクチャは以下の 4 つから成り立つと定義されています。
- アーキテクチャの構造（マイクロサービス、モノリスなどのスタイル）
- アーキテクチャ特性（可用性、拡張性、弾力性などの「〜ility」）
- アーキテクチャ決定（構築にあたっての決まりごと）
- 設計指針（ガイドライン）
特に「アーキテクチャ特性（非機能要件）」の重要性が強調されていました。
コードが書けること（機能要件）は当たり前で、ビジネスの要求に合わせて「システムがどう振る舞うべきか（性能、セキュリティ、保守性など）」を設計するのがアーキテクトの腕の見せ所なのだと理解しました。
学び ③：アーキテクトに求められる「知識の広さ」
開発者は特定の技術を深く知ることが求められますが、アーキテクトには技術の幅が求められるという話も刺さりました。
私は現在、インフラ（AWS/Docker/k8s）からフロントエンド（React/Next.js）まで手を広げて勉強していますが、「広く浅く知っていること」は決して悪いことではなく、むしろ「どの引き出し（技術）を使えば課題を解決できるかを知っている」という点で、アーキテクトにとって重要な資質なのだと勇気づけられました。
今後のアクションプラン
まだ読み始めたばかりですが、今後の学習において以下の意識改革を行おうと思います。
-
「なぜその技術を選んだのか？」を言語化する
- 単に「流行っているから」ではなく、メリットとデメリット（トレードオフ）を天秤にかけて選定理由を説明できるようにする。
-
アーキテクチャ特性を意識した実装
- コードを書く際、「この書き方は保守性が高いか？」「パフォーマンスに影響しないか？」を常に自問自答する。
-
継続的なインプット
- 本書を読み進めつつ、実際に手を動かして（Hands-on）、理論と実践を行き来する。
おわりに
『ソフトウェアアーキテクチャの基礎』は、技術書でありながら、エンジニアとしてのキャリアや考え方についても深く考えさせられる良書だと感じています。
これから入社までの期間、技術的な実装力と並行して、こうした「設計の視点」も養っていきたいです。
同じようにアーキテクトを目指している方や、設計・要件定義に興味がある学生エンジニアの方に、ぜひおすすめしたい一冊です。特にこの記事に書いたことだけでも十分に価値があると感じ、キャリアをスタートさせる上での重要なマインドセットが醸成されることは疑う余地がないと思います。
※本記事は学習中のメモであり、解釈に誤りがある可能性があります。ご指摘等あればコメントいただけると幸いです。
Discussion