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

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

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

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

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

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

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

※写真はイメージです

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

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

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

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

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

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

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

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

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

処理時間のバグの例題

　　　　　　 1|2|3 次のページへ