TSKaigi 2025 ２日目 に参加しました。
イベントの概要
学び、繋がり、”型”を破ろう
2024年に産声をあげ、大盛況のうちに幕を閉じた TSKaigi を今年も開催します！
私たちは、誰かの発表を聞くだけでなく、他の誰かに向けて発表することもまた学びの一つだと考えています。 参加者、登壇者、スタッフ、スポンサーをはじめ、TSKaigi に関わるすべての人たちが互いに学び合い、新たな繋がりを生み出し、型にとらわれないエンジニアとして生き生きと活躍できる世界を目指します。 その実現に向け、今年は会場を中野から神田へ移し、2日間開催とすることで、大幅にパワーアップしました。
TypeScript に関するあらゆるテーマを扱う国内最大級のカンファレンスとして、まさに「型破り」なイベントを目指し成長を続ける TSKaigi にご期待ください。
引用：
１日目の内容
オープニングトーク
理事であるアセンド丹羽さんからのあいさつ。
2024年の価値。40超えるトーク、2400名以上の参加。
そこからTSKaigiの価値を見直した。
学び、繋がり、"型"を破ろう。計画的偶発性を引き起こす。
ひとりひとりの技術力を高め、より豊かな社会に。
TSセッション
-
TypeScriptネイティブ移植観察レポート TSKaigi 2025
■メモ
最新の動向。A 10X Faster TypeScript。
落ちてるのに気づきにくいが、本当にそのまま動く。
大規模になるほど速さが際立つ。
速さ。TypeScriptCompilerが速くなる。
今までJSのランタイムで動くことでパフォーマンスとスケーラビリティに課題がある。
JSはコンパイラのような計算負荷の高い用途に最適ではない。
限界があり、GO言語に移植する。
TSのあらゆる挙動はどこかのプロジェクトに利用されている。
型チェッカーは後方互換が絶対。
なので、プラグアンドプレイで置き換えられるものを目指す。
GO言語の理由。
・関数＋データ構造での手続き的な実行スタイルとの親和性。
・ガベレージコレクションを持ち循環参照を自然に扱える。
・共有メモリを利用した並列処理ができる。
・クロスプラットフォームにネイティブコードで動作する。
速さについて。
内訳。ネイティブ化*並列処理=10x Faster。
ネイティブ化
・JITとdeopt、柔軟で動的なオブジェクトからの脱却
・データ構造のインライン化、メモリの効率的な利用
・文字列管理が効率的なGO言語の特性
並列処理
・独立可能な処理の並列化
・型チェッカーはプロジェクトを４分割して並列処理
互換性について。
目標99.99%の互換性。10万件のエラー差分検知テストが存在する。
但し、Union型や型自体の決定的順序付けを導入。
今までは偶然の順序だったことを決定的した。
開発スピードについて。
TSに習熟している人間が移植に関わっている。
TS⇒GOへの構文変換ツールを用意。
AIベースの一括変換は利用していない。AIのランダムな出力は今回の目的に不向き。
CompilerAPIの今後。
ネイティブ実装への移行で変化は発生する。
APIはバージョンが作られる。
言語サービスプラグインの開発は大きな影響を受ける。
ts-morphは今後に注意。継続できない可能性あり。
10倍速くなったことで得たパフォーマンスバジェットの使い方。
超複雑な型を書いて生まれた性能を使いつぶさないこと。
気持ち。
取り組み全体がいち開発者として印象的。ちゃんと動いていて本当に速い。
型あってこその型破りを実践している。
■感想
A 10X Faster TypeScriptの勉強になりました。
無知からの聴講でも理解が深まる濃厚な時間でした。
コンパイラが速くなる。結果、試行錯誤が速くなる。
結果、今まで実現していたことを実現しても時間が生まれる。
この時間を何で埋めるのかは大事だと思いました。
NotebookLMに資料呑ませて、もう一度セッション内容復習します。 - フロントエンドがTypeScriptなら、バックエンドはPHPでもいいじゃない
■メモ
バックエンド開発の話。
もともとバックエンドエンジニアが多く、フロントエンドエンジニアが増えている。
フロントエンドはやること多い。なので、バックエンドへの関与がほぼ無い。
昔、フロントエンドエンジニアはいなかった。
バックエンドエンジニアがフロントも書いていた。
フロントエンドは2010年代前半に生まれた。インクリメンタルサーチが革命だった。
バックエンドエンジニアの強み：インフラ、DB、サーバ構築、CI/CD。
フロントエンドエンジニアの強み：HTML/JS/CSS、アクセシビリティ、UI/UX
バックエンドがなぜ必要か。
セキュリティ担保、非同期・ジョブ実行、ビジネスロジック隠ぺい、外部システム連携。
時間のかかること、秘密にしたいことをバックエンドで実現する。
バックエンドとフロントエンドは分離すべき。
Information Leakage。情報が漏れる。明瞭な役割分担できなかった負債が溜まる。
後で分けるのは無理。
アーキテクチャ構成の柔軟性。
参考：https://www.amazon.co.jp/-/en/John-Ousterhout/dp/1732102201
バックエンドを分離する。
では言語は？何でもよい。要点は責任分離。言語は次点。
PHPを推す理由。
来月30周年。サーバサイドの7割を占めてる。
PHPはすぐに学習できる。
シェアードナッシングアーキテクチャ。効率悪いけど安全。
モダン化の流れ。PHPUnit。PHPStan。
PHPFoundationが開発している。毎年新バージョン出てる。
PHPコミュニティ。2023年から活発。
■感想
40代前半のバックエンドエンジニアとして刺さる内容でした。
自分はエンジニアとしてはじめて扱った言語はクラシックASPだったので、自分にとってJSに対する古い記憶はテキストボックスに変な値入力されたらアラート出す役目でした。
PHP Conference 2025も楽しみです。 - Pragmatic Functional Programming in TypeScript
■メモ
書籍、言語、フレームワークのトレンドがある。
副作用の分離、関数構成、データ表現…
理屈は分かるが実業務に充てて考えることが難しい。
チームで取り組むことにも学習コストと適用のハードルが高い。
既存のアーキテクチャにも少しずつ組み込みやすく実践しやすい。
Functional Programming self-affirmations:
— Dmitrii Kovanikov (@ChShersh) 2024年11月22日
1. Parse, Don’t Validate
2. Make Illegal States Unrepresentable
3. Errors as values
4. Functional Core, Imperative Shell
5. Smart Constructor
Repeat daily in front of a mirror for 2 minutes.
分類軸：事前条件・不変表明⇒型で厳密に表現できるかで分類する
分類軸：信頼性・保守性⇒ISO品質特性より
・Parse, Don’t Validate
・Make Illegal States Unrepresentable
・Smart Constructor
・Errors as values
４原則はいずれも型に着目している。
厳密な型により後続処理の設計を改善し、保守性・信頼性を向上できる。
改善できないものについても対処は考える。
・Make Illegal States Unrepresentable
クラスベースのアーキテクチャでどこまで従うかはよく考える。
何も考えないとドメインモデル貧血症のオブジェクトが多発する。
コントローラー以外：不変表明・事後条件を方で厳密に表現
コントローラー：型で表現された異常系に対処し、副作用を実行
副作用のある処理・ない処理を分離し、コードベースの保守性を向上できる。
■感想
関数型プログラミング。
ずっと気になって放置してしまっていたので導入として勉強になりました。
型に拘り過ぎているとドメインモデル貧血症のオブジェクトが多く生まれてしまうという話は、用法・用量を守ってお使いくださいとして理解しました。
関数型まつり、参加を悩んでいます。 - 技術書をソフトウェア開発する - jsprimerの10年から学ぶ継続的メンテナンスの技術
■メモ
jsprimer。
JavaScriptの話をする。
なぜjsprimer書いているか？
2015年に大きな変化があり、入門書を作りたかった。
変化し続けているので更新を続けている。
Working in public。生きているものは何かに依存している。
jsprimerはJSに依存している。
コードも静的状態とアクティブ状態がある。
価値を保つためにはメンテを続ける必要がある。
書籍もアクティブな状態を保つ必要がある。
なぜ書籍というスナップショットを出すか。
読みやすいようにする。
・変化を前提とした設計
スコープ管理。目的でないことを明確化し、依存を減らす。
・読みやすさを優先
書くより読むことの方が多い。読むコストを下げる工夫。
既知の言葉で未知のことを説明する。
・テスト
自動テスト（校正、表現統一）、サンプルコードの動作検証。
textlintにより、書く側でもルールを意識しやすくなる。
・変化の追従プロセス
・オープンソース開発
・コミュニティ
バグが無い書籍は無い。変化に対応できるようにする。
・経済的支援モデル
書籍出している。GitHubスポンサー。OpenCollective。
オープンソースと変わらないことをしている。
依存関係を最小化する設計。
継続的な改善サイクルを確立している。
真面目に技術書書くのと真面目にソフトウェア開発するのはほぼほぼ一緒。
■感想
つい最近はじめてページ数は少ないですが本を作ったばかりだったためとても興味深かかったです。
自分のやったことを持続性を上げるために構造化して精度をあげていくと～といったイメージが持てました。
特に本の構造化した捉え方や執筆をコーディングと重ねた捉え方も興味深かったです。
jsprimer、読みたい。 - ts-morphで、人間も編集できるコード生成を実現しよう！
■メモ
自動生成されたソースコード、なぜ編集してはいけない？
再生成したらロストしてしまうため。
動的にしたい場合は、外部に手動生成ファイルを用意して参照する。
スキーマ駆動開発。
最初にデータ構造のスキーマを定義し、それをもとにAPIやアプリケーションの開発を進める。
スキーマファースト vs. コードファースト（実装からスキーマ生成）。
同一ファイルに自動生成されたものと、手で書きたいものが同居する場合。
スキーマと実装を比較して差分を計算し、実装に反映する。
実装方針。
プログラマーの実装を尊重。必要最低限の部分だけ生成・更新をかける。
ASTを用いると少し堅牢な処理を書ける。
ts-morph。TypeScriptCompiler APIのラッパーライブラリ。
ASTベースで組み立てるか、文字列ベースで組み立ててくれる。
・良い点
人間の実装に従って人間にとって理解しやすいコード生成
生成されたコードがブラックボックスになりづらい
・悪い点
従来のコード生成と比較して複雑な処理
■感想
自動生成されたソースコードとの付き合い方について勉強になりました。
ts-morphの利用は別として、こうした機構があることは覚えておきたい。
そして、スライドのフォントが好きでした。 - 機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する
■メモ
フロントエンドで機能的凝集をあまり聞かない。
ロールごとに条件分岐、ロールごとにコンポーネント分割、どっちが読みやすい？
ロールごとにコンポーネント分割を目指したい。
複数ロール、類似の機能を多く含む複雑なシステム設計を機能的凝集で整理する。
結果、機能中心で考えることでAPI、デザイン、要件を総合的に考えることができる。
ドメインや要件の観点の分割の話題にフォーカス。
凝集度とは？
凝集度が高いモジュールは、堅牢性、信頼性、再利用性、可読性の点で良い。
UIの観点では、論理的凝集、機能的凝集。
論理的凝集：類似処理をフラグや条件で切り替えて１つに纏めている状態
機能的凝集：モジュール全体が単一の明確な目的のために構成されている状態
論理的凝集はプロダクトの成長に伴い、拡張されがち。
機能の修正や追加に耐えやすく、
要件とコードが一致しているか確認しやすい機能的凝集を目指す。
機能的な関連性を正しく評価する。
機能上やる価値があるか？デザイン上やる価値あるか？
要件上も一緒か？APIスキーマのオブジェクト型的にも一緒か？
分割すると失敗することもある。
差分が小さいと責務の薄いコンポーネントが生まれることもある。
結果、全体の可読性を落とす。
やったことでチームのベロシティ安定した。
コードと要件の対応が良くなりオンボーディングしやすくなった。
■感想
フロントエンドで凝集度の高いプログラム作るイメージができました。
責務の薄いコンポーネントについては、午前中のドメインモデル貧血症を思い出しながら聞いていました。
実践からの学びの共有尊いです。チーム内でも輪読したい。 - "良い"TSのコードを書く為のマインドセット
■メモ
TypeScriptは構造的型付け。大元がJavaScriptだから。
言語には、静的言語、動的言語がある。
静的：実行前に型が決定／動的：実行時に型が決定
TypeScriptは中間に位置する。
動的言語であるJavaScriptとの親和性を高めるために、構造的型システムを採用。
TypeScriptは半静的言語。
コードの中の健全性。実行時とコンパイル前は同じ型。（静的）
コードの中の実用性。健全性と引き換えにコードの実行自体を優先。（動的）
良いTypeScriptを書くためのマインドセット。
健全性と実用性のトレードオフを意識的に行っている。
健全性はコードが冗長になりパフォーマンスにも影響する。
実用性はセキュリティや堅牢性を犠牲にする。
どちらを選ぶべきかは状況や対象によって判断する。
■感想
TypeScript初学者にとって一番学びの濃度が高いセッションでした。
今までうっすらと伝え聞いていたTSの特徴を整理して理解できました。
トレードオフの判断はこれから実践していく上で経験していきます。
まとめ
１日目が物理的なセッションが多かったのに対して、２日目は論理的なセッションが多かった印象でした。
これからTypeScriptで実装を進めていくにあたりどういった思考をすればよいかを学べた気がします。
それは今までの自分のプログラミングの延長線上にあり、親和性が高く感じました。
これから型と戦っていきます。
１日目含め両日ともに学びの多いイベントでした。
これからTypeScriptでプロダクト開発を行っていく初学者レベルのエンジニアですが、
TypeScriptがどういった特性や課題を持ち、どういった考えで実装し、どういった流れの中にあるのかは、芳醇な経験となりました。
これからの実践を通し、学びや経験に繋げていけたらと思います。
また、１つの言語コミュニティの関心毎を終日浴びれたのも大きな経験となりました。
来月参加予定のJJUGやPHP Conferenceでも、前回までは気になるセッションのみの参加でしたが、終日じっくり参加したいと思います。
とても有意義な学びの多い２日間となりました。ありがとうございました。
来年習熟度を上げてまた参加したいです。
