InfoQ

News

チェックリストの力

作者 Kurt Christensen, 翻訳者 沼田 暁子 投稿日 2008年1月8日 午前12時8分

コミュニティ
Agile
トピック
アジャイル技術
タグ
Best Practices,
プロセス採用,
Checklists and Guides
Atul Gawande氏はNew Yorkerの最近の記事(source)で、明らかにローテクな手段であるチェックリストを用いて、どのようにしてPeter Pronovost博士が世界中の病院のICU(集中治療室)における感染症の発生率を低下させたかについて述べている。Pronovost博士は最も感染症を引き起こしそうな手順を特定し、その手順ごとに簡単なチェックリストを作成した。そしてそのチェックリストを守ったところ、それらの手順による感染症の発生が急激に減少した。
彼は全てのことをカバーするチェックリストを作ろうとはしなかった。彼はたった一つの問題に取り組むことを目的としたのだ。...Pronovost博士は、ICUで働く看護師達に、医師達が患者のラインを入れるのを一ヶ月間観察し、どのくらいの頻度で各手順が完璧に行われているかを記録するように依頼した。3分の1以上の患者において、少なくとも1つ以上の手順が省略されていた。

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

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

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

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

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

チェックリストが2つの主な効果をもたらしたことにPronovost博士は気づいた。1つめは、特にもっと重大な出来事に耐えている患者の場合に見落としやすい、日常的な事柄を思い出す助けとなることである。...2つめの効果は、複雑なプロセスで最低限求められる手順を明白にすることである。 Pronovost博士は、経験豊富な人材でさえも、いくつかの予防策の重要性を理解していないことがしばしばあることに驚いた。
懐疑的な読者達は、これがたった一つの病院での出来事であることに気づくだろう。おそらく職場の特別な事情があったのではないだろうか?
Pronovost博士は、デトロイトにある最も状況が悪いいくつかの病院も含めた、ミシガン州全体の病院のICUでチェックリストを試した。結果はNew England Journal of Medicineで研究論文として発表された。
プロジェクトの最初の3ヶ月間で、ミシガン州のICUでの感染症発生率は66%減少した。典型的なICU-デトロイトにあるSinai-Grace 病院のICUを含む-の四半期毎の感染症の発生率はゼロにまで減った。ミシガン州の感染症発生率は非常に低下したので、そのICUの平均は全国的なICU の90%を上回った。Keystone Initiativeの最初の18ヶ月で、病院はおよそ1億7500万ドルのコストを節約し1500人以上の命を救った。この成功はほぼ4年間続いたが、全てばかばかしい短いチェックリストによるものである。

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

Kent Beck氏が提唱するエクストリーム・プログラミング(Extreme Programming、XP)の12のプラクティスは、ちょっとしたチェックリストであるが、そのものではない。ねらいは、つまらない間違いをしたり、チームやシステムに問題を起こしそうなプロセスの各部に適用可能な、短くて簡単なチェックリストを明確にすることである。例えば、日々の仕事の中でどのような種類のチェックリストを使っているかを尋ねたら、Kent氏はこう言った。
私はIDEが直接サポートしていないリファクタリングを行う場合は「ばかばかしい短いチェックリスト」を使います。例えば、フィールドをコンポーネントに移動する場合は次のようなチェックリストです。
  1. そのフィールドに値を設定している全てのコードを、コンポーネントのフィールドを設定するように変更
  2. そのフィールドにアクセスしている全てのコードを、コンポーネントからフィールドにアクセスするように変更
  3. そのフィールドの宣言を削除
  4. これが可能にする、さらなる単純化であれば何でも実施
確かに、重要な変更を行おうとしているアジャイルの実践者達が直面している困難な組織的な問題は、簡単なチェックリストでは解決されないだろう。しかし、おそらくアジャイルのコミュニティは、最小のオーバーヘッドで最大の価値を付加すると認められたこれらのチェックリストを明確にし共有しようとすることで、利益を得るだろう。あなたは日々の仕事の中で、どのような「ばかばかしい短いチェックリスト」を使っているだろうか?

原文はこちらです:http://www.infoq.com/news/2007/12/agile-checklists
ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

ジャンル別一覧

インタビュー: Emmanuel Bernard氏にBean Validation仕様について聞く

Bean Validationフレームワークの初期ドラフトに関する以前の記事に続き、InfoQは専門家グループが求めているコミュニティの関与と提案について理解を深めるため、Emmanuel Bernard氏と対談しました。

ポーカーに学ぶ、ソフトウェア開発のレッスン

ポーカーは他のトピックにも広く適用できるような数少ない教えを私にもたらしてくれたと信じています。実際私はソフトウェアを開発すればするほど、これら二つの仕事は非常に似ていると言う確信の度合いを深めています。

InfoQがBPEL4PEOPLEの代表と対談

恒例の「バーチャルパネルセッション」で、InfoQは新しいOASIS BPEL4People技術委員会の代表と対談をし、この作業が何故必要であるかについて彼らのフィードバックを得る機会を得ました。

CLR上でのドメイン特化言語の構築

ドメイン特化言語は最近非常に人気が高まっている話題です。これは恐らく、Rails現象に起因していると考えられます。Railsの人気と、Railsにおけるドメイン特化言語(以降、DSL)の大規模な使用は、DSLに対する広範な関心を呼び起こしました。

Rubyのデバッガを調査

Rubyには、Rubyコミュニティの内外で広く知られている誤解が一つある。Rubyにはデバッガがないという誤解だ。しかし、Rubyにデバッガが無いということは誤解なのだ。実際のところ、Rubyにはデバッガ用のツールがある。

改善、成功と失敗: 中国でのスクラム導入

InfoQ Chinaは中国でスクラム(Scrum)がどのように導入されているかに関する調査を行いました。私たちはこの記事のために5つの事例をピックアップしました。これらの事例は、異なるさまざまな会社によるもので、異なるプロセスが利用され、異なる結果が生じたものです。

洗練されたサービス契約による見事なスケーラビリティ

Udi Dahan氏のチームが、サービス契約を利用した2度の失敗を避け、複数の側面でのスケーラビリティに対処しています。

塹壕より Scrum と XP

Agileを始めるときは、とても分かりにくいです。一体どこから手をつければいいのでしょう?この物語はそんな皆様の一助になれば幸いです。本書は、スウェーデンにある、とある40人ほどの会社で、どのようにAgileとXPを実行したか、プロセス改善を行ったかを記しています。