知識とソフトウェアのギャップ、それをどう埋めるのか?実行可能な知識とソフトウェア(2)

知識にはいろいろな性質がある。モジュール性、伝達可能性、柔軟性、抽象性、具体化可能性などなど。単に知識が「あればいい」というわけではない。「知識の質」、特に「知識のダイナミクス」を支える質が重要なのだ。今回はその1つ、知識の検証可能性ということを考えてみることにしよう。(本文より)

» 2004年04月06日 12時00分 公開
[山田正樹,メタボリックス]

 この連載ではソフトウェアを「実行可能な知識(の1つの表現形態)」と見なす。「実行可能な知識」とは、さまざまな知識を表しているソフトウェアというものがまさに、CPU上で実行可能だということを意味する。これは従来の紙の上に書かれているだけの知識にはなかった特徴だろう。「知識」の範囲を少しだけ広げて考えれば、例えばビジネス・プロセスも実行可能な知識(ビジネス組織が実行する)だし、遺伝情報も実行可能な知識(生命体が実行する)と思ってよさそうだ。ソフトウェアは実は、こういうさまざまな存在とつながっている。

 知識にはいろいろな性質がある。モジュール性、伝達可能性、柔軟性、抽象性、具体化可能性などなど。単に知識があればといいということではまったくない。「知識の質」、特に「知識のダイナミクス」を支える質が重要なのだ。今回はその1つ、知識の検証可能性ということを考えてみることにしよう。

 知識の「正しさ」を知る方法には実は2種類ある(「正しさ」に2種類あるといってもいい)。1つは検証(verification)と呼ばれるもの、もう1つは妥当性確認(validation)と呼ばれるものだ。この使い分けは微妙で難しいが(分野によっても違うかもしれない)、大ざっぱにいうと 検証とは自分たちがこういうものを作ろうと決めたとおりにできているかどうかを確かめること、妥当性確認とはできたものが本当に欲しかったものかどうかを確かめることだ。

 例えばテスト仕様書を書き、テスト仕様に従ってソフトウェアを実行したときにどのような答えが出るかをチェックする。これが検証。検証できたからといって、そのソフトウェアが「本当に」正しいとは限らない。だって仕様書にすべての場合を列挙することはできないし、そもそも仕様書が顧客の意図したものになっているとは限らない。それに対してユーザーや顧客が欲しかったソフトウェアになっているかどうかをチェックするのが妥当性確認。

 極端な話、100万行のシステムの仕様上、コード1000行当たり欠陥密度が0.001だったとしよう。検証を行ってその仕様を満たしていることは分かったとする(注1)。ところがその1つの欠陥がユーザーのニーズにとって決定的な欠陥だったとしたら、そのシステムは妥当とはいえないだろう。ある仕様に対してシステムが検証されているということは、システムが妥当であることの必要条件とはなっても十分条件にはならないのである。

▼注1

 ここで何か変だと思った人はおそらく正しい。100万行のシステムのコード1000行当たりの欠陥密度が0.001ということは(おそろしく信頼性の高いシステムだが)、システム全体で1つの欠陥しかないということだ。ん? 欠陥が1つしかないということはなぜ分かるのだろう? 欠陥が1つあるということが分かっていたら直せばいいではないか!


 工業製品の信頼性は例えば100万個に1個の割合で不良品が発生するというもので、これは考え方として分かりやすい。製品1個1個はほとんど独立したものと考えていいのだから。ところが、ソフトウェアの1行1行は独立しているどころか、同じ1つのものの一部なのだ。100万行に1つしか欠陥がないということにはほとんど意味がない。そのことによって残りの99万9999行も使い物にならないかもしれないのだから。



 製品の妥当性は顧客の満足度につながっている。だからこそ重要なのだが、妥当性を確認するためにはどうすればいいだろう?

 いろいろな考え方があるが、僕は多くの種類のソフトウェアでは最終的には「実際に動かしてチェックする」しかないだろうと考えている。だって動かないソフトウェアを見ても何も分からないから。できるだけ早い段階で「実際に動かしてチェックする」ために僕たちは繰り返し的な開発を行う。そして同時に常に検証を繰り返す。検証によって妥当性が保証されるわけではないけれど、有効な検証ならばいかにも妥当性に一歩一歩近づいている感じがするではないか!

 ではもう一方の検証はどうすればいいだろうか? 僕たちは「知識」に基づいてソフトウェア開発を考えようとしているのだから、検証も知識の変換過程として考えよう。すると検証とは「いまこう動く(as-is)」という知識と「かくあるべし(should-be)」という知識をすりあわせる過程(注2)だと考えることができる。そのためには「いまこう動く」ということと「かくあるべし」ということが(実行可能)知識としてうまく表されていてほしいわけだ。

▼注2

 この「すりあわせる」というところが肝心。僕たちの立場では「かくあるべし」が最初から絶対に正しいとは思わないのだ。



 JUnitをはじめとするxUnitと呼ばれる単体テスト・フレームワークもその方法の1つだ。いまやデファクト・スタンダードとなり、一緒の納品を求められることも多いだろう。「いまどう動くか」は実際にボタンを押せば、結果が赤や緑で表示される。とても「感情的な」知識表現になっている。「どう動くべきか」という知識はテスト・コードが表す。面白いのはどう動くべきかという知識も検証対象となっている知識と同じプログラミング言語で同じように記述されていることだ。xUnitを使ったプログラムの書き方(テスト駆動開発)からいっても、テストされるコードとテストするコードが依存し合い、渾然一体となっている。非常にソフトウェアらしい側面で面白いんだけれど、「何を検証しているか」はやっぱり分かりやすいとはいいにくい。

 「どう動くべきか」を表すもう1つの方法は「契約」という考え方だ。契約はサービスを提供する側とサービスを受ける側の間で結ぶ。例えばホテルに泊まるときには、宿泊客が義務を果たしていれば、ホテルも義務を果たしてくれるというのが契約だ。

 ソフトウェアの検証という立場からはサービスとはメソッドや関数の呼び出しということになる。例えば、平方根を計算するサービスを提供するメソッドdouble sqrt(double x)に関する契約は、サービスを受ける側の義務(0か正数の引数xを渡すサービスを提供する側の義務)結果を自乗すると引数に等しい、となる(もっとも、現実のdoubleには誤差が含まれるから、まったく等しくなるとは限らない)。サービスを受ける側の義務を事前条件(pre-condition)、サービスを提供する側の義務を事後条件(post-condition)という。契約とは事前条件が満たされたら事後条件が満たされることを保証するということだ。

 これをJML(Java Modeling Language)という契約記述言語では、Java言語のJavaDoc風に次のように書く。

//@ requires x >= 0.0;
//@ ensures JMLDouble.approximatelyEqualTo(x, \result * \result, eps);
public static double sqrt(double sqrt) { ... }

 epsは誤差の範囲を表す定数、JMLDoubleはJMLが提供するライブラリ、\resultは結果を表す変数だ。この契約を見れば、引数が正しいかどうかチェックするのは呼び出す側の仕事ということがひと目で分かる。また呼び出した側は結果を自乗すると引数と同じ(一定誤差範囲で)ということを信頼してその先の仕事を進めることができる。

 JMLのオープンな処理系ではこのJavaDocを解析して、メソッドの呼び出し前後に事前条件、事後条件をチェックするコードを吐き出してくれる。契約が満たされていなければ例外が発生する。もっとも製品コード中にこんなコードを埋め込んでおくのはもったいないから、十分テストが終わったら普通にjavacでコンパイルすればよい。

 「契約」という考え方をサポートしてくれる処理系はほかにもいくつかある。xUnitに比べていい点は「かくあるべし」という知識が明確に表現されている点だ。xUnitでは結局テスト・コードを読まなければ、何がテストされているのかよく分からない。すべてのメソッドに契約を書いてから(注3)メソッド本体を書くというプラクティスを身に付ければ、それは「契約駆動開発」といっていいだろう。「契約」という知識を、それを満たしつつ動作するソフトウェアという知識に変換する(ミクロな)過程なのである。もしちゃんとできれば、間違いなくソフトウェアの質は向上する。

▼注3

 単なるsetter/getterは多分契約を書かなくてもいいだろう。誤差や時間を含むような場合には簡単にいかないこともある。また意図したこと以外には何も変わっていないことを確認するのは実際には難しい。



著者プロフィール

山田正樹

(株)ソフトウェア・リサーチ・アソシエイツ 、(株)ソニーコンピュータサイエンス研究所を経て、1995年(有)メタボリックス設立。代表取締役。アーキテクチャ、モデリング、マネージメント、コラボレーションなどを含む広い意味でのソフトウェア・プロセス・エンジニアリングが専門。ソフトウェア・ツール開発、メンタリング、コンサルティングなどを行っている。



Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ