基本的に、本に書いてあることはあまり信用しません。特に、ソフトウェアの開発手法に関することは信用しません。

マイクロソフトでうまくいった開発手法と聞けば、少し信用度は上がります。なぜなら、マイクロソフトは腐ってもマイクロソフトで、批判する人も多いですが、マイクロソフトの作るソフトウェアは相対的に良くできているからです。 IBMでうまくいった開発手法と聞くと、ほとんど信用しません。なぜなら、IBMの作るソフトウェアはほとんど腐っているからです。

ただ、信用するかどうかと、試してみるかは別の話です。そもそもほとんど最初は信用しないので、信用するものしか試さないとしたら、試すものがほぼゼロになります。

ソフトウェア(コード)インスペクションは、ものの本によれば、欠陥(バグ)の8割を検出できるとあります。8割という数字は、IBMの最初の論文の数字だけ独り歩きしている気がします。こんな数字は条件次第でいくらでも変わります。例えば、初心者がCで書いたコードなら、コードを見ただけで、かなりの数のバグを見つける自信があります。一方、上級者の書いたJavaのコードだと、コードを見ただけでバグを見つけられるか自信がありません。要は、IBMにいるぐらいヘボなプログラマがコードを書いて、IBMにいるぐらい優秀な人がレビューすれば、バグもいっぱい見つかる理屈です。

IBMの最初の論文:

• http://www.research.ibm.com/journal/sj/153/ibmsj1503C.pdf

論文からいくつか引用(日本語は井上のコメント):

A piece of the design of a large operating system component (all done in structured programming) was selected as a study sample (これだけでは何作ったかは不明)

the design was submitted for coding in PL/S (PL/SはPL/Iの派生らしい...)

Three programmers designed it, and it was coded by 13 programmers

An important aspect to consider in any production experiment involving human beings is the Hawthorne Effect. (ホーソン効果に言及しているのは、流石IBM)

an application program of eight modules was written in COBOL (システムプログラムの対比としてのアプリケーション。やはりCOBOL...)

The program size was 4,439 Non-Commentary Source Statements (約4500行。ぬるい)

The inspections were obviously very thorough when judged by the inspection error detection efficiency of 82 percent (たぶん、これが8割の根拠)

全体的に、いくらなんでも、色々と古すぎます。

参考サイト(日本語):

• http://itpro.nikkeibp.co.jp/article/COLUMN/20070910/281567/
• http://blog.goo.ne.jp/bensun2/e/cf138a47a4c9e22e41d8b040a3de5a3b

文句ばかり書いていますが、ソフトウェアインスペクションを試す予定です。面白い成果が得られれば、ここで発表します。

試行錯誤の中で良い手法を確立しようと考えています。今のところ、以下のことをやる予定です。基本的にスモールスタートです。欲張って続かないより、ささやかでも継続、が重要だと思っているからです。

• 少人数で定期的に開催
• 事前に作成者に知らせる(突然なので準備していない、という言い訳を防ぐため)
• 指摘した問題を記録にとる
• 「チェックリスト」は状況を見て徐々に作成
• 5分で解決できない問題はペンディングリストに記入