なぜ、日本のソフトウェア品質は悪いと言われるのか？

日本の技術力の高さは日本人であれば皆知るところである。持ち前の勤勉さを武器に戦後まもなく復興し先進国に名乗りを上げた。IT産業もその限りではなく、年々売り上げを伸ばし、2011年には約20兆円(注)を売り上げている。一方で、現在グローバル戦線において苦戦を強いられているのもまた事実だ。ガラパゴスケータイに象徴されるような日本の習慣に特化していて海外ではなかなか売れないということが起きている。そうした中でアメリカなどと比較し品質が悪いという声も聞かれるようになった。
そこで日本のIT産業の特徴について解説しつつ、日本のソフトウェアの品質は本当に悪いのか、詳しく述べていきたい。

(注)出展　 IT産業の動向 | IT Job Gate（情報サービス産業協会）

労働集約型ビジネスと知識集約型ビジネス

世界で利用されているソフトウェアはどのようなものがあるだろうか。そう考えたとき頭に思い浮かぶ製品の多くはアメリカのソフトウェア会社の製品だろう。Microsoft、Apple、Googleなど巨大企業が思い浮かぶ。それでは日本とアメリカでは一体どのような点が違うのだろうか。
日本とアメリカの違い、その一つとしてソフトウェア会社のビジネス形態が大きく異なっていることがあげられるだろう。日本の主流は労働集約型産業、アメリカの主流は知識集約型産業とそれぞれ呼ばれている。

労働集約型産業

事業の機械化が難しく、主要な部分を人の労働力が担っているビジネス形態であるそのため必要な人件費と作業時間によって製品の見積もりが行われている。
このビジネス形態を端的に表すのであれば「ローリスクローリターン」だろう。ユーザー企業からの依頼を受けて開発するため、最低限依頼された機能さえ作れていれば期日までに納品することができる。最低限の品質で、その後の取引が続くかは別として、とりあえずの対価を得ることが可能なのだ。あらかじめ収益が確保されているビジネス形態であるために大きな損を出すことが少ない。
一方でいくら品質を良くしたとしても、見返りが少ないというのも特徴だ。報酬は事前の契約で定められているため、納品されたソフトウェアを用いてユーザー企業が儲かったからと言って利益の大幅増は見込めないのだ。
このビジネス形態をとっている企業は収益を伸ばすことが難しい。受注できる件数にも限界があり、売り上げを伸ばすには社員数を増やして受注件数を増やすしかない。もちろん発注する企業の数も大きく増えることはなく、新人を増やすにも限度がある。そうなると利益を上げるために人件費を削るという発想につながりかねない。
日本のソフトウェア産業がこのビジネス形態を採用している理由として、終身雇用制度が示すように会社が長年存続することを重視する傾向がある。この慎重さは日本が海外にサービス展開に積極的でないということにつながってくる。日本だけでもビジネスがある程度成り立ってしまうがために博打を打とうとはしてこなかったのだ。

知識集約型産業

労働集約型産業とは正反対の「ハイリスクハイリターン」がこのビジネス形態だ。主に研究や開発、デザインといった専門的な判断を必要とするサービスを提供しており、ヒットすれば大儲け、ヒットしなければ大損といった、いかにもアメリカらしいフロンティア精神に溢れている。労働集約型との大きな違いとして開発する製品への意識の違いがある。労働集約型では事前に製品開発の対価を決められているのに対し、知識集約型では開発努力によって対価を増やすことができるのだ。もちろん良いサービスがすべて売れるわけではないのだが、ヒットした際の利益は大きなものとなるだろう。
ハイリスクとは表現したものの、工場や施設を作らなければならないような産業と比較するとソフトウェア産業の初期コストは少ない。優秀なエンジニアとPCさえ用意できれば仕事を始められるのだ。
これまでのように日本だけで商売するのであれば労働集約型で問題はなかったのだろう。競争相手が少なく、経済力があるため安定していたのだ。しかし、現状は日本だけでなく海外のソフトウェア会社が競合相手となっている。知識集約型によって産まれた尖ったサービスに安定志向の日本のソフトウェア産業は対抗できていないのではないだろうか。

発注者・受注者間の取引・契約関係力が弱い

日本とアメリカでは、エンジニアの勤め先から大きく異なっている。日本のエンジニアの多くはIT企業に勤めており、ユーザー企業から依頼を受けて開発を行う。そのため大手企業の運営するサービスであっても、実は全く名前が知られていないような会社が開発したということが起こるのだ。
一方アメリカでは、エンジニアの多くが勤めているのはユーザー企業だ。自社サービスの開発に力を入れており、成功失敗に左右されるというのも先ほど述べた通りである。
この違いは発注者・受注者の関係に大きな影響を及ぼす。アメリカでは発注者・受注者は共に同じ会社の人間だ。コミュニケーションはスムーズに取ることができ、遠慮なく意見交換を行えるだろう。しかし、日本では受注するIT企業にとって発注元のユーザー会社は「お客様」だ。和を重んじ、お客様を大切にする日本社会においては、受注側と発注側の間に明確な力関係が生まれてしまう。日本のユーザー企業はIT部門を持っていないことが多く、ITについて詳しくない。そのため、無茶な要望をしてしまうこともあるのだが、弱い立場のIT企業はそれを断るのは難しい。加えてIT企業はITの専門家だから、できて当然という思考が働いてしまう。
こう考えると日本でもユーザー企業が開発すればよいと思うのだが、そう簡単には解決できない。
ユーザー企業は常に開発しているわけではないので、状況ごとに必要な人材は異なる。日本は終身雇用の習慣が根強く、簡単には人員の整理ができないので、人材の入れ替えが起こるIT部門の運用は難しい。また人材の流失が少ないということは、中途社員の確保が難しくなるということだ。かといって新人を育てるのはコストがかかりすぎる。
このような理由で日本のソフトウェア産業は自社サービスの開発に踏み出せていないのだ。

柔軟性に欠ける開発手法

日本のソフトウェア産業では開発手法としてウォーターフォール型が一般的だ。1970年に提唱され今なお活用されている手法である。しかし、これもまたやや時代遅れの手法となっている。

出典　ITpro「開発プロセスを学ぶ」

この手法は、まず始めに要件定義、それから設計、プログラミング、テストという手順を踏んで納品に至る。各手順を滝から落ちるように順番に進めていくことから、手戻りがないことが特徴だ。

メリット

計画が立てやすい
あらかじめ作業手順が決まっているので、いつごろ完成するのか目途が立ちやすい。
進捗管理できる
全体の計画が決まっているので、どの手順まで進んでいるのか確認することで進捗状況を把握できる。
ドキュメント(書類)ベースの開発ができる
ドキュメントを完成させてから次の手順に移るため、開発が行いやすい。

ウォーターフォール型はこのように管理を行いやすいというのが最大の特長だ。スキルの低いエンジニアやマネージャーでも指標となるドキュメントが多いため、スムーズに作業に携わることができるのだ。
しかし、そのしわ寄せも当然生まれている。時代遅れと言われているのは以下のデメリットがあるからだ。

デメリット

柔軟性に欠ける
手戻りがないので要件定義のミスや追加機能の要望があっても対応が難しい。
ドキュメント作成が負担
作業を進めつつドキュメント作成も行わなければならないので負担が重い
リリースまでに時間がかかる
手順を全て完璧に終わらせなければリリースできないので時間がかかる

日々技術が進歩する現代において、時間がかかる、柔軟性に欠けるというのは致命的だ。いくら要件定義通りのソフトウェアができたとしても、もしそれがもう必要のない機能ばかりであれば、品質の良いソフトとは言えないだろう。
このようなデメリットがあるため、新たな手法としてアジャイル開発やRADなどが注目されてはいるものの、手法を熟知したスキルの高いマネージャーが必要であり扱いが難しい。特に日本のように経験の少ないエンジニアが多いと思うようにいかず新たな手法を導入しても失敗してしまうのだ。

ITゼネコン（多重下請け構造）

ウォーターフォール型を採用する際に、一つの企業で初めから最後まで開発を行うという例は少ない。大規模なソフトウェアであれば、なおさら一つの会社では処理しきれない。そのため、理がしやすいウォーターフォール型では、各手順をどんどん下請けに発注していく多重下請け構造が生まれやすい。建設業界などでおなじみのゼネコンがIT業界にも存在しているのだ。
このITゼネコンは以下のように多くの問題を抱えている。

適切な対価が得られない
開発を受注した企業は利益を出さなければならない。限られた予算で下請けに発注するため、当然下請けの得られる対価は少なくなる。さらにそこから発注、と下請けが続けば作業量に見合わない対価になってしまうのは明らかだろう。しかし断れば他の企業に仕事を取られてしまうので受けざるを得ないのだ。
交換可能なモノ扱い
下請けの企業はウォーターフォールの手順を進めるための歯車でしかない。とびぬけたスキルはあまり必要とされないため、簡単にほかの企業に仕事を奪われてしまう。結果として安い費用、作業の速さなど、エンジニアに負担を強いる形で他社と競うことになる。
エンジニアが育たない
下請けの企業に任されるのは誰にでもできる、ただ時間がかかる仕事ばかりだ。加えて、任される仕事は全体のほんの一部で何のための仕事なのかわからないこともある。このような環境ではスキルアップは望めず、歯車で終わってしまうこともある。
法的にグレー
多重派遣はもちろんのこと、労働基準法・職業安定法により多重下請構造が法に抵触する可能性がある。

■職業安定法
（労働者供給事業の禁止）
第四十四条　何人も、次条に規定する場合を除くほか、労働者供給事業を行い、又はその労働者供給事業を行う者から供給される労働者を自らの指揮命令の下に労働させてはならない。
■労働基準法
（中間搾取の排除）
第六条　何人も、法律に基いて許される場合の外、業として他人の就業に介入して利益を得てはならない。

ではなぜ、ITゼネコンが生まれているかというと、あくまでも業務委託であれば、違法にはならないからだ。これが発注者から請負労働者へ直接指示を行うとなると、法に抵触することになる。しかし、ユーザー会社に常駐して開発を行う場合、直接受注した企業と下請け企業とは明確な区別をしていないことが多く、違法な状況が放置されている可能性がある。
ITゼネコンの大きな問題点は上記の通りだ。そして、これはアメリカも通ってきた道でもある。1990年代までアメリカにもITゼネコンが存在したのだが、オフショアが浸透し下請け会社が皆淘汰されてしまったのだ。アメリカの後追いをすることが多い日本だが、国内ITゼネコンもアメリカと同じように淘汰されるのだろうか。

まとめ

日本のソフトウェア品質は決して悪くはない。

アメリカでは過去に労働集約型ビジネスモデルは崩壊している。オフショアの成長により、米国内の中小企業が姿を消したためである。それでは日本はどうだろうか。
アメリカと比べ日本の企業は品質の高いものを求めており、オフショアよりも日本製のものを求めている。日本のIT企業は多少時間がかかっても品質の良いソフトウェアを製品として送り出しているのだ。ウォーターフォール型の開発は完璧を求める日本企業の意識の表れに他ならない。
日本製の品質の良さは現状の構造には多くの問題がある中、エンジニアの努力によってなんとか保たれている。エンジニアのスキル育成と正当な対価を得られる仕組みづくりは急務であり、コストの安い諸外国に技術面でも抜かれることが危惧される。