はじめに 開発者であれば誰しも、「できるだけバグの少ないコードを書きたい」と思っていると思います。 また、実際にバグの多いコードに苦しんだ経験があるのではないでしょうか。自分自身もそのひとりです。 修正したはずの箇所で別の不具合が起きたり、「どこを変更すると何が壊れるのか」がわからなくなったり、特にコード量が多いと、「たぶん動いているけど、本当に大丈夫だろうか」という不安を抱えながら開発を進めることもあると思います。 そんな中で単体テストを書く機会があり、「そもそも単体テストとは何なのか」「どのように書けばよいのか」という疑問を持ちました。 そこで単体テストについて調べていく中で、「テスト駆動開発（TDD）」という言葉にたどり着きました。 「テスト駆動開発（TDD）」と聞いて “テストを書いてから実装をする開発手法”という説明はよく見かけます。しかし、有名なエンジニアたちが口をそろえて「T

はじめに Claude CodeやCodexの登場によって、IT業界の開発現場は、単に「プログラミングが速くなった」だけでは説明できない構造変化を起こしています。重要なのは、AIが優秀なプログラマーを完全に代替したことではありません。むしろ、AIによって大量の「それっぽいコード」が短時間で返ってくるようになり、熟練者がそれを監修する構造が強まったことです。 これは、アニメ業界における動画、第二原画、外注、作画監督、チーフ原画マンの関係にかなり近いものです。アニメ業界では、すべての絵をトップアニメーターが一枚ずつ描くわけではありません。大量の作業は外部や若手に渡され、返ってきたものを作画監督やチーフ原画マンが直し、全体の品質を揃えます。 IT業界では、従来この構造が成立しにくいものでした。なぜなら、プログラマーの力量差が大きすぎて、外に投げたコードが「直せば使える素材」として返ってくる保証が