チェックリスト記述ミス

ソフトウェア開発においては、いわゆる「本番」で不良、欠陥がわんさか出ます。通常の製造業でも、試作開発をしている頃はそうだと思います。通常の製造業と異なるのは、「量産」と言うプロセスがないために、

　常に一発勝負で完璧な品質を求められている

という点にあるのではないでしょうか。試作開発で試行錯誤する期間を持たず、新製品に対していきなり「量産開発しろ」、と言われているようなもんだと思えば、ＩＴ業界に詳しくない方でも少しは大変さがわかるかも知れません。

ですが、だからと言っていつもいつも手探りで開発するわけにはいきません。全く同じ製品でなくても似たような製品は作ることがありますし、似たような手法を再利用することも当然あります。

ですから、不良や欠陥が起きた際に現場のエンジニアまかせにして、毎度毎度１から「あーでもない、こーでもない」と対応策を模索するのではなく、ある程度フレームワーク化することは可能です。

むしろ、そうしないと無駄な工数を使い、限られたスケジュールを浪費し、余計なコストがかかる実状を変えることはできません。

今後、「ある不良」の分類に対して、そう断定する条件であったり、どう対応（是正）するのかだったり、あるいは他にも同じような不良があるのかどうか見直す必要があるのか否かだったりを簡単に、少しずつ小出しにして整理していきたいと思います。

で。

今回のテーマは「チェックリストの記述ミス」です。
なぜいきなりチェックリストの話なのか？
それは、たまたま頭の中に思い浮かんだからです_(:3｣∠)_=3

条件/原因

まず、問題を「問題だ」と認識した時からその原因を特定するため、いろいろ調査をすることになると思いますが、「チェックリストの記述ミス」は次の条件をすべて満たしたときにそう断定します。

　・設計書に誤りがない
　・設計記述の内容とプログラム記述の内容に差異がない
　・チェックリストの内容が設計記述の内容と一致しない

割と当たり前のことを書いているように見えますが、ほとんどのプロジェクトでは担当者やプロジェクトマネージャーの感覚や勘で判断していることでしょう。このように論理的に言語化して判断しているプロジェクトやエンジニア、マネージャーというのは意外と少ないんです。

注意点は、プログラム記述の内容とチェックリストの内容を比べないことです。

テスト工程の目的は「設計どおりに、製品を作っているか？」を確認するための答え合わせフェーズです。プログラムを元にしてチェックリストを作ったら、プログラム＝チェックリストになるわけですから、仮に設計と合っていないバグが混入していたとしても検知することができません。

まぁ、だからこそ

　「設計者と製造者は同一人物にしない」
　「『ソースが正』などという非論理的な言い分を認めない」

方がいいのですが…日本の場合は、有識者が作れば生産性が下がらないからという性善説に則った理由だけでそのまま継続させるところが多いため、品質が低くなりがちです。建築士に大工までさせている、あるいは大工に製図させているような状況ですね。

対策

対策するのは、次の通りです。