「ソフトウェアアーキテクチャの基礎」で学んだことは「アーキテクト的なモノの考え方」

2025-03-28
読書

Table of Contents

「ソフトウェアアーキテクチャの基礎」で学んだことは「アーキテクト的なモノの考え方」

すべては場合による. アーキテクトの役割はトレードオフのバランスを取ること. ←が本の結論です.

料理のレシピ本のように様々なアーキテクチャが掲載されている本だと思っているそこのあなた! この本を読む価値があるでしょう.

この記事は, アーキテクトを目指すエンジニアや, 判断に迷う中堅層に向けて書いています. とかめっちゃ上から目線なこと言ってますけど, 判断に迷いまくってるおっさんの1人がボクです

「すべては場合による」という言葉によって僕がどれだけ救われたか(笑).

多くの若手エンジニアはアーキテクチャについての疑問に対する答えを知りたがっています. 若手エンジニアから「この部分はどうすればいいですか?」と聞かれます. 多くの場合, 僕の答えは「場合による」です. しかし, 多くの若手エンジニアは「場合による」という答えには納得しません.

局所的な部分だけを取り上げて, 「ここはこうすべきだ」と言ってるエンジニアがいます. しかし僕は内心「でもこういう場合はこうすべきだよね?その議論は尽くされているのかな?」と思っていたりします.

きっかけは「同僚のおすすめ」

ソフトウェアアーキテクチャなんて実戦から学べばええやろ, 本とか読んでる奴はアホや!と思っていたことをめちゃくちゃ後悔し, 今年から粛々と本を読むようになった僕ですが, 今回読んだ本はアーキテクチャの基礎―エンジニアリングに基づく体系的アプローチです.

とてもタメになった本だったので, 内容の振り返り, 記事として残しておきたいと思います.

島田 浩二さんが訳した本を読むのは, 「スタッフエンジニアの道」に続き今年2冊目です.

本を読むキッカケは社内での同僚のお薦めでした. 「アーキテクチャを作るなら最低限これは読まなアカンやろ」と言ってたのを聞き, まさか「読んでません」とは言えずに僕は本をこっそり購入し読むことに...

TL;DR

  • 最も大切なことはアーキテクト的なモノの考え方を学ぶこと. この本はアーキテクチャのレシピ集ではなく, トレードオフのレシピ集である.
  • すべては場合による. アーキテクトの役割はトレードオフのバランスを取ること.

感想

本の全体構成はこんな感じ.

  • 1章 イントロダクション
    • アーキテクチャとは, アーキテクトのあるべき姿とは
  • 第一部(2章〜8章)
    • アーキテクチャの決定を左右するトレードオフの紹介
  • 第二部(9章〜18章)
    • 頻出するアーキテクチャスタイルの紹介
  • 第三部(19章〜24章)
    • 他者を説得するための技法の紹介

個人的には, この本の価値は第一部と第三部にある

おそらく第二部が, 皆さんがイメージするアーキテクチャ本だと思います(少なくとも僕はこのイメージが先行していた). コンポーネントをどこどこに配置して, ここでは何ちゃらデータベースを使って, ここは水平スケールできるようにして, ここにキャッシュを入れて, みたいなことやりたいじゃないですか?. でもね...そういう機会はあんまりないんです(悲). 仮にそういう機会があったとしても, 第二部で紹介されているアーキテクチャスタイルを「ほいさ!」と適用して成功できるほど現実は甘くはありません. むしろ, 第一部で紹介されているトレードオフに対する視点が欠落している状態で流行りのアーキテクチャスタイルを知っているだけの状態が一番危険です. アーキテクチャの決定を誤る可能性が高いですし, 一度誤ってしまうと取り返しがつかないのがアーキテクチャだからです(流行りに乗ってマイクロサービスアーキテクチャとか、イベント駆動アーキテクチャにしたのは良いものの, 結果的に自分たちの首を絞めているだけといった状況が結構あったりなかったり...).

第一部には様々なトレードオフが紹介されています. 実際のところ, 現実でアーキテクチャを決定する際にやることは正に, 様々な制約が課されている中で行われるトレードオフの駆け引き, それと, お腹の痛くなるような決断と周囲への説得の連続であったりするからです(泣). 要件と納期があり, そこからアーキテクチャ特性(非機能要件のこと)を特定し, 納期内で現実的に実行可能なアーキテクチャを選択せざるを得ないのです(悲).

僕の見方はやや悲観的すぎかもしれません(笑)

まぁまぁとにかくですね... 基礎知識としてトレードオフを学ぶこと. それを踏まえた上でアーキテクチャスタイルを選択するように! ってことですね.

第三部では, 他者を説得するための技法が紹介されています. そのアーキテクチャである必要性を他者へ理解してもらうこと, これがまた難しい... その他者はエンジニアかもしれないし, 非エンジニアかもしれません. エンジニアであっても, 「アーキテクチャの基礎」を読んでいないかもしれません(どちらかというと読んでいない可能性の方が高いでしょう).

難しい本なの?

難しくはない.

がしかし, 実務経験がない状態で読んだところで, トレードオフが大事なんだよ!とか言われても, なぜ大事なの?状態になってしまうかと...

読み解くためにはそれなりの実務経験が必要かもしれません.

目安としては, SRE, フルスタックエンジニア, バックエンドエンジニア, プラットフォームエンジニアのいずれかとして, 一般的なWebサービス(フロントエンド、バックエンド、データベースから構成される)の開発や保守運用に3年ほど携わったことがあれば大丈夫だと思います.

まとめ

最後にもう一度言いましょう.

すべては場合による. アーキテクトの役割はトレードオフのバランスを取ること