ここ最近、システム開発におけるアーキテクトの仕事とは何だろうということを考えている。このテーマは、私にとっては馴染みのもので、もともとは2006年に考えていたことだ。（先日から書いたエントリーでも触れたとおりである。）世の中でアーキテクトという仕事について様々な説明が為されているが、2006年当時に感じた違和感と同じものを、また感じている。
その違和感というのは、アーキテクトが技術の親分であるというようなことであったり、フレームワーク（ここでは、非機能要件や共通仕様をまとめたモジュール群という意味で。）を作るのが仕事というような理解のされ方だ。
私の考えるアーキテクトは、ユーザと技術の間に立つ人である。だから、技術の親分などではない。ずっと技術の仕事をしていたいから、アーキテクトになるというのは違うと思う。そういう人は、ITスペシャリストの道があるではないか、と。
一方で、フレームワークを作るのは、私もアーキテクトの仕事のひとつだと思う。ただ、それがすべてではないし、フレームワークを作る人がイコール・アーキテクトになるかというと、それもまた違うのではないか。
「職業としてのソフトウェアアーキテクト」では、建築とのアナロジーを用いて、ローマ時代の建築家であるウィトルウィウスの論を引いている。
- ユーティリタス（ニーズ）
- ベヌスタス（デザイン）
- ファーミタス（構造）
ウィトルウィウスは、建築をこの3つの要素からなる正三角形として捉えている。そして、同書ではユーティリタスをクライアントやコンサルタントが、ベヌスタスをアーキテクトが、ファーミタスをエンジニアが担当すると説明している。つまり、アーキテクトは、クライアントが持つニーズを理解し、システムの全体性をデザインすることに責任を持つとしている。そして、具体的な構造はエンジニアが担当するのである。
これを言葉のとおりに受け取れば、アーキテクトはエンジニアではないということになる。このことを理解するには、特にアーキテクトは技術の親分だと思っている人には、大いなるパラダイムシフトが必要になるのではないだろうか。
とはいえ、私は技術の重要性を軽んじるつもりは毛頭ない。ただ、アーキテクトに関する一部の論評が、あまりに技術に傾倒しすぎ、ユーザとの間にいる立場であることを無視しているのではないかと思うのだ。
