読者です 読者をやめる 読者になる 読者になる

仕様の意図を開発に反映させるということ

ソフトウェア開発

 TEFでテスト技術者の方と話していると、「仕様の意図を意識して成果物に反映させるべし」という視点の存在を再認識させられることがよくある。

 例えば原因結果グラフを使ってテストを設計する際は、設計手順にどれを選んでも問題ない複数の選択肢が現れることがある。そこでテスト技術者の方は、どちらが仕様の意図に適合しているか、という視点で選択をすることが多い。そうした視点を持てば、テストがより仕様に対して最適化されるほか、より仕様変更にも強くなり、テストの汎用性向上につながるという。

 これは、仕様書をベースにしてブラックボックステストやグレーボックステストを設計する業務をテスト技術者の方が多く手掛けているのを考慮すると、理にかなった自然な考え方だといえると思う。

仕様の意図をコードに反映すること

 この「仕様の意図を反映させることにより、仕様変更に対する耐性を高める」というアプローチは、当然実装でも役に立つ知見だと思う。

 たとえば以下の仕様を実装する場合を考えてみる。

  1. 性別、年齢が入力。プレゼントの種類が出力
  2. 男性は10歳未満にアメをプレゼント、女性は10歳未満にゼリーをプレゼント。それ以外はガムをプレゼント

 この実装方法はいくつかある。とりあえずC言語もどきで2種類表現してみる。

if (年齢 < 10) {
    if (性別 == "男性") {
        アメを返す;
    } else if (性別=="女性") {
        ゼリーを返す;
    } else {
        ガムを返す;
    }
}
if (年齢 < 10 && 性別 == "男性") {
    アメを返す;
} else if (年齢 < 10 && 性別 == "女性") {
    ゼリーを返す;
} else {
    ガムを返す;
}

 これらの実装が実現する挙動に違いはない。ただ仕様変更の容易性という視点で見ると、両者で汎用性が異なる場合がある。

 例えば仕様に「男性の年齢条件と女性の年齢条件は、意味は全く別々のもので、両方とも10歳未満となっているのはたまたま一致しているだけ」といった意図がある場合は、女性の年齢条件だけが変更されるような仕様変更の可能性が高くなる。そうした条件下では、後者の方が、男性の年齢条件の判定と女性の年齢条件の判定が別々に分離されている分、仕様変更時の修正範囲が小さくなる可能性が高いといえる。結果、前者より後者の方が仕様変更に強い実装といえると思う。

 また一方で仕様に「10歳未満という年齢条件は性別にかかわらず共通に定められるものだ」といった意図がある場合は、年齢条件の仕様変更は性別問わず一律に行われる可能性が高い。そうした条件下では、後者は条件を重複して判定しておりDRY原則違反となっていることから、後者を仕様変更に弱い実装と見なすことができる。

 これはすなわち、仕様の意図が、コードの汎用性を左右する要因を生み出す、ということだろう。

 なお上記の例はあくまで単純な実装レベルの話であり、仕様も小さいので深刻な問題とならないだろう。が、これが設計レベルやアーキテクチャレベルの話となると無視できなくなる。そこでは変更のダメージが大きくなり、仕様変更が致命的な問題の1つに十分なり得る。

仕様の意図を反映させるツールとしての仕様書

 この仕様の意図の反映は、普通なら暗黙的に行われていることなのだろうけど、あくまで暗黙レベルなのでともすれば不十分な状態に陥りがちなようにも見える。

 そうした現状は、小規模な開発ならば問題ないかもしれないが、開発物が相応の規模を持ってくると結構な問題になってくると思う。小さな修正で済む仕様変更はリファクタリングやレビューでなんとかできても、設計を破壊するような大きな仕様変更に対しては、色々な要因が絡んで「なんとかなる」といえなくなるためだ。

 その点、設計者と実装者が分離している開発や、複数の開発単位(チームや協力会社)で協力して進める開発なんかでは、積極的に仕様の意図を実装に反映させるプロセスや手段の整備を推進しなければならないと思う。


 なお仕様の意図を定義しコードに反映させる手段の1つに、仕様書が挙げられると感じる。
 少なくとも業務フローが図化されていたり、ユースケース記述がきちんと書かれていたり、また異常時処理の流れが定義されていたりすれば、それらをコードに反映させるのずっと楽になる。その役割を担うドキュメントレベルとしては機能仕様書やアーキテクチャ仕様書あたりだろうか。


 余談になるけれど、仕様書を書く上では、こういったメリットがあるということを知っていないと、大分損することになると感じる。
 それは言及するまでもない常識的なことかもしれない。が、時々学生の方のみならず、開発者の方でも仕様書に過剰な拒絶反応を示しているのを見ると、仕様書に対する誤解や過剰な低評価がこの業界で広がっているのではないかと感じることがある。