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

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

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

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

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

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

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

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

この記事を書いた人

井上 研一

経済産業省推進資格ITコーディネータ/ITエンジニア/ブロガー。
井上研一事務所代表、株式会社ビビンコ代表取締役、一般社団法人ITC-Pro東京理事。
北九州市出身、横浜市在住。 AIやIoTに強いITコーディネータとして活動中。著書に「初めてのWatson」、「ワトソンで体感する人工知能」など。セミナーや研修講師での登壇も多数。

この記事が気に入ったら
いいね!しよう

最新の情報をお届けします