コラム「同じ」プログラムであるとはどういうことか
望まれないバージョンアップ
プログラムをバージョンアップするとき、お客さん自体がそれを望んでいるわけではなく、単に古いOSが入手できなくなったとか、新しいOSが古い開発環境で作られたものの動作をサポートしてくれないとか、そういう外的なきっかけであることが多いようです。
こういう場合、お客さんはプログラムの挙動が変わることを一番恐れていて、やりたくもないバージョンアップをして、その結果実行結果が変わってしまったという場合、勢い製造現場への風当たりも強くなってしまいます。
また、こういうバージョンアップの場合、お客さんは仕様を考え直すようなモチベーションもなく、単に「前と同じように動作すること」という要求仕様で終わってしまうことも少なくありません。
しかし、VisualBasic6で作られたプログラムを無理やりC#やVB.Netで書き直すと、プログラムの形そのものが変わってしまい「どんなケースでも同じ結果を出す」プログラムであることを示すことが非常に難しくなります。
こういう場合、お客さんはプログラムの挙動が変わることを一番恐れていて、やりたくもないバージョンアップをして、その結果実行結果が変わってしまったという場合、勢い製造現場への風当たりも強くなってしまいます。
また、こういうバージョンアップの場合、お客さんは仕様を考え直すようなモチベーションもなく、単に「前と同じように動作すること」という要求仕様で終わってしまうことも少なくありません。
しかし、VisualBasic6で作られたプログラムを無理やりC#やVB.Netで書き直すと、プログラムの形そのものが変わってしまい「どんなケースでも同じ結果を出す」プログラムであることを示すことが非常に難しくなります。
仕様であるものとないもの
プログラムの動きには、残念なことに「こうしている」ものと「こうなっている」ものがあり、運がよければ前者は仕様に書かれているのですが、後者は書かれていません。そのため後者の範囲にあるものは、バージョンアップによって動きが変わってもそれに気づくこと自体が非常に難しくなります。たまたま見つかることはあっても、見つけるためのテストというものは、そもそも想定出来ません。想定できるものは仕様に書かれているからです。
通常、ネジなど工業製品には「許容公差」というものが仕様に必ずあり、どの範囲なら「同じ」と言っていいかが仕様に明確に定められています。
しかしソフトウェアにはこういうものがなく、発注側は「同じといったら同じだ」を繰り返すばかりです。
困ったことに、二つのものが同じであるかを証明するには無限の時間が必要ですが、同じでないことは、ただひとつの反例を見つけた時点で証明が終わってしまうのです。同じであることを保証するというのは、あまりにも分の悪い作業であることがわかります。
この「許容公差」という考えがないところが、ソフトウェア業界が産業として未熟であることを示しているのではないでしょうか。
通常、ネジなど工業製品には「許容公差」というものが仕様に必ずあり、どの範囲なら「同じ」と言っていいかが仕様に明確に定められています。
しかしソフトウェアにはこういうものがなく、発注側は「同じといったら同じだ」を繰り返すばかりです。
困ったことに、二つのものが同じであるかを証明するには無限の時間が必要ですが、同じでないことは、ただひとつの反例を見つけた時点で証明が終わってしまうのです。同じであることを保証するというのは、あまりにも分の悪い作業であることがわかります。
この「許容公差」という考えがないところが、ソフトウェア業界が産業として未熟であることを示しているのではないでしょうか。
仕様に書いていないものは仕様ではない
仕様に書いていないことすべてを「許容公差」であるとするならば、仕様には工業製品なみの厳格さが必要となり、「書いてなくても分かるでしょ普通」というようなノリが許されないようなルールが必要となってきます。ソフトウェアが「同じ動作」であることを保障する範囲が「仕様に書いてあること」であり、それに書いていない範囲のことで新旧のソフトの動作が違っていてもそれが許されるような仕様書こそが、ソフトウェアにはそもそも必要とされているのです。
このあたりの解決に、Alloyは非常に分かりやすい道筋を示してくれているように思えるのです。Alloyの探索の深さは、そのまま「許容公差」をイメージできる数値ともとれます。
Alloyのように、仕様を無表情に解釈し理解する脳こそ、ソフトウェアの設計に必要なものなのではないかと思うのです。
このあたりの解決に、Alloyは非常に分かりやすい道筋を示してくれているように思えるのです。Alloyの探索の深さは、そのまま「許容公差」をイメージできる数値ともとれます。
Alloyのように、仕様を無表情に解釈し理解する脳こそ、ソフトウェアの設計に必要なものなのではないかと思うのです。
(文責:片山 功士 2011/11/05)
今日: - 人
昨日: - 人
トータル: - 人
昨日: - 人
トータル: - 人