昨日は、とある方々と打ち合わせ（飲み会。ご馳走様でした）。主な話はDIとJ2EEアーキテクチャというところだったのですが、そこからITアーキテクトの話へ。
ITアーキテクトのあり方は建築業界の建築家に近づくべき
個人的にはITアーキテクトの役割は建築業界の建築家（アーキテクト）に近づくべきだと考えています。
建築業界の建築家というのは、特に大型案件でコンペがある場合、建物に求められるコンセプトから外観や内装に言及します。一方、建物の工法や材料そして費用というのはストラクチャ・エンジニア（構造エンジニア）の責任です。
これをIT業界に置き換えると、そのシステムのコンセプトや概要を決めるのがITアーキテクトであり、具体的なコンポーネントの選定や配置を考えるのはITストラクチャー・エンジニアということになります。
現在のITアーキテクトの一般認識はアプリケーション・アーキテクチャだけに責任を持つことだと思います。これはITストラクチャー・エンジニアという役割に近いでしょう。
従来PMは責任のわりに手札を持たない
従来のプロジェクト・マネージャ（PM）がつらい仕事だと認識されてしまったのは、その責任と手札のアンバランスさにあると思っています。プロジェクト全体の責任を持つ一方で、実装周りの品質をあげるという手札を持っていないわけです。たしかに判断権は持つでしょうが、知識が不足していては正しい判断ができるわけもありません。Javaのシステム案件の場合、むしろアプリケーション・アーキテクチャ（ストラクチャ）に、十分な知識を持つ人間が先導者となるべきでしょう。
一方、従来のITアーキテクトは、品質全体に関わる重要な判断を行うわりに責任が軽すぎるわけです。もしアーキテクチャを技術的なトレンドや好みだけで判断してしまい、それが失敗だった場合、その責任の重さは計り知れないものがあります。
ITアーキテクトはもっと大きな責任を負うべき
つまり、ITアーキテクトが、システム開発全体に対してもっと大きな責任を取るべきなのです（だからこそ建築業界では建築家の名前が刻まれるわけです）。
そう考えるとITアーキテクトの仕事は実に多岐にわたります。最も重要なのは、一般的に業務チームというメンバーが行う業務/仕様検討というものと、アプリケーション・アーキテクチャ（ストラクチャ）の橋渡しをすることです。具体的な例を出せないのですが、あるサブシステムにおいて、仕様検討方法とアプリケーション・フレームワークをリンクさせることで高い品質を実現できたことがあります。
つまり、いわゆる規約というのが、もっとアーキテクチャに織り込まれるべきなのです。COBOL時代は言語に規約が織り込まれていたので、だからアーキテクチャは考えなくて良かった（VBも比較的そうかも）。ところがJavaは自由すぎるため規約をどうアーキテクチャに織り込むというのはプロジェクトの成功に大きな影響を与える要素なのです。
これ以外にもITアーキテクトがなにをすべきかというのは、いろいろな考え方があるかと思います。それも機会があればエントリしていきたいです。
プロジェクトの役割分担
なんにせよシステム開発には実装や技術に対する深い造詣が必要なのです。この状況では従来型PMでは対応しきれないのが現状でしょう。
ITアーキテクトやストラクチャ・エンジニアには比較的若い人（30代）がなることが多いはずです（これはIT業界の歴史的経緯からいって仕方の無いことです）。一方、PMには経験のある人物がついたほうがいいはずです。これは立場が上下ではなく、あきらかに*役割*です。
年齢ではなく、役割の明確化というのもソフトウェア開発の進歩に向けて必要なことでしょう。
