制約という名の自由

会議の翌日、佐藤は自分の案を引っ込めてはいなかった。むしろ、渡辺の指摘を受けて、より詳細な設計書を作成していた。

「完全に厳密にするわけじゃなくて、レイヤーごとに型の要件を変えるんです」と、彼は新しい図表を示した。入力層ではある程度の柔軟性を保ち、ビジネスロジック層で厳密性を確保し、出力層ではバリデーションルールを統一する。理にかなっている。

渡辺も無視しなかった。「それで実装が複雑にならないですか」という質問は、単なる異議ではなく、本当の懸念だった。

二人の対話は、やがてチーム全体の議論へ広がった。

新人の森田が、一つの視点を投げかけた。「型が厳しいと、新しい機能を追加するとき、既存コードを大幅に修正する羽目になりませんか」

ベテランの加藤は異なる考えを示した。「そういうときこそ、型があれば影響範囲が明確になる。無責任な修正を防げる」

こうした意見の違いは対立ではなく、それぞれが異なる「コスト」を見ていることに気づかせた。開発速度のコスト、保守性のコスト、バグ対応のコスト。すべてを同時に最小化することは不可能だ。

会議室は問いの深さに包まれていた。

型システムをどう設計するかは、実は「このプロジェクトで、何を優先するのか」という経営的・組織的な決定を、技術レベルで表現することだったのだ。

佐藤と渡辺は視線を交わした。二人とも、答えがまだそこにはないことを知っていた。