最近、某氏に「ピープルウェア」を薦めたので、自分でも再読してみました。

再読して、この本で最も大事だと思ったのは、「幸運の遺伝子を持った女性を(ソフトウェア)開発チームに含めよ」です。

そんなこと書いてあったか?と疑う人は、心を無にしてもう一度読み直してみてください。

原典は知りませんが次の警句(?)を聞いたことがあります。

持つ者は失うことを恐れ、持たざる者はこのまま持たないままでいることを恐れる

持つ対象は、資産であったり、地位や名声であったり、幸福であったりします。これを聞いた時、なるほど、人間の不安の尽きることが無いことを良くとらえていると感心しました。

ソフトウェアの開発で、テストフェーズに入るとぼろぼろとバグが見つかることがあります。こういう場合、修正の簡単なバグが多数を占めます(なぜなら、複雑なバグはそう簡単に見つけられないので)。検証まで含めて数分で修正、なんてこともざらです。一日、10や20のペースでバグを修正することすらできます。どんどんバグが報告されて、どんどん修正していると、一見、開発チームに活気があります。テストする側も、程度の差はあれ、それなりに仕事をしている感覚が得られます。少なくとも、一日テストして、一件もバグ報告をできないよりは、遥かに充実感が得られます。バグを修正する側も、これも程度問題ですが、猛烈な勢いでバグを処理していくと、自分のスピード感に酔ってきます。少なくとも、何日もひとつのバグを調べて全く手掛かりがつかめずにいるより、充実した時間を過ごせます。

冷静に考えれば、コードを見てすぐに原因が分かるようなバグを大量に残している時点で何かが間違っています。それを猛烈な勢いで修正したからと言って、さして誉められた話ではありません。

野球で言えば乱打戦です。乱打戦の多いチームは、(一般的には)強いチームではありません。

リリースとともに熱狂が終わって冷静になると、これではいけない、という話になります。ソフトウェアの品質を上げて、テストフェーズにつまらないバグを残さないようにしよう、と言う話になります。これに反論する開発者は、(普通は)いません。野球で言えば、投手を中心にした守りの野球とでも言うスタイルです。

コードの品質が上がって、つまらないバグが無くなると、テストフェーズが穏やかになります。バグの報告数が少ないと、まるで全体的に仕事をしていないかのようになります(*)。簡単に言うと活気が無くなります。ソフトウェアの開発プロセスとして正しい進化のはずですが、不安が頭をよぎります。チームが強くなった引き換えに、リリースに伴う祝祭的気分を失うのです。

と言うわけで、たまには乱打戦も必要のようです。と、「ピープルウェア」にも書いてあります。ぼくの理想は4番が打って、エースがゼロに抑える某球団みたいな野球ですが。

(*)バグの報告数の少なさが即、品質の高さを示すかと言うと、その辺は疑っています。この話は、「バグがでないのは良い知らせなのか」(http://dev.ariel-networks.com/Members/inoue/bug-and-test)に書きました。