「ソフトウェアアーキテクチャの基礎」勉強会を終えて
知り合いの集まりで約2週間に一度リモートで集まって、技術書を読む勉強会を友人と合同で主催しています。今年は、4月から12月にかけて「ソフトウェアアーキテクチャの基礎」を扱いました。
自分の振り返りとして、書籍の感想と、勉強会の感想を書きます。
書籍の感想
書籍全体としての感想は、アーキテクトだけでなく、エンジニア全体に対しても意味のある良書だったかなと感じます。
同じ著者の最新の本に「Software Architecture: The Hard Parts」という本があり、私はそちらも読んでおり、被っている内容も多いのですが、個人的には「ソフトウェアアーキテクチャの基礎」の方が好みです。
「ソフトウェアアーキテクチャの基礎」では、具体的なアーキテクチャパターンの紹介や、チームにおけるアーキテクトの振る舞い方なども解説されており、このようなアーキテクチャ論の本の中では読み応えがあって、勉強会で議論するにも良い内容でした。もし、レガシーシステムをモダンなアーキテクチャにしたい、という課題を持っている人であれば、「Software Architecture: The Hard Parts」がおすすめです。
この本は、「I部:基礎」、「II部:アーキテクチャスタイル」、「III部:テクニックとソフトスキル」という3部構成で、アーキテクチャやアーキテクトについて網羅的に解説しています。以下では、それぞれの部のざっくりとしたサマリと感想を書きます。
I部: 基礎
I部では、まずアーキテクチャを検討する際の大原則が語られています。いくつかありますが、最も重要なのは、アーキテクチャに絶対的な正解はなく常にトレードオフがある、ということです。
システムのアーキテクチャは、概ねモジュールの区切り方を考えることであり、その区切り方でシステム特性(-bility)が異なります。そこに前述のトレードオフが発生するのですが、運用面なども含めた様々な角度から、アーキテクチャは意思を持ってアーキテクチャを選択します。
その選択をした後も注意が必要で、エンジニアが実装していく過程でアーキテクトの意思決定（いわゆる"思い"）から実際のコードが乖離していっては、せっかくの選択の意味がありません。それに対し、本書では、しっかりアーキテクトの意思に沿っているかを捉えるため、計測をしよう、という内容が書かれています。
この計測まで出来ている組織は、かなり少ないのではと思いますが、この本の中では、「基礎」という位置づけなのが興味深いです。これまで私の経験した組織だと、組織内に中心的な人物がいて、その人が長期間その組織にいることで、他のエンジニアの精神的な支柱にもなっており、対面的なコミュニケーション（場合によっては飲みニケーション）でそのシステムのフィロソフィーが伝承されたり、その人が社訓のようなドキュメントを書いたり、その人が全てのコードレビューを行って適宜軌道修正をする、というケースなどを見てきました。
この本のように、自動化可能な計測によって、ロジカルにアーキテクトの意思をシステムに根付かせるやり方は、なんとなく米国らしさ感じを受けましたが、人材の流動化が昔よりは進んでいる日本としても、計測が難しい部分はあると思いますが、必要なことだろうと思います。
II部: アーキテクチャスタイル
II部では、アーキテクチャに関するよくある（？）誤った考え方を振り返った後で、実際に過去から現在までに採用されてきたアーキテクチャパターンを整理しています。
誤った考え方の話題は、システム開発に従事したことがある人なら比較的一般的な話に思います。ただ、アーキテクチャパターンの話題については、近年のマイクロサービスアーキテクチャは一般的なものの、それ以前の過去に採用されていたアーキテクチャとそのアーキテクチャのトレードオフの整理は、個人的にも知らなかったことも多く、かなり参考になりました。
勉強会では、それぞれのアーキテクチャパターンが、自社で使われていた、や、どういった理由で使われなくなった、今もこういうところで使われている、と言った話を、DBのライセンスが高かった時代とOSSが一般的になった時代の変遷や、ESB(Enterprise Service Bus)を取り巻くSIerの失敗の歴史なども含めつつ議論出来ました。
個人的な趣味としては、スペースベースアーキテクチャが、複雑ではあるものの、スケールアウトに極振りしている感じが興味深いです。前職で、このスペースベースアーキテクチャを前提にしたプロダクトを扱っていました。通信やエネルギー分野の社会インフラの基幹システムで採用されています。
オーケストレーション駆動サービス指向アーキテクチャ、いわゆるSOA (Service Oriented Architecture)は…、よほどのことがない限り、やめたほうが良いだろうな、という印象です。
III部: テクニックとソフトスキル
III部は、チームにおけるアーキテクトの振る舞いなどの、オペレーションに関する内容です。
前述の通り、アーキテクチャ決定は決定論的ではなく、常に様々な視点からのトレードオフを踏まえた検討になるため、"人"の判断となります。また、その決定は、プロジェクトに関わる、ひいてはその会社に関わる多数の人の命運を左右するので、様々な人との議論を重ね、決定される、ある種属人的なものだと思います。
そのため、有効な議論ができることは、アーキテクトに必須のスキルであり、このIII部ではそうしたソフトスキルとして、リスク分析の方法論であったり、プレゼンのやり方など、多数のアドバイスが示されています。
また、アーキテクチャの一貫性が、プロジェクトが進んでも維持されるように、アーキテクチャの効果が劣化するので、その維持をさせる手段として、ADR (Architecture Decision Record)にも触れられています。
効果的なチームの構成や、チーム内で起きうる不協和音、どうしたらチームにアーキテクチャ決定を浸透させるか、と言ったマネジメント的な話も触れられています。
マイクロサービスの開発者であっても、ある程度は、組織全体を見通し、個々人がSREのような視点を持つことが重要だと思います。アーキテクトに限らず、この章の内容は参考になり、またそれが実践できるチーム・組織にしていくことが重要に思います。現職のチームでも、昨年くらいから、大きなアーキテクチャ上の決定がなされた時は、ADRを書くようにしています。
勉強会としての感想
勉強会は、私と友人がそれぞれ知り合いで興味ある人を募って、隔週ペースで、読書会（or 要約会）として実施しているものです。
この本を読むことになった背景は、元々この本の前に読んでいた、Systems PerformanceというLinuxのパフォーマンス改善に関する名著が、かなり具体的かつレクチャー色の強い内容だったので、今回はオープンなディスカッションができるような本にしよう、ということでこれになりました。
その狙い通りの内容で、「参加者の会社ではどうやっているか？」や、「この本ではこう書いているがこういう考え方もあるのではないか？」といった議論もできて、面白い勉強会だったかな、という印象です。
本書は、アーキテクチャ論の書籍では評価が高いものですし、議論がしやすいという意味で、勉強会・読書会と言った場面で利用しやすいと思います。
ちなみに、来年は、Googleの「サイトリライアビリティワークブック」を勉強会で読む予定です。
Discussion