  |
一般的なエンジニアの人材派遣市場においては、設計スキルのあるなしをもって、SE、PGという称号を変えていると思われる。
なおこの市場においては、採用側がエンジニアのスキルを正しく判断できないということもあり、逆選択に近い状態になっている。
明確な指針が不足している為、採用側は悪貨を掴まざるを得ないということを覚悟しなければならない。
であれば、技術的難度の高い箇所は自社エンジニアであったり、多少単価が高くともリスクが低いと思われるSEにお願いをして、
そうでない部分をPGにお願いするという形になる。
本来であれば、PMとITアーキテクトが分離されており、それぞれの得意（人の管理、技術の管理）に注力できるのが理想ではあるが、
PG=>SE=>PMといった出世魚的キャリアプロセスをとっている組織体であれば、「PMはSEやPGの行うことは出来てしまう」という認識が容易に発生し、
これにより、PMにITアーキテクトの役目をも負わせるようになる。
一人の人間に役割を集約させる為、コミュニケーションコストなどは減少するメリットはあるが、
同時に、そういった役割に対して十分なキャパシティを持っている人は少ないということもあり、最新技術への対応が後手後手に回るというデメリットがある。
更に言えば、ウォータープロセスの場合、要求定義、設計、開発、検証といったようにフェーズの切り分けが明確である。
PMの役割は本来それぞれのフェーズの進捗度管理と投入されるリソースの管理であり、それ自体は至って機械的な作業であると思われる。
ただ、現実には、発注元との窓口（これは実は営業的機能であるので、本来は別ものではないか？）であったり、生産性向上の為の要員のモチベーション管理の役目を背負わされているのが実際だろう。
41
