国家プロジェクトの失敗

 80年代の初めに、通産省はソフトウエア技術者不足に対処する目的で、250億円もの予算を注ぎ込み、「Σ(シグマ)計画」を発足させた。「ΣOS」と呼ぶ、ソフトウエア開発者が自由に利用できる開発基盤を整備し、ΣOS上で作ったツールやソフトウエアを交換可能にしようという狙いであった。しかし、Σプロジェクトは五年後に何の成果も出せないままひそかに幕を閉じた。

 自由で先進的な考えを持つソフトウエア技術者は、ソフトウエア開発者や研究者が自由に情報やツールやアイデアを交換できる共通プラットフォームを求めていた。彼らは、草の根で普及した「BSD版UNIX」という基本ソフトを使った全国的なネットワークの構築を目指した。彼らはワークショップに集い、Σ計画の要求仕様というべきものをまとめて提出したが、それはものの見事に無視された。

 結局、日本共通の開発基盤となるべきΣOSは、AT&T(米国電信電話)が開発した「UNIX System V」を基にすることになった。ところが、各コンピューターメーカーが個別にAT&Tと交渉して開発を進めたため、System Vを基にしているものの、互換性のないΣOSが、しかも複数個できるという事態に陥った。こうしてUNIXのまがい物がたくさんできあがった。

 しかも大蔵省を説得するためにプロジェクトの目的に加えられた「生産性向上」という名目の下で、コンピューターメーカー各社は、自社でさえ使われない開発ツール類をΣ用に焼き直し、成果物として押し込んだ。当然、各社のツール間に互換性はなかった。大手コンピューターメーカーは、ソフトウエア技術者の想いとは関係なく、250億円という国家予算を争って食いつぶした。

 技術者一人ひとりの自覚の上に、相互が刺激し合い、ソフトウエアを開発する。そのための共通の場を用意する。こうした共通環境を建設するという理想は、ここに完全についえ去った。後には、相互に刺激を受ける機会の乏しい、人海戦術的開発に従事する60万人のプログラマーが残った。Σ計画の失敗で、日本は、ソフトウエア産業の基盤を強化するまたとない機会を逃した。

 この間、ヨーロッパ諸国では、「Espr IT」と呼ぶプロジェクトで、日本のΣ計画と同じような目的のソフトウエア開発環境「PCTE (Portable Common Tool Environment)」を開発していた。Espr ITプロジェクトが完了した頃、筆者はたまたまヨーロッパのいくつかのソフトウエア会社を訪れ、各社がPCTEに基づいて開発ツールを作り販売しているのを知った。他にもいくつかの成果があり、ヨーロッパ諸国が日本より公的資金をはるかに有効に使っているのを知った。

技術伝承の断絶

 メインフレーム全盛時代は、メーカー各社がユーザー企業を囲い込んでおり、多種多様な用途に耐えるように、コンピューターハードウエア、基本ソフトウエア(OS)を自社で開発しなければならなかった。自己流で非効率な部分があったとしても、ハードウエア生産で培ったエンジニアリングをソフトウエアに応用し、直面する品質や生産性の問題を解決してきた。

 ところがメインフレームからクライアントサーバーへと技術の世代交代が起きた。このときに、経験を積み上げてきた技術者は表舞台から姿を消し、新たな技術で育った人たちに置き換わり、技術の伝承ができなくなった。

 ちょうどその頃、ソフトウエアの開発プロセスを改善する国際的な動きが目立ってきた。87年には、ソフトウエア開発能力の成熟度を示すCMMと呼ばれるモデルが、次いで94年にISO9000が品質マネジメントシステムの国際規格として公表された。日本では、まずISO9000によるソフトウエア開発組織の認証が、次いで国際的なデファクトスタンダードになったCMMによる成熟度レベルのアセスメントが始まった。

 それを契機として、グローバル化の旗印の下、これら外来のモデルに基づく認証獲得、またはレベル達成がブームになった。モデルをソフトウエア開発力の改善のための手段と位置付け、プロセス改善の客観的な成果を知るためにアセスメントを受ける真面目な組織も増えた。

 その一方で、目的と手段とを取り違えて、モデルに書かれたプロセスを表面的にこなし、小さな範囲で要領よく認証を取得し、あたかも会社全体がレベル達成したように宣伝する企業も増えた。認証獲得やアセスメント自体を目的とすると、達成した途端に経営トップが投資意欲を失い、地道な改善活動を妨げる。後には死んだ規格や形式的に書類に記録をするといった無駄な作業が残り、本来の目的と逆の結果をもたらす。このため、認証やアセスメントは、自主的かつ積極的にプロセス改善に挑戦する闘士ではなく、モデルを金科玉条のように扱い、かえってモデルに振り回される、受け身のマニュアル人間を増やした。

 以上のような様々な問題点に加え、日本のソフトウエア開発の産業構造には、決定的な欠陥がある。ソフトウエア技術者の派遣ビジネスである。

 大規模な開発プロジェクトの場合、ソフトウエア開発の仕事は、ほぼ例外なく複数の会社に分割発注される。ところがソフトウエアシステムをサブシステムに分割して請け負わせるケースは少なく、多くの場合、「一カ月いくら」で契約する派遣プログラマーを雇い、プロジェクトチームに組み込む。派遣会社の間で技術者を貸し借りするので、技術者が多層化する。いわゆる多重下請け構造である。発注者でさえ、実際の階層数や末端の会社名を知らない。ある政府のプロジェクトで、危険視された宗教の信者が最下層に参画しており、それに管理者は気付かなかったという話さえある。当然、開発責任は曖昧になる。厄介なことに、派遣契約の多くは請負契約を装っているので、書類だけでは実態はわからない。

 派遣がすべて問題なのではない。現に欧米でも派遣に相当する契約はある。それは、開発規模を決めるビジネスモデルをコンサルタントが作る場合や、不確定要素の大きい革新的なプロジェクトでリスクを避けるために使われる。また、成果物の品質責任を問われない事務的な仕事では、派遣は便利な形態である。しかし、品質に関して重大責任を負うに至ったソフトウエア開発ビジネスで、成果責任を負わない派遣形態がかくも横行しているのは日本だけである。

この先は会員の登録が必要です。有料会員(月額プラン)は申し込み初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら