Hotwired 第3回 「人材不足と慢性的残業の悪循環を断ち切る」 （2004年12月）
いったい誰が怠け者なのか
ずいぶん昔、雑誌でこんなジョークを読んだ覚えがある。
ある船着き場で大勢の労働者が、船から荷物を降ろしていた。田舎の船着き場なので、クレーンなどの設備はなく、港湾労働者たちは背中に麻袋を背負って船から荷物を降ろしている。たぶん、小麦かトウモロコシだろう。みんな背中には麻袋を二つ背負っているのだが、一人だけ麻袋を一つ背負って荷揚げ作業をしている男がいた。荷下ろし作業の監督者が、その男を呼びつけて叱りつけた。「みんな袋を二つ担いでいるのに、なんでお前は一つしか担がないんだ。おまえみたいな怠け者はクビだ」 すると男は目を丸くして、こう答えた。「えっ、おいらが怠け者だって。とんでもねえ、あいつらの方がずっと怠け者ですぜ。おいらが二回運ぶところを、あいつらは一回で済ませようとしてるんですぜ」
さて、あなたが監督者なら、どう答えるだろう。
全員の労働時間が同じであるならば、背中に一つしか麻袋を背負わない労働者は、他の労働者の半分しか仕事をしないことになる。少し難しく言えば、この「怠け者」の労働生産性は他の労働者の半分だということになる。したがって、作業量に応じて報酬を支払うというルールになっていれば、この「怠け者」の労働者の報酬は他の人の半分でよいことになる。
しかし、不思議なことにソフトウェア産業では、この「怠け者」に一人前の報酬を支払っていることが多い。場合によっては「怠け者」の言い分を真に受けて、「怠け者」の方が報酬が多くなることもある。なぜなら、他の人より長時間働くことになり残業手当が多くなるからである。この業界を知らない人にとっては信じられないことかもしれないが、これは事実である。
仕事のできない人間の方が給料が多いとなれば、仕事のできる人間がやる気を失ってもしまうだろう。これでは、仕事のできる優秀な人材が集まるはずがない。
この「怠け者」とそれ以外労働者の生産性の差は2倍である。しかし、ソフトウェアの世界における生産性の個人差は、これよりはるかに大きいことが知られている。それだけにソフトウェア産業では、個人の生産性に関する問題は、非常に重要である。「みんな袋を二つ担いでいるのに、なんでお前は一つしか担がないんだ。おまえみたいな怠け者はクビだ」とまで言う必要はないかもしれないが、能力と実績に応じた報酬や待遇を考える必要がある。
結論めいたことを書いてしまったが、まずは、プログラマの生産性の個人差が非常の大きいという話から始めよう。
プログラマの生産性の個人差
プログラマ(1)の生産性に大きな個人差があることについては、かなり昔から関係者は気付いていた。たとえば、IBMのシステム360のオペレーティングシステム（OS360）の開発を指揮したフレデリック・P・ブルックスは、その著書『人月の神話』の中で「プログラミングマネージャーは、できるプログラマとできないプログラマの間に、大きな生産性の相違があることに、前々から気が付いていた」と述べている(2)。
手元で参照している『人月の神話』は1996年の原著発行20周年記念増訂版であるが、この記述は1975年版から存在している。つまり、プログラマの生産性に大きな個人差が存在することは30年以上前から周知の事実なのである。
(1) ここでは、ソフトウェア技術者のことを総称して「プログラマ」と呼ぶ。けっしてウォーターフォール・モデルにおけるコーディング工程だけを担当する技術者だけを指すわけではない。
(2) フレデリック・P・ブルックス・Jr『人月の神話 〜狼人間を撃つ銀の弾はない』ピアソン・エデュケーション（1996）､ｐ.26
世の中にはプログラマの生産性の個人差を取り上げた論文も数多く存在する。その中で最も有名かつ古いものが、1968年に発表されたサックマンたちによる研究で、その論文によれば、個人の能力差は最大で28対1である(3)。
つまり、優秀なプログラマが1日で済ますことのできる仕事を、そうでないプログラマに任せると最悪の場合には約1ヶ月の期間を要するということである。仮に、個人の生産性に応じて給与を支払う会社があれば、優秀なプログラマはそうでないプログラマの28倍の収入を得ることになる。
(3) H. Sackman, W. J. Erikson, and E. E. Grant "Exploratory Experimental Studies Comparing Online and Offline Programing Performance", Communications of the ACM Volume 11, Issue 1 (Jamuary 1968)
この衝撃的な研究結果については、いろいろと批判がある。最も生産性のよいプログラマと最も生産性の悪いプログラマを比較しているために極端な結果が出ているとか、差が大きいのは現在ほとんど使われていないアセンブラ言語によるものだから、これを除いて結果をみるべきだという意見などである。
しかし、プログラマの個人による生産性に大きな差があることは、他の多くの研究でも実証されている。たぶん、最も有名なものは、トム・デマルコとティモシー・リスターが1984〜1986年に行ったプログラミング・コンテストだろう。これは、92社から延べ600人を超えるプログラマを集め、共通の仕様を与えてプログラムを作成させ、その所要時間と残存不良数を計測したものである。このこの研究から得られた結果は以下のとおりである（図表１参照）。
最優秀者の測定値は、最低者の約10倍である。
最優秀者の測定値は平均的作業者の約2.5倍である。
上位半分の平均測定値は、下位半分の平均の2倍以上である。
こうした多くの研究は、被験者の数や実験方法などに違いがあり、計測された生産性の数値も異なっているが、プログラマの能力は個人によって大きな差があるという結論だけは同じである。間違いなく、プログラマの生産性には大きな個人差が存在している。
生産性がマイナスのプログラマ
ソフトウェア開発の現場を知っている人たちからみれば、こうした研究の結論は、まったく驚くに値しないだろう。もしかすると、現実のプログラマの能力格差はもっと深刻だという意見もあるかもしれない。それは、できないプログラマは本当に仕事が「できない」からである。
プログラマの生産性を計測した研究論文を詳細に読むと、その中のいくつかの実験では、十分な時間を与えても作業を完了できなかったプログラマが存在している。ある研究では166人中13人が、別の研究では60人中6人が作業を完了できなかった。生産性の比較をする場合、こうした作業を完了できなかったプログラマのデータは除かれている。
現実のソフトウェア開発プロジェクトで、こうした課題をクリアできないプログラマがチームの一員だったら何が起きるのだろう。研究では、できないプログラマのデータを除いて分析することはできても、現実のプロジェクトではそうはいかない。
現実のプロジェクトでは、できないプログラマに無限に近い時間を与えることはできないし、仮に、そのプログラマに無限の時間を与えても、できないものはできないままで終わるように思える。とすれば、チームの他の誰かが代わりに仕事をすることになる。
ソフトウェア開発の場合、できないというのはプログラムが1行も書けないのではない。山ほどプログラムを書いているのだが、それがきちんと動かないのである。できないプログラマに割り当てられた仕事をするはめになったできるプログラマは、バグだらけのプログラムと格闘するか、ゼロからプログラムを組むことになる。
つまり、できないプログラマの生産性は、実験であればゼロなのだが、現実のプロジェクトでは他のメンバーの仕事を増やしてしまうためマイナスになるのである。もし、できないプログラマの存在確率を10％と仮定すると、7名のプロジェクトチームに生産性がマイナスのプログラマが1人以上含まれる確率は半分以上（52％）になってしまう。
もちろん、問題解決の方法は誰でもわかる。ランダムにチームのメンバーを決めるのではなく、生産性の高いプログラマを集めて開発チームを結成すればよいのである。
プログラマの給与の実態
では、優秀なプログラマを集めるにはどうすればよいだろうか。最初に思いつくのは優秀なプログラマには、それに応じた報酬を与えることである。給料がすべてではないが、給料が高ければ優秀な人材が集まりやすくなるはずである。
では、プログラマの給与の実態を見てみよう。利用するデータは、独立行政法人 雇用・能力開発機構が（社）情報サービス産業協会に委託した賃金実態調査である(4)。この調査は「ITエンジニア」を対象とした調査であり、サンプルには管理職やコンサルタントも含まれているが、大多数がソフトウェア開発に携わるソフトウェア技術者である（調査期間は2003年1月?2月で、有効回答数は702件）。
(4) （社）情報サービス産業協会『ITエンジニアのための仕事・市場基準の人材評価システム ?平成14年度情報サービス産業雇用高度化推進事業報告書?』平成15年3月
図表2は、年齢階層別にITエンジニアの年収を見たものであるが、一目で分かるように年収は年齢に比例している。プログラマの能力は、経験によって多少は伸びるものの、年齢に比例してどんどん伸びる性質のものではない。しかし、このグラフを見る限り報酬は年齢とともに増加しているように見える。
この報告書では、ITエンジニアの年収を決定する要因を分析するため、いくつかのモデルに基づいて重回帰分析を行っている。詳細は、拙著『ソフトウェア最前線』の153ページを参照していただくことにして、その分析結果のさわりを紹介すると、年齢が1歳上がると、年収が約15万円高くなる。また、プロジェクトマネージャーやシステムマネジャーになると年収は約64万円上昇し、コンサルタントになると約93万円上昇する。また、企業系列を考えると、独立系よりユーザー系の会社の方が平均して年収が46万円ばかり多く、逆にメーカー系だと独立系より57万円強安くなる。さらに正社員が多い企業に勤めた方が、収入面では恵まれていることもわかる。しかし間違いなく、年齢がプログラマの報酬の大部分を決定している。
この報告書で、もう一つ気になるデータがある。それは、残業手当である。図表3は、年齢別の給与構成比を示したものである。30歳代前半までは時間外手当が年収のかなりの割合を占めていることがわかる。残業をすれば時間外手当をもらうのが当然だと思うかもしれないが、個人によって生産性が大きく異なる場合には、そうとは言い切れない。冒頭で紹介した船着場の労働者の話を思い出してもらいたい。生産性の低い人（背中に一つしか麻袋を背負わない労働者）が、他の人と同じだけ仕事をしようとすれば、長時間働かなければならない。その超過部分に時間外手当を支払うべきなのだろうか。
プログラマの生産性が個人によって大きく異なることは間違いのない事実である。優秀なプログラマとそうでないプログラマに同じような作業をさせれば、早く仕事を終えるのは優秀なプログラマである。つまり、優秀でないプログラマの方が残業時間が長くなり、報酬も多くなることを示している。
たぶん、経営者からは反論があるだろう。「優秀なプログラマは仕事をてきぱきこなすために、残業が少なく、短期的にみれば収入は少ないかもしれないが、長い目でみれば、優れた仕事が評価されて昇級、昇格されることになるので、能力に応じた給与をもらうことになるのだ」というように。
しかし、これもむなしい反論である。プログラマの給与はほとんど年齢で決まっている。もう一度図表2の年齢階層別の年収をよく見ていただきたい。その偏り具合を示す標準偏差は年収の20％程度でしかない。もし能力に応じて報酬が決められているとすれば、標準偏差はこれよりはるかに大きくなるはずである。
優秀な人材の不足と慢性的な残業の悪循環
ソフトウェア開発プロジェクトを成功させる秘訣は、生産性の高いプログラマを集めてチームを編成することにある。しかし、これは言うは易く行なうは難しである。優秀なプログラマはそれほど多くないからだ。おまけに、ソフトウェア開発にかかわる人たちの労働環境が悪化するにしたがって、優秀なプログラマはどんどん減少している可能性が高い。
なぜなら、優秀なプログラマは、徹夜や休日出勤が日常化している職場に嫌気がさして、ソフトウェア開発の現場から姿を消すからである。もちろん、プログラミングが大好きで過酷な現場に残っている優秀なプログラマの存在を否定するわけではない。しかし、プログラマの能力が給与にほとんど反映されてないという事実は、当事者たちがもっともよく知っている。だから優秀なプログラマの多くは、自分より遙かに能力が劣るプログラマとそう変わらない給与しかもらっていないのに、彼らの数倍、十数倍の仕事をこなしている現状に極めて大きな不満を持っている。
一般的に、組織やチーム全体の志気（モラール）が低下すると、そこから出て行こうとするのは最も優秀な人たちである。彼らが一番不満を抱えていると同時に、転職できる可能性も高いからである。優秀でないプログラマは、給与に不満はあっても、今の会社を辞めると行き先がないことを自覚している。
プログラマの生産性は個人によって大きな差があるため、優秀な人材が逃げ出せば、ソフトウェア産業（あるいは企業）全体としての生産性は低下する。生産性が低下すれば、残った人たちの残業は増え、時間当たりの報酬は減少する。ますます、プログラマの労働条件は悪化し、職業としての魅力がなくなっていく（図表4参照）。優秀な若者はプログラマになろうとは思わない。もちろん、プログラミングが大好きで、プログラマになろうという若者もいるだろうが、この産業を支えられるほど大勢いるわけではない。生産性の高いプログラマが集まらなければ、産業全体としての生産性はさらに低下する。
これが、現在の日本のソフトウェア産業に起きている悪循環である。
悪循環を断ち切り、好循環に変える方法
日本のソフトウェア産業の未来を切り開くためには、この悪循環を断ち切る必要がある。では、どうすればよいのだろう。
原点に返って考え直してみよう。まず、プログラマの生産性は個人による格差が大きい。したがって、ソフトウェア産業の生産性を上げる最も簡単な方法は、優秀な技術者、プログラマを数多く集めるのが最も近道である。そのためには、プログラマとして優秀な人材が集まってくる職業にする必要がある。魅力のある職業に必要な条件は、(1) やりがいのある仕事、(2) 十分な報酬、(3) ゆとりのある労働時間だろう。
もちろん好き嫌いや適不適はあるだろうが、そもそもプログラミング自体は創造的で楽しい作業であるから、(1)の条件を満たすのはそれほど難しいことではない。また生産性の高い人材が集まれば、自然と報酬水準は高くなるし、残業問題も解消されて(2)の条件も(3)の条件も満たされるはずである。
つまり、図表5に示したような好循環を作り出せばよいのである。この好循環を作り出す第一歩は、能力に応じた報酬制度、あるいは成果に応じた報酬制度である。能力や成果を客観的に計測することは難しい。
最善の策ではないかもしれないが、この課題に対する解決策は「管理者からみて優秀なプログラマにはそれなりの給与を払う」ではないだろうか。ソフトウェア開発プロジェクトに携わってきた何人もの専門家に対して生産性の個人差について質問をしたが、全員が、できるプログラマはすぐわかると答えている。つまり生産性の正確な計測は難しいが、プログラマとして優秀かどうかは比較的簡単に分かるというのである。それならば能力に応じて報酬を支払うことは不可能ではない。残る問題は、プログラマ本人にそれを説得できるかどうかである。
優秀なプログラマは報酬が増えるので、不満がでる心配はない。問題なのはそうでないプログラマである。徹夜や休日出勤をして山ほど残業をしているプログラマに、プログラマとしては能力が低く、成果が出ていないからという理由で報酬のカットを申し渡さなければいけない。麻袋を一つしか背負わないのなら、時間当たりの労賃は、他の労働者の半分になるということである。実に理にかなった話なのだが、年功序列的賃金に慣れた人たちにとっては大変なことである。しかし、これは企業が生き残るためにも、日本のソフトウェア産業のためにも必要なことなのである。
この記事が気に入ったらサポートをしてみませんか？