【ITニュース解説】'Make invalid states unrepresentable' considered harmful

ソフトウェア開発において、プログラムが間違った情報や矛盾した状態を持つことを防ぐのは非常に重要である。例えば、商品の在庫数がマイナスになったり、顧客の年齢が200歳を超えたりするなど、現実ではありえない、あるいはシステムとして不適切とされる状態がプログラム内で発生すると、予期せぬエラーや誤動作につながる。このような「無効な状態」をそもそも発生させないようにする設計原則が、「無効な状態を表現できないようにする（Make invalid states unrepresentable）」という考え方である。

この原則は、ソフトウェアが持つデータやオブジェクトが、常に正しい、有効な状態であることを保証しようとするものだ。具体的には、プログラミング言語の型システムを活用したり、特殊なデータ構造を導入したりすることで、そもそも無効な値を格納できないようにプログラムを設計する。例えば、数量を表す変数にはマイナスの値を入れられないようにしたり、特定の条件を満たさないとオブジェクトを作成できないようにしたりする。これにより、開発者はプログラムの一部で無効な状態を意識することなく、安心してコードを書けるようになる。これは、バグの削減やシステムの堅牢性向上に大きく貢献するため、多くの開発者に支持されてきた強力な設計思想である。

しかし、この強力な原則にも適用を誤ると「有害」となり得る側面がある、と指摘する声がある。その指摘の核心は、「本当に無効な状態」と「一時的に不完全な状態」を区別することの重要性にある。

「本当に無効な状態」とは、システムがその整合性を永久に失うような、根本的に間違った状態を指す。例えば、データベースに保存される重要なビジネスデータが矛盾した状態になることは、システム全体に深刻な影響を及ぼす。このような状態は、徹底的に排除し、表現できないように設計することが望ましい。

一方で、「一時的に不完全な状態」とは、特定の操作の途中段階で一時的に発生するが、最終的には有効な状態になることを目指す状態である。例えば、ユーザーがウェブサイトの登録フォームに入力している途中の状態を考えてみよう。ユーザーがまだ名前やメールアドレスの入力を終えていない段階では、そのデータは「完全な有効なユーザー情報」とは言えない。しかし、それはシステムにとって「本当に無効な状態」だろうか。この時点では、それは単に「入力途中である不完全な状態」であり、ユーザーが残りの情報を入力し終えれば有効な状態になる。

もし、このような「一時的に不完全な状態」に対しても、「無効な状態を表現できないようにする」原則を厳密に適用しようとすると、プログラムは不必要に複雑になってしまう可能性がある。例えば、フォームの各入力フィールドの状態を、一つ一つ型システムで「未入力」「入力中だが不完全」「完全に有効」などと細かく表現しようとすると、使用する型やデータ構造が非常に複雑になる。これは、コードの可読性を低下させ、開発の速度を落とし、後から機能を追加したり変更したりする際の障壁となる。

特に、ユーザーインターフェース（UI）の設計においては、このような一時的な不完全状態が頻繁に発生する。ユーザーが情報を入力していく過程そのものが、ある意味で状態が変化し続ける連続体であり、その全ての段階を厳密な「有効/無効」の二元論で捉え、型システムで完全に表現しようとすると、かえってUIの状態管理が煩雑になり、柔軟性を失う。

また、現実世界のビジネスロジックは常に変化する。今日の「有効な状態」が、明日にはビジネス要件の変更によって「無効」と見なされるようになるかもしれないし、その逆も起こり得る。型システムで状態を固定的に表現しすぎると、将来の変更への対応が非常に困難になる。変更が発生するたびに、型定義や関連する多くのコードを修正する必要が生じ、システム全体の保守コストが増大する恐れがある。

したがって、この原則を適用する際には、その状態が「システムにとって本当に致命的な無効状態」なのか、それとも「特定のライフサイクルやコンテキスト（文脈）において一時的に不完全な状態」なのかを慎重に見極める必要がある。本当に無効な状態、つまりデータベースの整合性に関わるような永続的なデータについては、積極的にこの原則を適用し、システムが矛盾した状態になるのを防ぐべきだ。しかし、一時的な入力途中や処理途中の状態に対しては、過度な型システムによる制限を避け、より柔軟な方法で状態を管理する方が、全体のコードをシンプルに保ち、開発効率と保守性を高める場合がある。

開発者は、常にこの原則のメリットとデメリットを理解し、現在のプロジェクトの要件、将来の変更の可能性、そして開発チームのスキルレベルなどを総合的に考慮した上で、最も適切な設計アプローチを選択するべきである。単に流行の設計パターンだからといって盲目的に適用するのではなく、その背後にある思想と、それが実際のシステムに与える影響を深く考えることが、優れたソフトウェアを作る上で不可欠である。