2007/06/18

このバグ直しますか? - 原因療法と対症療法

急なれば標を治し、緩なれば本を治す

『黄帝内経』

実に久々の記事です (^^;)。今回はバグ修正のリスクについて書いてみます。

医療用語には「対症療法」と「原因療法」という言葉があります。表面的な症状の消失あるいは緩和を主目的とするのが「対症療法」、症状の原因となる疾患そのものを制御する治療が「原因療法」です。 完全回復や再発防止のためには原因療法が必要になりますが、事情によりそれがとれない時に対症療法がとられます。

対症療法を選択する理由はいくつかパターンがあります。そのひとつは、症状の原因が不明な場合。この場合、分かっているのは症状のみですから、対症療法以外すべがありません。原因はわかっていても有効な対策がわからない場合も同じです。風邪薬なんていうのはそうですね。
もうひとつのパターンは、原因療法に伴うコストやリスクが大きいた場合。手術をするにもお金がかかりすぎるとか、体力がもたないとかいう場合がそうです。その他、原因療法を施す前の応急処置として対症療法がとられることもあります。原因療法と対症療法は、排他的なものではなく相互に補完し合う関係にあります。

さて、この話は、ソフトウェア開発におけるバグ修正にも当てはまります。ソフトウェア開発における実装フェーズでは、バグの検出とその修正というサイクルが繰り返されます。このバグつぶし、デバッグという作業は病気の治療に似ています。そして、それは基本的には、根本原因をさぐってそれを直す原因治療として行われます。

しかし、これが製品リリース直前、あるいは、既にシステムの運用開始後、パッケージや組込みソフトウェアであれば製品発売してしまった後だったらどうでしょう。この場合は、不具合の原因がわかっていても、原因療法ではなく対症療法がとられることがあります。これは、修正のリスクを考慮してのことです。
このような運用直前あるいは運用中のケースでは、システムの品質は、一度は確認されているはずです。そして、バグの修正というのはそのシステムに変更を入れるわけですから、その部分の再確認が必要になってしまいます。しかし、大規模なシステムの検証コストは莫大です。全ての検証をやり直すなんてことはもちろんできません。よって、修正の影響範囲をしぼり、検証の範囲もしぼるということが必要になってきます。そこで、広い範囲に影響が及ぶような原因療法ではなく、見つかったバグの発生条件の場合のみに影響するような対症療法を選択するようなケースが出てくるのです。

別の医療用語に「トリアージ」という言葉があります。災害医療において、多数の傷病者を重症度と緊急性によって分別し、その対応方法を決める手順を指す用語です。このような緊急の場面では、重篤であっても救命不可能な患者は切り捨てられます。非常につらい選択ですが、できるだけ多くの命を救うためには必要な選択です。
運用直前や運用中のバグ修正も同じです。修正の時間は限られています。複数のバグがあったとしても、全てを修正して検証する時間はないかもしれません。つまり、バグの取捨選択が必要になります。先に書いたように対症療法でしのぐことによって検証時間を節約するというだけでなく、そもそも直さずにそのままにするという選択も時には必要です。検証コストを削減する一番の方法は、修正しないことですから。

分かっているバグを直さない、あるいは、原因がわかっていて根本修正もできるのに、表面的な回避しかしないというのは、プログラマにとっては非常に嫌な選択です。バグが見つかったら直したいというのが大半の意見でしょう。しかし、ソフトウェアの修正には、常にリスクが伴うということを忘れてはいけません。例え修正が正規のものであっても、隠れたバグをエンバグさせる可能性だってあります。マイナス×マイナスでプラスになっていたものが、マイナスになるかもしれないのです。修正したい気持ちは非常に非常に良く分かりますし、つらいのですが、ここはぐっと我慢が必要です。エレガントさよりも品質確保が重要なのです。

ソフトウェア開発の現場では、「動いているコードはさわるな」ということがよく言われます。これは上のような話が背景にあります。しかし、これも絶対ではありません。時と場合によります。運用直前や運用中は、上のような対症療法が有効な場合が多いですが、開発に余裕がある場合は、原因療法でしっかり直しておくべき場合がほとんどです。
所詮、対症療法は一時凌ぎにすぎません。安易な解熱剤や鎮痛剤の服用と同じで、中途半端な回避コードは、不具合を潜伏させ、自体をより悪化させることすらあります。ですので、対症療法をとった箇所はきちんと管理し、適切なフォローをすることを忘れてはいけません。

不具合のない品質の高い成果物を作ることがプログラマ・エンジニアの役目です。この時、理想論に走るのではなく、限られたリソースの中でいかにそれを最大化するかを意識することが、プロのエンジニアとしては必要です。

#　もちろん理想を追うのもわすれちゃいけません ^^)

【関連記事】
・バグを潜伏させない工夫
・デバッグと不確定性原理
・デバッグ指向のススメ

【関連書籍】
・ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系 F. ブッシュマン他
・ソフトウェア開発の持つべき文化 IT Architects' Archive ソフトウェア開発の課題1
・開発の現場 vol.007 - 運用・保守
・ソフトウェアパターン再考―ソフトウェア品質学 各論 パターン発祥から今後の展望まで
・達人プログラマー―システム開発の職人から名匠への道 Andrew Hunt
・リファクタリング―プログラムの体質改善テクニック