システム設計の先導者 ITアーキテクトの教科書 の感想

この本には、「ITアーキテクトが各フェーズで何を考え、何をしているのかを明らかにするのを目的とした」本と
と書かれています。
読むと上記のとおり、
要件定義から検証（テスト）までだけでなく、保守開発や再構築のフェーズも含めて、
各フェーズで作成すべき成果物とその内容が書かれており、その点は参考になりました。
ですが、
各成果物をどのように作ればよいかの具体的な手順の部分がとても薄く、
これを読んでも作れる気はしませんでした。

また、アーキテクチャ設計の評価手法としてATAM、
保守フェーズでのアーキテクチャ改善の評価手法としてCBAMが紹介されていますが、
これも説明の量が少なく、参考になりませんでした。

アーキテクトの全体を把握するのには使えますが、
実際にアーキテクトを行っていく中では、使えないと感じました。

本書は、日経SYSTEMSに連載されていた「ITアーキテクト養成講座」をベースに加筆・修正したものです。
著者の所属会社などから推察出来るとおり、本書の内容は受託開発などSIerでのビジネスモデルを前提としたものです。
このため、詳細設計工程がやけに大仰で、プログラマに過度の期待をしていないのかなという印象です(日経SYSTEMSの読者層からもそんな感じ)。
この辺りの考え方は、内製・少数精鋭・プログラマ主導を前提としたWebサービス系の企業では、受け入れづらいかなと思われます。

とはいえ、ITアーキテクトという職種・役割については大きく変わるものではないはずですので
Webサービス系の企業でアーキテクトの立ち位置を目指す人にも、本書は有用です。
特に以下のような考え方は、私の中でのITアーキテクトの定義・立ち位置を明確にするうえで役立ちました。

・プロジェクトマネージャはリリースまでのプロジェクト期間が責任範囲だが、
　ITアーキテクトはプロダクトのライフサイクル全般(運用->改修->廃棄までを含む)が責任範囲。
　このためリファクタリングなどの、プロジェクトマネージャからすると無駄なタスクについても
　アーキテクチャを維持するために必要であれば、関係者を説得して執行する必要がある。

・共通コンポーネントやフレームワーク構築のために重要なのは「不要な自由」を取り除くこと。
　個々の機能を実装するプログラマが不自由を感じてはならないが、自由すぎても実装手段に迷いが生じる。

ここでのITアーキテクト像はIPAの「システムアーキテクト試験」の対象者像に近いので
本書は特に、この試験を受験しようと考えている人におすすめです。