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

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

● 手続き的な要請との調和

　以上のような開発を進める場合でも，職場の開発方針からくる手続き的な要請から，どうしてもエビデンス（監査証跡）を残さなければならない場合もあるでしょう．「手続き的な要請」というのは，ISO 9000の認証を受けた事業所などで，「工程終了判定」の類を設けなければならない場合を指します．その場合はどうしたらよいでしょうか？

　手続き的な要請と開発現場の方針を調和させる方法として，以下のような方法が採り得ると思います．

　まず，コーディング→テスト→コーディング→テストと試行錯誤を繰り返す開発上の要請があれば，まずそれを前提として，エビデンスの揃え方を考えるべきでしょう（図9）．試行錯誤を繰り返す開発の場合でも，製品をリリースする前に最終的なエビデンスは用意できるはずです．例えば，リリース前の適切な段階で最適化したソース・コードのレビューを行い，テスト結果をドキュメント化して両者を記録に残すことは可能なはずですし，それはむしろ必要だと思います．

図9　最適化設計とそのエビデンス
試行錯誤を繰り返すのが前提の開発でも，リリース前には一定の記録を用意することが可能なはずだし，その必要性はむしろ大きい．製品を出す前にチーム単位でレビューする機会をなくしてしまうと，品質が保ちにくい上，開発テクニックの共有化が図れなくなってしまう．

　レビューの主な目的が「誤りの発見」であることは言うまでもありません．最適化というのは，とかく個人の力量に頼るところが大きくなります．製品をリリースする前に一度もチーム単位でのレビューが行われないとしたら，満足のゆく品質保証はできません．なぜなら，最適化した個人がミスを犯したら，そのまま開発チームの外にバグのある製品が出て行く体制を作りかねないからです．

　また，レビューはしばしば「新人の教育」という目的も兼ねることがあります．製品開発に必要なテクニックが文字になって書店などに並んでいるというのは，実は極めてまれです．大抵の開発テクニックというのは開発現場で培われているものであり，個人に属するところが大きいものです．これらは結局「見て覚える」，「盗んで覚える」という学習方法をとることが必然的に多くなります．開発経験の浅い人にとっては，他の経験豊かなエンジニアの仕事の結果を見ることで得るところが少なくありません．レビューを全く行わないというのであれば，この貴重な教育の機会を失ってしまうことにもなりかねません．

参考・引用＊文献
（1）冴木 元；「ひたすら流すだけ」にさようなら，Design Wave Magazine，2007年1月号，pp.119-124，CQ出版社．
（2）冴木 元；いかにしてバグの原因を突き止めるか，Design Wave Magazine，2006年6月号，pp.50-57，CQ出版社．
（3）冴木 元；リリースしたらテーブルが消えた？，Design Wave Magazine，2006年10月号，pp.132-138，CQ出版社．

さえき はじめ
＜筆者プロフィール＞
冴木 元．システム・エンジニア．連載をしばらく続けていると，ネタが少なくなるころに読みたい本がいくつか出てくるものだ（いずれもソフトウェアとは無関係なものなのだが）．本屋をうろついていると，いくつかの本が手招きしているような気がする．長めの休暇が得られたら，久々に読書に充ててみようかと思う．