バグの源流をたどれ

何だかクライブ・カッスラーの小説みたいなタイトルだけど、いつものようにソフトウェア開発におけるバグの話。

• 「設定可能な値の範囲が仕様外だったので、修正しました」
• 「仕様書の記載ミスだったので、修正しました」
• 「テストケースが不足していたので、追加しました」

社内の開発プロジェクトにて、tracのチケットにこんなコメントが付いていたので片っ端から文句を付ける。仕様書やソースコードでの対応なんてその場しのぎでの対策に過ぎず、抜本的な解決策になっていないのだ。バグを生み出すことになった、あるいは見逃すことになった根本原因を見つけ出して直す必要がある。

例えば仕様書の記載ミスなら、こんなことを考える必要がある。

1. 仕様書作成者のスキルが不充分
   • 仕様書の書き方について教育訓練の実施
   • 作業担当者の変更
2. 仕様書レビューでの指摘が不充分
   • 問題箇所を見つけられないレビュー担当者のスキル不足
     • レビューでの指摘能力について教育訓練の実施
     • レビュー担当者の変更、追加
   • チェックリストの項目が不充分
     • チェックリストが不足している理由の調査
     • 関連対策項目の調査
   • レビューの実施方法が不適切
     • レビュー手順の再確認
     • レビュー手順の見直し、改善
3. 仕様書承認プロセスでの指摘が不充分
   • 同上
4. 仕様書レビューが未実施
   • 作業手順を逸脱した理由の調査
   • 作業を管理できていないリーダーへの事情聴取

昨日と同じやり方を続ける限り、昨日と同じ数だけの障害が発生するのは当然のこと。障害件数を減らそうと思ったら、作業の進め方を見直す必要があるのだ。