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

7．対策

　処理時間のバグへの対策を以下に示します。

7.1 仕様書の規定値を現実的な値に設定する

　要求仕様で処理時間を記載する場合、無理のない現実的な値を定義しましょう。この値によっては、プロジェクトの進行が大きな影響を受ける可能性があります。また、応答性能を実現できなかった場合、どのように対処するか、事前に考えておきましょう。

7.2 プロトタイプを作る

　応答性能がクリティカルなソフトウェアでは、要求仕様定義の段階で、コアになる部分を2、3日でコーディングして実行し、目標とする応答性能が可能であることを事前に確認しましょう。「この応答性能を出すには、東京−大阪間の通信を120nsで終了しなければならない」といったような「物理的に不可能な桁違いの処理要求」を検出できます。

7.3 ボトルネックの把握

　パフォーマンス解析ツールを使用し、ボトルネック（プログラムのどこに時間を取られているか）のランキングを作成しておきましょう。あらかじめ調べておけば、応答性能系のバグ発生時に慌てることなく対処できます。

7.4 プログラムの記述方法に注意する

　処理時間が重要なプログラムの場合、以下の記述方法に気を付けましょう。

• より高速なプログラミング言語（アセンブラ、C/C++言語など）を採用することを検討する
• 部分的にアセンブラで記述する
• 除算は処理時間がかかるため、乗算に変更する
• べき乗をシフト演算に変更する
• 速度が速い標準関数を使用する
• より高速なアルゴリズムを探す
• 無駄なデータにアクセスしていないか確認する

　上記は、昔ながらの処理高速化の手法ですが、少しでも改善したい場合は効果があります。また、シニアエンジニアに聞くと、マニアックな改善手法を提案してもらえるかもしれません。

8．まとめ

　今回のまとめを以下に示します。

• 処理時間のバグとは、想定した処理時間をオーバーするバグのことである
• 処理時間は、プログラムの完成後に測定するため、開発の終盤で見つかり、プロジェクトの進行に大きな影響を与える
• 処理時間のバグは、プログラムを動作して確認したり、負荷などでプログラムが停止したりする場合に発生する
• 対策案は、「仕様定義での応答性能を現実的な値にする」「ツールでボトルネックを把握しておく」「より効率的なプログラムを記述し、処理時間を短くする」などがある

9．終わりに

　ハードウェアの能力は昔と比べて格段に向上しましたが、性能要求を満たせず慌てることが少なくありません。今回は、その中でも、処理時間のバグを紹介しました。

　処理時間のバグが発生すると、どうやって目標の応答時間内に収めるか、対処法をキチンと考えねばなりません。また、実機でやってみないと確かめられませんので、未然防止が非常に難しいバグです。処理時間が求められる製品を開発しているエンジニアは、常に頭に置いておくべきバグです。

　今回でシリーズの12回目となり、いろいろなバグの知識や、バグを見つける嗅覚が身に付いたことと思います。他のバグを知りたい方は、本連載の過去記事や、前シリーズの「バグ検出ドリル」、以下に紹介する書籍版の「ソフトウェア技術者のためのバグ検出ドリル」をご参照ください。