全てのアーキテクトに読んでほしい - Architecting Software Intensive Systems [arch]

やっと，やっとこの本を紹介できる日が来た．
「鉄板」である．自信を持って紹介させて頂こう．

Architecting Software Intensive Systems: A Practitioner's Guide Anthony J. Lattanze

著者の Anthony Lattanze は，CMU (Carnegie Mellon University: コンピューターサイエンスの名門・コンピューターサイエンス部門では2009年全米大学ランキング3位) の教壇に立つ一方で，SEI (Software Engineering Institute: ソフトウェアに関する最も権威ある研究機関の1つ・CMM やプロダクトラインの開発などが有名) のシニアメンバーを務める．ちなみに CMU と SEI は密接な関係にある (SEI は CMU のキャンパス内にあり，CMU によって運営されている) が，両者のスタッフを務めるのは現在彼1人である．

…などと書くと「理論ばかりのアカデミック・アカデミックした頭でっかち」という印象を持つかもしれないが，私に言わせれば Lattanze ほど現場の感覚を合わせ持った研究者はいない．というのも，元々彼は実企業で15年の経験を持つ叩き上げで，現在は世界中で企業のコンサルを行う傍ら，市場の製品を受注し自身で設計・実装している．先日 CMU が優勝した無人車レースではナビゲーションシステムを担当し，Google がスポンサーのロボットを月に飛ばすコンテストでも実装を担当している．現在もバリバリにコードを書く，筋金入りのアーキテクトなのである．

実はこのブログに何度も登場している「某 SEI アーキテクト」とは全て彼のことである．以前書いていた ソフトウェアアーキテクチャのエントリー も，彼から学んだことを，本人の許可を得て掲載したものだ．

私は光栄にも本書の監修の一部を依頼され，ちょうど去年の今頃から半年あまりかけて本書の原稿をレビューした．まだ原本を読んでいないので，どれだけ私の指摘が反映されたかは分からないが，少しでも本書の出版に貢献できたとしたら，これ以上の喜びはない．



内容について紹介すると，本書は大きく3つのセクションに分かれている．

セクション1は，ソフトウェアアーキテクチャについて抑えておきたいコンセプトが網羅されている．イメージとしては，SEI のシリーズでありアーキテクトのバイブルとされる Software Architecture in Practice (実践ソフトウェアアーキテクチャ)

のエッセンスを抜き出し，その内容をさらに進化させたものと言ってよいだろう．SEI のシニアメンバーでありながら，SEI が提唱している一部の理論については「考えが古すぎる」「現実に即していない」と自身のスタンスを貫いてきた彼が，ソフトウェアアーキテクチャの基礎を紐解いている．

セクション2は，本書の真髄とも言える ACDM (Architecture Centric Design Method) の解説だ．ACDM とは Lattanze が1999年から研究をはじめ，本書ではじめてその全貌を明かす渾身の開発プロセスである．ADD は設計にしか特化しておらず，ATAM は評価にしか特化していない．また CMM，RUP，XP，Scrum などは，本質的な部分は「設計しろ」としか言っていない…といった問題がある中で，数々の企業に携わった Lattanze が，その経験の集大成として提唱するソリューションだ．言わば「アーキテクトの活動手順書」であり，読めば目から鱗がポロポロと落ちてくるだろう．

セクション3では，実際の適用方法について言及している．一般的に方法論というものは，いつだって理想的な形で述べられており，時にはあまりに現実離れしている．だが彼はセクション2で ACDM の理想形を示した上で，セクション3で「では実際にどう適用すれば良いか」について，明瞭に答えている．


自信を持って断言するが，今日ソフトウェアアーキテクチャを語る上で，これほど現実的かつ，要所を分かりやすくおさえている書籍は存在しない．また本書で豊富に紹介されているテンプレートは，すぐにでもドキュメンテーションに役立つだろう．


まだ完全に成熟していないソフトウェア工学の世界において，いわゆる「王道」は存在しない．手法もプロセスも山のように転がっているが，どれもそのままでは使いものにならない．

それは当たり前なのだ．一口にソフトウェア開発といっても，その規模や形態は千差万別である．その中でやり方が一意に決められるのであれば，極端に言えば開発は全て自動化できてしまう．

そのままでは使えないという点では，本書も同じかもしれない．だが本書が他と違うのは，明確な視点に基き，とことん現場目線で書かれており，「実際に自分の組織・開発に適用するにはどのようにカスタマイズして取り込めば良いか」が，自ずと導き出されるという点であろう．


プロセスは，それが良いか悪いかではなく，そもそもプロセスが「ある」ということがまず重要である．もしあなたがアーキテクトという立場で，組織としてやり方が確立されており，過去のプロジェクトが全て大成功というなら，ACDM など必要ないだろう．だがもし私と同じように，理想と現実の狭間にもがき，それでも日々の開発を推し進めて製品やサービスをリリースしながら，少しでも良いやり方を模索しているなら，本書は必ず何かしらのヒントを与えてくれるはずである．

GoF が言っていること，Gamma が言っていること，Bushman が言っていること，Shaw や Garlan が言っていること，我々が SEI で言っていること，これらは重複もしているし，相反もしている．

なぜなら，まず第1に粒度がバラバラであるからで，そして第2に視点が明確になっていないからだ．

この2つだけでも，万人を混乱させるのに十分でしょう?

この議論にウンザリしているから，もう自分で本を書こうと思ったんだ．

-- Anthony Lattanze