型という言語

既存コードの一部について、型定義を徹底的に見直してみることにした。

今までのアプローチは、問題が起きてから型を後付けするようなものだった。エラーが報告される→原因を調査する→型を修正する。その繰り返しだ。しかし、もし最初から「このデータは何を表しているのか」を型で明確に宣言していたら、どれほどの問題が防げただろう。

田中はいくつかのモジュールを選び、それぞれの型定義を紙に書き出した。顧客情報、注文データ、決済ステータス。これらの型は、単なるバリデーションルールではなく、ビジネスロジック自体を語っていなければならない。

たとえば、決済ステータスはいくつかの状態を持つ。完了、保留中、失敗。これまでのコードでは、これらを単なる文字列として扱っていた。「pending」「completed」「failed」。その結果、無効な状態遷移が起こり得た。完了から保留中へ、という本来あり得ない流れが、プログラム的には何も警告しなかったのだ。

型システムでこれを表現すれば、あり得ない遷移はコンパイル段階で検出される。つまり、ビジネスルール自体が型に組み込まれることになる。

夜明け前、田中は試行錯誤の成果を整理していた。新しい型設計の骨組みが見えてきた。明日、これをチームに提案できるだろうか。反発されるかもしれない。しかし、二年間の失敗の履歴を見ていると、もう曖昧さを続けることはできない、と感じていた。

朝日がオフィスの窓から入り始めた時、田中のノートには、新しい設計図の輪郭が浮かび上がっていた。