  |
はてなキーワード: 入力ミスとは
今回のワクチン予約システムの不備を家の鍵、マスコミの確認作業（架空予約）を家への侵入に例えるのが（主にマスコミを犯罪者と印象付けたい人たちから）散見されて、それが例え話として間違っているっていうのはよく分かるけど何に例えるのが適切かいいアイデアが思い浮かばない。
そもそも例えるなってのは無しで。
（特にネット上では）例え話って忌み嫌われているけど、理解しにくい話を理解しやすい話に置き換えるのってちゃんと使えたら有用だと思うんだよ。
ある事柄を一般化（帰納）して、別の事柄に具体化（演繹）するっていう思考プロセスは例え話を使わなくてもよくやっているし、物事の本質を見極めるのに役立つと思う。
まぁそれが難しいし、ネット上の例え話は上記みたいな恣意的な例にして論点ずらしたり印象操作したりする人が多いから嫌われるのも分かるけどね。
とりあえず今回は思考の練習だと思って一緒に考えてみてほしい。
最低でも、
・公共の場であり不特定多数の利用者がいることが想定されている（予約システムは不特定多数が利用するけど家を使うのはその家族だけ）
・故意なくても簡易な誤りでトラブルを招く頻度が高い（入力ミスは多くの人がしうるけど他人の家に間違って侵入する人はそうそういない）
といった要素が不可欠だと思うんだけど、なかなか当てはまるものが思いつかない。
「役所の窓口で申請したらめちゃくちゃな内容でも受理された」ってのはオンラインをリアルに置き換えただけでちょっと近すぎるというか例える必要あるか微妙だし……。何かいい案ないかな。
この条件だと認証は接種会場でしかできない。だから予約システム上での認証は諦める。つまり予約は誰でもできるけれど、接種は接種券がなければできないという条件でシステムを考える。
まず現行システムの問題は、全く悪意がなくても、入力をミスると無効な予約を取ったり、他人の予約を上書きできてしまう。それともう一つ、予約時点では全く認証していないのに認証してるふりをしている。
前の二つは接種券番号を予約のidにしている事が問題なので、それをやめて、予約を取ったらシステムが予約番号を発行して予約に対してはその番号でアクセスしてもらう事にする。
ただそれだと、空の予約を取って予約番号を売るやつが出てくるので、今まで通り自治体、接種券番号、生年月日は入力してもらう。そして入力画面には「当日の確認に使用しますので、正確に入力してください」と一番添える。ボタンも認証とは書かない。
予約内容は、発行された予約番号と自治体、生年月日を入力して閲覧と取り消しができるようにしておく。ただし変更は許可しない。入力内容を変更したい時は一回取り消して再予約。これも予約の転売防止のため。
会場には接種券と生年月日が確認できる書類と予約番号を持って行き、現地で内容確認して接種。
接種券番号が違っていても、入力ミスならこの時点でリカバー可能。
これでどうかな？
この条件だと認証は接種会場でしかできない。だから予約システム上での認証は諦める。つまり予約は誰でもできるけれど、接種は接種券がなければできないという条件でシステムを考える。
まず現行システムの問題は、全く悪意がなくても、入力をミスると無効な予約を取ったり、他人の予約を上書きできてしまう。それともう一つ、予約時点では全く認証していないのに認証してるふりをしている。
前の二つは接種券番号を予約のidにしている事が問題なので、それをやめて、予約を取ったらシステムが予約番号を発行して予約に対してはその番号でアクセスしてもらう事にする。
ただそれだと、空の予約を取って予約番号を売るやつが出てくるので、今まで通り自治体、接種券番号、生年月日は入力してもらう。そして入力画面には「当日の確認に使用しますので、正確に入力してください」と一番添える。ボタンも認証とは書かない。
予約内容は、発行された予約番号と自治体、生年月日を入力して閲覧と取り消しができるようにしておく。ただし変更は許可しない。入力内容を変更したい時は一回取り消して再予約。これも予約の転売防止のため。
会場には接種券と生年月日が確認できる書類と予約番号を持って行き、現地で内容確認して接種。
接種券番号が違っていても、入力ミスならこの時点でリカバー可能。
これでどうかな？
この条件だと認証は接種会場でしかできない。だから予約システム上での認証は諦める。つまり予約は誰でもできるけれど、接種は接種券がなければできないという条件でシステムを考える。
まず現行システムの問題は、全く悪意がなくても、入力をミスると無効な予約を取ったり、他人の予約を上書きできてしまう。それともう一つ、予約時点では全く認証していないのに認証してるふりをしている。
前の二つは接種券番号を予約のidにしている事が問題なので、それをやめて、予約を取ったらシステムが予約番号を発行して予約に対してはその番号でアクセスしてもらう事にする。
ただそれだと、空の予約を取って予約番号を売るやつが出てくるので、今まで通り自治体、接種券番号、生年月日は入力してもらう。そして入力画面には「当日の確認に使用しますので、正確に入力してください」と一番添える。ボタンも認証とは書かない。
予約内容は、発行された予約番号と自治体、生年月日を入力して閲覧と取り消しができるようにしておく。ただし変更は許可しない。入力内容を変更したい時は一回取り消して再予約。これも予約の転売防止のため。
会場には接種券と生年月日が確認できる書類と予約番号を持って行き、現地で内容確認して接種。
接種券番号が違っていても、入力ミスならこの時点でリカバー可能。
これでどうかな？
この条件だと認証は接種会場でしかできない。だから予約システム上での認証は諦める。つまり予約は誰でもできるけれど、接種は接種券がなければできないという条件でシステムを考える。
まず現行システムの問題は、全く悪意がなくても、入力をミスると無効な予約を取ったり、他人の予約を上書きできてしまう。それともう一つ、予約時点では全く認証していないのに認証してるふりをしている。
前の二つは接種券番号を予約のidにしている事が問題なので、それをやめて、予約を取ったらシステムが予約番号を発行して予約に対してはその番号でアクセスしてもらう事にする。
ただそれだと、空の予約を取って予約番号を売るやつが出てくるので、今まで通り自治体、接種券番号、生年月日は入力してもらう。そして入力画面には「当日の確認に使用しますので、正確に入力してください」と一番添える。ボタンも認証とは書かない。
予約内容は、発行された予約番号と自治体、生年月日を入力して閲覧と取り消しができるようにしておく。ただし変更は許可しない。入力内容を変更したい時は一回取り消して再予約。これも予約の転売防止のため。
会場には接種券と生年月日が確認できる書類と予約番号を持って行き、現地で内容確認して接種。
接種券番号が違っていても、入力ミスならこの時点でリカバー可能。
これでどうかな？
この条件だと認証は接種会場でしかできない。だから予約システム上での認証は諦める。つまり予約は誰でもできるけれど、接種は接種券がなければできないという条件でシステムを考える。
まず現行システムの問題は、全く悪意がなくても、入力をミスると無効な予約を取ったり、他人の予約を上書きできてしまう。それともう一つ、予約時点では全く認証していないのに認証してるふりをしている。
前の二つは接種券番号を予約のidにしている事が問題なので、それをやめて、予約を取ったらシステムが予約番号を発行して予約に対してはその番号でアクセスしてもらう事にする。
ただそれだと、空の予約を取って予約番号を売るやつが出てくるので、今まで通り自治体、接種券番号、生年月日は入力してもらう。そして入力画面には「当日の確認に使用しますので、正確に入力してください」と一番添える。ボタンも認証とは書かない。
予約内容は、発行された予約番号と自治体、生年月日を入力して閲覧と取り消しができるようにしておく。ただし変更は許可しない。入力内容を変更したい時は一回取り消して再予約。これも予約の転売防止のため。
会場には接種券と生年月日が確認できる書類と予約番号を持って行き、現地で内容確認して接種。
接種券番号が違っていても、入力ミスならこの時点でリカバー可能。
これでどうかな？
自衛隊の予約システムは役所，銀行の整理券やファミレスのレジ前に置いてある名前を記入する用紙を電子化したような物．接種会場での本人確認が必須なので受付が捌き切れれば良く，本来はこの仕組みで運用を回せるのかを注視すべき．東京会場の次週分は予約終了した模様．
https://www.mod.go.jp/j/approach/defense/saigai/2020/covid/index.html
※マスコミはその辺ちゃんと取り上げて欲しいし，政府側もそういう説明が必要だった
自衛隊の接種はまだ始まっていない．接種回数の向上に貢献できるかで判断すべきでは．
「戦力の逐次投入」は悪手では．政府としても色々と自前でやり繰りできる体制の方が扱いやすいので自衛隊主体がいいと判断する気持ちは理解できる．自治体が必要な人員を適切に判断できるなら良いんだけど大阪住まいの私には出来ると思えない．そう言えば純粋な疑問なんだけど自衛隊が派遣されて自治体の業務を支援する場合って指揮系統どうなるんでしょう．
受付でチェックされるので入力ミスで予約できないよりは良いのでは．状況によっては対象の自治体を変更することもあると考えると緩いチェックも選択肢のひとつ．その辺の運用まで詰めてシステムを構築するのは結構大変．
65歳未満でも問題無いのは自治体コードの考え方と同じでは．不正な日付は私が試した際(予約までは確定せず)はエラーなったので修正されたんでしょうか．不正な日付で登録できたというソースは発見できていないですが．
個人情報にならないとしても各自治体と調整してデータを受け取る運用，業務フローを確立する必要がある．データの連携ができれば良いかもしれないが出来ないとしても何度も書くけど「受付で捌ければ良い」のであって必須ではない．「個人情報は氏名・住所・生年月日・電話番号の4点セット」は明らかに間違い．
5/16時点の高齢者累計接種回数は東京で約7,5000，大阪で約4,4000なんで1日1.5~2万は大した数でしょう．
https://www.kantei.go.jp/jp/headline/kansensho/vaccine.html
気になるなら自分で調べると良いよ．
VRSは各自治体がマイナンバーなどを含む個人情報をアップロードしている．自治体は自身の管理する住基台帳の分しか参照出来ないようになっている模様．VRSと連携すればいいじゃんとか言いだしそうな気がするので述べておくけどVRSへの反映が遅れたりそもそも自治体ではなく都道府県で優先して接種した場合はそっちに照会かけないと登録されないので完全なデータではないよ．GW明けで今月中に対応しろと言われたら泣く．
GW明けで今月中に対応しろと言われたら泣く．自治体と言っても規模や運用は異なっていて使っているシステムもデータ形式もバラバラ．人口数千〜数万人規模の自治体と人口百万人規模だと必要とされる要件も異なります．人口少ないならそもそも予約いらないし．
ちょっと面倒だったり怒られが発生しそうな電話を上司に丸投げするので
自分の入力ミスとか添付忘れとかの確認で取引先から電話がきてるのに
内容まで聞いておいて「担当者に代わります」って言って上司に代わって対応させるし。
「私が間違っちゃったのかもしれないんですけどお」って上司に謝る。
かもってなんだよかもって。
お前が一人で作業担当してるんだからお前が間違ったしかねえだろと。
現状では、自治体コード、接種番号、生年月日以外は入力しないので、ユーザーに悪意がなくとも次のような問題がある。
・6桁の数値・10桁の数値・生年月日の入力では必ず一定割合で入力ミスが発生するのに、それをリカバリーする方法がない
（初回に間違えて入力したら後から訂正・キャンセルすることが難しい）
・確認メールが送られてこないので、利用者が本当に予約しているのか確認するのが難しい
・現地での予約確認に番号と生年月日だけで付き合わせないといけないので面倒＆間違いが発生する
（1日10,000人だと30分で500人の受付をすることになる。それを番号と生年月日だけで間違いなくやれるのか？）
・現地で番号が一致しなかった場合に入力ミスなのか、予約をしていない・できていないのか判断がつかない
・1回目の予約で入力間違いがあった場合に2回目の予約はどうするの？
・現地での2回目の入力で番号の入力ミスがあったら、後でキャンセル・変更ができないのでは？
コロナ禍で美術館とかで無料でも予約必須になったりしているけど、ここまでひどいのは無くて、少なくともメールアドレス（or 電話番号）、氏名は入力させている。
だから、大規模接種の予約サイトもメールアドレス・氏名の入力を必須にして、メールを届いたことを確認した上で認証するようにすればいい。
そうすれば、番号の入力ミスがあっても後から気づいて修正できるし、現地での予約確認も容易になる。
私は元増田さんよりもっと酷かったです。元増田さんはこれでも読んで元気出してください。
・バイト初日、店員の顔色を伺いすぎて10分前に着いたにもかかわらず遅刻
・バイト２日目、前日に教わった事を覚えきれず怒られる。
・次のバイトはレジ打ちメインだったのだが、入力ミスで誤差3000出す（自動レジなのに）
・レジ締め作業がなかなか覚えられなかった（3回目くらいでやっと覚えた）
今大学4回生だけど、恵まれた環境とそこそこの運と愛嬌でやり抜いてきたから、今詰んでる。専業主婦目指してたけれど、パートナーに頼り切るのは申し訳ないし、子供産むもんなら子供が可哀想。人生詰んでる。マジ。
過去の文学作品にあるというのだが、実際にみてみると、ただの入力ミスっぽくて笑える
https://dictionary.goo.ne.jp/word/%E7%97%A9%E3%81%9B%E3%81%8E%E3%81%99/example/
登録番号って感染者かどうかに関わらず貰えるもんなん?それならなりすまし(陽性者騙り?)も可能だし問題だと思うが。
ただ単に「別人が貰った感染者の登録番号を総当りで入力出来る可能性がある」ってだけなら国内の感染者が7万人弱で人口の1％未満なんだから、3回の入力ミスでアプリが終了するなら結構な手間がかかって「容易」とは言い難いんじゃあないか。そしてその登録番号にはハッシュ値が含まれてないんか？
ツールの使用でどうにかできるかもしれんが、そこまでして悪用するやつを運用の想定に入れるかどうかって事になるわな。もちろん悪用出来ないに越したことはないんだけど。
#COCOAボランティアデバッグ に尽力されている皆様に深い敬意を表します。
併せて、 OSS コミュニティへの悪影響を残している関係行政機関・各社担当者を強く軽蔑します。
project dead? · Issue #773 · Covid-19Radar/Covid19Radar · GitHub
(注) これはアプリケーション固有の問題ではない( Apple-Google API の問題)が、前項の問題点と併せることで脅威となりうるので便宜的に示しておきます
※一部で報じられている「保健所から COCOA への陽性情報の登録に必要な処理番号が即日発行されない」などの問題もありますが、ここでは省略します
※以下はあくまでシミュレーションであり、 COCOA の悪用を助長する意図はありません
細かい説明や具体的な表現は控えましたが、この攻撃を仮に受けたとして致命傷に近いダメージを受ける事業者は少なくないと思います。
事業所単位で COCOA の導入を推奨している管理者は直ちに見直すことを推奨します。
本日より COCOA の導入を促すテレビCMが放映されているようです。（ #検察庁法改正案に抗議します で一躍有名になったきゃりーぱみゅぱみゅ氏などが出演されているようです）
一方で COCOA アプリケーションのリリースは 2020年7月13日 にリリースされた v1.1.2 を最後にアップデートが途絶えており、不具合ととれる多数の事象は解決されず、上記に挙げたような問題点が払拭されることも残念ながら当面は無さそうです。
世間では高ぶる正義感からか COCOA の導入を声高らかに勧めたり、従業員やビジネスパートナーに導入を強いている管理者も現れているようです。
このエントリを通じて、そのような方々へ抵抗出来る材料が提供できれば幸いです。
冒頭のように COCOA の原型であるとされる Covid-19Radar/Covid19Radar プロジェクトも OSS にあるまじき「放置状態」が続いています。
これが GitHub を買収した企業に所属する人間の所作ですか？
IT/ICT や OSS を通じて昨今の COVID-19 感染拡大を発端とする諸問題を解決する動きは支持したいですが、このような杜撰なサービス運営により IT/ICT や OSS に対する世間の期待を悪化させることを強く憂慮しています。
