「いつテストを書くか？」がめちゃくちゃ刺さった件 -TSKaigi 2026 レポート-

eye_catch

今年はどうだった？
特に印象に残ったセッション
どんな話だったの？
何が良かったの？
- ソフトウェアエンジニアとしてのプロフェッショナリズムを思い出させてくれる
- 理想に向かい試行錯誤することこそがエンジニアリングであることを思い出させてくれる
なぜこんなに刺さったの？
まとめ

こんにちは、エンジニアの toki (@tokai235) です。法人向け eギフトサービス giftee for Business の開発をしています。普段はバックエンドやインフラのお仕事が多いですが、フロントエンドも好きです。

先日 TSKaigi 2026 に参加してきました。今回はギフティはブース出展がない(無念...)ので、2日間トークセッションを浴び続けるスタイルで過ごしまして、TypeScript にどっぷり浸かった2日間でした。

今年はどうだった？

TSKaigi は TypeScript に関する世界最大級のカンファレンスです。実は自分はオフラインでは地域開催回に参加しただけで、本会場での参加は初でしたが、参加者やスポンサーさんの数がすごくて、現地参加は800名を超えたそうです。どのセッションもとても面白くて、参加できなかった方にも公式サイトの各セッション詳細ページから登壇資料へのリンクを辿れるようになっています。神とさせてください。興味のあるものがあれば、ぜひ資料から覗いてみてください！

また、公式サイトのマイタイムテーブルがとても便利で助かりました。最近こういう機能を用意してくれるカンファレンスが体感で増えてるなあと思っていて、とてもありがたいです。

【#TSKaigi2026 全日程終了🎊】
TSKaigi2026の全プログラムが終了しました。
2日間を通して800名以上の現地参加をいただき、
大盛況のうちに終えることができました。
ご参加いただいた皆様、本当にありがとうございました！
次は #TSKaigiSendai でお会いしましょう！#TSKaigi pic.twitter.com/GHZHyNTl6G
— TSKaigi (@tskaigi) May 23, 2026

特に印象に残ったセッション

どのセッションもとても良かったんですが、その中でも個人的にいちばん良かったなあと思っているのが lacolaco さん(@laco2net) のいつテストを書くか？―ソフトウェア開発における安心と不安について考えるでした。

実はこれ AI の話でも TypeScript の話でもなく設計論的なテーマのセッションで、他のセッションと比べると異彩を放っていました。トークの概要も「お話します」ではなく、「明確な答えはありませんが、一緒に考えてみませんか？」だったのが印象的でした。

登壇資料も公開されているので、気になる方はぜひ読んでみてください。

bit.ly

TypeScript に詳しくない方でも全然大丈夫ですし、内容もそんなに重くないので、すぐ読めると思います。Robert C. Martin 氏、Kent Beck 氏、和田卓人(@t_wada)氏などの著作からふんだんに引用されながら、それらを一連の流れとしてまとめ上げた感があります。ストーリー構成含めて素晴らしいプレゼンでぜひご本人の資料を読んでもらいたいので、内容については割愛して、何が良かったのかを話していこうと思います。

どんな話だったの？

ざっくりいうと、ソフトウェアに求められる保守性、変更容易性について掘り下げつつ、それを実現するための道具としてどうテストを使っていくのがいいのか、という話です。

みんな「テスト書かなきゃ」ってわかってるし、「テスト駆動開発（TDD）いいよね」って思ってるけど、その理由をロジカルに説明しきれますか？という問いに対して、lacolaco さんなりの回答を考えてきました、という回でした。

何が良かったの？

ソフトウェアエンジニアとしてのプロフェッショナリズムを思い出させてくれる

セッション中では、たとえばこんな言葉が出てきます。

ソフトウェアが簡単に変更できないなら、ソフトウェアの存在意義を妨害している

利用されているモジュールは振る舞いを変えてはならないが、モジュールには新しい振る舞いを追加できなければならない

『開いているのに閉じている』という理想

日々の開発に向き合っていると、つい忘れてしまいがちな「ソフトウェアはこうあるべき」という理想を思い起こさせてくれるセッションでした。

理想に向かい試行錯誤することこそがエンジニアリングであることを思い出させてくれる

上記の概念はあくまで理想でしかありません。セッション中でも「現実にはすべての仕様変更に強いソフトウェアはあり得ないでしょう」という言葉がありました。

色々なトレードオフの中で自分が良いと思ったものを選び取っていき、理想に限りなく近づけていく。変更しやすさは変更してみなければわからないので、そこで苦労することもある。要求も日々変わる。それらに耐えうるために絶えずリファクタリングし、より良い構造にチューニングしていく...

こういった営みはとても大変で、また普遍的な正解もありません。その中でこういう話を聞くと、「これがソフトウェアエンジニアリングなんだ、あの素晴らしいエンジニアたちもみんな戦っているんだ、自分も続くぞ」みたいな気持ちになります。

なお、この一連のフローに自然と導いてくれるのが TDD です。TDD はテストを先に書くことで安全に開発できる、というだけではなく、テストを通すための実装を通じて構造上の問題を学習し改善する、プログラマーの支援ツールとして提唱されたものだという話も lacolaco さんはしていました。「t_wada さんが言っていたことをやっと理解できた」と言っていたのが激アツで、自分も TDD に対する新たな見方が開けたことがすごく嬉しかったです。