ソフトウェア開発

問題点

近年、ソフトウェア開発業界では赤字案件の続出が共通の問題となっている。原因と目されるものは以下のようなものだが、放置すれば将来の日本のIT産業に大きな影響を及ぼす恐れが出てきている。 （１）元請・下請け構造 （２）人月ベースの見積もりの習慣 （３）SEなどの技術者のスキル不足 （４）外国勢の進出 （５）頻発する開発遅延、システムトラブル

（１） 元請・下請け構造 受託ソフトウェア開発ビジネスはコストのほとんどが人件費なので、稼働率をできるだけ高く維持することが必要で、仕事量を確保することが重要である。そのため中小のソフト会社では上位のソフト会社やシステムインテグレータの傘下にはいって安定的に仕事を確保することが行われている。この元請・下請け構造は仕事の安定的確保のほか、元請けにとっては要員調達の柔軟性などの利点はあるが、下請けは上位会社のコスト面のリスク分散を担わされるといった問題がある。 案件が大きくなるとさらに二次、三次下請けのように多重構造となって、下にいくほどしわ寄せを受け、経営を悪化させる。しかも、仕事を確保するためにこのような下請けに安住することでスキルアップの向上などの努力を怠り、業界全体としてのレベル低下の要因となるという問題も引き起こしている。 （２） 人月ベースの見積もりの習慣 ソフト開発は人手でしかできない労働集約作業なので、何人の人手がどれだけの期間かかわるか（人月）に基づいて見積もりし、契約を結ぶ。その1人月単価はSEなどの生活賃金やSEひとり当たりの平均的な生産性をもとに算出する。人月数は受託した仕事の内容（開発するシステムが提供する機能や難易度）から、どの職種が何人必要になるかを所定の方法や経験によって割り出す。しかし、一般的な基準がないため、ソフト会社によってバラバラで見積もりに大きな違いがでることがある。 また、人月ベースでシステム開発委託契約をした場合、優秀なエンジニアが素早く仕事を終わらせるよりも優秀でないエンジニアが数カ月仕事をした方が儲かるため、質の悪い成果物を高く買わされるという批判も古くからある。しかし一方で、こういった批判に対して論理的な説明ができないためにユーザーの値下げ要求に屈しやすく、赤字体質の原因ともなっている。 ユーザーにも納得性のある対価の決め方は成果物の出来具合によって計るなどが望ましいものの、いまのところ決定打がないのが実情である。これは多重請け構造にも関係していてユーザー、ベンダー共通の問題となっている。 （３） SEなどの技術者のスキル不足 日本のソフトウェア技術者のスキル低下は最近とみに進行しており、このままでは深刻な事態になるとの見方がされている。 現場での問題として、この状態はオープンシステムが普及しだしてから顕著になってきたともいわれている。 これまでの、しっかりしたドキュメントを作ってロジックやデータを机上で十分に検証してからプログラミングする、などのやりかたを使わなくても開発ができるようになったことが主な原因とされる。いきなりコーディングしてコンパイルさせて、エラーがでたら直せばいい、という安直なやりかたが当たり前になり、その結果、1000行あたりのバグの発生は以前に比べて2桁多いといわれている。 多くのソフト会社ではこのような状態を容認しているため、現実に品質不良とそれによる納期遅延および赤字体質が日常化している。 これに対しては大手の各社では品質管理を強化する努力をしているが、中小の下請け企業まではなかなか浸透していないのが現状である。 教育の問題もある。 「30歳以下のITエンジニアの半数は”初心者”」という報告がある。（NikkeiBP　ITスキル調査から） 「学生時代にコンピュータ・サイエンスやソフトウエア工学といった情報工学関連の教育を受けた人は48.6％と半数を下回った。機械や建設，電機などの業界では100％近いと言われるのに対し，IT業界の特殊性が浮き彫りになった。」 「諸外国のITエンジニアは，ほぼ例外なく専門教育を受けている」（大手ソフト会社の人事担当者）。この点を考慮すると，日本のIT業界の国際的な競争力の低さにつながりかねず，気になる数字だ。」 （４） 外国勢の進出 ソフトウェア技術者の分野でも中国を始めとするアジア諸国の進出は著しい。その最大の武器はコストである。日本の30%程度のコストで開発できるという。そのため、日本のソフト会社が大挙して中国との合弁や開発拠点を移したりする（オフショア）中国シフトが進んでいる。しかし、中国に限らず商習慣や国民性の違いから、オフショアビジネスは必ずしもすべてが成功しているとは限らない。とくに日本流を押し通そうとするところは失敗しているそうである。 多くは日本側でプログラム仕様書を作り、プログラミング段階を海外に委託する方法が行われている。国内の下請けに出す代わりに外国に出す形である。そこでよく問題になるのは、仕様書の曖昧さである。日本人どうしであれば多少の曖昧さは吸収するか、口頭での打ち合わせで了解が取れるが、外国人の場合には書いてあることが絶対であって、曖昧なところはないという前提で事を進める。したがって、間違ったものを作ったとしても、仕様書どおりに作ったので自分に非はない、ということになる。このため、日本語を使える外国人の技術者（ブリッジSEなどという）がはいって調整し、本国に伝えるような形をとることが多い。 このような壁はあるものの着実に海外シフトは進んでいる。 また、インドなどの企業が日本法人を設立して上流工程から請け負うケースが増えてきている。日本語の特訓や日本の商習慣を学んでできるだけ日本流に合わせた体制をとり、日本のユーザー企業に直接アプローチする。上流工程は日本法人で作り、それをコストの安い本国で開発し、保守も日本法人で行う形である。条件が合えばユーザーにとっては非常にメリットがある。 このように外国企業が上流から下流までの一貫したビジネスを技術力とコストを武器に展開してくれば、これまで日本語の壁や日本独自の商習慣に寄りかかってきた日本のソフト会社は、国際競争力を問われるようになってきわめて苦しい状況に陥る。 ユーザー企業もこれまでの情報投資を見直し、費用対効果をきびしく求めてくる情勢のなかでこの業界はますます安閑としてはいられない。 （５） 頻発する開発遅延、システムトラブル 多くのシステム開発の現場で、開発遅延や稼動後のトラブルが発生している。 ほとんどの原因は、 ・上流工程（要求定義、設計）に時間をかけすぎた ・開発途中で仕様の変更、追加が発生した ・バグが多く、手戻りが発生した ・テスト期間が十分にとれずに見切り発車した に集約される。 上流工程の遅れの原因はユーザー側の要求定義が決まらず、予定の期日が大幅にずれ込んでしまったり、要求定義が決まっても曖昧なところが多く、ベンダ側も詰めを十分にしないまま開発をスタートしてしまうため、途中で変更、追加が続出するということ。さらに、プログラムの品質不良のため、手戻りが頻発して時間を浪費することなどである。 最近の案件は納期が短く、しかもサービスインの期日厳守であるため、スケジュール上に余裕がなく、あとの工程ほど厳しい状況に置かれる。とくにテストにしわ寄せされる結果、テスト不足によって稼動後にトラブルが頻発する。 だいたいがこのようなパターンで、多くの案件で同じような状況に陥っている。さらに極端なハードスケジュールから長時間労働による健康障害やストレスによる精神障害などの問題が深刻化している。 プログラムの品質不良は設計書の不備や技術者のスキル不足によることは明らかである。そして、その背景には多重請けのような構造がある。 要求定義は多くはユーザー側に問題がある。その背景にはユーザー企業における情報システム部門が弱体化したり分社化されたりで、システム要件をまとめきれないという実情がある。ベンダ側も納期の制約があるとはいえ、不十分な仕様のまま着手するという問題もある。 このような事態を防ぐにはベンダ側だけでなく、ユーザー側の意識や体制改善も必要である。最近は開発プロジェクトにおけるユーザー側の発注者責任を重視して、プロジェクトマネジメントをユーザー側でおこなうべき、とする動きもあるが、まだ実例は少ない。