テストコードを書くように言われても、目の前の実装や納期があると、すぐには手をつけにくいことがあります。
機能を作るだけでも時間が足りない。仕様変更も入る。レビューもある。リリース日も近い。その中で「テストコードも書いてください」と言われると、どうしても追加作業に見えやすくなります。
このとき、「品質のためです」「会社のためです」と説明しても、あまり実感できないケースがあります。説明自体は正しくても、いま手を動かしている人の意識は別の方に向いているからです。
むしろ伝わりやすいのは、「あとで自分が楽になるから」という説明の仕方だと思います。テストコードの役割は、品質保証だけではありません。コードを変更するときの不安を減らし、安心して触れる状態に近づけるところにも効いてきます。
品質保証だけで見ると腹落ちしにくい
テストコードを「品質を守るためのもの」とだけ捉えると、今の作業からは効果が実感しにくいことがあります。
もちろん、品質を守る役割はあります。意図した挙動が壊れていないかを確認できるので、不具合の早期発見にもつながります。ただ、開発者の実感としては、それだけでは自分の作業として腹落ちしにくいことがあります。
目の前の実装が忙しいとき、未来の品質や会社全体の利益は、どうしても遠く見えます。自分の作業が増える感覚だけが残ると、テストコードは後回しになりがちです。
見方を少し変えると、テストコードは将来の自分に向けた確認手段になります。後日コードを直すとき、仕様を読み返し、影響範囲を調べ、手動で画面を確認し、レビューで説明する。その負担を少し減らしてくれるものです。
全部を自動化するためではありません。少なくとも、壊すと困る挙動が守られているかをすぐ確認できる。それだけでも、作業中の緊張感はかなり変わります。
古いシステムほど変更が怖い
古いシステムで開発スピードが落ちる理由は、実装そのものだけではありません。
「ここを触ると何が壊れるか分からない」という不安があると、作業の判断が重くなります。コードが読みにくい、技術が古い、仕様を知っている人が少ない。そうした事情もありますが、実務で手をつけにくくなるのは、もっと具体的な場面です。
このif文は消してよいのか。
ライブラリを更新したら、別の画面で副作用が出ないか。
金曜夕方のリリースで、この変更を入れて本当に大丈夫なのか。
こうした不安があると、変更そのものより確認に時間がかかります。実装は数行でも、影響範囲の調査、手動確認、関係者への確認、リリース後の監視が重くなります。
結果として、ビジネス側から見ると「小さな変更のはずなのに時間がかかる」状態になります。これは誰かが慎重すぎるという話ではありません。確認できる仕組みが少ないと、慎重に進めざるを得ないだけです。
テストコードがあると確認しながら進められる
テストコードがあると、すべてを理解し切れていなくても「少なくともここまでは守られている」と確認できます。
これはかなり大きいです。古いコードや複雑な仕様では、全体を完全に把握してから変更するのは現実的ではありません。理解できた範囲を増やしながら、安全に触れる形を作っていくほうが、実務には合っています。
テストコードがない状態では、変更後の確認が勘や気合いに寄りやすくなります。
この画面は手動で見た。
レビューでも違和感はなかった。
たぶん大丈夫。
もちろん、それで進めるしかない場面もあります。ただ、その確認が毎回人の記憶や注意力に依存すると、変更するたびに同じ不安が戻ってきます。
テストコードがあれば、同じ確認を何度も実行できます。実装の差分を入れたあと、既存の挙動が守られているかを機械的に見られます。変更を、勘で進める作業から、確認しながら進める作業に変えられます。
テストコードの実務で効果を発揮するポイントはここにあります。
最初から完璧なテストは要らない
テストコードの話になると、最初から網羅性を求めてしまうことがあります。
単体テストをどこまで書くか。境界値をどう扱うか。モックをどう設計するか。E2Eまで必要か。考えることは多いです。そこを最初から全部きれいに決めようとすると、書き始める前に疲れてしまいます。
最初から完璧なテストは要りません。
まずは、壊すと困る挙動に柵を立てるだけでも十分です。売上に関わる計算、ログインや権限の判定、データ更新の条件、ユーザーがよく通る画面の主要な挙動。そこが守られているだけで、次の変更時に確認しやすくなります。
テストコードは、理想の設計を一気に完成させるためだけのものではありません。変更のたびに不安が増えている箇所へ、少しずつ確認できる足場を作るものでもあります。
後の自分が助かる場所から書く。そう考えると、テストコードは少し始めやすくなります。
現場で確認しておきたいこと
テストコードを書き始めるときは、抽象的に「品質を上げる」と考えるより、次に変更が入ったときに何を確認できると楽になるかを見ると判断しやすくなります。
・最近の修正で、毎回手動確認している画面や処理を見る
・壊れるとリリース判断が重くなる機能を洗い出す
・消してよいか迷うif文や古い分岐の周辺で、守りたい挙動を先にテスト化する
・ライブラリ更新やリファクタリング前に、現状の挙動を固定するテストを書く
・リリース前に不安になる箇所を、次回は自動で確認できないか見る
・原因がまだ整理できていない不具合は、再現条件と期待する挙動をテストに残せないか考える
・レビューで毎回説明している仕様は、テスト名やテストケースから読み取れる形にできないか確認する
テストコードは、開発者を責めるためのものではありません。あとから触る人が、必要以上に怖がらずに変更できるようにするための確認手段です。
最初の一歩は小さくても、壊すと困る挙動に柵があるだけで、次の調査、修正、レビュー、リリースの見え方は変わります。そこから始めると、テストコードは「やらされる作業」ではなく、後の自分を助ける仕組みとして扱いやすくなります。
おわりに
X（旧Twitter）やBlueskyを中心に日々発信しております。
是非他のSNSもご覧いただけますと幸甚でございます。
https://x.com/itchie_tatsumi
https://bsky.app/profile/itchie-tatsumi.bsky.social
https://www.facebook.com/ichino.souta
また、辰巳電子工業SS事業部では、エンジニアが安心して長く働ける環境づくりに取り組んでおります。「今の経験で応募できるか知りたい」「案件やキャリア支援について聞いてみたい」という方は、是非カジュアル面談からお気軽にご相談願います。
