著者の一言

「人生万事、道化芝居さ！（センバー・ファルシシムス！）」

2007年にそれまでお世話になった会社を辞めて独立してから、僕はアーキテクチャに関するコンサルティングやセミナを仕事としてやってきた。

まぁ、そもそも業界歴が長いのでそれも入れると、かなりいろいろとやっている。最近では、異なる金融系のレガシーなシステムを統合するためのアーキテクチャを構築したり、USと香港、そして日本にあるサーバを結合したシステムのアーキテクチャだって構築したりしている（この辺の話を詳しくできるといいんだけど、残念なことに、そうすると僕は訴えられちゃうだろう……）。

ナントカという厳めしい国の機関のとある部門からの依頼でさまざまな企業のアーキテクトと称する人たちと会って、アーキテクチャのベストプラクティスを分析したり――この分析結果は最悪だった。何しろ、ほとんどの企業がベストプラクティスと言いながら、自社製品の宣伝を始めるんだから、まともな分析なんてできやしない――これまた厳めしい学会のある分会でDIとAOPを核としたAADL（SAE：Society of Automotive EngineersのArchitecture Analysis and Design Languageにもアーキテクチャ記述言語としてAADLって云うのがあったのがダメだったかな……。で、う～ん、僕が考えたコイツは一体なんの略だったっけ？）などのアーキテクチャの評価方法を考案（これは、まったく流行らなかった。そういえば、DIコンテナを利用した場合の凹型アーキテクチャなんていうのも考案したけど、これもまったく流行っていないなぁ）したり、ITだけでなく工事なども含めた国内の品質工学についてちょっとは知られた機関の講座で、非機能要件について語ったり、それと並行して、各企業でアーキテクチャの構築や改善だって随分とこなしてきた。少しは失敗もあったかも知れないけど、大抵の場合はなんとか帳尻をあわせうまくいっている。

だから、その経験を週末の2,3回潰してまとめあげ、ちょちょいと本にして少しばかり生活費を稼いでも良いじゃないかと思ったわけだ。それに、それが少しは世間の役に立つのであれば……。この週末にちょちょいという計画が大間違いだったのは、本を書き始めてすぐにわかったけどね。僕はプロジェクトマネージャ支援も仕事としておこなっている。見積りやスケジュール計画、リスク管理の話を日頃、偉そうに話したりしてるのに、こんなずさんな計画を立てたなんて、ひどくがっかりだ。それでも執筆というデスマーチをこなして、なんとか僕の成果を1冊の本にまとめることができた。

さて、この本に書いてあることは、学術論文や技術論文なんかじゃなくて、僕が日頃アーキテクチャについて考えているロクでもないことや、SEI（カーネギーメロン大学のソフトウェア工学研究所）が提唱するATAMやADDにアレンジを加えて現場で利用した結果のエッセンスとか、アーキテクチャを構築する時に利用できる実現手法の話や、アーキテクチャを構築するだけじゃなく、管理／維持するために実際に効果的だったリファクタリングやメトリクス測定などといったことに対する僕の感じたことを書いたエッセイだ。

もちろん、書いてあることが、そのままで役立ったりすることはないだろうし、かなりムダなロクでもない話がいっぱい散らばっているので、その辺は適当に読んで、利用できるところは利用して、あとは捨てるなりなんなりしてほしい。そうするとアーキテクチャ構築とかアーキテクトに必要な色んなことが理解できるはずだ。それとアーキテクトっていうのがどんな人種でどんなことを考えているかもね。多分……。

最後に、この本を買おうとしてる人にお断りしておくが、この本は、多少ふざけて、しかも、僕の思いを込めて書いている。だから、現場で即役に立つとか、まじめな、客観的な事実に基づいたアカデミックな権威をもった技術書を読むつもりだったら、大間違いだ。皆に話しても恥ずかしくない話を読みたい人は、自分のブログやアマゾンなどの書評で、この本を酷評する前に、頼むからこの本を買うのをやめて、他の真面目な本を買ってほしい（まぁ、この本に書かれているダメなアーキテクチャの悪口を考えることで、頭の中のアーキテクチャが整理できたのなら、それはそれで、役に立ったってことだと諦めてくれ）。