「ソフトウェアアーキテクチャの基礎」 オライリー 2022のまとめ①
- 自身のアウトプットとしてかなり久しぶりだし、質が低いかもしれないが、それは理解度の鏡写しなので質よりもまずは数で行く。
- まず本エントリの記述者である僕のバックグラウンドを述べる。
- 文系からのWeb系のプログラマ職へ新卒入社し、現在までテストや開発に従事している。
- コンピュータサイエンスを学んでおらず、現時点でもなにか体系だって学習したわけではないので、その辺りの知識、つまり基礎が欠落していると言わざると得ない。
- 業務では、既存システムのパフォーマンスチューニングや、既存機能の刷新とそれに伴って再設計などを具体的に行なっている。
- 3年目に入り、体系的に勉強して来なかったことへの焦りや、自身のスキルの伸びを感じられないことが最近の悩みになっている。
8章までまとめるつもりだった…
記述していて無理があると気がついたので、まずは1章までとする。そして理解できていない点も明らかになったので、今後も継続的にエントリを記述していく。
本書を8章まで読んだ今、キーフレーズで主題を表現すると...
それは、「すべてはトレードオフ」だ。
これは本書、すくなくとも8章まで読み進めるなかで、聴き飽きるレベルで口酸っぱく言われるフレーズだ。
そして本書に通底する思想である。
著者の言を借りれば、「すべてはトレードオフで、ベストな選択なんて存在しえないのだから、少なくとも"最悪の選択"だけは避けろ」である。
では、その「最悪の選択」を避けるにはどうすればよいか？ それを各章ごとに学んだことをまとめて、自分なりの解釈を記述していく。
1章：イントロダクション
なぜ本書が書かれたか？
それは凄まじい速度で変化するソフトウェアの世界において、既存の書籍は当時の時代背景や技術のエコシステムに即して記述され、20年前と現在（2022年）においては、まったく文脈が異なっているからだ。本書ではそれをDevOpsなどを例に挙げて、ソフトウェアアーキテクチャは文脈、つまり時代背景とエコシステムの中で初めて理解されることを強調している。
これは「はじめに」の項でも述べられている「公理を疑う」というテーマにも繋がってくる。
ソフトウェアアーキテクチャを扱うには
前述の理由も相まって、現代ではソフトウェアアーキテクト、そしてソフトウェアアーキテクチャの定義は非常に曖昧になっているとする。
著者らはこれらへの答えとして、ソフトウェアアーキテクチャを取り扱うにあたって、4つの構成要素からなるものだと主張する。それは、「アーキテクチャ特性」「アーキテクチャ決定」「構造」「設計指針」だ。
- 構造
- アーキテクチャ特性
- アーキテクチャ決定
- システムをどのように構築するか定めるもの。つまり、各アーキテクチャでその層がどこにアクセス可能かなどという、システムの制約を形成するもので、規律を作り上げるものだと理解した。
- 設計指針
アーキテクトへの期待
本書ではアーキテクトはどうあるべきかについても重きをおいて記述されている。非常に教育的であり、また人間臭く軽視されがちな政治を理解すべきということまでも言及されている。
これはアーキテクトの役割としてソフトウェアのアーキテクチャを考える上で、ドメイン知識のより豊富な人物から情報を引き出したり、営業や顧客のニーズを理解し、彼らとの折衝を担当したり、プログラマのミクロな視線や立場とも折り合いをつけて、彼らが実装する際に設計指針を満たすように協力してもらう必要があるからだろう。
本書ではアーキテクトへの期待されることとして8つ挙げられている。その中でも個人的に印象深く、意識すべきだと感じたものを挙げる。
- アーキテクチャを継続的に分析すること
- こちらは前述のソフトウェア業界の凄まじい速さでの変化に関連してくる。例えばあるシステムがあったとして、それが5年前に構築されたもののままであったらどうだろうか？もっと言うと10年前なら？そのような、全く変化していないシステムは少ないかもしれないが、もしそのシステムがあったら、すぐにでもアーキテクチャが見直されるべきだろう。結果として似たアーキテクチャに落ち着くかもしれないが、とにかくそのアーキテクチャが「最悪の選択」でないことは継続して、かつソフトウェアアーキテクトであるならば、常に検証し続けなければならない、と本書は説いている。
- そして、その際にアーキテクトが忘れがちな要素に、テストやリリースのための環境を挙げている。本記事を書いている僕自身の経験にリリースの遅れによって顧客からの不満が上がってきたり、テストのコストが掛かりすぎてリリースが迅速に行えず、機会を逃した経験がある。そのため、このテストとリリースのより良い環境構築の重要性には特に納得させられ、意識づけられた。
「どうやって」よりも「なぜ」
決定された事項に関して、アーキテクトはどうやって構造が機能しているかは解明可能であるが、「なぜ」その決定がなされたかは推測し導き出すことは難しい。だからドキュメントを残すにしろ、アーキテクチャ決定を為すにしろ、なぜその選択をしたかを残し、説明可能にしておくことは重要なのだと理解した。
参考文献
ソフトウェアアーキテクチャの基礎 Mark Richards, Neal Ford 著 島田浩二 訳 2022/3/4 株式会社オライリー・ジャパン
