PR

 ITエンジニア1人の1カ月間の作業時間に対する料金である「人月単価」。本誌7月号の特集3「人月単価の相場を押さえよう」は四つの職種(プロジェクトマネジャー、上級SE、SE、プログラマ)の人月単価の相場を、過去10年の金額推移や、大手ベンダーと中小ベンダーの違いなどをまとめた興味深い記事だった。

 記事では、人月単価のユーザー側のデメリットとして、費用の妥当性の評価が困難でありソフトウエア開発費用が不透明になる点を挙げていた。開発者側のデメリットとして、契約金額はソフトウエアの機能や品質ではなく開発工数で決まるため、開発生産性の向上やソフトウエアの付加価値向上へのモチベーションが生まれにくくなる弊害を指摘していた。
 一方で、人月単価によるメリットも、ユーザーと開発者の双方にある。ユーザー側は、人月単価方式だと予算内に収まれば、ベンダーにシステム構築を「丸投げ」できる。本来は開発工数の把握や作業内容と費用の妥当性検証といった発注者責任があるはずだが、それをサボって人月単価で丸めて発注し「あとはよろしく」といえる。

 開発者側のメリットは、元請け・下請け構造と密接に絡んでいる場合が多い。元請けは、高い人月単価で発注側と契約できれば、あとは人月単価の安い下請けに出してほぼ自動的に利益が確定する。元請けと下請けの力関係もあるため、よほど大きな開発トラブルでも発生しない限り、多少の無理は下請け会社に押し付けられる。下請け会社はその元請けからの無理強いのリスクを減少させるためにさらに孫請けに委託する…。このような多層化した取引において人月単価はとても便利な方式なのである。