ソフトウェア技術者のためのバグ百科事典（12）デスマーチを呼ぶ処理時間のバグ：山浦恒央の“くみこみ”な話（133）（1/3 ページ）

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第12回は、開発のデスマーチを呼び起こしかねない、処理時間のバグを取り上げます。

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

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

1．はじめに

　バグ百科事典は、筆者が気になったバグを紹介し、読者の皆さまに「バグの早期発見」と「バグの未然防止」に役立てていただくものです。今回でシリーズ12回目となり、バグの知識や、バグを検出する嗅覚が身に付いてきたことと思います。本コラムによって、より良いソフトウェア開発につなげていただければと思います。

　今回は、処理時間や応答性能に関するバグを取り上げます。難度の高いバグですので、苦労されている方も多いでしょう。

⇒連載「山浦恒央の“くみこみ”な話」バックナンバー

2．処理時間のバグとは

　ITの発達でハードウェアの性能が飛躍的に向上しました。例えば、最近のPCは、起動ボタンを押して1分もしないうちに使用でき、待ち時間を感じません。高度情報化社会になっても、少しでも早く実行できる機器を目指して、世界中の企業が競い合っています。

　ハードウェアの性能が向上しても、ソフトウェア開発の終盤で発生するクリティカルなバグは存在します。その一つが、「性能を満足できない」です。例えば、新しい携帯電話のソフトウェアを開発していて、「電源ONからユーザーが自由に動かせるまでの時間が3分以内であること」との仕様があるとします。その場合、規定値の3分をオーバーすると、仕様が満たせず、大きな問題となることも少なくありません。

　性能要求系のバグは、開発フェーズの終盤で発覚し、プロジェクトは大混乱します。高性能、大容量のハードウェアに置き換えたり、性能解析ツールでボトルネックを探して処理を分散させたりして、大半は力技で何とかしますが、場合によっては、妥協してリリースすることも少なくありません。

　性能にはいろいろな種類がありますが^※1）、その中でも、規定の処理時間が未達のケースは取り扱いが難しいようです。本コラムでは、「規定の処理時間が未達」を「処理時間のバグ」と定義し、詳しく紹介します。

※1）「性能」には、ユーザーインタフェース系や信頼性など、いろいろな要素を含みます。今回は、特に、処理時間や応答性能に関するバグを取り上げます。

3．処理時間のバグの特徴

　処理時間のバグの特徴を以下に示します。

3.1 やってみないと分からない

※写真はイメージです

　処理時間のバグが発生する理由の一つが、実際に動作するハードウェアとソフトウェアがないと処理時間を計測できない点です。できていないのですから、当たり前ですね。その結果、仕様定義する段階では、動作してほしい速度を性能要求として記載します。

　設計やコーディングのフェーズに入ると、詳細が明らかになりますので、処理性能が少しずつ分かってきます。テスト工程となると、最後は神頼み状態で、「お願いだから規定の処理時間内で動作して……」と祈る気持ちでテストに臨むことでしょう。

3.2 ハードウェアを変更できないことも少なくない

　処理時間が未達ならば、「高性能、大容量のハードウェアと交換すればいい」と思いますが、「開発の終盤となり、ハードウェアに関して顧客と合意してしまった」「今さら変更できない」などが原因で、変更できないことが少なくありません^※2）。

※2）筆者の経験上、「ハードウェア変更できないので、ソフトウェア側でどうにかしてください」と軽く言われるケースが多いようです。ソフトウェア側で処理性能を大幅に上げるには、アルゴリズムを根本的に変更せねばならず、システムがほとんど出来上がっているデバッグやテストの段階で処理方式を変えるのは自殺行為です。

　これは、完成間近の地下1階／地上4階建てのマンションを、地下2階／地上6階に変更するようなものです。そんな開発プロジェクトは、高い確率でデスマーチ化します。ハードウェアのアップグレードにかかる費用より、ソフトウェアの改造に必要なコストの方が圧倒的に大きくなり、同時に、品質が下がります。どうしてもハードウェアを変更できない場合、ソフトウェアの改造に必要な期間と工数をキチンと見積もりましょう。

3.3 プログラマーの真の腕が問われる

　処理時間のバグが発生すると、プログラマーは、あらゆる箇所を確認し、1msでも早くプログラムを動作するよう必死で対処します。例えば、「参照するデータを減らす」「入出力バッファーの初期設定を別のモジュールで実施する」「プログラムの記述方法を変更する」「高速なアルゴリズムを採用する」などでしょう。「ちりも積もれば山となる」方式により、小さな改善を繰り返し、処理時間を短くしようとします。

　注意すべきは、広範囲で小さい変更をするため、バグを作り込む可能性が増えることです。経験的に、プログラムを変更すると1箇所につき20％の確率で新しいバグを作り込みます。一まとまりの変更が終了するたびに回帰テストを実施して、正常に動作している既存の機能に悪影響がないか確認しましょう。