「システム開発プロジェクトでは一般に、業務で扱う実データを使うのは、検証するために必要になるテストフェーズからだ。でもそれよりもっと前の、基本設計フェーズでも活用すべきだ。そうすれば、仕様漏れによる手戻りを格段に減らせる」。

　日経SYSTEMS2月号の特集記事「システム要求仕様の固め方」の取材を重ねて、こういう思いを強くした。実データを活用することで仕様の漏れを設計の初期段階で防いだケースを多く取材できたからだ。

　この特集でテーマにしているシステム要求仕様とは、要件定義フェーズが終わって基本設計フェーズに入る段階で、設計者が詳細化する仕様を指す。

　要件定義書に書かれた仕様のまま、設計や開発、テストに取り掛かっても「仕様として書かれてある内容では不十分だ」「仕様に漏れがある」といったことに気付くことは少なくない。そうなると、仕様確認の手間や手戻りが発生してしまう。

　そういった確認の手間や手戻りを防ぐには、設計作業を始める前に、仕様の曖昧さや漏れをなくしてシステム要求仕様をまとめることが大切だ。そこで特集記事の取材では、要件定義書を受け取った設計者がどんな工夫を凝らせば、仕様の曖昧さや漏れをなくせるかを探った。

　特集記事では取材結果のうち、要件定義フェーズの成果物の内容から、仕様の曖昧さや漏れを見つける工夫を紹介している。ここでは、記者が冒頭のように強く実感したケースを三つ取り上げる。特集記事の内容と合わせて参考にしてもらいたい。

ケース（1）「コード」をチェック

　ここでいうコードとは、システム化の対象業務でユーザーが扱っている「商品コード」「顧客コード」「受注番号」といったものを指す。業務で扱う商品や顧客、受注案件を特定するために用いられている番号である。

　このコードを実データの中からチェックしてみよう。たとえば受注業務で受注番号が「PD14567・・・」「SV00138・・・」といった、アルファベットが含まれてはいないだろうか。

　もしそのような場合、仕様漏れを防げるチャンスだと思って、ユーザーにアルファベットが持つ意味と、業務でなぜ必要なのかを確認しよう。「アルファベットを、業務や会計処理のパターン分けに使っていることが少なくない」と、富士通で様々なプロジェクトの支援に携わる、津金成年氏（共通技術本部 情報化企画推進部 マネージャー）はその理由を説明する。つまりこの確認を通して、業務で必要な処理パターンに関する仕様漏れを防げるのだ。

　前出の例の場合、「PDは製品、SVはサービス」といった区分をアルファベットで示している。それを経理担当者が処理パターンを変えるのに利用していた。アルファベットが含まれていたり、コードがハイフンで区切られていたりしたら、「何らかの業務ルールがあるな、と当たりをつけて確認するとよい」と津金氏は話す。