【コード哲学エッセイ】 型は制約じゃなく約束の可視化だ

TypeScript が未来の自分にくれる地図

エディタに赤い波線が出ると、ついイラッとする。
頭のなかでは、こう言いたくなる。

「いまは通したいのに」
「そこまで厳しくなくていい」

かつての僕は、TypeScript の型を縛りだと思っていました。
コンパイラが、創造の足を引っ張る壁。
早く動かしたいのに、正しさを先に要求してくる、厳しい先生。

だから any に逃げた。
// @ts-ignore を、ためらいなく置いた。
エラーが消えるたびに、少しだけ安堵する。

通った。動いた。
今日はこれでいい。

そう自分に言い聞かせていました。

any に隠れた静かな崩れ

フリーランスになってから数年、小さな SaaS のフロントを任されたことがあります。
外部 API からユーザ情報を取り、画面に並べる。
当時の僕にとっては、よくある仕事でした。

レスポンスの型は、あえてざっくりにした。
any で受け、必要なフィールドだけ取り出す。
「あとで整える」と心のなかで言い訳した。

数週間後、バックエンドのフィールド名が一つ変わった。
userName が displayName になった。
互換のため、しばらく両方返す予定だった。

型がない場所は、コンパイラは黙った。
画面は、空の欄を表示した。
ログには、エラーも出なかった。ただ、名前だけが消えた。

その夜、僕は初めて思いました。
赤い波線は、敵じゃなかったのかもしれないと。

制約ではなく約束の可視化

いまの僕は、型をこう捉えています。

型は、未来の自分と交わす約束をコードの上に可視化したもの。

「この関数は、この形を返す」
「ここから先は、null ではない」
「この境界を越えたら、別の責任に渡す」

それは、正解を押しつける装置じゃない。
今の自分が、未来の自分に残す地図に近い。

コメントが意図の手紙なら、型は形の約束だと思うようになりました。
コメントは古くなりやすい。
型は、使い方と一緒に更新されやすい。

六月のエッセイで、設定を境界だと書いた。
型もモジュールとモジュールのあいだに引く静かな線だ。

隠すための金庫でも、縛るための柵でもない。
どこで何を約束するかが、読める地図になる。

地図は完璧じゃなくていい

誤解してほしくないのは、型を神格化したいわけじゃないということです。

最初から完璧な型を書こうとすると、また息が詰まる。
ユニオンが増え、ジェネリクスがねじれ、型のための型が生まれる。

僕も、そこで何度も迷子になった。

大切なのは、地図の精度を上げ続けることじゃない。
どの約束が、いまのプロダクトで本当に必要かを見極めることです。

たとえば、API の境界だけ型を厚くする。
画面の内部は、まだゆるくてもいい。
三回、同じ形の変更が来たら、型を太くする。
DRY を急がないのと、同じ姿勢です。

// 未来の自分への約束: ユーザー一覧で使う最小の形だけ先に決める
type UserListItem = {
  id: string;
  displayName: string;
};

一行の displayName が、あの夜の消えた名前を未来の僕から守ってくれる。
地図は、世界のすべてを描く必要はない。
迷子になりやすい場所だけ、濃く描けばいい。

型を書く前に僕が置く三つの問い

型を足す前に、僕は三つだけ問います。

誰と、どんな約束を交わしたいか。
その約束が壊れたとき、どこで気づきたいか。
いま厳しくしすぎて、変更の速度を落としていないか。

答えがはっきりしない型は、まだ早いのかもしれません。
any で逃げ続ける必要もない。
「TODO: 三回目の変更で型を引く」と一行書く。
それだけでも、地図の空白が意図になる。

エラーは、境界の案内役だと別のエッセイで書いた。
型エラーも、敵の宣告じゃない。
約束が食い違っている場所を、先に教えてくれる合図だと思っています。

僕がいまエディタの前で思うこと

梅雨の六月、外の空気は重い。
コードベースは、静かに育ち続けている。

型を書く作業は、派手じゃない。
けれど、半年後の自分を夜のデバッグから遠ざけることがある。

赤い波線が出たら、僕は昔の自分に声をかけます。

「ここは、縛りか。
　それとも、約束の地図か」

後者なら、少しだけ丁寧に線を引く。
前者に感じるなら、いま必要な約束だけに絞る。

TypeScript は、未来の僕に地図をくれるツールだ。
完璧な正解集じゃない。
どこで何を守るかが、読めるようにしてくれる優しい記録だと思っています。

同じように、型を縛りだと感じていた誰かに届けばうれしいです。

ひとりごと

若い頃の僕は、any で通した diff に少しだけ安堵していました。
きれいに動いた今日の自分を、未来の自分が信じすぎていたのかもしれません。

いまは、赤い波線を一枚、地図の更新通知だと思えることがある。
それだけで、六月の夜が少しだけ楽になる。

Substack はじめました

ここまで読んでくださり、ありがとうございました。

X では短い言葉で、note では整理した文章で発信していますが、Substack では、もっと途中経過の思考や削りきらなかった葛藤、技術者として日々考えていることを書いています。

もし興味があれば、覗いてみてください。

会社員（元システムエンジニア）からフリーランスとなり、
15 年目に突入しました。

納期と障害対応に追われる毎日の中で、
「もっと自由に、もっと本質的にものづくりがしたい」
そう思ったのが独立のきっかけです。

現在は、技術と文章を軸に、
仕事がラクになる仕組みや続けられる働き方を発信しています。

あわせて読みたい

▼ 境界を引く設計と並べて読みたいときに

6 月のコード哲学エッセイの流れ。
型も、責任が切り替わる線のひとつです。

▼ 未来の自分への手紙としてのコード

言葉の意図と、形の約束。
未来の自分を救う、もう一本の線です。

▼ エラーを敵にしない視点として

型エラーも、案内役として迎える。
境界の設計と響き合います。

次の一歩を一緒に決める作戦会議室へ

型の引き方や、API 境界の設計。
一人で迷う夜もあると思います。

作戦会議室では、現場で使える切り方を小さく分け合える場所にしたいです。
必要なときだけ、覗いてみてください。

参加する