IT業界のグランドデザインを問う SIerの憂鬱

<IT業界のグランドデザインを問う SIerの憂鬱>第26回 総括なきシグマプロジェクト

2007/10/08 16:04

週刊BCN 2007年10月08日vol.1206掲載

 シグマプロジェクト(ソフトウェア生産工業化システム開発計画)は、第2段階として全国にシグマサブセンターが設立されたものの、実装段階で起こったメインフレーム回帰をきっかけに失速してしまった。SI業界を襲ったバブル崩壊の衝撃が、その事業化に大きなブレーキをかけ、国家プロジェクトに持ち込まれた成果主義が施策を萎縮させた。総括が行われないまま幕を降ろしたプロジェクトが「失敗」とされる理由は何なのか、その成果とは何だったのか、本紙なりに検証してみよう。(佃均(ジャーナリスト)●取材/文)

評価すべき4つの成果

メーカーの下請け強化策


 まず、シグマプロジェクトの「その後」を振り返っておこう。

 1985年度に意気揚々とスタートしたプロジェクトは、全国にシグマサブセンターを設立する計画が明らかになった87年度に、ピークに達した。東京・晴海のメインセンターと通信回線で結ぶことで、地域におけるソフトウェアの分散開発を可能にしようというものだった。サブセンターは1年に7-8か所、5年間に計35か所が指定されることになり、地域の情報サービス業団体は行政機関を巻き込んで誘致に沸き立った。

 ところが、東京に設置するメインセンターに国産メインフレームを導入するという話が持ち上がったころから、シグマプロジェクトが急に失速する。SIer各社がシグマ開発本部に出向させていた研究員が2線級、3線級にレベルダウンしたこと、SIerの自立とソフト開発の生産性向上というプロジェクトのコンセプトがコンピュータメーカーの下請け構造強化に転換してしまったことなどが要因だった。

 東京のシグマセンターに国産メインフレームを導入するということは、ソフト会社が国産メーカーの開発環境に縛られる。しかも、生産性の向上を理由に、コンピュータメーカーは発注価額を切り下げてくる。UNIXによるダウンサイジングとTCP/IPネットワークによる協調型分散開発は、自社に何のメリットももたらさない、と多くのソフト会社が考えた。

バブル崩壊が追い打ち


 90年春、シグマプロジェクトの終了とともに開発本部は事業会社(シグマシステム)に改組することになった。財政当局(当時、大蔵省は通産省の予算管理部門)が求めたのは「成果」だった。成果は数字で示されなければならず、それはシグマプロジェクトの事業会社の売上高やサブセンターの受注実績にほかならなかった。

 SI業界のモチベーションがはるかに薄れていたなかで、バブルの崩壊が追い打ちをかけた。システム開発案件が急減し、ソフト業界には大量の余剰人員が出た。92年、ソフト業が雇用調整助成金制度の適用業種に指定されるのと並行して、産業構造審議会は「ソフトウェアの不当廉売防止と正常なソフトウェア市場形成のための緊急提言」を取りまとめた。それまでの相場をはるかに下回る価額での受注が相次いだのだ。

 事業化から5年目の95年、シグマプロジェクトは「失敗」の汚名をかぶったまま、事実上、終了した。インターネットの利用が広がり、Windows95の登場でITの利用環境が急速に変化した年と交差した。バブル崩壊の衝撃がようやく薄れ、システム開発案件が上向きに転じたとき、最も必要であるはずのソフトウェア開発環境整備プロジェクトに幕が降ろされたのは、何とも皮肉な話だった。

 のちに、事業会社を閉鎖して日本情報処理開発協会(JIPDEC)に移った辻岡健氏(元シグマシステム社長)は、経済の状況やソフト業界の理解度などさまざまな要因があったことを認めつつ、「研究開発の成果を、いきなり売上高で示すのは難しい。ソフトウェア開発環境の整備は、長期的な見地で取り組むべきものではなかったか」と語っている。

「なかったこと」では済まない


 シグマプロジェクトの終焉は、66年にスタートした「大型プロジェクト」の終結でもあった。大蔵省は85年度にさかのぼって予算執行の詳細を洗い出そうとし、多くの関係者から事情を聴取した。予算の一部が不明朗な使途に流れたのではないか、という疑いすらあった。

 それだけに、シグマプロジェクトに「失敗」のレッテルが貼られたことは、通産省にとって大きな汚点として記憶された。情報化関連施策を担う官僚もSI業界も、「なかったこと」にしてしまった。現在でも「シグマ」の3文字を口にすることは、経済産業省内ではタブーに近い。

 だが、「なかったこと」で済む話ではない。いや、250億円の予算がどのように使われたかが問題なのではない。国の予算を投入して行う技術研究開発に、成果主義を持ち込むこと自体が間違っている。利益を出せないまでも、十分な効果が確実に期待されれば、国の予算を投入するまでもなく、民間が自己責任で進めるだろう。「事前に落とし穴を探り、共通の技術基盤を形成する」のが大型プロジェクトの本質だったはずではないか。

 残念だったのは、シグマプロジェクトそのものが総括されなかったことだ。「失敗」の衝撃があまりに大きかったためだが、すべてがダメだったわけではなく、むしろ目に見えない多大な成果があった。1つはソフトウェア開発プロセスへの認識が高まったことだ。SLCP(ソフトウェア・ライフサイクル・プロセス)が策定され、JISに登録されたのは97年のことである。

 もう1つは、構造化プログラミングの技法が定着したこと。シグマプロジェクトを通じてシステム設計の構造化とソフトウェア・モジュールを学んだ技術者が、そこで得たノウハウを実務に適用していった。それは95年を境に急浮上したオブジェクト指向、スパイラル型のアジャイル開発手法と結びついた。

 3つめは工学的にシステムを構築するには、ユーザー(発注者)の理解と人材育成が決め手になるということを、SI業界が学んだことだった。ユーザーの理解を得るには、ソフト技術者が持っている技術や知識、ノウハウを客観的に評価する手法が必要だった。情報処理技術者試験に抜本的な見直しが行われ、ITスキル標準(ITSS)が提示されたのも、見方を変えればシグマプロジェクトの成果といっていい。

 4つめは、60年代から模索が続いてきた「システム構築における工学的なアプローチ」(ソフトウェア工学)が、体系的に整理されたことだった。ソフトウェア工学はプログラム開発ツールや適正な積算に限った話ではなく、データ構造の定義、ドキュメントの記述、プログラム作成・修正の管理、システム開発・運用プロセス、役割と責任の分担、技術者の育成などにかかわる広範なテーマであり、それが契約モデルにつながるという認識が形成された。

 情報処理学会を中心に全国の大学研究所で研究が進められているUML、文部省やIPS/SECなどによるエンピリカル・アプローチ、CSKグループなどが提唱している形式仕様記述手法「フォーマル・メソッド」などは、その具体的な〔解〕に違いない。
  • 1