2011-10-11
チェックリスト信仰
ソフトウェア品質 | |
開発現場で問題の再発防止策を検討すると、その結論として出てくるものの一つにチェックリストが有る。曰く、このチェックリストに従って確認を行えば、同じような問題の発生を防ぐことができるし、誰でも同じレベルで作業を行うことが出来る。チェックリストは素晴らしい、是非ともチェックリストを作るべきだ、チェックリストに従わないのはけしからん等々。
確かにその指摘は正しくで、実施すべき有力な対策の一つではある。優秀な開発者が自分の作業を終えて、万が一のミスが無いか確認する程度の使い方なら充分に有効だと思う。しかし、チェックリストの有効性を信じて疑わない人の姿を見ると、ちょっと待って欲しいと言いたくなってしまう。現場の人なら既に知っているように、チェックリストは同時に問題も多い存在だ。例えば、開発現場でこんな状態を見かけることは少なくないだろう。
- 確認作業の形骸化
「チェックリストで確認する目的は？」と聞かれた担当者が「規則で決まっているからです」と答えたら、それは立派に形骸化している証拠だと思う。担当者は本当にチェックリストの意義を理解しているのだろうか？ - リストの項目さえ確認すれば良いという思考停止
リストを作った人が「この程度はやっておくべき」という認識で作ったものの、それで充分だという保証は何処にも無い。リストの項目を確認しつつ、不足している項目は無いのか、修正が必要なものは無いのか常に考える必要があるはずだ。 - 環境の変化に追従できない内容
チェックリストが作られた時から開発環境もシステムバージョンも変わっているのに内容が更新されず、「古い項目があるので気をつけて」等という文句と共に引き継がれていることがある。こんなチェックリストを使い続けて良いのか疑問に思わない時点で、既に問題ありと思う。 - 確認漏れやミスの発生
幾ら詳細なリストが存在しても、それに従うのは生身の人間なのだ。だからリストで確認さえすれば100%OKと信じるのは危険だし、少し位の問題が残っている可能性が有るとリスクを見込むことが必要かも知れない。
チェックリストの記載内容は生き物だと思う。絶えずメンテナンスを続ける必要があるし、その存在意義や歴史的背景を充分に理解した上で使いこなす必要があるはずだ。だから、チームのメンバには「チェックリストを疑え」と言うことがある。自らの経験を元に、チェックリスト自身の問題箇所を指摘できるようになって初めて、作業担当者のスキルは一人前になるのではないかとも思っている。
トラックバック - http://d.hatena.ne.jp/rabbit2go/20111011/1318337732
チェックリストは、テストの原則に似た感じを受けます。チェックリストは、チェックしなかったことの確認にはなるが、チェックして正しかったことの保証にはならない。チェックを行っていない場合にはそれに気付くことができるが、チェックしたからといって正しいとは言い切れない。そんな感じです。
本来、チェックリストに1項目を追加することは非常に重いと思います。なぜなら、欠陥の根本原因分析を行って、その恒久対策の1手段としてチェックリストに1項目を追加しているはずだからです。コードを書く人は、仕様と実装技術を知っていればいいといえますが、根本原因分析を行う人は、ドメインの知識、開発プロセスや管理プロセスの知識、アーキテクチャと実装技術、個人スキルやチーム力学を把握していないといけないでしょう。また、パターン化が必要です。チェックリストはある程度、抽象度を高めないと適合しにくくなりますし、抽象化／汎化が過ぎると、チェックする人が実際の詳細設計やコードに具現化することが容易でなくなります。チェックリストに1項目を追加できるスキルは、非常に高度なスキルと言えます。
安易にチェックリストに1項目を追加してはいけないのだと思います。再発防止の結論をチェックリストへの1項目の追加で終わらせてはいけないのだと思います。チェックリストを廃止できなければ、真の根本原因分析が行えていない、正しい解決策になっていない、まだ根本原因は残ったままになっている、そんな気がしてなりません。
コメントを有りがとうございます。確かにリストの項目は増えていく一方で減ることは無いですね。
tacohachiさん
いつもコメントを有りがとうございます。確かに正しい解決策にはなっていないと感じます。でも開発現場は高度なスキルを持つ人ばかりではないですし、今日の不具合を明日繰り返さないための短期的な対処策としては、ある程度仕方の無い面もあるかと思います。