型が言葉になるとき

チェックリストを作ることにした。

田中は加藤の指示を受けて、その週から二つの記録簿を並行させた。一つは実装の進捗。もう一つは、型設計を通じて防げた問題、あるいは防ぎ損ねた問題の記録だ。

はじめの数日間は、型の力が明らかだった。状態遷移を型で表現することで、ある操作が「この状態では呼び出せない」ということがコンパイル時に検出される。従来なら実行時エラーになるような曖昧さが、事前に潰される。チェックリストには「未初期化状態での更新操作を型で防止」「遷移ルート外のアクセスを型チェック」といった項目が増えていった。

だが二週間目、田中は壁にぶつかった。

ある更新ロジックで、複数の状態から遷移可能なケースが出てきたのだ。型で状態を厳密に分けるアプローチでは、そうした「融通性」が扱いづらい。加藤のやり方なら、状態ごとのクラス分岐で対応できていただろう。しかし、その道は保守の地獄へ通じている。

田中は加藤にメッセージを送った。返信は三十分後に来た。

「その場面で『複数の状態から遷移可能』という判断は、どこから来たのか。本当に複数なのか、それとも状態の分け方が間違っているのか。型はそこを問い直すチャンスだ」

田中は画面から目を離した。加藤の言葉は、単なるアドバイスではなかった。十年前、彼が失敗した理由が見えた気がした。状態をクラスで分けるアプローチでは、曖昧さを構造で隠してしまう。一方、型でそれを表現しようとすれば、曖昧さ自体に向き合わざるを得ない。

チェックリストに新しい項目を追加した。「曖昧な状態遷移を、型の制約を通じて明確にした」

加藤は依然として、チェックリストを毎日確認していた。