「ダブルチェックでミスはなくなる」——だがスプレッドシートの研究では、点検は誤りを減らすが、ゼロにはしない

ダブルチェックすればミスはなくなる、と教わる。だが締めの主役であるスプレッドシートの研究は、実運用の表が高い割合で誤りを含み、丁寧な点検でも一部しか見つけられず、複数人で見ても誤りが残ることを示す。ダブルチェックは誤りを減らすが、ゼロにはしない。かといって無意味でもない。過信と放棄のあいだに立ち、速く締まったことを正しく締まったことと取り違えないのが、この単位の答えである。

速く締めることと、正しく締めること

前の単位では、不正の芽と、それを摘むと言われる仕組みを扱った。ここでは、不正ではない——ただのミスを扱う。数字を写し間違える、式の参照がずれる、行を一つ飛ばす。悪意はどこにもないのに、締めた数字が合わない。

この棚の青の段の入口では、「月次決算を早くするには？」という速さの問いを立てた。緑の段の締めであるこの単位は、その速さに正確さを返す。速く締めることと、正しく締めることは、しばしば引っぱり合う。 よく聞くのは、「ダブルチェックすればミスはなくなる」という言い方だ。この単位は、その「なくなる」がどこまで本当かを、締め作業の主役である表計算——スプレッドシートの研究から見直す。

「ダブルチェックでミスはなくなる」——スプレッドシートの研究が言うこと

多くの人にとって、月次や決算の締めはスプレッドシートの上で進む。だから、締めのミスを考えるなら、スプレッドシートに誤りがどれだけ入るかを調べた研究が、まっすぐ効く。

この分野には蓄積がある。Panko が1998年にまとめた研究は、実際に運用されているスプレッドシートが高い割合で誤りを含むことを示した。Powell・Baker・Lawson が2008年にまとめた文献レビューは、この分野の研究を整理し、Powell らが2009年に行った実地の監査は、現に業務で使われているスプレッドシートに誤りが見つかることを確かめている。

ここで数字の扱いには気をつける。誤りの割合の具体的な数値は逐語で確認していないので、「高い割合」という定性の言い方に留める——ただし、向きははっきりしている。実運用のスプレッドシートは、思っているより誤りを含む。「一度作ってダブルチェックしたから大丈夫」の「大丈夫」は、研究の前では強すぎる。

誤りが入り込む場所には、傾向がある。多いのは、手で数字を打ち込むところと、式が指し示す範囲の境目だ。前の月の表をコピーして今月分に作り替えるとき、集計の式が拾う範囲が一行ずれる。別の資料から数字を転記するとき、桁を一つ写し間違える。どれも、注意深いかどうかという個人の資質の話ではなく、表計算という道具の構造上、そこに誤りが集まりやすいという話である。だから対策も、「もっと気をつける」ではなく、「誤りが集まる場所を知って、そこを見る」という向きになる。

点検には、検出の上限がある

では、チェックを重ねれば誤りは消えるのか。ここが核心だ。Panko が1999年に、ソフトウェアのコード・インスペクション（複数人で一行ずつ点検する手法）をスプレッドシートの点検に応用した研究は、丁寧な点検でも、含まれる誤りの一部しか見つけられないことを示した。Panko と Halverson が1994年に個人と集団のスプレッドシート作成を比べた研究も、複数人で作っても誤りは残ることを扱っている。Powell らが2009年に業務用スプレッドシートの誤りを分類した研究も、誤りが多様な形で残ることを示す。

だから値切りはこうなる——ダブルチェックで誤りはゼロにならない。点検には検出の上限があり、二人で見ても、見落とされる誤りは残る。ただし、ここで反対側へ振り切らないことも大事だ。「だからチェックは無意味だ」も、同じくらい間違っている。 点検は、残る誤りを減らす。ゼロにはできないが、しないよりは減る。過信も、放棄も、しない。 チェックは「保険」であって「保証」ではない、という程度に扱うのがちょうどよい。

速さと正確さは、引っぱり合う

ここで、青の段の入口に戻る。「速く締める」ことには価値がある。だが、速く締める圧力が強すぎると、点検は形だけになりやすい。時間が足りないまま「見たことにする」チェックは、検出の上限をさらに下げる。速さと正確さは、しばしばトレードオフ（あちらを立てればこちらが立たない関係）にある。

この単位は、どちらか一方を選べとは言わない。速さを求めるなら、点検が形骸化していないかも同時に見る。「早く締まった」と「正しく締まった」は、別々に確かめるべき二つのことだ。速く締まったことを、正しく締まったことの証拠にしない——ここが、青の段の速さに、緑の段の締めが返す答えである。

ひとつ、規模の話も添えておく。ここまでの研究の多くは、まとまった量のスプレッドシートや複数人での点検を想定している。一人で全部を締めている人には、そもそもダブルの相手がいない。 その場合、二人で見るという前提は成り立たないから、できるのは「時間をおいて自分でもう一度見る」「手入力と参照の集まる場所だけを重点的に見る」といった、一人でも回せる形の点検になる。相手がいないことを、点検をしない理由にしなくてよい——見る場所を絞れば、一人でも残る誤りは減らせる。

時間・変化：スプレッドシート研究が積み上げてきたこと

順に置く。1994年Panko と Halverson が個人と集団の誤りのパターンを、1998年Panko が実運用スプレッドシートの高い誤り率を、1999年Panko が点検でも一部しか捕えられないことを示した。2008年Powell らが文献レビューでこの分野を整理し、2009年Powell らが実地監査と誤りの分類で、業務用スプレッドシートの誤りを重ねて確かめた。

この間に確からしくなったのは、「ダブルチェックすればミスはなくなる」ではない。確からしくなったのは、実運用のスプレッドシートは高い割合で誤りを含み、点検には検出の上限があり、複数人で見ても誤りは残る、という向きのほうである。

妨げるもの、助けるもの、最初の一歩

妨げるものの筆頭は、「ダブルチェックしたから、もう合っている」という過信だ。点検には上限があり、二人で見ても誤りは残る。反対に、「どうせ残るならチェックは無駄」という放棄も妨げになる——点検は残る誤りを減らす。過信と放棄の、あいだに立つ。もうひとつの妨げは、速く締まったことを、正しく締まったことと取り違えることである。

助けになるのは、点検の回数を増やす前に、自分の締めのどこに手入力と参照が集まっているかを、目で辿って知ることだ。誤りが入りやすいのは、たいてい手で打ち込んだ数字と、式が指し示す範囲の境目である。

最初の一歩は10分。直近の自分の締めで使った表計算を開き、手で数字を入力したセルをいくつか選んで、その値がどこから来たか（どの資料の、どの数字か）を辿って書き写す。次に、合計や集計の式が、どの範囲を参照しているかを数件、目で追って書き出す。誤りがゼロだと保証する作業ではない——どこに手入力と参照が集まっているかを、自分で見えるようにするだけである。他人の作業を点検する必要はなく、自分の締めの表だけで完結させる。

次の単位は 425「内部統制を整えるには？」——ここまで見てきた日々の規律を、統制という仕組みへどう束ねるのかを、その公式の由緒とコストの論争から積み直す。

皮肉なのは、「ダブルチェックすれば安心」と最も強く信じているときほど、点検が形だけになりやすいことだ。二人で見た、という事実が、見落とした誤りをかえって見えなくする。スプレッドシートの研究は、はるか前から言っている——実運用の表は思うより誤りを含み、丁寧な点検でも一部しか捕まらず、複数人で見ても残る、と。締めの数字がダブルチェック済みで安心に見えるとき、たいていそれは、まだ運よく、見落とした誤りが結果を大きく動かしていないだけかもしれない。だから、なくす、ではなく、減らして、残りを見張る。