「ソフトウェアの組み立て方」はソフト業界の古くて新しいテーマだ。ほぼ5年ごとにその必要性が叫ばれ、時に「技法」と呼ばれ、あるいは「方法論」と名を変え、そのつど、それなりに注目度は高まった。だが残念ながら、そのたびに大きな成果をあげることがないまま関心が薄れ、結果としてSI業界はマンパワー依存から抜け出していない。人月単価をベースに残業代が追加支給されることになり、ソフトウェアの品質や生産性を追求するより、いかに多くの時間をかけるかに重きがおかれたためだ。しかし、マンパワー依存からの脱皮に、業界は真正面から向き合わなければならない時がきた。（佃均（ジャーナリスト）●取材／文）

脱マンパワーができない理由は

ソフトウェアは工学の対象か

　「ソフトウェア工学」という言葉が意味を成すのか──という疑問がある。そもそも属人性が強いシステム設計やコンピュータプログラムに、製造業や建設業で一般的な構造解析、耐性分析が適用できるだろうか、というのが主な理由だ。コンピュータプログラムで数値化できるのは、技術者1人／1時間当たりで記述できるステップ数、総ステップ数当たりのバグ発生率といった程度ではないか。

　この疑問は1980年代初頭に国際ソフトウェア工学会議（ICSE）で提示され、それをきっかけに、研究の主テーマが「ソフトウェアの工学的積算手法」に転換した。大規模システム開発のウォーターフォール（滝）モデルにおけるステップ数をどう見積もるか、それにはファンクション（機能）ごとに難易度を勘案して点数で評価し、一定の係数をかけるファンクション・ポイント（FP）法が有効とされた。またバグの発生率については、ハインリッヒの法則が有用と考えられている。1件の重大なバグの後ろには29件の小さなバグがあり、さらにその背後に300のバグ予備軍が控えているという統計学的な考察だ。

　ただFP法もハインリッヒの法則も、プログラムの作り方にかかわる理論ではない。コンピュータプログラムも人間の生産物である以上、対象に応じた作り方（工法）があって然るべきではないか、というのが、「ソフトウェア工学」を推進する立場の主張である。その意味でいえば、ASSEMBLAやCOBOLのソースコードを自動生成する第4世代言語（4GL）は、ひとつの「解」だったといっていい。

モジュール化と構造化設計

　国内で「システム開発の工学的アプローチ」ないし「ソフトウェアの組み立て方」に関心が高まったのは、70年代後半の「ソフトウェア・モジュール」が最初だった。機能ごとにコンピュータプログラムを部品（モジュール）化し、部品と部品を組み合わせてシステムを構築する、という考え方だ。

　このためにソフト業界は通産省（当時）の支援を得て技術研究組合を結成、それが国策のソフト技術開発会社「協同システム開発（JSD）」に結びついた。JSDは出資企業から出向した技術者で構成され、ここでソフトウェアの構造化モデルが研究された。部品化したプログラムをどのように組み立てるか、それにはシステムを分析して構造化しなければならない、と考えられた。

　80年代に入って、情報産業界は空前の発展を遂げた。都市銀行の第2次オンラインシステムを中心に、超大型メインフレームが相次いで導入され、システム規模が急速に膨張した。

　「ハードウェアの時代」のようにみえるだろうが、実はリレーショナル型データベース管理システム（RDBMS）とネットワーク・アーキテクチャ、COBOLコンパイラなど、ソフトウェアの進化がメインフレーム全盛期をもたらしたのだ。

　この時、SI業界はソフトウェア工学を見限った。プログラムの生産性をあげるより、現場の開発要員が毎月200時間以上の就労実績を残したほうが、収益のメリットがあったためだ。月額80万円の技術者が毎月40時間の残業をすれば、実入りは100万円を超える。ソフト会社の経営者は従業員に、「とにかく現場に居残っていろ」と露骨な残業を指令することも珍しくなかった。生産性や品質はそっちのけで、いかに多くの要員を投入し、いかに多くの残業代を稼ぐかが、ソフト業の生業になっていく。

　メインフレーム全盛期に登場した工学的アプローチのひとつが、前述した4GLだ。英国グラスゴー大学でソフトウェア工学を研究していたジェームズ・マーチンが提唱した「プログラマなしのプログラム開発」が喧伝され、4GLがそれを実現するツールとして脚光を浴びた。だが4GLはソフト業界にとっては両刃の剣だった。「それを使うと売り上げが下がる」と多くの経営者が考えた。

　85年のこと、通産省は「西暦2000年にソフトウェア技術者が100万人不足する」という衝撃的な予測を発表した。当時、情報サービス業界の就労者総数は34万人だったから、差し引き65万人の不足を何らかの方法で埋めなければならない。電力会社、金融機関、鉄鋼業、自動車産業などの代表的な企業のソフト需要予測に基づいた数値だったが、実はソフトウェア・モジュール技術開発組合の事業を継承するのがねらいだった。

　通産省が取り組んだ「ソフトウェア生産工業化システム」がそれだ。俗に「シグマプロジェクト」とも呼ばれる。モジュール化したプログラムを大規模なDBMSに登録・蓄積し、全国どこからでもネットワークで利用できるようにする。JSDが研究してきたシステム設計構造化技法とソフトウェア・モジュール技法を集大成して実用化する。このために国家予算250億円が用意された。

シグマプロジェクトで沸点

　シグマプロジェクトの研究開発には、受託系SIerの大半が何らかのかたちで参加した。目白押しの大規模システム開発で要員が逼迫するなか、各社は社内ピカイチの技術者を研究開発チームに出向させ、競ってUNIXワークステーションを導入した。オムロンのLuna、ソニーのNEWS、サン・マイクロシステムズ社のエンジニアリング・ワークステーションが飛ぶように売れた。それは一方で始まっていたオープンシステム化とダウンサイジングの予兆でもあった。瞬間的にみれば、日本におけるソフトウェア工学が沸点に達したときだった。

　70年代後半のソフトウェア・モジュール、80年代前半の4GL、後半のシグマプロジェクトという具合に、「システム開発の工学的アプローチ」ないし「ソフトウェアの組み立て方」への関心は5年ごとに高まった。逆の言い方をすると、5年と長続きしたことがなかった。それはハードウェアの技術が5年ごとにリニューアルしていたことと無縁ではない。なぜ5年かといえば、ハードウェアメーカーがユーザーを囲い込んでレンタル契約を更新するための戦略だったからだ。

　70年4月に発表されたIBMシステム／370から81年1月のIBM308Xシリーズに代表されるように、メインフレームは仮想記憶方式、TSSモード、ネットワーク・アーキテクチャ、DBMS、COBOLコンパイラと発展し、そのたびに新機種へのリプレースと新規導入が喚起された。それがシステム構築需要に結びつき、ソフト業の急成長をもたらした。シグマプロジェクトこそ、脱ハードウェアのチャンスだったのだ。