「分かりやすい」で選ぶ - kaonavi tech talk 2025.9.18

Transcript

1. 「分かりやすい」で選ぶ 島田春樹 - Kaonavi Tech Talk 2025.9.18
2. 自己紹介 @peaske7 https://peas.ke 島田春樹（ジェイ） 24卒の代。主にTypeScript（元Rust） 今はLLMを使ったプロダクトを作ってます ↓ Respoで第一エンジニア ↓ Paidyでバックエンド now! Lymoでエンジニア
3. プログラミングって、 結構ロマンありますよね
4. 「難しそう」ってかっこいい - 凝った技術、自慢したくなるような実装にはロマンがある - 関数型のノマドとかファンクターとかってなんかかっこいい - NetflixとかUberのブログで紹介されてる技術ってかっこいい - ZigとかRustってなんかかっこいい - k8s使ってみたいとか
5. - LLM、Effect-ts、Bun、Svelte、T3 Stack … - ワクワクする、ロマンがある （Typescript界隈は特に流行り廃りが激しい） 「新しい」ってかっこいい
6. 「楽しい」と「仕事」の境界 エンジニアを生業とする以上、ものづくりで問題解決しないといけない 専門知識を持ってない問題領域で問題解決しないといけないかもしれない => 解決する道具箱のオーバーヘッドが少ないほうがいい 参考：https://boringtechnology.club/
7. Complexity（複雑性）を考えるようになったきっかけ - 技術本や技術ブログ、前職でのシニアエンジニアとの出会い - Hacker Newsのおじさんたち - 一周回ってちょっと疑い深い シニアエンジニア層
8. 複雑性を減らす工夫
9. 複雑性の管理こそ最大の難点 - 人が使い物を作っていると、どうしても複雑になる。 - LLMコード生成でたくさん書けても、バグが少なく安全なもの、メンテができるものを 作るにはレビューが必要。 - システムの複雑性がそのまま実装・運用コスト（= 開発スピードとサービスの安定 性）に響く。
10. 技術選びで複雑性を減らす 1. 複雑性が「目に見える」 = 隠されてないことが重要 2. 依存関係が少ない = 考える時のオーバーヘッドを抑えられる、SSOT 3. 直感が効きやすい = 考えやすい 4. 説明しやすい 5. 問題領域が探索されてる = RDBがこける書き方って周知だよね
11. コード生成で複雑性を減らす 1. 変更内容とスコープを明確にする = 変更内容が予測しやすい 2. コード規約と「黄金ファイル」で「書いて欲しい書き方」が分かりやすい 3. 生成を”step”で分解し、一度で生成する内容を限らせる = 質とレビューのしやすさの担保 4. 下手に抽象化するより、２度同じコードを書いたほうがマシ = DRYならぬTRY（Try not to Repeat Yourself） 5. 郷に入れば郷に従え = JSにJSの書き方、GoにはGoの書き方がある
12. 例 root/ ├─ style_guides/ │ ├─ TYPESCRIPT.md │ ├─ IMPLEMENTATION_PLAN.md │ ├─ FRONTEND.md ├─ plans/ │ ├─ FEATURE_IMPL_PLAN.md ├─ CLAUDE.md
13. ありがとうございました 島田春樹 @peaske7 https://peas.ke