デブサミ10周年記念に翔泳社で「君のために選んだ1冊 ソフトウェア開発の名著100」という本を企画されているそうです。カリスマプログラマからCIOまで、業界を代表する100人に書籍を推薦してもらうという企画だそうで、光栄にもお声がけいただき、原稿を書きました。私は、「アーキテクトを目指している現場のエンジニア」に向けての推薦図書というテーマで書いています。原稿をブログに掲載してもよいということでしたので、掲載します。
読者のみなさんで「アーキテクトを目指している」という方はいますか。そういった方は、アーキテクトにどのようなイメージを持っているのでしょうか。アーキテクトと呼ばれる理想の先輩がいるという漠然としたイメージかもしれませんし、スキルイメージを持って努力しているという方もいるのかもしれません。
実際、アーキテクトという言葉は色々な意味で使われています。スキルとして捉えられていることもあれば、プロジェクトのロールとして定義されている場合もあります。さしあたって、ここではシステムのアーキテクチャを決めるの人がアーキテクトであるとしましょう。
では、アーキテクチャとは何でしょうか。アーキテクチャという用語も、様々な文脈で語られている多義的な用語です。ソフトウェアアーキテクチャの教科書の定義によると、次のようになっています。
システムの構造、もしくは構造群のこと。ソフトウェアの要素や、外側から見える特性、およびそれらの関係から構成される。（Len Bass, Paul Clements and Rick Kazman, 2003, “Software Architecture in Practice, Second Edition”）
つまり、アーキテクチャとは、システムの機能や特性だけではなく、その関係も含んだ概念であるということです。単に、システムでどのミドルウェアやフレームワークが採用されているかというだけではなく、それらがどのように関係して全体を構成しているのか、それがシステムのアーキテクチャということなのです。
ですから、アーキテクトについての最初の定義をもう少し掘り下げると、アーキテクトとはシステムの要素とそれらの関係を決める人といってよさそうです。アーキテクトを目指しているという方は、ある技術のことを深く知っていたり、最新の技術動向を普段からチェックしているという方が多いのではないでしょうか。もちろん、アーキテクトになる上で、それらも重要です。しかし、それだけで満足することなく、もう少し広い視点でシステム要素の関係性にも目を向けるようにしてみてください。
「じゃあ、どうすればそういった視点が持てるのか」という質問がありそうですね。そのためには、アーキテクチャの引き出しを増やすこと、つまりアーキテクチャパターンを知ることが重要です。
マーティン・ファウラーの『エンタープライズアプリケーションアーキテクチャパターン』は、アーキテクチャとは何かを理解するのに最も優れた書籍です。さすがに今どきのシステムであれば優れたフレームワークのおかげで、この書籍で紹介されているようなテクニックやアーキテクチャは自然と実現されているはずです。だからといって、この書籍を読む必要がまったくないかというと、私はそうだとは考えません。
というのも、個々のシステムのアーキテクチャがどのようになっているのかということと、そのアーキテクチャの背景にあるパターンは異なるからです。さらにいえば、アーキテクトを目指すならばアーキテクチャパターン同士の関係も知っておく必要があります。たとえば、このシステムでドメインモデルを採用すると決めるのであれば、なぜトランザクションスクリプトを採用しないのかを説明できなくてはなりません。
個々のシステムのメタな表現がアーキテクチャだとすると、アーキテクチャのメタな表現がアーキテクチャパターンです。アーキテクチャパターン同士の関係を俯瞰するには、さらなるメタな視点を持つ必要があります。今にしてみると、このことは『エンタープライズアプリケーションアーキテクチャパターン』が私に教えてくれたと思うのです。
実のところ、私の書棚に何度も読み込んで手垢で汚れた本というのは、あまり多くありません。この書籍は、そのうちの一冊です。良書を精読することは、多くの学びをもたらします。また、そればかりではなく、良書は人と人との出会いをうながします。読書会のために喫茶店にこの書籍を片手に集まった人たちの多くとは、今でも交流があります。私が紹介した一冊は古い一冊ですが、あなたが新しい良書に出会うことを願っています。