ネットワーク処理で複数ユーザーを並列処理するケースはシングルタスクの単一思考では対応や想像できんな
大規模システムや多重請負構造を変えていかないとまともな人材育たんよ
子供でもわかること。
回線異常、停電、用紙切れ、紙詰まり、処理途中での退席（トイレとか）いろんなペンディング状態あると思うよ
で各ケースでちゃんと処理考えられて設計されてるのか１つの印刷イメージファイル使いまわすようなシステムとか呆れるしかない
システム開発でどこ関係か話が上がって富士通とながでると、その場にいた全員がため息をついて完成しねーなって話になる。
意味ないよ
それじゃあ責任も有耶無耶だわな
日本経済の停滞の元凶の一つ
1人だけ当たりくじ引ける抽選会してるようなもんだ当たりくじさえ出ないイカサマかもしれん
ゆとりは永遠の5歳児だから池沼餓鬼w
こ、ろされとけ
ゆとりは永遠の5歳児だから池沼餓鬼w
こ、ろされとけ
ゆとりは悪魔w首謀者のルフィもゆとりだったなしなぁw
ゆとりは永遠の5歳児だから池沼餓鬼w
こ、ろされとけ
ゆとりは悪魔w首謀者のルフィもゆとりだったなしなぁw
奴隷でもずっと残っていればまだいいが
開発終われば使い捨て
トラブル発生して右も左も分からない新しい奴隷を集めた所で上手くいくはずもない
安月給で人件費抑えようとして劣化してる
みじめな現実＞＜
醜いのはホスト端末にネットワーク共有ファイルとして検査データ1つで管理してた同期や排他処理なしで上書き保存
よく検査データ抜けや患者の時系列データがおかしくなって苦情電話来てたけど気のせいとか再度お願いして受け流してた最低なとこだった
更にダメージ食らったのは共有ファイルのインデックス領域がデータ量超えて破壊されたことだ
できもしない機器売りつけんなと怒り覚えたね
他でも別の会社で、富士通のサーバーでOEMのディスクシステムのマニュアル誤りで構築できなかったり悪い印象でしかないな
公共システムのデスマーチ的なのも見てきたけど下っ端はお気楽なもんだった その場にいたくなかったよ意味のない徹夜に感じて
なんで違うIDのデータを取得できる?wwww
まここまで行くとセブンペイだっけ?
と同じで信用して全くんしでしょ。信用のために住民票ってあるんだがwwwwwww
でしょ？
信じられないレベルだよ
意味わからん。日本語で書けやブンヤなら
それをきちっと参照できないなんて、ほんと日本ってイットに弱いね
中学生が書いたのならともかく
こんなものリリースする自称ＩＴ企業って
しかも大手ときたもんだ
ゆっくりやればよかったじゃないか運び屋君。
なんかそんなに急ぐ理由でもあるのかい？
エマニュエルから脅されたの？
誰から言われてるのかな？
あほーというかなんかそこまでせんといかん外圧を感じるわ。
エンジニアは責任持てないからこんな雑なリリースはしない
勝手にもっときっちりしてるんかと思ってたがどこもいっしょか
登録
とは？
問題は、丸投げした先の下請けが作ったものをチェックして、間違いがあれば修正させる管理能力があるかどうか
これはＩＴゼネコン側の担当者にそれなりのスキルが無いと難しい
おそらく社内の技術者が劣化し、管理能力が落ちまくっているのだろう
人を育ててこなかったんだろうな
下請け企業の報告を鵜呑みにして「問題ありません」としていたに違いない
設計にデザインは？
だから国が自主開発してナンボなのよね
デジタル庁職員にプログラム作らせろと
ええ大学出て優秀なんだろ
すぐできるだろうが
いまだに会見を開かずに逃げ回っている
そこも丸投げしてる可能性もあるし、自社でやってる可能性もある
ITゼネコンにより、同じ会社内でも部署により、様々だから
全然 原因の説明になってないと思うのは俺がだけかな
この記事書いた記者さん 自身これで 原因を説明してると思ってるのかな
こういうとこに我が国の劣化度合いが出てると思わない？
これはシチュエーションが理解されてないと、全然ピンと来ないだろうな。
まず、役所に転居届を出しに来た人が居たとする。
１．転居届を役所の窓口に出す
２，役所内のキヲスク端末で住民票を発行しようとする
３．まさにこのとき、役所の中の人が転居届の内容を住基システムに入力し、エンターキーを叩いた
４．あ、他人の住民票が出て来た!!!
ごく一瞬の隙をついた、偶然の産物ってことだわ。
だけど偶然だからしょうがないよね、じゃ済まない話でさ。
だからなんでこれで他人の住民票が出るのよ
更新前の住民票が出るのはわかるよ
そんな金魚が空を飛ぶようなことが起こってるから、こうやって問題になってるんだろうw
ワイもSEじゃないんでこれ以上は説明ができん。だれか噛み砕いて教えてクレメンス。
住基システムは自治体によってメーカーが違うから、コンビニ交付システムとは
何らかの住基情報の連携をしてるはず
まさかとは思うが、CSVまたは固定長ファイルでの連携とかじゃないよね・・・
２０年前ならまだしも、今のご時世にそんなことはないと信じたい
JSONなら満足かよ？
トランザクション、難しくね？
やってやれない事も、無いだろうけど
形式はなんでもいいのだけれど、今どきファイル共有レベルで住基情報の
連携してないよね？ってことを言いたかった。
他人の情報がそのIDに登録されてんでしょ？
登録業者の問題がデカそうだなw
じゃあ更新うんたら関係ないじゃん
個人番号は、一意でしょ？
そこから否定するの？
そこ間違えて入力したらこうなるわな
えーっと
この話（この出来事）、理解してます？
データの不整合ってのは、>>501の例で言えば、住民票発行申請時点では届出前の旧住所だったのが、印刷処理時点では届出後の新住所になってるみたいな話だわ。
だったら届出後の新住所が印刷されるでしょ
何で他人の住所が印刷されるのかね
個人番号（マイナンバー）って、仕組みを
理解してますか？
このスレやなんかでシステムわかっている人の書き込みを見てると、たぶんそんなのをはるかに超えたもっと低レベルなお粗末な話です、良く知らんけど。
事象としては
またまた、
他人のデータが
プリントアウトされた
って話では？
Ｆがそう回答したから、
そのまま書いてるだけでは？
知らんけど
以下、あくまで想像
a)
住基システムは住基情報に変更・追加・削除があるたび、コンビニ交付システムに変更データを送る
or
コンビニ交付システムが定期的に住基システムに問い合わせて住基情報の変更・追加・削除のデータをもらう
↓
b)
コンビニ交付システムは内部のDBに変更・追加・削除情報を取り込む
1. Aさんが住民票の発行リクエストを出す
2. コンビニ交付システムがAさんのデータをマイナンバーをキーにして検索する→「マイナンバー12345番の住基情報の番号は67890番です」
3. 番号67890番をキーに住基情報を検索する
4. 3. と同時に a) b)の処理が入り、 3.の結果がかえって来るときには番号67890番のデータはBさんのものになっていた
5. コンビニ交付システムは番号67890番のBさんの住民票を作成して印刷
こんなずさんな処理をしてないと信じたい
以前のトラブルの時の富士通の説明を私が読み違えてなければ多分こんな感じ
(1)同時に印刷依頼が発生すると中身を取り違えるおそれは元々あって、防止する制御も組み込まれている
(2)住民台帳の変更があると、住民票発行システム側に変更を取り込む処理が動くが、その処理中は前項の取り違え防止の制御が外れてしまう
ここまでが前回のトラブル
取り違え防止が外れないように修正したつもりだったが直ってないパターンがあったってのが今回かなと
前回のトラブルの説明ありがとう。
> >>537
> (1)同時に印刷依頼が発生すると中身を取り違えるおそれは元々あって
なんでこんなことが起きるのかね
> 取り違え防止が外れないように修正したつもりだったが直ってないパターンがあったってのが今回かなと
台帳更新のイベントだけが取り違え防止が外れるトリガーなら、そのトリガーへの反応を修正した 直るはず なんで、他にもいっぱい条件があるような気がするな
富士通は全体を発表してないか、そもそも プログラマーを管理してる管理者とかデジタル庁が仕様を理解していないか
どちらにしろバグ 潰し はまだいろいろあり そうだな
> > (1)同時に印刷依頼が発生すると中身を取り違えるおそれは元々あって
>
> なんでこんなことが起きるのかね
よく分からんので曖昧にしたけど別々のコピー機に対して同じファイル名使ってるとかかな
そして本来直すべきはそっちなんだろうけどお客様相手のシステム開発してる人達は、トラブルの修正対応というと起きたトラブルに直接関与するとこだけ直すのが習性になってる
他に影響が出るかもしれないとか必要な再テストが膨大な量になるとか
> 別々のコピー機に対して同じファイル名使ってるとかかな
どういう意味？
コピー機Aに送付するファイルなら202307010409_A.pdfとかにしてどのコピー機に送るファイルか間違えないようにしとけばいいのに、宛先の区別がつかないファイル名になってるんじゃないかなって話
まあファイル名でなくても要はちゃんと区別がつけばいいんだけど
実際印字するコピー機に極力個人情報を送らない、保存させない、とか
外字／異体字とかの管理を考えると、コンビニ交付システムで印刷イメージまで
作成して（jpgとかpngとか）、それをコピー機に送るのかな
そうなると、ファイルレベルでのやり取りをすることは考えられる
ファイル名で完全にユニークになるならいいけど、設計が甘いとどうなるかな
それはないやろ
それが原因だったら 間違いが今の件数で済むわけがないからな
最初の釈明が、嘘っぱち
説
＞台帳更新のイベントだけが取り違え防止が外れるトリガーなら、そのトリガーへの反応を修正した 直るはず なんで、他にもいっぱい条件があるような気がするな
だｙね、まだまだ発生しそうな気がするよね。
多分、トランザクション分離レベルをガッチガチにすることはできるのかもしれないけど、
そうすると処理性能が極端に落ちて、仕様を満たせないんじゃないのかなと想像
なぜに、
アウトプットが変わる（間違った出力する）の？
他メーカーはできてるぽいから本当はできるんじゃないかな
ありがちな事情としては、昔の機械では性能上そうする必要があったとか昔の開発環境ではそういう書き方ができなかったとか
昔の手法を身につけてその後は勉強してない人達が発言力だけはあったりすると最新環境が宝の持ち腐れになる
マイグレーションやらコンバージョンなんて作業時に
そう言うところも加味してキチンと作業出来るところって中々無いんだろうね
昔からこれを使ってるから、現行がこうだからで
脳死でそのまま引き継いで先祖代々伝わる
秘伝のスパゲッティソースになっていく
マイナンバーは制度自体が本格化してきたのはここ数年だけど
ゼロベースで開発なんてしないだろうから
結局古い手法が入り込むんだろうね
前回のトラブルの説明ありがとう。
> >>537
> (1)同時に印刷依頼が発生すると中身を取り違えるおそれは元々あって
なんでこんなことが起きるのかね
> 取り違え防止が外れないように修正したつもりだったが直ってないパターンがあったってのが今回かなと
台帳更新のイベントだけが取り違え防止が外れるトリガーなら、そのトリガーへの反応を修正した 直るはず なんで、他にもいっぱい条件があるような気がするな
富士通は全体を発表してないか、そもそも プログラマーを管理してる管理者とかデジタル庁が仕様を理解していないか
どちらにしろバグ 潰し はまだいろいろあり そうだな
> > (1)同時に印刷依頼が発生すると中身を取り違えるおそれは元々あって
>
> なんでこんなことが起きるのかね
よく分からんので曖昧にしたけど別々のコピー機に対して同じファイル名使ってるとかかな
そして本来直すべきはそっちなんだろうけどお客様相手のシステム開発してる人達は、トラブルの修正対応というと起きたトラブルに直接関与するとこだけ直すのが習性になってる
他に影響が出るかもしれないとか必要な再テストが膨大な量になるとか
> 別々のコピー機に対して同じファイル名使ってるとかかな
どういう意味？
コピー機Aに送付するファイルなら202307010409_A.pdfとかにしてどのコピー機に送るファイルか間違えないようにしとけばいいのに、宛先の区別がつかないファイル名になってるんじゃないかなって話
まあファイル名でなくても要はちゃんと区別がつけばいいんだけど
実際印字するコピー機に極力個人情報を送らない、保存させない、とか
外字／異体字とかの管理を考えると、コンビニ交付システムで印刷イメージまで
作成して（jpgとかpngとか）、それをコピー機に送るのかな
そうなると、ファイルレベルでのやり取りをすることは考えられる
ファイル名で完全にユニークになるならいいけど、設計が甘いとどうなるかな
それはないやろ
それが原因だったら 間違いが今の件数で済むわけがないからな
最初の釈明が、嘘っぱち
説
＞台帳更新のイベントだけが取り違え防止が外れるトリガーなら、そのトリガーへの反応を修正した 直るはず なんで、他にもいっぱい条件があるような気がするな
だｙね、まだまだ発生しそうな気がするよね。
多分、トランザクション分離レベルをガッチガチにすることはできるのかもしれないけど、
そうすると処理性能が極端に落ちて、仕様を満たせないんじゃないのかなと想像
なぜに、
アウトプットが変わる（間違った出力する）の？
他メーカーはできてるぽいから本当はできるんじゃないかな
ありがちな事情としては、昔の機械では性能上そうする必要があったとか昔の開発環境ではそういう書き方ができなかったとか
昔の手法を身につけてその後は勉強してない人達が発言力だけはあったりすると最新環境が宝の持ち腐れになる
マイグレーションやらコンバージョンなんて作業時に
そう言うところも加味してキチンと作業出来るところって中々無いんだろうね
昔からこれを使ってるから、現行がこうだからで
脳死でそのまま引き継いで先祖代々伝わる
秘伝のスパゲッティソースになっていく
マイナンバーは制度自体が本格化してきたのはここ数年だけど
ゼロベースで開発なんてしないだろうから
結局古い手法が入り込むんだろうね
67890番のデータを修正するからそれはありえない
あるいは 67890番には データなしにして修正後のデータに 別の番号を付与して、同時にマイナンバーとデータベースのデータ 番号の対応表も 修正する
ほんまに 何が原因か分からん
もう一つ 以前も横浜かどっかで他人の情報が印刷されること起こってたよね
その時の原因は何だったのかな
総点検で横浜の件に対する対応は確認されたはずだよな
要はdirty readとかfuzzy readとか起こってるんじゃないか、ってこと言いたかったんだけど、
さすがにそんなずさんな処理してないよね
横浜の件は印刷制御に問題があったって言ってたから
もしかしたら
コンビニ端末がコンビニ交付システムから印刷イメージを取得する際、共有ファイルで
やり取りしてて、そのファイル名がユニークでなかったのかもしれん
年月日時分秒.pdfみたいなやつ。
> 年月日時分秒.pdfみたいなやつ
あはははは
さすがに、そんな処理してないと信じたいよね
492 だけど、俺はシチュエーションを理解した上で それで何で他人の住所が出てくるのかの説明になってない記事だとと思ったんで質問したんだけど、あなたは不審におもわなかった？
それは･･･システムのつくりがあまりにお粗末過ぎるのがバレるんで、たぶん口が裂けても言えないんだと思うよ。
法律で制限しろ
NECと富士通は、日本の花形企業だったんだけどねぇ～
もう、ダメポ
いないし、出来ないよ
口だけ出す奴ばかりでしょ
何かあれば責任を取らせる
だから、小さなベンチャー企業とは契約しない
損害賠償1つでt倒産するような規模の会社では困るからね
コメント