このままでは日本のソフトウェアはダメになる～我が国情報サービス産業の革新にむけて～ （2004年12月）
ソフトウェアと自動車
2004年5月、ダイムラー・クライスラー社のメルセデス・ベンツ部門は、2002年3月以降に生産したEクラスのセダン、2001年10月以降に生産したSLクラスのスポーツカーなど68万台のリコールを発表した。リコールの原因は、最新式の電子制御ブレーキシステム『センソトロニック』に原因があると報道されている。
このセンソトロニックは、ブレーキがどれだけ踏み込まれたかをセンサーで感知し、それぞれの車輪の状況にあわせて最適なブレーキ圧をコンピュータが計算してブレーキを作動させるシステムである。報道から推測すると、油圧タンクに発生する気泡がその計算を狂わせる可能性があるらしい。一種のソフトウェア・バグである。
最近の自動車には平均して60個程度のコンピュータが搭載されており、そのコンピュータはソフトウェアによってコントロールされている。ソフトウェアに不具合があっても人身事故には結びつかないものも多いが、こブレーキ・システムやパワーステアリング、エンジン制御システムなどのソフトウェアにバグがあれば、重大な事故が起きる可能性がある。
現実に、高速走行時にエンストがおきるソフトウェアの不具合が見つかっているし、ギアが勝手にバックに入ってしまう不具合が原因でリコールされた自動車もある。
高まる社会のソフトウェア依存度
ソフトウェアの不具合が原因で製品が回収される事件は、携帯電話やビデオ・プレーヤー、デジタル・カメラなどの分野でも数多く起きている。エアコンや炊飯器、洗濯機などの家電もソフトウェアによって制御されていることを考えれば、こうした家電がソフトウェアの不具合が原因で、異常動作をする可能性はゼロとは言えない。
ソフトウェアによってコントロールされているのは自動車や家電だけではない。電話やインターネットなどの情報通信ネットワークはもちろん、金融機関のネットワーク、電力やガスなどのエネルギー網、新幹線や地下鉄などの公共交通網などの社会インフラの制御にもコンピュータが利用されており、このコンピュータを動かしているソフトウェアに不具合があると、さまざまなトラブルが発生する。たとえば、システム障害が原因で銀行のATMでカードがつかえなくなったり、口座振込みができなったという事件が実際に何件も発生している。
最近では、2004年9月に紀伊半島沖で地震が連続して発生したときに、システムの不具合が原因で、気象庁の津波観測情報システムの一部が作動しなくなり、１時間ほど観測情報を関係機関に送信できない状況が続くという事件が起きている。
このように、身の回りの機器から社会システムまで、多くの機器やサービスがソフトウェアに依存しており、その依存度はどんどん高まっている。
日本のソフトウェアの国際競争力
ソフトウェアへの依存度が高まっているということは、それだけソフトウェアの重要性が高まっていることでもある。しかし、日本のソフトウェア産業の国際競争力は極めて低い。
図表１は、日本のソフトウェアの輸出入額をグラフにしたものである。2000年の日本のソフトウェア輸入額は9189億円もあるのに、輸出額は90億円と、輸入額の1％程度しかない。
この原因の一つは、コンピュータの基本ソフトであるOSや、ワープロや表計算といったパソコン向けのパッケージソフトの市場を外国企業に握られていることにある。しかし、図表２に示すように、カスタムメイドのソフトウェアの輸入も急増しているのである。
こうした数字が意味するものは、「日本のソフトウェアの品質や性能は、外国製のソフトウェアに比較して著しく劣っている」あるいは「品質や性能が同等であっても日本のソフトウェアは価格が高い」ことを意味する。つまり、日本のソフトウェアは設計や品質管理が悪くて粗悪品になっているか、ソフトウェア産業における労働生産性が低くて割高なものになっている、あるいはその両方だということになる。
問題の所在
日本のソフトウェアの品質と生産性を高めなければ、ソフトウェア産業に未来はないと多くの関係者が考えている。経済産業省はこのため、2004年秋に情報処理推進機構（IPA）にソフトウェア・エンジニアリング・センター（SEC）を設置した。
もちろんソフトウェア工学は重要である。しかし、ソフトウェア工学だけで日本のソフトウェアの未来は開けない。なぜなら、日本のソフトウェア産業が抱えている最も深刻な問題は、ソフトウェア工学で解決できないからである。
最も重要な問題については、次節以降で述べるが、日本のソフトウェア産業は、このほかにいくつもの問題を抱えている。たとえば、日本のソフトウェア開発プロジェクトではウォーターフォール・モデルと呼ばれる開発手法が最もよく利用されているが、この手法はソフトウェア開発の専門家からソフトウェア開発には適していないと指摘されている。また、ソフトウェアの発注側がソフトウェアの本質をよく理解していないために、開発企業に無理難題を押し付けたり、安物買いの銭失いをしているという問題もある。
こうした問題は、拙著『ソフトウェア最前線』（アスペクト刊）に詳述したので、興味のある読者はこの本を読んでいただければ幸甚である。
プログラマの生産性の個人差
プログラマ(1)の生産性に大きな個人差があることは、かなり昔から公知の事実である。たとえば、プログラマの生産性の個人差を取り上げた論文が数多く存在する。もっとも有名なサックマンらによる研究によれば、プログラマの能力差は最大で28対1である(2)。
この衝撃的な研究結果については、いろいろと批判がある。最も生産性のよいプログラマと最も生産性の悪いプログラマを比較しているために極端な結果が出ているとか、差が大きいのは現在ほとんど使われていないプログラミング言語によるものだから、これを除いて結果をみるべきだという意見などである。
しかし、プログラマの個人による生産性に大きな差があることは、他の多くの研究でも実証されている。たぶん、最も有名なものは、トム・デマルコとティモシー・リスターが行ったプログラミング・コンテストだろう。これは、92社から延べ600人を超えるプログラマを集め、共通の仕様を与えてプログラムを作成させ、その所要時間と残存不良数を計測したものである。このこの研究から得られた結果は以下のとおりである（図表３参照）。
a. 最優秀者の測定値は、最低者の約10倍である。
b. 最優秀者の測定値は平均的作業者の約2.5倍である。
c. 上位半分の平均測定値は、下位半分の平均の2倍以上である。
こうした多くの研究は、被験者の数や実験方法などに違いがあり、計測された生産性の数値も異なっているが、プログラマの能力は個人によって大きな差があるという結論だけは同じである。間違いなく、プログラマの生産性には大きな個人差が存在している。
生産性がマイナスのプログラマ
ソフトウェア開発の現場を知っている人たちからみれば、こうした研究の結論は、まったく驚くに値しないだろう。現実のプログラマの能力格差はもっと深刻だという意見もあるかもしれない。それは、できないプログラマは仕事が本当に「できない」からである。
プログラマの生産性を計測したいくつかの実験では、十分な時間を与えても作業を完了できなかったプログラマが存在している。生産性の比較をする場合、こうした作業を完了できなかったプログラマのデータは除かれている。しかし、現実のプロジェクトでは、できないプログラマを最初から除外して進めるわけにはいかない。最終的には、チームの他の誰かが、できないプログラマの代わりに仕事をすることになる。
ソフトウェア開発の場合、できないというのはプログラムが1行も書けないのではない。山ほどプログラムを書いているのだが、それがきちんと動かないのである。できないプログラマに割り当てられた仕事をするはめになったできるプログラマは、バグだらけのプログラムと格闘するか、ゼロからプログラムを組むことになる。
つまり、できないプログラマの生産性は、実験であればゼロなのだが、現実のプロジェクトでは他のメンバーの仕事を増やしてしまうためマイナスになるのである。もちろん、問題解決の方法は誰でもわかる。ランダムにチームのメンバーを決めるのではなく、生産性の高いプログラマを集めて開発チームを結成すればよいのである。
プログラマの給与の実態
では、優秀なプログラマを集めるにはどうすればよいだろうか。優秀なプログラマはそれなりの報酬を得ているはずだから、給与の高いプログラマを集めればよいと思うかもしれない。しかし、それは間違っている。
プログラマの報酬はけっして個人の生産性や実力によって決まっているわけではない。図表４は、独立行政法人 雇用・能力開発機構が（社）情報サービス産業協会に委託した賃金実態調査の結果を年齢階層別にみたものである(3)。
一目で分かるように年収は年齢に比例している。プログラマの能力は、経験によって多少は伸びるものの、年齢に比例してどんどん伸びる性質のものではないのだが、このグラフを見る限り報酬は年齢とともに増加している。
この報告書では、ITエンジニアの年収を決定する要因を分析するため、いくつかのモデルに基づいて重回帰分析を行っている。図表５は、その一例であるが、この分析結果によれば、年齢が1歳上がると、年収が約15万円高くなる。また、プロジェクトマネージャーやシステムマネジャーになると年収は約64万円上昇し、コンサルタントになると約93万円上昇する。また、企業系列を考えると、独立系よりユーザー系の会社の方が平均して年収が46万円ばかり多く、逆にメーカー系だと独立系より57万円強安くなる。さらに正社員が多い企業に勤めた方が、収入面では恵まれていることもわかる。しかし重要なことは、年齢がプログラマの報酬の大部分を決定しているである。
残業手当の問題
この報告書で、もう一つ気になるデータがある。それは、時間外手当である。図表６は、年齢別の給与構成比を示したものである。30歳代前半までは時間外手当が年収のかなりの割合を占めていることがわかる。残業をすれば時間外手当をもらうのが当然だと思うかもしれないが、個人によって生産性が大きく異なる知的労働者の場合には、そうではない。
多くの研究が明らかにしているように、プログラマの生産性が個人によって大きく異なる。優秀なプログラマとそうでないプログラマに同じような作業をさせれば、早く仕事を終えるのは優秀なプログラマである。できないプログラマはいつまでたっても仕事を終えることができないため、残業時間がどんどん長くなる。もし、時間外手当を支払っているとできないプログラマの方がたくさんの報酬を得ることになってしまう。
たぶん、経営者からは反論があるだろう。「優秀なプログラマは仕事をてきぱきこなすために、残業が少なく、短期的にみれば収入は少ないかもしれないが、長い目でみれば、優れた仕事が評価されて昇級、昇格されることになるので、能力に応じた給与をもらうことになるのだ」というように。
しかし、図表４をよく見ていただきたい。プログラマの給与はほとんど年齢で決まっている。報酬のばらつき具合を示す標準偏差は年収の20％程度でしかない。もし能力に応じて報酬が決められているとすれば、標準偏差はこれよりはるかに大きくなるはずである。
優秀な人材の不足と慢性的な残業の悪循環
ソフトウェア開発プロジェクトを成功させる秘訣は、生産性の高いプログラマを集めることである。しかし、これは容易なことではない。優秀なプログラマはそれほど多くないからだ。おまけに、ソフトウェア開発にかかわる人たちの労働環境が悪化するにしたがって、優秀なプログラマはどんどん減少している可能性が高い。
なぜなら、優秀なプログラマは、徹夜や休日出勤が日常化している職場に嫌気がさして、ソフトウェア開発の現場から姿を消すからである。もちろん、プログラミングが大好きで過酷な現場に残っている優秀なプログラマの存在を否定するわけではない。しかし、プログラマの能力が給与にほとんど反映されてないという事実は、当事者たちがもっともよく知っている。
一般的に、組織やチーム全体の志気（モラール）が低下すると、そこから出て行こうとするのは最も優秀な人たちである。彼らが一番不満を抱えていると同時に、転職できる可能性も高いからである。優秀でないプログラマは、給与に不満はあっても、今の会社を辞めると行き先がないことを自覚している。
プログラマの生産性は個人によって大きな差があるため、優秀な人材が逃げ出せば、ソフトウェア産業（あるいは企業）全体としての生産性は低下する。生産性が低下すれば、残った人たちの残業は増え、時間当たりの報酬は減少する。ますます、プログラマの労働条件は悪化し、職業としての魅力がなくなり、優秀な人材は集まらなくなる。生産性の高いプログラマが集まらなければ、産業全体としての生産性はさらに低下する。（図表７参照）。
これが、現在の日本のソフトウェア産業に起きている悪循環である。
悪循環を断ち切り、好循環に変える方法
日本のソフトウェア産業の未来を切り開くためには、この悪循環を断ち切る必要がある。
原点に返って考え直してみよう。まず、プログラマの生産性は個人による格差が大きい。したがって、ソフトウェア産業の生産性を上げる最も簡単な方法は、優秀な技術者、プログラマを数多く集めるのが最も近道である。そのためには、プログラマとして優秀な人材が集まってくる職業にする必要がある。魅力のある職業に必要な条件は、(1) やりがいのある仕事、(2) 十分な報酬、(3) ゆとりのある労働時間だろう。
もちろん好き嫌いや適不適はあるだろうが、そもそもプログラミング自体は創造的で楽しい作業であるから、(1)の条件を満たすのはそれほど難しいことではない。また生産性の高い人材が集まれば、自然と報酬水準は高くなるし、残業問題も解消されて(2)の条件も(3)の条件も満たされるはずである。
つまり、図表８に示したような好循環を作り出せばよいのである。この好循環を作り出す第一歩は、能力に応じた報酬制度、あるいは成果に応じた報酬制度である。ただし、能力や成果を客観的に計測することは難しい。最善の策ではないかもしれないが、この課題に対する解決策は「管理者からみて優秀なプログラマにはそれなりの給与を払う」ではないだろうか。ソフトウェア開発プロジェクトに携わってきた何人もの専門家にインタビューしたが、全員が、できるプログラマはすぐわかると答えている。つまり生産性の正確な計測は難しいが、プログラマとして優秀かどうかは比較的簡単に分かるというのである。それならば能力に応じて報酬を支払うことは不可能ではない。
年功序列的賃金に慣れた企業にとっては大変なことかもしれないが、これは企業が生き残るためにも、日本のソフトウェア産業のためにも必要なことなのである。
注
(1) ここでは、ソフトウェア技術者のことを総称して「プログラマ」と呼ぶ。けっして詳細設計書にしたがってプログラムを書く技術者だけを指すわけではない。
(2) 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)
(3) 出典は、（社）情報サービス産業協会『ITエンジニアのための仕事・市場基準の人材評価システム −平成14年度情報サービス産業雇用高度化推進事業報告書−』平成15年3月。この調査は「ITエンジニア」を対象とした調査であり、サンプルには管理職やコンサルタントも含まれているが、大多数がソフトウェア開発に携わるソフトウェア技術者である。調査期間は2003年1月〜2月で、有効回答数は702件である。
この記事が気に入ったらサポートをしてみませんか？