アーキテクチャをデザインするにあたって、パフォーマンスや柔軟性など多数の観点から考えなければならないことをひたすら体系的にまとめた本でした。 パフォーマンスや組織など多数の観点について、図示の方法、チェックリスト、主な落とし穴などがまとまっているので、じっくり1回読んで終わり、ではなくどんな本かさらっと目を通した後は、気になったときに辞書的に使うのが良いかと思いました。 実は、例えばある処理を実現する場合には A と B の間にキューを挟むといい、というようなアーキテクチャデザインについて学ぶことを想定して買ったので、失敗したと思いましたが、読んでいくうちにすごい本を見つけたと思うようになりました。 私は、規模は非常に小さいですが、仕事で0からのシステム設計を主導する際に、手探りで行き当たりばったりになりながらも、回数を重ねるうちになんとなく自分なりの型を見つけて、型をブラッシュアップしつつシステム設計を進めていました。 自分なりの型が見え始めた段階でこの本が読めていたら、効率的に自分なりの型がブラッシュアップできたなと思います。 初めてシステム設計をする段階だと書いてあることが抽象的でピンと来ず、読むのも辛いぐらいだと思いますが、自分なりの型が見え始めた段階以降でこの本を読むと学べる部分が多いと思います。

私の知る限りでは、日本のITプロジェクトでは、アーキテクトという役割を専任で行うことはあまりない。大体が、要件定義、設計、コーディング、テスト、運用というフェーズごとに責任者、担当者がアサインされており、PMが全体を見る形である。 本書で説明されるアーキテクトは、主に要件定義から設計につながる部分で、問題空間と解決空間を調整しながら結びつけるのが大きな役割で、プロジェクト全体を通して解決策がユーザーの問題に適切に対処しているかを監視する。確かに、ここの役割をおろそかにすると、特にウォーターフォール型開発では、上流からのインプットを完全に正しいとして突き進み、いつの間にかユーザーの要望から乖離してしまう、ということが起こりがちだろう。 というわけでアーキテクトという役割が大切なのだが、この人が責任を持つソフトウェア・アーキテクチャを正しく構築するには、どのような観点で検討すればよいのかを、ビュー（視点）とパースペクティブ（側面）という分類でうまく整理している。やっぱり、PMBOKなどを生み出すだけあって、欧米は知識を体系的に整理するのが上手だ。こういうフレームを参照すれば、アーキテクチャにおける考慮モレは減り、より良いシステム構築につながると思った。