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

【4】「工程」について，その理論と実際（1/2）

　最後に，「工程」という考え方から見た最適化設計とテストについて述べておきたいことがあります．

　最適化が1度のコーディングで終了することはまれです．大抵の場合，試行錯誤を経て，徐々に処理スピードやメモリ使用量の目標値に近づけていくことになります．

　この場合，コーディング→テストという工程を杓子定規にとらえて「最適化コーディングという工程の終了判定が確実に行えない限り，次工程であるテスト工程は開始できない」などと考え，一切テストを行わずに最適化を進めたら大変なことになります．なぜなら，最適化コーディングをすべて終わらせてからテストして，もしバグが見つかったら，どの変更でミスが混入したか分からなくなってしまう恐れがあるからです．そうなると，せっかく最適化したソース・コードをまるごと捨てることにもなりかねません．最適化に限らず，ソースの変更・修正は「少しずつ確実に」が原則です．

　世にある開発標準のたぐいは，よく考えて使えば品質保証に役立つことも少なくないのですが，反面，単純に杓子定規にあてはめるとかえって混乱が増すものも数多くあります．規則を作るときは趣旨をよく考えることが大切だと，筆者は考えます^（3）．

● テスト項目の充実と高速化を両立させる

　ここまで述べてきたコーディングとテストを繰り返すような開発スタイルを図にすると，図8のようになります．「初期」，「中期」，「終期」と時間を分けてありますが，この三つを厳密に区別する必要があるわけではありません．ポイントはむしろ，「テスト項目の充実化」，「テストの自動化・高速化による工数の圧縮」という二つのアプローチをともに満たす必要があるという点にあります．テストを自動化してテスト実施にかかる時間を短縮する一方，テスト項目は必要なだけ充実させてコーディングとテストを繰り返す体制を整えることで，より確実に品質を保証できます．

図8　最適化設計に必要な工程の組み立て
初期段階では，設計とコーディングに時間がかかるのでテストは軽めとなる．しかし，ある段階でテスト項目を充実させて品質を確かなものにすることが必要．終期にはテストの自動化で工数の削減とテストの充実を両立させる．

　初めて開発する組み込みモジュールの場合，仕様がよくわかっていないため，テスト項目を考えるのに一苦労することがよくあります．これまでに存在しないアルゴリズムを開発対象としたような場合は特にそうです．その場合，最初は設計とコーディングだけで手一杯になってしまうことがあります．

　しかし，そのような場合でも，ある段階でテスト項目を充実させて品質保証を確かなものにする，というフェーズが必要です（図8の（1））．なぜなら，作りっぱなしでリリースしてしまえば，当然バグが潜んでいる恐れがあるからです．テストをろくにせずに品質の低いモジュールを提供し続けていると，「あそこのチームは工程全体をストップさせる常習犯だ」とみなされてしまうことにもつながりかねません．

　一方で，テスト項目の数が充実してくると，当然テストそのものの実施に時間がかかることになります．そのため，開発が終盤にさしかかって，わずかな修正/変更とリリースを短期間で繰り返すフェーズになると，テストがしばしば省略されがちになります．これがバグの原因となることは既に述べました．テストを省略せずにテスト工数を削減して効率化するための手段として，テストの自動化が挙げられるわけです（図8の（2））．もちろん，（1）と（2）を同時に実現できるのであれば，それに越したことはありません．テスト項目を増やすと同時に，それを自動的に実施できるようなテスト・プログラムを作っておけば手間が省けます．