ソフトウェアアーキテクチャの基礎 の商品レビュー

Mark Richards(著者),Neal Ford(著者),島田浩二(訳者)

2026/02/25

アーキテクチャについて何も知らなかったので，少なくともどんな概念があるのかを知ることができたので，読んでよかった．１５〜２０章は一旦飛ばした．今後事あるたびに手に取る気がする
Claude Codeを動かす時になんでそのアーキテクチャを選んだかの説明（ADR）も，必要に応じてログに残すようにした．

2026/01/11

アーキテクチャについて、個別に知っていた知識が線で結ばれた、知らなかったことを知れた感じがした。知識の偏りをうまく保管しつつバランスが取れた感じになり、システムの意図を理解することが楽になった。
アーキテクチャってそもそも何なんだろ？と個人的にモヤモヤしていたことも、この本を通じてある程度考えがまとまった。
また、トレードオフの大切さも改めて認識した。

2025/08/04

横文字、カタカナが多くて理解しながら読むのが苦しかった。優れたアーキテクチャには、正解が無くトレードオフで成り立っている事の重要さ、それぞれのアーキテクチャの区別とメリデリ（かなり詳細な技術的な内容なので読んでて凄く眠くなったw）、そしてビジネスや交渉力の観点からみたアーキテクトの立ち回り方がそれぞれ詳しく書いてありました。一見ベテラン向けの本ではありますが、開発者目線で読むのも楽しいです。

2025/03/31

ソフトウェアアーキテクトの重要性。20年前はマイクロサービスアーキテクチャの実現には高額なライセンス料金がかかったが、OSSの台頭によりDevOpsの概念が生まれ、ソフトウェア産業が変革していった。アーキテクチャは構造、アーキテクチャ特性、アーキテクチャ決定、設計指針から構成される。アーキテクトに求められるのは深さより幅。アーキテクチャは様々な要素のトレードオフの上に成り立っている。メトリクスは結合度を洗練させたコナーセンス、抽象度、不安定度…。各種コナーセンスを強さ順に並べ弱い方からリファクタリング。コード構造のメトリクスである循環的複雑度CC。CC≦5が望ましい。システム設計する組織はその組織のコミュニケーション構造を設計に反映してしまうというコンウェイの法則。アーキテクチャの分類: モノリシック(レイヤード/パイプライン/マイクロカーネル)、分散(サービスベース/イベント駆動/スペースベース/サービス指向/マイクロサービス)。サービスベースはACID、マイクロサービスはBASEトランザクション。面白いと思ったのはアーキテクチャのプレゼンテーション(説明方法)にまで言及していること。段階的に全体像を見せていく。終盤は開発プロジェクトにおけるアーキテクトの振る舞いや握手の仕方に至るまで具体的な議論していて興味深い。肩書きでものを言わずに手本を示す。

2025/02/24

ソフトウェアアーキテクトという職種が気になっているので読んでみた。
本書のイントロダクションにょると、『「ソフトウェアアーキテクト」という職種は、世界中で最高の職業リストの上位に入っている』とのこと。
日本ではまだまだソフトウェアアーキテクトという職種は一般的ではないのだけど、もっと知名度が上がらないかなと思う。

ただ、本書自体は理論的で抽象的な話が多く、少し分かりづらかったかなという印象。ソフトウェアアーキテクトになれた時に見直したら、また違って読めるのかもしれない。

凝集度というのは、それこそ基本情報の勉強をしていた15年以上前から聞いたことはあったのだけど、細かい違いはよく分かってなかったと最近気づいた(そもそも、「ギシュウ」と読んでいた…)。凝集度も意識してコードを書けるようになりたい。

「コナーセンス」という言葉がよくでてきたけど、いまいちよく分からなかった。ようは、結合度や変更容易性についての指標(メトリクス)なのかな？　もう少し調べてみたいと思った。

アーキテクチャ特性という言葉はたまに聞くけど、ようは「非機能要件」のことなのかということを理解できた。「イリティ」という言葉は最近何かの本で読んだけど、覚えておいたほうがよさそう。

循環的複雑度は単純だけど、なかなか計算式を覚えられそうにない。ESLintを使ったらJavaScript(TypeScript)でも、自動的にチェックできたりするのだろうか。

それぞれのアーキテクチャスタイルの違いは、なかなか覚えられそうにないけど、こういうのも意識できるようになったほうがいいのだろうな。
「サービスベースアーキテクチャ」や「マイクロサービスアーキテクチャ」が良さそうなアーキテクチャだそうなので、もう少し調べてみようと思った。

アーキテクトのパーソナリティについての「コントロールフリークアーキテクト」と「アームチェアアーキテクト」の話が面白かった。厳しすぎるのも、ゆるすぎるのもどちらも悪いことなんだろうな。
意外だったのが、期間が短いプロジェクトはゆるい「アームチェアアーキテクト」のほうがいいということ。むしろ期間が短いほど、厳しい「コントロールフリークアーキテクト」のほうがいいと思ってた。

後、チェックリストはやっぱり重要なんだろうなと。特に、リリース作業にあたってはチェックリストを作っておいたほうがいいのかも。あまり、自分の記憶は信用しないほうがいいのかもしれない。

最後のほうに、アーキテクトのカレンダー(というより、スケジュール)についての話があったけど、やっぱりアーキテクトになるとミーティングでいっぱいになるのだなと思った。日本企業には会議が多いといわれるけど、アメリカでも似たようなものなのかも。このへん、うまく減らせたらいいんだけどね。本書でも必要悪とは書いてあったけど。

2024/03/30

https://blog.masterka.net/archives/4141
https://blog.masterka.net/archives/4237
https://blog.masterka.net/archives/4253

2023/09/24

組み込みしかやってないので内容がわからないところもありましたが、そういう世界もあるんだなーと楽しめました。

2023/07/22

各アーキテクチャスタイルのトポロジー説明、およびアーキテクチャ特性評価をまとめた表がわかりやすく、非常に参考になった。
「ソフトウェアアーキテクチャはトレードオフがすべて」という法則（場合による）は、よくよく頭に入れておきたい。

2023/02/13

やたら評価高かったから読んだ

エンジニア3年目の自分には少々ハードな内容だったけど、評価の高さがわかる充実度だった

初オライリーだったので読むのにちょっと苦労した
結構な情報量ではあったが、基礎というだけあって知っておいた方がいい知識であることは間違いないなと思った
個人的に最後の方のソフトスキルの話が好きだった

2022/12/24

すべてを理解したわけでは決してないけど全体俯瞰して飲み込めた気がする。
モノリシックより分散型の方が断然良いと過信していたが、ネットワークの信頼、分散ロギング、分散トランザクションについて誤信していた。
マイクロサービスでもデータ分離と通信、トランザクションが頭痛の種となる。いずれも境界をどう区切るか十分に検討すべき。サービスベースアーキテクチャか。
アーキテクチャ選定でリスク分析にはリスクストーミングという方法がある。
アーキテクチャの図解やプレゼンスキルはカミソリのように磨いておく、なるほど。。
370冊目読了。