新人技術者のためのロジカル・シンキング入門（9） ―― メモリ転送速度の最適化設計

【3】最適化によるバグに注意（1/2）

　何度も言うようですが，モジュールが仕様通り正しく動くということが最適化の前提です．従って，最適化の工程においては最適化作業そのものと並行して，新たなバグの発生を防ぐためのテスト・ケースを用意する必要があります．

　一般的なソフトウェア工学の概念によれば，「設計」，「コーディング」，「テスト」は別々の工程であり，一つの工程が終わってから次の工程が始まることになっています．しかし，最適化の作業においては，これらのサイクルを短い期間に何度も回す必要が生じます．つまり「コーディングを少し進めたらテストする」を繰り返すことで，品質の劣化を防ぐことになります（図6）．

図6　工程と工数分布の実際
概念的には，工程は一つ一つ実施することになっている．しかし最適化では，通常，作っては確認することを繰り返す．この場合，テストにかける工数をしかるべきタイミングで充実させ，新たなバグを生まないようにする工夫が必要となる．

● テストは時間がかかる

　ここで問題となってくるのが，テストそれ自体にかかる工数の増大です．本来，組み込みシステム開発に限らず，開発した各モジュールは十分にテストしてから結合する必要があります．しかし，テストというのは，工数不足を理由にしばしば省略されることが多い工程でもあります．これは「テスト項目そのものが用意されていない」というような極端なケースばかりとは限りません^（1）．開発の初期においてはきちんとテスト項目を用意して，テストしてからモジュールをリリースしていたような場合でも，開発の終期にさしかかるとテストを省略してしまうこともあり得ます．なぜなら，モジュールの開発終期というのは，わずかな変更（バグの修正であれ，仕様変更であれ）を加えて短期間でリリースしてほしい，と要求されるケースが多々あるからです．「修正はごくわずかだから，まさか問題は生じないだろう」と考えて未検証のモジュールを提供してしまい，後で大問題となるケースは枚挙にいとまがありません．