ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

『アナタはなぜチェックリストを使わないのか?』に答えられないからチェックリストを使うしかない

 信頼できる読み手がTwitterで言及しているのを見つけて読んでみました、『アナタはなぜチェックリストを使わないのか?』。
 期待通り、とってもいい本だったので紹介してみます。

 この本は、「複雑な事象」に対応するにあたって、シンプルなチェックリストがいかに役立つかを紹介しています。エピソードが豊富で、特に医療・航空・建設など、些細なミスが死に直結するような現場における実践からの洞察は、説得力に満ちています。

 ただ、以下のようなアオリはちょっとどうかと思います。

オバマ大統領も認めた著者が贈る全米30万部突破のベストセラー書!
「チェックリスト」の作成こそが危機管理の特効薬だ!

 「特効薬」ではないんですよね。
 本書でいうチェックリストは、とても地味だし、すべてをカバーするものではないし、常に発展途上のものです。それでもなお、目に見える効果があるというのです。

チェックリストのよくある問題点

 「チェックリスト」という言葉自体に、激しい嫌悪を感じる人も多いと思います。
 あれやるにもチェックリスト、これやるにもチェックリスト。セル結合のExcel、3桁レベルのチェック項目、謎の職印欄、よくわからない内容・・・(フィクションです)。

 チェックリストには、それ自体と、それを使う人間の方、両方に問題が出がちです。

チェックリスト自体の問題

  • 項目の抽象度のコントロールの難しさ。いろんな局面で汎用的に使えるものにしようとすると、ふんわりしすぎていて何をしていいかわからない内容になる。逆に具体的にしすぎると、個別の話にしか適用できない項目が山盛りになってしまう。
  • メンテされないことによる項目の肥大化、重複、陳腐化。

使う側の問題

  • チェックリストの項目はすべてを網羅しており、他のことは考えなくていいと考えてしまう。
  • チェックリストの記述は常に正しいと思考停止してしまう。
  • チェックリストの項目の背景にあることに注意しない。

 その結果「チェックリストは使えない」となって使わない、メンテしないの負のループ。
 心当たりはないでしょうか?

本書でいうチェックリスト

 本書でいうチェックリストは、そういうものではありません。
 本書第6章で、著者は明確にこう言っています。

チェックリストはマニュアルではない。すべての手順を詳細に説明するものではない。熟練者を助けるためのシンプルで使いやすい道具なのだ。素早く使えて、実用的で、用途を絞ってあるという特性こそが肝要だ。

 すべてを網羅したリストではなく、外してはいけないクリティカルなポイントを簡潔にまとめたもの
 それが本書でいうチェックリストなのです。

 パイロットのためのチェックリストは、チェックリストに「載せる」「載せない」それぞれについて面白い判断があります。

 まず、「載せない」もの。
 たとえ重要な手順であっても、プロのパイロットが忘れることが考えられないもの(たとえば「管制塔に連絡する」)は、意図的にチェックリストに含めないそうです。チェックリストはすべての手順を網羅するものではないので、載せても価値のないものはできるだけそぎ落とすのです。

 一方で、「載せる」もの。
 エンジンが停止した時のためのチェックリストには、エンジン再始動の方法が6つの手順に凝縮されているそうです。その1つ目の手順は、なんと「飛行機を飛ばせ」。あまりに当たり前に思えますが、パイロットはしばしば、エンジン停止の原因分析に集中してしまい、もっとも肝心な「飛行機を飛ばす」ことが頭から抜けることがあるのだと・・。

 著者はこうも言っています。

人々が手順を忠実に守らない理由の一つに、硬直化が怖い、というのがある。機械的にチェックを行っていたのでは現実に対処できなくなる、チェックリストばかり見ていると心のないロボットのようになってしまう、と思い込んでいる。だが実際は、良いチェックリストを使うと真逆のことが起きる。チェックリストが単純な事柄を片付けてくれるので、それらに気を煩わせる必要がなくなる*1

 難しい状況、変化が激しい状況にあっては、人間が迅速に決断をしていく必要があります。チェックリストは、それ以外のことに判断力・記憶力を使わなくてすむようにしておくためのツールなんですね。

ソフトウェア開発で使いどころはあるか?

 「注意すべきことを網羅的に整理したもの」ではないので、ソフトウェア設計とかテスト観点のレビューには、あまり合わないように思いました。
 本書に出てくるエピソードを読む限りは、以下のような場合に合うんじゃないかと思います。

  1. 重要かつリスクの高いリリース
  2. システム障害時の対応

 手術準備完了のチェックリストには、「手術台の上にいるのは正しい患者か」「手術するのは右側か左側か」という極めて基本的な項目があるそうですが、システムを操作する際の「ログインした環境は正しい環境か」なんて、そのままなんじゃないかと思います。

 ところで本書では、チェックリストの副産物として、2つのことを繰り返し強調しています。
 「コミュニケーション」「責任の分散」です。

 手術に臨む際のチェックリストには、「1分でもいいから全員が必ず話し合う」という項目があり、これが2つの効果があるそうです。

  • お互いの名前と役割を理解し合う。お互いの名前を知っているグループの方がチームワークがよい。
  • 最初に懸念を表明する機会を与えられると、当事者意識と責任感が高まり、その後も問題提起や提案をしやすくなる。

 各メンバーが、「からの指示通り動く作業者」ではなく、「成功に至るための責任者の一人」として振る舞えているかも、チームとしての成功に大きく関わることだと思います。

おわりに

 書評を見ると、「文章にまとまりがなく、長すぎる」といったものがあり、確かに否定できません。チェックリストうまく作る・使うための洗練されたレシピみたいなもの*2を求めている人には、このハードカバーは長すぎでしょう。

 ただこの本は「ノウハウ集」ではなく、「チェックリストの効果、それを普及させるたも経緯を追体験する」ような形で書かれており、ストーリーを追って読むものです。読み物なので、厚い割には意外なほどスルスルと読めるのですよ。

 この本から、チェックリストのあるべき姿を学び、自分の仕事のどんな場面で使えそうかを考えてみると面白いでしょう。

*1:少し、自動テストの発想にも似ている。機械的にできることは機械にやらせる。人間は人間にしかできないことに時間を使う。

*2:それに近いもの、「チェックリスト作成のためのチェックリストが巻末に載っている。