従順

あるプログラムが正しく動いていることを、どうやって確かめるのか。もっとも素朴な方法は、入力を与えて出力を見ることです。内部のコードは読まない。期待した応答が返ってくれば合格とする。ブラックボックステストと呼ばれるこの考え方には、はっきりした限界があります。用意した入力の範囲でしか確かめられないという、当たり前の限界です。試していない入力に対して何が起きるかは、原理的に分からない。

ここに、観測等価という概念が重なります。二つの実装があって、あらゆる入力に対して同じ出力を返すなら、外側からその二つを区別する手段はない。中身がどれほど違っていても、観測の側からは同一物として扱うほかありません。この語の指す人物のふるまいは、ちょうどこの状態に置かれています。何を考えていようと、返される応答が同じであるかぎり、周囲にとっては同じ。素直に納得している人物と、面倒を避けて処理している人物と、深く諦めている人物は、観測の範囲では等価です。上司や親が「あの子は従順だ」と言うとき、述べられているのは内面ではなく、観測記録の要約にすぎない。

ただし、この比喩はあるところで壊れます。人物は関数ではありません。同じ入力に対して常に同じ出力を返すのは、状態を持たない純粋な関数の性質であって、人間には当てはまらない。この語が指しているのは決定性そのものではなく、内部状態の変化を出力に反映させない性質のほうです。状態は溜まっている。溜まっていることが観測できないだけで、更新は毎回起きている。だから比喩を修正するなら、こう言うべきでしょう——観測不能なカウンタが黙って加算されつづけている実装。

もう一つ、テストの側から借りられる考え方があります。想定した入力だけを試していると、いつまでも同じ結果しか観測できない。だから実務では、意図的に想定外の値や極端な値を投げ込んで、そこで何が起きるかを見ることがあります。人物についても同じで、周囲が投げる入力の範囲が狭いかぎり、その人物は従順なままです。応答が変わらないのは性質のせいなのか、単に誰も範囲の外を試していないだけなのか、観測記録は答えてくれない。この語が人物の説明として頼りない理由は、この曖昧さにあります。

この修正が効くのは、破綻の書き方が変わるからです。従順な人物が反抗する場面は、しばしば唐突に読まれます。準備が足りないと言われる。けれども準備とは、伏線を撒くことでも、不満をこぼす台詞を挟むことでもない。それをやった時点で内部状態は観測可能になり、この語は成り立たなくなります。必要なのは、作者の側だけがカウンタを持っていることです。何回目の依頼を引き受けたか、何回目の呼び出しで顔を上げなかったか、読者に数えさせずに数えておく。

実務上の帰結はかなり具体的です。二つ返事で引き受ける場面を、少なくとも三度は同じ形で書く。三度とも、内心の説明を一行も入れない。読者は退屈するかもしれませんが、その退屈こそが観測記録の質感です。そして四度目に、応答の形だけを変える——引き受けるが、返事が半拍遅れる。内部状態が初めて出力に漏れた瞬間で、そこまで一度も漏らしていなかったからこそ、半拍が読める。