バグ修正とリグレッションテストの仕組み

どうも。今回はですね、ソフトウェア開発の、まあ、裏側というか、見過ごされがちなんですけど実は品質を支えるめちゃくちゃ大事なステップ、バグ修正とその仕組みについてちょっと深掘っていこうと思います。 早速見ていきましょう。 いや、これ、プロジェクトに関わったことがある人ならもう「あるある」って頷いちゃうんじゃないですかね。よし、直したぞって報告があったはずの機能がなぜかまた動かなくなってる。 え？なんで？って頭を抱えたくなるあの瞬間。これね、実は開発の現場だと、本当に、本当によくある話なんですよ。 じゃあ、なんでそんなことが起きるのか、その話の始まりから見ていきましょう。多くの人が、まあ直感的にこう思うんですよね。 バグが一個あったらそれを一個直せば「はい、おしまい」って。でも果たして本当にそれで完了なんでしょうか。 この、一見すると当たり前っぽい、でも実は大きな誤解から話を始めていきたいと思います。 はい。まずは基本の言葉からですね。「デバッグ」です。これ、まあ、ご存知の方も多いと思いますが、プログラムから虫、つまりバグを取り除く作業のことですよね。 どこが原因なのか、その根本を突き止めて、プログラムを正しく直す。開発には欠かせない、めちゃくちゃ大事なプロセスです。 で、このデバッグが、無事に終わるとチームはもう大盛り上がりですよ。「よっしゃ、直った、これでリリースできるぞ」ってね。 この達成感、わかる、すごくわかる。でも、実はこの瞬間こそが一番やばい、危険な落とし穴が口を開けて待ってるタイミングだったりするんですよ。 いや、なんでバグが直った瞬間が危険なの？って思いますよね。ここからが今日の話の核心です。そう。そこに潜んでいるのが、この「デグレード」っていう隠れた危険なんです。 1つ直したと思ったら、全然別のところが壊れちゃう。この本当に予期せぬ問題についてちょっと詳しく見ていきましょう。 今回の話の、いわば悪役が、この「デグレード」ですね。日本語だと「先祖返り」なんて言ったり、英語だと「リグレッション」、つまり「退行」ですね、そう呼ばれたりもします。 要するにどういうことかっていうと、何かを直すじゃないですか。そのせいで今までずっと全く問題なく、完璧に動いてたはずの全然別の機能が ある日突然動かなくなる。これがデグレードの正体です。 このスライド見てもらうと、一発でわかると思います。まさに、コードの中で起きるドミノ倒し。見てください。左側。 修正前は機能Aが壊れてて、機能Bはちゃんと動いてる。OK。で、開発者が一生懸命機能Aを直します。 すると右側。はい。機能Aはバッチリ直りました。と思いきや、そのせいで今まで元気だった機能Bが、今度は壊れちゃってるんです。 「えー？」みたいな。この予期せぬ連鎖反応こそがデグレードの一番質の悪いところなんです。 じゃあこんな恐ろしいデグレードっていう怪物に、プロはどうやって立ち向かうのか。その答えがこれなんです。 ソフトウェアの品質を守るための絶対欠かせない安全網。そう、リグレッションテストの登場です。 それがこの「リグレッションテスト」。まあ日本語だと「回帰テスト」なんて言ったりもしますね。 で、これ、何をするかっていうと、目的はたった一つです。今回の修正のせいで、今まで動いてたものが壊れてないよねっていうのを確認する。 そのためだけに、過去に一度パスしたテストを、もう一回全部やり直す。そういう作業なんです。 って聞くと、多分、今、皆さん、こう思いましたよね。「えー、嘘でしょ、全部のテストを、また一から、全部やり直すの？ そんなの時間がいくらあっても足りないじゃん」って。はい。その通りです。全くもおっしゃる通り。手でやったらまあ無理ですよね。 もちろん何百、何千っていうテスト項目を、毎回人間が手でポチポチやり直すなんてまあ不可能です。 だからこそプロの現場では、このとんでもなく大変なリグレッションテストを「自動化」するのが当たり前になってるんですね。 それこそJenkinsみたいなツールでCICDパイプラインってやつを組んで、開発者たちがぐっすり寝てる夜の間に、コンピューターが文句も言わず休むことなく、ずっとテストを回し続けてくれる、そういう仕組みをちゃんと作っておくわけです。 これが高い品質を守り抜くためのプロの仕事の流れです。いいですか。まず、バグを見つけますよね。で、それを直す。 でも、ここで終わりじゃないんです。必ずこの3番目、リグレッションテストを前に挟む。 ここで、「よし、全部OKだね」って確認が取れて初めて、安心してリリースボタンを押せるわけです。このステップこそが製品の信頼を守るための最後の砦と言ってもいいかもしれません。 はい。ここまでデバッグのお話、そして恐ろしいデグレードの話、さらにはその安全網であるリグレッションテストの話をしてきました。 じゃあここまでの内容をギュッとまとめて、今日皆さんにこれだけは覚えて帰ってほしいっていう一番大事なポイントをはっきりさせたいと思います。 結論、これに尽きます。修正と再テストはもう常にワンセット、ニコイチなんです。 高品質なものを作ろうと思ったら、バグを直すっていう作業と、そのせいで他が壊れてないか再テストするっていう作業は、絶対に切り離しちゃだめ。 この二つでようやく一つのタスクが完了する。この考え方ができてるかどうかが、もしかしたらプロとアマチュアを分ける一つの大きな境界線なのかもしれないですね。 じゃあ最後に今日の重要キーワード3つ、おさらいしておきましょうか。まず「デバッグ」。これはプログラムを直すこと。 で、「デグレード」。これは何かを直したら、今まで動いてた別のものが壊れちゃう、あの嫌な現象のことでした。 そして最後。「リグレッションテスト」。これはそのデグレードが起きていないかをチェックするための、大事な大事な安全確認、ということでしたね。 さて、この話をですね、ぜひ一度ご自身のプロジェクトとかチームに当てはめて考えてみてほしいんです。 皆さんのプロジェクトには、このデグレードから製品を守るための安全網、ちゃんと、しかも十分に強く張られていますか？ この問いかけが皆さんのチームの品質をもうワンランク上に引き上げる何かいいきっかけになったら、僕としてはすごく嬉しいです。