曖昧さの輪郭

加藤の指摘は、田中の頭の中で形を変えていった。複数の状態から遷移可能という判断は、本当に要件なのか。それとも、要件を読み違えているのか。

チェックリストを手に、田中は仕様書を読み直した。更新ロジックの部分を何度も目を通す。するとやがて、曖昧さの輪郭が見えてきた。状態を遷移可能と判断したのは、自分たちの「現在の実装」がそうなっているからだ。実装が先にあって、仕様をそれに合わせていたのだ。

逆向きに考えると、要件だけから見れば、その更新操作が必要とする状態は一つだけだった。他の状態から来るケースは、どれも実装の都合で生まれた迂回路だった。

田中は加藤に報告した。その後、型の設計を修正してみることにした。状態を細分化し、更新ロジックの前提条件を型で明示する。すると、コンパイラが新しい警告を出した。呼び出し元のいくつかが、その細分化された前提を満たしていない。

そこからが本当の修正だった。型が指摘した不整合を辿っていくと、チェーン状につながった矛盾が浮き上がった。実装の各層が、互いに異なる想定で状態を扱っていたのだ。

二日かけてそれを整理すると、田中は気づいた。型は曖昧さを拒否する。だからこそ、隠れていた設計の綻びが見える。加藤が十年前に経験した保守の地獄とは、この綻びを見ないまま実装を重ねることだったのだ。

チェックリストに新しい行が加わった。「型による曖昧さの可視化」

次の朝、別の課題が待っていた。