既にいくつかのシステム設計を行い、それらを完成させている。
世間では、アーキテクトという職種がもてはやされているし、
自分自信、ＰＭなどよりはアーキテクトの肩書きがしっくり来る。
しかし、アーキテクトが具体的に何を考え、何を行う職種なのかイメージが湧かない。

この本は、上記のような読者にこそ読んでもらいたい。

まずは第１章から第５章までを通読することをお勧めする。
ステークホルダ、ビューポイント、パースペクティブと
その周辺概念についての理解を深めていく中で、
これまで漠然としたイメージで語っていた、アーキテクチャやアーキテクトというものの
具体的なイメージが、読者の中でかなりクリアになっていくはずである。

アーキテクチャ記述言語に依存しない記述になっている。
抽象的記述にしたためか、ソフトウェアのアーキテクチャとは何かが明確になっているわけではない。

利用者にとって重要なのは、ソフトウェアのアーキテクチャではなく、システムのアーキテクチャではないだろうか。
システムのアーキテクチャの中で、ソフトウェアがどういう役割を果たすとよいかは変動的だろう。
ハードウェアのアーキテクチャの変更があるかどうか、ハードウェアの構成に変更があるかどうか、利用者の利用方法に変更があるかどうかで、ソフトウェアのアーキテクチャを検討するのではないか。

P18で、アーキテクチャで責務が必要なのはよくわかる。
しかし、境界とインタフェースの違いがわからなかった。

全体を通して、ビューとパースペクティブの関係もよくわからなかった。
階層的なビューではなぜだめなのだろうか。

疑問がたくさん残った。

アーキテクチャが貧弱なシステムは開発も保守もしにくく、品質も往々にして良くない。
反対に入念に設計されたシステムは開発も保守も容易で、品質も高い。

これまでの業務経験上、アーキテクチャの重要性を痛感する事が非常に多かったので、アーキテクチャ設計には高い関心を持ち、色々な本を読んだりして勉強してきました。
しかしこの本には自分の中にあった知識のほぼすべてが網羅されている上、これまで気付いていなかった重要な視点やプロセスについても説明されています。
たとえば私の場合、ステークホルダをここまで広範囲にとらえてはきませんでした。
しかしよくよく考えるとシステムを開発し運用していく間には様々なロールを持った人が関わっていることに気付かされました。

システムを設計・開発する際はこの本を手元におき、各章末にあるチェックリストを参考にしながら重要なポイントを考慮し忘れていないか検証していけば、システムのリリース後に大きなトラブルが発生する確率は激減するでしょう。

経験や試行錯誤だけででここまで網羅的なアーキテクチャ設計思想を身につける事は不可能です。
システムを設計する立場にある方はこの本の内容を熟読し、システムに関わるすべてのステークホルダを幸せにしてあげてください。

アーキテクトを担っている方、これから目指す方どちらにも是非とも読んで頂きたい「アーキテクトの思考プロセス」のベストプラクティスです。

本書のチェックリストをシステム提案、計画時に活用すれば手戻りも減る事でしょう。

ソフトウェアシステムのアーキテクチャ設計における、視点・原則・戦略・記述法が体系的に説明されている。アーキテクトはもちろん、システム構築に携わる他のステークホルダなど意思決定に携わる全ての方に読んでもらいたい。とは言え、書かれていることがいつも完璧に実践できることはありえず、プロジェクトとは常に妥協点を見出しながら進めていくわけである。しかしながら、ここで述べられているような視点・原則を身に付けていることで、限られた時間制約の中でよりベターな意思決定ができるのではないかと思う。原理を学んで、より優れたシステム構築を実践しよう！でも現実世界はやっぱり厳しいなあ。。。