大規模システムの品質をどう守る？｜テスト整備を依頼された話

はじめに

「テストコードを整備したいんですが、どこから手をつければいいか分からなくて」

あるクライアントからそんな相談を受けました。

長年運用してきた大規模なWebシステム。ユーザー数は多く、毎日使われているサービスです。コードは動いている。でもテストがない。だから変更のたびに不安になる。そういう状況でした。

クライアントが抱えていた悩み

テストがないシステムへの変更は、常に「たぶん大丈夫」の積み重ねです。

修正のたびに手動で動作確認して、「今回は問題なさそう」と判断してリリースする。でも本当に大丈夫かどうかは、本番で何か起きるまで分からない。

実際にこんなことが起きていたそうです。あるバグを修正したら、同じロジックを使っている別の機能で新たな問題が出た。改善したいコードがあっても「どこかで何かが壊れるかもしれない」という不安で手が止まる。技術的負債は分かっているのに、触れない。

規模が大きくなればなるほど、テストのない状態のリスクは大きくなっていきます。でもそのシステムを止めることもできないし、日々の開発・運用をこなしながらテストを整備する余裕もない。

「やらないといけないのは分かってる。でも手が回らない」という状態でした。

どう進めたか

いきなり書き始めなかった

最初にやったのは、「どんなテストを書くか」の基準をクライアントと合意することです。

テストといっても、どこまで網羅するかによってコストは大きく変わります。重要なロジックに手厚くテストを書く部分と、シンプルな処理は最低限確認する程度にする部分。そのメリハリをルールとして定義しました。

また、テストコードをいきなり書くのではなく、先にテストの設計書（どんなケースを検証するか）をドキュメントで作ってチームに確認してもらう、という2ステップのフローにしました。設計の段階で認識を合わせておかないと、後から「これは違う」となるリスクがあるからです。

「テストを書けない部分」を早めに判断した

既存のシステムには、構造上テストを書くのが難しい部分もあります。そこに時間をかけても費用対効果が悪い。

どこをどこまで整備するか、最初に線引きをしたことで、作業が迷子にならずに済みました。「テストしにくいところにこだわるより、テストできる層を確実にカバーする」という判断です。

やってみて難しかったこと

既存コードの把握に時間がかかる

既存システムなので、各処理がどこで何をしているかを把握するところから始まります。テストを書くためには、対象のコードが「何をすべきか」を正確に理解しなければなりません。

ここを雑にやると、動作確認ではなく「現在の挙動を記録しただけ」のテストになってしまいます。そういうテストは、後から「バグを正としてテストしていた」ということが起きます。

ルールを作っても守られないと意味がない

テストの書き方をルール化しても、実際に書かれたテストがそのルールに沿っているかを確認する仕組みがないと形骸化します。

書いたテストを別の視点でレビューするプロセスを入れたことで、漏れや誤りを早めに発見できるようになりました。

おわりに

「テストを整備したい」という相談は、大規模なサービスを持つ会社からよく来ます。

課題はだいたい同じで、「必要なのは分かってる、でも手が回らない」です。

テスト整備で大事なのは、書く量より「どう続けるか」の設計だと思っています。ルールと仕組みが整っていれば、後は積み上げていくだけです。逆にそこがないまま書き始めると、いつの間にか「何のためのテストか分からない」状態になります。

同じような状況でお困りの場合は、ぜひ一度ご相談ください。