バグ分析

　開発が完了すると総括して資料化する。私はバグ分析を担当した。統計の知識が役に立つと思った。
　設計から試験までのバグ票をメーカにすべて点検してもらい、単純ミス、設計ミスなど分類してもらう。それをリーダがすべて点検した。数千個のバグをコードにしてカードにパンチし、ＰＬＩでプログラムを書いて集計した。エクセルなどまだない時代である。だが結論から言うと、何も見いだせず、資料化はできなかった。見いだせたのは、分かりきったことだけだった。たとえば、流用度が高いモジュールはバグが少ない。
　交換プログラムはＣＨＩＬＬというＰＬＩに似た言語で書かれ、機能毎にモジュール化されていた。メーカにはモジュール単位で発注していたから、生産性や品質もモジュール単位で議論するものと思い込んでいた。このモジュールは、あのメーカのあいつが担当していた、と顔が見えてくる。コンパイルエラーに苦労していたな、とか、いつもパッチを作っていたっけ。それ以上になにか結論付けることは難しかった。統計の無力を感じた。
　のちに、ＮＴＴコムウェアで、このプログラムを内製することになる。品質をモジュール毎に評価したがる品質保証部とは何度もケンカした。
　モジュール間が密に結合している場合、ある処理をどちらでやるか、設計時には詳細までイメージできてなくて、コーディングや試験になってバグになるケースがあった。しかし、二つのモジュールが一つで、モジュール内で気づいて直せば、軽いバグだ。分割し、しかも別のメーカに担当させていたら、重大バグと分類された。
　モジュール内かモジュール間か、バグの重要度とは本来無関係だ。どこでミスしても結果は同じだ。当時、モジュール間を重視したのは、メーカ間で意識がずれていないか気にしてだろう。モジュールをもっと大きくして、より包括的に担当できれば、意識ずれは起こりにくい。また、モジュールを無視して包括的に設計すればよい。
　どこまでをバグとするか、論じられない。「修正したらバグ？」ではない。わざわざバグ票を切って周知するのは、なぜか。一定の完成物に対して修正するとき、なぜ修正しなければならないか、をバグ票で説明する。いったん作ってしまったが、すみません。ここをこう変えたい。よろしく。そう仁義を切るのは、モジュールをまたぎ、メーカをまたぐからだ。
　では、モジュール内に閉じたバグは無視してよいのか？　そのバグをつくった担当者は、他でも同様のバグをつくっているかもしれない。たとえば、パラメータの順番を勘違いしていたら、その観点で、その担当者の他のコーディングも点検すべきだ。観点を絞るとウォークスルーはより効果的になる。実際、ベテランはそのように部下のプログラムを見ている。
　教科書には「バグは早期にとるべし」とある。本来は設計段階に見つけておくべきだったと、卑下するバグ票は多いが、本当だろうか。バグはリリースまでにとればよいのだ。設計時には気がつけなかったが、試験で見つけたのなら、よかったではないか。もし、それを設計時にとろうとすれば、レビューに膨大な時間とコストを使うことになる。レビューでバグを見つけることができる技術者は高級である。そういう高給技術者をレビューに浪費するのは効率的だろうか。
　古い教科書に、なぜそう書かれたのか。それは、コーディングや試験の工程が大変だったからだ。コンパイルだけでも計算センタに費用を払う必要があった。深夜になり、センタの運用時間を延長すると追加料金がかかった。試験もマシンコストが高かった。
　ところが、安いワークステーションやパソコンで、それらができるようになった。それなら、レビューなどに時間を使ってないで、とっととコーディングし、コンパイルし、試験してみればよいではないか。
　モジュールのバグを追うのではなく、開発者のスキルを追うべきだ。設計工程ではバグが少なく、試験になって次第に出てきたら、従来は設計が不十分と評価したが、本当は担当者のスキルがアップしてきたからかもしれない。
　教科書には「バグが多く見つかったプログラムは品質が良い」とある。それは、スキルが均一の場合だ。実際にはベテランのほうがバグは少ない。しかし、バグ密度が低いと品質が悪いと判断されるなら、ベテランはバグを用意してしまう。「あと二個でパス」などと言っている。
　ＮＴＴコムウェアで千人の開発者を詳細設計からコーディングのチームと試験のチームに振り分けるとき、ベテランを試験チームに振る決断をした。人数も四対六で試験を厚くした。大丈夫か、と心配してもらったが、それがねらいだった。新人のコーディングは信用できないから、ベテランは必死でレビューする、試験する。カナダの交換機メーカでも、技術者が最後に登り詰めるのが試験だと聞いて留飲が下がった。
　モジュール化したことで、モジュール毎に外注することになったが、ここにも問題があった。本当にモジュールが独立した機能ならばよいが、交換プログラムのモジュールは相互にかなり密に結合している。分割し、別メーカに分担させることは、非効率だった。モジュールを越え、メーカをまたいでレビューが必要となる。開発会議はメーカ間のレビューの場だったのだ。
　ＮＴＴコムウェアでは、モジュール単位ではなく、機能追加単位で詳細設計までやることとした。今流にいえば「ユースケース単位」の設計である。
　プログラムは複数のモジュールを「串刺し」にして動作する。それをそのまま「串刺し」に設計するのである。できた詳細設計書はネットニュースに投稿し、各モジュール担当がそれを見てコーディングする。試験チームもニュースを見て試験項目を検討する。
　モジュール化以前は、どのように開発していたのか、あるバグを例にメーカにヒアリングしたことがあった。解析を請け負ったメーカが書いたバグ票を見せてもらったら、プログラムがどう動き、どこが問題で、どこを直すべきと、ちゃんと「串刺し」で書いてあった。
　統計学がイギリスで発展したのは、植民地のインドからの情報が信用できなかったからだと習った。どうせあいつら手を抜いている、インチキしている。それで、分散を使って検定する統計手法が生まれたのだそうだ。しかし、内製するなら、社員を信用すればいい。プロジェクトのメンバは千人にすぎない。マスの統計ではなく、個々人のレビュー時間やバグ数の実績を集計すればよいのだ。野球やサッカーでポジション毎に評価したりしない。当然選手毎である。