みんなのプロジェクトマネジメント

メンバーが、リーダーが、マネージャーが、プロジェクトマネジメントを使いこなす。

バグはどこで生まれる?

自動車の組み立てを考えてみます。(厳密ではありませんが)
  (1)車両の設計
 →(2)部品の設計
 →(3)部品の作成
 →(4)車両の組み立て
 →(5)組み立てチェック
 →(6)動作テスト
 →(7)走行テスト
 →(8)納品
というフェーズがあったとき、不具合を作っているのはどのフェーズになるでしょうか?

正解は、(1)~(4)の、ものづくりを行っているフェーズです。
設計に誤りがあれば、最終的に出来上がる車に不具合が出てしまうし、
部品の寸法を間違えたり、組み立てるときに部品を付ける場所を間違えたりしても、車に不具合が出ます。
ですが、部品の寸法を測定したり、走行テストをしている段階では、不具合を作りこんではいません。不具合があるかを確認するフェーズとなります。

システム開発の話に戻ります。
基本的には自動車の組み立てと同様、「ものづくりを行っているフェーズ」にて、不具合が作りこまれます。
 ○要件定義…要件の漏れ、誤り
 ○設計…設計ミス、要件定義との相違(誤り)
 ○製造…コーディングミス、設計書との相違(誤り)
 ・テスト…設計・製造のミスを摘出
 ・ユーザ納品…要件を満たしているかを確認

バグを作りこむのは、ものづくりのフェーズだけです。
バグを発生させないようにするには、このフェーズを抑えないといけません。(予防)
ものづくり以降のフェーズは、バグがないことを検査し、是正するフェーズとなります。

また、かかるコストも「予防のコスト<検査・是正のコスト」となることが知られています。検査よりも、予防が重要であることを示しています。
適当に作った後、一生懸命にバグを探して、せっかく作ったプログラムに修正を入れる、というのは、無駄な時間をかけているとしか言いようがありません。
せっかくなら、作るときに完璧にして、無駄な修正を入れない方がいいですよね。
品質は、作るときに高めるものです。
作るときに不具合が埋め込まれることを意識し、高い品質のものを作りこみましょう。