シグマプロジェクト（ソフトウェア生産工業化システム開発計画）は、実装段階で起こったメインフレーム回帰をきっかけに失速し、全国に設立されたシグマサブセンターはハシゴを外されてしまった。しかしプロジェクトが高々と掲げた目標は、現在も一定の意味を持っている。そればかりでなく、より進化した形で「ネオ・シグマ」とも呼ぶべき取り組みが、深く静かに進められている。シグマプロジェクトがなぜ失敗したかをあげつらう後ろ向きの議論は、生傷に塩を擦り込むようなものだ。何が足りなかったのか、ネオ・シグマの諸相を探ってみよう。（佃均（ジャーナリスト）●取材／文）

動き出したネオ・シグマ

「銀のバレット」を模索

　「ちゃんと勉強してからこいよ！」

　3年前の秋、情報サービス産業協会（JISA）の会長だった佐藤雄二朗氏（アルゴ21創業者）は、若い記者の言葉に声を荒げた。若い記者は、「日本のソフト産業の規模は14兆円。すごいですよね」というようなことを、何気なく口にしたのだ。普段は温厚な佐藤氏が、その程度の言葉に反応するのは珍しいことだ。

　折りからIT需要が急速に高まっていた。中国やインドへのオフショア開発が話題になる一方、業界全体の利益率に陰りがみえ始めた。今こそ業界をあげて、ユーザーやコンピュータメーカーにソフトウェアの価値を訴えていかなければならない、と佐藤氏は考えていた。それによって再び業界全体の利益率を高め、研究開発や人材育成を強化する。

　「われわれが高度化するには、銀のバレット（狼男を倒した弾丸）はない。研究開発と人材育成がこの業界の生命線。その投資が価値の再生産につながっていく」

　JISAの会長として、佐藤氏はシステム構築の工学的アプローチを強く推進していくことを決意していた。にもかかわらず、足下のアルゴ21の業績が振るわなかった。加えて業界の多くの企業は、安易な派遣に走り始めていた。そのことへの苛立ちが、若い記者への反応となって現れたのだ。

それはウィーンで作られた

　このとき佐藤氏が想定していたのは、純粋な民間主導によるネオ・シグマだった、といえるかもしれない。JISAとは別に、佐藤氏はITAという独立系ソフト会社の有志による研究会の座長も務めていた。そこで主題に取り上げられていたのが「VDM」という工学的アプローチだ。VはVienna、日本では「ウィーン」と訳される。1970年代、IBM社のウィーン研究所で研究が進められたことから、その名が付けられた。

　VDMはまたの名を「Formal Method」とも呼ばれ、「形式仕様記述」と翻訳されている。システム開発の出発点である要求仕様を確定することで、プログラムの検証を可能にする手法と言い換えていい。場合によっては、ある程度のプログラムを自動的に生成することもできる。ひょっとすると「銀のバレット」かもしれない。

　CSKシステムズの阿部功二氏は、「いまさら聞けない形式手法入門」（@ITMONOistに掲載）で次のように問いかけている。

　〔ソフトウェアの品質を確保するため、誰もがレビューとテストを行います。しかし、一般的に行われているレビューやテストにおいて、システムが正しく動作することをどの程度保証できているのでしょうか。（以下略）〕

　個人技が発揮できる小規模なシステムであればきめ細かなチェックで品質を確認できるが、複数のチームがパートを分担して開発していく大規模なプロジェクトでは、全体の品質を管理するのは至難の業だ。だからこそ、プログラム作成に入る前に要求仕様を確実なものにしておかなければならない。

　要求仕様とは、どのようなシステムを構築するのか、どのような機能・性能が求められるかを定義するプロセスを指す。それを満たすためには発注者が何を求めているかを聞き出すヒアリング技術や、それを可視化するドキュメント技術が欠かせない。UMLもその技法の一つだ。

　UMLは○や□、△を線で結び、システムの動きや相互の関係を示す。仔細なデータの動き、デスクトップのGUIといった煩雑な情報を排除し、システムを抽象化してモデル化する。だが、要求仕様を視覚化することはできても、品質を保証するものではない。実際、システム開発の現場でUMLは「発注者と受注者の間の情報共有の手段」として使われているに過ぎない。

言葉を定義し曖昧性を排除

　VDMは「記述（表現を構成する言葉）を定義すること」から出発する。言葉というものはもともと曖昧性を含んでいる。例えば「など」といった副助詞、「したがって」「しかし」「または」といった接続詞、「古い」「新しい」などの形容詞、「これ」「それ」に類する代名詞、「約」「おおむね」「すぐに」「とても」などの副詞が絡み合うからだ。

　どういうことかというと、「など」と言ったとき、それが示すのはA、B、Cなのか、D、Eまでなのかはっきりしない。定常的に処理する対象がA、B、C、イレギュラー処理の対象がD、Eと定義すれば、曖昧性は解消する。人の言葉を数値や数式に置き換えるのが要求仕様を確定するプロセスということになる。

　もう一つ重要なファクターは「論理的な振る舞い」の定義だ。火災検知システムと消火システム、漏水防止システムがどのように動作するかを考えるとよくわかる。火災検知器が異常な熱を検出すると、スプリンクラーが放水を始める。その水が床下に滴ると漏水防止システムが水道の元栓を締める。すると放水が止まり、異常な熱源、つまり火を消すことはできない、という矛盾が発生する。

　火災報知機―スプリンクラー―漏水検知器が縦の順列に接続し、同じリソースを使っていると論理的な矛盾が発生する。少なくとも漏水検知器は別の系統に配置しておき、それが動作する条件を厳密に設定しておかなければならない。

　次に、要求仕様記述と要求論理の定義を重ね合わせ、動作の関連性を記述していく。機能ファクター、機能、アクション、設定条件（いつ・誰が・何を・どのように）を関係図に示すことによって、システムが可視化されるというわけだ。この段階でようやくUMLの有用性が理解される。

　こう書くと、VDMを使いこなすのは難しくないように思える。また、データと機能を業務処理手順に沿って図式化する従来のワークフロー型のDOA（Data Oriented Approach）に慣れている技術者は、「取り立てた新規性はない」と指摘する。あえてVDMを採用しなくても・・・、というわけだ。

　たしかに、事務処理などビジネス系アプリケーションはDOAで対応できる。もしシステムに不都合があっても、プログラムにパッチを当てることが可能だし、保守・改造で拡張していくこともできる。だがプログラムの完成時が製品出荷時である組込系プログラムはどうだろうか。演算素子の集積度が飛躍的に向上し、携帯電話に組み込まれているプログラムの総ステップ数はかつての金融オンラインシステムに匹敵する。要求仕様が曖昧でも、あとで何とかなるシステムではない。その品質をどう確保するか。ネオ・シグマのターゲットはまさにエンベデッドプログラムなのだ。