その1はコチラです。
レビュー祭りからあっという間に、開催から1週間が経ってしまいました。スピード感のないブログで申し訳ありません。その2では、チェックリストに関するセッション『レビューチェックリスト自慢、っん？』について。
チェックリスト。
この言葉を聞いただけで拒否反応を示す人もいるでしょう。
チェックリストの恐ろしいところは、「積極的に削減する理由がない」こと。これを「四次元クローゼットの罠」と呼びます。
ずっと着てもいない服を「破れてはいない」「いつか着るかも知れない」「捨てると後悔するかも知れない」という理由から捨てないのと同様、チェックリストやその項目には、「減らす」動機がない。そして恐ろしいことに、その「着ない服」がいくらあっても、チェックリストというクローゼットは満杯にならんのです。
それはさておきこのセッション、まずは野中誠先生、細川宣啓さん、安達賢二さんが順に、チェックリストに対するご自分の考えを述べられた後、野中先生の立ち会いのもとに、細川さんと安達さんが鍔迫り合うという展開になりました。
野中先生のお話
高齢者在宅監視システムの仕様検討不足の事例から、チェックリストのあるべき姿のお話をされました。この事例については、ThinkITにご自身の記事があります。
この事例のシステムでは、「鍵を内側からかけた」「水を使用した」といった日常の行動をイベントとして、「在宅」「不在」の状態を遷移させています。たとえば、「在宅」状態において「外から施錠」すると、「不在」状態に遷移し、係の人は外部から、不在であると判断できます。
この事例に基づいて、野中先生の挙げられたポイントの1つが「安全性」です。
このシステムでは、「不在→在」に比べて「在→不在」の状態遷移が、重大な意味をもっています。なぜなら、「不在」の人に室内で問題が起きることは「ありえない」。よって、安否を確認する側の注意は離れる。
だから、「在を不在にするイベント」はよく吟味して絞り込む必要があるし、逆に「不在を在にするイベント」は間口を広げておかなくてはならない。
もちろん、イベントがどう行われたかをすべて正確に判定することは不可能なので、実際の状態とシステムの「状態」にずれが起こる場合はある。で、それを許容するとして、「観測状態と実状態にズレが生じた場合、fail-safe か」という安全性の観点で、設計を検討することが必要になります。
この他、「妥当性」「整合性」、さらに「ビジネス価値との整合性」「目的と手段の整合性」などが紹介されました。これらは、チェックリストの項目そのものではなく、項目の分類・切り口と考えた方がよいのでしょうね。
細川さんのお話
細川さんは、チェックリストが単なる責任回避にしか使われていないケースに言及されていました。
何か問題が起きた時に、チェックリストに基づいて作業していないと「なぜ、チェックリストを使わなかったんだ！」という、本質とずれた議論になってしまう。逆にチェックリストをやっておけば「やるべきことはやっていたもんね！ 人事は尽くしたもんね！」という、これまたよくわからない言い訳の材料に使われる。ということは、ありそう。
結果、「チェックリストってめんどくさいけど、とりあえずチェックしとけばいいんでしょ」と「Just do it.」モードになって、ナイキマークをたくさん書くだけの簡単なお仕事になり下がってしまいますね。
細川さんはこの知的作業を、「カラスを飛ばす」と表現していました。チェックボックスに機械的にレ点を入れていくと、「レレレレレ」とカラスの大群が飛び去る姿になるからだそうで・・・。
そんな風になってしまう要因として、チェック項目からドメイン固有の要素を排除することによる、チェックリストの形骸化を挙げられています。またこの排除により汎用性が（見かけ上）上がるため、組織内での適用範囲が広がり、強制力も上がってしまうという問題点を指摘されました。
この他、プロダクトのチェックリストではなくプロセスのチェックリストについて、失敗の確率を下げるためのツールとして役に立つとお話しされています。
この場合の「プロセス」が、プロジェクト全体にまたがるようなプロセスを指すのか、もっと小さな作業を指すのかが、その場では判断できませんでした。わたしは前者はあまり好きじゃありませんが、後者は重要だと思っています。たとえば本番で稼働しているシステムでのプログラム入れ替えといった作業については、チェックリストによって過去の失敗を排除し、手順書の品質をできるだけ一定にして、ミスのリスクを最小化したいものです。
安達さんのお話
泣けるチェックリスト項目の例を、安達さんが挙げてくださいました。
↓何の意味もない巨大なチェック項目。
問題は残っていないか。
↓とても簡単にはカラスを飛ばせない、荘厳な項目。
顧客満足を獲得できるか。
↓古文書。
8inchFDスロットから読み込めるか。
安達さんは、チェックリスト、特に他人が作ったチェックリストは使わない！とのこと。
チェックリストは、「過去の事例を形式知化し、組織の財産にする」ということもできます。が、必要条件の羅列でしかないチェックリストを十分条件と勘違いして、「これに従っていればOK（意味はわからないけど）」という、思考停止の受け身な姿勢につながることもある。このマイナス面を、安達さんは嫌っているとのことでした。
ただし、レビューをする際の観点は用意しているそうです。たとえば、「利用者の立場で」「作業依頼者の立場で」といった、あるロールに成り代った視点でのレビュー、「青森恐山イタコ法」。
確かに設計書を読む時には、「これ、使い方わかりづらくないか？」「本当にこんなの実装できるの？」「これじゃテスト条件が不明確だ」などと、無意識に様々な立場で眺めています。逆にいうと、視点が安定していない。イタコとして明示的なロールを受け持つことで、効率的にレビューできるように思いました。
わたしの考え
これらのお話、およびディスカッションを聴いて、今わたしが考えているチェックリストの方針は、こんな感じでしょうか。
具体的な設計方法や事例は、チェックリストにしない。
ノウハウとして蓄積すること自体はよくって、教育資料だとか、ディスカッションの材料にするのがいいんじゃないかなと。事例を項目にすると、整理されず無限増殖する。
チェックに意味のない遠大なチェック項目を作らない
「問題は残っていないか。」のように、それをチェックすることで何も得られない。そのチェックが意味することが何もないようなリストはご勘弁を。
ツールにかければ見つかるようなものはチェックリストにしない。
静的解析ツールのような、機械でできることは、機械で。 いやまあ全然、目新しい考え方じゃないですけれど・・・。
第3回はコチラです。
