アーキテクトについて (2)

アーキテクトについて、さらに考えを深めていこう。
今回は、私の実体験から、アーキテクトの仕事を探り出すことにする。
次回以降で、世の中一般に言われているアーキテクトとは、何かを探り、私が実体験として知っていることとの違いがあるのかどうか、明らかにしたい。
そうすれば、少なくとも私は、どういうアーキテクトになるべきかが分かるだろうから。

私が研修講師として十八番にしている、RUPのアーキテクチャセントリックは、当然、実際のプロジェクトでも取り入れている。
フレームワークを使ってみたり、プロジェクト初期から腕の良いメンバーを技術専門要員（つまりアーキテクト）として、参入させたりしているのだ。
プロジェクトでの効果は顕著なものだと認識している。
逆に、失敗したり、火を吹いているプロジェクトを観察すると、いろいろな理由があると思うが、アーキテクトがいなかったり、投入タイミングが遅すぎることが、その1つであるのは、間違いないと思っている。

では、プロジェクトの中で、アーキテクトは、どんな仕事をしたのだろうか。

• 業務SEとの非機能要件のすり合わせ。
• 非機能要件を実現するフレームワークの開発や、アーキテクチャ説明書の執筆。
• 使用するミドルウェアの調査。
• 単体テスト方法の指示。
• 開発環境の整備。（Eclipseの設定指示、CVSの導入、Antスクリプトの作成など）
• 採用するフレームワーク、アーキテクチャに沿った、サンプルアプリケーションの開発。（実際の開発の雛形となる。）
• プロジェクト進行上で出てくる技術的な問題の解決。
• PMとのプロジェクトの進め方に関するすり合わせ。（特にテストツールの使用等をWBSに関連づける場合。）

ざっと、こうしたことが思いつく。
プロジェクトの初期から中盤にかけて、かなり大量の作業があることが分かる。

私は、実際のプロジェクトにアーキテクトとして参入した経験もあるが、大抵はアーキテクトに作業をお願いする側のリーダーや、業務SEであった。
考えてみると、実際のもの作りをするプログラマとの間で、関係が深くなるのは、業務SEよりアーキテクトであったケースが多いように感じる。
これは、特にプログラマが投入された最初期において、プログラマの具体的な作業を指示するのがアーキテクトだからということが、理由として考えられる。
他にも、アーキテクトの技術力が高く、プログラマの尊敬を集められることもあるかもしれない。
顧客に顔が向いている業務SE（もちろん、それは重要なことだ。）より、アーキテクトの方が、プログラマの気持ちに近いということもあるだろうか。

いずれにせよ、私が知っているアーキテクトとは、このようなものである。