仕様書の曖昧な表現はご法度

システム設計者の意図は仕様書でしかプログラマに伝わりません

システム設計者の意図は仕様書でしかプログラマに伝わりません

設計者とプログラマが同一人物であれば、作るべきプログラムの内容が分かっています。仕様書に曖昧な表現をしても影響ありませんが、通常は別人。システム設計者の意図は仕様書でしかプログラマに伝わりません。

優秀なプログラマは、疑問点などを整理して設計者に質問し仕様の曖昧さを排除します。しかし、経験年数が少ないと自分なりの解釈でプログラミングしてしまい、結果的に手戻りが発生します。

日本語は多彩な表現ができます。雨が降るにしても「ぽつぽつ」「ざーざー」「ぱらぱら」「しとしと」と、様々な表現が可能です。いくつもの表現ができる日本語で仕様を記述するのは至難の業。

ITベンダーの多くは新入社員に対してプログラミング研修は行いますが、仕様書の書き方について教育は行われていません。先輩の書き方をまねて勉強するしかなく、個人まかせになっているのが実態です。曖昧さがある日本語ですので誤解や思い込みが常に発生します。

例えば、「画面で入力チェックを行い、不適切な文字が入力されていたらエラー表示する」という仕様について考えてみましょう。

不適切な文字とは何でしょう。エラーはどのような内容を表示したらよいのでしょうか。文章以外に入力項目毎の別表を作って曖昧さをなくします。ある項目が入力された場合に、別の項目も入力されないとおかしい場合は関連チェックとして記載します。

(入力項目)日付
数字チェック&妥当性チェック(月は1~12のみなど)を行い、エラー時は日付エラーを表示する

エラー表示については指針をもうけ全画面共通にしなければなりません。画面によって日付エラーや数字エラーなど、様々なメッセージが表示されたらユーザーは戸惑うだけです。日付チェックに”うるう年”を考えるなら全画面共通にします。

形式手法(フォーマルメソッド)による記載

形式手法記述言語を使いこなすには教育が必要

形式手法記述言語を使いこなすには教育が必要

仕様書の記載には形式手法(フォーマルメソッド)という方法もあります。日本語ではなく形式仕様記述言語を用いて表現します。曖昧さのない言語で表現することで思い込みを排除し、手戻りをなくす手法です。ただし形式仕様記述言語を導入すれば、全てがかなえられるような魔法の道具ではありません。

まず形式仕様記述言語を、関係する全てのメンバーが使いこなせなければなりません。日本語と違い、見ただけでは暗号のようなプログラミング言語です。理解し、記述できるように教育が必要となります。自社だけでなく、協力会社を含めてプロジェクトを推進する時は協力会社にも教育が必要です。

形式手法記述言語を用いて仕様を記述する場合、従来の日本語による仕様記述よりも工数が多く掛かります。これは数学的に厳密な仕様を作るのに時間がかかるためです。ただし設計の質が向上しますので後工程での手戻りを減らし、プロジェクト全体の工数を減らせます。3倍程度、生産性が上がった事例や大規模プロジェクトで導入した事例があります。形式仕様記述言語からプログラミング言語を自動生成することも一部で行われています。