修正は作業の終わりではない_デグレードと回帰テスト

ソフトウェア開発の世界ってなんだかミステリー小説みたいだなって思うことがあるんですよね。ほうミステリー小説ですか。 ええ、犯人、つまりバグを捕まえたと思ったら、全然別の場所でえーと、新しい事件が起きるみたいな。ああ、なるほど。 問題を解決したはずなのに、かえって事態が悪化しちゃったなんて経験あなたにもありませんか？ ありますね。良かれと思ったことが裏目に出るというのは。ですよね。今回あなたが共有してくださった資料は まさにその謎を解き明かすための、まあ、捜査資料みたいで。テーマが「なぜ修正は作業の終わりではないのか」。ええ。 資料の出発点は、テストで見つかったバグを修正する「デバッグ」という作業ですね。これで一見落着と祝杯を上げたくたくなりますが、ここからが本題と。 まさに。その祝杯を上げる瞬間が実は一段危ないんだと資料は警告してるんです。危ないですか？ええ。 バグを取り除いたっていう達成感が、次の悲劇の序章かも、と。この予期せぬ副作用こそが今回の話の核心ですね。 なるほど、こっちを立てればあっちが立たず、みたいな状況ですね。資料ではこの現象を「デグレード」あるいは「先祖返り」と呼んでいました。 そうですそうです。例えば、Aという不具合を直したら、今まで、えーと、完璧に動いていたはずのBという機能が、なぜか動かなくなる。 想像するだけでちょっと、背筋が寒くなります。ええ。そしてじゃあなぜそんなことが起きるのか、資料の分析が非常に興味深いんです。ほう。 現代のソフトウェアって無数の機能が、なんていうか生態系みたいに相互に依存し合っているからだと。 生態系ですか？そうなんです。だから1箇所の変更が、ドミノ倒しみたいに全く予期しない場所へ影響を及ぼすわけです。 資料にあったんですが、ボタンの色を変えるっていうごく些細な修正が、決済システム全体を止めてしまった、なんて笑えない実例もあるそうですよ。 うわあ、それは怖いですね。一つの修正がそんな見えない爆弾になりうると。だとしたら開発チームはどうやってその地雷原を歩いていくんでしょう。 何かこう身を守るための地図みたいなものはあるんですか？素晴らしい問いですね。その地図こそが、 資料のもう一つのキーワードである「リグレッションテスト」、日本語で言う「回帰テスト」なんです。リグレッションテスト。はい。 回帰、という言葉の通り、基本に立ち返ってもう一度テストをやり直す、というアプローチです。 えーと、ちょっと待ってください。「もう一度」というのは、まさか、全てのテストをやり直すってことですか？そういうことになります。 いやいや。それって、あのー、現実的に可能なんですか？新機能を一つ追加するたびに全部のテストを人間が手でやってたら 日が暮れるどころか、もうサービスがリリースできなくなりそうですけど。その通りです。あなたの指摘はもっともで。 もし全部手作業でやっていたら、それはもう非現実的でしょうね。ですよね。だからこそ現場では このリグレッションテストの大部分を自動化するのが常識になっている、と資料にはあります。自動化！ ええ。人間が寝ている夜間にプログラムが自動で何千、何万というテスト項目をこう延々と実行してくれるわけです。 なるほど。人間がやるんじゃなくて、機械に任せるんですね。つまり、修正と影響範囲の再確認っていうのは、常にセットで考えなきゃいけないと。 ええ。修正っていう外科手術をしたら、術後に全身の健康診断をもう一度やる、みたいなイメージでしょうか。まさにとその通りです。 今回の議論から得られる本質的な教訓は、目の前の問題解決、つまりデバッグだけで満足しちゃいけないということなんです。 はい。その解決策がシステム全体という生態系にどんな影響を与えたか、必ず検証、つまりリグレッションテストをする必要がある。 この3つのキーワードをぜひ覚えておいてほしいんです。お願いします。まず、デバッグ。これはバグを直すこと。 はい。次に、デグレード。これはその修正が原因で他の正常な機能が壊れてしまうこと。うーん。 そして、リグレッションテスト。これはそのデグレードが起きていないかを確認するための、いわば保険ですね。 保険、ですか。なるほどなあ。この考え方ってソフトウェア開発だけの話じゃないですよね。と、言いますと？ 例えば、あなたが日々の生活で何かを改善しようとするとき。そうですね、例えば健康のために新しいサプリを飲み始めた、とします。 それがあなたのデバッグです。ええ。不調を直そうとしているわけですね。そうです。では、あなたのリグレッションテストは一体何になるんでしょう。 その改善策が意図せず他の何か、例えば睡眠の質とか、他の生活習慣を壊していないか、どうやって確認しますか？