とても良い本だ!アーキテクチャのパターンは体系的に整理されているし、アーキテクチャを議論する上で、共通の語彙となり得る用語を解説している(コンウェイの法則や、凝集度など)。
後半は、リスクや、チームビルディング、交渉術まで多岐に渡るトピックを網羅している。
必要なことは全部書いてある...けれど、なんとなく初めてPMBOKを読んだときに抱いた感想...読み始めてからすぐに「果たしてこの本に書かれている通りの考え方に沿って振る舞えばアーキテクトになれるのか?」という気持ちになりはじめたところで1章の最後の方に出てくる「ソフトウェアアーキテクチャの法則」が出てきて、「そうだよなー」という気持ちに。
つまり、ちゃんと考えようということでした。
というわけで、この本を読んでどうこう、というより、この本に書かれていることをきっかけに考えたり、書かれていることを例示に先輩から経験や教訓を引き出したり、誰かを教育する時にトピックの網羅性を考えるときに使うと良いのではないでしょうか。
あと、4章の最後に出てくるこの言葉は良かったですね、こういう考え方でいかないと何も先に進まない。
経験に裏打ちされた色々なトピックが出てきますが、いたずらに「正しい」と盲信してはいけなくて、「考えるきっかけ」とか、自分の考え方を「わかりやすく、つたわりやすく」表現するためのネタ本として使うと良いんじゃないかなーと思います。
ちなみに、自分だったら、アーキテクトには、こんなことを決めてほしいと思っている。正解ではなく、指針をもたらしてほしい。
アーキテクトの役割の一つに「守らなければいけないこと」「原則こうしてほしいこと」「トレードオフを理解して例外的に守らない時に気をつけること」を理解してもらうための活動が有る
— magnoliak🍧 (@magnolia_k_) 2022年4月9日
アーキテクトが権威的であってはいけないと思うんだ https://t.co/9m3PVO7O3s
— magnoliak🍧 (@magnolia_k_) 2022年4月9日
アーキテクトが居ることで、全体における「一貫性」「生合成」がもたらされる
— magnoliak🍧 (@magnolia_k_) 2022年4月9日
そこらじゅうに個別に、個別最適な仕組みを作り込むのはアーキテクトが居なくてもできると思うけど、それじゃあねぇ