アジャイラーとアーキテクトの緊張関係

アジャイラーとアーキテクトの緊張関係を示唆する記事をリンクしておく。

【元ネタ】
＠IT：ITアーキテクト宣言！

OOエンジニアの輪！ ～ 第 27 回 榊原 彰さんの巻 ～

「職業としてのソフトウェアアーキテクト (Software Architecture Series)」という本では、建築学をヒントにアーキテクトについて書いているらしい。
但し、絶版なので手に入れて読めないので、ネット上で調べてみた。
下記のBlogに、痛烈な批判が書かれている。

アーキテクトはユーザとエンジニアの間にいる -- INOCCU
※注意：ずっと保守モードで読めない。Googleのキャッシュで読むことは可能。

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

アーキテクトという役割は一体何なのか？
僕個人の経験では、アーキテクトと一体化しているコンサルやプロマネは、ユーザと開発者の橋渡しを期待されている。
しかし、「職業としてのソフトウェアアーキテクト (Software Architecture Series)」という本によれば、アーキテクトは設計だけを担当していて、ユーザとやり取りして要求を仕様へ落とし込む作業は担当していないし、ましてや実装も担当していない。
正直、アーキテクトの役割は抽象的すぎると思う。

ソフトウェアプロダクトラインの講演を聞いた時、衝撃を受けたのは、アーキテクトはユーザや開発者、管理者の間で調整する役割を担う人なのだ、という話。
僕もその話の方がはるかに実感できる。
本来の要望は何なのか、要望からどのように設計するか、開発者とどうやって技術で実現するか、要望と工数のバランスからどうやって折り合いをつけるか、などを考えるのがアーキテクトの役割だと思う。

そして、「システムアーキテクチャ構築の原理 ITアーキテクトが持つべき3つの思考 (IT Architects’Archive ソフトウェア開発の実践)」によれば、アジャイラーとアーキテクトの間には緊張関係がある。
カウボーイのようなアジャイラーと、管理者志向のアーキテクトは元々、水と油。
本来、役割を二つに分けるのがおかしいのかもしれない。