チェックリストの力

Atul Gawande氏はNew Yorkerの最近の記事(source)で、明らかにローテクな手段であるチェックリストを用いて、どのようにしてPeter Pronovost博士が世界中の病院のICU（集中治療室）における感染症の発生率を低下させたかについて述べている。Pronovost博士は最も感染症を引き起こしそうな手順を特定し、その手順ごとに簡単なチェックリストを作成した。そしてそのチェックリストを守ったところ、それらの手順による感染症の発生が急激に減少した。

彼は全てのことをカバーするチェックリストを作ろうとはしなかった。彼はたった一つの問題に取り組むことを目的としたのだ。...Pronovost博士は、ICUで働く看護師達に、医師達が患者のラインを入れるのを一ヶ月間観察し、どのくらいの頻度で各手順が完璧に行われているかを記録するように依頼した。３分の１以上の患者において、少なくとも１つ以上の手順が省略されていた。

翌月、彼とそのチームは、医師達がチェックリストにある手順を飛ばそうとしているのを見かけたら、それを止める権利を看護師達に与えるように病院の経営陣を説得した。看護師達はまた、外すべきラインが無いかどうかを毎日尋ねることにもなっていたが、それは必要以上にラインを残さないためである。これは画期的なことであった...もし医師達がチェックリストの全ての手順を踏まない場合、看護師たちは経営陣に間に入ってもらえるのである。

Pronovost 博士と同僚はその後１年間に起こったことをモニタした。結果は非常に劇的で、彼らは信じていいのかどうかわからなかった。１０日間のラインによる感染症の発生率は１１％から０％になった。そこで彼らはさらに１５ヶ月にわたって患者の追跡調査を行った。その期間中に発生した感染症はたった２件だった。この病院では、チェックリストにより４３件の感染症の発生と８人の死亡が防止され、２００万ドルのコストが節約された計算になる。

この成功を見て、ICUのチームは自己組織化を始めた。

研究者達は、単にICUの医師と看護師にそれぞれが毎日しなければならないことのチェックリストを作ってもらうだけで、数週間で、患者がICUに在室する平均的な期間が半分になるほど看護の安定性が改善されることを発見した。

しかし、看護師や医師は高度な訓練を受けた専門家達である。なぜ簡単な短いチェックリストによってこのような違いが生じたのだろうか？

チェックリストが２つの主な効果をもたらしたことにPronovost博士は気づいた。１つめは、特にもっと重大な出来事に耐えている患者の場合に見落としやすい、日常的な事柄を思い出す助けとなることである。...２つめの効果は、複雑なプロセスで最低限求められる手順を明白にすることである。 Pronovost博士は、経験豊富な人材でさえも、いくつかの予防策の重要性を理解していないことがしばしばあることに驚いた。

懐疑的な読者達は、これがたった一つの病院での出来事であることに気づくだろう。おそらく職場の特別な事情があったのではないだろうか？
Pronovost博士は、デトロイトにある最も状況が悪いいくつかの病院も含めた、ミシガン州全体の病院のICUでチェックリストを試した。結果はNew England Journal of Medicineで研究論文として発表された。

プロジェクトの最初の３ヶ月間で、ミシガン州のICUでの感染症発生率は６６％減少した。典型的なICU－デトロイトにあるSinai-Grace 病院のICUを含む－の四半期毎の感染症の発生率はゼロにまで減った。ミシガン州の感染症発生率は非常に低下したので、そのICUの平均は全国的なICU の９０％を上回った。Keystone Initiativeの最初の１８ヶ月で、病院はおよそ１億７５００万ドルのコストを節約し１５００人以上の命を救った。この成功はほぼ４年間続いたが、全てばかばかしい短いチェックリストによるものである。

しかし、ソフトウェア開発の場合は何をしなければならないのだろうか？アジャイル開発チームは、高品質のソフトウェアの予測可能な納品を可能するため、過不足のないプロセスを過不足のない個所に使おうとしている。そこで疑問であるのは、Pronovost博士が作ったような簡単なチェックリストを明確にし、ソフトウェア開発プロセスに適用することが可能かどうかということである。

Kent Beck氏が提唱するエクストリーム・プログラミング（Extreme Programming、XP）の１２のプラクティスは、ちょっとしたチェックリストであるが、そのものではない。ねらいは、つまらない間違いをしたり、チームやシステムに問題を起こしそうなプロセスの各部に適用可能な、短くて簡単なチェックリストを明確にすることである。例えば、日々の仕事の中でどのような種類のチェックリストを使っているかを尋ねたら、Kent氏はこう言った。

私はIDEが直接サポートしていないリファクタリングを行う場合は「ばかばかしい短いチェックリスト」を使います。例えば、フィールドをコンポーネントに移動する場合は次のようなチェックリストです。

1. そのフィールドに値を設定している全てのコードを、コンポーネントのフィールドを設定するように変更
2. そのフィールドにアクセスしている全てのコードを、コンポーネントからフィールドにアクセスするように変更
3. そのフィールドの宣言を削除
4. これが可能にする、さらなる単純化であれば何でも実施

確かに、重要な変更を行おうとしているアジャイルの実践者達が直面している困難な組織的な問題は、簡単なチェックリストでは解決されないだろう。しかし、おそらくアジャイルのコミュニティは、最小のオーバーヘッドで最大の価値を付加すると認められたこれらのチェックリストを明確にし共有しようとすることで、利益を得るだろう。あなたは日々の仕事の中で、どのような「ばかばかしい短いチェックリスト」を使っているだろうか？

原文はこちらです：http://www.infoq.com/news/2007/12/agile-checklists