msksgm’s blog

msksgm’s blog

Webエンジニアです。日々の勉強記録、技術書感想、美術観賞感想を投稿します。

「ソフトウェアーキテクチャの基礎」感想

概要

ソフトウェアアーキテクチャの基礎」を読みました。 「前提」「読了時間」「感想」「次に関連で勉強すること」「まとめ」を記述します。

前提

目的

主な目的は以下です。

  • 普段の業務で、設計について意思決定をする機会が多いので、設計の知識についてインプットできる本が欲しかった
  • 知人と設計の書籍について学ぶ勉強会を週一で開催しており、知人からの提案で課題図書になった
  • 近年発売された書籍で現代の課題について学べそうだった。過去の勉強会で読んだ書籍は 2000 〜2010 年代の時代背景の本が多かった

前提知識

設計関連で過去に読んだ書籍を紹介します。

他の、技術的な側面を主題とした書籍は以下です。

チーム的な側面を主題とした書籍は以下です。

DDD を主題とした書籍は以下です。

書籍以外では、普段の業務で「設計標準」と呼ばれる決まりごとを提案・導入・運用しています。 「設計標準」とはチームの課題について、議論して新しく標準として導入することです。 導入して 4、5 ヶ月ほど経過しています。良かった面もありますが、決まり事を守る難しさを実感しています。

読了時間

知人と勉強会を計画し、8 週間で読み切りました。 一度につき、準備に平均 3.5 時間、勉強会は 2 時間程度でした。 そのため、5.5 * 8 時間で 44 時間ほどかけて読み切りました。

感想

本書は、ソフトウェアアーキテクチャの第一法則「ソフトウェアアーキテクチャトレードオフがすべてだ」に乗っ取り、さまざまな観点からアーキテクチャについて評価できるようになる本でした。 どのような状況とアーキテクチャにおいても、「場合による」を一貫して貫き、偏った知見にならないように教えてくれます。 それは、ソースコードやハードウェアに限らず、アーキテクトとしての振る舞いや集団との関わり方についても同様でした。 この書籍を読むことで、「アーキテクチャ」についてモダンな見識を広げられるようになります。 良かった点と気になった点をそれぞれ挙げていきます。

良かった点は 3 つあります。

1 つ目はアーキテクトがあるべき振る舞いについて記述されていることです。 書籍では開発者とアーキテクトが別の役割として、説明されます。 例えば、次の文言があります。

プログラマーは利点はわかっているが、トレードオフはわかっていない。アーキテクトは両方を理解する必要がある」。

そして、開発者からアーキテクトになると技術的な深さよりも技術的な深さが重要になります。 また、アーキテクトは対人スキルを持ち、社内政治を理解する必要があるとも記述していました。
私は、アーキテクトはより技術的な見識が深い人がなるものだと思っていたので、これについて価値観が異なり驚きました。どちらかといえばエンジニアリングマネージャーの役割だと思っていたからです。 しかし、本書を読むことで、アーキテクチャの第一法則に従うと、トレードオフを考えられない場合は、本当の意味で理解していないことに気がつきました。 普段、第三者に設計について述べるときにはトレードオフを意識して話せていないので、これからはかならずメリットとデメリットを述べるようにしようと考えました。

2 つ目は、幅広いアーキテクチャについての紹介があることです。 レイヤードアーキテクチャから始まり、マイクロサービスで終わるアーキテクチャの紹介は、10 章にも渡ります。この章を読むことで、確実にアーキテクチャ知識の裾を広げられます。 中には、マイクロカーネルアーキテクチャやスペースベースアーキテクチャといった全く知見の無いアーキテクチャの紹介もありました。 「現場で使っているアーキテークチャはこのアーキテクチャだ」「現在のアーキテクチャにはこのようなメリットがある」と考えることで、メリットデメリットを理解できました。 関連して、現在は負債になっているようなアーキテクチャでも過去にはベストプラクティスの選択肢の 1 つだったと思えるようになりました。

3 つ目は、アーキテクチャの意思決定やうまくいくためのテクニックとスキルについてです。 特に印象に残ったのは、ADR、リスク分析、チームについてです。どれも自身の抱えている課題に対して役立ちそうだと思ったからです。
ADR は、アーキテクチャの意思決定の過程でドキュメント化しづらいものはスナップショット的にまとめるのは良いと思いました。何が有効なのかと同じぐらい何が無効なのかわかるのは非常に重要だと思いました。
リスク分析は特に刺さりました。さまざまなアーキテクチャを提案してきましたが、ステークホルダーが本当に気にするリスク分析をマトリックス化してまとめて来たことがなかったからです。現在、リプレイスを提案しているので、この本で記述されているリスク分析は必ず早めにやろうと思いました。
最後にチームについてです。チームビルディングについて何度か行ってきましたが、本当にバランスの良い状態になったことはありません。意図的に介入するのも、しないのも良いアーキテクトの役割と知り、実践できないかと思いました。

気になった点は 2 つあります。どれも本の評価を下げるほどのものではなく、個人的に感じたことです。

1 つ目は対象読者の層がよくわからなかったことです。 「基礎」というには幅が広く、「アーキテクトになってから」は遅く感じました。 例えば、アーキテクチャの種類を紹介する章では、ニッチすぎるように感じるものも紹介されていました。しかし、ソフトウェアアーキテクトがどうあるべきかは早い段階で知るべきだと思いました。 あえて言うのならば一瞬でもアーキテクトの知見が欲しければ必読の本だと思いました。

2 つ目は、図の読み取り方がよくわからない箇所が何個かありました。 致命的にわからない図はなかったですが、例えば、図 1-2 から図 1-6 は縦軸と横軸の意図が読み取れませんでした。 文章をうまく図に起こせているとは思えない部分があり、何度か戸惑った印象があります。 あくまで知人と自分の見解なので、自分だけの可能性があります。

次に関連で勉強すること

次は「Google のソフトウェアエンジニアリング」を読もうと考えています。 この書籍を読み終えたら、一旦は設計関連の勉強は終わりではないかと考えています。 または、ソースコードよりの書籍を読もうと考えています。

まとめ

本書籍では、ソフトウェアアーキテクトの幅を広げられる本でした。 主に以下について学べました。

  • ソフトウェアアーキテクチャの第一法則「ソフトウェアアーキテクチャトレードオフがすべてだ」について
  • アーキテクトが、技術的な知識、ビジネス的、チーム的にどうあるべきなのか
  • アーキテクトをうまく運営するための方法について