ピアレビュー

softwareengineering

研究のために必要だったので読んでみたのですがなかなか面白かったです。peer reviewだから、読んで字のごとく同等の人同士で行うレビューですね。そういえば、学術論文の査読とかもピアレビューって言いますね。。。。

ただ、欲を言えば全体的にちょっとボリューム不足な感じ。おそらくレビューについてのベストプラクティスについてのまとめを書いたつもりなんでしょうけど、それを導き出すために利用した事例の説明とか、ワークシートの解説なんかが少なすぎて、哲学というか一般論の羅列のようになってしまっているような感じがしました。おそらく、普通の大学生レベルが読んだとしたらそのほとんどがレビューの重要性とか、具体的な進め方なんかに想像力をめぐらすには厳しいと思います。

† 個人的な備忘録というか戯言

現実的に考えてソフトウェアの欠陥検出をするための技術としては「テストをする」というのが真っ先に浮かぶわけですが、それと双璧をなす手法が「レビューをする」ことだと思います。それ以外にソフトウェアの信頼性を確保する手段ってあるんでしょうか。とりあえず現実的でない欠陥検出方法としては「正しさを証明する」^*1っていうのはありますね。

† 確かにテストはすばらしいけれど

このうち「テストをする」というのは、手法をきちんと吟味すれば定量的に管理ができる場合も多くあり、行為に対する成果もわかりやすいので、学術でも関連する研究が多くあり、欠陥検出の主流になっています。ただ、ソフトウェア開発プロセスの全体を考慮すればきわめて限定された部分にだけしか適用することはできない^*2技術であり、主にプロセスの後半にならないと使えない手法であるというのはかなり痛いところです。

† 先手を打つ必要性

それなりのプロジェクトになれば、早期から欠陥を検出して将来起こりえる欠陥を未然に回避するというのは成功へのキーポイントになってきます。ソフトウェア開発プロセスのあらゆる局面^*3で行うことができるレビューは、テストと比べて有望な欠陥検出技術であると考えることができるのではないかと思います。

† プロセスとしての欠陥検出技術

過去の遺物なんていわれているウォーターフォールモデルなんかが失敗したのはウォーターフォールモデル自体がダメだったんではなくて、この欠点をもろにかぶってしまうプロセスになってしまっていて、それをみんな上手に克服できなかったからだと思います。逆に、品質保証をテストに過度に依存しないでソフトウェアが開発可能な組織であればウォーターフォールモデルでもソフトウェア開発は上手くいくはずなんでしょうけど・・・・・現実はそうではなかったということですね。結局、現在の開発プロセスの主流はアジャイル系やＲＵＰに見られるようなプロセスのサイクルを小さくして、それを反復することにより、テストの回数が結果的に多くなるようになっていますし。

† 俗人的な要素の問題

でも、レビューの大きな問題はどうやったら欠陥を発見できるかという部分において、俗人的な要素に満ちており定量化がしにくいこと。だから研究としてはやりにくい。個人的にはそのあたりに上手くメスを入れて、研究としてまとめてみたいという希望はあるんだけど・・・・・突き詰めていくと、クライテリア作りとか、ワークシートの工夫とか、論理的思考法ということになるんでしょうか。

安直な発想しか浮かばないのでもう少しアイディアを練らなければ。