バグ検出ドリル（10）“昔のバグ”は生命力が最強：山浦恒央の“くみこみ”な話（110）（1/4 ページ）

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第10回では、生命力最強という“昔のバグ”がテーマです。前回の第9回で扱った迷路探索プログラムの改造版からバグを見つけ出してください！

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

1．はじめに

　本連載では、エンジニアのバグ検出力の向上を目指し、バグ入りの問題を出題して読者のみなさんに見つけてもらいます。本コラムをきっかけに、より良いソフト開発につなげていただければと思います。

　今回は、前回の記事で使った迷路探索プログラムの改造版を出題します。課題としては少し長い200行のプログラムですが、他人のプログラムをあら探しする「システマチックに意地悪な視点」でじっくりバグを見つけてください。

2．昔のバグはものすごく手ごわい

※写真はイメージです

　ソフトの機能追加や修正などで自分のプログラムを見直してみると、自分が見過ごしていたバグを発見することがあります。時間がたつと、自分のプログラムでも先入観なく第三者の視点で見直せることでバグが顕在化するためです。とはいえ、何世代ものバージョンに渡りずっと生き残ったバグは、非常に生命力が強く、目の前にぶら下がっていても、なかなか見えてこないので、注意が必要です。

　自分のプログラムのバグなら、まだよいのですが、他のエンジニアが記述したプログラムで「不審箇所」を発見した場合、「これはバグなのか、仕様通りで自分が間違っているのか」と大いに悩みますね。自分の考えや疑問を最初の開発者に確認できれば良いのですが、たいていは会社にいません^※1）。

※1）筆者がプログラムの保守をしていた時のこと。コードを読んでいて「おかしいな」と感じた部分がありました。そこで、ソースコードの先頭のコメント欄に記述してある開発者を探そうとしたところ、先輩エンジニアから「あの人はもう別の会社に転職したよ」と言われ、悲しくなりました。

　ソフトウェア開発のフェーズは、「要求仕様」「設計」「コーディング」「デバッグ」「テスト（テスト合格後、出荷）」「（バージョン2以降の）保守」となります。この中で、圧倒的に時間と労働力をかけるのが「保守」で、全体の時間とコストの3分の2を投入します。バージョン1が完成した時点でプロジェクトが解散し、当初のエンジニアの10％だけで、バージョン2以降の保守をするのが一般的です。当然、保守担当の技術者は、他人のソースコード（9人分？）の面倒を見なければなりません。プログラムのオリジナルの作成者が同じ会社の他の部署にいる場合は、問い合わせが可能ですが、他社へ転職していたらお手上げです。仕様とソースコード間のトレーサビリティーは非常に重要ですが、技術者のトレーサビリティーも、同様に重要です。

　ちなみに、エンジニアが1つの会社にとどまる期間が2年弱の「転職王国」、米国では、保守の問題の1位が「開発したエンジニアの転職」、2位が「母体の理解、ドキュメント不足」、3位が「変更箇所の特定」です。2位、3位は、オリジナルの開発者が隣にいれば、解決がかなり容易になります。保守において、「オリジナルの開発者が身近にいない」は、世界中のプロジェクトで大きな問題です。

　今回は、前回の迷路探索プログラムの一部修正版を出題します。大半は同じですが、一部修正してあるので、先入観を捨てて、新たな気持ちで取り組んでください。