ソフトウェア開発にバグはつきものだ。プログラマであれば、バグに関する思い出の一つや二つはあるだろう。しかし、近年の短納期化やコスト重視の影響で、デバッグやテスト工程の様相は昔とは大分変わってきた。今回は、バグに関する法則を紹介する。
「世にバグの種は尽きまじ」であり「過ちを犯すのは人の常」なので、プログラムにはバグがつきものだ。バグに関するマーフィ学は長い歴史があり、多くの研究成果があるが、ここでは、昔の良き時代を振り返って現状を嘆くことにする。
往年は、納期にゆとりがあったし、プロジェクト管理も鷹揚だったので、プログラマは自分の関心に応じてデバッグに時間を割くことができた。当時のベテランプログラマにとって、デバッグは知的好奇心をくすぐり、後輩から驚嘆の目で見られ、達成感を味わえるので、テストは至福の工程だったのである。
ところが近年は、納期が厳しく、テスト期間を短縮する傾向がある。しかも、テスト管理が重視され、テストツールが普及してきたため、デバッグが無味乾燥の作業になってしまった。至福の工程どころか苦痛の工程になったのは嘆かわしいことだ。
バグ(虫)は隠れる。バグは跳ねる(作者不詳)
1970年代までのプログラマならば、プログラムのエラーを“バグ(虫)”と言い表すことを直感的に納得できるが、若い人には連想できまい。
「真空管式コンピュータに入り込んだ虫の死骸が、誤動作を引き起こしたこと」が“バグ(虫)”の由来だそうだが、プログラムのバグについては明確ではない。おそらく、エラー個所を発見して修正すると、他の場所で新たにエラーが発生する。それがノミが跳ねることを連想させたのであろう。
当時は、ソースプログラムを連続用紙という長い紙に印刷して床に広げ、這いつくばってプログラムのエラーを探していた(注)。これがフンドシのノミ探しを連想させることから名付けられたという説もあるが、日本独特の地方伝説であろう。
なお、虫との比喩で重要なのは、冬の間は活動しないが、春になると成虫になり動き出すことである。日次処理や月次処理でのバグが治まったので安心していると、4月初めの期末処理で動き出して大騒ぎになるのが慣例である。
(注)這いつくばる姿はエリートに不似合いである。そもそも構造化プログラミングは、GOTO命令により数メートル先まで這うのを避けるため、モジュール化は一つのソースプログラムの長さを1枚の紙に印刷できる行数(現在ではディスプレイ表示のためにその半分程度の行数)にするためであり、どちらも「机上デバッグ」を実現することが目的だった。
(昔)コンピュータは思ったようには動かない。指示したように動く(作者不詳)
(今)プログラムが期待した通りに動く保証はない。うまく動いたら神に感謝せよ
レガシー時代のベテランプログラマは、オープン環境に移行する際に大きなカルチャーショックを受けた。その一つにコンピュータ無謬性信仰の崩壊がある。
レガシー時代では、見習いプログラマから「先輩! コンピュータがエラーを起こしました!」と報告を受けたとき、「コンピュータはキミが思ったようには動かないさ。キミが指示したとおりに動くんだ」と言い、「COBOLコンパイラにエラーはない。キミのプログラムにエラーがあるんだ。マニュアルをよく読め」と諭していた。
しかし、パソコンの世界では「思ったように動かない」だけでなく、「指示した通りにも動かない」ことはよくあることだ。コンパイラはマニュアル(もしあればだが)の通りに動かない。そこで、「プログラマを疑うな。コンピュータを疑え」の方が一般的になってきた。
さらには、思いがけない動作が、コンパイラの「誤り」ではなく「仕様」だと居直られることすらある。
また、GUI環境で自動生成されたプログラムは、ソースコードの解読が事実上困難でプログラマのミスを指摘できない場合もある。そうなると、「どちらも疑うな。違う言語や開発環境で作り直せ」という対処が適切な場合が多くなる。その場合でも誤動作の原因は不明なので、作り直したプログラムが期待した通りに動くかどうかは分からない。
言語は思考を規制する
カルチャーショックは、無謬性の崩壊だけではない。異言語による思考混乱を受けたのである。日本語は右脳を使うので情緒的、英語は左脳を使うので論理的なのだそうだが、最初に覚えた言語の影響は恐ろしい。
COBOLをネイティブとする人は、ポインタが理解できない。FORTRANで育った人は、「count」を「icount」としないと不安に感じる(整数変数名はIかJで始まる規則があった)。
昔は配列は1から始まったが、現在では0からである。「配列の5番目の要素」といったとき、X(5)を指すのだろうか、x[4]なのだろうか? 「重点は次の3つです。第0に……、第1に……、そして最後の第2は……」と話す連中との対話は疲れる。
言語は字種にも影響する。昔は大文字だけが使用され、その後、小文字だけになり、現在では混在している。さらに、大文字と小文字を区別するようになった。しかし、男子学生をStudent、女子学生をstudentと命名するプログラマとは付き合いにくい。
このような環境では、往年のバグ探し能力を発揮することはできず、むしろ変な言動をして冷笑されるようになってしまった。
(脱線)多くの言語があるのに、少なくとも日本語対応言語ではYで始まる予約語を持つ言語はない(私の不勉強? あったら教えてください)。その理由は、JISキーボードでYは「ん」に対応しており、日本語に「ん」で始まる語がないからだろうか。
バグ発見能力が低ければ、納期を厳守できる
(逆)納期を短縮するには、バグを発見するな
最近は品質と納期が重視される。
プログラムの潜在バグを減らすことが品質向上には重要だが、それには十分なテスト期間が必要で納期が長くなる。また、潜在バグ量は測定できないので、バグの発見・修正の履歴を累積グラフにして、その傾きが水平に近くなっとときに打ち切ることになる。
バグ発見能力が低ければ、早期に水平の状況になる。すなわち、プロジェクトメンバーの能力が低いほど、納期は短縮できるのである。
また、納期を短縮するには、意図的にバグを発見しなければ良い。どうせバグがあることはユーザーも承知しているので、問題をSLAの交渉時期にまで先延ばしするのは容易である。さらに、管理能力の低いユーザーならば、後日、実際にエラーが発生しても気付かないかもしれないし、プログラムが原因だと特定できないかもしれない。発生確率を考慮することはリスクマネジメントの基本である。
このような総合的判断ができないバカがテストを担当すると、ささいなバグまで発見し、スケジュールを乱してしまう。また、マジメな連中は、多様な状況を配慮してテストケースを増やしてしまう。納期遅延を防ぐ最良の手段は、このような連中をプロジェクトチームに参加させないことである。
テスト工程は、ユーザーがベンダを最も信頼する工程である
システムテスト以降のテストでは、ユーザーがテストデータを作成し、主体になって行う必要がある。
ところが実際には、旧システムの先月データファイルといくつかの出力結果を渡すだけというケースが多い。ベンダがもっと積極的になるように依頼しても、「オタクの管理能力を信じて委託したのだから」という始末。どうせ「後になってエラーが見つかったら、タダで直させれば良いさ」と思っているのだろう。テスト管理よりもSLAの交渉に関心が高い傾向がある。
テスト軽視には伝統的な原因もある。
昔は情報システムのトラブルに寛容だった。取引先と業務上のトラブルがあると、「すみません。コンピュータにトラブルがありまして?」と言えば、互いにキズがつかず円満に収拾できた(これがシステム化の最大の効果だとも言われた)。
しかし、現在では、システムのトラブルは大きな社会問題に発展することすらあり、ユーザーが責任を追及されるようになってきた。それにもかかわらず、いまだにテスト軽視の習慣が残っているのは困ったものだ。
▼著者名 木暮 仁(こぐれ ひとし)
東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士(情報工学)、中小企業診断士、ITコーディネータ、システム監査など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」(日科技連出版社)、「もうかる情報化、会社をつぶす情報化」(リックテレコム)など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している
Copyright © ITmedia, Inc. All Rights Reserved.