ソフトウエアの仕様は現在,多くが自然言語で書かれている。
形式も人によってバラバラだ。
自然言語の持つあいまいさや仕様記述の方法論の不在が
仕様の解釈ミスを助長し,ソフトウエア開発の手戻りを招いてきた。
仕様を記述するには「形式的な仕様記述言語」という専用のツールがある。
日本ではほとんど認知されていないが
開発の上流工程の重要性が叫ばれる今は,形式的な仕様記述の使い時だ。

 「今,ソフトウエアの仕様書や設計書には,何の制約条件もない。建築や土木分野では仕様や設計図の書き方が詳細に決まっているのに,ソフトウエア開発では,未定義の塊を『仕様だ』といって実装者に渡している状況。これでは,実装者は勝手に解釈してくるに決まっている」――。長年,エンタープライズ分野でソフトウエア開発を主導してきたCSKホールディングス 取締役の有賀貞一氏は,現在のソフトウエア開発における仕様品質の低さについてこう分析する。

 一般にプログラムの実装者は,仕様書を見ながらコーディング作業だけを行っていると思いがちである。ソフトウエア開発工程の説明図でも「仕様策定から実装に向かって真っすぐ矢印が引かれていることが多い」(あるソフトウエア技術者)という。この点について,形式的な仕様記述を経験したソフトウエア技術者は口をそろえてこう言う。「それは間違った表記だ」と…。

 例えば実装者は,仕様書を見ながらプログラムを記述する過程でさまざまな迷いを感じる。仕様書を読むだけではプログラムの実装形態を決め切れず,どうしても仕様策定者にじかに会いに行き,今回のソフトウエアの開発意図や細かい動作の詰めを確認したくなるものだ。仕様書が実装者の担当するモジュールごとに分類して書かれてあることはまれなため,実装者から見ると仕様書のどの部分が自分の担当するモジュールに関連するのか,仕様書を読む限りでは分からないこともある。

 結果として,プログラムの実装者はその職種名とは裏腹に,仕様策定者へのヒアリング作業を通じて,仕様の精査の役割も担ってしまっているのが現実なのだ(図1)。前述の開発工程の説明図でいえば,矢印は双方向に描くのが正確である。「実装者というのは人数が多いし,コミュニケーションやヒアリングのスキルもバラバラ。質が一定でない実装者に仕様精査という身に余る作業を強いているからこそ,ソフトウエアの品質がエンジニアリング的に作り込めないのだ」(CSKの有賀氏)。

【図1 自然言語の仕様では解釈の誤差が膨らんで蓄積してしまう】 形式的な仕様記述では,事前/事後条件,不変条件などを明確に書き出す必要があるため,重要な前提条件などが埋もれにくい。チーム内で仕様をもんでいく際も,解釈の差が生じにくく議論がかみ合いやすい。
図1 自然言語の仕様では解釈の誤差が膨らんで蓄積してしまう
形式的な仕様記述では,事前/事後条件,不変条件などを明確に書き出す必要があるため,重要な前提条件などが埋もれにくい。チーム内で仕様をもんでいく際も,解釈の差が生じにくく議論がかみ合いやすい。
[画像のクリックで拡大表示]