という訳で、読書ノートである。書籍の紹介と自分のチラ裏ポエムを兼用する形でポストしていく。
サマリ
- ソフトウェアアーキテクチャを選択した時、そこに有るのはトレードオフだ。
- ソフトウェアアーキテクトはソフトウェアアーキテクチャを決めてガイドする。
- 少なくとも自分は、何気ない日々の意思決定がトレードオフの選択であることに改めて気付かされた
書籍の感想
3部24章。読んでいる途中で「これは本当に基礎なのか？」と思いつつ、読み終わってから「いや、確かに基礎だ」と思い直した。この場合の基礎というのは「簡単」「入門」からは少し遠い単語ベクトルであって、「実務を抽象化して理解し実践するための前提知識全部」という感じ。
「ソフトウェアアーキテクチャ」自体の定義が難しいことは本書でも語られている。その上で本書はⅢ部構成をとって、第Ⅰ部でソフトウェアアーキテクチャを考える上でのメタ的な基礎、第Ⅱ部では実際に存在するソフトウェアアーキテクチャのスタイル、第Ⅲ部ではソフトウェアアーキテクチャをソフトウェアアーキテクトとして決めていくためのテクニックが紹介されている。
当たり前だが「ソフトウェアアーキテクト」というロールは「ソフトウェアアーキテクチャの基礎」とは切っても切り離せない。本書は勿論ソフトウェアアーキテクトに対するガイドとしても書かれている。
面白かったポイント
いったん個人的な感想ポエムは後半に追いやり、読書ノート的に面白かったポイントを書き記していく。だいぶ絞ったが多くなってしまった。ここに書かれている内容に少しでも「お？」となるなら本書を読む価値はあるだろう。
- (22.1)ソフトウェアアーキテクトの役割は、開発者のためのちょうどいい箱（制約の境界）を作ることである。
- (1.2.1)アーキテクトに期待されている役割において重要なのは「ガイドする」ことだ。チームの技術的な選択を「指定」するのではなく「ガイド」しなければならない。
本当にそう。指定するだけでなくガイドする役割がないと形にならない。
ドキュメント系。最近「なぜ」を示すためのインフォデッキを意識的に作る事が増えたのだが、実際に効果を感じている。
いわゆる非機能要件は暗黙的かつ優先度を付けるしか無いもの。わかる。
ノウハウ系。わかる。PaaSを組み合わせたようなアーキテクチャを組むようになってからネットワークを意識することが増えた。
ソフトスキル系。わかる。それ故にソフトウェアアーキテクトは実装する機会が減っていく…
- (1.0)アーキテクチャとは、文脈の中で初めて理解できるものだ。
これは本当にそう。個人的には哲学とかの人文系と一緒で、コンテキストが無いと何故そうなったのかが理解しづらかったりする。
より個人的な感想
近年の自分はざっくり、小さなB2BプロダクトのPdMっぽい仕事をやっている。といいつつ何でもやるのでMVPを作ることも有るし「今回の構成ならDBはPaaSに任せるか、いやそもそもRDB要らないかな？」みたいな判断はやることがある。
そんな感じなのだが、実は自覚的にソフトウェアアーキテクチャを選択してきたことは少ない気がする。ある程度チーム内で実績のあるカタ(型)を基本にして「次はこれやってみるか」で時折新しいものに手を伸ばすことが多かった。なんならパッケージ製品をやっていた頃は、最初からある程度パッケージ側でアーキテクチャが決まっていて、表面化している非機能要件だけを拾ってすり合わせするような仕事も多かった。実はそういう現場も世の中には結構あるのではないかと思っている。
ソフトウェアアーキテクチャの選択に大して常に自覚的でいられるか
最近は幸い「顧客にこの機能を使ってもらうために、ここをこうして非同期にしたい」みたいな議論をすることが増えたので、本書の内容は自分が何を意識すべきなのか、を再認識できた。いっぽうで思い返してみればアーキテクチャの選択そのものは今までのキャリアでも何度も有った訳で、今までその選択に自覚的でなかったのかもしれない、というのも本書を読んだ気付きだった。
