ソフトウェア技術者のためのバグ百科事典（15）最大の試練、仕様変更で起きるバグ：山浦恒央の“くみこみ”な話（136）（2/2 ページ）

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

※本記事はアフィリエイトプログラムによる収益を得ています

4．仕様変更に関連したバグ

　仕様変更に関連したバグは、「オーバーフロー」「ゼロ除算」のように、表面にはっきり見える外部事象ではなく、もっと根が深くて複雑です。仕様変更が原因となってバグを作り込むことも踏まえ、以下に、仕様変更が原因となるバグを示します。

4.1 仕様変更に気付かなかった

　残念ながら、「仕様変更に気付かない」「聞いていない」ことが少なくありません。仕様は日々、変わると考えてください。知らないうちに、いつの間にか変わっているかもしれません。その場合、自信満々で作成したプログラムがテスト工程でうまく動作せず、確認すると仕様変更が原因だったことに気付きます。

4.2 仕様変更があったことを忘れていた

　仕様変更があると認識していても、さまざまな業務の中で後回しにすることがあります。その場合、変更内容を忘れてしまい、テスト工程でバグが発生します。

4.3 仕様変更で機能退行

　コーディングフェーズでどうしても仕様変更しなければならない場合、仕様を変更せざるを得ません。ただし、それで解決できる保証はありません。場合によっては、現状より悪くなり、機能退行となる可能性があります。例えば、「通信方式を直前で変更したところ、応答性能を改善できないどころか、これまで正常に動作していた機能も正しく動かなくなった」が該当します。

5．筆者がやってしまったバグ

5.1 自信満々のプログラムが……

　自信満々で作成したプログラムがありました。他のエンジニアのプログラムと結合してテストしたところ、テスト結果がNGばかりとなります。確認すると、筆者の持っていたドキュメントが古く、最新版ではありませんでした。同僚に聞くと、「ここは最近変わったんですよ……」と言われました。「聞いてないよ。いつの間に変わったんだよ……」と大きく落胆したことを覚えています。

5.2 仕様の再検討ミス

　テスト工程で、成果物が意図した通りに動作しませんでした。いろいろ考えた結果、本来の仕様を変更して対処しました。

　仕様を変更し、コードを修正して、再確認したところ、変更した仕様でも思った通りに動作せず、結局、仕様を根本から検討し修正しました。場当たり的な仕様変更は良くないと痛感しました。

5.3 終わりのない画面修正

　画面構成などの見栄えに関係するものは、顧客の好みが顕著に現れます。正解が存在しないため、何度も修正が発生します。時には、顧客が2つの画面のどちらにするかで迷い、「単振動」する場合もあります。

　筆者がかつてホームページを制作していたとき、顧客から、「“かわいい”ページを作ってほしい」と要望がありました。“かわいい”って何だろうと思いながらも、画面構成の仕様を作成し、OKをもらいました。ところが、実際に画面を作成すると、変更要求が多発し、当初の画面構成から大幅な変更となってしまいました。芸術的な要素が絡むと、正解は存在しないと痛感しました。

6．バグの傾向

　仕様変更のバグは、全フェーズで発生し得るバグです。

　実際にバグを追う場合、プログラムの出力結果や実行結果で判断するため、仕様変更が原因とはすぐに分からない場合が少なくありません。実行結果を見て、現象が絞れてきた場合は、「仕様変更があった場所かどうか」も頭の片隅に置きましょう。

　また、テスト工程に入り、波及する場所も考えずに場当たり的な仕様変更をした場合は、要注意です。特に、ある程度デバッグをしておかないと、不正な事象を改善できないことがあります。また、変更箇所が悪い形で他へ波及していないか確認しましょう。

7．対策

　仕様変更に関する根本的な解決策は存在しませんが、以下に注意しましょう。

7.1 変更に強い開発プロセスを考えておく

　ソフトウェア開発には、作らないと判断できないことが多くあります。特に、性能要求に多く、「制御方式」や「通信速度」が該当します。そんな機能は、早めに作れば（あるいは、プロトタイプを数日で作って正しいことを確認すれば）、土壇場の仕様変更を防げます。

7.2 運用でカバーできないか

　仕様を変更しなくても運用方法でカバーできないか検討しましょう。仕様を変えることは、開発フェーズによっては、非常に大きな影響が出て、納期、コスト、品質に多大なインパクトを与えます。プログラムはそのままで、使い方を変えるだけで済めば、コスト増、納期遅延、品質低下を招くことなく問題に対処できます。仕様を変更することなく、発注側と開発側のどちらもハッピーになる運用方法を探しましょう。

7.3 回帰テストは忘れずに

　コーディング済みのソフトウェアで仕様変更が起きると、さまざまな波及効果が発生します。全機能の正常機能をチェックする回帰テストをしっかり実施しましょう。

8．終わりに

　仕様変更がプロジェクトに与えるインパクトは甚大です。仕様変更が難しいのは、いつ発生するか分からないことです。場合によっては、テスト工程の中盤で発生するかもしれません（これは、致命的ですね）。

　ただし、仕様変更はより良い製品を作るためには必要なことでもあるので、なくなることはありません。仕様変更が必ず発生することを前提に、バグを作らずに仕様を変更する方法を考えましょう。

山浦先生執筆の書籍「ソフトウェア技術者のためのバグ検出ドリル」が発売中！

　山浦恒央先生が執筆した書籍「ソフトウェア技術者のためのバグ検出ドリル」が日科技連出版から発売中です。本連載「山浦恒央の“くみこみ”な話」とTechFactoryの連載「組み込みエンジニアの現場力養成演習ドリル」をベースに、大幅加筆、改訂した内容になっています。

　内容は、「デバッグの詰将棋」で、要求仕様定義、設計、コーディング、テスト、保守の5フェーズでの「バグを埋め込んだ仕様記述やソースコード」を読んで、バグをピンポイントで見つける問題集になっています。全部で31問あり、難易度は初級から上級まで、いろいろです。興味のある方は、Amazon.comや書店でチェックしてください！

【 筆者紹介 】

山浦 恒央（やまうら つねお）

東海大学 大学院 組込み技術研究科 非常勤講師（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科准教授、2016年より非常勤講師。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。