** 年収から人月価額を逆算する
派遣法改正案が規制強化（派遣の抑制）か緩和（派遣の増大）かはともかく、許認可で「働かせ方」に枠を作るもの。一方、仮称「ITサービス業法」の位置づけは、コンピュータ／ソフトウェア／ネットワークにかかわる技術提供の枠組みと安心・安全・信頼性の確保がねらい。法律を作るのは霞が関の官僚か国会議員に任せるとして、ITエンジニアが自己再生するのに必要な年収から、標準的な人月単価を設定する。脱・人月の方策はそのあとのことである。
人月価額の根拠は何か
――Aクラスが75万円、Bクラスは70万円、Cクラスは65万円……。
古い資料を整理していたら、こんな書き付けが目に止まった。あるコンピュータ・メーカーがプログラミング業務を外注するときの標準月額だ。日付は1984年の11月。これはプログラマーの標準外注月額なので、システム設計やプロジェクトマネジメントの業務ならもっと高かった（おそらく100万円台）だろう。COBOL全盛、これからメインフレームの大型リプレースや増設が始まろうとするとき、受託ソフトウェア業界はまさに昇り竜のごとくだった。
書き付けにはAからFまで6ランク、最低ランクは50～35万円とある。35万円は新卒者ないし現場経験1年目の初心者。月額35万円では給与と社会保険料、諸雑費でカツカツ、利益はほとんどない。だが、仕事を分配してくれるうえにプログラミング教育もしてもらえるのだから、ソフト会社にとってコンピュータ・メーカーはありがたい存在だった。だけでなく、メーカーの外注標準価格が業界内での目安、あるいはユーザーと業界の間での暗黙の了解になっていた。
また、ソフト会社の少なからずが外資系やユーザー系のITベンダーとの取引を望んだのは、国産コンピュータ・メーカーに比べて発注価額がよかった（高かった）からだ。その代わり求められる技術レベルは高かったし、多重下請けには厳しい制約が課せられた。
歴史的な経過はさておき、現在はそのような目安が見当たらない。強いていうと建設資材にかかる積算資料ないし設計労務単価に入っているシステム構築・運用にかかる労務費が唯一だが、関係者によると、そこでいうシステムとはCADとCALS（懐かしい！）を指しているらしい。
つまりITシステムの開発・運用・保守全般に適用できるわけではない。のだが、これを拡大解釈して、ITベンダーから提出された見積りの評価・査定に使っている自治体もあると聞く。
「難しい」は理由にならない
ソフトウェアの価値を客観的に説明するために、工学的アプローチからファンクション・ポイント（FP）法が研究されている。機能や画面、帳票、処理プロセスなどから総FPを算出し、ITエンジニア1人当り95万円／月＝生産能力10.5FPの場合、120FPだったら95×（120÷10.5）＝1040万円というわけだ。
FP法も人月価額を基準にしている点は変わらない。しかし一定のレベルで有効な積算手法であるなら、ITサービス業界が一丸となって「1人当り95万円／月」の根拠と理論構築に取り組めばいい。カルテルの一つも結べないで何の業界団体か、とは言わないが、価額決定の根拠を示すことぐらいはできるだろう。
これに対して業界団体側の言い分は次のようだ。
――ソフトウェア開発業務やシステム・オペレーション業務では、技術・技能が多様なうえ、対象領域が広がり続けている。製造原価方式であれ、時給方式であれ、一律の方程式を適用するのは難しい。それに業界団体として標準価額ないし価額決定根拠を示すのは自由競争の原則に反する。
いうまでもなく、これは「やりたくない」を表明しているにすぎない。「難しい」が理由になるはずもなく、「自由競争」とは「野放し」と同義である。メインフレームの“神話”が崩壊してからこの方、無為無策に流されてきた結果がこんにちの体たらくだ。
人月価額をエンジニアリングする
これに対してデータ入力・作成の価額算出は全く異なっている。日本データエントリ協会（JDEA）が毎年更新している「データエントリ料金資料」があって、これが公共システム調達の目安になっている。それは過度な低価格受注がデータ品質の劣化や事故を招き、ひいては業界全体のモラルダウンに結びつくと考えられたからにほかならない。
「データエントリ料金資料」がデータ量×時間当りキー・タッチ数で算出していたのは1990年代の前半までで、現在はデータ量の多少は要件の一つに過ぎない。プログラム作成、デリバリー、チェック、エントリー、ベリファイといったプロセスに応じた料金が設定されている。のだがその根拠を突き詰めていくと「事業を継続していくのに必要な売上」になる。
複雑なシステムを高い品質で生産性高く構築するためにソフトウェア工学は有効だし、複数のシステムが安心・安全に連携・連動していくにはシステム工学が必要。その価値をいかに“見える化”するか等々、研究者は理論と理屈を振り回す。しかし現場のITエンジニアやIT企業の経営陣にはほとんどリーチしていない。「事業継続に必要な売上」を保証するものではないためだ。
ソフトウェア工学やシステム工学を否定するものではないが、現場にリーチしないのでは空しかろう。例えばITエンジニアが持続的に自己再生するのに必要な年収をどう設定するか、技能や経験値、チーム編成力や指導力、就業と知識獲得のバランス、年齢や家族構成といったファクターをどのように給与と会社の利益に反映するか。それを基に人月価額の標準を設定していく。まずは「エイやッ」で決めるしかない、とは思うのだが、それをエンジニアリングする発想はないだろうか。
