アーキテクトもプログラミングするべきか？

プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
で以下のようなコメントをいただきました。

アプリケーションのアーキテクトという役割についてちょっと理解が曖昧だったのがこのエントリ読んでだいぶスッキリした。今度の開発系の勉強会のネタにとりあげようかな

アーキテクトの働き方の参考に。

そもそもオブジェクト指向を本当に理解していてプログラミングも得意なアーキテクトがどれくらい居るのやら。 全体の設計がちゃんと推敲されていて、きちんと疎結合が達成されているなら、後の修正にも耐えられる。

アーキテクトが何をどこまで責任持つのか、という認識が整合されてないんじゃないの

現代的アーキテクトの仕事

このようなコメントから、「アーキテクト」という仕事の内容については、実はよくわからないと考えている方が多いように感じられます。実は、私自身も「アーキテクトという役割で仕事をする*1」などと書いたのですが、アーキテクトの役割や仕事の範囲について決定的なイメージを持っているわけではありません。少なくとも、ITSSのITアーキテクトの定義ITSSの次期版「V2」公表へ，専門分野の分類や記述を改良 | 日経 xTECH（クロステック）を参考にすると、実装技術よりも、上流のソリューションよりの傾向が強い気がしますから、普段の自分の仕事とはかけ離れていると思います。一方で、ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系やエンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)のような本で出てくるアーキテクチャーパターンという用語を考えると、設計レベルよりは視点が広めとは言え、かなり実装よりな視点からプログラムの全体構造を設計する人という解釈が自然なようにも思われます。
実はソフトウェアアーキテクトという言葉の意味するものが何なのかということは、日本のIT業界だけでなくて、海外でもさまざまな解釈があるようです。特に、アーキテクトがコードを書くべきかどうかという点については議論が分かれるところのようですね。アーキテクトは建築家ということなので、建物のメタファーで考えると、アーキテクトがコードを書くということは、建築家が金槌や釘を使って作業しているようでいかにも不自然に思われます。ですから、ソフトウェアの世界でアーキテクトがプログラムを書くなどということは、アーキテクトの単価に見合わない、お金の無駄使いのように考えている人も多いようです。
しかし、現実問題としては、プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指してで書いたとおり、言語やフレームワーク、ツールなど実装レベルの詳細を理解していないと、有効な設計を考えることは難しいという事実があります。*2建築のメタファーからすると不自然ですが、アジャイル開発のブームなどもあって、最近はアーキテクトがプログラミングできなくてはならないという事実が顕在化してきたみたいです。そこで、海外ではプログラムを書かないアーキテクトをhands-offアーキテクト、プログラムを書くアーキテクトをhands-onアーキテクトと読んで区別するようになっているみたいです。*3英語でネット検索するとアーキテクトの仕事の募集がたくさんで出てくるのですが、「hands-on Javaアーキテクトを募集」などという使われ方をするみたいです。
Spring Frameworkの作者であるRod Johnsonの著したExpert One-on-One J2EE Development without EJBの74ページで以下のような説明があります。

I believe that there is an important role for architects but that architects must retain hands-on contact with code. There is a real danger in architects who never work at the coal-face ― and hence lack awareness of the myriad of practical issues that dictate the success or failure of projects ― defining and dictating architecture in glorious isolation. This is a recipe for failure, and nearly always results in enormous complexity. Unfortunately, the notion that successful career progression involves a complete move away from coding dies hard, and does immense harm.
アーキテクトには大切な務めがありますが、アーキテクトはコードに直接手で触れる立場にいなくてはならないと信じます。開発現場での実労働を経験したことのないアーキテクト（したがって、プロジェクトの成否を左右するたくさんの実務上の問題を知らない）が、天下り的にアーキテクチャーを定義して押し付けるということは本当に危険なことです。これは失敗に至らしめる処方箋なのであって、ほぼ間違いなく、途方もなく複雑な設計に帰結します。*4残念ながら、キャリアパス上で昇進すると完全にコーディングから手を引くという考え方が染み付いていることもあり、これが甚大な被害をもたらしています。
Software architecture can be defined only with detailed knowledge of the issues that implementing them will pose. Architects who spend all their time writing documents and working with models seldom produce realistic architectures.
ソフトウェアアーキテクチャーは、それを実装するのに必要な事項に関する深い知識を通してのみ定義することが可能です。すべての作業時間を文書作成やモデルの作成に費やしているようなアーキテクトが、現実的なアーキテクチャーを創り出すことはほとんどありません。

hands-onとhands-offのアーキテクトは、別々の場面で、それぞれ役割があるのだと思いますが、少なくとも1プロジェクトのレベルでJava EEのようなプラットフォーム上でシステムの開発を行う場合は、スキルの高いhands-onアーキテクトの参画がプロジェクト成功の鍵を握っているというのは紛れもない事実であると思います。このことが日本ではいまだに広く知られていないのが問題ですね。私が比較的最近、途中からの立て直しのためヘルプで参加したことのあるプロジェクトでは、hands-offアーキテクトの判断でJSFとJPAというJava EEの標準仕様を導入し、少なくとも設計上はDDDを取り入れた斬新な設計を構想していたようなのですが、性能がまったく出ず、予算を大幅に超過して1年もリリースを延期した上に、大部分の設計見直しを行ったというところがありました。この失敗の主要な原因は、JPAの詳細な仕様を開発を引き継いだプロジェクトメンバーが誰も理解しておらず、lazyローディングや、SQLとO/Rマッピングの使い分けなど細かいところで適切な設計判断ができていなかったことが大きかったです。
最後に、上級プログラマーとhands-onアーキテクトとの役割の違いについて私の考え方を述べます。アーキテクトである以上、要件はもちろん、スケジュールやメンバーの経験などさまざまな観点から、全体として最適な方法を考えるというのがポイントになると思っています。設計ではどうしてもあっちを立てるとこっちが立たずというトレードオフの関係に陥ることが多いのですが、全体のバランスを考えて一部は妥協するようなバランス感覚が重要なのではと思います。また、実装上ちょっと仕様を変えるだけで、使い勝手が向上するだけでなく、大幅に工数を削減できるような有効な手段があるような場合は、可能な範囲で上流にフィードバックするといったような役割もhands-onアーキテクトにはあると思います。要するに、ユーザーやプロジェクト全体に対する視点も少しは必要かなと思います。そういうところが特定のモジュールの実装を担当する一般のプログラマーとの違いかと思います。

*1:あくまでも会社の営業的にアーキテクト単価で仕事をするという意味です。とはいっても実際は通常のSE単価と大差がないです。PMよりは金額的にははるかに下。一般のPG単価よりは数割程度は高いと思いますが。

*2:このアーキテクチャーの設計とコーディングの関係については、ファウラーの有名な論文でも論じられていますね。- 設計の終焉?

*3:日本語にあえて訳すと上流アーキテクト、下流アーキテクトといったような意味になるかもしれません。

*4:こうなるひとつの原因として、hands-offアーキテクトがプログラマーの苦労を考えず、やたらと複雑な商品を採用したがるという傾向が考えられると思います。分散オブジェクトやWebサービス、ESB、そして、最近はクラウドなど。そうして大規模で複雑な設計にした方が会社が儲かってhands-offアーキテクト自身の評価も高くなるというところもあるのでしょう。こういうアーキテクチャーをマーキテクチャーと呼ぶそうです。Marchitecture - Wikipedia