オンラインジャーナル/PMプロの知恵コーナー

先号　　　次号

ダブリンの風(73)　「バグ」

高根　宏士：7月号

　複雑なソフトウエアに内在するバグを根絶することは至難の業である。このことはソフトウエア業界の人間が「雑」であるとか、「手抜き」や、「やってもいないテストをした」とかいって偽装行為を働いているからとかいうレベルの問題ではない。ソフトウエアが発生した由来から来ている。この数十年来、制御系にしろ、通信系にしろ、エンジニアリングの進歩により、理論は高度になり、内容は複雑になってきた。昔のように、ハードウエアで作った論理素子でそれを表現しようとすると、表現しきれない。無理に論理設計図を描いて、その通りに回路を組み立てても、設計図に問題があったとき、ハードウエアの変更は大きな手間と時間とコストがかかる。しかも設計図が大丈夫という保証はない。そのようなリスクを回避し、設計に問題があってもハードウエアを変えずに、単にデータを入れ替えれば、動かせるようにするためにコンピュータは発明され、ストアドプログラム方式が日の目を見た。プログラムはハードウエアの回路のみでは非常に困難なロジックを比較的改修が簡単に実現できる方式として編み出されたものである。したがって、ソフトウエアは膨大な論理の塊を扱うことになるため、人間の能力と特性からみれば、バグが発生するのは残念ながら仕方がないのかもしれない。
　ところで最近、「ソフトウエアのバグを根絶することは不可能に近い」ということについて、危険な兆候を感じる。ITのシステムを利用しているユーザーの方々から聞いた例である。
　最初の例は交通関係システムのユーザー(A)である。Aはシステムを発注したベンダーのプロジェクトの状況を把握するために、彼らが実施しているレビューに参加させてもらった。そこでは数名のメンバーで詳細仕様書のレビューが行われていた。各メンバーから問題点、疑問点が次々に挙げられていった。指摘された問題点は全てペンディングリストとして整理され、それぞれの修正予定日も決められていった。レビューミーティングはきちんとなされた。このミーティングに参加してAはあることに気がついた。挙げられた問題点は非常に多く、しかも誤字・脱字や送り仮名の間違いを含め、単純なミスが多かった。そこでAはこんなに問題が出ていては最終的な成果物の品質も悪いのではないかと心配になり、そのことをベンダーに伝えた。彼らは、「これだから素人は困る」というような表情をして、「ソフトウエアにバグは付きものですよ。だからレビューをやっているのではないですか。ペンディングリストもきちんと作ってフォローしていますから大丈夫ですよ」と言われてしまった。ソフトウエアのプロの云うことだからそれ以上の追求はしなかった。しかしA自身はどうしても納得がいかなかった。
　二番目の例は医療関係のシステムのユーザー(B)である。ベンダー側における最終フェーズのシステムテストに参加した。そこではBが思っていたよりも大量のバグが発生し、スケジュールは遅れ気味になり、担当者も長時間残業で息切れしそうな状況であった。しかし障害(バグ)管理はしっかりされているようで、日々バグつぶしの作業が精力的に行われていた。ただバグの内容を見ると、システムテストで出るようなバグではなく、単体テストをやっていれば、そこで検出されるようなバグや、仕様ミスにしても、少し注意して確認しておけばわかるようなミスが大半であった。Bはベンダーに、「こんなにバグがあるようでは納入されても、品質が悪くて運用に問題が出るのではないか」といった。ところがベンダーからは「ソフトウエアにバグがあるのは仕方がない。だからテストをやっているのではないですか。そして障害管理もしっかりやっています。少なくとも現在手が打てる最善はやっています。」と反論されてしまった。
　AもBもソフトウエアを主体としたシステム開発についてはプロではない。ベンダーはプロである。だからベンダーから反論されて、それを論破できるだけのものを持っていない。しかし二人は納得いかなかった。そして雑談の中でこの疑問を筆者に問いかけてきた。
　ＡやBの疑問はもっともである。個々に挙げた例では、ベンダー側の感覚が間違っている。ベンダー側が主張しているのは、筆者が最初に述べた「ソフトウエアの本質的な難しさ」のことではない。
　Bの主張はそれ以前のフェーズが雑にされていたのを、「ソフトウエアの難しさ」に転嫁している。しかもベンダー自身は転嫁している認識がない。ソフトウエアが難しいことが原因と思っている。しかし単体テストやレビューをきちんとしていれば多分システムテストに入る前に90%以上は潰しておけたはずである。
　Aにおいて指摘された事項の大半は、数名も集まってレビューするようなものではなく、詳細仕様書を書いた本人が、きちんと読み返しておけば修正できたはずだし、万一本人ができなければ本人以外の誰かがきちんとチェックしておけば済むことである。このようなことをレビューミーティングでやっているのでは、数人集まって、一人分の作業しかしていないことになる。これでは効率など思いもよらない。
　レビューについては、囲碁における、あるアマチュア高段者の話を紹介したい。彼は新聞に棋譜が連載されたりすることがあるが、その中でプロが彼の棋譜を解説していた。そこでプロの指摘は参考になるかと聞いたら、「自分が悪手とわかっていることを指摘されても参考にはならない。それは自分でもどのように打てばよかったかはわかっていることだから。プロに期待することは自分では問題ないと思った手についてプロの視点から見るとどう打てばよかったかを指摘してもらったときだ」といっていた。
　筆者が危険と感ずるのは難しいことの本質をきちんと認識せず、自分たちの未熟さから派生する問題を「本質的に難しいこと」から発生すると勘違いすることである。