アカウント名:
パスワード:
重複予約の回避は色々なしがらみで難しかったかもしれない。でも、市区町村コードなんて一覧がある [soumu.go.jp]のだから、チェック機能入れるだけじゃないの？と思う。誰が設計したんだ、これ。
接種券番号自体は自治体主管で総務省すら把握してないからしょうがないというのは百歩譲っても、2020年6月生まれでも予約できるとかなんなら2月31日でも予約できるとかシステムとすら呼べないデザインモックレベルなのは言い訳のしようも無いというか。これで毎日や朝日の記事を叩くのは逆ギレでしかない。
わざわざ「このシステム適当に番号入力しても通りますよー」と宣伝する必要があると思う？過失があったら何してもいいわけではない
逆ギレでも何でもないよ
今後、ワクチン接種対象年齢が引き下げるんだし、改修繰り返してミスするよりか、自由記入の方がマシかと。本人がウソつかなければいいだけでは？ウソついたら接種できないわけだし。
これはひょっとしたらあるのかもしれない「描いた通りのものを入れるべきで、勝手に修正するべきじゃない」とうるさい客に会ったことがあるので…
2月31日と書きたい人が書けないシステムはダメそういう判断する人がいたのかも
ウソをつくつかないじゃなくて利用想定がただでさえ不慣れな高齢者で且つ予約の取り合いになるほど殺到してる昨今の情勢であわてずミス無く入力してくださいなんて「お願い」しても意味ないんですよ。間違えた入力をしても正常完了してしまう。予約券番号の一桁間違えたくらいなら多少人の推測や気遣いでカバーできるかもしれませんが、自治体番号間違えたらその人の予約はどこの自治体とも紐付かずいざ当日いってみたら貴方の予約はありませんとしかならないんですけどどういう運用想定なんですか？
名前と時間とかで大体わかるんじゃね?
なんかわかった気がするわこれは単なる「紙の代わり」なんだよだから制約もチェック機能もない だって紙にはないから
そういう発想で作ったんだろうチェックデジットなんか入れてそれがおかしかったらどうする!全部現場で確認するからいいんだ!
っていう奴か…
紙には窓口のおばちゃんってチェック機能があるやん
郵送の代わりぐらいなんでしょう当日担当者はいる訳だし、ネットで「おばちゃんの代わり」相当のものを実装できると思ってもないんだろう実装すべきとも思ってない。間違ってたら困るから。的な
そもそも予約番号にチェックデジットどころか規則性がない、と合うか自治体に任せてて、全自治体につなぐなんてのがパッとできるわけでもないので番号については最初の発行から間違ってたのであってサイトのせいとは言い難い気がする
腐った仕様にまともな皮被せるのは難しいんだよ
番号についてはまだ分かるただ親コメの市区町村コードとか日付すらバリデーションしてないのはやる気ないだけだろう
同じ意見です。システムとしてもうちょっと何とかしてもよかったとは思うけど、何か問題になるかと言えばそうじゃない。
1%ぐらいミスで照合できなくて当日に接種できなかったとして、次の日に回せばいいだけで問題にならないと思う。ワクチンは治療と違うから即どうこうなるわけじゃないし、どうせ無料で全員接種する予定なんだから、対象じゃない人に打っても大きな問題ない。
それもあるけど、なんで高齢者対象の段階なのに、生年月日のデフォの選択年が「昭和45年」なのか？誰が合理的な説明を教えてくれまいか？せめて高齢者の下限ぎりぎりでセットしとけよと
今後一々その辺変更しないから。その辺の手順増やすとミス発生に繋がる。
アップデート履歴2021/6/3 生年月日のデフォルト選択を「昭和45年」に変更しました。2021/5/31 生年月日のデフォルト選択を「昭和40年」に変更しました。2021/5/20 生年月日のデフォルト選択を「昭和35年」に変更しました。2021/5/10 生年月日のデフォルト選択を「昭和30年」に変更しました。
とか段階で変更するの？
このコメント見てるだけでも「偽りを述べる者が愛国者とたたえられ、真実を語る者が売国奴と罵られた世の中を、私は経験してきた。」の様相を呈してきたな…
そのご都合主義な「チェック」の仕様を述べよ
システム開発の教科書でいいかい？
教科書の内容で大規模システムの(上っ面だけじゃない)チェックが行えるならいいよ
実際に存在する自治体コードかどうかを確認することがそんなに難しいのですか．
あなたがお勤めの会社が何らかのオンラインサービスに関わっているのでしたら，その程度の技術力のところには発注しないでほしいです．
で、自治体が発行した予約番号に自治体コードって入っているの？
自治体が発行した接種券に、券番号１０桁と市区町村コード（自治体コード）６桁が記入されてた（親の接種券を見た）
予約はまだしてないので、予約番号というのはよくわからない…
エア開発者だらけだな
市町村コードくらいはチェックしろというのは同意します。その上で、なんですが……ただ「チェック機能入れるだけ」では済まなくて、都度更新されるので、過去のマスタも保持する必要があり、ちゃんと設計しようとすると面倒なことになります。面倒を避けるために国交省や農水省が公開している電子納品チェックシステムは定期的にブランチ切ってコードフリーズみたいなことをやってますね。いずれにしろコードの一覧が公開されている以上、悪意のある入力を弾くことはできないので、誤入力対策でしかないのは留意する必要があります。
上の方にも書いてあるが、せめて接種券番号にチェックデジット入れるだけでいいだろ・・・
接種券番号は自治体主管だから無理。人口100人くらいの村から来た爺さんにチェックサムの仕組み説明できるか？
こっちで作った番号を100個持たせて返せよ検証アプリも渡したほうが良いか むしろURLかな?
別に未来永劫維持するシステムではないので手メンテできれば十分ですが。。。それともあなたの世界線では日々数件以上の市町村コードが変更されているのですか？
契約期間終了後の「手メンテ」は誰がするのよ？
契約期間終了後に限らず、契約期間中の市町村コードの改訂は誰が責任もって監視して追従するのかという話になるリアルタイムで更新していくのか、年度ごとにマスタを管理して更新していくのか、市町村側とも歩調を合わせないといけないやれと言われたらやるのは難しくないけど、そこに至るための合意を得るのに時間が掛かるのが縦割りの官公庁
NHKニュースによるとこの「大規模」接種は8月下旬までの期間限定らしいよ。年度メンテなんて発生しない。 https://www3.nhk.or.jp/news/html/20210517/k1 [nhk.or.jp]
寄与率1/16000って、日本のその他の場所で2億4千万回/日もの接種できるリソースがあるってこと？それとも、この大規模接種会場はたった1日しか稼働しない前提ですかね。
SQLのJOIN部分で変なことになんないのかとか、画面表示は業務的に正常な何かになるのかとか、いろいろ気になっちゃう。
この記事のコメント量から、メンテ前に登録した予約は参照更新が上手くできませんとかあったらむっちゃ叩かれそうやで
市町村コードくらいはチェックしろというのは同意します。その上で、なんですが……ただ「チェック機能入れるだけ」では済まなくて、都度更新されるので、過去のマスタも保持する必要があり、ちゃんと設計しようとすると面倒なことになります。
市町村コードって合併とかあったら変わるもんでしょ？センターの運用期間内（2年くらいか）に合併がなさそうなら無視していいんじゃない？
合併があったらそんとき手作業で変えればいい
合併してコードが変わっても券は変わらないパターンもありえるし、防衛省はコードの責任省庁ではないからコードがどう変わるか責任を取れない調整したら時間がかかる
まあ多分大丈夫でしょで万一が起こることに目を瞑るかザルにするかの選択にならざるを得ないかと
そういうの全部ひっくるめた上で雑な運用をするというのなら、それはそれでアリ。
一度そういう検討を経て、市町村合併でコードが一致しない事象も発生し得ることが分かっていれば、バリデーションチェックで引っ掛かったときに「未知のコードが入力されました。この現象は市町村合併で生じることがあります。本当にこのまま送信しますか？」といった警告で通す設計も考えられる。
何も考えずに、ただ市町村コードをチェックしろみたいなのが一番ダメ。事前に想定したコード以外は絶対に通さないクソシステムの出来上がり。
同じ期間・工数で作れるかどうか考えたら、答えが見つかるかもしれない
# いや、実際は金も時間もあったのにクソみたいなところが作っただけかもしれないが
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
市区町村コードくらいは (スコア:0)
重複予約の回避は色々なしがらみで難しかったかもしれない。
でも、市区町村コードなんて一覧がある [soumu.go.jp]のだから、チェック機能入れるだけじゃないの？と思う。
誰が設計したんだ、これ。
Re:市区町村コードくらいは (スコア:1, すばらしい洞察)
接種券番号自体は自治体主管で総務省すら把握してないからしょうがないというのは百歩譲っても、
2020年6月生まれでも予約できるとかなんなら2月31日でも予約できるとかシステムとすら呼べないデザインモックレベルなのは言い訳のしようも無いというか。
これで毎日や朝日の記事を叩くのは逆ギレでしかない。
Re: (スコア:0)
わざわざ「このシステム適当に番号入力しても通りますよー」と宣伝する必要があると思う？
過失があったら何してもいいわけではない
逆ギレでも何でもないよ
Re: (スコア:0)
今後、ワクチン接種対象年齢が引き下げるんだし、改修繰り返してミスするよりか、
自由記入の方がマシかと。
本人がウソつかなければいいだけでは？
ウソついたら接種できないわけだし。
Re:市区町村コードくらいは (スコア:2)
これはひょっとしたらあるのかもしれない
「描いた通りのものを入れるべきで、勝手に修正するべきじゃない」
とうるさい客に会ったことがあるので…
2月31日と書きたい人が書けないシステムはダメ
そういう判断する人がいたのかも
Re: (スコア:0)
ウソをつくつかないじゃなくて
利用想定がただでさえ不慣れな高齢者で且つ予約の取り合いになるほど殺到してる昨今の情勢であわてずミス無く入力してくださいなんて「お願い」しても意味ないんですよ。
間違えた入力をしても正常完了してしまう。
予約券番号の一桁間違えたくらいなら多少人の推測や気遣いでカバーできるかもしれませんが、
自治体番号間違えたらその人の予約はどこの自治体とも紐付かず
いざ当日いってみたら貴方の予約はありませんとしかならないんですけどどういう運用想定なんですか？
Re: (スコア:0)
名前と時間とかで大体わかるんじゃね?
なんかわかった気がするわ
これは単なる「紙の代わり」なんだよ
だから制約もチェック機能もない だって紙にはないから
そういう発想で作ったんだろう
チェックデジットなんか入れてそれがおかしかったらどうする!
全部現場で確認するからいいんだ!
っていう奴か…
Re: (スコア:0)
紙には窓口のおばちゃんってチェック機能があるやん
Re: (スコア:0)
郵送の代わりぐらいなんでしょう
当日担当者はいる訳だし、
ネットで「おばちゃんの代わり」相当のものを実装できると思ってもないんだろう
実装すべきとも思ってない。間違ってたら困るから。
的な
そもそも予約番号にチェックデジットどころか規則性がない、と合うか自治体に任せてて、
全自治体につなぐなんてのがパッとできるわけでもないので番号については最初の発行から間違ってたのであってサイトのせいとは言い難い気がする
腐った仕様にまともな皮被せるのは難しいんだよ
Re: (スコア:0)
番号についてはまだ分かる
ただ親コメの市区町村コードとか
日付すらバリデーションしてないのは
やる気ないだけだろう
Re: (スコア:0)
「先月」ボタンを960回クリックさせようとするんだろうな
Re: (スコア:0)
同じ意見です。
システムとしてもうちょっと何とかしてもよかったとは思うけど、何か問題になるかと言えばそうじゃない。
1%ぐらいミスで照合できなくて当日に接種できなかったとして、次の日に回せばいいだけで問題にならないと思う。
ワクチンは治療と違うから即どうこうなるわけじゃないし、どうせ無料で全員接種する予定なんだから、対象じゃない人に打っても大きな問題ない。
Re: (スコア:0)
それもあるけど、なんで高齢者対象の段階なのに、生年月日のデフォの選択年が「昭和45年」なのか？
誰が合理的な説明を教えてくれまいか？
せめて高齢者の下限ぎりぎりでセットしとけよと
Re: (スコア:0)
Re: (スコア:0)
今後一々その辺変更しないから。
その辺の手順増やすとミス発生に繋がる。
Re: (スコア:0)
アップデート履歴
2021/6/3 生年月日のデフォルト選択を「昭和45年」に変更しました。
2021/5/31 生年月日のデフォルト選択を「昭和40年」に変更しました。
2021/5/20 生年月日のデフォルト選択を「昭和35年」に変更しました。
2021/5/10 生年月日のデフォルト選択を「昭和30年」に変更しました。
とか段階で変更するの？
Re: (スコア:0)
このコメント見てるだけでも
「偽りを述べる者が愛国者とたたえられ、真実を語る者が売国奴と罵られた世の中を、私は経験してきた。」の様相を呈してきたな…
Re: (スコア:0)
そのご都合主義な「チェック」の仕様を述べよ
Re:市区町村コードくらいは (スコア:1)
システム開発の教科書でいいかい？
Re: (スコア:0)
教科書の内容で大規模システムの(上っ面だけじゃない)チェックが行えるならいいよ
Re: (スコア:0)
実際に存在する自治体コードかどうかを確認することがそんなに難しいのですか．
あなたがお勤めの会社が何らかのオンラインサービスに関わっているのでしたら，その程度の技術力のところには発注しないでほしいです．
Re: (スコア:0)
で、自治体が発行した予約番号に自治体コードって入っているの？
Re: (スコア:0)
自治体が発行した接種券に、券番号１０桁と市区町村コード（自治体コード）６桁が記入されてた
（親の接種券を見た）
予約はまだしてないので、予約番号というのはよくわからない…
Re: (スコア:0)
エア開発者だらけだな
Re: (スコア:0)
市町村コードくらいはチェックしろというのは同意します。その上で、なんですが……
ただ「チェック機能入れるだけ」では済まなくて、都度更新されるので、過去のマスタも保持する必要があり、ちゃんと設計しようとすると面倒なことになります。
面倒を避けるために国交省や農水省が公開している電子納品チェックシステムは定期的にブランチ切ってコードフリーズみたいなことをやってますね。
いずれにしろコードの一覧が公開されている以上、悪意のある入力を弾くことはできないので、誤入力対策でしかないのは留意する必要があります。
Re: (スコア:0)
上の方にも書いてあるが、せめて接種券番号にチェックデジット入れるだけでいいだろ・・・
Re: (スコア:0)
接種券番号は自治体主管だから無理。
人口100人くらいの村から来た爺さんにチェックサムの仕組み説明できるか？
Re: (スコア:0)
こっちで作った番号を100個持たせて返せよ
検証アプリも渡したほうが良いか むしろURLかな?
Re: (スコア:0)
別に未来永劫維持するシステムではないので手メンテできれば十分ですが。。。
それともあなたの世界線では日々数件以上の市町村コードが変更されているのですか？
Re: (スコア:0)
契約期間終了後の「手メンテ」は誰がするのよ？
Re: (スコア:0)
契約期間終了後に限らず、契約期間中の市町村コードの改訂は誰が責任もって監視して追従するのかという話になる
リアルタイムで更新していくのか、年度ごとにマスタを管理して更新していくのか、市町村側とも歩調を合わせないといけない
やれと言われたらやるのは難しくないけど、そこに至るための合意を得るのに時間が掛かるのが縦割りの官公庁
Re: (スコア:0)
契約期間終了後に限らず、契約期間中の市町村コードの改訂は誰が責任もって監視して追従するのかという話になる
リアルタイムで更新していくのか、年度ごとにマスタを管理して更新していくのか、市町村側とも歩調を合わせないといけない
やれと言われたらやるのは難しくないけど、そこに至るための合意を得るのに時間が掛かるのが縦割りの官公庁
NHKニュースによるとこの「大規模」接種は8月下旬までの期間限定らしいよ。
年度メンテなんて発生しない。
https://www3.nhk.or.jp/news/html/20210517/k1 [nhk.or.jp]
Re: (スコア:0)
寄与率1/16000って、日本のその他の場所で2億4千万回/日もの接種できるリソースがあるってこと？
それとも、この大規模接種会場はたった1日しか稼働しない前提ですかね。
Re: (スコア:0)
SQLのJOIN部分で変なことになんないのかとか、画面表示は業務的に正常な何かになるのかとか、いろいろ気になっちゃう。
この記事のコメント量から、メンテ前に登録した予約は参照更新が上手くできませんとかあったらむっちゃ叩かれそうやで
これくらい雑な運用でええやろ (スコア:0)
市町村コードくらいはチェックしろというのは同意します。その上で、なんですが……
ただ「チェック機能入れるだけ」では済まなくて、都度更新されるので、過去のマスタも保持する必要があり、ちゃんと設計しようとすると面倒なことになります。
市町村コードって合併とかあったら変わるもんでしょ？
センターの運用期間内（2年くらいか）に合併がなさそうなら無視していいんじゃない？
合併があったらそんとき手作業で変えればいい
Re: (スコア:0)
合併してコードが変わっても券は変わらないパターンもありえるし、防衛省はコードの責任省庁ではないからコードがどう変わるか責任を取れない
調整したら時間がかかる
まあ多分大丈夫でしょで万一が起こることに目を瞑るかザルにするかの選択にならざるを得ないかと
Re: (スコア:0)
そういうの全部ひっくるめた上で雑な運用をするというのなら、それはそれでアリ。
一度そういう検討を経て、市町村合併でコードが一致しない事象も発生し得ることが分かっていれば、バリデーションチェックで引っ掛かったときに「未知のコードが入力されました。この現象は市町村合併で生じることがあります。本当にこのまま送信しますか？」といった警告で通す設計も考えられる。
何も考えずに、ただ市町村コードをチェックしろみたいなのが一番ダメ。事前に想定したコード以外は絶対に通さないクソシステムの出来上がり。
Re: (スコア:0)
同じ期間・工数で作れるかどうか考えたら、答えが見つかるかもしれない
# いや、実際は金も時間もあったのにクソみたいなところが作っただけかもしれないが