arclamp.jp アークランプ

打ち合わせ強化月間につき、簡単に。
IT Proのみなさん，プロマネになりたいですか？より

「プロマネ，プロマネとおだてられているけど，実態は『現場の便利屋』に近い。何の権限もないのに，トラブルの責任だけは負わされる。正直，『これじゃ，やっていられない』と思うことがありますよ」　 ＜中略＞ これだったら技術だけに責任を持てばよいアーキテクトのほうがよっぽど楽に思える

びびった。これが世の中の認識だとしたら、由々しき自体である。アーキテクトとPMをくらべて、どちらが楽と議論する時点で、かなりいけないことになっている。

ソフトウェア開発におけるアーキテクトの役割とは、「プロジェクトの構造（フレームワーク）を構築する」ことにある。家の建築家がライフスタイルの分析から家を立てるように、技術というのはビジネス目的の上に成り立っている。だから、どうしてもプロジェクト全体の構造を定義せざるを得ない。

例えば、StrutsとHibernateを使うとする。まず、自動生成が品質向上のためにも確実に必要だろう。その場合の自動生成の元ネタというのは仕様書に密接に関わる。であれば、仕様書から自動生成できれば無駄がなくなる。さらに、アプリケーション特性にあわせて、自動生成範囲を広げていくことが考えられる。StrutsやHibernateの機能を100%使い切ることはないだろう。スクラッチでPGをする部分の仕様書も、そのプロダクトの使い方にあった形で書くべきだろう。そして、それらの仕様書はテストでも使われる。
つまり、仕様検討・仕様書、開発環境定義・実装、テスト・品質管理、加えればハードウェア構成、デプロイ手順、さらに運用手順、継続開発方法などなど、そのプロジェクトのライフサイクルすべてを見なくてはいけない（というか、見ないで技術要素を決めても、破綻する）。

もちろん、すべてを独りで決める必要性はない。それぞれの専門家と連携をとりながら、すべてが緩やかに繋がっていればよいのだ。

そして、実際にプロジェクトを動かすのがPMの仕事だろう。アーキテクトが決定したフレームワークに従いながら、メンバーが動くのを把握し、フィードバックを得る。アーキテクトは、常にPMのそばにいて、現場からのフィードバックを受けてプロジェクトのフレームワークを柔軟に適用させていく。つまり、PMとアーキテクトは両輪であり、どっちが大変とか言うことはない。明確な役割分担である。

忘れてはいけない。アプリケーションを作るのは現場のメンバーだ。彼らに、能力を最大限に引き出してもらうようにすることがPMとアーキテクトの役割なのだ。