（愛知県知事リコール）中村区提出署名簿の作業を、FMEA的に検証する

はじめに

ウォッチ中の愛知県知事リコール。情報が徐々に出てくる中、署名簿番号や数量についての不自然な点を前回上程しました。
今回は追加情報があったので、作業プロセスに注目し、少しだけFMEA的思考で考察してみたいと思います。

署名簿番号と簿内番号、署名総数の疑義

そんな中、以前にも引用した田中弁護士ブログに、中村区の署名簿提出についての続報が出ています。

名古屋市中村区選挙管理委員会に提出された署名簿: 弁護士田中智之ブログ

ブログ内にpdfファイルが紹介されています。その情報の中で、以下２つの文書の存在が確認できました。

①請求代表者が、署名簿を提出時に添付したレター
②選管が、請求代表者に交付した仮提出受領証

この内容から、以下の２つの事項の相違が推察されます。

（Ａ）請求代表者が作成した、仮提出時の添付レター記載の署名簿番号、署名総数
（Ｂ）選管が作成した、仮提出受領証発行の署名簿番号、署名総数

上記事象を、多少恣意的、短絡的に考えると、以下理由が推察されます。

・①作成時の数字を間違えた
・②の数字が実は違う
・①と②の作業時の実署名簿側が変化した

しかし、上記考察はいささか短絡的。そこで、作業プロセスを推定して、どこで、何のエラーが発生した可能性があったのかを考察してみます。

作業プロセスの想定

実際の現場を見ていませんので、あくまで想定です。
署名簿番号採番～仮提出受領証発行までのプロセスを、以下のように設定します。（設定内容に、実際の作業時との相違があれば、コメントいただくと幸いです）

上記プロセスのうち、作業番号３でレター作成しています。
また、作業番号９で、レター修正作業が行われています。

さらに、作業番号９の作業発生の為には、作業番号５及び６が必要です。
まずポイントは、これら作業番号の順番が実際はどうだったのか？だと考えます。

上記は、私の各情報眺めていての推定順番＆作業内容で、私の推定に基づく仮定です。まず、この仮定が正しいか否か？が、本記事内容の真偽・正誤を論じるうえでは重要なポイントです。
一旦、この仮定が正しいとの前提で以下に進めます。

作業内容の根拠となる判定内容は？

番号を記入したり、冊数を記入したりするには、現物を確認するか、記入者が想像するかしないと、数字は書けません。
当たり前だろ？とよく言われますが、作業にエラーが生じていないか？どこに生じるのか？を論じる上では、一見当たり前だろ？と思う事も、きちんと書き出すことが重要です。

蛇足ですが、この視点って私の周りでもなかなか浸透しません・・・
例えば、「蛇口を閉める」という作業でも、何を以て「閉めた」と判定するか？
①水が出ないことを確認する
②手で回して、それ以上回らないことを確認する
③ハンドルの位置（角度、高さ）を確認する
など、複数の方法があり、人によりどれを行うか、どれを重視するかなどが変わります。

例えば、①だけの確認で終わらせていたとすると、大本が断水していた場合も水が出ません。実は蛇口が空いていて、大本上流側の断水が解消されたときに、周りが水浸し…はよくある事象。
私が仕事で作る設備装置の試運転要領書は、この手の事項も事細かく書くので、いつも分厚くなってしまいます（苦笑）

さて、ポイントとなる作業について、判定事項を書いてみましょう。

黄色く塗った部分がポイントとなる判定方法と考えます。

署名簿数カウント＠レター作成時（作業番号２）

この時の番号記載、冊数記載の確認方法として、以下の２通りを想定します。

①実際の数を数える
②署名簿番号の末尾を確認する

結果として、冊数、番号ともに、仮提出受領証発行時点とは異なる数字を記載してしまいました。そのような事象が起こりうるのか？を検証します。

①実際の数を数えた

この場合の、結果として発生事象としてなりうる事項は以下

（Ａ）数を数え間違えた
（Ｂ）数を数えた時点と、仮提出受領証発行時点で数が変化した

②署名簿番号の末尾を確認した

同様に、発生事象としてなりうる事項

（Ｃ）違う地区の署名簿末尾番号を見た
（Ｄ）数字を見間違えた
（Ｅ）数を数えた時点と、仮提出受領証発行時点で数が変化した

以下は私見です。

今回の数字の変化は、冊数、簿番号ともに「減少」している
　⇒（Ａ）（Ｃ）（Ｄ）であれば、違和感ない
　（作業者レベルや、疲労状況等々あるでしょうし・・・）
　⇒（Ｂ）（Ｅ）であれば、レター作成時と仮受領証発行時点で、署名簿がなくなっている（紛失or他地区へ提出）

署名簿の再採番（作業番号６）の発生理由

署名簿番号の再採番として、小番打ちがされています。
非常に変な作業。これは、重複する番号が存在したことによります。
また、小番は２までですので、重複番号署名簿は２個だけとも推定されます。

何でこんなことが発生したか？の理由考察です。
前提として、作業番号６以前に、署名簿に以下事象が発生していたと推定されます。

・同一署名簿番号となる署名簿が存在

また、最終的な番号として、請求代表者レター作成時の署名簿番号の方よりも、仮提出受領証発行時の署名簿番号が小さい事も重要なこと。その点からは以下事項が推定されます。

・作業番号２時点で存在した署名簿が、作業番号６時点では存在しない。
ただし、エラー事象が（Ａ）（Ｃ）（Ｄ）の場合はこの限りではない。

可能性の話ですが、レター作成時に他地区向けが混在し、改めて抜き取って他地区へ提出などされた可能性もあります。
そうなると、どこかの地区で以下事項があるはず。

・中村区重複番号に該当する署名簿番号が、欠番となっている地区
・レター作成時点で中村区と思っていた最終番号付近の署名簿の番号が、飛び番号ないし小番として提出されている地区

またどこかでゆっくり探してみたいと思います。

結局のところの考察

以上より、エラーを防ぐためには？を考察していくのが、本来のFMEAの活用方法。
ただ、今回はなぜ、このようなことが発生したのか？を、恣意的視点も含めて記載します。

・数を数える、仕分けをするという作業において、スキル不足・混乱・疲労などでエラーを誘発する環境となっていた
・作業番号３～９の間で、署名簿の増減が発生している
・増減した署名簿の行方はどこ？

もう少しデータに基づいて検証できるネタも揃ってきました。
ほどほどに確認していきたいと思います。

皆様はどう感じられましたか？
今回はこれぐらいで。